how to use simOTA for mask_r_cnn ?

I want to use SimOTAAssigner instead of MaxIoUAssigner.
I changed cfg as follows(based on mmdetection/configs/swin/mask_rcnn_swin-t-p4-w7_fpn_1x_coco.py).
    train_cfg=dict(
        rpn=dict(
            #assigner=dict(
            #    type='MaxIoUAssigner',
            #    pos_iou_thr=0.7,
            #    neg_iou_thr=0.3,
            #    min_pos_iou=0.3,
            #    match_low_quality=True,
            #    ignore_iof_thr=-1),
            assigner=dict(type='SimOTAAssigner', center_radius=2.5),
            sampler=dict(
                type='RandomSampler',
                num=256,
                pos_fraction=0.5,
                neg_pos_ub=-1,
                add_gt_as_proposals=False),

            allowed_border=-1,
            pos_weight=-1,
            debug=False),
        rpn_proposal=dict(
            nms_pre=2000,
            max_per_img=1000,
            nms=dict(type='nms', iou_threshold=0.7),
            min_bbox_size=0),
        rcnn=dict(
            assigner=dict(type='SimOTAAssigner', center_radius=2.5),
            # assigner=dict(
            #    type='MaxIoUAssigner',
            #    pos_iou_thr=0.5,
            #    neg_iou_thr=0.5,
            #    min_pos_iou=0.5,
            #    match_low_quality=True,
            #    ignore_iof_thr=-1),
            sampler=dict(
                type='RandomSampler',
                num=512,
                pos_fraction=0.25,
                neg_pos_ub=-1,
                add_gt_as_proposals=True),
            mask_size=28,
            pos_weight=-1,
            debug=False)
            ),

However, I got the following error.
  File "/home/u094724e/vinbig/src/mmdetection/mmdet/models/detectors/base.py", line 172, in forward
    return self.forward_train(img, img_metas, **kwargs)
  File "/home/u094724e/vinbig/src/mmdetection/mmdet/models/detectors/two_stage.py", line 135, in forward_train
    rpn_losses, proposal_list = self.rpn_head.forward_train(
  File "/home/u094724e/vinbig/src/mmdetection/mmdet/models/dense_heads/base_dense_head.py", line 326, in forward_train
    losses = self.loss(*loss_inputs, gt_bboxes_ignore=gt_bboxes_ignore)
  File "/home/u094724e/vinbig/src/mmdetection/mmdet/models/dense_heads/rpn_head.py", line 93, in loss
    losses = super(RPNHead, self).loss(
  File "/home/u094724e/anaconda3/envs/openmmlab/lib/python3.9/site-packages/mmcv/runner/fp16_utils.py", line 186, in new_func
    return old_func(*args, **kwargs)
  File "/home/u094724e/vinbig/src/mmdetection/mmdet/models/dense_heads/anchor_head.py", line 485, in loss
    cls_reg_targets = self.get_targets(
  File "/home/u094724e/vinbig/src/mmdetection/mmdet/models/dense_heads/anchor_head.py", line 365, in get_targets
    results = multi_apply(
  File "/home/u094724e/vinbig/src/mmdetection/mmdet/core/utils/misc.py", line 30, in multi_apply
    return tuple(map(list, zip(*map_results)))
  File "/home/u094724e/vinbig/src/mmdetection/mmdet/models/dense_heads/anchor_head.py", line 246, in _get_targets_single
    assign_result = self.assigner.assign(
TypeError: assign() missing 1 required positional argument: 'gt_labels'

what should I do?

SimOTA is not compatible with Mask R-CNN for now because it requires more inputs. We may support that in the future.

SimOTA is not compatible with Mask R-CNN for now because it requires more inputs. We may support that in the future.

any update?

Update
In MMDetection-3.x, we support using any kind of single-stage model as RPN, which means you can use the YOLOX head as the RPN head. In this way, you can use the SimOTA in Mask R-CNN's RPN.
Please refer to this doc and have a try! https://github.com/open-mmlab/mmdetection/blob/3.x/docs/en/user_guides/single_stage_as_rpn.md
Feel free to open a new issue if you have any problems with the "Single-stage as RPN" feature.


Question about Positions / Superbatch and Positions

Hi,
I have a question regarding the positions count in the training data:
What happens if the Positions / Superbatch is smaller than the Positions?
I assume that the training will use only the first Positions / Superbatch positions for the training.
Is my assumption correct?
Best regards,
Krasimir

@bagaturchess the superbatch is wholly independent of dataset size, if you have less positions in your dataset than are in one superbatch, the superbatch uses its usual number of positions, wrapping back round to the start of the dataset.
I recommend joining the Engine Programming Discord Server (https://discord.com/invite/F6W6mMsTGN).

Thanks for the answer.
Best regards, Krasimir


Expose hook into the module resolution (resolve)

@styfle tests passing now 😉

Implemented the suggestions and got the tests passing again 😉


Dev

moved several functions from batch.py to new script batch_utils.py for access from local.py, #202
build_timetree now returns standardized residuals to measure departure from molecular clock by lineage, #213
JSON and Newick outputs are now automatically timestamped
dbstats.json now carries lineage-specific information for colouring the tree, #213
added --dry-run parameter for testing batch script (prevents upload of data files to webserver)
moved several files to temporary deprecated folder
removed unused reference sequence data files
updated VCF to version 4, #214
removed unused filter_fasta() function from treetime.py
filtering genomes using both lower and upper quantiles of Poisson distribution, #228
added colour legends for time-scaled tree plot
beadplot SVG now dynamically redrawn to scale with window size
moved most JS from index.html to new file covizu.js
added FileSaver.js to enable users to download trees, #174
refactored data structures to be more compact, #208
search interface refactoring in progress

On cluster:

[ ] cancel cron job for the day (comment out entry in crontab)
[ ] checkout dev branch
[ ] run batch.py as usual (refer to crontab)
[ ] data files should be generated in about 12 hours
[ ] download datafiles to local computer running dev branch to evaluate front-end

If all checks out, merge pull request, update cluster and webserver

On cluster:

[ ] cancel cron job for the day (comment out entry in crontab)
[ ] checkout dev branch
[ ] run batch.py as usual (refer to crontab)
[ ] data files should be generated in about 12 hours
[ ] download datafiles to local computer running dev branch to evaluate front-end

If all checks out, merge pull request, update cluster and webserver

Since this coincides with installing the new server (PoonLab#203) tomorrow, and yesterday's run is still in progress, I am holding this run until tomorrow.


[IOTDB-6041] Pipe: NPE when handling partial insertion using DisruptorQueue in extractor stage

See IOTDB-6041 for more details.

coverage: 47.896% (-0.002%) from 47.898% when pulling 7949161fe4bf4b480c82f3b299e66d5f2a952db8 on IOTDB-6041 into 689663f20d141de4aa447addf858ef7a07ceb818 on master.


Incompatibility with VManip

This issue causes weapons to not immediately be given to the player when Use / Spawn at Self is used.

Resolved via commit 4041b0a7e6b86e9e23854e8f5d031fd1785c19ca.


Hot loaded not being serialised to JSON

Getting builtins.TypeError: Object of type function is not JSON serializable because the lambda created when adding hot load, is not being serialise.

Fixed in branch JH_http_serve


make sdf_mutate friendlier and more predictable

This resolves issue #1329

The documented example works without any chnges
data(beavers, package = "datasets")
beaver_tbl <- copy_to(sc, beaver1, "beaver")
beaver_tbl %>%
  mutate(squared = temp ^ 2) %>%
  sdf_mutate(warm = ft_binarizer(squared, 1000)) %>%
  sdf_register("mutated")
#
#  # Source:   table<mutated> [?? x 6]
# # Database: spark_connection
#      day  time  temp activ squared  warm
#    <dbl> <dbl> <dbl> <dbl>   <dbl> <dbl>
#  1   346   840  36.3     0    1320  1.00
#  2   346   850  36.3     0    1321  1.00
#  3   346   900  36.4     0    1321  1.00
#  4   346   910  36.4     0    1326  1.00
#  5   346   920  36.6     0    1336  1.00
#  6   346   930  36.7     0    1346  1.00
#  7   346   940  36.7     0    1348  1.00
#  8   346   950  36.8     0    1351  1.00
#  9   346  1000  36.8     0    1355  1.00
# 10   346  1010  36.9     0    1360  1.00
# # ... with more rows

The job exceeded the maximum time limit for jobs, and has been terminated.

Not sure what to do about that.

@mattpollock Thanks for the PR! Looking at the issue you opened I'm thinking we can consider deprecating sdf_mutate() in favor of something like https://github.com/rstudio/sparklyr/issues/1267. Is your use case for sdf_mutate() basically to avoid typing a bunch of "s? I think we want to avoid having too many ways to achieve the same thing.

I see your point. I like using the mutate construct where I can name the output column on the LHS and forego the quotes. That makes spark API operations feel more like they belong in a dplyr pipeline.
I feel pretty strongly that sdf_mutate should not stay as is given the odd behavior I pointed out in #1329, however if the direction you all are going in is to promote direct use ft_* and similar functions in pipelines I can deal with that. Would #1267 be a breaking change requiring all the current SE functions to be transitioned to NSE and (presumably) new [ft|ml]_*._$ functions to be written to support standard evaluation?

I've been mulling this for a 1/2 hour now. I don't presume to have much of a vote here, but keeping NSE in verb functions seems more consistent. Let ft_ and ml_ use standard evaluation (i.e., don't do #1267) in the same way that grepl, gsub, etc. use standard evaluation in local dplyr pipelines. Locally most functions use SE and dplyr verbs do NSE. Following this pattern seems less confusing with the one caveat being that the output_col= argument is unique in the spark context.
I'd like to keep sdf_mutate around with the purposed modifications, but as I said above, if you want to kill it I can modify how I'm doing stuff today.

Just gave this some thought, too. The plan for #1267 was that for ft_.tbl_spark() functions we'd support looking up unquoted names in the dataframe columns, then look for bindings in the calling environment, so it wouldn't break current usage. However, one of the workflows is that the user would interactively use these ft_ and ml_ functions with a data frame, e.g.
beaver_tbl %>%
  ft_binarizer("temp", "hot", 36.5) %>%
  ft_r_formula(hot ~ time + activ) %>%
  ml_logistic_regression()

then easily turn it into a pipeline by replacing the data frame input:
pipeline <- ml_pipeline(sc) %>%
  ft_binarizer("temp", "hot", 36.5) %>%
  ft_r_formula(hot ~ time + activ) %>%
  ml_logistic_regression()

NSE would complicate things here since it won't be obvious where we're looking for the variables first. This would be an argument for not implementing #1267 even if it's backwards compatible. (Also, it adds yet another way to do something...)
Perhaps we should patch sdf_mutate() now so it supports named arguments and you're unblocked. Also we could designate sdf_mutate() as the one place where NSE is supported for feature transformers. We want to move away from lazyeval though and use tidyeval instead.
@kevinushey @edgararuiz @javierluraschi thoughts here?

OK we caught up a bit and this is what we'll do. We'll soft deprecate sdf_mutate(), so instead of
beaver_tbl %>%
  mutate(squared = temp ^ 2) %>%
  sdf_mutate(warm = ft_binarizer(squared, 1000))

we'd write
beaver_tbl %>%
  mutate(squared = temp ^ 2) %>%
  ft_binarizer("squared", "warm", 1000)

We can still use feature transformers without breaking pipelines. The ft_ functions aren't SQL so this syntax makes that a bit more explicit. Also, the sdf_ functions should really map 1:1 to Spark DataFrame functions. We can revisit implementing something in the future but it'd be a different name (or package.)
As for https://github.com/rstudio/sparklyr/issues/1267 we'll put it on hold for now. It'd be pretty involved and if we don't do it right it has the potential to cause much confusion and unexpected behavior.
Thanks again for the issue and your thoughts, @mattpollock !

Works for me. I'll adjust accordingly. Thanks very much.


Question: Are repositories synchronized sequentially?

Hello team, congratulations for your work. We are testing git2consul-go as a replacement for Gonsul.
This is the version we are using:
git2consul --version
git2consul, version v0.1.1 (branch: HEAD, revision: abdf3a1d746539f08ce5122f9d7db43ae4e79afd)
build date: 20200106-19:50:06
go version: go1.13.5

Our case is the following: Gonsul works great for a "flat" infrastructure (mirroring the Git values into Consul KV) but we want to be able to "reuse" some values, creating "default" values that we can override per environment (eg: production)
So, I have a single test repo named consul with 2 folder: "base" and "prod". All the values are located inside "base". Inside "prod" I just have added the values I want to override for production.
I have created the following config.json file:
{
  "local_store": "/tmp/git2consul",
  "repos": [
    {
      "name": "consul-base-development",
      "url": "ssh://gitlab.myorganization.com/consul.git",
      "source_root": "/base/",
      "mount_point": "development/",
      "skip_repo_name": true,
      "skip_branch_name": true,
      "expand_keys": true,
      "credentials": {
        "private_key": {
          "pk_key": "/path/to/.ssh/id_rsa",
          "pk_username": "git"
        }
      }
    },
    {
      "name": "consul-base-production",
      "url": "ssh://gitlab.myorganization.com/consul.git",
      "source_root": "/base/",
      "mount_point": "production/",
      "skip_repo_name": true,
      "skip_branch_name": true,
      "expand_keys": true,
      "credentials": {
        "private_key": {
          "pk_key": "/path/to/.ssh/id_rsa",
          "pk_username": "git"
        }
      }
    },
    {
      "name": "consul-production",
      "url": "ssh://gitlab.myorganization.com/consul.git",
      "source_root": "/prod/",
      "mount_point": "production/",
      "skip_repo_name": true,
      "skip_branch_name": true,
      "expand_keys": true,
      "credentials": {
        "private_key": {
          "pk_key": "/path/to/.ssh/id_rsa",
          "pk_username": "git"
        }
      }
    }
  ]
}

When I execute git2consul -config ./config.json -debug -once sometimes it works great: the production KV path is populated with all the values from "base" (the "default" values) and then those specific values in "prod" are used to override the production settings. So, the production KV path has correctly merged base and prod. So far so good.
But this process seems to be not idempotent. Sometimes, when I execute the same command, the result is that "production" only shows the values from "base".
So, my question is: are these "repositories" (they are actually the same repo) processed sequentially or in parallel? If they are processed in parallel (and the order is not guaranteed), is it possible to force a sequential execution of these repos? (first we apply "base", then we apply "prod" on top)
Thank you very much in advance

@leoblanc sorry for the slow response time on our side. Unfortunately we're currently not in a position to implement a lot of changes or help much (we're short staffed due to the pandemic).
This might be as simple as adding an optional order key that forces it to be processed in the order you want. We'd appreciate any pull requests. :)

@Smiley73 Hi, thanks for your answer! My Go skills are limited but I'll try to provide a PR, thanks again

From what I can tell the code is using go routines and select, so order is not guaranteed.
Here are some notes about the relevant code for this feature enhancement request ...

Here is the go routine that starts the runner.
Relevant select statement
The Watcher code using channels

@leoblanc We have a similar use-case, where we keep as much as possible in a "common" section (i.e. your "base"), and override for specific instances where required. We use the following structure in Consul:
services/<service-name>/common/env/[KV Pairs]
services/<service-name>/<instance-name>/common/env/[KV Pairs]
services/<service-name>/<instance-name>/[dev|test|prod]/env/[KV Pairs]

we keep this in a single repo that mirrors this structure. Come deploy time, we use consul-template, with a routine like:
{{/* Build a map of the environment variables. */}}
{{/* First we get all the instance variables, and set them in the Map */}}
{{ range tree $instancevars }}
    {{ scratch.MapSet "vars" .Key .Value }}
{{ end }}
{{/* Get all the common variables. Don't overwrite a variable if it is already in the map */}}
{{ range tree $commonvars }}
    {{ scratch.MapSetX "vars" .Key .Value }}
{{ end }}

This will first grab everything in a specific instance branch of the tree, and drop the values in an internal map. Next it will grab everything out of a common branch, but only set data in the map if the key's don't already exist.
I can then render the data (in this case it is going into a config file) like so:
{{ range $thekey, $theval := (scratch.Get "vars" | explodeMap) }}
    {{ $thekey }}: {{ $theval }}{{ end }}

Hope this helps.

@MartijnDekkers This is great, thank you very much! We tried to work on a git2consul-go patch but didn't have success so far. I'll try your approach, thanks again!

@leoblanc were you able to resolve this issue?

@Smiley73 Not yet, I'm creating a PoC based on consul-template. @MartijnDekkers Can you please tell me how you load the $instancevars and $commonvars variables? Thank you very much

@leoblanc This is part of the definition section of my template, it is on top of the file:
{{/* Define variables to be used in the template. Keep the template clean and readable. */}}
{{/* Get required information from the environment. It is possible to get these from elsewhere if required. */}}
{{- $service := env "SERVICE" -}}
{{- $instance := env "INSTANCE" -}}
{{- $deploy := env "DEPLOY" -}}

{{/* Some stuff that uglifies the template. Put them here for easier debugging and readability */}}
{{/* Frequently used lookups */}}
{{- $commonvars := (printf "%s/common/vars" ($service)) -}}
{{- $instancevars := (printf "%s/%s/%s/vars" ($service) ($instance) ($deploy)) -}}
{{- $commonparams := (printf "%s/params" ($service)) -}}
{{- $instanceparams := (printf "%s/%s/%s/params" ($service) ($instance) ($deploy)) -}}
{{- $dcospath := (printf "%s/%s/%s" ($service) ($deploy) ($instance)) | replaceAll "tenants" "" -}}
{{- $dcoscommonsettings := (printf "%s/DCOS" ($service)) -}}
{{- $dcosinstsettings := (printf "%s/%s/%s/DCOS" ($service) ($instance) ($deploy)) -}}
{{- $volnamesuffix := (printf "%s%s" ($deploy) ($instance)) | replaceAll "/" ""}}
{{- $port := keyOrDefault (printf "%s/%s/%s/vars/PORT" ($service) ($instance) ($deploy)) (key (printf "%s/common/vars/PORT" ($service))) -}}
{{- $pwxdefs := (printf "%s/common/DCOS/volumes" ($service)) -}}
{{- $commonsecrets := (printf "%s/common/DCOS/secrets" ($service)) -}}
{{- $instancesecrets := (printf "%s/%s/%s/DCOS/secrets" ($service) ($instance) ($deploy)) -}}

This layout (and the rest that follows) will leave a whole bunch of empty lines at the top of the rendered file, there are different ways to deal with that.  This particular template renders to a YAML file, that I run through yq to end up with a JSON file that's valid for my use-case.
This approach makes that you can use {{ range tree $instancevars }} in the main body of your template, instead of {{ range tree (printf "%s/%s/%s/vars" ($service) ($instance) ($deploy)) }} which makes for a nicer experience.

Great! This is very useful. Thank you very much!


Image rendering issue

GitHawk don’t render image when they are in a table properly.

GitHawk
GitHub

Bug Report Dump (Auto-generated)

Version 1.19.1<PHONE_NUMBER>)
Device: iPhone X (iOS 11.3.1)
TestFlight: false

Ya images in tables aren't supported at this time. Would take a little bit of elbow-grease to get this wired up, but not impossible.

@rnystrom can you give me some pointers on how I can contribute to fix this ?
Sent with GitHawk

@mackoj sure thing! This might be a little more complicated than I first thought. Let me know what you think!
Check out how we dynamically download and resize image cells in issues. We cache the sizes as well.
Atm table cells are assumed to be all text. We precompute the sizes and put them in these models. Then we use this cell to display the whole table.
So we'd need to add a new model (or update the existing one) w/ image info, async load the image, and on load refresh the table.
Another tricky part is that the height/width of the image will change the size of the rows/columns of other cells.

I was trying to approach this issue and got a little blocked. It seems like this file in the cmark-gfm-swift pod would need to be modified to pass in images.. I'm not sure how to go about making modifications to project dependency.
Also, would it be a good idea or overkill to refactor the current cell  that displays the markdown table to use a ListAdapter/ListSectionController?

@BrianLitwin ya I think you’re right. Need to update that library as well. The nice part is we can do this in stages, and that library is setup with tests.
Not sure about refactoring to use IGListKit on that. What would we be trying to gain?
Sent with GitHawk

The same issue applies to images in numbered lists.  Not a humongous deal, but it’d be nice to not be missing content altogether, even if the rendering isn’t an exact match.  Seeing something like this makes a user question every rendering he or she sees, and forces me to pop any rendering that looks odd into Safari to confirm that I’m not missing something relevant.

Thanks for all of your diligent work on this project.  Is there any way we can donate to support this project?

@billybooth thank you! Re: donations, I appreciate the thought, but since this is a community operation, I’d rather donations go to a cause in GitHawks name.
http://hispanicfederation.org/unidos/
Sent with GitHawk

Also a review on the App Store is free and helps out the entire project 😉❤


feat(bivariate-matrix): 13230, 13231 - indicators selection reimplemented

https://kontur.fibery.io/Tasks/Task/The-selected-indicators-are-not-highlighted-in-the-BM-for-the-whole-world-13230
https://kontur.fibery.io/Tasks/Task/The-legend-panel-is-not-updating-after-choosing-the-layer-on-BM-for-the-whole-world-13231
no screenshots as it's just a fix of existing behaviour

Codecov Report

Merging #357 (32c03b7) into main (b59b3d0) will decrease coverage by 0.30%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main     #357      +/-   ##
==========================================
- Coverage   11.63%   11.33%   -0.31%
==========================================
  Files         537      541       +4
  Lines       38703    38794      +91
  Branches     1132     1122      -10
==========================================
- Hits         4505     4398     -107
- Misses      33765    33950     +185
- Partials      433      446      +13

Impacted Files
Coverage Δ

...ivariate_manager/atoms/bivariateMatrixSelection.ts
0.00% <ø> (ø)

...nectedBivariateMatrix/ConnectedBivariateMatrix.tsx
0.00% <0.00%> (ø)

...yersDetailsResource/areaLayersDetailsParamsAtom.ts
0.00% <0.00%> (ø)

src/utils/atoms/forceRun.ts
0.00% <0.00%> (-100.00%)
:arrow_down:

src/core/api_client/index.ts
0.00% <0.00%> (-100.00%)
:arrow_down:

src/core/notifications/index.ts
0.00% <0.00%> (-100.00%)
:arrow_down:

src/core/logical_layers/index.ts
0.00% <0.00%> (-100.00%)
:arrow_down:

src/core/notificationServiceInstance.ts
0.00% <0.00%> (-100.00%)
:arrow_down:

src/utils/atoms/createAsyncAtom/index.ts
0.00% <0.00%> (-100.00%)
:arrow_down:

src/core/apiClientInstance.ts
0.00% <0.00%> (-90.25%)
:arrow_down:

... and 83 more

Merging #357 (b50a8f6) into main (b59b3d0) will decrease coverage by 0.30%.

Can we add a bit of tests to make this change positive? Thanks.


add Remote Chat

please add Remote chat

Would love this, since a lot of RATs have the same feature.

Duplicate of #351.


GraphCast improvements - Part I

Modulus Pull Request
Description

Closes https://github.com/NVIDIA/modulus/issues/506, https://github.com/NVIDIA/modulus/issues/505, https://github.com/NVIDIA/modulus/issues/486, https://github.com/NVIDIA/modulus/issues/508, https://github.com/NVIDIA/modulus/issues/509, https://github.com/NVIDIA/modulus/issues/511
Checklist

[x] I am familiar with the Contributing Guidelines.
[x] New or existing tests cover these changes.
[x] The documentation is up to date with these changes.
[x] The CHANGELOG.md is up to date with these changes.
[x] An issue is linked to this pull request.

Dependencies

/blossom-ci

@mnabian
Since you are revisiting GraphCast now, adding a few comments

Can we add the option to use transformer_engine.LayerNorm? In AIFS benchmarks, we just could get a 1.3x end-to-end improvement from doing so since the PyTorch implementation is rather bad for the sizes we encounter in these workloads.
Can you check whether the current combination of MeshGraphNodeBlock and MeshGraphEdgeBlock actually matches the paper (https://github.com/NVIDIA/modulus/blob/main/modulus/models/graphcast/graph_cast_processor.py#L97-L98) I created a schematic of the GraphCast architecture for some Arch folks last week, and I think the order of residuals over the edges does not match the paper here. I might have made a mistake when trying to use shared primitives here the last time. The issue here is that in MeshGraphNet, EdgeBlock already applies the "residual" on the edge features, while the NodeBlock would expect then the features including the residual connection prior to message-passing while in GraphCast, all residual connections are only applied after both the updated edge and node features are computed (at least according to the paper).
What would you think of splitting the GraphCastNet into a GraphCastNetERA5 and a GraphCastNet model? The current issue I see with GraphCastNet is that it is very specific to the nature of the ERA5 dataset (e.g. when it comes to preparing the input and output to switch between the HxW layout and the typical "serial" graph layout. GraphCastNet then could be a rather data-agnostic model defining the operations on (g2m_graph, mesh_graph, m2g_graph), while GraphCastNetERA5 defines the things somewhat specific to the workload like checkpointing, input/output conversions, etc.. In the longer term, I think it really could make sense to try to make things a bit more modular. In particular, this also includes things like "history" or the actual "prediction" mode, i.e. whether GraphCastNetERA5 predicts y_t = f(x_t-1) or y_t = x_t - 1 + f(x_t-1). It could make sense if the "backbone" is agnostic to these things while having a specialized prediction wrapper.

@mnabian Since you are revisiting GraphCast now, adding a few comments

Can we add the option to use transformer_engine.LayerNorm? In AIFS benchmarks, we just could get a 1.3x end-to-end improvement from doing so since the PyTorch implementation is rather bad for the sizes we encounter in these workloads.
Can you check whether the current combination of MeshGraphNodeBlock and MeshGraphEdgeBlock actually matches the paper (https://github.com/NVIDIA/modulus/blob/main/modulus/models/graphcast/graph_cast_processor.py#L97-L98) I created a schematic of the GraphCast architecture for some Arch folks last week, and I think the order of residuals over the edges does not match the paper here. I might have made a mistake when trying to use shared primitives here the last time. The issue here is that in MeshGraphNet, EdgeBlock already applies the "residual" on the edge features, while the NodeBlock would expect then the features including the residual connection prior to message-passing while in GraphCast, all residual connections are only applied after both the updated edge and node features are computed (at least according to the paper).
What would you think of splitting the GraphCastNet into a GraphCastNetERA5 and a GraphCastNet model? The current issue I see with GraphCastNet is that it is very specific to the nature of the ERA5 dataset (e.g. when it comes to preparing the input and output to switch between the HxW layout and the typical "serial" graph layout. GraphCastNet then could be a rather data-agnostic model defining the operations on (g2m_graph, mesh_graph, m2g_graph), while GraphCastNetERA5 defines the things somewhat specific to the workload like checkpointing, input/output conversions, etc.. In the longer term, I think it really could make sense to try to make things a bit more modular. In particular, this also includes things like "history" or the actual "prediction" mode, i.e. whether GraphCastNetERA5 predicts y_t = f(x_t-1) or y_t = x_t - 1 + f(x_t-1). It could make sense if the "backbone" is agnostic to these things while having a specialized prediction wrapper.

Thanks @stadlmax , I'll add your comments to my epic and consider them all.

Note to myself: API updates breaks GraphCast tests. Need to update them all.

@stadlmax as far as I remember, we were using fused layernorm and that gave us nice speedup (although I can't find it in the most recent code)... Did you also compare  transformer_engine.LayerNorm with fused layernorm?

@stadlmax as far as I remember, we were using fused layernorm and that gave us nice speedup (although I can't find it in the most recent code)... Did you also compare transformer_engine.LayerNorm with fused layernorm?

Yes, for AIFS, I found TE > APEX > PyTorch throughout a bunch of usual sizes AIFS had in their RFI benchmark. Especially the backward kernels in TE are much better for our cases. (reported numbers are runtimes, lower is better)
num_channels = 256

layer_norm_impl
1626240 x 256
327660 x 256
40962 x 256
542080 x 256
814540 x 256

apex
9.75127
2.03821
0.371149
3.32072
4.9402

pytorch
10.752
4.17265
0.957743
3.63721
10.2774

transformer_engine
2.59236
0.580879
0.801795
0.916124
1.33596

num_channels = 384

layer_norm_impl
1626240 x 384
327660 x 384
40962 x 384
542080 x 384
814540 x 384

apex
11.2164
2.3109
0.359366
3.79922
5.64847

pytorch
11.8419
4.33466
0.583828
3.99414
10.6802

transformer_engine
3.98762
0.849599
0.396184
1.38306
2.022

num_channels = 512

layer_norm_impl
1626240 x 512
327660 x 512
40962 x 512
542080 x 512
814540 x 512

apex
12.1739
2.50785
0.37578
4.11927
6.14573

pytorch
12.7752
4.5477
0.615464
4.30874
11.2191

transformer_engine
4.90182
1.04243
0.391352
1.6877
2.4967

@stadlmax as far as I remember, we were using fused layernorm and that gave us nice speedup (although I can't find it in the most recent code)... Did you also compare transformer_engine.LayerNorm with fused layernorm?

Yes, for AIFS, I found TE > APEX > PyTorch throughout a bunch of usual sizes AIFS had in their RFI benchmark. Especially the backward kernels in TE are much better for our cases. (reported numbers are runtimes, lower is better)
num_channels = 256
layer_norm_impl	1626240 x 256	327660 x 256	40962 x 256	542080 x 256	814540 x 256
apex	9.75127	2.03821	0.371149	3.32072	4.9402
pytorch	10.752	4.17265	0.957743	3.63721	10.2774
transformer_engine	2.59236	0.580879	0.801795	0.916124	1.33596
num_channels = 384
layer_norm_impl	1626240 x 384	327660 x 384	40962 x 384	542080 x 384	814540 x 384
apex	11.2164	2.3109	0.359366	3.79922	5.64847
pytorch	11.8419	4.33466	0.583828	3.99414	10.6802
transformer_engine	3.98762	0.849599	0.396184	1.38306	2.022
num_channels = 512
layer_norm_impl	1626240 x 512	327660 x 512	40962 x 512	542080 x 512	814540 x 512
apex	12.1739	2.50785	0.37578	4.11927	6.14573
pytorch	12.7752	4.5477	0.615464	4.30874	11.2191
transformer_engine	4.90182	1.04243	0.391352	1.6877	2.4967

This is great comparison, thanks! I'll switch to te then. Do we have any reason to still keep fused layernorm from apex, or we should just remove it?

This is great comparison, thanks! I'll switch to te then. Do we have any reason to still keep fused layernorm from apex, or we should just remove it?

I guess, no, not really. TE also should be decently covered when it comes to development specifically for Blackwell and beyond. I know a few POCs that try to optimize The LN in TE even further.
If we are based on the DLFW containers, TE also should come pre-installed.

@stadlmax added support for TE layernorm.

Note to myself: API updates breaks GraphCast tests. Need to update them all.

Done

/blossom-ci

/blossom-ci

/blossom-ci

/blossom-ci

/blossom-ci

/blossom-ci

Thanks for addressing the feedback, looks good to me.

/blossom-ci


Packaged Addons can't run on TF2-nightly if built against TF2-alpha

We're in the process of getting ready to release a 0.3 version, but there are several breaking changes in the tf2-nightly vs. tf2-alpha (as there should be).
To start the shared libraries are now named with versions and OS syntax. We can get around this by using the link flag that has now been added to tf.sysconfig though.
API changes are harder to work around. For example:  https://github.com/tensorflow/addons/pull/192 -- which means on the 0.3 release branch we'll need to roll-back some changes if we continue to build against tf2-alpha. I think this is the best course of action while we wait for a tf2-beta, but wanted to discuss.
We can also point users to this issue if they are building from source and running against tf2-alpha.
cc @karmel @martinwicke

We did make some tf.image name changes to eliminate duplicate "image"s.
In theory you could use a try block to ensure the code works for alpha and
nightly, which could be eliminated once the 2.0 is in RC (or beta) and
people stop caring about alpha0.
How much trouble would that be?
On Fri, Apr 19, 2019 at 6:09 AM Sean Morgan<EMAIL_ADDRESS>wrote:

We're in the process of getting ready to release a 0.3 version, but there
are several breaking changes in the tf2-nightly vs. tf2-alpha (as there
should be).
To start the shared libraries are now named with versions and OS syntax.
We can get around this by using the link flag that has now been added to
tf.sysconfig though.
API changes are harder to work around. For example: #192
https://github.com/tensorflow/addons/pull/192 -- which means on the 0.3
release branch we'll need to roll-back some changes if we continue to build
against tf2-alpha. I think this is the best course of action while we wait
for a tf2-beta, but wanted to discuss.
We can also point users to this issue if they are building from source and
running against tf2-alpha.
cc @karmel https://github.com/karmel @martinwicke
https://github.com/martinwicke
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tensorflow/addons/issues/193, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEM57L7B3A5YGY2AADC3ADPRHAB5ANCNFSM4HHEAO4Q
.

Now that we have nightlies being published, the recommended way to run against tf-nightly-2.0-preview is to use tfa-nightly
pip install tfa-nightly

Once we publish 0.4 we'll do our best to keep it compatible with tf2-nightly but that is not something we can guarantee.


add: ArkPool website link

I'd happy to merge this, but I found there website to be quite weird. Like there are spelling errors in the header and the navigation links aren't clickable. Can we be sure this the correct site? I think that's the reason the 'link' field is currently blank..
What do you think?

Hmm, I agree. The site looks pretty weird indeed.
At least btc.com links to them on their site: https://btc.com/stats/pool/ArkPool.
I'm not sure exactly how we can validate the authenticity of the site.

Closing this for now


GraphQL API error after upstream schema updates

Today all cirrun-run calls have started failing :
cirrus_run.api.CirrusAPIError: API returned 1 error(s):
[ { 'extensions': {'classification': 'ValidationError'},
    'locations': [{'column': 13, 'line': 2}],
    'message': 'Validation error of type FieldUndefined: Field '
               "'githubRepositories' in type 'Root' is undefined @ "
               "'githubRepositories'"}]

Most likely this is caused by backwards-incompatible changes to upstream GraphQL schema.
I haven't had a chance to look further yet.

Looks like CirrusCI moves to become platform agnostic. All 'github*' schema members have been renamed to 'owner*' counterparts. Call signature has also been changed to incorporate new 'platform' parameter:
Old:
type Root {
  viewer: User
  repository(id: ID!): Repository
  githubRepository(owner: String!, name: String!): Repository
  githubRepositories(owner: String!): [Repository]
  githubOrganizationInfo(organization: String!): GitHubOrganizationInfo
  build(id: ID!): Build
  searchBuilds(repositoryOwner: String!, repositoryName: String!, SHA: String): [Build]
  task(id: ID!): Task
  webhookDelivery(id: String!): WebHookDelivery
}

New:
type Root {
  viewer: User
  repository(id: ID!): Repository
  ownerRepository(platform: String!, owner: String!, name: String!): Repository
  build(id: ID!): Build
  searchBuilds(repositoryOwner: String!, repositoryName: String!, SHA: String): [Build]
  task(id: ID!): Task
  hook(id: ID!): Hook
  webhookDelivery(id: String!): WebHookDelivery
  persistentWorkerPool(poolId: ID): PersistentWorkerPool
  persistentWorker(poolId: ID, name: String): PersistentWorker
  ownerInfo(platform: String, uid: ID): OwnerInfo
  ownerInfoByName(platform: String, name: String): OwnerInfo
}

@sio I noticed this on Friday and didn't report it immediately in case it was a transient issue on Cirrus CI's part. I was going to report it now but I see you took care of everything already ;)
Can we expect a 1.0.1 release that includes this fix to land on PyPI soon?
Thank you for your continued work on cirrus-run :)

Thanks for the kind words :) Yes, I plan to see this through and publish v1.0.1 to PyPI then.

Looks like I jumped the gun a bit with closing this issue.
Even though the query affected by schema update works correctly now, cirrus-run still can not create new builds via GraphQL API. Another error has surfaced.
I've trimmed the issue down to a minimal reproducible example, but it seems that I will not be able to proceed without some help from CirrusCI staff. See upstream issue here: https://github.com/cirruslabs/cirrus-ci-web/issues/426

Internal server errors on API side have quietly disappeared today without any modifications on cirrus-run side.
I've just pushed v1.0.1, my pipelines are turning green one by one :)


the problem Zuul with oauth

i configure the zuul with @EnableOAuth2Sso.
and the ENV:

zuul service
A service
B service

now, the call chain is follow:
Browser -> Zuul -> A Service -> Zuul -> B Service
but, the last request Zuul forwad to B Service is unauthentication, so the call is failed.
does anyone know how to fix it!

Do you config  zuul.sensitiveHeaders: Cookie,Set-Cookie,Authorization

thanks a lot. i had fix it, i found the second request had been reset the context.


Testing Performance

When I test the ADEKChallenge2016 dataset and VOC2012 dataset, I find the result is bad ,how was your test result?

Hi, have a look at my fix  #7

Thanks! I will try ,but I have  a question, Why verification set data is resized and will affect the final result,

During training the CNN learn multiple features from the images it sees. When you use the openCV resize function it deform the image and the features learned during training are not the same so it cannot generalise. As an example if during training the CNN would have consider a small line to be a relevant feature, if the image is deformed (during validation) this line would not be a small line but let say a curved line and thus it would not be identified as a relevant feature by the CNN leading to bad performances

that's a question to ask to @aitorzip

@InstantWindy Hi I think you misunderstood the paper. Fig. 2 in paper doesn't mean shrinked image will be input directly, watch out the little words in the pic "share weights and computation". This means feature map is actuallly the input.


Repackage to hatch/pyproject.toml

See: https://github.com/pimoroni/boilerplate-python/issues/16
and: https://github.com/pimoroni/boilerplate-python/pull/13

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

15 of 16 (93.75%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.4%) to 58.209%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pa1010d/init.py
15
16
93.75%

Totals

Change from base Build<PHONE_NUMBER>:
0.4%

Covered Lines:
78

Relevant Lines:
134

💛  - Coveralls


can't find mosquitto patch

hi , I successfully  went done to Compile websockets module:  but cant pass Compile mosquitto module:  because there is no such directory or file , I might add mosquitto 1.4.11 with enable websocket  installed on this patch /etc/mosquitto/ and it hasn't SConstruct file
BR

same here

looked into /var/lib/mosquitto and /etc/mosquitto/ folders and couldnt find any sconstruct

try
cd /etc/mosquitto
then
sudo nano SConstruct
then copy paste the code into the new file

which leads to this:
scons: Reading SConscript files ...
File "/etc/mosquitto/SConstruct", line 1
else:

   ^

SyntaxError: invalid syntax


Add a compossible way to augment splash (addons?)

When trying to augment splash functionality from a scrapy middleware I found two problems:
Composability: When using scrapy middlewares, if two different scrapy middlewares want to extend splash by using lua code and the /execute endpoint the scripts will overwrite each other.
Verbosity: If you want to use a lua or content script you need to send it again for every request even if it's the same.
Here are a few solutions I can think of:

Keep splash like it is, provide some common libraries and modules in a separate repository.
The splash users can download them if they want and they would be pre-installed in the hosted splash version.
This would solve the verbosity problem and make it a bit easier on the composability one, since a most of the code could be sent as a lua module that it's loaded in the main script.

Allow "saving" and loading of splash scripts and content scripts.
You could send the same script once to splash and splash would cache it returning a reference to load it again
This would give problems when splash is behind a load balancer, I initially liked this option but the load balancer problem would be to complicated to get around.

Allow passing an array with several scripts as the lua_script parameter
The first scripts would do whatever they needed and typically the last one would load the page and return the response data.
This solves the composability problem but not the verbosity one.

Have "splash" addons. Addons would be lua files that would add some features. You select what addons you want to use by sending the names in a parameter.
This solves both the composability problem and the verbosity problem, but we still need to provide a library of addons.
There are two sub-options.

4a: Addons only work work in the /execute endpoint. This is my favourite option, it solves the problem without being excessively complicated.
4b: Addons work in every endpoint. I suspect this would be a pretty large rewrite of splash.

Some Ideas for addons/modules:

Crawlera addon
Page actions
localStorage shim

(1) Keep splash like it is, provide some common libraries and modules in a separate repository.

Sorry, could you please elaborate on how is it different from 4a?

(2) Allow "saving" and loading of splash scripts and content scripts.

This can be done in a way similar to redis EVAL / EVALSHA (http://redis.io/commands/EVAL): you send a script and get a hash back, then you can use this hash to preload the script. Splash checks if hash exists, and if script is not found it tells client to send the script again.
It is a solution to save network traffic without requiring an access to server.

(3) Allow passing an array with several scripts as the lua_script parameter

Isn't is the same as passing "\n".join(scripts)? If so, it can be a client-side solution.

(4) Have "splash" addons. Addons would be lua files that would add some features. You select what addons you want to use by sending the names in a parameter.

Currently you can create such "addons" as Lua modules (see http://splash.readthedocs.org/en/latest/scripting-tutorial.html#custom-lua-modules). They only work in /execute endpoint. Instead of auto-loading user must require them in a script explicitly. A module can provide a set of useful functions (like crawlera.enable()) or just execute some code as an import side effect. Is it what you want in 4a?

@kmike, just curious, when you use the /execute endpoint, do you typically create lua modules for your scripts? Or do you pass the script as a very long URL arg to Splash? I imagine the former is a better practice?

@AlexIzydorczyk at the moment I'm passing very long URLs, because of deployment reasons. Server-side scripts is a better practice, but they are harder to use if you have a shared Splash cluster for various tasks.

@kmike got it, that's where I'm at too. I have multiple jobs running on a Splash cluster and just have every individual request bring it's own script. Was just curious how you approached it.
The HAproxy config file was extremely helpful by the way, works very well.

The HAproxy config file was extremely helpful by the way, works very well.

Great! See also: https://github.com/TeamHG-Memex/aquarium (it is a workin progress though).

@kmike - very cool, interestingly enough, I've been working on something similar myself..  Many of these features don't fit into Splash itself but would work for this.
On a different note, who or what is TeamHG? I've and use a lot of TeamHG things (mostly found through the DARPA open source Memex page) that are very useful...

Feel free to contribute :) TeamHG means "Team Hyperion Gray"; see http://blog.scrapinghub.com/2015/02/24/memex/
@Youwotma sorry for having a chat here!
I guess the question is who can extend Splash with addons. If it is an user who runs Splash instance then we should make it easier to use server-side Lua modules (suggestions are welcome, my take on it was 'Custom Lua Modules' feature). If it is an user of Splash instance we should think of a way to make it easier to pass scripts (suggestions are welcome).
What I don't want to do is to make Splash stateful. An API where user can submit a script via HTTP and expect it to be persisted forever doesn't sound good to me because it requires a centralized storage, permissions control, etc.

@Youwotma see also: https://github.com/scrapinghub/splash/issues/143.

(1) Keep splash like it is, provide some common libraries and modules in a separate repository.

Sorry, could you please elaborate on how is it different from 4a?

In option 1 you still need to require the module in the lua script. In option 4a you pass a list of modules that will be loaded and do something without requiring to explicitly call them. On option one if two different scrapy middlewares want to load a different module they either overwrite each other or they need to use really ugly regular expressions to add code to the previous script.

(2) Allow "saving" and loading of splash scripts and content scripts.

This can be done in a way similar to redis EVAL / EVALSHA (http://redis.io/commands/EVAL): you send a script and get a hash back, then you can use this hash to preload the script. Splash checks if hash exists, and if script is not found it tells client to send the script again.

It is a solution to save network traffic without requiring an access to server.

Yes, that was my idea for implementing it too.

(3) Allow passing an array with several scripts as the lua_script parameter

Isn't is the same as passing "\n".join(scripts)? If so, it can be a client-side solution.

Yes, but different scripts would have different main methods. That way different scrapy middlewares could extend splash without overwriting each other (I'm always coming back to the scrapy middlewares example because there is where I noticed the problem)

(4) Have "splash" addons. Addons would be lua files that would add some features. You select what addons you want to use by sending the names in a parameter.

Currently you can create such "addons" as Lua modules (see http://splash.readthedocs.org/en/latest/scripting-tutorial.html#custom-lua-modules). They only work in /execute endpoint. Instead of auto-loading user must require them in a script explicitly. A module can provide a set of useful functions (like crawlera.enable()) or just execute some code (e.g. add a splash:on_request handler) as an import side effect. Is it what you want in 4a?

That would be option one, option 4a is auto-loading them so that you don't need to modify the existing lua_script.
Another way to help a

Addind another possibility to the list, how about allowing loading resources (like adblock lists, javascript profiles, lua scripts, lua modules and proxy profiles) by url? Sounds like it would be easy to implement and useful: you could use a public script on rawgit, the update URL of adblock lists, a javascript files on a public CDN or upload to s3 and pre-sign an URL.
Since this opens an attack vector (loading code from the internet) we could hardcode the hash of the files in the URL and make splash check it like this:
https://cdnjs.cloudflare.com/ajax/libs/jquery/2.1.4/jquery.min.js#md5=4a356126b9573eb7bd1e9a7494737410
This would make it easier to cache since now you only need to use the hash as the cache key and you don't need to follow all the rules of the cache-*, vary, expires, etc... headers

@Youwotma

adblock lists - the problem with them is that they may require quite a lot of RAM; we're compiling them to a single regex (to match efficiently), and this is also slow. So now it is done at startup; building 2-3 filter sets from EasyList may take several seconds. But it'd be nice to have better adblock filters support in Lua scripts, in this case you'd be able to load filters using splash:http_get and then use them.

javascript - there is splash:autoload, is there anything left to do?

proxy profiles - there is splash:http_get and request:set_proxy, do we need anything else?

lua modules - it worths trying;

lua scripts - what does it mean? load a module and execute it immediately?

@kmike
With lua scripts I was referring to what you pass in lua_source, and proposing adding an alternative lua_url parameter, with lua modules I was referring to stuff you require and proposing adding a require_url lua function.


Add simplePaginate() method

+1

Please add a simpelPaginate() method as soon as possible.

pagination follows the rules of  Laravel Scout, as this is a driver we have to subscribe to Scout scope


Cannot play same video widget on WEB

If you put the same video Widget more than one time and make them play programmatically, only the last starts playing the video
In Windows or Android it works fine.

Web browsers don't work like this.


datastore: don't require auth with local datastore server

Fixes #936
When a service object is created (such as a Dataset object), we have the choice of telling our "makeAuthenticatedRequestFactory" function that we don't care about the authentication part via an option called customEndpoint. A Dataset is the one place we use this option in the event a user is trying to communicate with their own Datastore server.
We were skipping the auth when:

A user instantiated a Dataset providing an apiEndpoint option:

var dataset = datastore.dataset({ apiEndpoint: 'http://localhost:8080' });

But, we also need to support when:

A user has the DATASTORE_HOST env var set

We have had half of the puzzle solved; we detect the presence of that env var and send the API requests to it accordingly. But, we forgot to update customEndpoint, the option that skips authenticating.
// @brainsiq

LGTM

:+1:


Error thrown when testing dropdown menu

Bug report
I've run into an issue when trying to test my dropdown component that uses @radix-ui/react-dropdown-menu as the base. The issue seems to be around the trigger element, when I try to mock a click event on it, it throws various errors. In my actual project, I get this error:
ReferenceError: DOMRect is not defined

and in the reproducible example, there is one error like so:
The provided value is not of type 'Element'.

and a bunch of stack traces in the console.
I ran into this error in my project after refactoring a fully custom-built dropdown to use the Radix base. Tests were passing before so I assume it's an issue with this component.
Current Behavior
Tests throw errors as soon as I mock a click event on the dropdown trigger

Expected behavior
No error to be thrown
Reproducible example
CodeSandbox Template
Your environment
  "dependencies": {
    "@radix-ui/react-dropdown-menu": "0.1.4",
    "@radix-ui/react-icons": "1.0.3",
    "@testing-library/react": "12.1.2",
    "@testing-library/user-event": "13.5.0",
    "react": "17.0.2",
    "react-dom": "17.0.2",
    "react-scripts": "4.0.0"
  },
  "devDependencies": {
    "@babel/runtime": "7.13.8",
    "@types/jest": "27.4.0",
    "typescript": "4.1.3"
  },

Hey @mrseanbaines,
This because test environments aren't always full representation of the the DOM/engine.
Have a look at this comment which should explain what you need to do: https://github.com/radix-ui/primitives/issues/420#issuecomment-771615182
Also, some other relevant threads on this search: https://github.com/radix-ui/primitives/search?q=DOMRect&type=issues
I'll close the issue for now, but feel free to keep discussing on it or re-open if you think I haven't addressed your concerns.
👍

Thanks @benoitgrelard! The solution you linked solved the issue.
I definitely did a little Googling before opening the issue but think I forgot to search the issues 🙈.


Numeric mask - Option to disable 'k' and 'm' key handlers

I have a lot of inputs on my forms with numeric (integer) input masks with auto group, and I just noticed that in v4 if i press 'k' then two zeroes, and when i press key 'm' 5 zeroes will be inserted to input. A property to disable this functionality would be great.
Or is there any option to turn this off which I didn't notice?

+1

I noticed the same thing and have not found an option to disable this yet. Let me know if you do!

I've modified the script internally at the company and removed this feature.

Could you advise how you fixed this issue, what did you change? I have version 4.0.6 and I noticed the same problem.

According to #1912 this is resolved in v5-beta.


about pre-trained model

Could you tell me about the pretrained Model?
How much time and what data set was used? and etc?
thank you.

Hi, it was trained on the 86 training tracks from the MUSDB18 dataset using 2 V100 GPUs. It was trained for 250 epochs which took about 2 days. You can check the hyperparameter settings in the train.py file (the defaults).


1.27.3 is available, please give feedback

The latest version available on bintray seems to be 1.25.0:stable. Is there a plan to upload the newer versions as well? The problem we are facing with 1.25.0 is mainly related to the openssl version (1.0.2t). Newer openssl versions (>1.1.0 I think) are incompatible due to some breaking changes.
Thanks in advance for your help!

You can see newer version branches on git, but they don't work for several reasons yet.
We need for example components support in the Conan CMake generator and adopt the abseil recipe accordingly. Newer grpc versions require abseil and individual abseil CMake targets.

Thanks for your fast reply!
Would it be an option for you to have a version of grpc 1.25 build with openssl 1.1.1 on bintray? I think the current one is based on openssl 1.0.2t which reach end of life at the end of 2019.

If this can be backported and CI succeeds I will accept a PR for it
PS: For the case that someone create a PR please target testing/1.25.0
https://github.com/inexorgame/conan-grpc/commit/f72a7c47b277845236949c5bc52896133c9ce053

Hey Croydon
I forked the repo and cherry-picked two of your commits to get to version 1.1.1g. Some of the tests in the CI fail but I am not really sure how relevant those are in the current state of the CI pipeline. Could you have a quick look at them?
https://github.com/motth/conan-grpc/tree/testing/1.25.0
As soon as the CI is fine I will create a PR.

The GCC 9 and XCode 11 failures because of missings prebuilds are tolerable.
XCode 9 is unsupported as this point, so does not matter to me.
However, Windows should not fail

I tried to figure out what the problem with the Windows tests is and noticed that the same tests already fail on stable/1.25.0 without any new commits.
https://ci.appveyor.com/project/motth/conan-grpc/builds/32976481
Any idea what the problem could be?

Hey @Croydon, any update on the issue with the Windows tests in the CI?

It would be nice to have this merged, since old ssl might become a blocker of keep using this package unfortunately

Hello Croydon.
How about this style recipe? https://github.com/ZCube/conan-grpc
This recipe includes protobuf and protoc_install.
The dependency is too difficult to separate protoc from protobuf.
When using gRPC, I don't think there will be too many cases of choosing a version other than the default protobuf.
So, it is easy to use by putting it all in one package.
like this.
# conan setup
include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup(TARGETS)
include_directories(${CMAKE_BINARY_DIR})

# find packages
find_package(protobuf CONFIG REQUIRED)
find_package(gRPC CONFIG REQUIRED)

# project setting
add_executable(greeter_client_server greeter_client_server.cc helloworld.proto)
target_link_libraries(greeter_client_server gRPC::grpc++_reflection gRPC::grpc++ protobuf::libprotobuf)
grpc_generate(TARGET greeter_client_server)

tested on 1.29.1 and 1.30.0-pre1.

The dependency on openssl 1.0.2t is a problem for me, also.  I'm still searching for a solution.

Hello,
is there any update on what is the status on new releases?

1.27.3 is now available in the Conan remote.
I haven't tested it with any real world project, so please report back if you do.  VS2015 and VS2019 also fail in CI while VS2017 works, which is rather odd.
In order to get a grpc recipe really mature we still need to get the protobuf+protoc recipe stable first and this requires still some work..

VS2015 + VS2019 binary packages are available now too. See #39

Somewhat ironic that people are constantly asking me on several platforms if there is any progress to report, but once there is there is radio silence 😄

Sorry for delayed reply, I am switching to 1.34 now. Will update if any issues

I tried building a 1.27.3 package on my machine, but I got the following:
Exporting package recipe
grpc/1.27.3@upc/master exports: File 'conandata.yml' found. Exporting it...
grpc/1.27.3@upc/master exports: Copied 1 '.yml' file: conandata.yml
grpc/1.27.3@upc/master: A new conanfile.py version was exported
grpc/1.27.3@upc/master: Folder: C:\Users\xxxxxxx\.conan\data\grpc\1.27.3\upc\master\export
grpc/1.27.3@upc/master: Using the exported files summary hash as the recipe revision: aaec5eab3a9710064000d8c70e9b484c
grpc/1.27.3@upc/master: Exported revision: aaec5eab3a9710064000d8c70e9b484c
Configuration:
[settings]
arch=x86
arch_build=x86
build_type=RelWithDebInfo
compiler=Visual Studio
compiler.runtime=MT
compiler.version=15
os=Windows
os_build=Windows
[options]
[build_requires]
[env]

abseil/20200923.3: Not found in local cache, looking in remotes...
abseil/20200923.3: Trying with 'conan-center'...
Downloading conanmanifest.txt completed [0.24k]
Downloading conanfile.py completed [6.99k]
Downloading conan_export.tgz completed [0.25k]
Decompressing conan_export.tgz completed [0.00k]
abseil/20200923.3: Downloaded recipe revision b2d602ea9f45c5bb738956d0f7aafa3d
grpc/1.27.3@upc/master (test package): Installing package
Requirements
    abseil/20200923.3 from 'conan-center' - Downloaded
    c-ares/1.15.0 from 'conan-center' - Cache
    grpc/1.27.3@upc/master from local cache - Cache
    openssl/1.1.1h from 'conan-center' - Cache
    protobuf/3.13.0 from 'conan-center' - Cache
    re2/20201101 from 'conan-center' - Cache
    zlib/1.2.11 from 'conan-center' - Cache
Packages
    abseil/20200923.3:33bc954080da4a576fa6b68c025ee043497105fd - Build
    c-ares/1.15.0:33bc954080da4a576fa6b68c025ee043497105fd - Cache
    grpc/1.27.3@upc/master:7c7f8defd91ce5526aeded87c3a54c72cfbff434 - Build
    openssl/1.1.1h:33bc954080da4a576fa6b68c025ee043497105fd - Cache
    protobuf/3.13.0:33bc954080da4a576fa6b68c025ee043497105fd - Cache
    re2/20201101:33bc954080da4a576fa6b68c025ee043497105fd - Cache
    zlib/1.2.11:33bc954080da4a576fa6b68c025ee043497105fd - Cache

Cross-build from 'Windows:x86_64' to 'Windows:x86'
Installing (downloading, building) binaries...
Downloading conan_sources.tgz completed [0.57k]
Decompressing conan_sources.tgz completed [0.00k]
abseil/20200923.3: Configuring sources in C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\source
Downloading 20200923.3.tar.gz completed [1742.17k]

abseil/20200923.3: Copying sources to build folder
abseil/20200923.3: Building your package in C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd
abseil/20200923.3: Generator cmake created conanbuildinfo.cmake
abseil/20200923.3: Calling build()
-- The C compiler identification is MSVC 19.16.27043.0
-- The CXX compiler identification is MSVC 19.16.27043.0
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Professional/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x86/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Professional/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x86/cl.exe - works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Professional/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x86/cl.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Professional/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x86/cl.exe - works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Conan: called by CMake conan helper
-- Conan: called inside local cache
-- Conan: Adjusting output directories
-- Conan: Using cmake global configuration
-- Conan: Adjusting default RPATHs Conan policies
-- Conan: Adjusting language standard
-- Looking for pthread.h
-- Looking for pthread.h - not found
-- Found Threads: TRUE
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    BUILD_TESTING
    CMAKE_EXPORT_NO_PACKAGE_REGISTRY

-- Build files have been written to: C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd
Microsoft (R) Build Engine version 15.9.21+g9802d43bc3 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

  Checking Build System
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/hash/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/base/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/time/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/base/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/numeric/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/flags/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/base/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/time/CMakeLists.txt
  city.cc
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/debugging/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/debugging/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/random/CMakeLists.txt
  spinlock_wait.cc
  commandlineflag.cc
  exponential_biased.cc
  civil_time_detail.cc
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/random/CMakeLists.txt
  log_severity.cc
  int128.cc
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/base/CMakeLists.txt
  time_zone_fixed.cc
  time_zone_format.cc
  time_zone_if.cc
  time_zone_impl.cc
  time_zone_info.cc
  time_zone_libc.cc
  time_zone_lookup.cc
  time_zone_posix.cc
  zone_info_source.cc
  randen_round_keys.cc
  leak_check.cc
  leak_check_disable.cc
  flags_commandlineflag_internal.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_flags_commandlineflag_internal.lib
  seed_gen_exception.cc
  strerror.cc
  city.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_city.lib
  random_internal_platform.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_random_internal_platform.lib
  log_severity.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_log_severity.lib
  exponential_biased.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_exponential_biased.lib
  leak_check_disable.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_leak_check_disable.lib
  leak_check.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_leak_check.lib
  civil_time.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_civil_time.lib
  int128.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_int128.lib
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/base/CMakeLists.txt
  spinlock_wait.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_spinlock_wait.lib
  random_seed_gen_exception.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_random_seed_gen_exception.lib
  strerror.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_strerror.lib
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/random/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/random/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/base/CMakeLists.txt
  raw_logging.cc
  randen_slow.cc
  randen_hwaes.cc
  periodic_sampler.cc
  time_zone.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_time_zone.lib
  random_internal_randen_hwaes_impl.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_random_internal_randen_hwaes_impl.lib
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/random/CMakeLists.txt
  random_internal_randen_slow.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_random_internal_randen_slow.lib
  randen_detect.cc
  raw_logging_internal.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_raw_logging_internal.lib
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/types/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/base/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/types/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/types/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/debugging/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/base/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/base/CMakeLists.txt
  periodic_sampler.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_periodic_sampler.lib
  bad_optional_access.cc
  bad_any_cast.cc
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/strings/CMakeLists.txt
  scoped_set_env.cc
  bad_variant_access.cc
  throw_delegate.cc
  cycleclock.cc
  spinlock.cc
  sysinfo.cc
  thread_identity.cc
  address_is_readable.cc
  unscaledcycleclock.cc
  elf_mem_image.cc
  vdso_support.cc
  random_internal_randen_hwaes.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_random_internal_randen_hwaes.lib
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/random/CMakeLists.txt
  ostringstream.cc
  utf8.cc
  escaping.cc
  randen.cc
  debugging_internal.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_debugging_internal.lib
  bad_optional_access.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_bad_optional_access.lib
  bad_any_cast_impl.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_bad_any_cast_impl.lib
  bad_variant_access.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_bad_variant_access.lib
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/debugging/CMakeLists.txt
  throw_delegate.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_throw_delegate.lib
  scoped_set_env.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_scoped_set_env.lib
  stacktrace.cc
  base.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_base.lib
  strings_internal.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_strings_internal.lib
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/base/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/debugging/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/strings/CMakeLists.txt
  random_internal_randen.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_random_internal_randen.lib
  low_level_alloc.cc
  demangle.cc
  ascii.cc
  charconv.cc
  escaping.cc
  charconv_bigint.cc
  charconv_parse.cc
  memutil.cc
  match.cc
  numbers.cc
  str_cat.cc
  str_replace.cc
  str_split.cc
  string_view.cc
C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\source_subfolder\absl\strings\internal\charconv_parse.cc(379): warning C4018: '>=': signed/unsigned mismatch [C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\source_subfolder\absl\strings\strings.vcxproj]
  C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\source_subfolder\absl\strings\internal\charconv_parse.cc(498): note: see reference to function template instantiation 'absl::lts_2020_09_23::strings_internal::ParsedFloat absl::lts_2020_09_23::strings_internal::ParseFloat<10>(const char *,const char *,absl::lts_2020_09_23::chars_format)' being compiled
C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\source_subfolder\absl\strings\internal\charconv_parse.cc(382): warning C4018: '>': signed/unsigned mismatch [C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\source_subfolder\absl\strings\strings.vcxproj]
C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\source_subfolder\absl\strings\internal\charconv_parse.cc(402): warning C4018: '>=': signed/unsigned mismatch [C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\source_subfolder\absl\strings\strings.vcxproj]
C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\source_subfolder\absl\strings\internal\charconv_parse.cc(416): warning C4018: '>=': signed/unsigned mismatch [C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\source_subfolder\absl\strings\strings.vcxproj]
C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\source_subfolder\absl\strings\internal\charconv_parse.cc(419): warning C4018: '>': signed/unsigned mismatch [C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\source_subfolder\absl\strings\strings.vcxproj]
  stacktrace.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_stacktrace.lib
  substitute.cc
  demangle_internal.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_demangle_internal.lib
  malloc_internal.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_malloc_internal.lib
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/synchronization/CMakeLists.txt
  graphcycles.cc
  strings.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_strings.lib
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/debugging/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/strings/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/time/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/random/CMakeLists.txt
  symbolize.cc
  arg.cc
  bind.cc
  extension.cc
  float_conversion.cc
  output.cc
  parser.cc
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/random/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/hash/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/strings/CMakeLists.txt
  discrete_distribution.cc
  gaussian_distribution.cc
  civil_time.cc
  clock.cc
  duration.cc
  format.cc
  time.cc
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/flags/CMakeLists.txt
  graphcycles_internal.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_graphcycles_internal.lib
C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\source_subfolder\absl\strings\internal\str_format\bind.cc(224): warning C4018: '>': signed/unsigned mismatch [C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\source_subfolder\absl\strings\str_format_internal.vcxproj]
  seed_material.cc
  hash.cc
  cord.cc
  commandlineflag.cc
  random_distributions.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_random_distributions.lib
  symbolize.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_symbolize.lib
  str_format_internal.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_str_format_internal.lib
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/flags/CMakeLists.txt
  time.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_time.lib
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\VC\VCTargets\Microsoft.CppBuild.targets(321,5): error MSB3491: Could not write lines to file "random_internal_distribution_test_util.dir\RelWithDebInfo\random_i.82629D1D.tlog\random_internal_distribution_test_util.lastbuildstate". The specified path, file name, or both are too long. The fully qualified file name must be less than 260 charact
ers, and the directory name must be less than 248 characters. [C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\source_subfolder\absl\random\random_internal_distribution_test_util.vcxproj]
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/debugging/CMakeLists.txt
  marshalling.cc
  hash.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_hash.lib
  flags_commandlineflag.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_flags_commandlineflag.lib
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/synchronization/CMakeLists.txt
  examine_stack.cc
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/flags/CMakeLists.txt
  private_handle_accessor.cc
  barrier.cc
  blocking_counter.cc
  create_thread_identity.cc
  per_thread_sem.cc
  waiter.cc
  notification.cc
  mutex.cc
  random_internal_seed_material.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_random_internal_seed_material.lib
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/random/CMakeLists.txt
  pool_urbg.cc
  examine_stack.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_examine_stack.lib
  flags_private_handle_accessor.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_flags_private_handle_accessor.lib
  cord.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_cord.lib
  flags_marshalling.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_flags_marshalling.lib
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/debugging/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/status/CMakeLists.txt
  failure_signal_handler.cc
  status.cc
  status_payload_printer.cc
  synchronization.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_synchronization.lib
  random_internal_pool_urbg.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_random_internal_pool_urbg.lib
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/flags/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/container/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/random/CMakeLists.txt
  program_name.cc
  hashtablez_sampler.cc
  hashtablez_sampler_force_weak_definition.cc
  seed_sequences.cc
  failure_signal_handler.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_failure_signal_handler.lib
  status.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_status.lib
  random_seed_sequences.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_random_seed_sequences.lib
  flags_program_name.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_flags_program_name.lib
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/status/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/flags/CMakeLists.txt
  hashtablez_sampler.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_hashtablez_sampler.lib
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/container/CMakeLists.txt
  statusor.cc
  usage_config.cc
  raw_hash_set.cc
  statusor.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_statusor.lib
  raw_hash_set.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_raw_hash_set.lib
  flags_config.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_flags_config.lib
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/flags/CMakeLists.txt
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/flags/CMakeLists.txt
  flag.cc
  reflection.cc
  flags_internal.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_flags_internal.lib
  flags_reflection.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_flags_reflection.lib
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/flags/CMakeLists.txt
  flag.cc
  flags.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_flags.lib
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/flags/CMakeLists.txt
  usage.cc
C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\source_subfolder\absl\flags\internal\usage.cc(148): warning C4018: '>=': signed/unsigned mismatch [C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\source_subfolder\absl\flags\flags_usage_internal.vcxproj]
  flags_usage_internal.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_flags_usage_internal.lib
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/flags/CMakeLists.txt
  usage.cc
  flags_usage.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_flags_usage.lib
  Building Custom Rule C:/Users/xxxxxxx/.conan/data/abseil/20200923.3/_/_/build/33bc954080da4a576fa6b68c025ee043497105fd/source_subfolder/absl/flags/CMakeLists.txt
  parse.cc
  flags_parse.vcxproj -> C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd\lib\absl_flags_parse.lib
abseil/20200923.3:
abseil/20200923.3: ERROR: Package '33bc954080da4a576fa6b68c025ee043497105fd' build failed
abseil/20200923.3: WARN: Build folder C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd
ERROR: abseil/20200923.3: Error in build() method, line 61
        cmake.build()
        ConanException: Error 1 while executing cmake --build C:\Users\xxxxxxx\.conan\data\abseil\20200923.3\_\_\build\33bc954080da4a576fa6b68c025ee043497105fd --config RelWithDebInfo -- /m:12 /verbosity:minimal

@floriansimon1 With the abseil changes merged, does it work now for you?

Nope, I now get the following errors:
$ conan create recipes/grpc/all/ grpc/1.27.3@test/testt
Exporting package recipe
grpc/1.27.3@test/testt exports: File 'conandata.yml' found. Exporting it...
grpc/1.27.3@test/testt exports: Copied 1 '.yml' file: conandata.yml
grpc/1.27.3@test/testt: The stored package has not changed
grpc/1.27.3@test/testt: Exported revision: 8192b718c9397033538910cbf8c0ae8d
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=Visual Studio
compiler.runtime=MD
compiler.version=16
os=Windows
os_build=Windows
[options]
[build_requires]
[env]

grpc/1.27.3@test/testt: Forced build from source
grpc/1.27.3@test/testt (test package): Installing package
Requirements
    abseil/20200225.3 from 'conan-center' - Cache
    c-ares/1.15.0 from 'conan-center' - Cache
    grpc/1.27.3@test/testt from local cache - Cache
    openssl/1.1.1h from 'conan-center' - Cache
    protobuf/3.13.0 from 'conan-center' - Cache
    re2/20201101 from 'conan-center' - Cache
    zlib/1.2.11 from 'conan-center' - Cache
Packages
    abseil/20200225.3:3fb49604f9c2f729b85ba3115852006824e72cab - Cache
    c-ares/1.15.0:95ac61b4b7e9e66bcc9af3260647ab977ee3250a - Cache
    grpc/1.27.3@test/testt:23d4a633468a5ff225c6d552e2682943aad34789 - Build
    openssl/1.1.1h:3fb49604f9c2f729b85ba3115852006824e72cab - Cache
    protobuf/3.13.0:3fb49604f9c2f729b85ba3115852006824e72cab - Cache
    re2/20201101:3fb49604f9c2f729b85ba3115852006824e72cab - Cache
    zlib/1.2.11:3fb49604f9c2f729b85ba3115852006824e72cab - Cache

Installing (downloading, building) binaries...
abseil/20200225.3: Already installed!
c-ares/1.15.0: Already installed!
c-ares/1.15.0: Appending PATH environment variable: C:\Users\xxxxxxx\.conan\data\c-ares\1.15.0\_\_\package\95ac61b4b7e9e66bcc9af3260647ab977ee3250a\bin
openssl/1.1.1h: Already installed!
protobuf/3.13.0: Already installed!
protobuf/3.13.0: Appending PATH environment variable: C:\.conan\2d29d34\1\bin
re2/20201101: Already installed!
zlib/1.2.11: Already installed!
grpc/1.27.3@test/testt: WARN: Build folder is dirty, removing it: C:\.conan\8c2076f\1
grpc/1.27.3@test/testt: Copying sources to build folder
grpc/1.27.3@test/testt: Building your package in C:\.conan\8c2076f\1
grpc/1.27.3@test/testt: Generator cmake created conanbuildinfo.cmake
grpc/1.27.3@test/testt: Generator cmake_find_package_multi created ZLIBConfigVersion.cmake
grpc/1.27.3@test/testt: Generator cmake_find_package_multi created ZLIBConfig.cmake
grpc/1.27.3@test/testt: Generator cmake_find_package_multi created ZLIBTargets.cmake
grpc/1.27.3@test/testt: Generator cmake_find_package_multi created ZLIBTarget-release.cmake
grpc/1.27.3@test/testt: Generator cmake_find_package_multi created OpenSSLConfigVersion.cmake
grpc/1.27.3@test/testt: Generator cmake_find_package_multi created OpenSSLTarget-release.cmake
grpc/1.27.3@test/testt: Generator cmake_find_package_multi created OpenSSLTargets.cmake
grpc/1.27.3@test/testt: Generator cmake_find_package_multi created OpenSSLConfig.cmake
grpc/1.27.3@test/testt: Generator cmake_find_package_multi created protobuf-config-version.cmake
grpc/1.27.3@test/testt: Generator cmake_find_package_multi created protobufTarget-release.cmake
grpc/1.27.3@test/testt: Generator cmake_find_package_multi created protobufTargets.cmake
grpc/1.27.3@test/testt: Generator cmake_find_package_multi created protobuf-config.cmake
grpc/1.27.3@test/testt: Generator cmake_find_package_multi created c-ares-config-version.cmake
grpc/1.27.3@test/testt: Generator cmake_find_package_multi created c-aresTarget-release.cmake
grpc/1.27.3@test/testt: Generator cmake_find_package_multi created c-aresTargets.cmake
grpc/1.27.3@test/testt: Generator cmake_find_package_multi created c-ares-config.cmake
grpc/1.27.3@test/testt: Generator cmake_find_package_multi created absl-config-version.cmake
grpc/1.27.3@test/testt: Generator cmake_find_package_multi created abslTarget-release.cmake
grpc/1.27.3@test/testt: Generator cmake_find_package_multi created abslTargets.cmake
grpc/1.27.3@test/testt: Generator cmake_find_package_multi created absl-config.cmake
grpc/1.27.3@test/testt: Generator cmake_find_package_multi created re2-config-version.cmake
grpc/1.27.3@test/testt: Generator cmake_find_package_multi created re2-config.cmake
grpc/1.27.3@test/testt: Generator cmake_find_package_multi created re2Targets.cmake
grpc/1.27.3@test/testt: Generator cmake_find_package_multi created re2Target-release.cmake
grpc/1.27.3@test/testt: Calling build()
CMake Error: The source directory "C:/.conan/8c2076f/1" does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.
grpc/1.27.3@test/testt:
grpc/1.27.3@test/testt: ERROR: Package '23d4a633468a5ff225c6d552e2682943aad34789' build failed
grpc/1.27.3@test/testt: WARN: Build folder C:\.conan\8c2076f\1
ERROR: grpc/1.27.3@test/testt: Error in build() method, line 120
        cmake = self._configure_cmake()
while calling '_configure_cmake', line 116
        cmake.configure(build_folder=self._build_subfolder)
        ConanException: Error 1 while executing cd C:\.conan\8c2076f\1\build_subfolder && cmake -G "Visual Studio 16 2019" -A "x64" -DCONAN_LINK_RUNTIME="/MD" -DCONAN_IN_LOCAL_CACHE="ON" -DCONAN_COMPILER="Visual Studio" -DCONAN_COMPILER_VERSION="16" -DCONAN_CXX_FLAGS="/MP12" -DCONAN_C_FLAGS="/MP12" -DCMAKE_INSTALL_PREFIX="C:\.conan\c27002d\1" -DCMAKE_INSTALL_BINDIR="bin" -DCMAKE_INSTALL_SBINDIR="bin" -DCMAKE_INSTALL_LIBEXECDIR="bin" -DCMAKE_INSTALL_LIBDIR="lib" -DCMAKE_INSTALL_INCLUDEDIR="include" -DCMAKE_INSTALL_OLDINCLUDEDIR="include" -DCMAKE_INSTALL_DATAROOTDIR="share" -DCMAKE_PREFIX_PATH="C:/.conan/8c2076f/1" -DCMAKE_MODULE_PATH="C:/.conan/8c2076f/1" -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY="ON" -DCONAN_EXPORTED="1" -DgRPC_BUILD_CODEGEN="ON" -DgRPC_BUILD_CSHARP_EXT="OFF" -DgRPC_BUILD_TESTS="OFF" -DgRPC_INSTALL="ON" -DgRPC_ABSL_PROVIDER="package" -DgRPC_CARES_PROVIDER="package" -DgRPC_ZLIB_PROVIDER="package" -DgRPC_SSL_PROVIDER="package" -DgRPC_PROTOBUF_PROVIDER="package" -DgRPC_RE2_PROVIDER="package" -DgRPC_BUILD_GRPC_CPP_PLUGIN="True" -DgRPC_BUILD_GRPC_CSHARP_PLUGIN="True" -DgRPC_BUILD_GRPC_NODE_PLUGIN="True" -DgRPC_BUILD_GRPC_OBJECTIVE_C_PLUGIN="True" -DgRPC_BUILD_GRPC_PHP_PLUGIN="True" -DgRPC_BUILD_GRPC_PYTHON_PLUGIN="True" -DgRPC_BUILD_GRPC_RUBY_PLUGIN="True" -DProtobuf_USE_STATIC_LIBS="ON" -Wno-dev C:\.conan\8c2076f\1

With this command line: $ conan create recipes/grpc/all/ grpc/1.27.3@test/testt


Alternative download source

Would you mind providing an alternative to the download from Playstore? I could think of at least 2 options:

providing the APK with the releases/ (you can simply attach it there, easy to do)
having it built by F-Droid (requires a flavor without Firebase/Crashlytics, which would be great anyway for those who mind being tracked)

Thanks in advance!

Good point, I think for now the way will be attach the production apk.
Create a flavor without google stuff would be nice, if you know very well how to do it you can open a PR.

Thanks a lot for the first part (please let me know when it's there). As for the second part: I'm no dev, so sorry I cannot make that PR.


Remove name and email from identify custom_attributes object, update …

@hankim813 Let me know what you think!

@brennan hey great job on the PR. I thought more about the impact of this though... and not sure if we want to do this. My reasoning is that even though we shouldn't have been sending semantic traits duplicately under custom_attributes, this is the current prod behavior and I'm afraid a lot of customers would have their reports broken if we stop sending email/name under both top level and inside custom attrs.
Also, is this change necessary to ship on the client side as well? From the looks of it, we don't even set custom_attributes so I'm wondering if this change would be nullified from the client side continuing to treat email/name as both top level and custom_attributes implicitly under the hood?
If you can confirm that sending traits.name and traits.email on the client side only updates the proper top level name and email fields inside Intercom UI, I think I'd feel much better shipping this for the server side.

Thanks, @hankim813! Just tested, and confirming that passing traits.name and traits.email on the client only updates the proper top-level name and email fields in Intercom's UI.

@brennan nice! yeah then im okay with shipping this :)
can you add a release commit on top of this?

bump package.json a patch version
update HISTORY.md
`$ git commit -m 'Release x.x.x'

Thanks!

@hankim813 Cool - just pushed the release commit!


Make a performance test runner!

Like this: 😄
https://www.armanbilge.com/react-angular-ember-elm-performance-comparison/

Done, it's part of tyrian-todo.


That's correct. \labmda_1 is for OT loss, \labmda_2 is for TV loss.

Hello, I used three different graphics cards to do a control experiment, and reproduced your results on rtx2080ti. Thank you very much for your help. I wish you a bright future

That's awesome! Thank you for letting me know!


[Github] fix: move label outside of button group

1. Why is this change necessary?
See https://github.com/shopware/shopware/issues/4932
2. What does this change do, exactly?
See https://github.com/shopware/shopware/issues/4932
3. Describe each step to reproduce the issue or behaviour.
See https://github.com/shopware/shopware/issues/4932
4. Please link to the relevant issues (if any).
https://github.com/shopware/shopware/issues/4932
5. Checklist

[x] I have rebased my changes to remove merge conflicts
[ ] I have written tests and verified that they fail without my change
[x] I have created a changelog file with all necessary information about my changes
[x] I have written or adjusted the documentation according to my changes
[ ] This change has comments for package types, values, functions, and non-obvious lines of code
[x] I have read the contribution requirements and fulfil them.

Imported from Github. Please see: https://github.com/shopware/shopware/pull/4934

[public] Shopware automated response: This issue is linked to the internal issue: NEXT-38761
[created from NEXT-38761, comment 501434]


rsync error.  you must have a tty to run sudo

I am running vagrant 1.6.2 on Centos 6.5.
I have following in my vagrantfile.
config.ssh.pty = true
config.vm.synced_folder "/vagrant", "/vagrant", disabled: false

I am getting following error.
sudo: sorry, you must have a tty to run sudo
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(600) [sender=3.0.6]
Is there a workaround?
Thanks

see posted issue above