Roll Flutter Engine from 3d3fb4faed02 to 66a64a10a1a1 (5 revisions)

https://github.com/flutter/engine/compare/3d3fb4faed02...66a64a10a1a1
2023-08-09<EMAIL_ADDRESS>Roll Skia from e2885a01f134 to ff6d82573f69 (3 revisions) (flutter/engine#44536)
2023-08-09<EMAIL_ADDRESS>Remove GFX and Scenic dependencies from Fuchsia integration tests (flutter/engine#44498)
2023-08-09<EMAIL_ADDRESS>Roll Skia from ac2b25fec6eb to e2885a01f134 (1 revision) (flutter/engine#44534)
2023-08-09<EMAIL_ADDRESS>Roll Skia from d097852dc928 to ac2b25fec6eb (3 revisions) (flutter/engine#44533)
2023-08-09<EMAIL_ADDRESS>[Windows] Return keyboard pressed state (flutter/engine#43998)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC chinmaygarde@google.com,rmistry<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.


feat(ci): Add a new test to validate modules are correctly set in DEFAULT_MODULES

What does this PR do?
Create a new inv modules.validate command to test all module dependencies are correctly set in DEFAULT_MODULES. Otherwise this can be detected only during release candidate creation, which is a waste of time

Motivation
Stability

Additional Notes
I wanted to put a .pre-commit hook as well but the test is too long (~20sec), according to me

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

/merge


make repr of null configurable

some users prefer null to be displayed as an empty result instead of "null"
maybe https://github.com/twosigma/beakerx/pull/5205 can handle that?

You mean #5120 I guess :-)

What do you think a good way to configure it is?

As an attribute I can set overwriting Kernel ?

See https://github.com/hadim/scijava-jupyter-kernel/blob/master/src/main/java/org/scijava/jupyter/kernel/ScijavaKernel.java#L53


Tweak README example to be clearer

Both the crate and the macro in the original text were named "my_macro",
so it was not obvious which one corresponded to what. This commit names them
"foo-macros" and "bar".
Also, the original text talked about the "my_macros" crate and the shim crate,
but the shim crate deserves to have the name the user gave to the original
pre-watt crate, since that is what gets published to crates.io.
The text now walks the user through renaming "foo-macros" to "foo-macros-impl"
and naming the shim crate "foo-macros".

I would've liked the part about renaming the original crate to -impl to be left in.

It's not a necessary step. I would tend to give the shim the same name as suggested in the update. There shouldn't be steps in the readme that aren't needed.

It's fine to give this the same crate name as the
previous crate, since the other one won't be getting published to crates.io. In
a new Cargo.toml, put:

And where does the reader put this new "Cargo.toml" which is supposed to be for a crate with the same name "my_macros", when the directory for my_macros already has the original crate?
There are two parts to renaming. The directory and the crate name. It's fine if you don't want to rename the crate, but I would've liked to keep the part that mentions renaming the directory.
See for example the demo in this very repo: https://github.com/dtolnay/watt/tree/master/demo/impl


Consider adding keep-runtime-typing or equivalent option for pyupgrade rules

pyupgrade allows opting out of upgrading typing aliases of built-in collections and typing.Unions if they are used at runtime (e.g. by libraries such as Pydantic and cattrs) in Python versions in which they are unsupported if not stringified (< 3.9 for the former and < 3.10 for the latter).  It would be great if ruff could provide an equivalent option so that we are able to adopt the new syntax upon upgrading Python, without having to ignore the rules (and later forget to unignore them).

Can do!

Added in https://github.com/charliermarsh/ruff/pull/965. I mirrored pyupgrade's behavior, which is that if you target Python 3.9, we still make those upgrades even if you passed in --keep-runtime-typing -- so that setting is only applicable when --target-version is 3.7 or 3.8, and you've imported from __future__ import annotations .


No "Closed-Display Mode Fail-Safe" option

I'm using M2 Macbook Air and can't find the "Closed-Display Mode Fail-Safe" option:

This is a bug that will affect the M2 Air and Pro.
The option’s not being shown because Amphetamine is looking at the machine’s model identifier and seeing if it contains “Book” to check it’s a laptop.
For the M2 MacBook Pro and Air, Apple changed the model identifier to Mac14,7 and Mac14,2 respectively, so this lookup fails and the option doesn’t show.
When you select this option (if it shows), it adds and launches the cdm-manager plist file to launchctl, which when triggered, runs this script.
You can re-create this manually by copying the amphetamine-enhancer-cdmManager.plist to /Library/LaunchAgents and then running the following in terminal:
launchctl load -w /Library/LaunchAgents/amphetamine-enhancer-cdmManager.plist

launchctl start amphetamine-enhancer-cdmManager

That being said, I investigated this with the intention of making sure my M2 Air didn't sleep when on battery and connected to an external monitor, but this didn't work and my Air still goes to sleep. I think the way this is handled in M2 (and maybe M1) macs is different and so the CDM manager code just doesn't work.
I wanted this for battery preservation (to not leave it at 100% all the time), and so my eventual solution was just to keep the Macbook connect to charge, but to use AlDente to manage the battery.

Mmm that's a bummer :/
My solution is run two bash scripts to switch on or off hibernation and sleep settings and enable clamshell mode without AC cable attached, independently from the app.
Run clam-sleep-off.sh to disable hibernation and sleep. This allows clamshell mode without AC ot happen basically..
Run clam-sleep-on.sh to restore default hib&sleep settings.
clam-sleep-off.sh
#!/usr/bin/env bash

#Disables sleep and hibernation
#allowing to use a second monitor with the lid closed

hib_mode="$(pmset -g | grep hibernatemode | grep -Eo "\d")"
sleep_mode="$(pmset -g | grep "\bsleep\b" | grep -Eo "\d")"
sleep_off="$(pmset -g | grep SleepDisabled | grep -Eo "\d")"

printf "\nRunning %s\n" "$0"

printf "The current hibernation mode is %s, default is 3 for Macbooks\n\n" "$hib_mode";

sudo pmset -a sleep 0 && printf "sleep set to %s\n" "$sleep_mode";

sudo pmset -a hibernatemode 0 && printf "hibernation mode set to %s\n" "$hib_mode";

sudo pmset -a disablesleep 1 && printf "SleepDisable is set to %s\n\n" "$sleep_off"

echo "Hibernation and sleep disabled. Clamsheel mode without AC activated"

clam-sleep-on.sh
#!/usr/bin/env bash

#Restores default settings for sleep and hibernation
#After running this script
#clamsheel mode requires the AC power connected to the mbpro

hib_mode="$(pmset -g | grep hibernatemode | grep -Eo "\d")"
sleep_mode="$(pmset -g | grep "\bsleep\b" | grep -Eo "\d")"
sleep_off="$(pmset -g | grep SleepDisabled | grep -Eo "\d")"

printf "\nRunning %s\n" "$0"

printf "The current hibernation mode is %s, default is 3 for Macbooks\n\n" "$hib_mode";

sudo pmset -a sleep 1 && printf "sleep set to %s\n" "$sleep_mode";

sudo pmset -a hibernatemode 3 && printf "hibernation mode set to %s\n" "$hib_mode";

sudo pmset -a disablesleep 0 && printf "SleepDisable is set to %s\n\n" "$sleep_off"

echo "Hibernation and sleep default settings restored"

little update for anyone still looking for a solution, the developer quietly released an updated testflight build on their twitter that fixes this issue! the enhancer tool doesn’t have a testflight but it seems to work just fine without it so far.

It kinda fixed it for me but again it appeared. Grayed out for me with the testflight build.

Has that TestFlight build been pushed to stable release yet?


Question: Is this Package available for .netstandard soon ?

Hello,
i'm just asking for future purposes.
Regards cunnza

I'm already using Zxing in .netstandard project.
Try to add string below to your netstandard  *.csproj
<PackageTargetFallback>portable-net45+win8+wpa81+wp8</PackageTargetFallback>
It works in my project, but only with .netstandard1.4 project

Great, got it working with .netStandard 2.0 ! Thank you !

Hey folks I plan on getting .Net standard support very soon.

Seems this is a duplicate of https://github.com/Redth/ZXing.Net.Mobile/issues/578

@Redth do you need help to migrate it in .Net standard ?
:)

Looking forward to .Net Standard support. Hopefully it's available soon. The app I'm working on for my company requires Barcode scanning, and all of the other libraries are terrible. Lead doesn't like the unsupported warning on the project references, so am waiting for .Net Standard support, instead of the fallback.

There's a 2.4.0-beta1 on nuget which has this. Please give it a try!

Thanks for all @Redth. I will try it today !

Nice, this is the last component in our apps that doesn't have .net standard support. Finally our last warnings will be gone

If you're using Visual Studio, close it, and delete the 'bin' and 'obj' folders in each project. Restart VS and try again, see if that helps.

Thanks for reply, I have fixed this issue by using old NuGet packages.

Thanks for reporting this issue!  Unforunately it took me way too long to respond 😭.  Sorry, I apologize!  Recently the source code for this project was completely refactored to modernize it.  Many PR's were included in this effort, and many bugs were hopefully fixed.  Please try out the latest 3.x series of NuGet packages (currently in prerelease).  To try and make the project more maintainable in my spare time going forward, I've decided to close all existing issues to start with a clean slate.  If you're still experiencing this issue on the newest version, please open a new issue with as much detail as possible.  Thank you for your patience and understanding!  Happy scanning!


Tes2

Please check if the PR fulfills these requirements

[ ] The commit message follows our guidelines
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
What is the current behavior? (You can also link to an open issue here)
What is the new behavior (if this is a feature change)?
Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
Other information:

Codecov Report

Merging #3 (2ecd7c1) into main (07e74c7) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main       #3   +/-   ##
=======================================
  Coverage   43.71%   43.71%
=======================================
  Files         419      419
  Lines       22822    22822
  Branches     3128     3128
=======================================
  Hits         9976     9976
  Misses      12846    12846

Impacted Files
Coverage Δ

packages/core/src/Entity.ts
82.98% <ø> (ø)

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 f9c3f58...2ecd7c1. Read the comment docs.


AnatomicalTargetPosition

Reflating problems raised in issue #10 of ephys and adding AnatomicalTargetPosition

@Peyman-N Thanks for the update and preparing the schema in general. Could you also introduce the first controlledTerms instances for the new terminology (anatomical identification type)? Meaning creating the controlledTerm schema, the instances in the terminology folder and first instances (e.g. stereotactic and landmark based).
This schema is fine now and I will merge it.


Use sodiumoxide PublicKey and SecretKey

There's no need to re-implement PublicKey and SecretKey structs within revault_net. Instead use PublicKey and SecretKey from sodiumoxide which already have conversion functions and memory zeroing for SecretKey when it is dropped.
Fixes #29
based on #33

?


Refactor process_response with multiple heads and pattern-matching

Conditionals are bad(tm).
Cfr. https://github.com/ShaneWilton/stockastic/pull/1

thanks @asymmetric


Unable to install azure-functions-core-tools in VSCode

Does this occur consistently?
Repro steps:

Action: azureFunctions.pickProcess
Error type: Error
Error Message: Functions host is no longer running.
Version: 0.22.1
OS: win32
OS Release: 10.0.18363
Product: Visual Studio Code
Product Version: 1.45.1
Language: en

Call Stack
extension.bundle.js:334:101651extension.bundle.js:334:101651
fulfilled extension.bundle.js:334:99073

@rakeshmotghare Please add repro steps.


Add support for HTTP HEAD and OPTIONS methods

Summary
During the EthPrague event there was a hack project to run the static wikipedia on swarm, based on the static-wiki project. That requires support for HEAD and OPTIONS methods.
Implementation
A workaround was that instead of adding this to Bee the support was added to the gateway-proxy in this branch.
Another problem was that Bee supports the accept-encoding header and browsers by default try to use gzip and pass in this header, but that breaks either the HEAD or the OPTIONS methods, so the proxy just removes this header.

Related: #2709

@agazso do we still need OPTIONS?

@agazso do we still need OPTIONS?

For the static.wiki use case: yes.


Ajout historisation des objectifs (test CI)

This was just to see if the tests in the CI were passing.


docs: Python SDK

Note: when dependencies change on llama_deploy main branch, the lockfile in docs prevents a clean build until you run poetry lock. This is not obvious so I decided to remove the lockfile from docs altogether.

coverage: 71.351%. remained the same
when pulling 20d1b69ec9e39591196a43f4cd7187380cbcc55e on massi/sdk-docs
into 955ef73730016d141c258dde097498cbaa6a83b4 on main.


Copybook without 01 or root record

Background
Though root record with 01 level is mandatory, can cobrix handle copybook without 01 level
Feature
Having feature where cobrix can read copybook without root or 01 level. It would check the presence of 01 record and if it's not available then it should consider as ignoring the root level like the schema_retention_policy to collapse_root. If user has provided schema retention policy to collapse_root then even if root record is not available still we should consider the root record as implicit and not to fail the code.
Proposed Solution [Optional]
Solution Ideas
1.
2.
3.

Thanks for raising the issue! I had exactly the same idea :)
We are going to implement it exactly like this.


Script to uninstall AlsaMixerFreeze added

uninstall.sh script has been added
README.md has been updated with How to uninstall section.

Adding hacktoberfest-accepted label on this pull request will be helpful for me.

Thank you for remembering me, added to PR


PaPa Iridium Smart Backhaul V.2

Is your feature request related to a problem? Please describe.
I wouldn't say that is a problem it just is a revision to the current version that is out for PaPa Iridium. Currently, PaPa Iridium only uses the RockBlock Satellite Modem the Wifi upload part of the original PaPa was taken out. But as discussed with the community and Owl it can get quite expensive sending data over the Iridium Network. So a better and smarter solution needs to be put in place of V.1.
Describe the solution you'd like
So In order to resolve this issue, I am going to make a V.2 of PaPa Iridium so that when WiFi is available it will use it. But for whatever reason a storm hits, earthquake, grid/network infrastructure goes down. The PaPa Iridium would switch back to using the Iridium Sattelite Modem until WiFi comes back online.

[x] Add WiFi Data Upload Backin

[x] Add Smart Switch Feature

[x] Update Docuementation for V.2

DishDuck V.2 is out, tested and works well.


Extend the example to show using a customised schema/block/plugin

Add a new block type, block renderer and interaction.

Added the video plugin


270-tests-for-recipes

Adding tests for all the recipes.
The recipes are moved into the clarity/ package directory.  There didn't seem to be a strong motivation for having 'recipes' outside of the clarity package. Placing everything under 'clarity' makes things a lot easier to manage and simplifies the packaging.

Adding tests for all the recipes.
The recipes are moved into the clarity/ package directory. There didn't seem to be a strong motivation for having 'recipes' outside of the clarity package. Placing everything under 'clarity' makes things a lot easier to manage and simplifies the packaging.

Asteroid and SpeechBrain have the Recipes outside the packages.
I presume this is to separate the package functionalities from the examples of using the package.
Tbh, I prefer having the recipes outside because we expect people to adapt the recipes to their needs, having the recipes inside clarity may feel more like messing with the package than modifying a recipe

OK, that's a good point. And it's best to keep things as conventional as possible. We'll keep them outside. But we'll need to adjust some of the config files to make sure that they are included in the code coverage. I'll move them back up before completing this PR

@groadabike @ns-rse - this is a bit of an epic PR but it's mostly just test coverage for the recipe code that had previously been overlooked -- there are also a few minor fixes to the recipes themselves that have been made along the way as issues were discovered. I've added a short intro at the top to make it easier to follow. A lot of files are reported as changed but these are mostly additional small files under tests/test_data.  This deals with  most of issue #270 and should mean we are at much less risk of breaking recipes when refactoring.  😄


Changed Files

@CodiumAI-Agent /review

PR Review

 ⏱ Estimated effort to review [1-5]
4, due to the extensive changes across multiple CSS and React component files, which involve both stylistic and functional modifications. The removal of several components and the addition of new styles and behaviors increase the complexity of the review.

 🧪 Relevant tests
No

 🔍 Possible issues

Duplicate IDs: The use of the same ID 'btn' for multiple elements in 'Navbar.jsx' can lead to invalid HTML and issues with CSS and JavaScript that rely on unique IDs.

Animation Performance: The extensive use of CSS animations and pseudo-elements in 'Navbar.css' and 'home.css' might cause performance issues on lower-end devices or browsers.

Removed Imports: The removal of component imports in 'Build.jsx' without a clear replacement might break functionality unless handled elsewhere not shown in the diff.
 🔒 Security concerns
No

 Code feedback:
relevant fileclient/frontEnd/src/Components/Navbar.jsx
suggestion

Replace duplicate IDs with classes or unique IDs to ensure valid HTML and prevent potential issues with CSS and JavaScript functionality. [important]

relevant lineFAQ
relevant fileclient/frontEnd/src/Styles/Navbar.css
suggestion

Consider optimizing the CSS for lower-end devices by reducing the number of complex animations and perhaps using media queries to adjust or disable them on such devices. [medium]

relevant linebackdrop-filter: blur(20px);
relevant fileclient/frontEnd/src/Components/Build.jsx
suggestion

Ensure that the functionality removed (like component imports and state management) is either no longer needed or adequately replaced to maintain application integrity. [important]

relevant lineimport '../Styles/Build.css'
relevant fileclient/frontEnd/src/Styles/home.css
suggestion

Use more descriptive class names than 'marquee1' and 'marquee2' to improve maintainability and clarity of the stylesheet. [medium]

relevant line.marquee1 span{

 ✨ Review tool usage guide:
Overview:
The review tool scans the PR code changes, and generates a PR review which includes several types of feedbacks, such as possible PR issues, security threats and relevant test in the PR. More feedbacks can be added by configuring the tool.
The tool can be triggered automatically every time a new PR is opened, or can be invoked manually by commenting on any PR.

When commenting, to edit configurations related to the review tool (pr_reviewer section), use the following template:

/review --pr_reviewer.some_config1=... --pr_reviewer.some_config2=...

With a configuration file, use the following template:

[pr_reviewer]
some_config1=...
some_config2=...

See the review usage page for a comprehensive guide on using this tool.


TiFlash crash when Aggregation FailPoints in createAggregateStates triggers

Bug Report
Please answer these questions before submitting your issue. Thanks!
1. Minimal reproduce step (Required)

Turns on Aggregation RandomFail point
Prepare TPCH database, SF=10,  run query_13.sql parrelly, you'll get core dump, and stack trace like this:

2. What did you expect to see? (Required)
TiFlash no crash.
3. What did you see instead (Required)
4. What is your TiFlash version? (Required)
v6.2.0-alpha-nightly-20220710

I try this failpoint by using master code and find there is no crash.
The bug is very likely caused by the aggregation of non-joined data after an exception happened.
In my previous attempt, I change the code line of 201 to parent.cancel(false);. https://github.com/pingcap/tiflash/blob/764bd3c9801d37b9b9157944d054846005e4080a/dbms/src/DataStreams/ParallelAggregatingBlockInputStream.cpp#L192-L202
Then the crash doesn't happen anymore because the aggregation code of non-joined data isn't triggered. (see the code below)
https://github.com/pingcap/tiflash/blob/764bd3c9801d37b9b9157944d054846005e4080a/dbms/src/Interpreters/Aggregator.cpp#L519-L529
However, this line of code doesn't change at present.
Why does the crash not happen? It's due to https://github.com/pingcap/tiflash/pull/5274.
In this PR, if an exception happens, the non-join data will not be fetched anymore so the aggregation code of them will not be triggered as well.
By the way, I think the code line of 201 still needs to be changed though it seems no harm for now.
https://github.com/pingcap/tiflash/blob/764bd3c9801d37b9b9157944d054846005e4080a/dbms/src/DataStreams/ParallelAggregatingBlockInputStream.cpp#L192-L202

Maybe we can close this issue or change the severity to minor?

The bug is introduced by https://github.com/pingcap/tiflash/pull/3434.


GitHub Action to lint Python code

Fixes # .
Changes proposed in this pull request:

Coverage increased (+0.2%) to 97.04% when pulling 579578c36d24bd06b33ae05b83c2469f44cdfef9 on cclauss:patch-1 into 1ed14fbde5be3d144760fec4982e90064f151e88 on zalando:master.

Thx for the PR @cclauss. Unfortunately it's currently outdated as we switched to github actions. You're welcome to add a Python 3.9 test suite there though (on the main branch).

Output: https://github.com/cclauss/connexion/actions

Closed in favor of #1379 and #1380


Workflow for AMRs with attached manipulators

I understand that the dispenser workcell is assumed to be some fixed automation equipment that is meant to be shared among multiple AMRs.
For AMRs with attached manipulators (e.g. robot arm), I assume it would be quite different from the current workflow.  For one, the AGV and dispenser are tied together so it's not possible to specify the pickup_dispenser and dropoff_dispenser in the Delivery.msg during task creation as that would depend on agv that gets assigned the task.
Is there any recommendations / tentative workflow for this situation?
What I currently have in mind is to just place a dummy pickup_dispenser and dropoff_dispenser such that all DispenserRequest get routed to the same "dispenser workcell adapter" and manually communicate with the fleet driver to find out which AGV is at the station and actuate the manipulator on that AGV.

I think all of the current request messages have a significant abstraction problem:

They're too low-level to be a good interface for task requests, because requesters really don't care about details like what the pickup waypoint is or what dispensers should be used.
They're too high-level to be a good interface for a complete task description, because like you're saying there are all sorts of edge cases that aren't adequately captured.

I think the current delivery task message exists the way it is because we don't have a proper task planning framework yet. At OSRC we've been extremely focused on getting the traffic planning and negotiation right that we haven't had time to really dig into task planning and negotiation.
What I would propose for the long-term is that request messages (like the delivery message) should only include fields that describe the desired outcome (e.g. deliver x item(s) to y locations) and not include any details about how it should be done. That request should be sent to a distributed task planning + task negotiation system that can gather information about what resources are available and how the task might be accomplished. That task planning system can then issue more detailed lower-level messages to command specific plans based on implementation details of how the robot subsystems work.
However, what I've described will definitely take time. There is still a lot of work that I intend to do on just the traffic planning and negotiation, so I don't have any timeline in mind yet for the task planning and negotiation.
In the meantime, I am fully on board with using dummy values as a stopgap measure. The most important thing is that the fleet adapter needs to know which "dispenser" result to listen to when deciding whether it can proceed to the next phase of its current task. That's all that the pickup_dispenser and dropoff_dispenser fields are currently being used for.

One way we could make the stopgap approach work is the following:
In the latest API of the fleet adapter, there's a function called FleetUpdateHandle::accept_delivery_request. The fleet adapter developer is expected to pass this function a callback that takes in a request message and passes back a bool.
One thing we could do is have the callback function take in a mutable reference instead of a const-reference, and then you could have your callback modify the pickup_dispenser and dropoff_dispenser fields before the message gets used by the fleet adapter.
Let me know if that sounds like a desirable approach, and then I can simply remove the const on that callback function signature.

I don't think modifying the request message is necessary for the time being, since in our case, we know before hand (when creating the delivery request), that we will be using our AGV with attached arm, so we can set the pickup_dispenser and dropoff_dispenser correctly when creating the delivery request.
On the other hand, I think it might be useful if the DispenserRequest message carried some information regarding which AGV the dispenser is to pick from / place to, e.g. a transporter_name in addition to the transporter_type in the DispenserRequest.  I believe it would be useful beyond my stopgap approach.

Discussing a revision of the DispenserRequest message definition might belong in its own thread, but could you elaborate on the use of a transporter_name field? Is the idea that if we're delivering to a patient, then we'll want something like:
transporter_type: "patient"
transporter_name: <ID of patient>

I may have misunderstood the use of transporter_type.  My understanding is it gets filled with the fleet name, in which case I think it would be useful to also include which AGV in the fleet is handling this task.
e.g.
transporter_type: "magni"
transporter_name: "magni001"

The idea is that two robots of the same transporter type should be interacted with in the same way. A transporter_name field was intentionally left out of the message definition because of the belief that a dispenser shouldn't have to care about which specific transporter it's interacting with, as long as it knows what type of transporter it is.

On second thought, I think your initial idea would make more sense.  I suppose the workflow would be upon receiving call for accept_delivery_request, after the delivery has been created and the underlying fleet manager has assigned an AGV, the FleetUpdateHandle will use this information to update the relevant _dispenser fields with the assigned AGV info.
However, this means that accept_delivery_request will need to wait until an AGV is assigned before returning.
In any case, I think removing the const on the callback function signature is a way forward.

On second thought, I think your proposal of having accept_delivery_request modify the _dispenser fields would make more sense.
I suppose the workflow would be on receiving call to accept_delivery_request, the delivery request is passed to the underlying fleet manager.  When the fleet manager has assigned an AGV, the FleetUpdateHandle will update the _dispenser fields with the relevant AGV info, which will then be available in the DispenserRequest message.
This will, however, mean that accept_delivery_request can only return after an AGV has been assigned by the underlying fleet manager.
In any case, I think removing the const from the accept_delivery_request signature is a way forward.

In the current implementation of the full_control fleet adapter, the fleet adapter is deciding which AGV to assign to the task rather than the fleet manager.
We could add a function to the fleet adapter library's API that accepts a callback where the callback gets told which AGV is assigned, and the callback can modify the fields of the delivery request based on which AGV was chosen.

I think that's a good approach

Even if the fleet adapter decides which AGV to assign, this only happens when the fleet adapter sends a follow_new_path request.  The _dispenser field cannot be populated during the accept_delivery_request.
So another option forward that maintains the fleet adapter's ability to decide which AGV to assign is to provide the candidate AGV when calling accept_delivery_request.
I'm not sure which is a better approach.

Even if the fleet adapter decides which AGV to assign, this only happens when the fleet adapter sends a follow_new_path request.

What I meant to suggest in my last post is that we could add a function to the agv::FleetUpdateHandle API that lets you give it a callback that will be triggered after the fleet adapter selects an AGV but before it triggers the follow_new_path function. That callback will be told which AGV has been selected and it will provide a mutable reference to the delivery request so you can modify its field accordingly.

So another option forward that maintains the fleet adapter's ability to decide which AGV to assign is to provide the candidate AGV when calling accept_delivery_request.

This wouldn't be ideal because the accept_delivery_request gets triggered before an AGV is selected. I would rather not have the fleet adapter waste effort on selecting an optimal AGV for a task if we aren't going to accept the task anyway.

I see, that would work also

Closing as this is not an issue. To continue discussing this topic, please open a discussion.


Need more tests for capes

test coverage is really bad

If you specifically mean that file, it's an issue with all of the routes, mainly because of the etag code.

It seems like there is no test that would actually return an image


origin-web-catalog does not honor updates_to on plans

We specify in the dev plan that it can be updated to prod in the updates_to array in the dev plan and I can do that. (see comment at: openshift/origin-web-console#2350 for catalog output.)
However we don't specify that prod can be 'downgraded' to dev (the updates_to array is empty and omitted in the catalog output, but the UI still lets me try to do that.
@eriknelson @jmrodri @pmorie @spadgett This was in the proposal I was working off in our docs, though it looks not to be in the broker spec.
https://github.com/openshift/ansible-service-broker/blob/master/docs/proposals/updates-first-pass.md#apb
I don't know how you'd all like to proceed.

@jwforres

The UI appears to remove the Edit option when we fail to update
I see
Status:
    Failed
Status Reason:
    Error updating ServiceInstance of ClusterServiceClass (K8S: "27793015fe45db2fbc1deb7372cc4036" ExternalName: "dh-rhscl-postgresql-apb") at ClusterServiceBroker "ansible-service-broker": Status: 400; ErrorMessage: <nil>; Description: plan update not possible; ResponseError: <nil>

and no more option to edit. Would it be possible to retain the option to edit even though the update task failed?

Without a mechanism to validate possible plan transitions from the UI side, the broker can only handle the validation server-side by returning an error that it is not allowed. So @jmontleon point is valid that we will need to continue edit.

@jeff-phillips-18 How hard is it to re-enable the back button to make additional changes on errors?
Depending on the size of this change, it might have to come post 3.7.

Should be able to do that relatively easily. I think the issue here is allowing Edit on service instance's with a failed state. Can we tell the reason for failure? Should we allow edit of all failed instances?

Is the service permanently failed if an update fails? That seems bad.
cc @jwforres

Seems like it stays failed 😢

@spadgett @jmrodri How should we proceed here? Allow edit of failed instances?

Can someone clarify for me what the "updates_to" array is?

the updates_to identifies what plans can transition to what other plans. That is you can go from dev to prod and prevents prod going to dev.

Right now I'm looking through our catalog response and it seems we have an updates_to which is not spec compliant. So it makes sense as to why it is not being respected.
The larger issue is that if we use the current mechanism, of doing server-side validation, we will return an error if the plan transition is invalid. Which as stated https://github.com/openshift/origin-web-catalog/issues/533#issuecomment-339458438 the instance is marked as failed forever.

updates_to is some internal implementation detail of the ansible broker, right?

Closing as this is now tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1507844


Enhance Behavior With Action and Validation

Tutorial URL: https://developers.sap.com/tutorials/abap-environment-behavior-action.html
Please specify the step you are referring to: step 4
For the action implementation - the generated code defines method 'acceptTravel' but the example code uses method 'set_status_completed'.

Hi @sedacrivity ,
'acceptTravel' is the action that is needed for the method 'set_status_completed'. Therefore you need both.
Best regards,
Merve

Thank you for your feedback. The issue seems to be resolved, so I am closing the issue.
If you still have questions, feel free to reopen the issue.

@mervey45 @MichaelCzcz
You are misunderstanding my comment.
I followed the tutorial using the latest updates of the eclipse addons and the source code generated is different from your tutorial.
The behaviour implementation class no longer has a method 'set_status_completed' but a method with the same name as the action.
METHODS acceptTravel FOR MODIFY
  IMPORTING keys FOR ACTION Travel~acceptTravel RESULT result.

`CLASS lhc_Travel DEFINITION INHERITING FROM cl_abap_behavior_handler.
PRIVATE SECTION.
TYPES tt_travel_update TYPE TABLE FOR UPDATE zi_sds_travel_1_m.

METHODS CalculateTravelKey FOR DETERMINATION Travel~CalculateTravelKey
  IMPORTING keys FOR Travel.

METHODS validateCustomer FOR VALIDATION Travel~validateCustomer
  IMPORTING keys FOR Travel.

METHODS validateDates FOR VALIDATION Travel~validateDates
  IMPORTING keys FOR Travel.

METHODS acceptTravel FOR MODIFY
  IMPORTING keys FOR ACTION Travel~acceptTravel RESULT result.

METHODS get_features FOR FEATURES
  IMPORTING keys REQUEST requested_features FOR Travel RESULT result.

ENDCLASS.`


:s/<exact_match> /substitution/g    --> not working

The title pretty much says it but specifically,
I was trying to replace instances of vector with vector
using
:%s/<round>/nround/g     ***
I've investigated a little,
note that the above command is effectively executing the following (instead of substitute for exact match)
:%s//nround/g     ***
EDIT: I've just noticed that the 'github flavored markdown' is messing with the *** lines.  My intended string of characters, for example, shows correctly in the subject line but in the body github is parsing the back-slashes and <, > characters.  Does anybody know what is the github escape character (like back slashes in bash)?  Thanks

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/1446111-s-exact_match-substitution-g-not-working?utm_campaign=plugin&utm_content=tracker%2F252770&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F252770&utm_medium=issues&utm_source=github).

I have encounter the same problem too


Tests hang randomly on iOS and throws timeout error

Describe the bug
When I run the tests, sometimes it finish successfully and sometimes it hangs and throws a timeout error. Async callback was not invoked
It also throws a warning:
detox[12393] WARN:  [Client.js/PENDING_REQUESTS] App has not responded to the network requests below:
  (id = 4) invoke: {"target":{"type":"Invocation","value":{"target":{"type":"EarlGrey","value":"instance"},"method":"detox_selectElementWithMatcher:","args":[{"type":"Invocation","value":{"target":{"type":"Class","value":"GREYMatchers"},"method":"matcherForAccessibilityID:","args":[{"type":"NSString","value":"login_button"}]}}]}},"method":"performAction:","args":[{"type":"Invocation","value":{"target":{"type":"Class","value":"GREYActions"},"method":"actionForTap","args":[]}}]}

That might be the reason why the test "UAT_Login Incorrect username" has timed out.

The test is visually finished, but detox keeps waiting. Like if detox doesn't know that the test is completed.
To Reproduce

[x] I have tested this issue on the latest Detox release and it still reproduces

Running the tests with: detox test -c [configuration] [spec file]

It happens when the tests contains the .tap() action
Expected behavior
Run the tests with the same result every time they are launched.
Environment:

Detox: 13.1.1
React Native: 0.59.1
Node: v10.15.2
Device: iPhone 7
Xcode: 10.2.1
iOS:
macOS: 10.14.5

Device and Verbose Detox Logs
logs.txt

Please follow this guide: https://github.com/wix/Detox/blob/master/docs/Troubleshooting.Synchronization.md#lower-level-idling-resources-rebug-ios-only
Reproduce and post the result here. Thanks

The logs with a failing test (it has the .tap() action) are huge. You have them here:
https://drive.google.com/open?id=16MY79ZPErHdxY4FY1OUPXHD_c1wwDip1
To compare, here are the logs with a successful test (without the .tap() action).
log.txt

The link provided requires permissions. Can you please upload here: https://gist.github.com/

Sorry, It is impossible to upload the file there. I gave permissions to the file on drive. Try it again with this link.
https://drive.google.com/file/d/16MY79ZPErHdxY4FY1OUPXHD_c1wwDip1/view?usp=sharing

@LeoNatan Sounds very similar to the issue I'm having where the App will close it self after detox has launched it when using detox version 13.0.3 or above. This happens on my local machine and 2 other clients and all three works fine with 13.0.2 or lower.
Once the app has been closed, detox will just wait until the test time out and attempt to start the next test suit.
By using the Debugging in Xcode During Detox Tests trick I see that the app crash as
void)applicationDidBecomeActive:(UIApplication *)application Thread 1: EXC_BAD_ACCESS (code=2, address=0x7ffeead66ff8)
after it has been called 34872 times.
I think this is a bug that is introduced in #1511 .

@juandiegombr WXAnimatedDisplayLinkIdlingResource is busy, meaning there is an endless animation. Please mock that or stop the animation during testing
@lapto Your issue is followed in #1525. Please see my request there and follow it and provide the log output. Thanks

Yes, you are right. It was an animation that was not working properly. It confused me because the error happened sometimes, not always.
Thank you for your attention.

Cheers!


simplify anormal pass

Seems reasonable, what's the story here?

the conversion to ANF is renaming way more variables than it needs to, and we should be able to take advantage of the fact that the input program never has shadowing, in order to limit renaming variables.
but this implementation is wrong, I just found a case which fails:
let a = (let b = 0 in b + 1)
\b. a + b

==>

let b = 0
let a = b + 1
\b. a + b

actually, it wasn't the renaming that was taking so long, it was the fact that the bookkeeping for what to rename was done in a separate pass, as well as converting a list to a set on every iteration.

A fact with 200 int fields
feature ints200 ~> group a1 ~> latest 1 ~> fields

45.2s -> 3.44s

!!!

45.2s -> 3.44s

Wow!!

yeah, it's crazy!

I can only imagine how bad it is for a 500 field struct

let's find out!

918.87s -> 31.56s

unreal

Winning, going to make a huge difference

:100:


Change Cupertino page transition box shadow to a simple custom gradient

Creates another Decoration for drawing outside the decorated box with a gradient to emulate the shadow.
Lets the cupertino transition page's background be transparent.
Fixes #9321


Trouble signing in

I have deployed the code into a web app in azure but when i try to access the web app, it gives me the below error.
AADSTS50011: The reply url specified in the request does not match the reply urls configured for the application: '1be*****************6d91475'.
the redirect url for the app service i have given is "https://twinsvisualizer.azurewebsites.net/"

Hi @sanyam8182,
the redirect URL you mention was part of the example. Please enter the URL of the web app you have deployed there.

"https://twinsvisualizer.azurewebsites.net/" is the url i have given for the app service in active directory.


Latence after changing route and return to builder page

Hi, first i want to thank you for this greet work, i'm using your project in a new project where users can build their own store, the problem i'm facing is when changing pages and return to the store builder page the builder  begane to be too slow, any idea on how to fix performance slow ??

Thank you for your feedback. From what I've read though, there is nothing tangible that I can start from.
Performance issues can occur due to many reasons, especially that the builder performs well on its own.
Maybe you can give we a working example or access to your project, so I can help more on debugging this issue.

Hi, thx for the reply, to reproduce the issue juste go to the builder example page ( https://baianat.github.io/vuse/example.html ) -> select theme 1 -> click on go back button ( browser ) and repeat it at least five times, you will see that scroll page became too slow.
After hours of debugging i've found out that the probléme were with "popper.js" which installs listeners on scroll page event, after i've disabled it with the option : eventsEnabled:false, it seems that the problém was solved.

The actual problem here is that the styler instances is not destroyed when routing (you can see it still living in the DOM) so its events will still be active too.
Calling $builder.clear() it will clear all sections and it's styler component.


Refactored JS logic

This pull request introduces significant changes to the existing JavaScript codebase. The main objective of this PR is to improve the code's readability, structure, maintainability, and scalability by refactoring the existing function-based code into a Class-based structure.

Class-bases layout became more readable.


404 at: /docker-for-mac/index/

URL: /docker-for-mac/index/
Accessed from: https://store.docker.com/editions/community/docker-ce-desktop-mac/plans/docker-ce-desktop-mac-tier?tab=instructions under

Documentation
To learn more, read the Docker for Mac documentation.

Many thanks.

@nandhini can we work together to get some links fixed on Store?

On the Docker for Mac Store page, both the main docs and "Where to go next" links don't work per the feedback above: https://store.docker.com/editions/community/docker-ce-desktop-mac/plans/docker-ce-desktop-mac-tier?tab=instructions

For the main docs link, we have index in the path and it shouldn't be there. The proper links are:
https://docs.docker.com/docker-for-mac/
https://docs.docker.com/docker-for-mac/#where-to-go-next

On Docker for Windows Store page, the first link to the docs works, but the second one, Where to go next, is broken. This should be: https://docs.docker.com/docker-for-windows/#where-to-go-next

Let me know if you need more info or want to look at these together.

The Docker for Mac and Docker for Windows pages are both fixed now. Links should be valid and point to https://docs.docker.com/docker-for-mac/, https://docs.docker.com/docker-for-mac/#where-to-go-next for Mac, and https://docs.docker.com/docker-for-windows/#where-to-go-next for Windows.

@peternicholls All are fixed now, closing this issue. Thank you so much for the feedback!
@nandhini915 thanks, you are awesome!!!


/sell all

They issue broken only /sell all we cant sell item is something wrong with code $item = $sender->getInventory()->getItemInHand(); becuase is only hand on sell all commands

what? I don't get you. If there's an error in the console, could you please paste it in here?

you should test when i give stone then i sell /sell all is said you cant sell item they already have config

for me it works perfectly fine. Could you maybe record a video and send it? Also, did you check if you didn't accidently changed something in the config. When you change the config you also have to reload the server for the changes to happen


feat(e2e): Added bicep template to help generate the ARM template

Bicep is a Domain Specific Language (DSL) for deploying Azure resources declaratively. It aims to drastically simplify the authoring experience with a cleaner syntax and better support for modularity and code re-use. Bicep is a transparent abstraction over ARM and ARM templates.
This PR creates a Bicep template to deploy the resources needed in our ADT tests. It seems very readable and easy to use. After the Azure Connect day, we decided to give this a try and I have been happy so far and looking forward to feedback.
Note: The ARM template is now auto generated by the command - bicep build 'test-resouces.bicep'

are you going to update the setup script to also generate this ARM template? what extensions do we need to install?

I would start adding notes to the readme file. we have to note that we should stop hand editing the ARM template and always generate using the bicep

are you going to update the setup script to also generate this ARM template? what extensions do we need to install?
We don't need to update the script. The script just points to the generated ARM template, which has been done manually. However, it is a good idea to probably do the bicep build in the script itself to save us a step. But for the pipelines, we will have to ensure that when we change the .bicep file, we have to run the bicep build and check in the updated arm template.

are you going to update the setup script to also generate this ARM template? what extensions do we need to install?
We don't need to update the script. The script just points to the generated ARM template, which has been done manually. However, it is a good idea to probably do the bicep build in the script itself to save us a step. But for the pipelines, we will have to ensure that when we change the .bicep file, we have to run the bicep build and check in the updated arm template.

I recommend adding a pre setup script that the pipeline automatically runs and run the ARM template generation in there. that will ensure we use the latest up-to-date script

are you going to update the setup script to also generate this ARM template? what extensions do we need to install?
We don't need to update the script. The script just points to the generated ARM template, which has been done manually. However, it is a good idea to probably do the bicep build in the script itself to save us a step. But for the pipelines, we will have to ensure that when we change the .bicep file, we have to run the bicep build and check in the updated arm template.

I recommend adding a pre setup script that the pipeline automatically runs and run the ARM template generation in there. that will ensure we use the latest up-to-date script

If that is possible, it is a great idea. Will sync with you on adding that.

I would start adding notes to the readme file. we have to note that we should stop hand editing the ARM template and always generate using the bicep

yes updating the readme and 1N will come next, if we all decide to go ahead with this :)

are you going to update the setup script to also generate this ARM template? what extensions do we need to install?
We don't need to update the script. The script just points to the generated ARM template, which has been done manually. However, it is a good idea to probably do the bicep build in the script itself to save us a step. But for the pipelines, we will have to ensure that when we change the .bicep file, we have to run the bicep build and check in the updated arm template.

I recommend adding a pre setup script that the pipeline automatically runs and run the ARM template generation in there. that will ensure we use the latest up-to-date script

If that is possible, it is a great idea. Will sync with you on adding that.

absolutely, I can show you how that is done, I think if we get that in and have a script to build the bicep, we can call this good to go

build bicep script.
call the build script during setup.ps1
call build script during pre-resourcedeployment script to ensure we run the latest ARM template.

Added tasks for that. Will be working on those tasks next.

/azp run new -digitaltwins -tests

/azp run net -digitaltwins -tests

/azp run new - digitaltwins -tests

/azp run net - digitaltwins - tests

/azp run net - digitaltwins - tests


It is possible to use production build react version rather than development version

Hi,
I have successfully implemented react inside angular project, and it looks great.
I have encountered a minor issue though. When I deploy my code to production environment, I am getting warning message from react:

It looks like you're using a minified copy of the development build of React. When deploying React apps to production, make sure to use the production build which skips development warnings and is faster.

Is there a way that I can really use the production build of react in order to avoid this warning message?
If it matters, I use grunt-babel with es2015 presets + transform-react-jsx plugin.
Thanks!

I have override for this in wiredep task of my gruntfile.js
      overrides: {
      'react': {
        main:  [
          'react.min.js',
          'react-dom.min.js'
        ]
      }
   }


Test integration test apps' runner files against current template app

Add a script and CI test to ensure that the files present in the Windows subdirectories for integration tests match those of the app template in order to ensure that any changes made to the template are reflected in the integration tests.
Part of https://github.com/flutter/flutter/issues/118643
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[ ] I signed the CLA.
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is test-exempt.
[x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

+1 to Chris's ignore list suggestion https://github.com/flutter/flutter/pull/118646#discussion_r1073924126, that seems like a great idea 👍
(Sorry for the new thread, for whatever reason I can't reply to your comment)


[Documentation] Added code examples for the save_png method of Image

I've added some more information regarding the "path" parameter of this method and I've added a code block containing two informative examples.
I'm not sure if this pull request should be against the master branch or against the 3.1 branch.
Please advise as I hope to continually contribute documentation.

it's fine while running with editor but saving a file in res:// is prohibited on most platform with exported game.
for exported game, better to use user:// path.

@volzhs Good point. I'm going to rewrite this to have a single example and refer the reader to the filesystem page.


properly quote commands

This is a start of a fix to #73; I'd like feedback on this code. If you like it, I can fix the other commands as well.
The TL;DR is that you should pass each arg separately, so they get quoted properly, rather than use string formatting to create the command. I tried to modify the surrounding code as little as possible.

Yes I agree and your fix looks good to me.


Youtube Music failed to remove Ads

I used QX and utilizing this awesome Javascript, but today it can’t block the Ads inside the Youtube Music. It was worked before.
“Update”
The YTM lyric translate, button block function still works, only the Ads appeared again.

same in youtube

#63


[Bug]: Querying a column of type datetime(3), the result set displays a precision of only 2 bits

ODC version
4.2.3
OB version
<IP_ADDRESS> （May any version）
What happened?
ODC query for a column of type datetime(3) shows only two millisecond values, while the command line displays them normally.
What did you expect to happen?
Demonstrate correct accuracy.
How can we reproduce it (as minimally and precisely as possible)?
(Ditto)
Anything else we need to know?
No response
Cloud
No response

great

pass


Fix shouldn't have eslint-plugin-prettier

Plugin wasn't used and what we have is eslint-config-prettier that disable the formatting rules to delegate to prettier

:x: There is undocummented changes. Run chronus add to add a changeset or click here.
The following packages have changes but are not documented.

:x:@typespec/eslint-config-typespec

To recap:

eslint-plugin-prettier - bad, prettier via eslint
eslint-config-prettier - good, disables eslint rules conflicting with prettier (as this assumes prettier is run stand-alone)

You can try these changes at https://cadlplayground.z22.web.core.windows.net/prs/3100/
Check the website changes at https://tspwebsitepr.z22.web.core.windows.net/prs/3100/


Add requests.Session(timeout) parameter

...as a parameter which gets inherited globally by get() and other HTTP methods.
session = requests.Session(timeout=30)
session.get(...)
session.get(...)

Would be equivalent to:
session = requests.Session()
session.get(..., timeout=30)
session.get(..., timeout=30)

Thoughts?

Thanks for opening this! This is a duplicate of #3341: please read the discussion there for more.

Oh sorry about that.


inline lookup feature

When populating tables with key values, it's hard for users to have access to those keys and build spreadsheets manually with them. It would be a lot easier for the user to upload spreadsheets that have text values that we can automatically, silently convert to matching key values.
The idea here is to have an InlineLookup object. You'd use this after a normal upload, so there's no change to the core upload behavior.
You new up an InlineLookup<T> where T is the key type (typically int). You also specify the raw upload (source) table along with the output table that will store the results of all your attempted mappings. You also pass one or more Lookup objects that describe the mappings in use. We create blank rows in the output table to match the input, then update the result based on your defined joins:
var inlineLookup = new InlineLookup<int>("excel.RawSalesData", "excel.SalesDataKeyColumns", new Lookup[]
{
    new Lookup("RegionName", "RegionId", "dbo.Region", "Name", "Id")
});

using (var cn = GetConnection())
{
    await inlineLookup.ExecuteAsync(cn);
}

See the test showing this in use.


Logging returns true

See #64
Types of Changes

Logging methods (like Console.info) consistently return true regardless of Output

Contribution

[x] I added tests for my changes.
[x] I tested my changes locally.
[x] I agree to the Developer's Certificate of Origin 1.1.

Just realized, that this is not complete yet. A log not matching the current filter will still return nil. For example, with log level info Console.debug("test") will return nil

This looks somewhat reasonable to me.
I think if we had to establish a behaviour, it should be that the log operation returns truthy if it does something and falsey otherwise.
I believe if filter ... end already returns falsey if it isn't logged.
Regarding the other cases, I'm okay for them to return true if something was logged or not.
What do you think?

I have two thought:
1st: I assume ::Logger uses true as a universal return value to allow for log("message") and do_something_else
2nd: Personally, I like to have a consistent return value. My code should not need to care if the log has been written or not.
Consider this code
def do_something
  # more code
  Console.error("we did something") unless it_was_done
end

Now, in tests and development, you'll probably have error logging on, but in production, you might raise the log lever to fatal. Suddenly your method would return a different value.
If we ensure logging returns a uniform value, application code can rely on that and do what's right.
I've went ahead with returning true just because Console already returned truthy values (and a little bit to mimic ::Logger). I would be totally fine changing this and returning nil everywhere.

If we are planning to return nothing why not always return nil?

I've decided to go ahead with always returning nil from Console::Filter.
Honestly, I could see different ways this could be implemented. Returning true/false is also interesting, because it might allow conditional behavior (if this was not logged, do something else). The question of whether something is logged or not, however, IMHO, should not affect program behaviour. So, I decided not to encourage that. In addition, returning true might encourage users to use Console... in a conditional and I also don't want to encourage that either.

Thanks for your contribution, closing in favour of #68.


Add RegExp.prototype[@@search]

Hi @goyakin, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Gorkem Yakin). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

@kunalspathak & @abchatra, could you take a look?

LGTM.


[test][multistage] enhance query plan test

optimized query physical plan to omit all mailbox

non-leaf will also get omit
multiple worker within a server will also get omit
all places with contextual info are now

printed as the following format: <PREFIX>[<FRAGMENT_ID>]@<HOSTNAME>:<PORT>|[<WORKER_ID>],
with multiple instances of the context, the format will be wrapped in { and } in a comma-separated list.

...
              └── [1]@localhost:1|[1] PROJECT
                  └── [1]@localhost:1|[1] JOIN
                      ├── [1]@localhost:1|[1] MAIL_RECEIVE(HASH_DISTRIBUTED)
                      │   ├── [2]@localhost:2|[2] MAIL_SEND(HASH_DISTRIBUTED)->{[1]@localhost:2|[2, 3],[1]@localhost:1|[0, 1]} (Subtree Omitted)
                      │   ├── [2]@localhost:2|[3] MAIL_SEND(HASH_DISTRIBUTED)->{[1]@localhost:2|[2, 3],[1]@localhost:1|[0, 1]} (Subtree Omitted)
...

support other plan parsing in ResourceBasedQueryPlansTest

regex replace supported feature such as AS ..., ...ATTRIBUTES
WITH ... is not supported as we don't actually have corresponding processing on this variance yet.

This also addresses the verbose issue of subtree omit in #11272

Codecov Report

Merging #11966 (bd038c3) into master (45f1869) will decrease coverage by 14.97%.
Report is 2 commits behind head on master.
The diff coverage is 100.00%.

@@              Coverage Diff              @@
##             master   #11966       +/-   ##
=============================================
- Coverage     61.43%   46.47%   -14.97%
+ Complexity     1135      931      -204
=============================================
  Files          2385     1787      -598
  Lines        129150    93574    -35576
  Branches      19994    15138     -4856
=============================================
- Hits          79347    43489    -35858
- Misses        44049    47020     +2971
+ Partials       5754     3065     -2689

Flag
Coverage Δ

custom-integration1
?

integration
?

integration1
?

integration2
?

java-11
?

java-21
46.47% <100.00%> (-14.84%)
:arrow_down:

skip-bytebuffers-false
46.47% <100.00%> (-14.94%)
:arrow_down:

skip-bytebuffers-true
?

temurin
46.47% <100.00%> (-14.97%)
:arrow_down:

unittests
46.47% <100.00%> (-14.96%)
:arrow_down:

unittests1
46.47% <100.00%> (-0.20%)
:arrow_down:

unittests2
?

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

Files
Coverage Δ

...inot/query/planner/PhysicalExplainPlanVisitor.java
88.29% <100.00%> (+0.79%)
:arrow_up:

... and 986 files with indirect coverage changes
:mega: Codecov offers a browser extension for seamless coverage viewing on GitHub. Try it in Chrome or Firefox today!


Fix more left-overs from local code

Change form url from "core:search" to "lite_cms_core:search"
Remove references to not public available module "frontend_auth"
Decide on icon set, currently django-bootstrap-icons is another dependency, document or remove

Maybe copy some icon svgs to project to avoid another dependency


mup setup fails silently

mup setup is yielding nothing on the command line ( after doing mup init and editing the settings ).
mup deploy shows "Building App Locally" but nothing seems to happen afterwards.
I was using mupx and done dozens of deployments but out of the blue without any aparent change on server or client the deployments stopped working.
it seems to be very hard to get this right because i tried mup before docker, then mupx, then meteor-up now and all of them seems to have real issues making this smooth.
mupx used to work 100% smooth until yesterday with my ubuntu server / Darwin local computer.
Today it simply don't work anymore even on a new linux server.
really frustrating.
thank you a lot for your work and efforts tough

Hey @hems i'm getting the same "silent fail" behavior, very frustrating... Did you get anywhere with this?

the same! what is possible solution guys?

@git4t3ch / @fishdude i noticed some other project i had actually still deploy, so i'm wondering if that is something to be with an npm package or even if an specific meteor version ( although i didn't update my meteor project ).
My temporary solution was to copy the project to the server old school way ( rsync + ssh ) to my server and it worked okay for me, at that point my project wasn't anymore working inside a docker docker so I also had to install mongodb on my server, backup the old mongo data from inside docker and import into the new one.
hope that helps somehow

Maybe post your config to see if anything looks out of the ordinary? I'm using meteor-up with meteor <IP_ADDRESS> and all is working fine.
Do you get anything in the logs?

I'm also seeing this. This is on an existing server where I was running mupx previously, but am not running into issues with the updated nodejs libraries and have moved to this meteor-up version using the abernix/meteord:base docker image.

Anyone find a fix for this? I too am just moving from mupx. I copied and pasted a lot of the config, but I think I got everything. I'm not able to use a clean server right now....
ubuntu@ip-172-31-11-0:~/mercury-dev/.deploy$ mup logs -f
ubuntu@ip-172-31-11-0:~/mercury-dev/.deploy$ DEBUG=* mup setup
  mup:module:default exec => mup setup +0ms
  mup:module:docker exec => mup docker setup +15ms
ubuntu@ip-172-31-11-0:~/mercury-dev/.deploy$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
ubuntu@ip-172-31-11-0:~/mercury-dev/.deploy$ DEBUG=* mup deploy
  mup:module:default exec => mup deploy +0ms
  mup:module:meteor exec => mup meteor deploy +1ms
  mup:module:meteor exec => mup meteor push +15ms
Building App Bundle Locally
ubuntu@ip-172-31-11-0:~/mercury-dev/.deploy$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

My mup.js looks like:
module.exports = {
    servers: {
        one: {
            host: "xx.x.xxx.xx",
            username: "ubuntu",
            pem: "~/dev.pem"
        }
    },

    meteor: {
        name: 'mercury',
        path: '/home/ubuntu/mercury-dev',
        port: 80,
        servers: {
            one: {},
        },
        buildOptions: {
            serverOnly: true,
        },
        env: {
            ROOT_URL: "https://xyz.com",
            MONGO_URL: "mongodb://<IP_ADDRESS>:27017/mercury"
        },
        dockerImage: 'abernix/meteord:base',
        deployCheckWaitTime: 60,
        enableUploadProgressBar: false,
        ssl: {
            crt: "/etc/nginx/certs/chained.pem",
            key: "/etc/nginx/certs/key.pem",
            port: 443
        }
    }
};

Any help would be awesome! Thanks!

Your pem path has a ~ which wasn't supported. I just released mup 1.2.1 which included a fix for that.

Wow, thanks for the quick reply!
That was it, got me past the silent fail.

@zodern thanks for the takeover & the feedback
I have a pem path with ~ I am on mup 1.2.1 but this does not seem to work it just fails silently

Does it work if you make it an absolute path without the ~?


Gracefully handle db connection limits

Split out from https://github.com/matrix-org/sliding-sync/issues/230. I forgot the Roadmap label.

Code has landed, pending deploy & testing.


fix: script intallation

There is a problem with the sudo command in the script during installation!

duplicate of #23

Fixed by #25


Write support for s3 gateway

Builds on #3411 to provide write support.
This should have docs. I could either add them in this PR, or open a separate PR with them once this is merged.
Fixes #257.

Beyond this PR and the last one, there's still 2 TODOs:

docs
dropping in the code to actually start the server (outside of tests.)

Should I just keep iterating on this PR, or wait until this is done and open a third with those changes?

Another note; this is being tested against minio, but not any other S3 clients. It's not clear to me whether this includes minio-specific extensions that could somehow cause issues for more vanilla S3 clients. This'll be easier to check for once the server is exposed somewhere.

Should we only expose this through TLS? I'm inclined to say yes, but it does imply configuration overhead.

I'd say start a new PR, since this one is LGTM and can be merged.
That's a good point about other s3 clients. The only other client I know, besides the official amazon one's which afaik can't be targeted at non-s3 endpoints, is boto, we should definitely test that one to see if anything lights up.
My instinct would be that there should definitely be a way to expose this over TLS but it'd be a pain if that was the only way to access it because it would mean people needed to go through some configuration overhead just to get things started, which might derail a lot of people early on.


Fixed broken link to examples

Case-sensitive typo

I'll submit a consolidated PR with all of the broken links

Oops, one to many global edits to fix a spelling mistake.
On Sat, Apr 22, 2017 at 6:40 AM, Robin Ury<EMAIL_ADDRESS>wrote:

I'll submit a consolidated PR with all of the broken links
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/feathersjs/feathers-docs/pull/541#issuecomment-296364691,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABezn4PPK5yDkfUTlm4_QX_fcFNq1Lj-ks5rydkwgaJpZM4NFC8p
.

@eddyystop ?

Sorry I wasn't clear. That's how  my typo occurred.


Firebase Products Depending on Core

After upgrading the plugins to the latest release, why is it required now to use firebase_core and initialize it first before using any other firebase plugin?
In android native for example, you can just add the dependency related to cloud firestore or any other product and use it immediately in your code.
Before we had to use it, but it was changed later on:

The Firebase Android library firebase-core is no longer needed. This SDK included the Firebase SDK for Google Analytics.

Now, to use Analytics or a product that recommends the use of Analytics (see table below), you need to explicitly add the Analytics dependency: com.google.firebase:firebase-analytics:17.5.0 or com.google.firebase:firebase-analytics-ktx:17.5.0.

https://firebase.google.com/support/release-notes/android
Also back then we needed to only add firebase-core as a dependency in the gradle file, but we didn't need to even call initializeApp(), according to the documentation:

For a vast majority of apps, FirebaseInitProvider will handle the initialization of Firebase for the default project that it's configured to work with, via the data contained in the app's google-services.json file. This ContentProvider is merged into the app's manifest by default when building with Gradle, and it runs automatically at app launch. No additional lines of code are needed in this case.

https://firebase.google.com/docs/reference/android/com/google/firebase/FirebaseApp

Without going into too much detail, the main reason for this change is to allow the initialisation of constant values, which helps us to align the API with the JavaScript API. For example, in the previous versions to check whether the currentUser on the Authentication module exists required an async call to native, now this is pre-populated when calling initializeApp().
I'll close this since it's a none issue, however happy to discuss.


Add Code Climate repo token to Circle CI yaml

Pulling this configuration value into the circle.yml file allows
cross-origin PRs to submit test coverage successfully.
@codeclimate/review :mag_right:

LGTM