Subsampling-based ALE subtraction analysis

In a couple of recent papers (Gu et al., 2019; Poudel et al., 2020), a new subsampling-based version of the ALE subtraction has been implemented to account for unbalanced groups.
It seems to me that the additional subsampling is unnecessary, as the standard method should be able to account for unbalanced groups just fine, but I'd like to get others' thoughts on it and see if we should add it to NiMARE.
First, I'll start with a description of the ALE subtraction method, as it is implemented in NiMARE:

Define voxels to analyze for group 1 > group 2 and group 2 > group 1 contrasts based on significant voxels from group 1 ALE and group 2 ALE, respectively.
Calculate ALE values for group 1 and group 2 datasets.
Calculate ALE-difference scores (group 1 ALE - group 2 ALE), restricted to selected voxels from first step.
Build voxel-wise null distributions of ALE difference scores using N permutations via the following procedure:
a. Randomly shuffle group assignments for experiments across both groups.
a. Calculate ALE values for each new "group".
a. Calculate ALE-difference scores for the two shuffled groups.
For each selected voxel, determine p and z values for real ALE-difference scores from null distribution of ALE-difference scores.

Here's the description of the subsampling method from Poudel et al. (2020):

To identify brain regions showing differential activity convergence between studies involving substance using versus non-using participant samples, we employed a permutation-based technique previously utilized for assessing two unequally-sized sets of contrasts/coordinates (Eickhoff et al., 2016, 2009; Gu et al., 2019). Specifically, the two datasets under consideration involved 40 contrasts from 29 papers among substance non-using samples (Table S4) and 25 contrasts from 14 papers among substance using participant samples (Table S5) probing risky-DM. In general, this permutation technique involved: 1) randomly sub-sampling both datasets to a number equaling 90 % of the total contrasts in the smaller dataset, 2) calculating thresholded ALE images separately for both datasets, and then 3) performing a contrast analysis between the now equally-sized groups. These steps were repeated 500 times and each voxel’s frequency of reaching significance was recorded.
More specifically, the following operations were performed for each of the 500 permutations. First, both datasets were randomly sub-sampled to a number equaling ∼90 % of the total contrasts in the substance user dataset (i.e., to n = 22 contrasts per group). Second, whole-brain ALE images for both groups of contrasts were computed, and multiple comparisons correction was separately performed for each group (user and non-users) using a Monte Carlo approach with 10,000 iterations to construct a null distribution (as described above). The ALE images generated from each of the 500 permutations were then thresholded (pvoxel < 0.001, cluster-extent pFWE-corrected < 0.05). Third, for the contrast analysis (users vs. non-users), the two groups’ unthresholded ALE statistic maps were subtracted to generate voxel-wise ALE difference scores. A Monte Carlo procedure was then used to create a null distribution of 10,000 maximum ALE difference scores after randomly shuffling activation foci between datasets. Only those voxels with an ALE difference score greater than the 95th percentile of the null distribution (pFWE-corrected < 0.05) were retained for each of the 500 permutations. In sum, this permutation procedure yielded 500 separate thresholded ALE images for both the substance user and non-user datasets and 500 thresholded ALE difference score maps (users vs. non-users). Finally, each of these three types of maps were binarized and summed to produce a voxel-wise frequency (f) of significance map compiling the outcomes from each of the 500 permutations. While a similar meta-analysis in the context of ambiguous-DM may provide additional insight into brain alterations among users versus non-users, we focused on risky-DM given our a priori interest on risky-DM and that a sufficient number of ambiguous-DM contrasts among substance users could not be identified in the literature.

I agree I don't really see the point of subsampling here; it doesn't seem like different N's should be a problem, but I didn't read carefully.
I'm a bit concerned about (1) in your description of ALE, however. If you start by defining voxels for the A vs. B contrast based on whether they're significant in A alone or B alone, you're heavily biasing the results, no? I could see a (bad) argument for using sub-sampling to mitigate that bias (under the assumption that by fixing N you're equalizing power in both groups), but the more sensible thing to do would be to use a non-circular procedure to select voxels. But maybe I'm missing something. Is there any good reason not to use all voxels in the A/B contrast, other than computational efficiency?

I agree that subsampling rarely makes sense, but I assumed that the motivation was that ALE statistic is not normalised, so that if you got equal proportion of studies in each group, you might find ALE differences if the group sizes are different?
It also points to the problem that ALE value is really a type of statistic about rejecting a null hypothesis of homogeneity... comparisons of test statistics are always a bad idea.

Thank you both for responding so quickly!

If you start by defining voxels for the A vs. B contrast based on whether they're significant in A alone or B alone, you're heavily biasing the results, no? I could see a (bad) argument for using sub-sampling to mitigate that bias (under the assumption that by fixing N you're equalizing power in both groups), but the more sensible thing to do would be to use a non-circular procedure to select voxels. But maybe I'm missing something. Is there any good reason not to use all voxels in the A/B contrast, other than computational efficiency?

I think it does bias the results, but I believe that the decision to exclude non-significant voxels was a practical one. Apparently, if there is any convergence in a voxel for one group, and none for another, the contrast results become highly significant, even when the first group would not find anything near significant convergence at that voxel.

I agree that subsampling rarely makes sense, but I assumed that the motivation was that ALE statistic is not normalised, so that if you got equal proportion of studies in each group, you might find ALE differences if the group sizes are different?

I hadn't thought of that, but that does make sense. ALE isn't normalized, so the raw difference scores would be biased toward the large group in cases of equal levels of convergence. But wouldn't that be reflected in the empirical null distribution from the standard contrast analysis as well?

It also points to the problem that ALE value is really a type of statistic about rejecting a null hypothesis of homogeneity... comparisons of test statistics are always a bad idea.

Whoa... I hadn't really thought of it like that.

I think it does bias the results, but I believe that the decision to exclude non-significant voxels was a practical one. Apparently, if there is any convergence in a voxel for one group, and none for another, the contrast results become highly significant, even when the first group would not find anything near significant convergence at that voxel.

If this is right then it sounds like a pretty good reason not to trust ALE subtraction at all, which accords with @nicholst's concern. There's no reason to think the bias would disappear for voxels that are significant for group A; it's just that the fact that you've already called them significant would hide the bias. If there isn't good simulation data showing that the procedure maintains the nominal error rate (or at least something close to it), I feel pretty strongly that we shouldn't include it in NiMARE. If we implement it, people will use it, and they likely won't have any clue about what's going on under the hood. (This kind of thing is a big part of the reason I eliminated the "custom analysis" functionality from neurosynth.org a few years ago.)

On thinking about this a bit more, it's not clear to me where the bias you describe would be coming from. Under the assumption that studies are exchangeable between groups (which seems reasonable), I think the p-values from the permutation analysis should be valid, even though the null distribution itself is likely to be biased away from 0 if the groups have different sizes. Are you sure this wasn't a problem only for earlier versions of ALE subtraction where the null was generated by randomizing activations in space, as opposed to permuting group membership? If that's correct (i.e., this is no longer a problem), then I'm fine keeping ALE subtraction in NiMARE. But in that event we should definitely drop the constraint that only significant values are analyzed, because that will definitely introduce a (strong!) bias.

The issue is just about units.  The ALE statistic is roughly like a sum of kernel density estimates.  The null hypothesis is that the 'population' ALE for group 1 map is equal to the population ALE group 2 map.  If the count of studies is equal then this null hypothesis will be true; but if the proportion of studies is equal you'll violate the null when n_1 and n_2 are unequal.  This is exactly the concern for the random shuffling of group (I wasn't assuming random spatial shuffling).
This is why I assumed someone would sub-sample to get equal sample sizes so that sums and proportions are the same thing.

@nicholst yes, that makes sense. My comment above was directed at @tsalo. I think we're talking about two different issues. I didn't realize that we're currently selecting voxels for A vs. B comparison based on showing significant effects for A or B alone, which is unrelated to the question of how to interpret a difference in ALE scores. The current voxel selection procedure is clearly circular, and will produce biased p-values (on the assumption that one corrects only for included voxels, and not the whole brain). I was trying to figure out where the justification for that came from, as I don't see any reason the current permutation analysis implementation would justify it. My guess is it's a hold-over from earlier versions of ALE subtraction.
In any case, as long as we eliminate the biased selection procedure, I'm fine leaving things as-is (I agree that interpretation of the subtraction analysis is hard, but that's the user's problem, I don't see it as a software issue). (@tsalo, if computational efficiency is an issue, let's touch base next week or the week after—I'm pretty sure we can optimize ALESubtraction quite a bit.)

BTW, @tsalo, at bare minimum (and preferably soon) we should generate a warning when users use the current ALESubtraction implementation. AFAICT from a quick glance, it doesn't look like they have any way of knowing that voxels that show A > B or B >A are a strict subset of (A || B). I assume we give back whole-brain maps, so the current approach will give a naive user the impression that there just weren't any other voxels that showed differences, when actually the algorithm never even looks at other voxels.

@nicholst, I believe that the empirical null distribution accounts for the problems with units, though. If the dataset counts are the same, and the proportions are the same, then the ALE difference score null distribution should be roughly centered around zero. If the dataset counts are different (let's say dataset 1 has many more studies than dataset 2) but the proportions are the same, then ALE scores should skew positively, but then so should the null distribution, right?
@tyarkoni Right, sorry, I meant that the voxel selection does sound like it would be biased, but the null distributions are derived voxel-wise, so I think the two elements are independent. I can add a warning to the ALESubtraction soon (before the next release), and can even update the Estimator's masker to reflect that it's only some voxels. I don't think computational efficiency is a major concern, and I haven't tried running it without the voxel selection, so I don't know if that's still a concern. I could try it though.
If it does turn out that running the standard subtraction analysis without voxel selection does produce weird results in edge voxels, then would you both prefer to have me implement the subsampling or retain the voxel selection?

@tsalo First let me say I haven't read the two papers you referenced, but, now that I worked out two cases, it might be OK.
Taking as a given that ALE is approximately an addition of kernels and not an average, we can do the following:   Suppose at some location we have group A with 4 in 10 studies with foci, and group B has 4 in 100 studies with foci, then the observed A-B difference in ALE maps should be about zero; under null random permutation, however, you have (on average) in group A 8/11010 ≈ 1 in 10 studies with foci and in group B 8/110100 ≈ 7 in 100 studies with foci; so your A-B null ALE distribution will be shifted quite negative you'll have evidence that zero is much larger than expected by chance and reject the null in favor of A>B.
Now, if consider equal rates: group A has 4 in 10 studies with foci, group B has 40 in 100 studies with foci; your ALE difference map will have A << B, but under null permutation expecting group A to have 44/11010 = 4 in 10 studies and group B to have 44/110100=40, and you should get ALE difference maps with similar characteristics as the observed, and you shouldn't reject the null.
So... OK... it's doing something sensible by the magic of permutation!  Am I understanding the methods correctly?
So, even though the ALE maps are 'wrong' for the task at hand (IMHO) by being based on sums instead of averages, permutation saves you by having a null distribution driven equal proportions under the null.

@nicholst Absolutely, that is my understanding of the standard ALE subtraction analysis.

I think the issues with the standard ALE subtraction method have been figured out, and the issue with voxel selection will be handled by #245. Given that the empirical null distribution should be valid and that circular voxel selection will soon be eliminated, can either of you see any benefit to the subsampling wrapper described in the first comment?

Nope, I'm fine ignoring those papers and closing this.

Sounds good to me!


docker 1.7.0-rc1 does not fall back to Docker Hub gracefully when mirror not available

Using docker 1.7.0-rc1, the docker engine will no longer fall back to using direct connection when a docker v1 mirror is not available:
Error response from daemon: invalid registry endpoint https://mirror.core.dckrindy.io:5000/v0/: unable to ping registry endpoint https://mirror.core.dckrindy.io:5000/v0/
v2 ping attempt failed with error: Get https://mirror.core.dckrindy.io:5000/v2/: dial tcp: lookup mirror.core.dckrindy.io on <IP_ADDRESS>:53: server misbehaving
 v1 ping attempt failed with error: Get https://mirror.core.dckrindy.io:5000/v1/_ping: dial tcp: lookup mirror.core.dckrindy.io on <IP_ADDRESS>:53: server misbehaving. If this private registry supports only HTTP or HTTPS with an unknown CA certificate, please add `--insecure-registry mirror.core.dckrindy.io:5000` to the daemon's arguments. In the case of HTTPS, if you have access to the registry's CA certificate, no need for the flag; simply place the CA certificate at /etc/docker/certs.d/mirror.core.dckrindy.io:5000/ca.crt

In this case, I am not in the same location as the mirror.  Previous behavior was that it would just bypass the mirror but it no longer falls back to direct connection as expected.
Docker daemon parameters:
/usr/bin/docker -d -s overlay -H fd:// -H <IP_ADDRESS>:2376 --tlsverify --tlscacert=/etc/docker/ca.pem --tlscert=/etc/docker/server.pem --tlskey=/etc/docker/server-key.pem --registry-mirror=http://mirror.core.dckrindy.io:5000
I am running docker on debian sid using the .deb from test.docker.com.  I revered back to 1.6.2 and it works as expected.

If you are reporting a new issue, PLEASE make sure that does not have any duplicates already open.
We would like to take this time to remind you of the information we need to debug the problem you are seeing. This is an automated response so if this ticket is not about a bug, do not fret.
If you fail to provide this information within 7 days, we will close this because we cannot debug your issue. We can reopen whenever the information is provided.
Thank you.
Please see:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues
Description of problem:

`docker version`:

`docker info`:

`uname -a`:

Environment details (AWS, VirtualBox, physical, etc.):

How reproducible:

Steps to Reproduce:
1.
2.
3.

Actual Results:

Expected Results:

Additional info:

#ENEEDMOREINFO

@RichardScothern Do you mind taking a peak?

Yep, I'm on it. @stevvooe

Awesome.  Definitely fixed in RC2 :+1:


It's not compiling... Gradle sync issue

Could not find com.android.tools.build:gradle:3.0.0.
Searched in the following locations:
https://plugins.gradle.org/m2/com/android/tools/build/gradle/3.0.0/gradle-3.0.0.pom
https://plugins.gradle.org/m2/com/android/tools/build/gradle/3.0.0/gradle-3.0.0.jar
https://jcenter.bintray.com/com/android/tools/build/gradle/3.0.0/gradle-3.0.0.pom
https://jcenter.bintray.com/com/android/tools/build/gradle/3.0.0/gradle-3.0.0.jar
Required by:
project :app
Add google Maven repository and sync project
Open File

我也是这个问题，请问怎么解决呢


ARROW-6754: [C++] Merge allocator.h into stl.h

Merged files into stl.h and also merged the test file allocator_test.cc into stl_test.cc.

Do we want to keep a tiny allocator.h that includes stl.h to ease transition?

Do we want to keep a tiny allocator.h that includes stl.h to ease transition?

IMHO that's not necessary. This is a little-used interface, probably.

Thanks for the changes. Several things to do:

you should rebase from git master, this will fix the AppVeyor failure
as you can see on Travis-CI, linting the C++ code failed; you'll have to fix the issues
there were also some doc building issues on Travis-CI (in the failed Python job), probably due to the class name changes); you can see here about building the documentation

May still have an issue with the documentation.  I built the docs using the docker container but still got warnings.  Not 100% sure why its not updating properly...

Still lint issue on TravisCI  build.  I ran arrow/run_cmake_format.py and make lint.  Are there any steps Im missing?

Easy to misread: there is run_clang_format.py and run_cmake_format.py

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@ed753fd). Click here to learn what that means.
The diff coverage is 90.38%.

@@            Coverage Diff            @@
##             master    #5560   +/-   ##
=========================================
  Coverage          ?   89.37%
=========================================
  Files             ?      791
  Lines             ?   116966
  Branches          ?        0
=========================================
  Hits              ?   104535
  Misses            ?    12431
  Partials          ?        0

Impacted Files
Coverage Δ

cpp/src/arrow/stl_test.cc
97.75% <100%> (ø)

cpp/src/arrow/stl.h
95.48% <83.87%> (ø)

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 ed753fd...cd503f8. Read the comment docs.

Rebased by hand on garbled master.

Merged. Thank you @david1437 !


White spotlight effect on inference images with custom-trained model

Hi,
I am training a model on my dataset. It shows good results saved by the training script during validation. But when I use a saved checkpoint file with the provided inference script it gives a white spotlight effect to the output. It also produces flipped output sometimes. Here is an example
Input

Val Output

Inf Output

I am looking forward to your kind help.

There may be some bugs in the image input/output normalization of the inference script. You can try using the test script to process the aligned images, which is similar to the validation.

Thanks. Solved it by adding normalization and hflip in preprocessing. Just for my information did you train your model without normalization and hflip preprocessing?

We use flip preprocessing randomly and normalize the lq images to [0, 1] following ControlNet when we train our model.

Hello, I see that you successfully run this code, but when I try to reproduce it, I always get stuck after running an epoch, and then it says' CUDA out of memory ', in fact, I must have enough memory, I would like to know how you reproduce it, what is your environment configuration or what changes have been made, thank you very much.


Fix XRBodyModifier3D hip driving for avatars no Root bone

The XRBodyModifier3D node fails to correctly drive avatars which have no Root bone. This occurs on common avatars such as ReadyPlayerMe, Mixamo, and AvaturnMe where the root bone of the skeleton is the hips. The importers Skeleton Retarget doesn't add a Root but instead leaves the Hips as the root bone but with the corrected name.
The XRBodyModifier3D code assumes their must always be a bone associated with the Root tracking joint, and picks bone 0 (the first bone) if it didn't find it by the correct bone name. Unfortunately if it does this with an avatar where bone 0 is the hips then it associates the hips with the root and locks the hips in place.
This PR removes the offending code:
https://github.com/godotengine/godot/blob/89f70e98d209563abb4dbc1f8cd5d76c81eb7940/scene/3d/xr_body_modifier_3d.cpp#L255-L258
With this removed the behavior is as follows:

The XRBodyModifier3D is still positioned at the trackers "root" location
The Hips bone is correctly positioned relative to the trackers "root" location

The following video demonstrates four different avatars moving correctly:

An AvaturnMe avatar with no Root bone (bone 0 = Hips)
A Mixamo avatar with no Root bone (bone 0 = Hips)
A ReadyPlayerMe avatar with no Root bone (bone 0 = Hips)
A VRM avatar with bone 0 = Root

https://github.com/godotengine/godot/assets/1863707/9f1d90b8-fccc-4769-8bc1-ee7cad062ae9

At a first glance a hips bone is not a root bone. I’ll try to give a proper answer or someone from the animation can be more detailed.

I assume that adding RootBone would seem to be better than making Hip RootBone. (If necessary, such a feature may need to be added to Retargeter as well)

The purpose of this PR is indeed to prevents the hips from erroneously being driven with "root motion" rules.
My Godot Mocap plugins (VMC, Movella, AxisStudio) do synthesize root motion from the hips - because the mocap data-stream they're consuming doesn't include root motion information. It's just a Vector3.slide to project the hips onto the floor, followed by a double-cross-product to orient the joint facing upwards.
	# Get the hips transform
	var hips : Transform3D = _body_tracker.get_joint_transform(XRBodyTracker.JOINT_HIPS)

	# Construct the root under the hips pointing forwards
	var root_y = Vector3.UP
	var root_z = -hips.basis.x.cross(root_y)
	var root_x = root_y.cross(root_z)
	var root_o := hips.origin.slide(Vector3.UP)
	var root := Transform3D(root_x, root_y, root_z, root_o).orthonormalized()

Thanks!


How to create custom ring renderable such as the selection visualizer one?

Hi,
in our app, we would like to add resizeable selection visualizer according to the size of the current model renderable being selected. I've tried to add FootprintSelectionVisualizer with our custom renderable which size is changed according to the current model and it works fine, but we would like to have the default ring renderable as the visualizer, but I'm just not capable of replicating that renderable, the best I've got is setting the cylinder shaped renderable with zero height, which makes this filled circle shape, but we would like to have the ring with transparent insides. Is there any way how to replicate this renderable? Thank you

If I understood your issue correctly, a ViewRenderable might be a possible solution.
See this discussion: https://github.com/SceneView/sceneform-android/discussions/300#discussioncomment-2087242
Instead of a Rectangle use something like this
<?xml version="1.0" encoding="utf-8"?>
<shape xmlns:android="http://schemas.android.com/apk/res/android"
    android:shape="oval">
    <size android:height="40dp" android:width="40dp"/>
    <stroke
        android:width="1dp"
        android:color="#FFFFFF" />
</shape>

Probably you have to implement your own SelectionVisualizer

More samples with roughness = 1.0

Emission Strength = 0.0

Emission Strength = 1.0

You can also call this
https://github.com/SceneView/sceneform-android/blob/ecaa67a59a999d39ff1def0f24fbdbc009090387/ux/src/main/java/com/google/ar/sceneform/ux/FootprintSelectionVisualizer.java#L34
and use a the glb of your choice.
Feel free to use the cursor.blend from sceneview-android as a starting point for your node selector.
Define the shape you want inside Blender and apply the same material as the linked model. Mostly for the color values which must be applied as diffuse if you don't want to come back here telling that your model seems dark. Using the baseColor your node selector will act as a "real"/"augmented" object. So if you're not using your app on a very sunny environment, the baseColor white will not be a "pure"/"non AR" white as it will be inflenced by the lights. emissiveColor is what you have to use if you want your model to be augmented but with a environment light independent material.

Thank you for your answer, but if I understand correctly there is no way how to change the model renderable size in scene dynamically according to the current model selected, when it's supposed to serve as the selection visualizer. The RGregat's solution seems much more suitable, but the FootprintSelectionVisualizer takes only ModelRenderable as selection visualizer, so I will have to implement my own selection visualizer probably.

It's true that the FootprintSelectionVisualizer node is private so you can't scale it directly.
https://github.com/SceneView/sceneform-android/blob/ecaa67a59a999d39ff1def0f24fbdbc009090387/ux/src/main/java/com/google/ar/sceneform/ux/FootprintSelectionVisualizer.java#L27
But you can also just copy paste this
https://github.com/SceneView/sceneform-android/blob/ecaa67a59a999d39ff1def0f24fbdbc009090387/ux/src/main/java/com/google/ar/sceneform/ux/FootprintSelectionVisualizer.java#L22-L55
And adjust your model scale by modifying the node scale.

#300 (comment)

I've made my custom selection visualizer which sets view renderable as the selected node renderable, but it doesn't work with view renderable, it isn't displayed. But when I change the view renderable to model renderable implementatition, it shows the selection visualizer, so maybe I'm doing something wrong with the view renderable that I'm unaware of?
Here is my custom selection visualizer, which works fine if I replace the view renderable with model renderable
`class CustomSelectionVisualizer(context: Context): SelectionVisualizer {
private val selectionNode = Node()
init {
    ViewRenderable.builder()
        .setView(context, R.drawable.selection_visualizer)
        .build()
        .thenAccept {
            it.isShadowCaster = false
            it.isShadowReceiver = false
            it.collisionShape = null
            selectionNode.renderable = it
        }
}

override fun applySelectionVisual(node: BaseTransformableNode?) {
    selectionNode.parent = node
}

override fun removeSelectionVisual(node: BaseTransformableNode?) {
    selectionNode.parent = null
}

}`
Here is the drawable I use for the view renderable
<?xml version="1.0" encoding="utf-8"?> <shape xmlns:android="http://schemas.android.com/apk/res/android"     android:shape="oval">     <size android:height="250dp" android:width="250dp"/>     <stroke         android:width="10dp"         android:color="@color/black" /> </shape>

Oh ok, I found why it doesn't work, there's error inflating the given view from given source.

setView takes a view res not drawable.

I've managed to set the view to the ViewRenderable, but it displays weirdly as a square view mirroring the background.

I guess it is expected behaviour according to the google docs.
https://developers.google.com/sceneform/develop/create-renderables#create_from_android_widgets
The ViewRenderable should behave as a flat card in the scene displaying some view, so I'm not sure if the selection visualizer would even work with the ViewRenderable as @RGregat suggests, but it seemed like a good solution for my problem since I need to adjust the visualizer renderable size dynamically. Do you have any suggestions for this problem?


Error Running

Python 3.7, Ubuntu 18.04.2
/virtualenvs/atomicdatabase/lib/python3.6/site-packages/imgui/integrations/__init__.py:15: FutureWarning:
    Integration layer in imgui.integrations is still in experimental mode.
    Expect mayor changes in future versions. For safety it is recommended
    to use code vendoring for specific integration impementation.

    This subpackage should become stable in 1.0.0 version.

  """, FutureWarning
Added ReversePredicate pattern.
Added PredicateContraction pattern.
Added Predicate pattern.
Added SimpleQuery pattern.
Added ReverseSimpleQuery pattern.
Added FindEntitySimpleQuery pattern.
Added FindEntitySimpleQueryContraction pattern.
Traceback (most recent call last):
  File "AtomicDatabase/__main__.py", line 257, in <module>
    run()
  File "AtomicDatabase/__main__.py", line 167, in run
    window, gl_context = impl_pysdl2_init()
  File "AtomicDatabase/__main__.py", line 141, in impl_pysdl2_init
    print("Error: Cannot create OpenGL Context! SDL Error: " + SDL_GetError())
TypeError: must be str, not bytes

Oh that's fun. What happened here is we have an error reporting an error... It wasn't able to open an SDL window, but when it tried to show the error it got a bytes type which can't be concatenated onto a string.
You need SDL2.

So probably apt-get install libsdl2-dev

Also check requirements.txt, you might need a few more packages besides the ones in the pip file in the recent merge. (Or I might be thinking of the new runtime branch I didn't finish...) Ill move them over if there are any but before I get to that you'll need to install those manually. more_itertools might be one iirc

Also, test.db.json in the source directory is a useful example database. It contains some stuff referenced in the wiki, too.

Okay it seems that my SDL2 installation is borked. Closing this for now.

Do you know what's wrong with it? I might be able to help figure it out.


Add recipe for sharing common variables and naming between TF modules

This PR solves #858.
Pull Request Template
What are you trying to address
When deploying infrastructure from code, it's common practice to split the code into different modules responsible for the deployment of a part or component of the infrastructure. In Terraform, this can be done by using modules.
In such kind of situation, it is useful to be able to share some common variables as well as centralize naming conventions of the different resources in a central fashion, to ensure it's easy to refactor when it has to change, despite the dependencies that exist between modules.
Description of new changes
This PR adds a recipe with a solution to solve the problem described above.
For all pull requests

[x] Link to the issue you are solving (so it gets closed)
[x] Label the pull request with the appropriate area(s)
[x] Assign potential reviewers (you may also want to contact them on Teams to ensure timely reviews)
[ ] Assign the project - Engineering Playbook Backlog
[x] Assign the pull request to yourself

@omusavi @meulta thanks for the reviews & approvals.
It looks like I am not allowed to merge the PR myself in this repo. Can one of you press the button for me, please? :-)
Thanks !


Doesn't work with Proton

Doesn't seem to work with Proton, Tried on POP OS and verified that at least Seamless Coop seems to work fine. However modengine doesn't seem to. Just wanted to pop in and say it, and if there's anything I can provide or assist with just let me know.

30139.445:0130:0134:err:module:import_dll Library Z:\home\user\.local\share\Steam\steamapps\common\ELDEN RING\Game\modengine2\bin\modengine2.dll (which is needed by L"Z:\\home\\user\\.local\\share\\Steam\\steamapps\\common\\ELDEN RING\\Game\\eldenring.exe") not found
It looks like it's matter of it not being able to find modengine2.dll, I presume because of unescaped back slashes. That was the only error in the steam log.

Workaround: https://github.com/Cloudef/ModEngine2/releases/tag/<IP_ADDRESS>-proton

@Cloudef amazing workaround, thank you so much.
I don't know how big the changes are but have you considered making a push request?


AMQ Streams documentation site is not rendering the styles

SUMMARY
The status of the Document site at https://ansiblemiddleware.com/amq_streams/ is:

Any references to the style resources (js, css, images) are returning 404 (not found) exceptions, so the site is not usable to review the documentation.
ISSUE TYPE

Bug Report

STEPS TO REPRODUCE
Browser the documentation site at https://ansiblemiddleware.com/amq_streams/
EXPECTED RESULTS
Same user experience as the other middleware collection sites.

Fixed by adding .nojekill to gh-pages branch


test: update assertions to pass

Why is this needed?
To unblock merging work into the default branch.
How was this fixed?
By updating the expected bundler version in the assertions
related to the failing tests.

can't argue with a ✅ .

Agreed 👍 :shipit:


Add ability to run integration tests on secure OpenSearch cluster

Need feature of running integ tests on secure OpenSearch cluster or similar environment with enabled security plugin.
k-NN plugin has something similar as part of the CI, but test runs are flaky. That approach is based on docker setup that depends on distribution builds and also hard to troubleshoot in case there are errors.
Alternative approach is discussed here, we can install security plugin and run tests locally without spinning up a docker with min distribution.

Code has been shipped.


Build system expects executable in environment search path - best practice?

Hi,
I have a case where a given build system for a library (qtwebkit) expects both gperf and cmake to be available via environment search path. Vcpkg replaces system and user path, and uses a path with build relevant entries only. I guess that's a well considered careful approach. But how to deal with build systems (I think there must be may) that expect entries in the path? Add what is needed? For gperf it's easy, as it would be downloaded through vcpkg_find_acquire_program, so the path is clear and gperf seems unproblematic, but how about cmake? It could reside in many places. So I think my question are two:

is something like SET(ENV{PATH} "$ENV{PATH};${GPERF_DIR}") okay?
is it problematic to add cmake to the path, and if not, how to best do it to cover all possible install locations. Does vcpkg maybe provide a variable?

Yep! Modifying the ENV macro is the way to do it. If I remember right, openssl does this.
Additionally, since we are using cmake as the scripting language, the cmake executable is always available as ${CMAKE}. That's how vcpkg_configure_cmake works.

Another case, I just bumped into, if you don't mind: qtwebkit runs Qt5's rcc.exe as part of the build. Rcc is found, but it requires zlib.dll to run (and maybe more libs). Would we therefore add installed\<triplet>\bin to the path of the build-shell (like the gperf-case above)?

Exactly right again :). GRPC does this:
# gRPC runs built executables during the build, so they need access to the installed DLLs.
set(ENV{PATH} "$ENV{PATH};${CURRENT_INSTALLED_DIR}/bin;${CURRENT_INSTALLED_DIR}/debug/bin")

https://github.com/Microsoft/vcpkg/blob/93d46a9a612d2c09b3861532ed427a197da887be/ports/grpc/portfile.cmake#L52

Thumbs also for thinking through adding the bin-path by default. I guess the earlier it is done, the more efficiently real world problems will help to tell if it's a good thing or not. It is easy to imagine many cases where adding the bin folder to the path would be useful. E.g. in tests.


Order of scenarios plotted are inconsistent

Scenario visualizations order scenario groupings based on variance.
This causes an artifact where plots do not maintain consistent ordering. It should always be "counterfactual", "unguided", "guided".
https://github.com/open-AIMS/ADRIA.jl/blob/437d51a030bd58f0d794dd46d03056a70f8fa09c/ext/AvizExt/viz/scenarios.jl#L221

@ConnectedSystems the idea behind that was that, if a plot has a big variance and it's on top of another with low variance, it will cover it and it will be hard to "read" the plot.
Before I change this, just wanted to confirm that we want to keep a fixed/consistent order instead of adjusting based on variance.

The functionality should be split.
When comparing sets of runs, you'd want the order to be consistent between figures, especially for reports and the like.
For scenario clustering I agree you want things to be reordered based on scenario cluster properties.


Fix internal routing consistency for client nav

Now you can click around and all buttons should work as expected within project/quote/invoice/expense stuff.  Does not cover jobs (email).
All the tests will fail, //TODO

Wow, tests actually passed...


customize typescript path

Current behavior

Before 5.0.0 version, typescript support customize path resolve, like { typescript: require.resolve(path) }, but after 5.0.0 version, i don't set this
In my project, typescript is optional, so I don't want to install ts when create
Expected behavior

Steps to reproduce the issue

Issue reproduction repository

Environment

fork-ts-checker-webpack-plugin: [5.0.1]
typescript: [version from the package.json]
eslint: [version from the package.json]
webpack: [4.43.0]
os: [e.g. Ubuntu 19.04]

You can use typescript: { enabled: false } to disable typescript support. Is it something that solves your issue?

No, I want to set a special ts path to resolve

Then it's not possible to do starting from 5.0.0. It was removed to simplify the codebase and therefore make it easier to maintain.
I don't understand the reason why you would like to set a custom path of the typescript. Could you elaborate a little bit more about your use-case? Maybe I could help you or you could convince me to add support for this feature in version 5 :)

Example project
├── toolChain(Build tool)
│   ├── node_modules
│   ├── bin
├── project
│   ├── node_modules
│   ├── ├──typescript
│   ├── ├──toolChain (symbol link)

when I run webpack dev, has error Error: Cannot find module 'typescript'

Sorry, but we don't have a plan to support this setup in next versions :) I think that this plugin should not fix issues with node_modules resolution

It's ok, thanks for your quick replay


BlendshapeRecorder out of sync with RecordMotion Clip

And there is some “curves problem”.
If one blendshape change to 100 the change to 0 before 1 second, the curves should like that:

but curves become that:

#25 fix_issue_17 (facial recording problem)
Resolved by this pull request.
Thanks!


Permissions bug when contenttypes are in both TENANT_APPS and SHARED_APPS

I think this is a big bug in django tenants.
I moved my auth and auth user model to the SHARED_APPS and my permissions stopped working. The permissions are applied to groups and then users are applied to the group they belong in.
This is my settings.py:
SHARED_APPS = [
    'django_tenants',

    'django.contrib.contenttypes',
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',

    'apps.companies',
    'apps.employees',
    'crispy_forms',
]

TENANT_APPS = [
    'django.contrib.contenttypes',

    'apps.categories',
    'apps.invite',
    'apps.memos',
    'apps.notifications',
    'apps.report_bug',
    'apps.videos',
    'apps.phone_verify',
    'apps.quiz',

    'django_cleanup',
]

It seems my whole permissions system is broken. To give an example.. in my admin panel when looking at the permissions in the admin panel you see:
admin | log entry | can add User Progress
auth | group | can add True/False Question
contenttypes | contenttype | Can view email message

This makes no sense. It is like my permissions are not lining up with their category..
Thoughts on what can be done to fix this?

This is a bug that is actually recommended in the documentation. I don't understand why but it says to put contenttypes in the TENANT_APPS. Problem is it mixes up the permissions when you do this. Some are missing and some are gone. How to fix this? Remove contenttypes from TENANT_APPS

Did you tested it on clear DB? If not, then removing any app from TENANT_APPS do not remove tables from schemas.  So you really can mess your DB this way.
This recommendation is not a bug, I use it in production environment for 6 years already.

Did you tested it on clear DB? If not, then removing any app from TENANT_APPS do not remove tables from schemas. So you really can mess your DB this way.

Yes, on two different projects on several new databases I am able to duplicate this bug.

This recommendation is not a bug, I use it in production environment for 6 years already.

The result of the recommendation happens to be a bug.

How to fix it? Revert tenant migrations of apps you want to remove before removing them, use zero:
https://docs.djangoproject.com/en/3.0/topics/migrations/#reverting-migrations

I tried removing all migrations and starting fresh with new databases every time I changed a setting. These are fresh databases and fresh migrations.

I'm seeing similar behavior suddenly (permissions "jumbled"). Been in production for a year with one tenant, everything fine, with contenttypes in both SHARED_APPS and TENANT_APPS
Last week in preparation for adding 3 new tenants, upgraded django-tenants from 3.4.1 to 3.5.0 and from psycopg2 to psycopg3... so when I saw the jumbled permissions in the new tenants I first assumed the upgrade was responsible, but behavior persists even rolling back to previous versions
Haven't removed any apps.
When creating new tenants, the permissions for the new tenants is jumbled. And the count of the permission names is incorrect, so not merely shuffling between them.
Have a Settings model in each of 8 project apps. In the older app, the permissions are correct (and there are 8 of them for each of the default actions):
<Permission: common | settings | Can view settings>
<Permission: financial | settings | Can view settings>
<Permission: landing | settings | Can view settings>
<Permission: masterdata | settings | Can view settings>
<Permission: production | settings | Can view settings>
<Permission: purchasing | settings | Can view settings>
<Permission: tenants | settings | Can view settings>
<Permission: users | settings | Can view settings>]>

For new tenants, only 5 permissions are created, and the app_model listed for two of them are incorrect :
<Permission: financial | settings | Can view settings>
<Permission: masterdata | equipment cost | Can view settings>
<Permission: masterdata | item price | Can view settings>
<Permission: tenants | settings | Can view settings>
<Permission: users | settings | Can view settings>]>

And the exact same 5 results above occur across may 20 tenant creations, both with 3.4.1 and 3.5.0


Merge Pull

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

35 of 35 (100.0%)  changed or added relevant lines in 2 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.02%) to 97.81%

Files with Coverage Reduction
New Missed Lines
%

storages/sled-storage/src/index.rs
1
93.51%

Totals

Change from base Build<PHONE_NUMBER>:
0.02%

Covered Lines:
28808

Relevant Lines:
29453

💛  - Coveralls


Track events for Actionsheet for transaction confirmation

Ref: https://github.com/AlphaWallet/alpha-wallet-ios/pull/2282
Logged as this on iOS:
enum Navigation: String, AnalyticsNavigation {
    case actionSheetForTransactionConfirmation = "Screen: Txn Confirmation" //actionsheet appears
}

enum Action: String, AnalyticsAction {
    case confirmsTransactionInActionSheet = "Txn Confirmation Confirm Tapped" //tapped the button, doesn't imply success
    case cancelsTransactionInActionSheet = "Txn Confirmation Cancelled"
}

Bump


STOR-1317,STOR-1318: Refactor for transition from TP to GA

This is a partial revert of changes that were made to build the TP bundles. Also changes the IAM role request to conform to the upstream manifests.

To testy the changes I built the bundle in my quay repo. It should be testable using this CatalogSource:
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: gcp-filestore
  namespace: openshift-marketplace
spec:
  sourceType: grpc
  image: quay.io/tsmetanarh/gcp-filestore-csi-driver-index

Basic smoke tests look to be OK so far.

/retest

CI complains:

message: 'constraints not satisfiable: no operators found in channel preview of
package gcp-filestore-csi-driver-operator in the catalog referenced by subscription
oo-xq4gg, subscription oo-xq4gg exists'

Do you want to fix it before this PR is merged?
https://github.com/openshift/release/blob/967c060f5ac20b4826311d432f52094ddf2ee764/ci-operator/config/openshift/gcp-filestore-csi-driver-operator/openshift-gcp-filestore-csi-driver-operator-main.yaml#L121
(+ 4.14 / 4.15 files)

e2e succeeded \o/
/lgtm

/retest

/label qe-approved

/lgtm cancel
just testing github approvals


gnuradio: [<IP_ADDRESS>->3.7.11] [Enable Darwin support]

Motivation for this change
GNU Radio only required a few small tweaks to enable compilation on Darwin. Updated to 3.7.11 which is compatible with 3.10.1 and includes bugfixes.

UHD builds on Darwin with no changes, links and works
qwt6_qt4 was already Darwin enabled, but was missing AGL

Things done

[ ] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[ ] NixOS
[x] macOS (using nix-shell --pure)
[ ] Linux

[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

This is my first pull request so I apologize if it is preferred to submit a separate pull per package.
There are child gnuradio packages which are still linux-only (small changes for darwin support), but I wanted to improve the PYTHONPATH situation before submitting them.
This package produces python outputs, so I propose changing this to a wrapper package which would depend on gnuradio-core and gnuradio-python. gnuradio-python would create a python package using buildPythonPackage.
I had to use DYLD_FRAMEWORK_PATH due to Python27 linking to a pure CoreFoundation, causing QWT/QT to segfault.

Attached is the output log of nox-review:
gnuradio_qwt6-qt4_uhd_darwin_buildoutput.txt

I ran nix-collect-garbage -d, and now running nix-build '<nixpkgs>' -p gnuradio -v 4 --pure --cores 8 --no-out-link
results in this

scanning for references inside ‘/nix/store/q343nsw48n3abjyx80c8z5gkm74kj048-gnuradio-3.7.11’
building path(s) ‘/nix/store/06vnp56jbw8w97c24997kmk5mic9xlm7-shell’
build input 4 does not exist
builder for ‘/nix/store/7cmldwrfp0i6lcbl8zjknvvfasvjap9j-shell.drv’ failed with exit code 1
error: build of ‘/nix/store/7cmldwrfp0i6lcbl8zjknvvfasvjap9j-shell.drv’ failed`

You should use nix-build '<nixpkgs>' -A gnuradio -p only makes sense for nix-shell, same for --pure but I think that's just ignored. You can also force a rebuild by adding --check without having to run a garbage collect first.

I'm just wondering what the build input 4 does not exist line means. It originates from nixpkgs/pkgs/stdenv/generic/setup.sh and causes the build to fail (which didn't happen before).

I'm getting some test failures https://gist.github.com/LnL7/34bc91c98e28cafdc40e09013bc39e45

@LnL7 Test 166 seems to be one of a handful which intermittently fail due to generating (and capturing) large amounts of data. I can compile a list of these as we may want to disable them to prevent spurious failures.
Regarding 196, that is what the install_name_tool line in the postBuild is for, as CMake isn't properly linking the qwt libs on Darwin (placing a relative path instead of a full path to the nix store library file). I'm not sure if you still have the log from it laying around, but I've had it fail due to a segfault as a result of python2 and qwt4, where qwt4 uses an impure CoreFoundation framework. (which was fixed by DYLD_FRAMEWORK_PATH)
sorry about the wall of text. I will have time to investigate the issue more this weekend.
notes:

it may be beneficial to resolve the qwt linking errors with a patch. gnuradio-3.8 is in the works (introduces many breaking changes), I can check if they fixed it
is there a way to wrap the binaries with a specific python interpreter, but using build-output python libraries? (to avoid use of PYTHONPATH)

Apparently the qwt framework name was a relative path. Using install_name_tool -id to repair the Darwin qwt framework (in the qwt* packages) seems to fix the linking issue, removing the need for install_name_tool -change in the gnuradio builder! I'll be pushing the fixes to my branch soonish, and they should permanently resolve the 196 test failure.
unrelated to above:
since I couldn't really tell from the contributing docs, would you prefer if I pushed all of these little changes as their own commits, or should I rebase them before pushing to my branch? I been rebasing before pushing previously, but can see how that may make it more difficult for reviewers to tell that I made a change...

I'm going to close this until i have a chance to polish it.  (next week)
Still needs to be done for this version:

Possibly bump to 3.7.11->3.7.12
Fix PYTHONPATH issues: using makeWrapper breaks .py imports on examples, etc. Need to use pythonEnv
Add dynamic PYTHONPATH/GRC_BLOCKS_PATH so gnuradio-* extensions can be used via nix-shell -p gnuradio-* without needing gnuradio-wrapper to bundle all of it together

Since GR-3.8 is coming soon with some breaking changes, I may be able to work on that too. Of note

Use of qwt6 with qt5
Python 3
Possible changes to plugins

@LnL7 : I noticed you merged 3.7.11, which is awesome!
Regarding PythonPath, is it acceptable to make gnuradio-* act like pythonpackages?
Essentially, "plugins" would be used by calling nix-shell -p gnuradio -p gnuradio-osmosdr for example (which would dynamically set GRC_BLOCKS_PATH and PYTHONPATH). I have this functionality working on my local copy but wanted to get your thoughts.
This method prevents the need for any interpreter patching and eliminates potential user profile conflicts (e.g. GNUr-enabled python 2 being linked in the user profile), and also makes all gnuradio executables and example scripts "just work" when used within the shell.

Something like nix-shell -p gnuradio -p gnuradio-osmosdr can only work with a setupHook. That wouldn't be run when installing these individual items in a profile. For that, you would need to perform a composition in some other way.


Support Pricing Tier

This checklist is used to make sure that common guidelines for a pull request are followed.

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your PR is merged into master branch, a new PR will be created to update src/index.json automatically.
The precondition is to put your code inside this repo and upgrade the version in the PR but do not modify src/index.json.

spring-cloud

You may need add test cases since you add new commands


Add method to check if the folder is a JHipster Lite project

Can you do a quick review plz @Bolo89 ?


L1->L2 messaging

Closes #1525
Ended up going for a separate mempool to avoid managing the sequencer's nonce outside of the builder.

Just realized there are some ways this can be simplified. Will re-open when it's ready :sweat_smile:


Fix tests always passing

Description
@tdawe noticed that tests were always being reported as passing as long as they met the coverage thershold, even if the tests themselves were failing. This PR fixes that.
Issues
List the issues impacted by this PR:
None
Checklist:

[X] I have performed a self-review of my own code
[X] I have commented my code, particularly in hard-to-understand areas
[X] I have made corresponding changes to the documentation
[X] I have added tests that prove my fix is effective or that my feature works

How Has This Been Tested?
Pointed a failing branch of csi-powerflex to this branch and verified that it fails correctly

@tdawe do you want to try this branch against your test case and see if it works there as well?

closing for now because I need to fix a formatting issue

Re-opening -- formatting issues fixed, tested on Trevor's test PR: https://github.com/dell/karavi-metrics-powerflex/runs/4941805531?check_suite_focus=true


[SPARK-39760][PYTHON] Support Varchar in PySpark

What changes were proposed in this pull request?
Support Varchar in PySpark
Why are the changes needed?
function parity
Does this PR introduce any user-facing change?
yes, new datatype supported
How was this patch tested?
1, added UT;
2, manually check against the scala side:

In [1]: from pyspark.sql.types import *
   ...: from pyspark.sql.functions import *
   ...:
   ...: df = spark.createDataFrame([(1,), (11,)], ["value"])
   ...: ret = df.select(col("value").cast(VarcharType(10))).collect()
   ...:
22/07/13 17:17:07 WARN CharVarcharUtils: The Spark cast operator does not support char/varchar type and simply treats them as string type. Please use string type directly to avoid confusion. Otherwise, you can set spark.sql.legacy.charVarcharAsString to true, so that Spark treat them as string type as same as Spark 3.0 and earlier

In [2]:

In [2]: schema = StructType([StructField("a", IntegerType(), True), (StructField("v", VarcharType(10), True))])
   ...: description = "this a table created via Catalog.createTable()"
   ...: table = spark.catalog.createTable("tab3_via_catalog", schema=schema, description=description)
   ...: table.schema
   ...:
Out[2]: StructType([StructField('a', IntegerType(), True), StructField('v', StringType(), True)])

scala> import org.apache.spark.sql.types._
import org.apache.spark.sql.types._

scala> import org.apache.spark.sql.functions._
import org.apache.spark.sql.functions._

scala> val df = spark.range(0, 10).selectExpr(" id AS value")
df: org.apache.spark.sql.DataFrame = [value: bigint]

scala> val ret = df.select(col("value").cast(VarcharType(10))).collect()
22/07/13 17:28:56 WARN CharVarcharUtils: The Spark cast operator does not support char/varchar type and simply treats them as string type. Please use string type directly to avoid confusion. Otherwise, you can set spark.sql.legacy.charVarcharAsString to true, so that Spark treat them as string type as same as Spark 3.0 and earlier
ret: Array[org.apache.spark.sql.Row] = Array([0], [1], [2], [3], [4], [5], [6], [7], [8], [9])

scala>

scala> val schema = StructType(StructField("a", IntegerType, true) :: (StructField("v", VarcharType(10), true) :: Nil))
schema: org.apache.spark.sql.types.StructType = StructType(StructField(a,IntegerType,true),StructField(v,VarcharType(10),true))

scala> val description = "this a table created via Catalog.createTable()"
description: String = this a table created via Catalog.createTable()

scala> val table = spark.catalog.createTable("tab3_via_catalog", source="json", schema=schema, description=description, options=Map.empty[String, String])
table: org.apache.spark.sql.DataFrame = [a: int, v: string]

scala> table.schema
res0: org.apache.spark.sql.types.StructType = StructType(StructField(a,IntegerType,true),StructField(v,StringType,true))

gentle ping @HyukjinKwon @cloud-fan

LGTM! Thanks!

Merged to master, thank you all!
@HyukjinKwon I will send followup PR for arrow/py4j/udf, thanks for pointing out it!

late LGTM, do we want to support CharType in pyspark?

@cloud-fan  I think so, let me add it in near future.
@HyukjinKwon Btw, I guess we may not need to add extra support for pyarrow or py4j+python UDF, because it seems that there is not a class for char/varchar instances in scala or python (pandas/numpy/built-in), and they are treated as string internally.
There is also a warning message if we want to cast to char/varchar, in CharVarcharUtils
The Spark cast operator does not support char/varchar type and simply treats them as string type. Please use string type directly to avoid confusion.


Check if charset is defined

Check if charset is defined in http section, currently when choosed charset to "none", the code add charset option without value, and nginx service fail.
According http://nginx.org/en/docs/http/ngx_http_charset_module.html

@fichtner It's ok, will create a release note for it after merge. It's good to see that there are some contributors on this plugin as well.


AWS AMI: ami-0312c8ef72c898c8 in us-west-2 fails to boot

When running an AMI from us-west-2 using Flatcar-stable-2605.7.0 AMI (ID: ami-0312c8ef72c898c8e) the instance never boots. I've attached a screenshot of the host in AWS for the error.

The error is Wrong EFI loader signature
Impact
Can't deploy instances with this AMI
Environment and steps to reproduce

Find the AMI in the UI
Launch an instance with all the default settings, using your own SSH keypair
Download a screenshot of the failed instance

Expected behavior
Ability to deploy instances

Please try again with release 2661.0.0 or newer.

(also, thanks for reporting the issue :smile_cat: )

Using Flatcar-alpha-2661.0.0-hvm<PHONE_NUMBER>25/Flatcar-alpha-2661.0.0-hvm & ID: ami-0c7fa97342e18ae64) in us-east-1 I get the same error: see screenshot -- I'm using a t3.large in my scenario. Any clues as to why this might happen?

Ok - super interesting but it seems like it's some weirdness either with my config or with Amazon. I was able to book a server with no userdata, but I still saw the Wrong EFI loader signature message, it just boots past that in a few seconds. Not clear why this is inconsistent but likely something on my end. I'll keep digging into it.

Going to close this and reopen until I can reliably reproduce.

Found the problem - issue was definitely on my side and was two fold. One was that a new ignition policy did allow access to an s3 object, which appears to then just rerun ignition over and over (causing what appears to be a hung system). My initial issue is that this Wrong EFI loader signature is a red herring. It doesn't actually indicate a problem at all, and thus when I was testing without any ignition settings, I was not waiting long enough to get past this portion of the boot. Sorry for the trouble and thanks again!

@endzyme nice find. Glad you found the culprit!


Update look and feel

Changed images and font.

Oops, meant to merge this into a forked repository. Disregard


reverse iterator

i don't love this code
for i in (1..10).rev(){
println!("{}",i);
}
why we can't use this code
for i in 10..1{
println!("{}",i);
}

If we think about this mathematically..
The range 10..1 can be seen as the set formed by: { x | is_integer(x) && 10 <= x < 1 }.
This holds for exactly zero integers, wherefore the set is empty.
It is important to not have surprising and different semantics than to mathematics.
I think that the hassle of .rev() is not too large and well worth this consistency.


add a status section to SIPs

Add a field to the top of a SIP that indicates the status of this SIP.
Status: Implemented or Status: Not Implemented Yet or Status: In Progress
This will help us understand the state of the implementation side of the proposal. The person implementing should update the status field of the SIP in the PR that completes the implementation for the SIP.

Do intend to allow revisions after status Completed is achieved? If so, maybe we could add a revisions table, too. This could help provide context to the Updated At field too.
| Revision | Summary of Changes |
| -- | -- |
| 1 | Initial Version |


address warning for unused TimedResource in t-w-r declarations

[WARNING] /home/runner/work/emissary/emissary/src/main/java/emissary/core/MobileAgent.java:[343,28] auto-closeable resource timer is never referenced in body of corresponding try statement
[WARNING] /home/runner/work/emissary/emissary/src/main/java/emissary/place/CoordinationPlace.java:[201,32] auto-closeable resource tr is never referenced in body of corresponding try statement
[WARNING] /home/runner/work/emissary/emissary/src/main/java/emissary/core/HDMobileAgent.java:[409,28] auto-closeable resource tr is never referenced in body of corresponding try statement

The proposed solution is a bit of a step-back since it does not take advantage of the language feature for AutoCloseable resources. This scenario lives in an edge case where the language doesn't expect a usage where the declared resource is never used in the try block. IntelliJ actually has a nod to this and using a variable name of ignored silences the IDE warning. That doesn't work for maven and adding the -try lint flag is much too large in scope.
A different solution would be to add @SuppressWarnings("unused") on the method, but that's still a bit heavier in scope than I would like. The code could be refactored to minimize the impact of such an annotation if that is preferred though.

An alternative approach which seems to also suppress the warning is to use an assertion within the t-w-r body:
assert tr != null; // silence "auto-closeable resource tr is never referenced in body"

An alternative approach which seems to also suppress the warning is to use an assertion within the t-w-r body:
assert tr != null; // silence "auto-closeable resource tr is never referenced in body"

I like this idea better. Thank you.


Incompatible with the Easy Magic mod

Seems there is an incompatibility with the Easy magic mod
When said mod is installed, the eterna, quanta and arcana is not showing up inside the enchanting table.
This is on 1.21.1 neoforge

They are incompatible by nature because they are both overriding the vanilla enchanting table. Choose one enchanting mod over the other.

I did
I choose You!!!


edvr in mmediting can't match edvrm_x4_8x4_600k_reds checkpoint?

edvr in mmediting can't match edvrm_x4_8x4_600k_reds checkpoint?

Please post the full command line, and the full error with stacktraces.

for company confidentiality mechanism, I'm not convenient to take a screenshot.
./tools/dist_test.sh configs/restorers/edvr/edvr_reds.py mmediting_pth/edvrm_x4_8x4_600k_reds_20200622-ba4a43e4.pth 4 --save-path ./result  --out test.pkl
problem
missing keys in source state_dict: generator.conv_first.weight ...........................................

basicvsr can match the checkpoint well

@Yshuo-Li Please check if the edvr code was touched recently

@xiab3369 The filename edvr_reds.py is not present in our repo. Please post the modification. For stacktraces, you can remove the private info such as usernames and file paths, and keep other info

we just change the name of the file, not change edvr_net in backbone and config file content

Can you share the full command line that accurately inference edvr network with edvrm_x4_8x4_600k_reds_20200622-ba4a43e4.pth

basicVSR also exist the same problem

The checkpoint contains 'module', we remove 'module' in pth file and successfully resolve the issue.

Which version of mmcv is used? The "module" should be stripped by mmcv automatically.

mmcv-full 1.3.7

It is automatically installed by mmediting on torch1.4

I just tried on my side. edvrm_wotsa_x4_g8_600k_reds indeed has the problem about .module.
But edvrm_wotsa_x4_8x4_600k_reds and basicvsr_reds4 do not have the issue.

@ckkelvinchan Is this caused by the publish code?

We may add tests for published checkpoints 🤔

@ckkelvinchan Is this caused by the publish code?

I think no. EDVR is uploaded long time ago, and the error we encountered before is a different issue. Actually it is strange that edvrm_wotsa_x4_8x4_600k_reds has no problem, as these two checkpoints should be uploaded at about the same time.
Anyway I will fix this first.

We may add tests for published checkpoints 🤔

Could we load weights from http in unittest? If yes I think it could be done.

Thank you for help and effort. The basicvsr also exist the problem.  ‘’“missing keys in source state_dict: step_counter”. I am not sure whether it will cause negative impact on the network.

Thank you for help and effort. The basicvsr also exist the problem. ‘’“missing keys in source state_dict: step_counter”. I am not sure whether it will cause negative impact on the network.

step_counter is added later (after the model has been trained) to count training step. This does not affect the performance.

Yes we need sort out cache in github actions. I will try cache in https://github.com/open-mmlab/mmocr/pull/327


Improve load time of children endpoint

Describe the Bug
https://cms.integreat-app.de/augsburg/en/wp-json/extensions/v3/children/?depth=1
needs more than 2 seconds to load
Steps to Reproduce
request https://cms.integreat-app.de/augsburg/en/wp-json/extensions/v3/children/?depth=1
with postman or with the browser
Expected Behavior
should need less than 500ms
Actual Behavior
needs 3s

@SteffiStuffel Do you have other ideas for optimizations? Otherwise, I would just open a PR with this change, should be a pretty significant improvement already.

@SteffiStuffel Do you have other ideas for optimizations? Otherwise, I would just open a PR with this change, should be a pretty significant improvement already.

Thanks for taking care of this. I would have checked the insights, why this request needs a lot of time and fix it depending on the result. So fine for me how you suggested.


version 1.2.1

Improved test coverage
Small fixes and correct type declaration for AnyDate

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

Project coverage is 99.85%. Comparing base (5774d3c) to head (3e8854a).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main       #5      +/-   ##
==========================================
+ Coverage   97.49%   99.85%   +2.36%
==========================================
  Files          10       10
  Lines         678      683       +5
  Branches      191      204      +13
==========================================
+ Hits          661      682      +21
+ Misses         17        1      -16

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


[DNM]Touch to create PR and test CI

What problem does this PR solve?
What is changed and how it works?
Check List
Tests

Unit test
Integration test
Manual test (add detailed scripts or steps below)
No code

Code changes

Has exported function/method change
Has exported variable/fields change
Has interface methods change
Has persistent data change

Side effects

Possible performance regression
Increased code complexity
Breaking backward compatibility

Related changes

Need to cherry-pick to the release branch
Need to update the documentation
Need to update the tidb-ansible repository
Need to be included in the release note

/run-all-tests tikv=v5.0.3 tidb=v5.0.3 pd=v5.0.3

/run-all-tests tikv=v5.0.3 tidb=v5.0.3 pd=v5.0.3

/run-all-tests tikv=v5.0.3 tidb=v5.0.3 pd=v5.0.3

/run-all-tests tikv=v5.1.0 tidb=v5.1.0 pd=v5.1.0

/run-all-tests

/run-integration-test tikv=v5.1.1 tidb=v5.1.1 pd=v5.1.1 test-flash=true

/run-integration-test tikv=v5.1.1 tidb=v5.1.1 pd=v5.1.1 test-flash=true

/run-all-tests tikv=v4.0.14 tidb=v4.0.14 pd=v4.0.14 tiflash=v4.0.14

/run-all-tests tikv=v4.0.16 tidb=v4.0.16 pd=vv4.0.16

/run-all-tests tikv=v5.1.0 tidb=v5.1.0 pd=v5.1.0

/run-all-tests tikv=v4.0.16 tidb=v4.0.16 pd=v4.0.16

/run-all-tests tikv=release-4.0-20211029 tidb=release-4.0-20211029 pd=release-4.0-20211029

/run-all-tests tikv=release-4.0 tidb=release-4.0 pd=release-4.0


Add pulse and finance tutorials

Summary
Adds the working pulse and (some) finance tutorials.
Details and comments

Verified docs look good.


chore(master): release 0.30.0

:robot: I have created a release beep boop
0.30.0 (2024-06-20)
Features

remove authz token (f6f5ef6)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v0.30.0
:sunflower:


.md or .rst

for the docs in this repo, it would be good to choose either .md or .rst and be consistent.
My vote is for .md as these docs are quite simple and markdown is more widely used than .rst, and we can copy from GH issues, etc that have markdown styling.

vote with 👍  for .md
vote with 👎 for .rst

I am going to suggest we use .md to have things nicely rendered on github. if there are no objections by the end of the week, I will assume folks are okay with this :)

I say you phrased that survey very biased by giving one a :+1: and one a :-1:  ... ;-)

there is only a small choice of emojis here ;-)

I am fine with either. But I do think that with .md you sometimes reach the limits soon...
However, if it is without any sphinx then it might actually be more than enough.

Yeah, I don't have strong opinions either way, but I think this repo should stay pretty simple in terms of what we need/want to include. The website-building should be confined to the individual repositories docs + the simpeg website itself

I just changed form :-1:  to :+1: - given your explanation that it is only for here, the community repo.

Thanks @prisae! Since only you and I seem to have opinions on this, I will call that consensus :)


Add Overloads to the symbols signature so it is publicly visible

This should of been visible in the original commit but was missed unfortunatly.
This also adds the matchParameter number argument so either all
overloads, or overloads matching the current symbols parameter count
can be returned.

Hey Dave, could you add some tests, and some documentation to the tutorials under docs?  We need to always be doing both for all new API sureface area

I can this one is pretty low priority for me at the moment, although it seems to complete a missing part of the API in my opinion anyway :-)


fixed URL for Use a custom log parser

https://docs.microsoft.comcommit/cloud-app-security/custom-log-parser => https://docs.microsoft.com/cloud-app-security/custom-log-parser

@ErikMoreau : Thanks for your contribution! The author, @curtand, has been notified to review your proposed change.

#sign-off


⚠ Bofrost.lu has degraded performance

In fe34e82, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1284 ms

Resolved: Bofrost.lu performance has improved in 9fa357a after 6 minutes.


Adding open_datatree backend-specific keyword arguments

[x] Closes ##9135
[ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
[ ] New functions/methods are listed in api.rst

you might want to rebase / cherry-pick the two commits for this PR onto main, so there's only those two commits to check in this PR. If you don't have any idea how to do that, I can do it for you.

so unfortunately I can't push to your repository, because it is a fork of someone else's fork (and I'm not a maintainer on that fork). To fix that, you can either request someone from github to "reroute" your fork, or you can pull all your branches to local (I'm sure you did already), delete the repository and fork again. I'm not sure what would happen to this PR, though.

if you want to finish up this PR, you can also follow the steps yourself. Basically, what you do is:
git switch main
git pull
git switch open-dtree-kwargs
# rewind to main
git reset --hard HEAD~60
git merge main
# apply the two commits that were added in this PR
git cherry-pick 179b6960c6e2f49b38eda13a97d977a72bcb5990
git cherry-pick 563b5dbda4dabd253c38c9ca577015224447314f
git push --force

Do we need tests for this?

Funny you should ask - it turns out this functionality wasn't tested to begin with, so @eni-awowale and I are actually working on implementing some (started at SciPy sprints and not yet opened as a draft PR, but located here). Thanks to @santisoler for his help getting that effort started during Sprints!

@JessicaS11 it would be great if you could push whatever you have as a PR (don't worry about perfecting it!) just so that those tests don't get lost in the ether


[marisa] Add new port

Describe the pull request

What does your PR fix?
Fixes
#20446
#4289
#26179
https://github.com/s-yata/marisa-trie

Which triplets are supported/not supported? Have you updated the CI baseline?
<all / linux, windows, ...>, <Yes/No>

Does your PR follow the maintainer guide?

I am still working on this PR

If you are still working on the PR, open it as a Draft: https://github.blog/2019-02-14-introducing-draft-pull-requests/

I know this PR is in draft state, so this is just early feedback.

I fixed almost all the comments. I will draft the pr and try to fix the build on windows.

I know this PR is in draft state, so this is just early feedback.

All done.

@JonLiu1993  Here is the minimized project to test the build. I had tested it locally.
https://github.com/day253/vcpkg-mini-project

@JonLiu1993 Here is the minimized project to test the build. I had tested it locally.
https://github.com/day253/vcpkg-mini-project

Thanks for your contribution.

The msbuild doesn't install pkgconfig files. So for uniform usage, they would need to be created from the portfile based on configure_file("${SOURCE_PATH}" ...).

Okay.

I guess we need  "supports": "!windows, mingw, windows & (x86 | x64) & staticcrt". (mingw and arm still untested.)

need

I will test the list.

This is ci error log:
CMake Error at scripts/cmake/vcpkg_check_linkage.cmake:25 (message):
  Refusing to build unexpected dynamic library against the static CRT.

      If this is desired, please configure your triplet to directly request this configuration.
Call Stack (most recent call first):
  ports/marisa-trie/portfile.cmake:2 (vcpkg_check_linkage)
  scripts/ports.cmake:147 (include)

~I guess we need "supports": "!windows, mingw, windows & (x86 | x64) & staticcrt". (mingw and arm still untested.)~
I lost a ! before staticcrt. (It was there in a previous comment.) Fixed:
"supports": "!windows, mingw, windows & (x86 | x64) & !staticcrt"

Very thanks.

The msbuild doesn't install pkgconfig files. So for uniform usage, they would need to be created from the portfile based on configure_file("${SOURCE_PATH}" ...).

Should I set the addtional prefix like this?
# Create pkgconfig file
set(PACKAGE_VERSION ${VERSION})
set(prefix "${CURRENT_INSTALLED_DIR}")
set(exec_prefix "\${prefix}")
set(libdir "\${prefix}/lib")
set(toolexeclibdir "\${libdir}")
set(includedir "\${prefix}/include")
configure_file("${SOURCE_PATH}/marisa.pc.in" "${CURRENT_PACKAGES_DIR}/lib/pkgconfig/marisa.pc" @ONLY)

# debug
if (NOT VCPKG_BUILD_TYPE OR VCPKG_BUILD_TYPE STREQUAL "debug")
  set(prefix "${CURRENT_INSTALLED_DIR}/debug")
  set(exec_prefix "\${prefix}")
  set(libdir "\${prefix}/lib")
  set(toolexeclibdir "\${libdir}")
  set(includedir "\${prefix}/../include")
    configure_file("${SOURCE_PATH}/marisa.pc.in" "${CURRENT_PACKAGES_DIR}/debug/lib/pkgconfig/marisa.pc" @ONLY)
endif()

The msbuild doesn't install pkgconfig files. So for uniform usage, they would need to be created from the portfile based on configure_file("${SOURCE_PATH}" ...).

I tested this on my windows. I think it's okay now.

@dg0yt , I follow your advice build the test project get the error, @day253 , please take a look:
1> CMake generation started for configuration: 'x64-Debug'.
1> Found and using vcpkg toolchain file (F:/Feature-test/marisa-trie/vcpkg/scripts/buildsystems/vcpkg.cmake).
1> Command line: "C:\WINDOWS\system32\cmd.exe" /c "%SYSTEMROOT%\System32\chcp.com 65001 >NUL && "C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\ENTERPRISE\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe"  -G "Ninja"  -DCMAKE_BUILD_TYPE:STRING="Debug" -DCMAKE_INSTALL_PREFIX:PATH="C:\Users\source\repos\CMakeProject45\out\install\x64-Debug" -DCMAKE_C_COMPILER:FILEPATH="C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe" -DCMAKE_CXX_COMPILER:FILEPATH="C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe"  -DCMAKE_MAKE_PROGRAM="C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\ENTERPRISE\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\Ninja\ninja.exe" -DCMAKE_TOOLCHAIN_FILE="F:/Feature-test/marisa-trie/vcpkg/scripts/buildsystems/vcpkg.cmake" "C:\Users\source\repos\CMakeProject45" 2>&1"
1> Working directory: C:\Users\source\repos\CMakeProject45\out\build\x64-Debug
1> [CMake] -- The C compiler identification is MSVC 19.29.30146.0
1> [CMake] -- The CXX compiler identification is MSVC 19.29.30146.0
1> [CMake] -- Detecting C compiler ABI info
1> [CMake] -- Detecting C compiler ABI info - done
1> [CMake] -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe - skipped
1> [CMake] -- Detecting C compile features
1> [CMake] -- Detecting C compile features - done
1> [CMake] -- Detecting CXX compiler ABI info
1> [CMake] -- Detecting CXX compiler ABI info - done
1> [CMake] -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe - skipped
1> [CMake] -- Detecting CXX compile features
1> [CMake] -- Detecting CXX compile features - done
1> [CMake] CMake Error at C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.20/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
1> [CMake]   Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
1> [CMake] Call Stack (most recent call first):
1> [CMake]   C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.20/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
1> [CMake]   C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.20/Modules/FindPkgConfig.cmake:70 (find_package_handle_standard_args)
1> [CMake]   F:/Feature-test/marisa-trie/vcpkg/scripts/buildsystems/vcpkg.cmake:829 (_find_package)
1> [CMake]   CMakeProject45/CMakeLists.txt:13 (find_package)
1> [CMake] -- Configuring incomplete, errors occurred!

1> [CMake]   Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)

@JonLiu1993 Please provide this yourself in your environment. You can pick pkgconf from vcpkg.

@dg0yt , I follow your advice build the test project get the error, I have removed https://github.com/day253/vcpkg-mini-project/blob/90d236ac753d832112fe602b14c0148ce5b73d8b/CMakeLists.txt#L3-L4 @day253 , please take a look:

1> CMake generation started for configuration: 'x64-Debug'.

1> Found and using vcpkg toolchain file (F:/Feature-test/marisa-trie/vcpkg/scripts/buildsystems/vcpkg.cmake).

1> Command line: "C:\WINDOWS\system32\cmd.exe" /c "%SYSTEMROOT%\System32\chcp.com 65001 >NUL && "C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\ENTERPRISE\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe"  -G "Ninja"  -DCMAKE_BUILD_TYPE:STRING="Debug" -DCMAKE_INSTALL_PREFIX:PATH="C:\Users\source\repos\CMakeProject45\out\install\x64-Debug" -DCMAKE_C_COMPILER:FILEPATH="C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe" -DCMAKE_CXX_COMPILER:FILEPATH="C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe"  -DCMAKE_MAKE_PROGRAM="C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\ENTERPRISE\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\Ninja\ninja.exe" -DCMAKE_TOOLCHAIN_FILE="F:/Feature-test/marisa-trie/vcpkg/scripts/buildsystems/vcpkg.cmake" "C:\Users\source\repos\CMakeProject45" 2>&1"

1> Working directory: C:\Users\source\repos\CMakeProject45\out\build\x64-Debug

1> [CMake] -- The C compiler identification is MSVC 19.29.30146.0

1> [CMake] -- The CXX compiler identification is MSVC 19.29.30146.0

1> [CMake] -- Detecting C compiler ABI info

1> [CMake] -- Detecting C compiler ABI info - done

1> [CMake] -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe - skipped

1> [CMake] -- Detecting C compile features

1> [CMake] -- Detecting C compile features - done

1> [CMake] -- Detecting CXX compiler ABI info

1> [CMake] -- Detecting CXX compiler ABI info - done

1> [CMake] -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe - skipped

1> [CMake] -- Detecting CXX compile features

1> [CMake] -- Detecting CXX compile features - done

1> [CMake] CMake Error at C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.20/Modules/FindPackageHandleStandardArgs.cmake:230 (message):

1> [CMake]   Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)

1> [CMake] Call Stack (most recent call first):

1> [CMake]   C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.20/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)

1> [CMake]   C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.20/Modules/FindPkgConfig.cmake:70 (find_package_handle_standard_args)

1> [CMake]   F:/Feature-test/marisa-trie/vcpkg/scripts/buildsystems/vcpkg.cmake:829 (_find_package)

1> [CMake]   CMakeProject45/CMakeLists.txt:13 (find_package)

1> [CMake] -- Configuring incomplete, errors occurred!

Okay

Thanks for the great work. I'm sorry that I have to ask for changes again. @JonLiu1993 Can you perhaps build the offered test project on x64-windows in order to verify the pc file? You will have to remove https://github.com/day253/vcpkg-mini-project/blob/90d236ac753d832112fe602b14c0148ce5b73d8b/CMakeLists.txt#L3-L4 (I don't have a MSVC toolchain.)

CMakeLists.txt
set(VCPKG_TARGET_TRIPLET x64-windows)
include(C:/Users/work/CLionProjects/vcpkg/scripts/buildsystems/vcpkg.cmake)
set(PKG_CONFIG_EXECUTABLE "C:/ProgramData/chocolatey/bin/pkg-config.exe")

The build log.
C:\Users\work\AppData\Local\JetBrains\Toolbox\apps\CLion\ch-0\222.4345.21\bin\cmake\win\bin\cmake.exe -DCMAKE_BUILD_TYPE=Debug -DCMAKE_MAKE_PROGRAM=C:/Users/work/AppData/Local/JetBrains/Toolbox/apps/CLion/ch-0/222.4345.21/bin/ninja/win/ninja.exe -G Ninja -S C:\Users\work\CLionProjects\vcpkg-mini-project -B C:\Users\work\CLionProjects\vcpkg-mini-project\cmake-build-debug
-- Running vcpkg install
Detecting compiler hash for triplet x64-windows...
All requested packages are currently installed.
Restored 0 package(s) from C:\Users\work\AppData\Local\vcpkg\archives in 109.8 us. Use --debug to see more details.
Total install time: 142.6 us
The package marisa-trie can be imported via CMake FindPkgConfig module:

    find_package(PkgConfig REQUIRED)
    pkg_check_modules(marisa REQUIRED IMPORTED_TARGET marisa)
    target_link_libraries(main PkgConfig::marisa)

-- Running vcpkg install - done
-- Found PkgConfig: C:/ProgramData/chocolatey/bin/pkg-config.exe (found version "0.28")
-- Checking for module 'marisa'
--   Found marisa, version 0.2.6+20200926
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/work/CLionProjects/vcpkg-mini-project/cmake-build-debug

[Finished]

build log
====================[ Build | main | Debug ]====================================
C:\Users\work\AppData\Local\JetBrains\Toolbox\apps\CLion\ch-0\222.4345.21\bin\cmake\win\bin\cmake.exe --build C:\Users\work\CLionProjects\vcpkg-mini-project\cmake-build-debug --target main -j 12
[1/1] Linking CXX executable main.exe
FAILED: main.exe
cmd.exe /C "cd . && C:\Users\work\AppData\Local\JetBrains\Toolbox\apps\CLion\ch-0\222.4345.21\bin\mingw\bin\g++.exe -g  CMakeFiles/main.dir/main.cpp.obj -o main.exe -Wl,--out-implib,libmain.dll.a -Wl,--major-image-version,0,--minor-image-version,0  vcpkg_installed/x64-windows/debug/lib/libmarisa.lib  -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cmd.exe /C "cd /D C:\Users\work\CLionProjects\vcpkg-mini-project\cmake-build-debug && C:\Users\work\AppData\Local\Microsoft\WindowsApps\pwsh.exe -noprofile -executionpolicy Bypass -file C:/Users/work/CLionProjects/vcpkg/scripts/buildsystems/msbuild/applocal.ps1 -targetBinary C:/Users/work/CLionProjects/vcpkg-mini-project/cmake-build-debug/main.exe -installedDir C:/Users/work/CLionProjects/vcpkg-mini-project/cmake-build-debug/vcpkg_installed/x64-windows/debug/bin -OutVariable out""
C:\Users\work\AppData\Local\JetBrains\Toolbox\apps\CLion\ch-0\222.4345.21\bin\mingw\bin/ld.exe: CMakeFiles/main.dir/main.cpp.obj:C:/Users/work/CLionProjects/vcpkg-mini-project/main.cpp:9: undefined reference to `marisa::Trie::Trie()'
C:\Users\work\AppData\Local\JetBrains\Toolbox\apps\CLion\ch-0\222.4345.21\bin\mingw\bin/ld.exe: CMakeFiles/main.dir/main.cpp.obj: in function `main':
C:/Users/work/CLionProjects/vcpkg-mini-project/main.cpp:11: undefined reference to `marisa::Trie::~Trie()'
collect2.exe: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.


Prototype of Polonius

Current status:

the most up-to-date details about prototyping are in this hackmd, and evolved out of the two previous descriptions
we've started looking into realizing this design in-tree, but it's still early days


Add type definitions to allow for use in type-safe Python projects

Is your feature request related to a problem? Please describe.
I have a disability that makes my working memory extremely limited. As such, non-typed libraries are extremely difficult to use, as I struggle to work without advanced editor completions. These editor completions are vastly improved by adding type annotations.
Describe the solution you'd like
Add type annotations to Mido, so that its users can get improved editor support.
Describe alternatives you've considered
Create type definitions in the typeshed repository. This is viable, but means that the type-definitions can't be validated against the library as easily.
Additional context
If needed, I'd be happy to try my hand at this. Just let me know:

Should I set the project up to use mypy for static verification of the project?
How permissive/strict should the definitions be?

Examples where type definitions would be helpful:

I also use mypy for type checking, but I think that having type annotations in mido library would make it safer and more convenient to use.


Cache fileExists in core/resolve

In a project where I have import/no-unresolved enabled, I get the
following results with ESLint's TIMING=1 environment variable enabled:
Rule                          | Time (ms) | Relative
:-----------------------------|----------:|--------:
import/no-unresolved          | 18563.065 |    40.6%
react/sort-comp               |  1621.646 |     3.5%
no-irregular-whitespace       |  1386.958 |     3.0%
react/prop-types              |  1197.552 |     2.6%
no-implied-eval               |   829.967 |     1.8%
react/jsx-uses-vars           |   765.702 |     1.7%
keyword-spacing               |   765.665 |     1.7%
no-eval                       |   578.730 |     1.3%
semi-spacing                  |   549.684 |     1.2%
no-whitespace-before-property |   477.285 |     1.0%

To speed up this outlier, I decided to cache the results of file
existence checks in a Map. Adding this cache brings this time down
from ~18s to ~13s:
Rule                    | Time (ms) | Relative
:-----------------------|----------:|--------:
import/no-unresolved    | 13199.978 |    32.5%
react/sort-comp         |  1793.781 |     4.4%
react/prop-types        |  1400.975 |     3.4%
no-irregular-whitespace |  1315.485 |     3.2%
react/jsx-uses-vars     |   794.097 |     2.0%
no-implied-eval         |   765.593 |     1.9%
keyword-spacing         |   752.945 |     1.9%
no-eval                 |   592.048 |     1.5%
semi-spacing            |   532.061 |     1.3%
no-control-regex        |   479.856 |     1.2%

Addresses #187

This is awesome, thanks! I hadn't thought to look at this. I need to double check some things with cache correctness for eslint_d and eslint-loader, but I'll merge + publish ASAP!


fix: distribute tsconfig and rollup config files

Summary:
We currently distribute the source code for the project, but not the
configuration files, meaning that users cannot build the project. This commit
adds the tsconfig.json and rollup.config.js files to the distributed package.
Test Plan:

Run npm run build and ensure that the project builds successfully
In another project add this package as a dependency and run npm install && cd node_modules/web-vitals && npm install --ignore-scripts && npm run build and ensure that
the project builds successfully

Motivation:
I am currently working on a patch for the web vitals Chrome extension and need
to use a development build of this web-vitals package.  To do that, I want to make a patch like
diff --git a/package.json b/package.json
--- a/package.json
+++ b/package.json
@@ -13,7 +13,7 @@
   "private": true,
   "scripts": {
     "lint": "npx eslint src --fix",
-    "build": "npm install; cp node_modules/web-vitals/dist/web-vitals.attribution.js src/browser_action/web-vitals.js"
+    "build": "npm install && (cd node_modules/web-vitals/ && npm install --ignore-scripts && npm run build) && cp node_modules/web-vitals/dist/web-vitals.attribution.js src/browser_action/web-vitals.js"
   },
   "devDependencies": {
     "babel-eslint": "^10.1.0",
@@ -21,6 +21,10 @@
     "eslint-config-google": "^0.14.0"
   },
   "dependencies": {
-    "web-vitals": "^4.0.0"
+    "web-vitals": "git://github.com/GoogleChrome/web-vitals.git#soft-navs"
+  }

however, the npm run build part fails because we don't distribute
tsconfig.json and rollup.config.js.  This commit fixes that.

I would have thought if you only wanted to build this library, then you'd download the source (i.e. git clone the repo) and then build. So you'd have the tsconfig.json and rollup.config.js files.
Alternatively, if you wanted to to build this as part of a larger app, you'd npm install is as a dependency and use that larger project's typescript and build options.
Is it usually expected to build just the package from npm install? Not sure I've come across that before for a JS library...

Thanks for the quick reply!

Is it usually expected to build just the package from npm install? Not sure I've come across that before for a JS library...

I don't know.  My feeling was that if we distribute the src/, the expectation is that users should be able to build it.  I understand your feeling that users should just write their own build configuration.
What if the web-vitals package's build steps were more complicated and we still distributed src/?  Would it be expected that users reimplement the whole build configuration in order to use the src/ files we already distribute?  I get that in this case the build steps are simple so writing a script in the Web Vitals Chrome extension wouldn't be hard.

As a follow-up, what would you suggest I do for https://github.com/GoogleChrome/web-vitals-extension/pull/184 ?  Do you think I should git clone this package instead of npm installing it?

idea: can we publish a web-vitals@soft-nav version of this package on npm?  That would make the Extension patch the simplest

It already is published there! And I try to keep it up to date as we make changes to the main branch.

🤦🏾♀ I swear this was the first place I looked, and after not finding it, I decided to do this more complicated solution.  Sorry I can't read!


Enable the new model serialization for dynatrace

Contributing to the Azure SDK
Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.
For specific information about pull request etiquette and best practices, see this section.

API change check
API changes are not detected in this pull request.


Name change to React Robins.

Thanks for opening this PR. I think we should have some messaging referring to our previous name maybe in the FAQ or about section and initially have a small toast banner at the top
of the page to announce the change.


CQ-4282135 Focus loss is observed after removing last tag from added …

…from added tags, while navigating using keyboard tab key

Issue is when we remove all added tags focus got lost. As discussed in team focus should be restore to previously focused element prior to taglist.
Description

If removed tag is last tag than in that case detachItem and this._itemToFocusAfterDelete are same element because we can't find previous sibling and next sibling of last tag. so initialised this._itemToFocusAfterDelete to this.parentElement in that case
Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.

Thanks can you pls add a test case ?

@icaraps : Changed approach for this PR. Handled cases if no parent element present.

CQ-4282135 Refactor to restore focus to coral-taglist itself if parent component does not manage focus

CQ-4282135 Wait a frame before checking focus restoration

CQ-4282135 Suppress focus rectangle on empty taglist

CQ-4282135 TagList: don't focus if parentElement.focus() has already restored focus

If parentElement of taglist has already restored focus to a descendant of the TagList, don't focus the TagList and instead call the blur handler to clean up code that allows TagList itself to receive focus.

See https://github.com/gagan031992/coral-spectrum/pull/1 for fixes to unit tests.

@majornista @icaraps  Please review this

@icaraps, can you merge this if everything is ok?
cc @gagan031992


🧻🧻🧻 Towel mode rework – Bot API 5.5 | The towel in the private chat

Looks like we could make towel-mode even better!

Bot API 5.5

• Bots can now contact users who sent a join request to a chat where the bot is an admin – even if the user never interacted with the bot before.
• Added support for protected content in groups and channels.
• Added support for users posting as a channel in public groups and channel comments.
• Added support for mentioning users by their ID in inline keyboards.
• And more, see the full changelog for details:
https://core.telegram.org/bots/api#december-7-2021

Warning: As previously announced, user identifiers can now have up to 52 significant bits and require a 64-bit integer or double-precision float type to be stored safely.

[ ] wait till python-telegram-bot add 5.5 support
[ ] update deps
[ ] rework towel-mode over new one2one method (but do it in funny way!)

Actually, just before rolling out of a towel-mode:2.0 feature I guess we should made several steps:

Implement proper tests for all current bot modes/skills

Mock Telegram API and test what calls are actually made by the bot
Etc

Implement some kind of State Machine global and per mode/skill, from which every would benefit. So for example, let's say Nyan are having conversation with User=x in PM, and TowelMode can set State depends on a dialog flow.
Just before we are getting merged towel-mode:2.0 we should enable Join Requests in VLDC Chat, so bot will be the one who decide should someone be added to group or not.

About rework of towel-mode, I guess it should like this:

User clicks invite link or join group
Join request were created -> Nyan can write to user in PM
Nyan writes Towel Mode Message to user in PM
User reads carefully that message, and for example replies to that message with his beautifully crafted intro message
Nyan forwards that message to main group and someone should put 👍 as a reply to that message (or we can use inline buttons, but i like reply more)
Putting 👍 means intro was good (not bot-alike), and nyan accepts user join request
If no one puts 👍, sad for user 😢
If someone puts 👎 , social credit goes down and user should write new intro which will be sended after for example 24 hours or after he will write /send to Nyan, so he can edit his intro message well
We can actually implement some kind of bypass of a Towel Mode -- for example, if user gets invited by someone or user is a known member of VLDC Chat

@egregors @C-Pro  What do you think guys?

I think we need to make separate Issue for the Test Coverage of Nyan. 👍


Add documentation for running visualisation snapshot tests

Summary
A number of community contributors are looking at tackling issues relating to visualisations. This requires them to update the visualisation snapshot tests. This PR adds documentation to the contributing.md explaining how to run snapshot tests and update them.

As a side note, every time test/ipynb/mpl_tester.ipynb is used to run the snapshot tests, some of its metadata changes. While the file can be easily taken out of a commit, maybe it would be useful to include it in the .gitignore file.

As a side note, every time test/ipynb/mpl_tester.ipynb is used to run the snapshot tests, some of its metadata changes. While the file can be easily taken out of a commit, maybe it would be useful to include it in the .gitignore file.

I use https://pypi.org/project/nb-clean/ for "cleaning" notebooks before pushing them. Maybe add this as a recommendation in the doc?
Other possibility is to add nb-clean as a pre-commit hook. But this means yet another req-dev. Maybe @mtreinish has an opinion.

thanks for the review @1ucian0 😄 I've made the changes you suggested (just tweaked the grammar a bit). Ready for re-review when you get a moment


Fix Double Spaces Not Showing on Frontend

Double spaces are rendered as single spaces on frontend, making for some confusing edge cases such as
https://www.f2p.wiki/players/st%20pk
https://www.f2p.wiki/players/st%20%20pk

Also related is this issue https://www.f2p.wiki/players/_Bon_Sufar