1060 Duplicate Column Error since update to 8.5.1

Hi
I have done a composer update and laravel datatables updated to 8.5.1.
Most of my  queries are now throwing errors
[2018-05-14 02:10:43] LIVE.ERROR: PDOException: SQLSTATE[42S21]: Column already exists: 1060 Duplicate column name 'id' in /var/www/html/odie55/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:80
Stack trace:
#0 /var/www/html/odie55/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php(80): PDO->prepare('select count(*)...', Array)
Please can someone point me in the right direction
This Query causes an the above error ...
$icdcs = Icdc::leftJoin('locks as a1', function ($join) {
                $join->on('icdcs.id','=','a1.obid')
                  ->where('a1.appl',get_base_model('icdc')->id)
                  ->orWhere('a1.id',null);
                })
                ->Leftjoin('peops as a2', function ($join) {
                $join->on('a1.peop','=','a2.id')
                  ->where('a2.id','!=',null)
                  ->orWhere('a2.id',null);
                })
                ->leftJoin('pmbis as a3', function ($join) {
                $join->on('icdcs.id','=','a3.icdc')
                  ->where('a3.id','>',0)
                  ->orWhere('a3.id',null);
                })
                ->select('icdcs.id as id',
                        'icdcs.code as code',
                        'icdcs.desc as desc',
                        'icdcs.vald as vald',
                        'icdcs.valp as valp',
                        'icdcs.pmbi as pmbi',
                  DB::raw('icdcs.id, case when a1.id > 0 then concat("Locked by ",a2.name," at ",a1.created_at) else "" end as lockMess'),
                  DB::raw('icdcs.id, case when a3.id > 0 then "Yes"  else "No" end as pmbc'));
      return Datatables::of($icdcs)->make(true);

System details

UBUNTU 16.04
PHP 7.1
Laravel 5.5
Laravel-Datatables 8.5.1

Same issue here.

Hi ... yup ... done that .... what is the correct way to roll back ... I tried updating composer.json to use 8.5.0 and did a composer update, but nothing rolled back ... so in desperation I restored the yajra directory in vendor .... please advise
Regards
Arnold

Don't close the issue, it's still an issue.

BTW, can you please paste the generated queries so that we can pinpoint on what part the queries failed.

I just updated my project to 8.5.1 again, so that I can specify the issues a bit more.
My issue only persists on tables with complex queries, that use belongsToMany relations and so on.
SQLSTATE[42S21]: Column already exists: 1060 Duplicate column name 'created_at' (SQL: select count(*) as aggregate from (select * from `suppliers` inner join `supplier_manufacturer_to_meta` on `suppliers`.`id` = `supplier_manufacturer_to_meta`.`supplier_id` where `supplier_manufacturer_to_meta`.`meta_id` = 1) count_row_table)

@TheClassified thanks for the feedback. Were you able to test by removing join on the array list? Does it fixes your issue?

Hi
This is one of the failing queries .... In case you still need it
SQLSTATE[42S21]: Column already exists: 1060 Duplicate column name 'id' (SQL: select count(*) as aggregate from (select icdcs.id as id, icdcs.code as code, icdcs.desc as desc, icdcs.vald as vald, icdcs.valp as valp, icdcs.pmbi as pmbi, icdcs.id, case when a1.id > 0 then concat("Locked by ",a2.name," at ",a1.created_at) else "" end as lockMess, icdcs.id, case when a3.id > 0 then "Yes"  else "No" end as pmbc from icdcs left join locks as a1 on icdcs.id = a1.obid and a1.appl = 20 or a1.id is null left join peops as a2 on a1.peop = a2.id and a2.id is not null or a2.id is null left join pmbis as a3 on icdcs.id = a3.icdc and a3.id > 0 or a3.id is null) count_row_table)
Regards
Arnold

@arnoldjp57 thanks for the feedback. Will get back to this when I got the chance. I think making join as complex query should not cause an issue but it does. :)


[v1] Placeholder vanishes when filepicker opened, causing page reflows

When the filepicker is opened the placeholder vanishes, causing images without an explicit height (read: most images) to go height 0 and cause the page to reflow/jump about

Thanks to #48, this is now a visual bug, but not breaking - just looks a bit ugly while opening the filepicker, as the empty editor is visible

Closing in favor of #50


chore: Automated PR for VersionBump

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 79.609%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
2034

Relevant Lines:
2555

💛  - Coveralls

ps: useful to wait until sig release of the VHD (not the service) is done to merge this so folks developing off master in standalone have a good build


Add Matthias Evering as sponsor

Thanks @ewingson! <3
We'll add you to https://solidservers.org/#current-sponsors
There is a markdown problem there which happens on https://solidservers.org but not on https://github.com/solid-contrib/solidservers.org#current-sponsors which is rendered from the same markdown source. Will see if I can somehow fix that at the same time.


[AIRFLOW-1909] Update docs with supported versions of MySQL server

Also, updates a docs script to be compatible with both
Python 2 and Python 3.
Make sure you have checked all steps below.
JIRA

[x] My PR addresses the following Airflow JIRA issues and references them in the PR title. For example, "[AIRFLOW-XXX] My Airflow PR"

https://issues.apache.org/jira/browse/AIRFLOW-1909

Description

[x] Here are some details about my PR, including screenshots of any UI changes:

Update docs with supported versions of MySQL server
Update a docs script to be compatible with both Python 2 and Python 3.
Update a docs script to always serve the docs from the right directory regardless
of which directory the script was called from.

Tests

[x] My PR adds the following unit tests OR does not need testing for this extremely good reason:

Ran the docs build successfully.
Manually reviewed the documentation to make sure it looks fine.

Ran the python script for starting the server from various different directories and with Python 3.

Commits

[x] My commits all reference JIRA issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

[x] Passes git diff upstream/master -u -- "*.py" | flake8 --diff

Codecov Report

Merging #2869 into master will decrease coverage by 0.58%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #2869      +/-   ##
==========================================
- Coverage   73.96%   73.38%   -0.59%
==========================================
  Files         160      160
  Lines       12157    12179      +22
==========================================
- Hits         8992     8937      -55
- Misses       3165     3242      +77

Impacted Files
Coverage Δ

airflow/utils/db.py
37.5% <0%> (-49.11%)
:arrow_down:

airflow/hooks/dbapi_hook.py
76.31% <0%> (-9.65%)
:arrow_down:

airflow/hooks/base_hook.py
88.46% <0%> (-3.85%)
:arrow_down:

airflow/executors/dask_executor.py
79.06% <0%> (-2.33%)
:arrow_down:

airflow/models.py
86.93% <0%> (-0.55%)
:arrow_down:

airflow/configuration.py
84.97% <0%> (+0.96%)
:arrow_up:

airflow/bin/cli.py
54.92% <0%> (+1.18%)
:arrow_up:

Continue to review full report at Codecov.

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


Fixes theme switching in bridge-dapp

Summary of changes

Fixes theme switching issue in bridge-dapp by updating the useDarkMode hook.

Proposed area of change

[ ] apps/bridge-dapp
[ ] apps/stats-dapp
[ ] apps/webbsite
[ ] apps/faucet
[ ] apps/tangle-website
[x] libs/webb-ui-components

Reference issue to close (if applicable)

Closes #1220

Screen Recording
https://github.com/webb-tools/webb-dapp/assets/53374218/0e68b874-3f01-4f2e-a620-02b54fa2c3f8

Can we push this straight to master @devpavan04

@devpavan04 should be v0.0.9 bump - check master branch and releases.

@devpavan04 should be v0.0.9 bump - check master branch and releases.

Updated @dutterbutter 👍🏼


v-show conflicts with style display binding

Version
3.2.20
Reproduction link
codepen.io
Steps to reproduce
click changeStyle
What is expected?
style change and should keep element style "display: none;" attribute via v-show
What is actually happening?
The element is displayed even if v-show value is false.

causes by commit 3f38d599f5aacdd3eeaa9475251a24f74e7ae3b4 .
I understand it should be v-show control display and hide,  computed style control display style.

Oh right I confused these two issues. Seeing you have an idea how to solve #4759, we'll look at that.
I'll  hide the misleading comments here.

style

Yeah i know this, but we are talking about why the code behaves differently when written in different ways, right?


DynamicPin IO is very slow

I am trying to do some I2C bitbanging ( not really for 824 since it has enough ports ), I then need dynamic pins so that I can both read and write to the pins. The problem is that every set_high() & set_low() ends up calling into Register::new() which is a rather expensive function to call as it is 30+ instructions long with many writes to memory, This severely hampers the speed at which I can switch the gpio pins.  I am thinking that the Register block will be the same every time it is newed() and can be cached somehow ?

Hi @snakehand, thank your for opening this issue.
Are you compiling with --release? I always assumed that the compiler would optimize this out, but looking at the code again, I'm not sure that's right. Maybe adding an #[inline(always)] to Registers::new will help though.


Fix same site urls

I'm using locally downloaded livereload.js because sometimes I don't have internet access and 3.0.1 broke local urls. I'm getting message:
LiveReload disabled because it could not find its own <SCRIPT> tag

In 3.0.1 src attribute used to find script location, but we need to parse src attribute to find out explicitly written port 80 and src element property to work with same-site urls.

Great PR! Thanks!
I will release it soon.


Setup EDV Repos

https://github.com/decentralized-identity/edv-spec
https://github.com/decentralized-identity/edv-test-suite
https://github.com/decentralized-identity/edv-sample-implementation

This is now done.


Unknown IR type: Shading

Attach (recommended) or Link to PDF file here:
1.pdf
Configuration:

Web browser and its version: Google Chrome  97.0.4692.71
Operating system and its version: masOS Big Sur 11.01
PDF.js version: 2.6.347
Is a browser extension:

Steps to reproduce the problem:

pdfjs.getDocument(...).getPage(1)
2. page.getOperatorList()
3.pdfjs.SVGGraphics(page.commonObjs, page.objs)

What is the expected behavior? (add screenshot)
Normal operation
What went wrong? (add screenshot)
Error: Unknown IR type: Shading
Link to a viewer (if hosted on a site other than mozilla.github.io/pdf.js or as Firefox/Chrome extension):

PDF.js version: 2.6.347

That version is no longer supported, please find the latest releases at https://mozilla.github.io/pdf.js/getting_started/#download
Furthermore, as already mentioned in the FAQ, the SVG-backend is not officially supported; see https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions#backends

Duplicate of #8045


Are _keyword_map required for modflow6 classes?

In GitLab by @Huite on Apr 28, 2022, 17:24
At a glance now, it seems like they (sometimes) could be avoided by choosing different names in the jinja2 templates?

In GitLab by @Huite on Apr 29, 2022, 12:37
After some research: this is technically true. However, the name from the map is also used in generating the external mf6 files. Getting rid of the map would result in section names differing from the files. E.g.:
begin griddata
  alh
    open/close GWF_1/dsp/longitudinal-horizontal.bin (binary)
  ...
end griddata

I would prefer:
begin griddata
  alh
    open/close GWF_1/dsp/alh.bin (binary)
  ...
end griddata

As this is consistent. I think the best way to describe this approach is: within Python we try to strive for readable (if verbose) variables; outside of Python we try to strive for consistency.


Pock doesn't hide

Pock doesn't hide while double-press ^Control.
If i understood correct - on any screen, or application, if i double-press this shortcut - it hides Pock. But on my system - it's not truth.
MacOS version:
10.14.6

At morning - Pock working correctly. Why - i dont understand

I had exactly the same problem. I restarted the software after setting the 'double click' control option and that seemed to fix it.


NOISSUE - Add opc-ua type handling and unsubscription

Signed-off-by: Manuel Imperiale<EMAIL_ADDRESS>

Codecov Report

Merging #1029 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1029   +/-   ##
=======================================
  Coverage   79.75%   79.75%
=======================================
  Files          95       95
  Lines        6565     6565
=======================================
  Hits         5236     5236
  Misses       1017     1017
  Partials      312      312

Continue to review full report at Codecov.

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


ENH: Lower mem usage rfft

This PR, by using np.fft.rfft for filtering and resampling:

Reduces memory slightly
Should speed up filtering a little bit
Fixes some minor bugs with resample(..., window=<non-boxcar>)

Only reason it's not MRG is that I am not on a CUDA machine currently so can't see if that passes (though it should). @jona-sassenhagen if you are on a CUDA machine can you run pytest mne/tests/test_filter.py and let me know if it passes for you?

Hm ... it seems I broke my pycuda. Tensorflow still working, pycuda not so much. So far I haven't managed to repair it. Sorry.

Ok, I fixed it, I'll try ...

Here's my error log:
fft.txt
There's a few problems with the dimensionality of returned arrays.

Okay @jona-sassenhagen if you have a minute feel free to try again

Better :)
$pytest mne/tests/test_filter.py
================================================= test session starts =================================================
platform linux -- Python 3.6.6, pytest-3.7.1, py-1.5.4, pluggy-0.7.1
rootdir: /home/jona/tools/mne-python, inifile: setup.cfg
plugins: cov-2.5.1, hypothesis-3.59.1
collected 15 items

mne/tests/test_filter.py .s..........F..                                                                        [100%]

====================================================== FAILURES =======================================================
______________________________________________________ test_cuda ______________________________________________________

    def test_cuda():
        """Test CUDA-based filtering."""
         Once this is done I can move onto https://github.com/mne-tools/mne-python/pull/4119#issuecomment-412087576

I can't really review the code cause the math is too heavy for me ... but as you can see, it passes tests on my machine.

thx @larsoner !


update for 4.12 and MULTIARCH-2635

Addresses MULTIARCH-2635 Make OLM Label for Descheduler Policy for v4.12.0
Adds S390, ppc, and arm support to operator hub.
Signed-off-by: Chandrasekhar Bade<EMAIL_ADDRESS>

Reached out to @manojnkumar @jaypoulz in Slack to review on behalf of multiarch

/LGTM for master
Needs to be back-ported to the release-4.12 branch as well?

If you could also please update https://github.com/openshift/cluster-kube-descheduler-operator/blob/master/manifests/art.yaml#L10-L11 to:
    - search: 'olm.skipRange: ">=4.9.0 <{MAJOR}.{MINOR}.0"'
      replace: 'olm.skipRange: ">=4.9.0 <{FULL_VER}"'

/hold
Adding a hold flag to ensure we can control when it gets merged post updates and approval.

/LGTM

@chandra0007 would you please squash the commits before the final approval?

/approve
/lgtm

/unhold


[AutoDiff] Propagate @frozen attribute to TangentVector struct.

During Differentiable derived conformances, mark synthesized TangentVector structs as @frozen if the conforming type is @frozen.

Also @usableFromInline  :)

Also @usableFromInline :)

Done!

@swift-ci Please test tensorflow

@swift-ci Please test tensorflow

@swift-ci Please test tensorflow

@swift-ci TensorFlow commands appear broken. I've just emailed @shahmishal asking for help.
Locally verified that tests pass via ninja check-swift. Merging.


First step of adding nccl headers to the build.

I ended up reworking the CUDA toolkit download because we really need to full toolkit now (or at least more headers from it), and the support that was implemented had some issues.
I made it conditional to use an external toolkit if CUDAToolkit_ROOT is specified and download/use an internal toolkit otherwise. This is a change of behavior but probably reasonable: I've never had much success with the pure auto-detection without setting a CUDAToolkit_ROOT to a pre-installed version.
Just uses the nccl make machinery to auto-gen the header files and make them accessible. This may be overkill: it is just doing token replacement of some version bits. Open to feedback here.

I suspect that before landing this, I will need to make a corresponding change on the CI to include more of the toolkit.

Thanks for helping iterate on this - great cleanup!
I think we may have some larger implications coming along with nccl, though, that we'll have to work through. May be worth a gvc with you @mattwalsh and I to brainstorm.
One is that NCCL doesn't work on Windows, meaning that if we start to unconditionally use it we lose Windows support. I'm not a fan of that, obviously :P I think we may want a dedicated cmake configuration option for enabling NCCL (IREE_HAL_DRIVER_CUDA_NCCL or something?), and when not available we'd have fallbacks either at runtime or emitted in the compiler just as we need to do with other backends; so all-reduce would also emit a reduce and if NCCL wasn't compiled in or enabled at runtime it'd use that. There are people who have had it working under WSL (and others who haven't) and even some ports to Windows but having a clean way to disable it seems universally good regardless (and easier).
The other big one is that NCCL only supports CUDA static linkage (or dynamic but not via dlopen by way of CUDARTLIB https://github.com/NVIDIA/nccl/pull/220/files). That puts us in a weird situation as we use the driver API dynamically while NCCL uses the runtime API statically. Worse, it means we are violating ODR with any binary that embeds us and also uses NCCL. The implication there is that we need to be set up for users to specify the NCCL library instead of us using our own unless as a fallback for our own binaries - if we've got a submodule pinned to some version it's unlikely to match what the user has their version/system pinned to.
The static linkage and runtime API usage is rather unfortunate. If we're going to use NCCL it may radically change the way we have to integrate CUDA, and that's a little scary :(

Yeah, I was figuring it needed to be optional at some point which is why I have the c guard -- it is just unconditionally true now and could use a cmake flag instead if needed but I don't think we're going to need it. See below.
We can chat over VC, but I think I'm seeing something other than you about dynamic linking -- it looks ok to me. We're really only using the build time nccl hookup to reference the headers for enums/types/etc. I just hadn't typed in the actual trampoline.
Since it is just a header dep, I think I can just ifdef it out on windows -- no build goo needed. May not even need to do that since the headers should be fine on windows, but obviously it won't be possible to find at runtime.
I was thinking that we could have a hard switch when creating the driver: if you create with a "usenccl" or "ncclcommunicator", then we do all of the extra steps to initialize it, failing if not available. Then, yeah, generated code could switch in that somehow.

No, I was just going to dlopen the system one at runtime. I haven't had my coffee yet either so may be missing something, but this seems all set up correctly to do if I install the package or (as a user) build from source. Nccl dynamically links to the cudart (it can also statically link, but down that path lies madness for us).
Jax currently vendors a copy of nccl locally but I think they would like to change to what I'm proposing.

We only need the header for a handful of tiny enums - we should just replicate those and then we don't even need the header file. We can't use the function declarations in the header as we'll be dlsyming them so doing all this just to get 4 enums seems like overkill. This is what pytorch does: https://sourcegraph.com/github.com/pytorch/pytorch/-/blob/torch/csrc/cuda/nccl.h?L43
Here's what we need:
https://github.com/NVIDIA/nccl/blob/7aa1c46fd551d5514474cfc55848219dc67ca683/src/nccl.h.in#L35-L41
https://github.com/NVIDIA/nccl/blob/7aa1c46fd551d5514474cfc55848219dc67ca683/src/nccl.h.in#L105-L150
We'll be wrapping the results up in iree_status_t anyway and mapping from HAL buffer types to the nccl types, so they're going to be sequestered in a switch statement in some helper file anyway and we may as well just redefine what we need.
Alternatively given the size of the header (~350lines) and license (BSD) I think it could just get checked in under third_party/ to avoid cmake goo, but I think I'm happier to rewrite those enums if it saves us the submodule or extra external header and removes the confusion :)

Alternatively given the size of the header (~350lines) and license (BSD) I think it could just get checked in under third_party/ to avoid cmake goo, but I think I'm happier to rewrite those enums if it saves us the submodule or extra external header and removes the confusion :)

I'm confused about this bit. Wouldn't we still want to check this in under third_party/? Or do you mean that we just have a file containing a couple enums rather than copying the whole thing? Given that it's <400loc, that doesn't really seem worth it, but :shrug:

Yeah agreed, what we're talking about here is taken to its extreme effectively something like:
iree_status_t iree_hal_nccl_result_to_status(int result) {
  switch (result) {
    case /*ncclSuccess=*/0: return iree_ok_status();
    case /*ncclUnhandledCudaError=*/1: return iree_make_status(IREE_STATUS_FOO);
    ...
  }
}

(though we still probably want enums for readability - but the return codes are part of their API and we don't have to copy their code verbatim to have enums with the same values in our client code)

Hey @stellaraccident, the final piece of this is to enable CUDA by default.
Given this change, iis still relevant since this is changing the behavior of CUdA dependencies?

Hey @stellaraccident, the final piece of #8971 is to enable CUDA by default.
Given this change, iis still relevant since this is changing the behavior of CUdA dependencies?

I'd like to break just the CMake changes out of this PR and land them before enablind CUDA by default. I found and fixed a few  issues that I wouldn't want to inflict on others without this patch (i.e. it was re-downloading on every cmake invocation, and there was a lot of instability I witnessed in the detection).

Closing some old PRs. Looks like NCCL was added back in https://github.com/iree-org/iree/pull/11585.


Adding logic for UUID and friendly names

@begoldsm - The x-ms-client-name extension has been added to the schema. Re-running the CI against the updated schema, still resulted in a failure. Please  make sure that the CI passes.

closing this in favor of #193


Airdrop working handoff NOT

Please include the following information.

OS Version: 10.12
Mac model: iMac 27 mid 2011
Dongle or replaced card?: Both
Used dongle/card: Dongle: Asus BT400  Card: BCM94360CD

Your Issue:
I make a clean insatalation of Siera 10.12 and CAT gives me the report that continuity is working and nothing been changed.
I have a handoff option in system preferences from installation of Sierra.
If i install CAT with terminal with command sudo -a and then check system preferences I see that continuity is not compatible with bluetooth.
Airport with iPhone is working.
Steps done to try to fix the issue:

If I remove the dongle I have no bluetooth in Mac. it disappears from everywhere.
Original bluetooth card I removed before because CAT uses original bluetooth card instead of dongle.
Actually Handoff works from iMac to my MacBook Pro 2013, but when I try to open something via Handoff on iMac from MacBook weird things happend just open the blank window.


chatty API

Why is the python code so much smaller than the Java/C#? We should have similar (small) verbosity on all the platforms. I see no good reason not to create a nice DSL on top of the more verbose builders.
Example:
python code to read timeseries:
client = monitoring.Client()
metric = 'compute.googleapis.com/instance/cpu/utilization'
query_results = client.query(metric, minutes=5).iter(headers_only=True)
for result in query_results:
    print(result)

vs
java code to read timeseries
MetricServiceClient metricServiceClient = MetricServiceClient.create();
String projectId = System.getProperty("projectId");
ProjectName name = ProjectName.create(projectId);

// Restrict time to last 20 minutes
long startMillis = System.currentTimeMillis() - ((60 * 20) * 1000);
TimeInterval interval = TimeInterval.newBuilder()
    .setStartTime(Timestamps.fromMillis(startMillis))
    .setEndTime(Timestamps.fromMillis(System.currentTimeMillis()))
    .build();

ListTimeSeriesRequest.Builder requestBuilder = ListTimeSeriesRequest.newBuilder()
    .setNameWithProjectName(name)
    .setFilter("metric.type=\"compute.googleapis.com/instance/cpu/utilization\"")
    .setInterval(interval)
    .setView(ListTimeSeriesRequest.TimeSeriesView.HEADERS);

ListTimeSeriesRequest request = requestBuilder.build();

PagedResponseWrappers.ListTimeSeriesPagedResponse response = metricServiceClient
    .listTimeSeries(request);

System.out.println("Got timeseries headers: ");
for (TimeSeries ts : response.iterateAll()) {
  System.out.println(ts);
}

@garrettjonesgoogle @jabubake PTAL

@balopat this is a matter of trade-offs. The Python client here has hand-written code to make common tasks easier. The Java client is purely auto-generated with no such helpers. The Python client is more expensive to maintain; the Java client is much cheaper - we just have to regenerate anytime the protos change. So that's the basic reason: available resources to work on it.

That being said : I still think its worth thinking of how we could simplify some of the generic statements here, which might be applicable across multiple libraries.
Constructing a resource  ProjectName with the projectId : comes up for Pub/Sub as well.
It would be good to users to provide projectId if required, and allow for the generated code to autodetect projectId with ServiceOptions.getDefaultProjectId().
String projectId = System.getProperty("projectId");
ProjectName name = ProjectName.create(projectId);

A TimeInterval helper which can possibly provide a start/end time and duration, so this amount of code does n't become necessary.
Java users are used to simpler ways of building time intervals like here.
// Restrict time to last 20 minutes
long startMillis = System.currentTimeMillis() - ((60 * 20) * 1000);
TimeInterval interval = TimeInterval.newBuilder()
    .setStartTime(Timestamps.fromMillis(startMillis))
    .setEndTime(Timestamps.fromMillis(System.currentTimeMillis()))
    .build();

@garrettjonesgoogle thank you for the response. I think that it would be very beneficial to invest into this extra layer:

we can fine tune for better user experience and achieve greater adoption
if the protos change, that doesn't necessarily mean that the API has to change! the current way means that introducing a typo change or rename in a proto field will definitely generate breaking changes in client code, whilst with an extra layer we can protect against that too to a certain extent

It is true that we can fine tune APIs, but the maintenance burden is 10x that of auto-generated libraries. I'd rather look at what kind of specialized code generation we could do to reduce the pain some, even if it isn't completely solved.
Our policy is to count proto field renames as breaking changes. API owners need to take that into account and not rename fields after their API has become GA.

@garrettjonesgoogle : I agree, that's why I think its worth investing into efforts that span multiple APIs (possibly @ code generation) : time interval concept should not be so complicated to the end user, user's code should n't have to be littered with project-name based resource objects. See issue on Color here.

Okay, thanks for the input, I'll try to think about it in automation ways then when I run into inconvenient APIs. I put in another example issue #2333 where the protobuf driven API is a bit confusing for a new user.

So with there being two issues now (the present one and #2333 ), what should be the focus of the present one?

I looked at the Java code in more detail, and there are some places where the sample itself is more verbose than necessary, which exaggerates the differences between Python and Java. I think the following Java sample makes a fairer comparison:
MetricServiceClient metricServiceClient = MetricServiceClient.create();
String projectId = System.getProperty("projectId");
ProjectName name = ProjectName.create(projectId);

// Restrict time to last 20 minutes
long startMillis = System.currentTimeMillis() - ((60 * 20) * 1000);
TimeInterval interval = TimeInterval.newBuilder()
    .setStartTime(Timestamps.fromMillis(startMillis))
    .setEndTime(Timestamps.fromMillis(System.currentTimeMillis()))
    .build();

ListTimeSeriesRequest request = ListTimeSeriesRequest.newBuilder()
    .setNameWithProjectName(name)
    .setFilter("metric.type=\"compute.googleapis.com/instance/cpu/utilization\"")
    .setInterval(interval)
    .setView(ListTimeSeriesRequest.TimeSeriesView.HEADERS)
    .build();

for (TimeSeries ts : metricServiceClient.listTimeSeries(request).iterateAll()) {
  System.out.println(ts);
}

It looks like this has answered the original question, acknowledging that it is still not as concise the as the Python. Please reopen or create a new issue if there is further iteration required.


Feat(eos_cli_config_gen): Add 'route_reflector_client' key to BGP neighbor in VRF

Enhancement summary
Currently this is only supported at peer-group level and global neighbor level, but not under a VRF.
Which component of AVD is impacted
eos_cli_config_gen
Use case example
Configure a BGP neighbor as a route reflector client inside a VRF
Describe the solution you would like
The following key added to the BGP neighbors data model under VRF:
route_reflector_client: < true | false >

Describe alternatives you have considered
eos_cli for BGP VRF
Additional context
No response
Contributing Guide

[X] I agree to follow this project's Code of Conduct

I can work on a PR for this


Homeseer WD200+ dimmer not providing updates to MQTT topics on change

Describe the bug
When setting the changeValue topic with MQTT to turn on/off or set dim level the light changes to the correct setting but the MQTT topics currentValue and targetValue never get updated.
Discussion of issue: https://zwave2mqtt.slack.com/archives/C01DQ24SDKL/p1610818512273700
It looks like SupervisionCCReport command is failing in the zwave logs.
Device information
Which device(s) is/are affected (make/model)?  Homeseer WD200+
What are the node IDs? 22
Last Known Working Configuration

[ ] New device

[ ] Previously working device (node-zwave-js)

Which library version/docker image/adapter version?
Have you made any recent configuration changes to the device? Describe.

[X] Previously working device (other platform)

Which platform? zwave2mqtt/HA Native Zwave
Have you made any recent configuration changes to the device? Describe.

Installation information
How did you install node-zwave-js?

[X] Zwavejs2mqtt (latest) docker image
[X] Zwavejs2mqtt (dev) docker image
[ ] ioBroker.zwave2 adapter
[ ] Pkg
[ ] Manual docker build

Against which branch of node-zwave-js?
With which branch of zwavejs2mqtt?

[ ] Other (describe)
[ ] Manually built (git clone - yarn install - yarn run build:full)

To Reproduce
Steps to reproduce the behavior:

issue:  z2m/nodeID_22/38/0/targetValue/set to 0
light turns off, but MQTT targetValue and CurrentValue do not get updated with a new timestamp or value.
issue:  z2m/nodeID_22/38/0/targetValue/set to 50
light is set to dim level of 50, but targetValue and currentValue do not get updated with a new timestamp of value.

Logfile:
zwavejs_1_WD200_LightOn.log

Please test https://github.com/zwave-js/node-zwave-js/pull/1453

Please test https://github.com/zwave-js/node-zwave-js/pull/1453

@AlCalzone #1453 did not solve this issue.   Looking at new zwavejs logs it is the same message at the end after an update:
19:25:51.271 SERIAL « 0x010d00040016056c02070000d50059                                    (15 bytes) 19:25:51.271 SERIAL » [ACK]                                                                   (0x06) 19:25:51.272 DRIVER « [Node 022] [REQ] [ApplicationCommand]                       └─[SupervisionCCReport]                           session id:          7                           more updates follow: false                           status:              NoSupport                           duration:            [Duration: 0seconds]

@AlCalzone #1453 did not solve this issue.   Looking at new zwavejs logs it is the same message at the end after an update:
19:25:51.271 SERIAL « 0x010d00040016056c02070000d50059                                    (15 bytes) 19:25:51.271 SERIAL » [ACK]                                                                   (0x06) 19:25:51.272 DRIVER « [Node 022] [REQ] [ApplicationCommand]                       └─[SupervisionCCReport]                           session id:          7                           more updates follow: false                           status:              NoSupport                           duration:            [Duration: 0seconds]

Oh, right - I just skimmed through the issues with the polling support label.

Oh, right - I just skimmed through the issues with the polling support label.

@crzykidd It might be that the device in question has a firmware issue. I would like to ask Homeseer about this, but I'll need another log that includes the entire interview process as well as a switching attempt.
You can do that by clicking refresh info in the dashboard while the log is active.

@crzykidd It might be that the device in question has a firmware issue. I would like to ask Homeseer about this, but I'll need another log that includes the entire interview process as well as a switching attempt.
You can do that by clicking refresh info in the dashboard while the log is active.

@AlCalzone I am attaching new logs.   zwavejs_1.log has node 22 which is the Homeseer WD200+ from zwavejs2mqtt.    For comparison since the switches seem to be working fine in OZW with zwave2mqtt, I am attaching a log for that as well in OZW_log.txt   The switch in question in this log is node003.
OZW_Log.txt
zwavejs_1.log

@AlCalzone I am attaching new logs.   zwavejs_1.log has node 22 which is the Homeseer WD200+ from zwavejs2mqtt.    For comparison since the switches seem to be working fine in OZW with zwave2mqtt, I am attaching a log for that as well in OZW_log.txt   The switch in question in this log is node003.
OZW_Log.txt
zwavejs_1.log


[Android Agent] Remote wipe is not working for BYOD devices

Description:
Device wipe is not working for Android BYOD devices.
Affected Product Version:
Agent 3.1.21
Steps to reproduce:

Enroll android device as a BYOD device.
Trigger remote wipe operation.

Expected: Device being wiped
Actual: Operation returns completed status without wiping the device.

Closing as issue is fixed and changes are merged with PR https://github.com/wso2/cdmf-agent-android/pull/119


Heathens - Twenty One Pilots

Song Name
Heathens - Twenty One Pilots
Artist Name
Twenty One Pilots
Source
Youtube
Youtube Link
Ei5DPvQdETpqHqZN
Direct File Link
No response
Song ID
749713
Start Offset [ms]
0
Extra
Created from Auto Nong.
Created for level: 107380822

reject
invalid YouTube link


lazy pre loading for images only works with an integer as 'slidesPerView'

This is a (multiple allowed):

[x] bug

[ ] enhancement

[ ] feature-discussion (RFC)

Swiper Version: 4.3.5

Platform/Target and Browser Versions: all

Live Link or JSFiddle/Codepen or website with isssue: http://www.plnkr.co/edit/twdgGAkupDrZkaKM7QNr

What you did
I'm displaying 1.2 (one slide is completely shown, the next slide on the right slide only partially) lazy loaded images, but I want the next/prev images to be loaded before they are shown in the viewport.
    var swiper = new Swiper('.swiper-container', {
      // Enable lazy loading
      lazy: {
        loadPrevNext: true
      },
      pagination: {
        el: '.swiper-pagination',
        clickable: true
      },
      navigation: {
        nextEl: '.swiper-button-next',
        prevEl: '.swiper-button-prev'
      },
      // does not preload images, if this value includes a comma
      // with e.g. 2 it works
      slidesPerView: 1.2
    });

If you change the value of slidesPerView to 2 everything works as expected.
Expected Behavior
When the first 1.2 images are shown, the 3rd image should already be loaded.
Actual Behavior
When the first 1.2 images are shown and is is swiped to image 2 the 3rd image just begins to load.
Best regards,
Reinhard

+1 I´ve got the same issue.

same here

Has somebody found any possible solution so far? Or can you direct me where there might be the problem, so I can fix that myself?

Same issue here, I need to use slidesPerView: 'auto' because I have variable width slides, but lazy loading only loads the first 2 slides and then 1 slide every time you swipe forwards. I've tried using watchSlidesProgress: true, watchSlidesVisibility: true, observer: true, observeSlideChildren: true and swiper.update() but the issue persists.


Adding account to a duplicated network

While investigating #371 I also found that adding two networks with different names but the same host is allowed, and apparently the one that comes last alphanumerically is used when you try and add an account for either of them.

The fact, that two networks with the same host are allowed, is by design. This could allow you to separate messages, received by different accounts...
I will test a problem with account addition.

I just tested this case using AndStatus v.27.04 - no problems found.
I created additional "Quitter.se2" network, which duplicates hostname of  "Quitter.se" and was able to create accounts in any of them. Moreover, I could create account of the same user in these two networks ("yvolk"), see the screenshot.


Using API Host in the swagger file appends a trailing slash in the operation definition

When using redoc-cli bundle with a swagger file containing host: example.com. The bundled package adds a trailing slash to all paths. Example, host is defined as example.com, and a snippet of index.html would be
https://example.com//api/v2/registration resulting in the operation definition looking like https://example.com//api/v2/registration.
Thanks for any insight!

Dup of #912


Changes to package after JOSS review 1

Thanks to @robaina for suggesting these changes!

Fixes advanced examples notebook (#154)
Adds contributing.md (#158)
Adds bioscrape simulation comparison (#159)

Working on the macos py 3.10 issue..

Hey @ayush9pandey ,
These changes look awesome. Thanks for addressing these issues and congrats on bioscrape performance (I somewhat was expecting MATLAB to be slower but not that slow, thanks we have open source projects :D)

Changing python setup.py install to pip install . fixed the testing issue. Setuptools is deprecated now and we should move to the new way of installing packages. Raised an issue #161


Can't make Pull Request

I wanna make some refactor, for exemple tabulation, better structures of foleds and try to add some other exemples but cant do any PR.
Check if able to make it.

Hi @MoONStterTeixi, it's my first time seeing that prompt for public repositories but may I know what happens when you click the Fork this repository button?

Sorry sir,
Im new too collaborating.
I will hope u see well my PR.
Have a great day.


[Event Request] codeunit 5943 Lock-OpenServContract- Function LockServContract

Dear ALAppExtensions Team,
We would like to request the following event publisher in codeunit 5943 function LockServContract, of course without the prefix DIN.
        if "Annual Amount" < 0 then
            Error(Text003);
        // DINNL <<
        DINOnAllowServiceContractsWithZeroAmount(DINIsHandled);
        if not DINIsHandled then
        // DINNL >>
        if IsInvoicePeriodInTimeSegment() then
            if "Annual Amount" = 0 then
                Error(Text004);

local procedure DINOnAllowServiceContractsWithZeroAmount(var IsHandled: Boolean)

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


Adding Test Coverage to Positions Math

When switching shares from NO -> YES or YES -> NO, there needs to be:

Force selling opposite shares held.
Must be a negative / selling transaction showing up on record (actual sell function used).
Test coverage

This specific branch is building toward that whole fix, working on adding test coverage to the positions functionality which is used within selling.

Tests added are passing but not necessarily good at this point...I would like to go back in to the math document so I can use this to make sure the tests are sufficiently robust and make sure the math documentation matches our functionality.

To Do:

Ideally, we should implement banker's rounding to accurately reflect our math documentation.
We need to deal with the divide by zero / infinity case in the situation where all shares from a market have been sold and WPAM goes back to 0.5, but the normalization factor gets calculated as infinity.
We should probably implement the scenarios laid out in our mathematical documentation in terms of trades and subsequent calculations to be more demonstrative. Hypothetically if further problems are found in the software, we can add additional test cases.
Payout of initial market subsidy after final resolution can be done in a different ticket (placing in v0.0.4).

We'll do banker's rounding in a different ticket. https://github.com/orgs/openpredictionmarkets/projects/4/views/1?pane=issue&itemId=87892514
Need infinity avoidance in normalization calculation.


Automated way of cluster setup added

With the purpose of easier deployment of libvirt-coreos Kubernetes cluster with the default settings, the way of installing using the automated script from https://get.k8s.io/ has been added.

@johndmulhausen - should I create a new PR with the described fixes or I have possibility to fix in an existing one?
Thank you.

Hi @idvoretskyi, apologies I missed your question. You can reuse this PR! When you created this PR, it also created a fork of our repo, which is your copy to play with. Just address any issues and make any changes in this copy and this PR will be automatically updated. :)
https://github.com/idvoretskyi/kubernetes.github.io

@johndmulhausen thank you for your recommendations, I've updated the PR.

I tried the commands myself and was successful so I'm calling that a good tech review. :)


Skip validation of unspecified response codes.

I might be wrong on this, but if I read the swagger specification right, there is no need to specify every possible response nor to define a default. In my particular case status code 304 was not given in the swagger document but the validator was still trying to operate on an undefined response schema (object).

Just to make sure I understand, this patch will make it so that for responses where there is no response code, we do not attempt to do response validation.  Is this correct?
I'm on the fence about this one.  If your API does in fact return a status code, it is part of your API and should be documented.  But since Swagger does not force it up on you, the safe bet is probably to just skip validation for responses that are not defined in Swagger.
Works for me but if you don't mind writing a unit test for this, that would be great.

+1 on this
Validation of unspecified schemas is an information leakage security threat. Imagine the following:

a required parameter is defined in the Swagger API specs
the client does not provide the parameter. That will very likely happen, and we can't do anything against it
the API developer forgot to add a default catch-all response code

Now the Swagger request validation notices the missing parameter and sets the status code to 400 Bad Request. But because of the missing default response schema, Swagger will run into a NullPointerException while trying to validate the response.
This exception is sent back to the client and leaks sensitive information such as path names of the active deploy.
An alternative to just skipping validation on unknown status codes (which could possibly send unintended data to a client) would be responding with an error object like such:
{
    message: 'Response validation failed: no validation schema available'
}

This would enforce specifying at least default catch-all response schemas and provide meaningful information for a developer in case he forgot to do so (which I did, leading me to this pull request....)

@whitlockjc I finally got around adding the test case you asked for. Sorry that this took so long...

I'll merge this and fix since I've been hacking swagger-tools a bit and I'm sure diffs won't align.  I think this will also fix #232.

@jlauinger Leaking paths names is not necessarily part of swagger-tools.  The error stack has those values and it's up to you to use/present/prune them.

I manually merged this and linked this PR in the commit message.

thank you :sparkles:


Fix github action due to org change.

Pull Request Test Coverage Report for Build 786852370

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 37.077%

Totals

Change from base Build 786834250:
0.0%

Covered Lines:
340

Relevant Lines:
917

💛  - Coveralls


Add a NgTableParams setting to modify the default "-" value for SELECT filters

Adds a "defaultSelectValue" setting to override the default value of "-" on filters that use a SELECT element, specified when creating new NgTableParams.
e.g.
var myTableParams = new NgTableParams({
    // params
}, {
    defaultSelectValue: 'Show all'
});

Hi Jonathan, thanks for the pull request. I'm helping out where I can on the repo.
Now, just be warned things are running much slower than I'm sure everyone would like on ngTable, So I'm not sure how long it will take for your pull request to be reviewed.
I would like to look into this myself but I might not get the chance. My priority is to get full coverage for the documentation of the existing features first.
C

So as far as I understand it, the desired behaviour for using an option list is demonstrated below.
That is NOT what we're currently getting. At the moment the select list has both an empty option plus a "-" option. That's quite poor.
To get the behaviour below - specifically the list showing a single empty option, I had to make a couple of small changes.
I think this is a preferable solution than having an option that says "please select" or "-" or any variation.
So I'm going to push that my change instead.
Desired behaviour
1. Initial load of table

2. Picking an item from the list

3. After selecting an item

4. About to remove the previous selection

5. After previous selection removed

BTW, here's the commit that closes this pull request: https://github.com/esvit/ng-table/commit/1ee441bebf3e1f8fac260a38b8b82122714191d2


pygit2: resolve_rev raise a proper exception with ~<n> like referen…

fix: #30
Current pygit2 backend's resolve_rev didn't raise a proper exception when dealing with
HEAD~n like references.

Catch the exception in resolve_rev and reraise it into a proper format.
Add a test for it.

In resolve_refish both HEAD~n like references and non-exist references raise a ValueError, can't distinguish them. And I don't think we should let Inner exception InvalidSpecError be thrown outside of scmrepo. But this method is a relatively slow one, because we need to iter over all of the remotes.

I'm still confused as to why this PR is needed, since exp show -n ... and pygit resolve_rev(f"HEAD~{n}") worked prior to the recent refactors. It seems like this might need some more investigation into why resolve_rev started failing here (since the exception was not raised at all before)

I'm still confused as to why this PR is needed, since exp show -n ... and pygit resolve_rev(f"HEAD~{n}") worked prior to the recent refactors. It seems like this might need some more investigation into why resolve_rev started failing here (since the exception was not raised at all before)
Is the issue that the exception is raised when n is invalid (and that relative commit does not actually exist)? Or that it is still raised when HEAD~n points to a valid commit (and that the problem is with using ~ at all)?

It raises when n is invalid, I add two test cases here.
    assert git.resolve_rev("HEAD~1") == init_rev # this is valid , and works pretty fine in previous.

    with pytest.raises(RevError):
        git.resolve_rev("HEAD~3") # in this case, the previous version will raise `InvalidSpecError` instead of `SCMError`

In the previous version of DVC, if we input an invalid number of n, it will raise an unexcepted error.
$ dvc exp show -n 100 --no-pager
ERROR: unexpected error - refs/remotes/origin/HEAD~11: the given reference name 'refs/remotes/origin/HEAD~11' is not valid

Having any troubles? Hit us up at https://dvc.org/support, we are always happy to help!

@karajan1001 this needs a rebase for the CI fixes

@mergifyio rebase


Let "depoly-setup.sh" and "undeploy.sh" fail on error

Ignoring errors seems not best. It can make it harder to find problems with the script.
If a command in the script is known to fail for valid reasons, then that should be treated specially (for example, with || :). By default, treat any unexpected failure as fatal and propagate the failure to the caller.
Fixes:<PHONE_NUMBER>3d ('Add RBAC for cluster resource')
CC: @pliurh

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.02%) to 38.404%

Totals

Change from base Build<PHONE_NUMBER>:
0.02%

Covered Lines:
4817

Relevant Lines:
12543

💛  - Coveralls

Hi @thom311 can you please do a force push I am not able to trigger the k8s lane for some reason

/test-all

all green merging nice work!


Fixing a typo

Summary
Fixing a typo in "Town-Square is Read-Only" setting description. Will update docs once this is approved.

@mkraft Wasn't sure who to ask but do you know if there are other places where this should be updated?

@amyblais This looks like all the places to me 👍

@amyblais  You need to merge master into this.

@hanzei I probably don't have access to do that or I'm not sure how to do it.

@amyblais Fixed and merged this for you. Hope you are fine witht this.

Thank you!


Merge Ingestion Aggregation Feature

Description
This PR adds Ingestion Aggregation. The design doc can be found https://github.com/apache/pinot/issues/8360.
This feature aggregates values at ingestion time, which reduces the number of rows stores (thus speeding up queries), using the same strategy as the 'aggregateMetrics' feature. This expands the feature to include, COUNT, MIN, and MAX, with the ability to expand further.
Upgrade Notes
Does this PR prevent a zero down-time upgrade? (Assume upgrade order: Controller, Broker, Server, Minion)
Yes (Please label as backward-incompat, and complete the section below on Release Notes)
Does this PR fix a zero-downtime upgrade introduced earlier?
Yes (Please label this as backward-incompat, and complete the section below on Release Notes)
Does this PR otherwise need attention when creating release notes? Things to consider:
New configuration options
Deprecation of configurations
Signature changes to public methods/interfaces
New plugins added or old plugins removed
Yes (Please label this PR as release-notes and complete the section on Release Notes)
Release Notes
Ingestion Pre-Aggregation is now supported for MIN, MAX, and COUNT, in addition to SUM. To enable the feature, add an aggregationConfig to the ingestionConfigs of a realtime table config. The format of the config is
"aggregationConfigs": [
{
"columnName": "destColumn",
"aggregationFunction": "MIN(srcColumn)"
}
],
The destColumn must be in the schema and the srcColumn must not be in the schema. Additionally, all destColumns must be noDictionaryColumns.
Documentation
After this PR I will add the documentation.

Codecov Report

Merging #8611 (db7fb0d) into master (232b946) will decrease coverage by 1.60%.
The diff coverage is 76.92%.

:exclamation: Current head db7fb0d differs from pull request most recent head ce69c7b. Consider uploading reports for the commit ce69c7b to get more accurate results

@@             Coverage Diff              @@
##             master    #8611      +/-   ##
============================================
- Coverage     70.68%   69.08%   -1.61%
- Complexity     4321     4362      +41
============================================
  Files          1693     1695       +2
  Lines         88795    88922     +127
  Branches      13472    13501      +29
============================================
- Hits          62767    61433    -1334
- Misses        21639    23174    +1535
+ Partials       4389     4315      -74

Flag
Coverage Δ

integration1
?

integration2
25.68% <3.84%> (-0.11%)
:arrow_down:

unittests1
66.98% <76.92%> (+0.03%)
:arrow_up:

unittests2
14.17% <0.00%> (-0.03%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...he/pinot/common/utils/grpc/GrpcRequestBuilder.java
72.72% <ø> (ø)

...che/pinot/controller/util/FileIngestionHelper.java
91.02% <ø> (ø)

...g/apache/pinot/spi/utils/IngestionConfigUtils.java
73.33% <50.00%> (-2.73%)
:arrow_down:

...local/indexsegment/mutable/MutableSegmentImpl.java
59.44% <56.52%> (+0.63%)
:arrow_up:

...tils/ingestionaggregation/IngestionAggregator.java
80.64% <80.64%> (ø)

...he/pinot/segment/local/utils/TableConfigUtils.java
66.53% <84.21%> (+1.39%)
:arrow_up:

...ache/pinot/segment/local/utils/IngestionUtils.java
29.14% <90.90%> (+4.14%)
:arrow_up:

...rg/apache/pinot/common/function/FunctionUtils.java
100.00% <100.00%> (ø)

...a/org/apache/pinot/common/utils/PinotDataType.java
81.11% <100.00%> (+0.04%)
:arrow_up:

...he/pinot/common/utils/config/TableConfigUtils.java
83.82% <100.00%> (ø)

... and 148 more

Continue to review full report at Codecov.

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


[Bug]: Single burst edge case test giving unexpected results

Checked for duplicates
Yes - I've already checked
Describe the bug
When I ran through an edge case, specifically this one, I noticed that a higher number of download jobs were launched than expected by the system. Specifically, additional MGRS tile set references were observed to be matched by the system.
What did you expect?
Only two download jobs to be submitted, representing unique MGRS tile sets: MS_20_30 and MS_20_29
Reproducible steps

Go to INT-FWD Mozart

Run this command:
python daac_data_subscriber.py query -c OPERA_L2_RTC-S1_V1 --release-version=3.0.0-rc.3.0 --job-queue=opera-job_worker-rtc_data_download --chunk-size=1 --processing-mode=reprocessing --native-id="OPERA_L2_RTC-S1_T020-041121-IW1_20231101T013115Z_20231104T041913Z_S1A_30_v1.0"

Observe the following log result
[2024-04-16 17:23:11,211: INFO/run_query] len(results)=4
[2024-04-16 17:23:11,211: INFO/run_query] results=[('MS_20_30$147', '1f5d746f-6565-481d-bde1-265ea41cc984'), ('MS_20_29$147', '24bb76e3-e990-4f4a-a69e-a670e12a7108'), ('MS_20_29$160', 'd8d44fd4-f7b6-4898-9824-c3a4d584dac8'), ('MS_20_30$160', 'd4213286-1a52-427b-a342-2ad2ee55e100')]

In step (3) above, we expect Len(results)=2 not 4.

Environment

Version of this software: PCM 3.0.0-rc.3.0
Venue: INT-FWD
settings.yaml configuration:...
DSWX_S1_COVERAGE_TARGET: 1
# Force DSWx-S1 processing of pending burst sets after X minutes, rather than waiting for additional data
DSWX_S1_COLLECTION_GRACE_PERIOD_MINUTES: 0
...

Note that the acquisition time cycles were 147 and 160. At most these two should be 1 apart. It's not possible to have 13 cycles away for a single RTC granule triggering.

@chrisjrd I checked with latest develop branch, it triggers 3 download jobs, not 2.
coverage_results_short={-1: ['MS_20_30', 'MS_20_31', 'MS_20_29']}


After Update to v1.39.1 in Windows 10 Pro All Extensions Stay Disabled

I update VSCode from v1.38 to v1.39.1 in Windows 19 Pro and all the extensions were disabled by the update. I enable the extensions but they stay in the Disable section even when they were enabled. I close the program and when open it all the extensions were disabled by the program again. I have a Mac Mojave where I do the update too and this issue does not happen.

which version of windows are you running? for me its ok on windows 10 pro 1903.

Windows 10 Pro v10.0.18362 Build 18362

Same issue here
And i found  node debugger azure pipelines fielded and disabled

I have the same issue, as workaround i downgraded to 1.38.1 through chocolatey:
choco install vscode --version=1.38.1

/duplicate of https://github.com/microsoft/vscode/issues/82359


FIX: Android background permission check does not work.

During background operations, the Context received with Registrar.activity() is null. This is also in the doc for Registrar.activity().
The solution is to use an Activity (Registrar.activity()) for requestNotificationPermissions, which will only make sense in the foreground and use a Context (Registrar.context()) for getNotificationPermissionStatus which can also be used during background tasks, such as handling a (silent) push notification.

@gahms I was reading the documentation for the registrar, and in this case does it make more sense to use the activeContext?
https://api.flutter.dev/javadoc/io/flutter/plugin/common/PluginRegistry.Registrar.html#activeContext--

Yes! You are totally right. I have no idea why I looked at activeContext() and dismissed it. I have tested, and it works great.

Android Studio tells me I should upgrade the Gradle Plugin used and I am guessing Travis fails due to the use of an old Gradle Plugin - should I upgrade and commit to this PR, open a new PR or just ignore?


DocsArchive-<IP_ADDRESS>Auto archive content

Please don't merge this PR until target archive repo PR https://github.com/OPS-E2E-PPE/docs-yml-archive-non-versioning-archive/pull/205 is merged into live branch.
Auto archive content to https://github.com/opstest2/docs-yml-archive-non-versioning-archive.git

Docs Build status updates of commit a120d45:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

.openpublishing.redirection.json
:white_check_mark:Succeeded

docs/TOC.yml
:white_check_mark:Succeeded
View

docs/index.yml
:white_check_mark:Succeeded
View

docs/to-be-archive/level1/article3-1-1.md
:white_check_mark:Succeeded
View

docs/to-be-archive/level1/article3-1-2.md
:white_check_mark:Succeeded
View

docs/to-be-archive/level1/article3-1-3.yml
:white_check_mark:Succeeded
View

docs/to-be-archive/level1/sql-database-engine.png
:white_check_mark:Succeeded

docs/to-be-archive/level2/article3-2-1.md
:white_check_mark:Succeeded
View

docs/to-be-archive/level2/article3-2-2.md
:white_check_mark:Succeeded
View

docs/to-be-archive/level2/article3-2-3.yml
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Remove dependency on kobconfig; pass through all config options straight from 'config'.

This change removes all references to "kc" (kobconfig.py); all config options are directly taken from config (pykob/configure.py).  Changes to wire #, station ID, and WPM were already passed through directly to config file; this code adds a guard to make sure the values of wire # and WPM are valid integers before returning them (otherwise substituting "1").
This is a first step to incorporating the Preferences dialog - this change makes sure the config file is in sync with the main panel at all times and that the PyKOB configs are the only interface to the config file(s).

It works for me, Patrick. I notice the main window starts up smaller than before, but that'll be OK once the window size and position are saved for the next time the program is run.
~Les

It works for me, Patrick. I notice the main window starts up smaller than before, but that'll be OK once the window size and position are saved for the next time the program is run.
~Les

Actually I noticed the window size and position were taken from fixed constants in kobconfig.py; I figured that was a shortcut to getting the actual window size so I "fixed" the code to compute the actual window size and use that directly instead.  The size and position are not currently saved in the config file anywhere (they were hard-coded in kobconfig.py) so it should've always been coming up in the same place, and at the same size.  Now it comes up in its minimal size, centered horizontally, a bit above the center of the screen (there's a 40/60 split of the vertical padding built into the code).
Let me know if you want to revert to using the previous hard-coded window size (and why).  If it's important (e.g. for some text field to be a different size) we may be better off specifying that in the text field creation and otherwise let the size be whatever it needs to be.

Actually I noticed the window size and position were taken from fixed constants in kobconfig.py; I figured that was a shortcut to getting the actual window size so I "fixed" the code to compute the actual window size and use that directly instead.  The size and position are not currently saved in the config file anywhere (they were hard-coded in kobconfig.py) so it should've always been coming up in the same place, and at the same size.  Now it comes up in its minimal size, centered horizontally, a bit above the center of the screen (there's a 40/60 split of the vertical padding built into the code).
Let me know if you want to revert to using the previous hard-coded window size (and why).  If it's important (e.g. for some text field to be a different size) we may be better off specifying that in the text field creation and otherwise let the size be whatever it needs to be.

Patrick, there's nothing magic about those size and position numbers in the old, obsolete code. If you can make the window the same size as the MorseKOB 2.5 window, it might make it appear more familiar (i.e. 'comfortable') to existing users, but don't go to too much effort on that. Centering the window on the screen initially is fine. The size is a bit cramped as it is, but it can always be resized (and repositioned) on the fly by the user.
At some point we'll want to save the size and position between sessions. This will be especially important when the user creates multiple profiles, with the respective windows coming up in preestablished locations on the screen when each instance is launched.
~Les

Patrick, there's nothing magic about those size and position numbers in the old, obsolete code. If you can make the window the same size as the MorseKOB 2.5 window, it might make it appear more familiar (i.e. 'comfortable') to existing users, but don't go to too much effort on that. Centering the window on the screen initially is fine. The size is a bit cramped as it is, but it can always be resized (and repositioned) on the fly by the user.
At some point we'll want to save the size and position between sessions. This will be especially important when the user creates multiple profiles, with the respective windows coming up in preestablished locations on the screen when each instance is launched.
~Les

This is probably why my #223 change has a conflict. I think it's fine, I'll prefer your changes over mine when I merge. The main point of my #223 was to add the auto-connect option and use it in MKOB to connect at start up. But I also came across the kobconfig redundancy and removed them - just leaving the size and location values.

This is probably why my #223 change has a conflict. I think it's fine, I'll prefer your changes over mine when I merge. The main point of my #223 was to add the auto-connect option and use it in MKOB to connect at start up. But I also came across the kobconfig redundancy and removed them - just leaving the size and location values.

The config file should have an application specific section where things like the size and position can be saved. The config file is a traditional Windows format that has [section-name] sections. There should be a [mkob] section that has values specific to the MKOB app.

The config file should have an application specific section where things like the size and position can be saved. The config file is a traditional Windows format that has [section-name] sections. There should be a [mkob] section that has values specific to the MKOB app.

Configure should only set/show the common configuration. Any app specific configuration should only be used/set by the app. This is normal Windows config file behavior. It's a bit different for Mac and Linux, but since the app started as a Windows app, that is how things work.

Configure should only set/show the common configuration. Any app specific configuration should only be used/set by the app. This is normal Windows config file behavior. It's a bit different for Mac and Linux, but since the app started as a Windows app, that is how things work.

I'll second the goal of having size and position recalled between sessions.  At the AWA I normally have two sessions of 2.5 running, one in the upper left of the screen and the other in the lower right when they are not in full screen mode.  This even allows a little overlap as I'm normally working with the one on the lower right side of the screen and I overlap its window with the one in the upper left as it is usually just a broadcast wire and unless I need to change them, hiding the controls on the lower right of the window still leaves the reader screen portion uncovered.  When I exit full screen mode they return to their former size and position.
73, Chris

I'll second the goal of having size and position recalled between sessions.  At the AWA I normally have two sessions of 2.5 running, one in the upper left of the screen and the other in the lower right when they are not in full screen mode.  This even allows a little overlap as I'm normally working with the one on the lower right side of the screen and I overlap its window with the one in the upper left as it is usually just a broadcast wire and unless I need to change them, hiding the controls on the lower right of the window still leaves the reader screen portion uncovered.  When I exit full screen mode they return to their former size and position.
73, Chris

Les, see issue #233 to make the main window’s widgets explicitly the size in the current display (fixed at 800x500) by changing the size of various text widgets to natively make the window and its contents about the same size (802 x 503, IIRC).
I just put out a pull request for a change to do so (and in the process hide the window during construction so it doesn’t “jump” quite so visibly at startup).
The task of saving the size and position across invocations remains for a separate change.
73, -Patrick.

On Jan 14, 2021, at 10:31 PM, Les Kerr<EMAIL_ADDRESS>wrote:
Patrick, there's nothing magic about those size and position numbers in the old, obsolete code. If you can make the window the same size as the MorseKOB 2.5 window, it might make it appear more familiar (i.e. 'comfortable') to existing users, but don't go to too much effort on that. Centering the window on the screen initially is fine. The size is a bit cramped as it is, but it can always be resized (and repositioned) on the fly by the user.
At some point we'll want to save the size and position between sessions. This will be especially important when the user creates multiple profiles, with the respective windows coming up in preestablished locations on the screen when each instance is launched.
~Les
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/MorseKOB/PyKOB/pull/229#issuecomment-760683925, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALTAYK2D5IYBSX3X6BYFJZ3SZ7OLLANCNFSM4WDRU5GQ.

Les, see issue #233 to make the main window’s widgets explicitly the size in the current display (fixed at 800x500) by changing the size of various text widgets to natively make the window and its contents about the same size (802 x 503, IIRC).
I just put out a pull request for a change to do so (and in the process hide the window during construction so it doesn’t “jump” quite so visibly at startup).
The task of saving the size and position across invocations remains for a separate change.
73, -Patrick.

On Jan 14, 2021, at 10:31 PM, Les Kerr<EMAIL_ADDRESS>wrote:
Patrick, there's nothing magic about those size and position numbers in the old, obsolete code. If you can make the window the same size as the MorseKOB 2.5 window, it might make it appear more familiar (i.e. 'comfortable') to existing users, but don't go to too much effort on that. Centering the window on the screen initially is fine. The size is a bit cramped as it is, but it can always be resized (and repositioned) on the fly by the user.
At some point we'll want to save the size and position between sessions. This will be especially important when the user creates multiple profiles, with the respective windows coming up in preestablished locations on the screen when each instance is launched.
~Les
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/MorseKOB/PyKOB/pull/229#issuecomment-760683925, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALTAYK2D5IYBSX3X6BYFJZ3SZ7OLLANCNFSM4WDRU5GQ.


Fix invalid paths on Non-Windows systems

Before, due to the backslahses, The script tries to create a single folder called Assets\SkinMods\{modname}, which breaks everything that tries to access files with a path. Using Path.Combine like the rest of the code makes it create directories correctly

Looks, good, thanks for a contribution.

Looks, good, thanks for a contribution.


Support for bokeh plot

This pull request adds support for creating interactive visualizations using Bokeh. The integration includes utilities for generating html plots and embedding them into the application.

Looks like some formatting failures, could you follow: https://google.github.io/mesop/internal/development/#commit-hooks - the pre-commit hooks should fix the formatting issues. thanks.

Hello @wwwillchen
I have fixed pre-commit lint errors

Also added e2e tests, however I am not able to run pywright tests it failed with error error Your lockfile needs to be updated, but yarn was run with --frozen-lockfile.
Can you please run CI again?

Hello @wwwillchen I have fixed pre-commit lint errors
Also added e2e tests, however I am not able to run pywright tests it failed with error error Your lockfile needs to be updated, but yarn was run with --frozen-lockfile.
Can you please run CI again?

Re-running CI. Sometimes the npm modules gets in a weird state - try running: bazel clean --expunge && rm -rf node_modules and see if that fixes the yarn error.

I've been thinking about this some more and I think it may be better to just have bokeh be an example in the demo gallery rather than its own component because the implementation is fairly simple:
  from bokeh.embed import file_html

  html(file_html(figure, "inline"), style=style)

Arguably the existing plot component (for matplotlib) shouldn't be a component and I think it was kind of borderline then, but matplotlib is the most popular Python package for plotting: https://pypistats.org/packages/matplotlib, so that was my original rationale for including it in Mesop.

This approach has not been working for me, also not with plotly's own generated html file.
I do not get anything displayed (see image below).

Would that issue be solved by the (already done in code) addition of "sandboxed" mode in the html component (hopefully coming soon :))?

I've been thinking about this some more and I think it may be better to just have bokeh be an example in the demo gallery rather than its own component because the implementation is fairly simple:
  from bokeh.embed import file_html

  html(file_html(figure, "inline"), style=style)

Arguably the existing plot component (for matplotlib) shouldn't be a component and I think it was kind of borderline then, but matplotlib is the most popular Python package for plotting: https://pypistats.org/packages/matplotlib, so that was my original rationale for including it in Mesop.

This approach has not been working for me, also not with plotly's own generated html file. Both make heavy use of Javascript. I do not get anything displayed (see image below). I am assuming that this has to do with the javascript since i cannot see the javascript when looking at the page using dev tools in chrome.

This is the code that ends up being displayed:

Bokeh Application

Would that issue be solved by the (already done in code) addition of "sandboxed" mode in the html component (hopefully coming soon :))?

I've been thinking about this some more and I think it may be better to just have bokeh be an example in the demo gallery rather than its own component because the implementation is fairly simple:
  from bokeh.embed import file_html

  html(file_html(figure, "inline"), style=style)

Arguably the existing plot component (for matplotlib) shouldn't be a component and I think it was kind of borderline then, but matplotlib is the most popular Python package for plotting: https://pypistats.org/packages/matplotlib, so that was my original rationale for including it in Mesop.

hey @ChemicalFC we released v0.9.4 yesterday which includes the HTML sandboxed mode - please give that a shot! If you run into more issues, please feel free to open a new issue. I'll close this PR for now.

Tested and worked with bokeh and plotly (via html code)


Figure out how to handle errors

I've defined a result and have a few errors around. Figure out the best way to use them instead of panicking and how to store the most context.

Actually, panic! may be best. These errors aren't actually recoverable - they all result in puzzles not being able to be solved. The goal here should be to make sure there's enough information to debug and fix the issue, rather than handling them gracefully.

https://github.com/dtolnay/anyhow gives good context handling


Add an explicit NDK version to Android template

Summary
Added an explicit NDK version to the Android template. This allows tooling to detect which NDK version to install automatically.

Changelog

[Android] [Added] - Add an explicit NDK version to Android template
Test Plan

Template builds as it should. NDK version gets installed with initial Android set up.

AFAIK the NDK is not necessary for regular users who don't build from source. Can you make sure this doesn't affect the users i.e. requiring them to install NDK?

cc @dulmandakh

@thymikee I was getting errors with 0.63 as so:
android/app/build/intermediates/merged_native_libs/debug/out/lib/x86_64/libreactnativejni.so' due to missing strip tool for ABI 'X86_64'. Packaging it as is.

The fix was to install the NDK

Status on this? @dulmandakh

@safaiyeh  i am trying to build app bundle with symbols and facing an issue related to NDK though i have ndk installed it keeps saying me its not installed
0.63.2
> Task :app:extractReleaseNativeSymbolTables FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:extractReleaseNativeSymbolTables'.
> NDK is not installed

Probably an option to set NDK would be nice

@dulmandakh for the aab to build with symbol we need to specify NDK 20, i had NDK 21 installed and it gave me the above error i mentioned please have a look.

@fkgozali updated!

Hmm, thinking about this, is this approach generally correct? According to https://github.com/facebook/react-native/wiki/Building-from-source, some environment sets up ANDROID_NDK env var to point to specific NDK version. That environment may not have the exact NDK version set in this PR (20.1.5948944).

What happens if ANDROID_NDK and the version specified here mismatch? Which has the priority?
Should we guide people to instead set ANDROID_NDK var per https://github.com/facebook/react-native/wiki/Building-from-source ?

@fkgozali After careful thoughts here is my opinion.
What happens if ANDROID_NDK and the version specified here mismatch? Which has the priority?
I just tried to make a quick experiment about this.

Currently, I have two versions of NDK installed. The first one is NDK 21.3.6528147, this is the one I specified on my env var and the second one is NDK 20.1.5948944. When I tried to run RNTester and ReactAndroid with the explicit NDK version (20.1.5948944) Gradle will prioritize the explicit NDK version that we set on the Gradle file not the one on the env var.
And when I set the version to 20.0.5594570 which is not installed locally on my machine the build would not be successful but Gradle can list all of my locally installed NDK version regardless of what I specified on the env var.

Should we guide people to instead set ANDROID_NDK var per https://github.com/facebook/react-native/wiki/Building-from-source ?
The guide on installing Android NDK is quite outdated. I much prefer to install NDK from Android Studio's SDK Manager. Why? For example, no Mac NDK before NDK r21 was signed or notarized. This shouldn't matter for NDK downloads performed by Android Studio's SDK Manager, but if you manually download an NDK from https://developer.android.com/ndk/downloads on macOS 10.15 you'll see warnings when you try to run the extracted tools. The NDK is not quarantined when it is downloaded via the SDK manager, so is currently allowed by Gatekeeper. For me, I think The SDK manager is currently the most reliable way to get the NDK and I think this is should be the way we advise people to install NDK.
Additionally, what happens if React Native core updates its NDK version, but the hosting app (assume one creates an app with an older release from template) still has it pinned to an older NDK version? Would that potentially cause issue due to ABI, etc? In this case, it seems like using a global ANDROID_NDK might be more consistent?
I just tried this, and even tho I only install android NDK version 21.3.6528147 and set that up on my env var the app won't build because somehow it's searching for non-existent NDK version 20.0.5594570. This problem can be easily fixed if we just configure a specific NDK version on the Gradle file.

The case I wasn't sure about is :ReactAndroid, where we build the C++ by calling into ndk-build directly. In order to find the right NDK dir, it does this: https://github.com/facebook/react-native/blob/master/ReactAndroid/build.gradle#L249-L271
def findNdkBuildFullPath() {
    // we allow to provide full path to ndk-build tool
    if (hasProperty("ndk.command")) {
        return property("ndk.command")
    }
    // or just a path to the containing directory
    if (hasProperty("ndk.path")) {
        def ndkDir = property("ndk.path")
        return new File(ndkDir, getNdkBuildName()).getAbsolutePath()
    }

    if (System.getenv("ANDROID_NDK") != null) {
        def ndkDir = System.getenv("ANDROID_NDK")
        return new File(ndkDir, getNdkBuildName()).getAbsolutePath()
    }

    def ndkDir = android.ndkDirectory ? android.ndkDirectory.absolutePath : null

    if (ndkDir) {
        return new File(ndkDir, getNdkBuildName()).getAbsolutePath()
    }
    return null
}

Now, I'm not sure if this logic has covered the case where ndkVersion is set in the root project build.gradle.

I just tried this, and even tho I only install android NDK version 21.3.6528147 and set that up on my env var the app won't build because somehow it's searching for non-existent NDK version 20.0.5594570. This problem can be easily fixed if we just configure a specific NDK version on the Gradle file.

Yeah this is true, however, the issue is not just about missing NDK installation, but also about cross-version compatibility (C++ ABI etc). For example, perhaps the different NDK versions are already installed, but what if NDK version A output is not compatible with version B output? It may cause compilation error or runtime crash.
So it feels to me that if an app wants to build from source, the same NDK version should be used to compile all parts of the sources to ensure compatibility.
Thoughts? cc @safaiyeh @dulmandakh @Kudo

Is it possible to expose the NDK version used by ABI to the user land template?

Is it possible to expose the NDK version used by ABI to the user land template?

Did you mean which NDK is used by the system? I think that's set by ANDROID_NDK path, which may or may not have the version on it. E.g. many system just symlink /opt/android_ndk to something in local machine.

Now, I'm not sure if this logic has covered the case where ndkVersion is set in the root project build.gradle.

Just checked, and yeah the logic doesn't cover when Gradle execute buildReactNdkLib it will use the one that people set on ANDROID_NDK. I only checked stripDebugSymbol yesterday.

Share my understandings:

android/app/build/intermediates/merged_native_libs/debug/out/lib/x86_64/libc++_shared.so' due to missing strip tool for ABI 'X86_64'. Packaging it as is.
android/app/build/intermediates/merged_native_libs/debug/out/lib/x86_64/libreactnativejni.so' due to missing strip tool for ABI 'X86_64'. Packaging it as is.

These are warnings but not errors.
If there are *.so, gradle will try to use NDK strip tool to strip debug symbol.
If NDK is not setup correctly, gradle will give these warnings and skip the stripping process.
However, the solution @safaiyeh here is better that will prevent developers install unexpected NDK.

Yeah this is true, however, the issue is not just about missing NDK installation, but also about cross-version compatibility (C++ ABI etc). For example, perhaps the different NDK versions are already installed, but what if NDK version A output is not compatible with version B output? It may cause compilation error or runtime crash.

AFAIK, NDK maintains ABI stability really well.
The old JSC was built from NDK r10c and we ran for years.
Until we replacing with new JSC, at that time, RN was built from NDK r17c
That was really amazing that we didn't face ABI incompatibilities from NDK r10c to r17c.
Well, relying on NDK ABI stabilities is not a good practice. Building from source will prevent potential problems.

The original goal of this is coming from a new RN Developer perspective.
Download the template -> Know the correct NDK to install

OK, thanks for the context. Based on NDK ABI stability and easier starting point when using the template, then this change seems reasonable to try out. For whether ReactAndroid and RNTester should explicitly define the version as well, let's discuss more in https://github.com/facebook/react-native/pull/29987.


How to resume?

Hi, I want to know how to recover training from the checkpoint file. I did not find this option in the configuration file, only "-- resume dataloader". Additionally, I trained on my own dataset (only 1800 images), and although I set "-- train iters" to 200000, the training automatically stopped at 50000, and the error message is shown in the figure:

I also faced the same problem recently... It's a bug of sat, and I'm working on fixing it.
By the way, 1800 images do not worth 50000 training iters...

OK, Thank you very much!! @1049451037


Integration tests

This mainly has 3 integration tests, for common, party_walls and floors_estimation.
What else:

Removal of all BGT usage
Some formatting (sorry)
Corrected a few things to remove deprecation warnings
(see comments below)

The most relevant work is in the test_integration.py files.
I basically mocked upstream assets and run the rest of the jobs - not sure if there is any better way to mock upstream assets so feel free to change as you see fit.
Specifically for the pipeline jobs, the integration runs only the nl_reconstruction and nl_export jobs. I did not manage to add nl_deploy yet but I might write a separate test for it later.
You can clone the repo and follow the instructions in README to run all the tests but you will need tyler, geoflow etc. - so maybe do that in gilfoyle.
Before merging, pyproject.toml files need to be updated again to remove references to this branch.

I am going to close this because I want to add some more work with the mocks

I reopened this PR, now it is ready for review.


Introduce a deterministic algorithm for choosing a port for the aggregator server.

The workflow will probably be as follows:
Director config will feature a new parameter open_ports listing one or more ports.
This list will be tracked by the Director-service, which will provide one of the ports to the Aggregator at the start time.

Hi,
Thank you for doing this. Motivation behind this is that when one is working on secure system, it is important to open just as much ports as is needed, in a controlled fashion. With aggregator picking "random" port, it is rather problematic to achieve minimalisation of open ports.


New app: SpaceX Launch

This PR introduces a new app "SpaceX Launch" that displays information about an upcoming SpaceX rocket launch.

Can we expect the app to work reliably over time?

The Launch Library 2 API has been around a few years, and seems to have a healthy community (Reddit, Discord).

Is the app handling user data responsibly?

There's no real user data apart from API key, but that's passed in as config and not persisted outside of how Tidbyt persists configs.

Is the app caching in an appropriate manner?

I believe so, it caches a single API resource and image for 5 minutes to comply with the API's 15 req/hr rate limit.

If an external API is being used, is the app taking care to keep request rates at a reasonable level?

Yes, it makes one request every 5 minutes.

I have read the CLA Document and I hereby sign the CLA

recheck

Thanks for the PR. A little bit worried we'll exceed that low rate limit. When a cache record expires there can potentially be several instances of the app trying to refresh at the same time, resulting in a higher request rate than one might expect. But let's give it a try and see what happens.

Hey @matslina thanks for giving it a try! Yeah that makes sense, didn't think about that.
I think the app could still have value even if updated e.g. once an hour, so if you do see issues perhaps we can just bump out the cache duration to much longer.


New themes :D

Maybe make the new theme the default and call the old ones "legacy"?

Maybe make the new theme the default and call the old ones "legacy"?

Actually, this is a bit more than a theme since I'm also moving stuff around. If people like it, we should move the css code to site.css and just keep here the colors variables, like other themes. That way I wouldn't need all the !important overrides and new layout would work with any of the color themes.


UI 2.0: detail views never populate if /detail-view-config endpoint returns 404

Environment

Nautobot version (Docker tag too if applicable): next
Python version:
Database platform, version:
Middleware(s):

Steps to Reproduce
Example: https://next.demo.nautobot.com/extras/object-changes/ce20d17c-ed11-455b-93a3-d7efc59594be/

Expected Behavior
Page to render with some default layout

Observed Behavior

The underlying trigger appears to be that ObjectChangeViewSet is not a NautobotModelViewSet subclass and so it doesn't implement the detail-view-config API action. Regardless, the front-end needs to account for this possibility.

Should this be blocked by https://github.com/nautobot/nautobot/issues/3526?

Closed by #3805


"Add tunnel" quick fix not shown after already fixing one

URL
No response
How to reproduce the issue?
Create a waterway that crosses two roads.
When selecting the waterway, the validator correctly shows the quick fix menu the first time but after there is only an option to ignore the problem.
Screenshot(s) or anything else?

I understand that this happens because after the tunnel is created, the selection includes three waterways and the validator don't know what to do.
It should either:

show the full quick fix menu
automatically change selection to the next problematic segment
don't show "ignore this issue" because it might mislead mappers into thinking there’s nothing else to do to fix it

And clicking the yellow box zooms in on the problematic way but still keeps the selection the same, so the quick fix menu is still incomplete.
Which deployed environments do you see the issue in?
Released version at openstreetmap.org/edit, Development version at ideditor.netlify.app
What version numbers does this issue effect?
2.30.4
Which browsers are you seeing this problem on?
Chrome, Firefox

hi , i tried replicating the issue but it didnt occur can you upload a video of it?

https://github.com/user-attachments/assets/de11235c-2ff7-42d2-9e2f-f347ef8be68c

Thanks for sharing this issue, @Nekzuris. I have been able to replicate this issue, the third option to not show "ignore this issue" may be the most straightforward approach. About the implementation for option 1 & 2, if we show the full quick fix menu, and if the user selected to add a tunnel further, we can't know which feature is the tunnel getting added to right?
For option 2, what does change selection to the next problematic segment  mean?
Thanks a lot

For option 2, what does change selection to the next problematic segment mean?

Exactly what I did manually at 0:05, but I don't think this is a good solution to implement.

we can't know which feature is the tunnel getting added to right?

We can know for sure because if you click the top of the yellow box it zoom the map exactly were the tunnel should be added.

i guess we can change it to  highlight the next issue and show full quick fix menu , i would like to work on this issue (just a thought but we can give a small popup or something which tells user that everything's fine after fix)

hi @Nekzuris @Darshit42 I have raised a PR that doesn't show ignore_issue message that might mislead the mappers. Please do check it out.
Thanks
https://github.com/user-attachments/assets/0bb47f74-4cbc-43a8-aa7a-85ae8abde138


Initial Keccak256 hash implementation for circuit

@lightning-li

@ZhAnGeek yep, agree about more testing (also using fuzz), will add it to the PR.

lgtm


AuthorizeHelper will no-op if endpoint routing is used

Fixes #9216
If I understand correctly, Auth will run on the Endpoint metadata (which we set the authorize metadata correctly) so internally SignalR doesn't need to run Auth again in the Endpoint code path.

Ping reviewers, I basically rewrote the change so we no longer do Auth inside HttpConnectionDispatcher and rely on Auth through Endpoint routing.
The one remaining thing is that app.UseSignalR(routes => routes.MapHub<MyHub>("/path")); doesn't set the HubMetadata on the Endpoint produced.

The one remaining thing is that app.UseSignalR(routes => routes.MapHub("/path")); doesn't set the HubMetadata on the Endpoint produced.

Can you explain why this is the case?

Can you explain why this is the case?

I've just made a commit with a fix, I didn't do it initially because it's a bit ugly, but I don't have a better solution right now.

/azp run all

@aspnet/build What's going on?

@aspnet-hello triage https://dev.azure.com/dnceng/public/_build/results?buildId=206259&view=logs

@BrennanConroy looks like AzDO missed your comment or hit a temporary glitch.
Later, the Hello bot ignored your triage request. That bot seems to get confused when the URL doesn't exactly match a known format (see aspnet/AspNetCore-Internal#2425). In this case, &view=logs probably busted it.

@dougbu I doubt it: https://github.com/aspnet/AspNetCore/pull/10425#issuecomment-495394631

@BrennanConroy that was a whole week ago ❕
More seriously, we don't know why the bot sometimes ignores triage requests.

/azp run AspNetCore-ci

/azp run AspNetCore-ci

/azp run AspNetCore-ci

@aspnet-hello triage https://dev.azure.com/dnceng/public/_build/results?buildId=207741&view=logs


Add wss option for XML only signing

Add wss option for XML only signing since in XAdES we need to have partial signing without wss option signed Element will have wss:Id attribute instead of Id attribute
also add support for SHA512 Digest and rename id for SHA256 in digester because url have been relocated.

Hi, lookds good, can you create additional test case for the wss: false option, without modifying the existing test case, so that we can be sure that it is backwards compatible?

@ebeigarts I just bring back test. please review again thanks for quick reply 👍

@pistachiology thanks, released in v1.7.0


Switch to CircleCi

Travis stuck again.

OK, apparently we can't use Travis for any other repo except for DMD.
Then let's switch to CircleCi. It's very trivial here as all setup is done within the Makefile :)
Worked immediately on my fork: https://circleci.com/gh/wilzbach/dlang.org/2

From #1713

This is now live, so I'm going to disable Travis

Alrighty, closing this one then as well.


Update migration-troubleshooting.md

Small typo on the example command

@MrRodrigoAntunes Thank you for for fixing this. I am merging this PR and it should be live soon.