Fix issue #70. Added recursive removal on Windows.

Do you think it's better to

Delegate delete_recursive on non-windows machines to the typical delete function, or
(vice versa) Delegate delete on windows machines to recursively delete?

Advantage of 1 is that it would be backwards compatible, advantage of 2 is that the API would seem more unified and likely more intuitive. I lean towards 2, but don't have a strong opinion.

Thanks for making this proposition! I didn't see 1) as I thought that delete_recursive() would only be required on windows in the first place. However, I don't think this is validated yet unless the test is enabled for all platforms.
With that said, I think delete_recursive() shouldn't be necessary on non-windows platforms, but there is no issue in adding it if it turns out to be necessary after all.

So is there consensus on the best way to move forward with the API and testing? If so, what would that be?

I think it would be best to start running the test on all platforms - it's still the expectations that the trashing of directories works on some platforms already.

Can do. And in terms of the API, should delete_recursive be added to all platforms, left just on Windows, or incorporated into delete on Windows?

That depends on the outcome of the test. I think everything coming from that was already written in my previous comments.

Thanks a lot!
The fix was released as well.


Update FindMaxTest.java

Describe your change:

[ ] Add an algorithm?
[ ] Fix a bug or typo in an existing algorithm?
[x] Documentation change?

References

Checklist:

[ ] I have read CONTRIBUTING.md.
[ ] This pull request is all my own work -- I have not plagiarized.
[ ] I know that pull requests will not be merged if they fail the automated tests.
[ ] This PR only changes one algorithm file. To ease review, please open separate PRs for separate algorithms.
[ ] All new Java files are placed inside an existing directory.
[ ] All filenames are in all uppercase characters with no spaces or dashes.
[ ] All functions and variable names follow Java naming conventions.
[ ] All new algorithms have a URL in its comments that points to Wikipedia or other similar explanation.
[ ] If this pull request resolves one or more open issues then the commit message contains Fixes: #{$ISSUE_NO}.

transfer values


Make Lazy an interface

Btw - regarding lazy values we now get the return of invest that most of Javaslang's types are designed as interface. :feeling proud:

Lazy itself will not be proxied. We will better not change the class vs interface design at this point.


Adding new npm maintainers

I've been slow to respond to issues recently, mostly due to going on vacation for the past few weeks.
I'd hate to see progress stalled on this project due to my own lack of free time, so if the other maintainers could please post their npm usernames here, I'd be happy to add them as npm authors so that they can publish. :)

I'm rsutphin there, too.

Thanks for the trust, btw.

:+1:

:+1:

@rsutphin You are an owner in npm now. Great power, great responsibility, yada yada. :wink:
My only advice is to use your best judgment and look for +1s from the community before merging something. I'm happy to advise on PouchDB-related issues, but I admit that I haven't used Ember in a long time, and so I'm really out-of-date with changes in Ember Data. At work, we use React and YUI, and in my personal projects I'm mostly using Angular or raw DOM, so that's another reason I'm not able to keep up.
I'm really touched and honestly kinda blown away by how the community really picked up this plugin and ran with it. I think it's a testament to the Ember community; I've never seen any other group so eager to roll up their sleeves and make one of my libraries better. At some point, if I really drop off the face of the Earth, I'd be happy to create a Github organization or something so that it's no longer under my name, but I'll let you all be the judge of when it's time to do that. :)
Thanks so much, and awesome job to everybody involved.

@nolanlawson Sad to hear that you take a step away from this repo, but after I've stumbled upon your name in blogs and GitHub related projects so often lately I was thinking this guy has either no free time or owns a second parallel universe where he can load balance some tasks. Thank you for the Ember plugin, it is a key component of a project I am working on.
@rsutphin Good to hear that you take responsibility for npm. I am really confident that you are the right guy for this.

@OleRoel That parallel universe is called my personal life, which I basically haven't had for the past year or so. ;) Thanks for understanding!

I've published 2.0.2 with @OleRoel's fix for #72. Thanks again for your trust, @nolanlawson. I know we all appreciate the work you do on PouchDB itself and your other contributions (I've learned a lot from your PouchDB blog posts).

Thanks, and I really appreciate you swooping in to help out.  :) Many people don't realize that open-source software is a full-time job (in addition to our regular jobs!), so it's so helpful when I don't have to spread myself so thin. :)

Leaving this issue open in case anybody else wants to be added as a npm owner. @broerse I realized I didn't even add you as a Github collaborator (my bad, sorry!), but you are one now.

@nolanlawson Thanks. I hope I can help out.


parse_gctx.py performance improvements

I'm not sure if this is the same or a different issue from what @shababo brought up the other week. But parsing the GCTX file takes ~8 times longer than loading the same data via pd.read_table when loading subsets of data. It is ~2X slower when loading the full matrices. It's unclear if the compression is the same on these files. I hadn't noticed this previously as I typically was loading once and often loading only methylation via the *.tsv.gz files.

Tagging @bsiranosian @ANaka for visibility and to bring the discussion into github.

cc @shababo

Yes, this is exactly what we observed - roughly 2m30s to parse the methylation when saved as gctx. We were able to bring this down to roughly 7 seconds - IIRC - by loading the methylation matrix from an uncompressed h5 file. That said, this might still be slower than other options, e.g. loading from npy. There is also a newer file type that is potentially faster than h5 for python called zarr.
There are a few axes to consider when optimizing methylation data loading:

are we loading all of the data or subsets at each load
what filetype we choose
how we associate metadata
do we need to perform operations over columns/rows and how this relates to how the data is stored

Feel free to add to this list.
For now we decided to punt on this because the current RRBS dataset is relatively small - so the max diff between optimal and suboptimal is smaller. If we want to address this, we can certainly design a set of experiments and run them. Open to it. I'm sure @Armandpl  and I could make this happen.

We're going to be writing out npy files for all columns (samples) of the matrix after the next iteration of @tiffanyshi 's filtering script. So those will always be available as individual files shortly. Doesn't solve all the issues, but it does give you more flexibility.

That's definitely helpful. I think that also supports the "let's come back to this later" path. It's likely we'll want to run these tests at some point though.


Swagger changes to introduce REST APIs for offline and online region for the Cosmos DB account

This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
PR information

[x] The title of the PR is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[x] Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
[x] If applicable, the PR references the bug/issue that it fixes.
[x] Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

[x] I have read the contribution guidelines.
[x] My spec meets the review criteria:

[x] The spec conforms to the Swagger 2.0 specification.
[x] The spec follows the guidelines described in the Swagger checklist document.
[ ] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: arsalana-microsoft sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

Automation for azure-sdk-for-node

Automation for azure-sdk-for-python

Automation for azure-sdk-for-go

@ravbhatnagar could you please take a look?

@ravbhatnagar can you please take a look?

Just one minor thing. Rest looks good. Signing off from ARM.


Add csv and json formater

Moved sql_query to db
Created a module for formaters
Moved influxdb to formaters
Created the CVS formater

Thanks for your review.
MetricsResult have in one place the resutls, metada and filters. The idea is to create like a standard set of data in the workflow from the metrics output and the formatters


Add help text for label editing

The purpose of labels may not be immediately obvious. Let's add context-sensitive help like we have in other places.

Alternatively and/or additionally, if we can make the label step obsolete for most reviews by inserting that field into the form if the API detects we don't already have a given thing, then we could substantially reduce the confusion.

I was confused by label today. I think I'm still confused. Is the label the name of the "thing"?

Yep, like the title of the movie or book. Definitely needs work to be clearer.

Done.


[BACKLOG-31475] - Spoon’s thin-client dialogs lost some styles

Also, you should add the dependency to pentaho-kettle/plugins/repositories/core, pentaho-kettle/plugins/file-open-save/core, pentaho-kettle/plugins/connections/ui and pentaho-kettle/plugins/file-open-save-new/core; just like pentaho-kettle/plugins/get-fields/core has.

PR updated


fix: batchSpanProcessor test failing intermittently

Which problem is this PR solving?

Resolves #350

This has been verified locally by running regression test, with and w/o the change.

Codecov Report

Merging #444 into master will increase coverage by 0.08%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #444      +/-   ##
==========================================
+ Coverage   95.32%   95.41%   +0.08%
==========================================
  Files         124      124
  Lines        6166     6175       +9
  Branches      505      508       +3
==========================================
+ Hits         5878     5892      +14
+ Misses        288      283       -5

Impacted Files
Coverage Δ

...try-tracing/test/export/BatchSpanProcessor.test.ts
100% <100%> (ø)
:arrow_up:

.../opentelemetry-plugin-dns/test/utils/assertSpan.ts
100% <0%> (ø)
:arrow_up:

...try-plugin-dns/test/functionals/dns-enable.test.ts
100% <0%> (ø)
:arrow_up:

...in-dns/test/integrations/dnspromise-lookup.test.ts
90.82% <0%> (+0.91%)
:arrow_up:

packages/opentelemetry-plugin-dns/src/utils.ts
70% <0%> (+1%)
:arrow_up:

...ry-plugin-dns/test/integrations/dns-lookup.test.ts
94.16% <0%> (+1.66%)
:arrow_up:

...kages/opentelemetry-plugin-dns/test/utils/utils.ts
57.14% <0%> (+23.8%)
:arrow_up:


QoS - ugly fix, but hopefully it is working as intended

Fixes #1

Could argue that the methods isActiveAndClaimed is not the best boolean check, maybe it should be limited to just "!isClaimed".

No testing done, building dev env didn't work at my machine for some reason

No testing done, building dev env didn't work at my machine for some reason

Did you see https://bubify.github.io/development/? Otherwise I can test later this week

Yes, followed the doc, didn't work, if u could test, would be great!


Upstream Style.copy constructor regression breaks _Openpyxl2Writer

Starting with openpyxl 2.2.0, various tests in pandas.io.tests.test_excel fail with tracebacks similar to this one.
======================================================================
ERROR: test_basics_with_nan (pandas.io.tests.test_excel.Openpyxl2Tests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/site-packages/pandas/io/tests/test_excel.py", line 1229, in wrapped
    orig_method(self, *args, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/pandas/io/tests/test_excel.py", line 641, in test_basics_with_nan
    self.frame.to_excel(path, 'test1')
  File "/usr/local/lib/python2.7/site-packages/pandas/core/frame.py", line 1267, in to_excel
    startrow=startrow, startcol=startcol)
  File "/usr/local/lib/python2.7/site-packages/pandas/io/excel.py", line 778, in write_cells
    xcell.style = xcell.style.copy(**style_kwargs)
  File "/usr/local/lib/python2.7/site-packages/openpyxl/styles/styleable.py", line 107, in style
    protection=self.protection
  File "/usr/local/lib/python2.7/site-packages/openpyxl/styles/__init__.py", line 42, in __init__
    self._font = font
  File "/usr/local/lib/python2.7/site-packages/openpyxl/descriptors/base.py", line 35, in __set__
    raise TypeError('expected ' + str(self.expected_type))
TypeError: expected <class 'openpyxl.styles.fonts.Font'>

pandas.io.excel._Openpyxl2Writer.write_cells uses openpyxl.styles.Style.copy to merge newly specified style data with style data on existing cells. Sadly, the obvious workaround—iterate over the fields of the Style object and use them to build an updated Style object—won't work either without additional coddling, because the fields don't reliably return the native object that the Style constructor demands.
>>> from openpyxl.styles import Style
>>> s0 = Style()
>>> s1 = Style(fill=s0.fill)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/obrienjw/venv/py27-openpyxl220/lib/python2.7/site-packages/openpyxl-2.2.0-py2.7.egg/openpyxl/styles/__init__.py", line 43, in __init__
    self._fill = fill
  File "/Users/obrienjw/venv/py27-openpyxl220/lib/python2.7/site-packages/openpyxl-2.2.0-py2.7.egg/openpyxl/descriptors/base.py", line 35, in __set__
    raise TypeError('expected ' + str(self.expected_type))
TypeError: expected <class 'openpyxl.styles.fills.Fill'>

(See upstream issue: 444 copy() method on Style object raises TypeError)

replaced by #10125


docs: use rich text formatting in Component API Props description

It may be better to parse the description field in the Component API Props documentation to show code text as code instead of `code`:

A simple RegExp replace method should be enough, if a string can be parsed as HTML:
"`hasIconOnly` must be set to `true`.".replace(/`(.*?)`/g, "$1");
// Output: "hasIconOnly must be set to true."

So, in ComponentApi.svelte:115,
https://github.com/IBM/carbon-components-svelte/blob/8c304521691c3e25a1670e3f73d18cc9c59ee5cc/docs/src/components/ComponentApi.svelte#L114-L116
line should be appended with the replace method described above:

{@html line.replace(/`(.*?)`/g, "$1")}.

Noted

May I open a PR?

Sure


fix: add

resolves #issueNumber
Checklist for profile addition

[ ] Name the PR fix: add <your-username>.
[ ] You've added file named your-username.json in the profiles directory.
[ ] You've linked the PR to the correct issue.

Other additions/changes

[ ] Changes made in this PR are mentioned below
[ ] Search previous suggestions before making a new one, as yours may be a duplicate.
[ ] I acknowledge that all my contributions will be made under the project's license.
[ ] I've read the contributing guidelines

This PR adds/fixes

Notes

resolve #1261

Open to contribute more :)
Greetings ✨

Ok thanks


Missing init.py

Hello,
I install google-cloud Python SDK 0.21.0 using the following command:
$ pip install \
> --no-cache-dir --upgrade --ignore-installed \
> --install-option="--prefix=$APP_PYTHON_VENDOR" \
> -r $APP_ROOT_PATH/requirements.txt

I got an error when I use the Google SDK like this:
python -c "import sys; sys.path.insert(1, '$VENDOR_ROOT_PATH'); print(sys.path); from google.cloud import bigquery;"

Bellow, the error message:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named cloud

When I check the installed files, I see that google and google/cloud folders don't have any __init__.py files.
My previous test work well if I have 2 __init__.py files on each folders.

OS: Linux Ubuntu 16.04 LTS x64
Python: 2.7.12 on fresh empty virtual environment
google-cloud-python: 0.21.0

@JimyRyan thanks for reporting!
The reason there are no __init__.py files is because the library was switched to namespace packages (https://www.python.org/dev/peps/pep-0420).
Are you using a fresh environment? If not, I would recommend starting with a new virtualenv and see if the issue persists.

Yes, it's a fresh virtual environment. But in my case, I don't install the google SDK inside the virtual env but one a specific path using the --install-option="--prefix=..." pip install option. On my application, I add the path where I have installed the SDK (.../lib/site-packages) to the sys.path

Maybe our local packaging expert @jonparrott can chime in here?

Modifying sys.path isn't sufficient when namespace packages are involved.
In general, I highly recommend avoiding doing anything like this unless
completely necessary.
But, if you must, then use site.addsitedir instead.
On Wed, Nov 23, 2016, 9:26 AM Danny Hermes<EMAIL_ADDRESS>wrote:

Maybe our local packaging expert @jonparrott
https://github.com/jonparrott can chime in here?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-python/issues/2767#issuecomment-262579784,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPUcxMbZpJK2AIdhVHMsr4TdVE6sAEBks5rBHdPgaJpZM4K6kZr
.

This issue seems stale?


Chromecast player stalling when gap in live manifest

Have you read the FAQ and checked for duplicate open issues?: Yes
What version of Shaka Player are you using?: v2.4.4
Can you reproduce the issue with our latest release version?: Yes
Can you reproduce the issue with the latest code from master?: Yes
Are you using the demo app or your own custom app?: Both
If custom app, can you reproduce the issue using our demo app?: Yes
What browser and OS are you using?:
Chromecast (for example: V1, V2, Ultra)
What are the manifest and license server URIs?:
Our manifest contains SegmentTemplate with a gap like this:
             <SegmentTemplate timescale="10000000" media="S!dxIDVP7...8BFgZnDU9QUEUtV0lERVZJTkV4IOIBFQGv/QualityLevels($Bandwidth$)/Fragments(video=$Time$)" initialization="S!dxIDVP7...8BFgZnDU9QUEUtV0lERVZJTkV4IOIBFQGv/QualityLevels($Bandwidth$)/Fragments(video=Init)">
                <SegmentTimeline>
                    <S t="15440366781137770" d="30000000" r="12"/>
                    <S d="20000000"/>
                    <S t="15440367201137770" d="30000000"/>
                </SegmentTimeline>
            </SegmentTemplate>

Our stream is DRM protected which will make it hard to reproduce. We could provide the URIs in private and more information if needed.
What did you do?
We have played a live stream with gaps in the manifest on Chromecast. When the gap occurs, the player buffers for many seconds. We do not own the manifest and have to deal with those gaps.
What did you expect to happen?
There is a jump over the gap and continue.
What actually happened?
The player got stalled until it was outside of the availability window.
Do you have any idea why this happens?
1- In GapJumpingController.onPollGapJump_, We successfully jumped over the gap. We then exit GapJumpingController.onPollGapJump_
2- We return in GapJumpingController.onPollGapJump_ and enter in handleStall_. Conditions are met (we haven't understood what this implies entirely) so that the player prints 'Flushing media pipeline due to stall inside buffered range'
3- The player is stalled until it was outside of the availability window.
4- The player returns in the seek range and can play again until the next gap.
Workaround for now
We are not completely clear about why the Chromecast is stalling. We believe that this device is not fast enough to seek. We can see that this problem does not occur on web with a Chrome browser.
We have implemented a workaround and are eager to see what you think of it. Our workaround is to add a grace period after a jump before stalling. Basically, everytime we jump, we keep the timestamp of NOW and before stalling, we check if we have jumped recently over gap. Here is the interesting part:
// shaka.media.GapJumpingController.prototype.onPollGapJump_ ...
  if (gapIndex == -1) {
    if (this.gracePeriodIsPast_(currentTime)) {
      this.handleStall_();
      return;
    } else {
      shaka.log.info('Stalling within grace period');
      return;
    }
// ...
  if (isGapSmall || jumpLargeGap) {
// ...
    this.lastJumpPerformedTime_ = this.getNow_();
  }

/**
 * @param {number} currentTime
 * @return {boolean} if the grace period is past
 */
shaka.media.GapJumpingController.prototype.gracePeriodIsPast_ =
 function(currentTime) {
  return this.lastJumpPerformedTime_ +
    this.config_.gapJumpingGracePeriodInSeconds
    <= this.getNow_();
};

/**
 * @return {number} now
 */
shaka.media.GapJumpingController.prototype.getNow_ = function() {
  return new Date().getTime() / 1000;
};

EDIT: The gaps on the live streams occur only once every 22m30s. Therefore, we do not fear to have many gaps in a short period of time. This fix would not work in that case because we might jump over the first gap, might end up near another gap and our gapJumpingGracePeriodInSeconds would not allow the player to jump again. As of now, we are trying to gather more data with a gapJumpingGracePeriodInSeconds = 3. We might revisit this value if we see any side effects.
Questions:
1- Have you already experienced this issue? If so, how did you dealt with?
2- Do you have any comment/solution for our workaround?

We've definitely had problems with slow hardware problems with Chromecasts before. See issue #1411, for example. So your assumption about the cause of this seems reasonable, though without being able to reproduce the issue I can't say for certain.
Looking at the code, it also seems possible that our current check for stalling inside a buffered range is too aggressive. It assumes that if the media is "playing" but has had a playback rate of 0 for more than a second straight, the video has stalled. Maybe on slow hardware, like on Chromecasts, it simply sometimes takes more than one second to seek sometimes, so we are assuming the stream has stalled prematurely?
You can send details on reproduction to<EMAIL_ADDRESS>

To be clear, there are some ideas we could try, but we will need to be able to test them to be sure they actually solve the problem.

I have sent you the information by email. If anything else is need, tell us and we will provide the information as soon as possible!

We received the info by email.  Thank you!

Ok, I was able to reproduce the problem with a custom manifest. This change solves the problem on that sample manifest; I haven't tested the fix on your sample. I'll try it later, or you can try it yourself if you want. I won't close the issue until I know it's an actual fix.

Hi @theodab, the changes on e5b2428 are helping, but we actually observed delays greater than 0.5 seconds for the player to recover from a gap, more in the 1 or 2 seconds range, sometimes even more on a Chromecast V1 or embedded. Ideally, this value would be configurable. Any thoughts ?

We plan on gathering more thorough data on platform-specific gap behavior in the future. Hopefully that will help us better account for V1 Chromecasts, and other platforms with weak hardware.
I can write a CL for a configurable gap threshold, in the meantime, and see what the rest of the team thinks. That'd be straightforward enough.

That number specifies the distance from a gap where we will jump it.  So with that change, we'll jump a gap once we are 0.5 seconds from it.  This ensures we seek before the browser stalls due to not enough media.  This value has no effect on the stall detection.  What is probably happening is the Chromecast is taking too long to start playing after the gap jump so the stall detection kicks in and we do another seek.  The delay before we handle a stall would be better to be configurable.

It probably does not hurt to attempt the seek a bit earlier, but that's correct, we observed that the real issue was the stall detection kicking in too fast, before the chromecast even had the chance to seek and resume.
Detecting the stall is under the gapJumpTimer .25 seconds loop, but it can also be short-circuited by a segment being appended.
The "grace period" logic proposed by @maxi297 really did alleviate the issue.

@alexgerv I am sorry that progress on this issue has been dormant for so long.
I noticed that you mentioned in your last comment that stall detection is kicking too fast. As part of Issue #1839 we are making the stall detection logic configurable. Would that help you make progress until we find time to investigate gaps and stalls more carefully?
In offline converstaions, @joeyparrish and I have talked about how buffering, gap detection, and stall detection may need to be more cooperative, which would be in-line with your idea of grace periods. I'm confident that we'll find a solution that will work for you and others, but we will need time.
What may help this issue get more attention and slotted for a milestone is if you were to summarize what behaviors you need and open an enhancement request. Enhancement requests are easier for community members to rally behind, increasing their priority, and increasing the odds that they'll get resources directed to them.

As requested, here is the enhancement request: https://github.com/google/shaka-player/issues/1864
Thanks a lot for the guidance!


Auto SSL creation and renewal

Hi,
I have added the code to automatically generate the SSL certificate from Let's Encrypt during docker-compose up. This might be useful as it is very easy to set up. I have also added what needs to be done to enable the automatic generation of SSL certificate. It also checks for SSL certificate expiration and automatically renews the SSL certificate.
Please review it and Let me know if I can be more useful.
Regards.

Please don't add unnecessary dependencies to the nginx container. There is already a Certbot container that can be used for it.

@pichouk Another container seems to be the good option to include LE and manage certificate.
And I agree with replacing web image with Traefik. It would be a good enhancement. It is minimal and has LE support as well.

Try use this with matermost:
https://github.com/jwilder/nginx-proxy
https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion


SSL verification is Failed - Trying to add domain to blog from Amplify Console, Domain is hosted at Route 53

App Id: dahg57414ijrw
Region: us-east-2
Step: SSL verification
Status: Failed

Note:
My domain is hosted on Route 53. I am not sure that it is setup properly, I think an example of how it should be setup for Amplify would help. My nameservers are AWS and I have a CNAME record and SOA record.

Issue/question
How do I resolve this?
Error message
We could not verify ownership of the domain. Please ensure you own the domain and choose retry. If retrying fails, please create an issue in our GitHub issue tracker.
Error message: The status of this certificate request is "Failed". One or more domain names have failed DNS validation. Please check your domain name validation routes and try re-adding the custom domain to your app. Learn more: https://docs.aws.amazon.com/amplify/latest/userguide/custom-domains.html#custom-domain-troubleshoot-guide
Note: Be sure to check the message for sensitive information.
Additional information

.

Solved it by deleting domain on Amplify and then adding it back


GeoLocation Based AR

Hi,
I would like to know how to use this library for location marker. I need a 3d model to be anchored at a particular geolocation(lat,long).

Hi!
Well, the current live version only supports label markers for geolocation, but as it's the same approach we have planned it to support models (already tested)
However, the experience is not the best when it comes to models, so I could elaborate an example with better UX:

Create an anchor and save it's data to your server, attach to it the coordinates of your anchor.

When your model is on the desired range, anchor/resolve it.

The library update got delayed as we got blocked by technical issues on the iOS part, but we expect to solve them as soon as possible.

Is Geospatial API supported by any chance?

Hi! Well, the current live version only supports label markers for geolocation, but as it's the same approach we have planned it to support models (already tested)
However, the experience is not the best when it comes to models, so I could elaborate an example with better UX:

Create an anchor and save it's data to your server, attach to it the coordinates of your anchor.

When your model is on the desired range, anchor/resolve it.

The library update got delayed as we got blocked by technical issues on the iOS part, but we expect to solve them as soon as possible.
If it helps, we can add example of use-cases.
Best regards!

can you share a sample project with this implementation please? I am trying to implement this but don't quite understand how to


added window dpi context

Added dpi context information for WindowsExplorer

Here is error:

LNK2001 unresolved external symbol __imp_PhGetDllBaseProcedureAddress

unresolved external symbol __imp_PhGetDllBaseProcedureAddress

The plugins use PhGetProcedureAddress instead of PhGetDllBaseProcedureAddress

Done


Code Cleaning

Hi @jakharkaran  - as discussed at the Climate Code Clinic, there is quite a lot we can do to improve this repo from the software side.
I started to have a look at some packaging after #45, but ran in to a few issues with the way the code is structured at present.
As a result I stepped back and have started to look at some basic code cleaning and hygiene.
This PR is still WIP, but I have uploaded an example of starting to apply this to Py2D_Solver.py.
If this is something you'd be interested in pursuing further let me know.
It would need a fair bit of communication to make sure we both agree and understand any changes.
The best way to proceed may be to book a follow-up Climate Code Clinic to discuss further.

Thanks Jack. Yes, I wish to pursue this further. I have already booked a follow-up code clinic.


use Chef's embedded Ruby instead of system Ruby

The native Sierra Ruby can no longer install xcode-install due to jwt requirement of >= ruby 2.1, so we install to Chef's ruby. Fixes #4.

Make it so.


Ready Promise never fulfilled when Imported to WebWorker

This only occurs when trying to use an existing IndexedDB database.
I have tried using importScript, and via import localForage from "localForage" to import localForage into the web worker.
Assuming that no other instance of localForage is using a configuration with the same name property, all works fine. When trying to access the same database (name prop), but a different storeName the promise on _ready will never resolve. Both instances of localForage are created via localForage.createInstance({ ... })
Due to my app being a nuxt.js project, I cannot just import an already created instance via importScript.

Any update to this issue?
I think I am running into this. I have a pwa that is attempting to use the same name on the front end side as well as the service worker side. Getting some warnings along the lines of "{dbName} cant be downgraded from version 4 to version 3" warning.


nvidia_x11: 375.26 -> 375.39, nvidia_x11_beta: 378.09 -> 378.13

Figured our nvidia drivers could use a little bump! Didn't bump the legacy drivers since I can't test those
Things done

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

[x] NixOS

[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

pushed as of 12083de992057d55a575a36965260d0c153bc13a


Remove out dated caveat about using setTimeout from a headless js task

Hey Team,
I think this caveat is outdated.
This was fixed in https://github.com/facebook/react-native/pull/33044 and it's now possible to use setTimeout from a HeadlessJsTask.
See:
https://github.com/facebook/react-native/pull/33043
https://github.com/facebook/react-native/pull/33044

No probs @Simek that's done.


Add snapping endpoint

Translation is still missing.

Advanced parameters still need to be removed.

@merydian What is the status of this?

Translation is missing and there are merge conflicts, which are simple to solve though. Except for that it's ready for a review. 1-2h of work I think.


Create a docker-compose-explorer.yml file

Base this off the one in synbiohub-docker

There should be one version in release branch that uses the latest version
There should be one version in snapshot branch that uses the latest snapshot


Term changes must be persisted to disk.

Thanks @cannium -- good catch.
Reviewed by @benbjohnson -- merging on green. I had to kick the build due to a known issue with Continuous Queries.

Closed in favour of https://github.com/influxdb/influxdb/pull/2219 as I need to make more changes to the branch.

@cannium -- can you also sign the CLA? You can find it here:
http://influxdb.com/community/cla.html

Signed. Just curious, what's the difference between this patch and that of  #2219 ?

The CHANGELOG. I needed this change in quickly to meet a build requirement.


Refactor queue in app.py

Partially related to https://github.com/srcfl/srcful-gateway/issues/237, but specifically refactor the queue in app.py.
Would be cool to have also have an endpoint that returns all the tasks in the queue.

Not really sure what the goal of the refactoring is here. But I will try to put the task queue in the blackboard, then added tasks to the blackboard would be directly added to the queue.
There could however be threading trolls here...

This is done. Getting the tasks form the queue is impossible without destroying the queue or implementing a cached list of tasks. One alternative could be to implement a task observer thing that can be used - but imho this is overkill atm.
Decupled the blackboard from the TaskScheduler by introducing two interfaces SystemTime and TaskSource. Blackboard implements these two interfaces. Could be interesting to look into refactoring parts that do not need to depend on the entire blackboard.


Error list and quick info are not consistent with alias display behavior

module M1 {
    export function foo(x: IFoo) { }
    export interface IFoo {
        x;
    }
}

module M2 {
    interface IFoo {
        y;
    }
    import alias = M1;
    var ifoo2: IFoo;
    alias.foo(ifoo2);
}

The call to alias.foo is an error. Hovering on the error shows me the following:

Argument of type 'IFoo' is not assignable to parameter of type 'M1.IFoo'.
Property 'x' is missing in type 'IFoo'.

Note that the parameter type is called M1.Foo. However, hovering on foo in the expression alias.foo(ifoo2) shows me that the parameter type is alias.IFoo. So the parameter type in quick info is not consistent with the parameter type in the error.

Alias and M are senanomus, where ideally they should be the same, I am not sure this warrants a fix.

Okay


Please do not post the solution before 100 people solved the problem.

This is the graph of fastest solvers of the currently-only problem that has less than 100 solvers. (Problem 696)

The horizontal line is the time the solution is committed. (https://github.com/luckytoilet/projecteuler-solutions/commit/cf08a037b09242539385b624566b27839583cd19) The vertical axis is the time (in seconds) since the problem is posted, the horizontal axis is the number of people solved the problem.
I am not that good at statistics to see what's the probability of that happening by chance, but it is pretty clear just by looking at it.

If you insists on posting the answers despite PE's rules, at least don't post them before the fastest solvers table is finished.

Interesting graph. It looks like the effect is small, even after 2 months of the solution being public, there's still less than 100 solvers. It may be due to summer, since no new problems are released and university students having more spare time. Correlation is not causation, and it's hard to draw any conclusions from it.
As for withholding answers before 100 solvers, this has been discussed many times already. My policy is publishing answers as soon as I have it.

I can't see any good reason to publish all the answers (and just the answers) like this. You try to defend yourself by saying that it's people's own decision whether they want to cheat, but seriously, what else does this achieve? It is written clearly in their site that the purpose of PE isn't for people to learn from others' solution and you should respect that as a (presumably freemium) user.
And it least ruined my motivation as a user who once wanted to solve as many problems as possible, because now it is not as impressive to have many problems solved as before given that the answers are so readily accessible.
I know that you still don't care, but I'm just ranting here and feeling sad that PE isn't commercial like some CTF sites that actually have staffs tracking down leaked solutions. For now on PE my only worthwhile joy is to solve the most recent problem before it gets published here.

Sorry that I have ruined your appreciation of PE, but projecteuler-solutions has existed since 2009 and is here to stay. You can still solve the problems for your own satisfaction, or compete in the leaderboard by solving them the fastest.


make trace use same format as dump

Also add a newline in the end as it was previously missing from the output.
For following code:
~ dump∘ ↯ 4_4 0

the current output is:
┌╴main.ua:1:3
│ ╭─
├╴╷ 0 0 0 0
│   0 0 0 0
│   0 0 0 0
│   0 0 0 0
│           ╯
└╴╴╴╴╴╴╴╴╴╴╴╴╭─main.ua:1:1
╷ 0 0 0 0
  0 0 0 0
  0 0 0 0
  0 0 0 0
          ╯
╭─
╷ 0 0 0 0
  0 0 0 0
  0 0 0 0
  0 0 0 0
          ╯

With these changes the output becomes:
┌╴main.ua:1:3
│ ╭─
├╴╷ 0 0 0 0
│   0 0 0 0
│   0 0 0 0
│   0 0 0 0
│           ╯
└╴╴╴╴╴╴╴╴╴╴╴╴
┌╴main.ua:1:1
│ ╭─
├╴╷ 0 0 0 0
│   0 0 0 0
│   0 0 0 0
│   0 0 0 0
│           ╯
└╴╴╴╴╴╴╴╴╴╴╴╴
╭─
╷ 0 0 0 0
  0 0 0 0
  0 0 0 0
  0 0 0 0
          ╯

Ah, a bit of an oversight on my part.
Thank you!


CI: Suite-runtime.RuntimeLB With Containers validates service recovery on restart

/home/jenkins/workspace/Cilium-PR-Ginkgo-Tests-Validated/runtime-gopath/src/github.com/cilium/cilium/test/ginkgo-ext/scopes.go:420
Service list does not match
Expected
    <string>: "...p": "\u003c..."
to equal               |
    <string>: "...p": "10.15...."
/home/jenkins/workspace/Cilium-PR-Ginkgo-Tests-Validated/runtime-gopath/src/github.com/cilium/cilium/test/runtime/lb.go:193

Sep 25 21:46:11 runtime cilium-agent[32692]: level=debug msg="adding frontend and backend to SVCMap" backend="<IP_ADDRESS>:80" backendIndex=2 frontend="<IP_ADDRESS>:80" subsys=loadbalancer
Sep 25 21:46:11 runtime cilium-agent[32692]: level=debug msg="Controller func execution time: 18.495112ms" name=consul-lease-keepalive-0xc0005a9200 subsys=controller uuid=e4229748-dfdd-11e9-9419-080027b8a826
Sep 25 21:46:11 runtime cilium-agent[32692]: level=warning msg="Unable to list services in services BPF map" error="Unable to lookup element in map with file descriptor 14: invalid argument" subsys=daemon
Sep 25 21:46:11 runtime cilium-agent[32692]: level=debug msg="Restoring service" l3n4Addr="{IP:<IP_ADDRESS> L4Addr:{Protocol:NONE Port:80}}" subsys=service
Sep 25 21:46:11 runtime cilium-agent[32692]: level=info msg="Restored services from BPF maps" failedServices=0 restoredServices=1 subsys=daemon

cmd: "sudo cilium service list -o json" exitCode: 0 duration: 58.125921ms stdout:
[
  {
    "spec": {
      "backend-addresses": [
        {
          "ip": "\u003cnil\u003e"
        },
        {
          "ip": "<IP_ADDRESS>",
          "port": 80
        }
      ],
      "flags": {},
      "frontend-address": {
        "ip": "<IP_ADDRESS>",
        "port": 80
      },
      "id": 1
    },
    "status": {
      "realized": {
        "backend-addresses": [
          {
            "ip": "\u003cnil\u003e"
          },
          {
            "ip": "<IP_ADDRESS>",
            "port": 80
          }
        ],
        "flags": {},
        "frontend-address": {
          "ip": "<IP_ADDRESS>",
          "port": 80
        },
        "id": 1
      }
    }
  }
]

62321914_RuntimeLB_With_Containers_validates_service_recovery_on_restart.zip

BPF_MAP_LOOKUP_ELEM failed with EINVAL invoked by LookupElementFromPointers (https://github.com/cilium/cilium/blob/master/pkg/bpf/bpf_linux.go#L142). Unfortunately, I can't see which BPF map corresponded to fd=14.
There are a few cases for EINVAL to be returned to the BPF_MAP_LOOKUP_ELEM syscall - https://github.com/torvalds/linux/blob/v4.9/kernel/bpf/syscall.c:

The unused attribute fields contained some garbage: https://github.com/torvalds/linux/blob/v4.9/kernel/bpf/syscall.c#L283.
The map FD ops didn't match the BPF map ops: https://github.com/torvalds/linux/blob/v4.9/kernel/bpf/syscall.c#L222.

/cc @borkmann

Could be related: https://github.com/cilium/cilium/blob/886c2c82e7381cfb3f37b94c9d98caafe657afa1/pkg/maps/lbmap/ipv6.go#L325 has a wrong padding. u32 is the correct one (I'm going to open a PR).

This is not being tracked in context of any particular project, and from the PR comments seems like it's only been hit a couple of times.
Looks like it's not that pressing of an issue and is unlikely to see movement without more information.
Closing. Feel free to reopen if you have a build + sysdump.


Version overwrite on simultaneous write of same version

If two users are trying to write to the same archive at the same time, two versions with the same version number will be uploaded to the manager. These two versions will point to the same path in the fs and the last closed file will be the object associated with that version.
{'_id': 'big climate data',   'versions': [ '1.0.0', 'dependencies':  [('arch1','1.0.1')],                                '1.1.0', 'dependencies': [('arch1', '1.1.0'), ('arch2', '1.0.0'),                                  '1.1.0', 'dependencies':  [('arch1','1.0.1')]
In this case, the manager will reflect both version 1.1.0 entries but datafs will pull the last entry, not reflecting the earlier dependency update.

Just as a reminder of our discussion, rather than failing (succeeding?) silently, this should raise an error for the second user on write. e.g.
User 1                            | User 2
-------                           | -------
                                  |
api1 = get_api()                  |
                                  | api2 = get_api()
arch = api1.get_archive('test')   |
                                  | arch = api2.get_archive('test')
with arch.open('w+') as f:        |
                                  | with arch.open('w+') as f:
  f.write('hello 1')              |
                                  |   f.write('hello 2')
                                  |
                                  | Traceback (most recent call last):
                                  | ...
                                  | IOError: Simultaneous write occurred. User
                                  | <username> uploaded version <ver> at
                                  | <timestamp>


Memory regression on switch to new transition

On https://github.com/flutter/flutter/commit/543a7e858828e721258b8fb9ded62d7a2ff05808, several flutter_gallery benchmarks are showing a 10-20MB regression in memory footprint.
https://flutter-flutter-perf.skia.org/e/?begin=1648252513&end=1648446610&keys=X845c9ddf84d6ac62deff51c6cee6ad22&num_commits=50&request_type=1&xbaroffset=28090
Weirdly, SkiaPerf flags the following commit, but it's pretty clear from the chart where the regression happened.
@dnfield @AlexV525

/cc @flar Can you help us to identify whether it's a regression? The new transition holds multiple transform widgets in the same time.

SkiaPerf is also reporting improvements to startup time on the following commit, which I think might be related to this change instead:
https://flutter-flutter-perf.skia.org/e/?begin=1647970222&end=1648529864&keys=X81697c49f65f4df52f48a98a3abb5761&requestType=0&xbaroffset=28090

Compared to the last regression, it can be treated as the same one, at least they both have the same numbers: https://flutter-flutter-perf.skia.org/e/?begin=1629261122&end=1629326522&keys=X2d2c76f41c39fb3dfadbb3bef0e020cb&num_commits=50&request_type=1&xbaroffset=25489

It sounds like we were concerned this could cause a speed regression but didn't because of opacity peephole optimizations. But instead it's causing higher utilization of the raster cache because of those optimizations.
We should verify whether we really need the extra raster cache entries. I'd have to look more closely at the visual differences between the old and new transition to understand.

Although if that's the case, I'm not really clear on why it would be impacting the diff-min stat - the raster cache entries should be relatively short lived, and we should be hitting periods where they get evicted and we're back at baseline if my theory is right.

I'm trying to run the benchmark, but it bombs out almost immediately complaining that I don't have the super-parameters language feature enabled. Shouldn't the benchmark enable that itself?

From what I can see, the extra memory comes from duplicate caching which could be addressed soon in https://github.com/flutter/engine/pull/31892
I'm still looking at a way that this could be handled more efficiently in the engine.

Triage: adding the engine tag based on the discussion above.

@flar I'm not following how https://github.com/flutter/engine/pull/31892 will help. Is that PR something that one could patch in now to see if it will help?
@dnfield Are you seeing any feedback from customer: money?
cc @jonahwilliams @jason-simmons

PSS sizes from the end of run for the memory_nav benchmark on Android:

| Old Transition | New Transition | Delta |
-- | -- | -- | -- | --
Java Heap | 3448 | 2248 | 1200 |
Native Heap | 23972 | 45180 | 21208 |
Code | 25724 | 17148 | 8576 |
Stack | 836 | 768 | 68 |
Graphics | 53044 | 62352 | 9308 |
Private Other | 20116 | 19124 | 992 |
System | 4318 | 5289 | 971 |
  |   |   |   |
TOTAL PSS | 131458 | 152109 | 20651 |

So the native heap has grown a lot on the new transition. I think that could be explained by double raster caching (but I thought that would just be graphics memory?) as pointed out by @flar , but I'm surprised I don't see that showing up with the raster cache checkerboard.

Which event do we put that on? I only see a single RasterCachePopulate in the timeline (observatory or devtools) which confirms my observations of the new transition.

Also experimenting with removing the FadeTransition from the page transition, the PSS stays quite high - which tells me this is more to do with the impact of the translation than it does the raster caching of the opacity layer

Actually, If I add a FilterQuality.low, we drop back down to about the old PSS memory usage. Something I didn't know, when you provide a FilterQuality to a transform, we fall back to using a an ImageFilter instead of pushing a transform. Theoretically this allows raster caching of children to not be defeated, at the cost of small rendering artifacts.

If we use a higher filter quality do we get fewer artifacts?

So something may be wrong with how we have implemented raster caching for the ImageFilterLayer, or in how we can use it through the ScaleTransform widget. Unlike the other transitions, when I usage an ImageFilter via FilterQuality on the ScaleTransform widget, the raster cache checkerboard shows up on the entire screen - more or less permanently, even once the transition is "completed". Further more, this continues to update as various parts of the page itself are interacted with.
This could be related to the issue I observed with the "no-op" blue filter still going through the raster cache path, when instead it could entirely avoid it.

Observing the effects on device, the ImageFilter does not seem to allow us to retain raster cache child entires either, or at least not successfully.  Also oddly enough the ImageFilter seems to impact the preview banner

When animating a small scale (or any rotation), it is unlikely that a user could see the tiny transform artifacts while the animation is occurring. It would be slight blurring of the edges which would be lost in the motion. A large scale animation (say 1-5x) you'd start to have it look pixelated, but the transition here uses a very small scale.

Are the transition and opacity animations removed from the tree when it is done?

No, we leave them in the tree. In fact, we leave both the forward and reverse transitions in the tree always.

That could be the problem with the filter quality solution as it uses an ImageFiltered widget which will attempt to apply an ImageFilter on every frame. I'm not sure if either has a decision during the paint phase that eliminates the layer if the transform is identity. I do remember one RenderObject that tried to avoid a layer if the transform was a translation.

Yeah, that sounds similar to the issue I observed with bluring - even with a radius of 0 we still go through a seemingly more expensive pass. I could solve this in the route transition by forcing FilterQuality to null when the animation is at either 0 or 1 - but it would be ideal if there was a fast way the engine could skip these layers.

Yes, RenderTransform will omit a layer when the transform is a translation, but only in the case where there is no filterQuality.
The problem with omitting the filter layer when the transform is a translation or an identity is that if your scale animation goes from 0.8x to 1.2x then you will get a glitch when the scale passes through 1.0x. I think I intentionally didn't omit the filter for that reason and relied on the developer only using the filterQuality transforms during animations.
Is there a reason that these widgets are left in the tree even when not transitioning?

Currently, the engine is able to see the opacity value and make decisions based on that, but the ImageFiltered layer has an opaque SkImageFilter. We recently introduced DlImageFilter which could be smart about omitting itself, but we only use that in DisplayList objects. I filed https://github.com/flutter/flutter/issues/100454 to get the layers to start using the inspectable objects and then we could look into the engine omitting these operations automatically.

One issue with relying on the engine to reverse engineer the framework's inefficiency is that we have the framework wasting time managing widgets and render objects that are obsolete and building layers that aren't needed and then we have additional work in the engine to notice that the layers are obsolete and so we get everyone doing extra work to avoid the framework omitting the unnecessary layers on its own.

That makes a lot of sense, thanks. I think the right solution at least for these Animated widgets is to use thier knowledge of the animation status to only skip the layer at the beginning and end of an animation.

Separately, I'm going to take a pass at our documentation to ensure we mention that these layers aren't skipped, which I notice isn't mentioned on ImageFiltered at least

Not having these layers in the tree when they aren't animating might make a difference and it might also make the filterQuality solution work better.

@flar I'm not following how flutter/engine#31892 will help. Is that PR something that one could patch in now to see if it will help?

Right now if we have nested layers that both want to cache, they both will. Each layer decides independently whether it will cache in its own Preroll method and we execute all Preroll methods to make sure we accumulate the correct bounds up through the tree. But the parent's cache will obviate the need for the child's cache - and yet there they both are in our cache.
That PR will have us collect the requests for caching during Preroll and then evaluate them all during the Paint phase. This way, if a parent caches itself or "all of its children" during the evaluation phase, then it will skip the requests that its children made without any adverse effects on the children (other than their cache request being ignored) and only the parent will end up in the cache.

A quick summary:
The page transition landed in the next build, regressing memory benchmarks. Its not a huge regression, but its not nothing either - so we should probably revert it.
We do have fixes, but these fixes may have other trade offs and we probably shouldn't cherry pick them

Re-opening until we've confirmed the fix

Please file a cherry pick request

On a revert or?

Yeah, it sounded like you were suggesting that the switch to the new transition should be reverted. If so, that would need to be cherry-picked onto the release branch.

Sorry if that was unclear - I was just sumarizing what we know. I have zero idea whether we should cherry pick a revert.
At any rate, with the latest change I landed above we are back to previous memory usage:
https://flutter-flutter-perf.skia.org/e/?begin=1648191600&numCommits=300&queries=test%3Dflutter_gallery__memory_nav&requestType=0
Provided there are no other flagged regressions we can problably close this

Do we have updated docs on our chery pick process?

Yeah there's a new issue template https://github.com/flutter/flutter/issues/new?assignees=&labels=cp%3A+review&template=7_cherry_pick.yml&title=[CP]+<title>

I've submitted an announcement the announce group, please hold it if the transition needs a revert.

So this ended up only needing 2 small changes in the framework. If we're set on announcing that we support this transition, I'd say we either accept the small regression or we could cp both small changes to improve memory usage. Requiring an engine fix might be a bit too much but we might be OK without the other change

So this ended up only needing 2 small changes in the framework. If we're set on announcing that we support this transition, I'd say we either accept the small regression or we could cp both small changes to improve memory usage. Requiring an engine fix might be a bit too much but we might be OK without the other change

Yeah but it's not accepted yet. Though I'd upvote for picking small changes.

So unfortunately my changes caused a separate regression, see https://github.com/flutter/flutter/issues/101821 , so while we have fixed some of the issues we're not yet able to switch over to the ImageFilter for the reduced memory usage.

From discussion last week, we've decided not to revert this. Some factors:

Landing this default change was fairly extensive, and it would be a fairly extensive revert if we rolled into google3.
Functionally, the transition has changed it is expected that it has different performance characteristics. The cost also appears to be fixed.
This is a change in the default, but users can opt into one transition type or another themselves.
We noticed no issues nor received any complaints from already migrated g3 customers.

Given these, we will continue to explore ways to improve the performance but the severity should be downgraded.

I've relanded the switch to use an ImageFilter, this has lowered memory here:
https://flutter-flutter-perf.skia.org/e/?begin=1650997747&end=1651002848&queries=test%3Dflutter_gallery__memory_nav&xbaroffset=28565
Will mark as fixed as soon as all the benchmarks come back positive

Is there any jankiness with the IF caching on the first frame?

According to benchmarks yes:  https://flutter-flutter-perf.skia.org/e/?begin=1650989645&end=1651012744&keys=X809a5f88fb68c1b259242471f65ee081&num_commits=50&request_type=1&xbaroffset=28565
reverting again with https://github.com/flutter/flutter/pull/102611

https://flutter-flutter-perf.skia.org/e/?queries=test%3Dflutter_gallery__memory_nav

We're now back in the same memory ballpark with https://github.com/flutter/flutter/pull/106621


Remove InternalApi from Watchdog, and add InternalApi to FixedWatchdogProvider

Fix #829

I can't figure out why Java 7 tests failed... @vam-google passing this to you.

Closing as obsolete (implemented as parto of https://github.com/googleapis/gax-java/pull/1119)


style: further tidying employing go doc 1.19+ spec and features

I did a quick pass to ensure the doc comments conform to go doc spec, and reworded some for clarity (using 1.19 features since you bumped the version). Thanks again for the link.
I do have a couple actual features in mind I'd like to try my hand at implementing and submitting if I can, not just endless obsessing over comment style, I promise. :smile: I just like to get all the styling stuff out of the way first when I find a project to contribute to, otherwise it tends to be quite a nuisance to keep those tweaks from slipping into unrelated feature commits if I get to that point.

Converted to draft to include fixes to stylecheck linter errors.

Looks tidy! Thank you! Feel free to fix the remaining linter issues in another PR.


Added hxRaylib

Added new Haxe raylib (under progress) binding to BINDINGS.md

@ForeignSasquatch Nice! Thanks for the addition! :D


PubSub: Allow user specified timeout for this executor.submit() (nice to have)

https://github.com/GoogleCloudPlatform/google-cloud-python/blob/b2c7c11e4e24cf571cd5601803a883542136552c/pubsub/google/cloud/pubsub_v1/subscriber/policy/thread.py#L338
Since the future will block indefinitely, it would be nice to be able to specify a timeout.  The current work-around we use is to ensure that the callback function doesn't block forever, but that requires introducing yet another thread construct into the situation.

@chemelnucfin One thing I noticed was that doesn't seem to be an easy way to pass in any parameters to the thread.Policy used by subscriber.client.Client().  Any customization currently requires the caller to subclass the Policy class.  What are your thoughts on how to pass in parameters that then get forwarded to the thread.Policy object instantiated in _get_executor()?

Hello, sorry for haven't been responding.  I believe that my coworker is in the midst of overhauling the pubsub internals, which is why I have not tried to dig deep into pubsub problems.  I will keep this in mind and try to find out what is going on with the library.  Thanks.

Pub/Sub internals should be pretty solidified.
@jeffkpayne I'm not sure why this is needed. The future never gets awaited by our code (nor is it exposed to the user in a way that they could await it). We use add_done_callback just to log that the task was completed. Can you tell me more about your use case here?

Sorry, I worded the issue poorly.  Regardless of whether or not future.result() is called, the _callback function that processes the message could block a long time and eat up the threads in the ThreadPoolExecutor.  Again, this is a nice-to-have.  If this seems unnecessary to you, then please close it.

Hrm, I may be misunderstanding but it seems undesirable for our executor to kill callbacks. If you're worried your callbacks will hang forever, I feel like that's the responsibility of the author of the callback.
I'm happy to be talked into something different, though.

OMG, I'm losing my mind. There's no timeout parameter in submit... Closing. Sorry for wasting your time! I need a vacation.

Hahaha that's quite alright. :)
Hopefully you get to take a vacation soon.


Withdrawals, Deposits, Geocoordinates

Added support for the following new features:
--withdrawals endpoints
--deposits endpoints
--transactions by payer/payee
--atms by radius from geocoordinates
These are all tested and documented.  Thanks guys!
This closes #15 and closes #16 and closes #17

merging pull request from mike.


Latest Android SDK (Command-Line Tools Only) cannot be found by Flutter

Initially, when running either flutter doctor or flutter doctor --android-licenses, the only information I was getting about the Android Toolchain or Android SDK in my system was:
" Unable to locate Android SDK. "
Now, when running "flutter doctor" command without using options I'm getting:
[✗] Android toolchain - develop for Android devices
✗ ANDROID_HOME = /Users/samuelfranco/android-sdk/cmdline-tools/latest
but Android SDK not found at this location.
For context, I'm able to run the sdkmanager from within the Android SDK location, inside the "bin" folder in:
/Users/samuelfranco/android-sdk/cmdline-tools/latest/bin
So I think it's unlikely there are "installation" errors. But Flutter just won't recognize the SDK.
I implemented this file structure (<>/android-sdk/cmdline-tools/latest ) strictly following the instructions given in the official Android Developers Download Page for the Android SDK (Command Line Tools Only):
https://developer.android.com/studio/command-line/sdkmanager
Of course I've tried several solutions from across the internet but the most recent ones I've found are from 2020, at which time, the file structure of the Android SDK was different (build-tools, tools and platform-tools were direct children of the sdk folder) as you can see in this old thread:
https://github.com/flutter/flutter/issues/15114
I've set the $ANDROID_HOME environment variable in my /etc/zshrc file as follows:
export ANDROID_HOME="/Users/samuelfranco/android-sdk/cmdline-tools/latest"
and also updated my PATH to include this variable:
export PATH=$PATH:$ANDROID_HOME
So now I get a little bit more information:

So, Flutter does read the ANDROID_HOME variable and looks for the Android SDK there... It just doesn't find it (????

Hello @Francosf7. Thanks for filing this issue. Have you tried setting ANDROID_HOME to /Users/samuelfranco/android-sdk instead?

I have the same issue

I have the same issue

Same here

Me too, but I don't know if it's because of permissions on the computer that I don't have access to the folder

I have the same issue

Initially, when running either flutter doctor or flutter doctor --android-licenses, the only information I was getting about the Android Toolchain or Android SDK in my system was:
" Unable to locate Android SDK. "
Now, when running "flutter doctor" command without using options I'm getting:
[✗] Android toolchain - develop for Android devices ✗ ANDROID_HOME = /Users/samuelfranco/android-sdk/cmdline-tools/latest but Android SDK not found at this location.
For context, I'm able to run the sdkmanager from within the Android SDK location, inside the "bin" folder in:
/Users/samuelfranco/android-sdk/cmdline-tools/latest/bin
So I think it's unlikely there are "installation" errors. But Flutter just won't recognize the SDK.
I implemented this file structure (<>/android-sdk/cmdline-tools/latest ) strictly following the instructions given in the official Android Developers Download Page for the Android SDK (Command Line Tools Only):
https://developer.android.com/studio/command-line/sdkmanager
Of course I've tried several solutions from across the internet but the most recent ones I've found are from 2020, at which time, the file structure of the Android SDK was different (build-tools, tools and platform-tools were direct children of the sdk folder) as you can see in this old thread:
#15114
I've set the $ANDROID_HOME environment variable in my /etc/zshrc file as follows:
export ANDROID_HOME="/Users/samuelfranco/android-sdk/cmdline-tools/latest"
and also updated my PATH to include this variable:
export PATH=$PATH:$ANDROID_HOME
So now I get a little bit more information:

So, Flutter does read the ANDROID_HOME variable and looks for the Android SDK there... It just doesn't find it (?
I've been through the same thing

@Francosf7  Your Android_HOME should point to the root of the Android SDK folder  and this variable must be defined in rc file (.zshrc or .bashrc depending on your shell) and also ensure the ANDROID_HOME is under your PATH variable
export ANDROID_HOME="/Users/username/Library/Android/sdk"
export PATH="$ANDROID_HOME/tools:$ANDROID_HOME/tools/bin:$ANDROID_HOME/platform-tools:$PATH"

Additionally, install the command line tools from the Android studio refer  https://stackoverflow.com/a/67956603/8253662
If it's already installed try uncheck (delete) and reinstall.


Feature/lit 3748 js sdk setup local development environment for naga

Description

Updating several endpoints to V2

Closing this, created a new branch https://github.com/LIT-Protocol/js-sdk/pull/653 that checked out from the staging/v7 branch


Segments cannot be merged, the download process is stuck and cannot be completed

I encounter an issue like the image below

being blocked indefinitely like this and unable to continue

i using default:
dl.start(   url='http://example.com/file.txt',   file_path='file.txt',   segments=10,   display=True,   multithread=True,   block=True,   retries=0,   mirror_func=None,   etag=True )

can you test using this version and see if its still happening [https://test. pypi.org/project/pypdl/](https://test. pypi.org/project/pypdl/)

I'm trying out version 1.4.1, there's a minor syntax error. I've temporarily fixed it and I'm testing to see if the issue I encountered before still persists. Thank you!

can you provide the full error traceback