[UI] Inverted positive negative buttons do not follow style

Steps
Create elements with the following classes:

ui positive button
ui green button
ui inverted positive button
ui inverted green button

Expected Result
1 and 2 the same, 3 and 4 the same
Actual Result
1 and 2 the same, 3 and 4 are different
Version
2.3.3
Testcase
http://jsfiddle.net/nt3ecfsw/3/
Comments
To me since on light versions they are the same, inverted should follow the same pattern. This especially as in the official documentation page there are no samples of inverted positive and negative buttons (on a side note it would be nice if all the options for colors, basic and inverted would be following each other since otherwise it is a bit confusing, e.g. basic and inverted come before you mention there are even color options - it should be the opposite, color list first as basic and inverted use the list).

This is due to positive buttons not having .inverted variations, therefore using .inverted.positive will lead to the button getting styles from the black inverted button (hence the white borders) and the positive button (hence the green background).

Then it is a bug that it doesn't have those. :)

As per the docs there is no mention of positive or negative buttons having an inverted variation, therefore it is not intended to be a feature hence Enhancement.

Hm, true. Sorry, I never noticed that and I wouldn't have considered that either as we have found a lot of issues with the documentation. As the positive and negative seem like aliases for red and green it would be nice to show them on the dark theme so that it is clear they are not the same then. It would make it more clear. But thank you for pointing this out.


All my extensions are not working

Issue Type: Bug
Extension host terminated unexpectedly is popped as the first message. All the plugins including some default IntelliSense plugins are not working. This is making my workflow very slow. Please fix this asap.
VS Code version: Code 1.44.0 (2aae1f26c72891c399f860409176fe435a154b13, 2020-04-07T23:31:18.860Z)
OS version: Windows_NT x64 10.0.18363

System Info

Item
Value

CPUs
AMD Ryzen 5 2600 Six-Core Processor             (12 x 3394)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: disabled_offprotected_video_decode: unavailable_offrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledviz_display_compositor: enabled_onviz_hit_test_surface_layer: disabled_off_okwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
7.93GB (2.55GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions (35)

Extension
Author (truncated)
Version

jest-snippets
and
1.8.0

code-gnu-global
aus
0.2.2

vscode-intelephense-client
bme
1.3.11

path-intellisense
chr
1.4.2

es7-react-js-snippets
dsz
2.7.1

tslint
eg2
1.0.44

eppz-code
epp
1.2.41

vsc-material-theme
Equ
32.5.0

vsc-material-theme-icons
equ
1.1.4

prettier-vscode
esb
4.1.1

php-debug
fel
1.13.0

php-intellisense
fel
2.3.14

php-pack
fel
1.0.2

code-runner
for
0.9.17

terminal
for
0.0.10

sublime-babel-vscode
jos
0.2.10

node-module-intellisense
lei
1.5.0

vscode-language-babel
mgm
0.0.27

csharp
ms-
1.21.16

python
ms-
2020.3.71659

cpptools
ms-
0.27.0

vscode-typescript-tslint-plugin
ms-
1.2.3

debugger-for-chrome
msj
4.12.6

vscode-react-native
msj
0.14.2

laravel-blade
one
1.20.0

vscode-jest
Ort
3.1.1

material-icon-theme
PKi
4.0.1

tsimporter
pmn
2.0.1

live-sass
rit
3.0.0

LiveServer
rit
5.6.1

mongo-snippets-for-node-js
roe
1.2.0

js-jsx-snippets
sky
10.1.0

unity-debug
Uni
2.7.5

vscode-icons
vsc
10.0.0

JavaScriptSnippets
xab
1.7.2

(6 theme extensions excluded)

Please find out which of your extensions is causing the issue. Either disable all and then re-enable one at a time, or disable half of them to narrow the field faster (bisecting).

Disabled all the extensions but nothing happened. Still facing the same
problem.
On Thu, 9 Apr 2020, 13:56 John Murray<EMAIL_ADDRESS>wrote:

Please find out which of your extensions is causing the issue. Either
disable all and then re-enable one at a time, or disable half of them to
narrow the field faster (bisecting).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/94756#issuecomment-611401466,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACICLN4BSGBRA4L37PT52RLRLWBD3ANCNFSM4MEPP7IQ
.

You disabled all your extensions, then restarted VS Code, and you still got a message about "Extension host terminated unexpectedly", right?
Any more information in that message? Maybe paste a screenshot here?

I figured it out. The reason is the latest update 1.44
I reinstalled the software, I have version 1.38 installer. Everything
became normal until I closed the application and saw updating VS code
popped up on my screen. I again launched the application and the problem
was there again. I again uninstalled this version and reinstalled it with
v1.38 installer. This time before launching the application I turned off my
Internet connection. Then I headed over to the settings and disabled
update. Re enabled my extensions and my problem was thus solved.
Conclusion:
Problem is with the latest update for Windows i.e.  1.44
On Thu, 9 Apr 2020, 16:35 John Murray<EMAIL_ADDRESS>wrote:

You disabled all your extensions, then restarted VS Code, and you still
got a message about "Extension host terminated unexpectedly", right?
Any more information in that message? Maybe paste a screenshot here?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/94756#issuecomment-611469152,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACICLN25MKXOMLZH5D34XV3RLWTXJANCNFSM4MEPP7IQ
.

/causedByExtension
I don't know how I can help any further unless you are willing to upgrade to 1.44, disable all your extensions, then enable them one at a time until you discover which one is causing the problem.

It's some sort of bug. You need to fix the latest 1.44 update. I removed
all extensions and still faced that exact same problem.
On Thu, 9 Apr 2020, 21:31 VS Code Issue Triage Bot, <
<EMAIL_ADDRESS>wrote:

This issue is caused by an extension, please file it with the repository
(or contact) the extension has linked in its overview in VS Code or the
marketplace https://aka.ms/vscodemarketplace for VS Code. See also our issue
reporting https://aka.ms/vscodeissuereporting guidelines.
Happy Coding!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/94756#issuecomment-611608932,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACICLNZC7U7FFWF6SCTUFLTRLXWPJANCNFSM4MEPP7IQ
.

/duplicate of #94807


Publicly accessible VFS for Git test repository

Is there a publicly accessible VFS for Git repository, that we could use in things like bug reproduction scripts and such? As we can't do stuff like gvfs init and without a public testing repository, it's a bit hard to share reproduction steps.

Just realised, that of course there is one - used in functional tests. Closing the issue, for anyone else looking - it's https://gvfs.visualstudio.com/ci/_git/ForTests


[5.5] Set min PHP to 7.1 because of PHP support timeline.

Hello everybody,
some time ago Taylor announced that Laravel 5.5 require PHP 7+ (actually in the composer.json >=7.0) and will be an LTS Release. For some of our projects it is an requirement to use an LTS Version of Laravel, so after viewing the Support Timeline from PHP itself (https://secure.php.net/supported-versions.php) PHP 7.0 will get active support until 3 Dec 2017 and security fixes until 3 Dec 2018. I know that the plan for Laravel 5.5 would be: 2 years Bug fixes and 3 years security fixes. So (when it will released on 1 july 2017) the "bug fix support" will end on 2 july 2019 and the "security fixes support" will end on 2 july (2020 or 2022?). So Laravel would support versions that doesn't receive any PHP Security updates anymore.
For PHP 7.1 the timeline says: Bugfixes until 1 Dec 2018 and Securityfixes until 1 Dec 2019, so difference between PHP 7.1 EOL and Laravel 5.5 EOL would be only 7 months (enough time to update to the next LTS Version).
The changes required for migration PHP 7.0 to PHP 7.1 aren't so much, actually Laravel 5.4 runs on both without an error, and the improvements (speed, server requirements and so on) prevail.

I think it's better to approach it from the angle of "what PHP 7.1 features can we not live without?"... Even if Laravel runs on 7.0, that doesn't mean you can't also run it on 7.1, 7.2, 7.3, or whatever else.
The framework's PHP version constraint doesn't limit you to what PHP version you can run on, it limits the framework to what features we are going to use internally.

I will say the only 2 features that interest me in 7.1 are:

Multi-catch exception handling
Symmetric array destructuring

I think the most beneficial of the 3 features Taylor mentioned above is the async signals.
I'm all for requiring PHP 7.0+ / I tend to run and prefer bleeding edge, but I think it may be too early to force adoption of 7.1.. especially since (for example one of my production environments) has other sites on it, and while they behave nicely with 7.0.*, 7.1 has caused some sites to break.
I think (especially in terms of LTS) that 7.0 should be the requirement.  Features that come from 7.1 (async signals) could be still implemented while keeping backward compatibility.

Nullable types were introduced in 7.1 too.

Okay, i know that Symfony as sample goes with 4.0 (Release in Nov 2017) directly to PHP 7.1 (https://twitter.com/fabpot/status/851558576770252800)  because of the fact that PHP Active Support ends this year.
@astierler

I think (especially in terms of LTS) that 7.0 should be the requirement. Features that come from 7.1 (async signals) could be still implemented while keeping backward compatibility.

But for an LTS Version, what is the benefit of leaving on "old" php versions? I make the experience that when you have more than one project, you will leave the project "as it is" (on the same php version 7.0.x) after the release and doesn't update until the PHP Version isn't supported anymore. The Problem is, that this case for PHP 7.0 is in only six months, for an project that require LTS is that not really long, the case for  PHP 7.1 is in one year and six months, so enough time.

I would like to point out that Ubuntu is not currently providing PHP 7.1 from the xenial repositories (16.04 LTS), only PHP 7.0. Ubuntu will keep backporting security fixes for the lifetime of their LTS scheme,

A new LTS version is released every two years. In previous releases, a Long Term Support (LTS) version had three years support on Ubuntu (Desktop) and five years on Ubuntu Server. Starting with Ubuntu 12.04 LTS, both versions received five years support.

Source: https://wiki.ubuntu.com/LTS
Here's an example:
Ubuntu 14.04 LTS was first released in the beginning of 2014 and will get maintenance until a few months into 2019, a total of five years. (Source: Ubuntu Server and desktop release end of life).
At that time PHP 5.5 was the latest release (5.6 was released a few months later, in August 2014). This means that Ubuntu 14.04 LTS came with PHP 5.5. Ubuntu will maintain their PHP 5.5 packages and fix security issues for the lifetime of their LTS window. That means that Ubuntu will keep their PHP 5.5 packages up-to-date with security fixes for another two years.
PHP 5.5 had security support by PHP until July 2016. Ubuntu will provide it until 2019. To back this up; Ubuntu did security updates on their PHP 5.5 packages as recently as February 2017 (Source: php5 changelog @ ubuntu packages). Yes, they are still providing security fixes for PHP 5.5!
Now, if we look at the latest Ubuntu 16.04 LTS release, it includes PHP 7.0. That means that Ubuntu will provide security updates for PHP 7.0 until 2021, which is a year after the PHP team stops supporting PHP 7.1.
I know that I can use additional repositories to install PHP 7.1 on Ubuntu 16.04 LTS. I believe the most wellknown one to be ondrej's php repository. I would like to point out that there's no LTS support for those packages, and as late as last year he renamed his repositories which broke existing deployment scripts. (Ref: 1, 2, 3, 4).
Conclusion: Ubuntu 16.04 LTS will have security support for PHP 7.0 until 2021, and no official support  for PHP 7.1.

I have to agree with @sisve; I have a couple of enterprise government clients who run critical bestoke Laravel applications we've built for them.
They have to run only official Ubuntu disto repos in their government data centers. There is no room for negotiation on this point with the security government people. If its not an official repo - it doesnt get installed - end of story.
Yes - it is annoying. We can argue all day about why they should be allowed to run 7.1 - but this is not going to be changed. So statements like "...the changes required for migration PHP 7.0 to PHP 7.1 aren't so much..." are not entirely true.
If Laravel 5.5 forces PHP 7.1 - then that creates a massive issue, because people who want LTS are often the same organisations bound by policy restrictions like this.
It would put me in a situation where I cannot upgrade client applications to the next LTS 5.5 (because we cannot run 7.1), while the current LTS 5.1 expires - leaving me in a no mans land for support on these applications.

There is often talk about what "is an enterprise application" & "can Laravel be used for enterprise" blah blah. We all know all those talk are crap etc - but this is a test: If Laravel LTS 5.5 forces 7.1 then that will stop some enterprises from being able to consider using Laravel.
 I know it would be nice to use all the new features. I personally love 7.1 and use it on all my projects, or any client project where 7.1 is an option. I agree with @taylorotwell about his list and know they would be cool in the core.
But unfortunately not all enterprise need/want cool. Not all enterprise will allow bleeding edge. That is just the reality of the situation that some organisations play in, and these are the rules that some developers have to follow.

Sure, but why, Symfony can walk the way and Laravel not? I think symfony is more used in enterprise projects than laravel :)

Because Symfony 2.8 has LTS until 2019: http://symfony.com/doc/current/contributing/community/releases.html
Laravel 5.1 only has LTS until 5.5 (July 2017), when 5.5 takes over.
If the 5.1 LTS was longer - then I'd have no problem with 5.5 being 7.1. But at this stage that is not occuring.

I still feel like people are talking as if they won't be able to run their Laravel 5.5 projects on PHP 7.1. You all understand you will be able to right? We are only talking about what language features the framework itself can use. There is nothing else to discuss really.

I still feel like people are talking as if they won't be able to run their Laravel 5.5 projects on PHP 7.1.  We are only talking about what language features the framework itself can use internally.

The title of the PR is proposing to force Laravel 5.5 LTS to require PHP 7.1 (and use 7.1 features) - and the fact the PR is still open, implies it is under consideration and might be accepted?
All I'm saying is we really need to be able to run Laravel 5.5 LTS on PHP 7.0 - otherwise it creates issues for some larger enterprise clients and projects (for the reasons listed above).

I still feel like people are talking as if they won't be able to run their Laravel 5.5 projects on PHP 7.1. You all understand you will be able to right? We are only talking about what language features the framework itself can use internally. There is nothing else to discuss really.
@taylorotwell Sure, Laravel 5.5 will run on PHP 7.1, but an LTS release should be really strict and hard,or? So the additional return types (like null and void), that are implemented into PHP 7.1, allows  to make the complete framework "strict mode ready".

@LKDevelopment Laravel 5.5 wouldn't be able to become completely strict instantly. A lot of time required to refactor it. If there will be need of nullable types - 5.6 could require 7.1 because it wouldn't be LTS release already.

@LKDevelopment The target market for an LTS type release is the sort of user who cant or doesn't immediately upgrade to the latest PHP release. 5.5 being an LTS is an argument for keeping the version requirement low, not increasing it.

If I remember correctly the main reason why laravel introduced he LTS cycle in the first place is to attract larger organisations into using laravel. And since difference between php7.0 and 7.1 is huge (official support vs no official support in ubuntu16.04 case), it would definitely be a deciding factor for a lot of organisations whether to adopt laravel 5.5 or not. Making an LTS version too strict will be quite contradictory in my opinion, in a way that it's supposed to be a version that is widely adapted, but introducing a requirement that most cant afford.

I feel like I understand completely what Taylor have been saying in this PR.
I want Laravel 5.5 LTS with PHP version that is safe -> Good. Run it on 7.1, you don't need to force the rest of the world to do the same.


Document Agent.ADMIN

Coverage remained the same at 95.787% when pulling 83f69af74cf190809caba111a83bb9daa6802fc2 on rhoggSugarcrm:document-agent-admin into 2a66d5e605f2cca7c7c1cb03f51b20c01166053c on sugarcrm:master.

Coverage remained the same at 95.845% when pulling 18b2a026485389db4fe881374c0cec753896c5fc on rhoggSugarcrm:document-agent-admin into 0a7363a5c701ddce3fc86333874de37e507270c6 on sugarcrm:master.

Coverage remained the same at 95.549% when pulling 9fdf3146cf32a3658d71d94061a15e1146ee86b5 on rhoggSugarcrm:document-agent-admin into ecbcd356ca5a28ba88c15a3aa2e4fcf2b6ec9c0e on sugarcrm:master.

Coverage remained the same at 95.549% when pulling 1cba88e508fcf7a426154fb2c76a3e4a7af9ba49 on rhoggSugarcrm:document-agent-admin into 2cde8a2317c7bf0d313a741d29ed5eaed6e3123a on sugarcrm:master.

Coverage remained the same at 95.652% when pulling 0c175e0800a08350cc8548bb833d72b30a01bb84 on rhoggSugarcrm:document-agent-admin into 782b4a45384bf3005dee33b1bf4cebcd5335ffa2 on sugarcrm:master.


support tf.Unique legalize throught hlo/lhlo

This pr purposed a way to lower tf.Unqiue down to mlir core dialect, by adding relevant hlo/lhlo op, and a runner_utils which call a external function to actually do the unique thing with a hashmap, any discussion is welcomed for this pr as  we are trying to get things done right .
The reason why we import a external function to lower the relevant unique logic is that the hashmap type is not supported  currently in mlir core, a discussion is purposed in llvm discussion https://llvm.discourse.group/t/will-mlir-support-hashmap-type-in-near-future/691/2
So for code like
%1:2 = "tf.Unique"(%arg0)  : (tensor<?xi64>) -> (tensor<?xi64>, tensor<?xi64>)

will be first lowered to lhlo code
%0 = alloc() {temp = true} : memref<i64>
    "xla_lhlo.unique_count"(%arg0, %0) : (memref<?xi64>, memref<i64>) -> ()
    %1 = load %0[] : memref<i64>
    %2 = index_cast %1 : i64 to index
    %3 = alloc(%2) {temp = true} : memref<?xi64>
    %4 = dim %arg0, 0 : memref<?xi64>
    %5 = alloc(%4) {temp = true} : memref<?xi64>
    "xla_lhlo.unique"(%arg0, %3, %5) : (memref<?xi64>, memref<?xi64>, memref<?xi64>) -> ()
    dealloc %0 : memref<i64>
    dealloc %3 : memref<?xi64>
    dealloc %5 : memref<?xi64>

and then be lowered by newly added -lhlo-legalize-to-std pass to code like
%0 = alloc() {temp = true} : memref<i64>
    %1 = dim %arg0, 0 : memref<?xi64>
    %2 = call @_global_get_unique_ids_count(%arg0, %1) : (memref<?xi64>, index) -> i64
    store %2, %0[] : memref<i64>
    %3 = load %0[] : memref<i64>
    %4 = index_cast %3 : i64 to index
    %5 = alloc(%4) {temp = true} : memref<?xi64>
    %6 = dim %arg0, 0 : memref<?xi64>
    %7 = alloc(%6) {temp = true} : memref<?xi64>
    call @_global_unique_i64_i64(%arg0, %5, %7) : (memref<?xi64>, memref<?xi64>, memref<?xi64>) -> ()
    dealloc %0 : memref<i64>
    dealloc %5 : memref<?xi64>
    dealloc %7 : memref<?xi64>

so the two external function  _global_get_unique_ids_count and _global_unique_i64_i64 is called to actually do unique , which is now located in runner_utils lib

@qqsun8819 Can you please check reviewer comments and keep us posted. Thanks!

Could you create a discussion on the TF MLIR SIG about adding the op? We are trying to make adding operations and discussing them very open and not all follow PRs.

It has been 14 days with no activity and the awaiting response label was assigned. Is this PR still valid? Assigning the stalled label. Please comment to reassure me that this is still being worked on.

@qqsun8819 Can you please check @joker-eph, @jpienaar comments and resolve conflicts?. Thanks!

I'm going to go ahead and close this PR, because it seems to have stalled. If you're still interested in pursing this (and responding to my comments), please feel free to reopen!


Updated setup.py for v0.0.19

Codecov Report
Base: 60.02% // Head: 60.02% // No change to project coverage :thumbsup:

Coverage data is based on head (4739f8b) compared to base (62b2a28).
Patch has no changes to coverable lines.

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

Additional details and impacted files
@@           Coverage Diff            @@
##           develop     #559   +/-   ##
========================================
  Coverage    60.02%   60.02%
========================================
  Files           26       26
  Lines         2809     2809
========================================
  Hits          1686     1686
  Misses        1123     1123

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Fix default api

With the https://github.com/koding/kite.js/pull/79 PR I've introduced an issue with default kite api, this PR fixes that with by passing a Kite instance to KiteApi constructor. And we're wrapping the default api in KiteApi over the provided Kite instance.

@usirin I've merged this since there was an ongoing issue, PTAL


Xbox does not trigger MemoryManager_AppMemoryUsageLimitChanging event in background

There is a limitation of 128mb for uwp running in background.

Usually the audio will be 20-50mb around which last 60-120minutes.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 6538f51a-1819-34cd-0b30-e0b2245a34b2
Version Independent ID: 726323e1-322f-64a7-137e-93e0f36608e9
Content: Reduce memory usage when your app moves to the background state - Windows UWP applications
Content Source: windows-apps-src/launch-resume/reduce-memory-usage.md
Product: uwp
GitHub Login: @eliotcowley
Microsoft Alias: elcowle

Thanks for taking the time to let us know about this and we sincerely apologize for the delayed response. Due to the sheer volume of feedback in our repo, we are currently prioritizing new Issues. If you believe your feedback is still actionable, let us know either directly in this thread or by filing a new Issue and we’ll work to incorporate the suggestions into the documentation. Though the Issue will be marked as Closed, I will monitor any replies that come afterwards so feel free to treat this like an open Issue. Many thanks!


Error when downloading sass

As soon as I add a scss link to my index.html, trunk build or trunk serve fails with :
error from HTML pipeline

Caused by:
    0: error from asset pipeline
    1: failed downloading release archive
    2: error sending HTTP request
    3: error sending request for url (https://github.com/sass/dart-sass/releases/download/1.37.5/dart-sass-1.37.5-linux-x64.tar.gz): error trying to connect: dns error: No connections available
    4: error trying to connect: dns error: No connections available
    5: dns error: No connections available
    6: No connections available

I am wondering what might be happening. I'm on arch linux, with firejail and apparmor, and I wonder if somehow the dns is blocked somewhere...
I found a workaround for my case actually: removing "trust-dns" from reqwest's features in trunk's Cargo.toml makes the request complete, and the rest seems to work fine. So the issue seems to be related to reqwest and/or trust-dns.
Also, I suggest using the installed sass if it is available.

Any movement on this? I have this issue now as a new trunk user and it's breaking my forward momentum.
I would prefer to not have to copy the repo to fix this.

Hello all! I am sorry to hear that folks have been blocked by this issue. As far as I can tell, this appears to be an issue with configuration on your host machine. As suggested, it must be an issue with DNS being blocked. As much diagnostics info as you can muster will help us to resolve this issue for you and others in a more robust / automated way in the code.
The main thing I can suggest as an immediate workaround is simply to download the version of sass that you need manually. If it is already present on your machine, and matches the version which you require, then Trunk will not attempt to download anything.
Docs
The reference Trunk.toml in the repo has an example of how to specify the version of a tool: https://github.com/thedodd/trunk/blob/master/Trunk.toml#L33-L35
As you can see in the code here: https://github.com/thedodd/trunk/blob/master/src/tools.rs#L241-L242, Trunk will not attempt to install a new tools as long as it detects that the tool already exists on your PATH and has the correct version.
Summary: install the sass tool manually, and ensure it is the correct version. As long as you do that, Trunk will not attempt to download the tool for you.

For what it's worth I just dealt with this after we switched our web assembly project to use trunk instead of parcel. I haven't verified any of this so take it all with a grain of salt, but maybe it can help point to the issue.
For the most part we had no issues but with our windows build container if we ran trunk build --release via npm it would encounter this exact dns issue. Running trunk build --release directly, rather than via npm resolved the issue for us at least for now.


Fix for default librato snapTime and default flushInterval

It appears defaults were assumed to be in ms not seconds. Led to metrics being rejected by librato for being snapped to 2.7 hours ago and so outside of an acceptable time window. 10 recommended for both settings.

Thanks for catching this! Rather than merge the PR, I created a commit that adjusts the default for librato_snapTime to 10 seconds as well as add some missing params included in the npm module (ref be96fbc).
Also, I did not change the flushInterval as you originally submitted since the statsd default is 10000 ms (ref here). If you need to adjust the flushInterval, you can do so when you call the module like so:
class { 'statsd':
  flushInterval => 10
}

Hope this helps!


Add new accounts scopes

This PR adds 3 new scopes

accounts - List of accounts. This is allows applications to get the account names without the ability to generate subtokens. For backwards compatibility this scope is always set if any gw2:* scope is set.
accounts.verified - Include the ownership verification status for each account in the /api/accounts response.
accounts.displayName - Include the custom user-set display name for each account in the /api/accounts response

Does it make sense to add a DB migration to add the accounts scope to every existing authorization with a gw2:* scope, so we don't have to care about backwards compatibility in code and always check for both accounts and gw2:* scopes?


Add an addon options example

The scripts_argument example was removed recently.
As discussed on slack, creating an issue so that this isn't overlooked

I think this serves the purpose https://github.com/mitmproxy/mitmproxy/blob/master/examples/simple/custom_option.py

👍


[BUG] Wounds affecting max hp value leads to readability issues and problems with the damage planner

Module Version: v0.3.27
Describe the bug
When adding wounds to an actor, while using a health bar(in my case with Bar Brawl, but I believe it would still be an issue with the standard resource bars), 50% of a character's HP becomes harder to gauge. With 0 Wounds, it's easy to tell someone is Bloodied when their hp hits the half-way mark, or 50% if you have a percentage label:

However, with 1 wound, and the same amount of hp, that mark is changed instead to 67%(this token has the same amount of hp, but due to the lowered max hp, it reads as higher):

This is mainly an issue from the GM perspective, since foes are unlikely to have Wounds and you can tell from your own sheet when you're Bloodied. The GM however has to open a sheet to check if a PC is Bloodied, unless they memorize each PCs current Wounds.
Additionally, the Damage Planner evidently uses the token/actor's max hp affected by wounds to determine what 25% hp damage is(the correct value is 8; the second line is after adding a wound which causes it to treat 25% of 32 hp as 6):

To Reproduce
Steps to reproduce the behavior:

Create a character, drag their token onto the canvas
Set up a resource bar to track their hp, and display a percentage
Set their hp to 50% of their max(14 for Vagabonds, 16 for Wrights, 20 for Stalwarts and Mendicants)
Add a wound; the percentage displayed by the bar will jump up to a value around 67%, making it harder to judge at a glance that the PC is Bloodied

Expected behavior
I would appreciate it if it were easier to judge at a glance whether or not a PC is Bloodied. Having something closer to the example HP bar in the book's example(pg 82 of Icon 1.5) would be nice, but I'm aware that getting Wounds and Vigor to display like that requires Bar Brawl, and that module is not currently marked as a dependency for this system/not everyone will necessarily want to use it.
Additionally, the Damage Planner's 25% button should give the same amount of damage regardless of the number of wounds the character has.

I've tweaked this behavior for the next release. Max hp will remain constant.
There is now a new field on players (system.eff_max_hp) that tracks the old reduced value.


Duplicate "container element"s

Version
3.2.30
Reproduction link
stackblitz.com
Steps to reproduce
In Vue 2 when we wrap things in #app we don't get 2 container elements.
In Vue 3 though, we do.
Check Vue 2 project: https://codesandbox.io/s/reverent-tdd-4hs4j?file=/src/App.vue
Check Vue 3 project: https://stackblitz.com/edit/vitejs-vite-jnq5k4?file=src/App.vue
Vue 2 screenshot:

Vue 3 screenshot:

Notice the 2 container elements with id app in Vue 3 version
What is expected?
Vue 2 and Vue 3 should both render one container element
What is actually happening?
In Vue 3 2 nested container elements are rendered

I know that in Vue 3 we can have multiple root elements, but I think the container elements functionality should be the same in Vue 3.

No, this is a breaking change in Vue 3 and that is intentional.

@LinusBorg any reason why it is a breaking change and a link where is documented as such?

The reason is "Fragments", pretty much. As we can't guarantee a single root node, replacing the element at mount with several others, whose number also could change over time, could have unintended side-effects in cases where the document in which the app is mounted is controlled by other code, or break styling etc.
The RFC can be found here https://github.com/vuejs/rfcs/blob/master/active-rfcs/0009-global-api-change.md#mounting-behavior-difference-from-2x
Docs: https://vuejs.org/api/application.html#app-mount

You can mount to body, if that helps.
I can  accept that you can't understand it but that's what it is.


ScalaTest dependency not downloaded?

$ cat project/build.sbt
version := "0.1"
scalaVersion := "2.9.1"
resolvers += Classpaths.typesafeResolver
resolvers += "sbt-idea-repo" at "http://mpeltonen.github.com/maven/"
libraryDependencies += "org.scalatest" %% "scalatest" % "1.6.1" % "test"
addSbtPlugin("com.github.mpeltonen" % "sbt-idea" % "0.11.0")
addSbtPlugin("com.typesafe.startscript" % "xsbt-start-script-plugin" % "0.3.0")
addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse" % "1.4.0")
$ sbt update test
[info] Loading project definition from E:\work\experiments\scala\helloblueeyes\project
[info] Updating {file:/E:/work/experiments/scala/helloblueeyes/project/}default-3b8c51...
[info] Done updating.
[info] Set current project to helloblueeyes (in build file:/E:/work/experiments/scala/helloblueeyes/)
[success] Total time: 0 s, completed Oct 18, 2011 12:15:08 PM
[info] Compiling 1 Scala source to E:\work\experiments\scala\helloblueeyes\target\scala-2.9.1\test-classes...
[error] E:\work\experiments\scala\helloblueeyes\src\test\scala\StackSpec.scala:1: object scalatest is not a member of package org
[error] import org.scalatest.FlatSpec
[error]            ^
[error] E:\work\experiments\scala\helloblueeyes\src\test\scala\StackSpec.scala:2: object scalatest is not a member of package org
[error] import org.scalatest.matchers.ShouldMatchers
[error]            ^
[error] E:\work\experiments\scala\helloblueeyes\src\test\scala\StackSpec.scala:8: value should is not a member of java.lang.String
[error]   "A Stack" should "pop values in last-in-first-out order" in {
[error]             ^
[error] E:\work\experiments\scala\helloblueeyes\src\test\scala\StackSpec.scala:16: not found: value it
[error]   it should "throw EmptyStackException if an empty stack is popped" in {
[error]   ^
[error] four errors found
[error] {file:/E:/work/experiments/scala/helloblueeyes/}default-40d9ce/test:compile: Compilation failed
[error] Total time: 1 s, completed Oct 18, 2011 12:15:09 PM

Please use the mailing list for support.  Thanks!


Fix the reading of DSA parameters files using the dsaparam app

DSA parameters files were failing to load correctly. We also fix a number
of follow on issues which resulted in multiple similar errors messages
being displayed for the same problem, as well as a seg-fault.

This pull request is ready to merge

Fixup pushed, addressing @levitte's comment above.
@t8m - please can you reconfirm your approval?

Grrr. Typo fixed.

This pull request is ready to merge

Pushed. Thanks.


setup: Add extras-require

extras-require lets the user decide on any extra packages they may
want to install. This way users can just request for [all] and all
packages that shap uses internally will be installed in one go.
@slundberg this is somewhat of a follow up for https://github.com/slundberg/shap/issues/823
I understand that most packages are "optional", but in local/analytical environments some folks don't like tracking all dependencies and just want everything to work. So, added a extras_require as per setuptools convention to maintain a list of such dependencies.
These can be installed with:
pip install shap[all]

Thanks! I think the CI issue is with TensorFlow 2 (so unrelated to this PR). I like the idea of doing this for 'plots' and perhaps 'other', but I am not sure it makes sense for the modeling packages. For modeling packages users can't even try to use SHAP until they have those installed (since they won't have a model object).


Plugin system?

Hello !
Is a plugin system planned on Hermes roadmap? :)
I would live to develop one to add support for image charts to hermes. (like I did for mjml with mjml-charts)

Hi @FGRibreau !
No plugin system planned yet :).
Mjml is a framework, Hermes is not. Basically, Hermes is just Golang HTML templates describing typical emails ^^ (containing optional button, table, and so on). It's not meant to be as flexible as Mjml. User defines data and theme displays data as it wants.
Without any plugin system, a simple idea could be to add a Chart in Email.Body. But, every built-in theme will have to implement charts.
Can you give us more details of your idea and how it would be used with Hermes ? Do you want to include charts with your https://image-charts.com service ?

Without any plugin system, a simple idea could be to add a Chart in Email.Body. But, every built-in theme will have to implement charts.

Yes, that would be nice, who does not want to add charts to reports ? :)

Can you give us more details of your idea and how it would be used with Hermes ?

I could think of somthing like this:
type Chart struct {
	params map[string]string
}

Note that we could generate automatically generate the struct from the swagger/openapi specification like we did for mjml-chart thus offering automatic documentation and tests :) But it would be better as an plugin (so we could automatically update it) since here it's not planned it might not be the best idea ^^

Do you want to include charts with your https://image-charts.com service ?

That's why we created image-charts in the first place indeed, it was to hard for each project to setup server-side chart rendering, storage and scaling.

I think chart addition would be great !
Although, I think Chart struct should be more service-agnostic as possible, meaning it should contains points or something, not just params (it may not be possible depending on the kind of chart ?).
Maybe using an interface instead of struct would be nice, meaning we could have a plugin-like system.
Next step would be to propose a Chart type here, then community could debate on it 👍

Hi @matcornic !

Although, I think Chart struct should be more service-agnostic as possible, meaning it should contains points or something, not just params (it may not be possible depending on the kind of chart ?).

As you can see, it highly depends on the backend, Image-Charts follows Google Image Charts API so we could be our attributes on that but that does a LOT of attributes (the good news is we could definitely generate the Chart struct from the swagger.json spec and only keep the completely compatible parameters between the two (just like we did in mjml-chart) and offer a way to change the endpoint so the deprecated Google Image Charts and Image-Charts will be supported.

@FGRibreau I think this is the way to go 😉
Seeing the (big) swagger spec, I think that some fields don't need to be in the final struct. Just keep it as simple as possible, with convention over configuration principle in mind. I don't want the users to be overwhelmed with an overcomplicated Chart struct.
Thank you again for your proposal. I assign you to the issue 😛

type Chart struct {
  // (optional) Image-Charts or Google Image Charts endpoint
  endpoint string
  // (required) chart type
  cht string
  // (required) chart data
  chd string
  // (optional) text format custom scaling
  chds string
  // (optional) output fake format
  chof string
  // (required) chart size
  chs string
  // (optional) text for each series, to display in the legend
  chdl string
  // (optional) chart legend text and style
  chdls string
  // (optional) grid lines
  chg string
  // (optional) series colors
  chco string
  // (optional) chart title
  chtt string
  // (optional) chart title colors and font size
  chts string
  // (optional) line thickness and solid/dashed style
  chls string
  // (optional) pie chart labels
  chl string
  // (optional) Background Fills
  chf string
  // (optional) gif configuration
  chan string
  // (optional) doughnut chart inside label
  chli string
  // (optional) image-charts enterprise `account_id`
  icac string
  // (optional) HMAC-SHA256 signature
  ichm string
  // (optional) Force watermark display even if the chart was signed with an enterprise account
  icwt bool
}

I used this simple JS code to generate it:
console.log(`
type Chart struct {
  // (optional) Image-Charts or Google Image Charts endpoint
  endpoint string
${swagger.paths['/chart'].get.parameters
  .filter(x => x['x-meta'].implementation.status === 'COMPLETE')
  .map(x => `  // (${x.required ? 'required' : 'optional'}) ${x.description}\n  ${x.name} ${x.type === 'boolean' ? 'bool' : x.type}`)
  .join('\n')}
}`);

Ok Nice ! You may have to set struct properties as public for them to be available in the Go templating. (Just uppercase the first letter)
I'm not sure private functions and properties are available
Or maybe easier, create a public function on Chart type, rendering the needed URL, and just use this function in the template.
Note: I'm on holidays for a week, so I probably won't be able to help you until then 🌎🌍🌏

Hello @matcornic,
Oh did not see that you were from Rennes! (I'm from Nantes) are you going to Breizh Camp? I will!

@FGRibreau So will I ;)

Awesome, see you there!


Get the distributions of human pre-miR overhangs

get the distributions of human pre-miR overhangs relative to the mature forms, one for each side?
Here is a schema of what we need:
pre-miR
        10        20        30        40        50        60
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN pre-miR
     NNNNNNNNNNNNNNNNNNNNN                                      mature miR-5p
                                  NNNNNNNNNNNNNNNNNNNNNN        mature miR-3p
<<<<<                                                           pre-miR overhang 5p
                                                        >>>>>>> pre-miR overhang 3p

For this hypothetical miRNA locus, the 5p and 3p pre-miR overhangs would be 5 nts and 7 nts.
If there is only one mature miRNA annotated, then calculate both overhangs to that one (one will usually end up quite long in those cases).
Distributions can be represented as count tables (one for each distribution), e.g.,:

Overhang (nts)
Count
Fraction

0
?
?

1
?
?

...
...
...

20
?
?

20+
?
?

Here's the table:

Overhang (nts)
Count_5p
Fraction_5p
Count_3p
Fraction_3p

0
31
0.0162%
137
0.0714%

1
11
0.0057%
27
0.0141%

2
14
0.0073%
33
0.0172%

3
21
0.0109%
33
0.0172%

4
18
0.0094%
37
0.0193%

5
13
0.0068%
24
0.0125%

6
7
0.0036%
30
0.0156%

7
16
0.0083%
33
0.0172%

8
22
0.0115%
38
0.0198%

9
63
0.0328%
63
0.0328%

10
87
0.0454%
131
0.0683%

11
12
0.0063%
51
0.0266%

12
14
0.0073%
48
0.025%

13
11
0.0057%
33
0.0172%

14
12
0.0063%
31
0.0162%

15
40
0.0209%
61
0.0318%

16
7
0.0036%
6
0.0031%

17
4
0.0021%
16
0.0083%

18
2
0.001%
9
0.0047%

19
3
0.0016%
14
0.0073%

20
6
0.0031%
14
0.0073%

20+
485
0.2529%
991
0.5167%

Just in case you prefer a separate file, here it is:
overhang.txt

Thanks!
A couple of comments:

Presumably, the fractions are fractions, not percentages. So there shouldn't be a % in the table. Or otherwise multiple them by 100. Guess that was my bad, because I put fraction in the title of the example table, but then I put ?% in the rows...
Given that there should be a 5p and 3p overhang for every pre-miR, the fractions summed up should add up to 1. But they don't. Maybe for 3p they get reasonably close (0.97), but for 5p they are far off (0.47). Any idea why that is?
We should be getting an equal number of overhangs for both 5p and 3p, but the numbers are wildly different (899 vs 1860). Again, what happened to all the 5p counts? Also, it seems that to calculate the fractions you are dividing your counts by 1918. So apart from the issue with the 5p counts - what is the issue with the ~60 premiRs for which you don't get any overhangs at all? Don't they have a mature miRNA annotated?

The problem with the difference between the counts for the 5p and 3p overhang has been solved by taking into account the strand in which the pre-miR is found. now they sum up both to 1891 and their cumulative sum are 0.985 and 1.0002 for the 5p and 3p respectively when computing the fraction to this total.
Still, there are 27 pre-miRs missing. I figured out that the problem is found on the filtering of the file as it gives me 992 mature pre-miRs with 2 mature sequences and 899 with one single mature miRNA (which sum to 1891).  The commands to generate the files had been:
## pre-miRNA file
grep "miRNA_primary" hsa.gff3 > pre_miran.gff3

## mature miRNA file
grep -v "miRNA_primary" hsa.gff3 > mirna.gff3

## 5p mature
grep "5p" mirna.gff3 > mirna_5p.gff3

## 3p mature
grep "3p" mirna.gff3 > mirna_3p.gff3

## single mature
grep -v -e  "5p" -e "3p" mirna.gff3 > mirna_single.gff3

I was not able to find the error on that nor the problem in the files...

The new results - even if I do not believe they are valid - are:

Overhang (nts)
Count_5p
Proportion_5p
Cumulative_5p
Count_3p
Proportion_3p
Cumulative_3p

0
81
0.0422
0.0422
138
0.0730
0.0730

1
19
0.0099
0.0521
27
0.0143
0.0873

2
26
0.0136
0.0657
34
0.0180
0.1053

3
25
0.0130
0.0787
34
0.0180
0.1233

4
33
0.0172
0.0959
37
0.0196
0.1429

5
103
0.0537
0.1496
24
0.0127
0.1556

6
20
0.0104
0.1600
32
0.0169
0.1725

7
30
0.0156
0.1756
35
0.0185
0.1910

8
36
0.0188
0.1944
38
0.0201
0.2111

9
95
0.0495
0.2439
63
0.0333
0.2444

10
110
0.0574
0.3013
131
0.0693
0.3137

11
25
0.0130
0.3143
51
0.0270
0.3407

12
40
0.0209
0.3352
53
0.0280
0.3687

13
34
0.0177
0.3529
33
0.0175
0.3862

14
50
0.0261
0.3790
32
0.0169
0.4031

15
85
0.0443
0.4233
62
0.0328
0.4359

16
13
0.0068
0.4301
7
0.0037
0.4396

17
8
0.0042
0.4343
17
0.0090
0.4486

18
7
0.0036
0.4379
10
0.0053
0.4539

19
13
0.0068
0.4447
14
0.0074
0.4613

20
17
0.0089
0.4536
14
0.0074
0.4687

20+
1021
0.5323
0.9859
1005
0.5315
1.0002

And here's the file:
overhang.txt

Great.
Are you saying that 27 are missing because there are 1918 pre-miRs in the file, or because I said there are 1918 pre-miRs? Because I don't have that number from the file, but rather deduced it from your fractions (which may be wrong, if your calculation of fractions was wrong for the first table).

Okay, I've had a look at the annotation file myself. There are indeed 1918 pre-miRs and all of them have either one or two mature miRNAs annotated. See here for details.
Based on that, I don't see any reason why you shouldn't get overhangs for all pre-miRs. Most likely there are issues with your code, and until we know for sure that it does what we want, it doesn't make too much sense starting to interpret the results you shared.
Can you please prepare an annotated Jupyter notebook for your code and share it? Something like the one I linked above. More generally, please prepare Jupyter notebooks for these kinds of explorations. To share it, you can create a new repo in your own personal space, or -perhaps easier- push a branch to the MIRFLOWZ repo (or whatever project you are working on), like I did.
If yout want to play with the notebook I prepared, note that it requires Python 3.8 because of the use of self-documenting f-strings. Easiest is if you follow the installation instructions here.

I just saw your edition, haven't make the sanity checks - will add them soon - but the problem has been solved, I already posted the jupyter notebook and here's the final table:

Overhang (nts)
Count_5p
Proportion_5p
Cumulative_5p
Count_3p
Proportion_3p
Cumulative_3p

0
83
0.0433
0.0433
139
0.0725
0.0725

1
19
0.0099
0.0532
28
0.0146
0.0871

2
27
0.0141
0.0673
37
0.0193
0.1064

3
25
0.0130
0.0803
34
0.0177
0.1241

4
33
0.0172
0.0975
37
0.0193
0.1434

5
102
0.0532
0.1507
24
0.0125
0.1559

6
21
0.0109
0.1616
32
0.0167
0.1726

7
31
0.0162
0.1778
35
0.0182
0.1908

8
36
0.0188
0.1966
39
0.0203
0.2111

9
95
0.0495
0.2461
63
0.0328
0.2439

10
111
0.0579
0.3040
133
0.0693
0.3132

11
26
0.0136
0.3176
51
0.0266
0.3398

12
40
0.0209
0.3385
53
0.0276
0.3674

13
35
0.0182
0.3567
33
0.0172
0.3846

14
49
0.0255
0.3822
33
0.0172
0.4018

15
88
0.0459
0.4281
63
0.0328
0.4346

16
14
0.0073
0.4354
7
0.0036
0.4382

17
8
0.0042
0.4396
17
0.0089
0.4471

18
7
0.0036
0.4432
10
0.0052
0.4523

19
12
0.0063
0.4495
14
0.0073
0.4596

20
17
0.0089
0.4584
15
0.0078
0.4674

20+
1036
0.5401
0.9985
1021
0.5323
0.9997

And the final file:
overhang.txt

Thanks @deliaBlue.
The way you did the counting is a bit complicated (and that was probably the reason you ended up having mistakes), but it seems to do the trick (difficult to say for sure, though, without more sanity checks and manual checks in the notebook).
Given that the GFF is sorted in a way that the mature miRNAs of a given pre-miR are immediately following the record for that pre-miR, there is no need to split up things into different files and worry about how they are named (5p, 3p etc.; nobody ever claimed that these names would be consistent, so not good to make such assumptions).
So one way you could have done that (without using things like Pandas or htseq or BioPython):

Go through the file "pre-miR by pre-miR", including the corresponding mature miRs (you can see in my notebook how this can be done; it's important that you have to treat the last entry separately, outside of the loop in this sort of algo)
If you have more than one miR, "merge" them, i.e., create one new dummy region with that the starts with the smaller of the two start positions and ends with higher of the two end positions)
Calculate the difference between (1) the pre-miR start and the dummy (or single) miR start (-> 5p overhang), and (2) the pre-miR end and the dummy (or single) miR (-> 3p overhang).

Anyway, assuming your manual tests will show that your algo works and the results are accurate, then it seems that 15-30% of pre-miRs have a very short overhang (5 nt or less) on at least one side (and still 10% with <2 nt). That's of course a lot (way more than I would have thought).
So extending the pre-miR annotations seems indeed unavoidable for the pileup way of counting.
There are several options for how to do that, including at least the following:

Extend all pre-miRs by n nucleotides on either side.
Extend only pre-miRs with pre-miR/mature miR overhangs shorter than n on either side.
Extend only if there is actual data supporting an extension, i.e., alignments that overlap partly, with >= m nucleotides, either
a. the pre-miR
b. a mature/canonical miRNA

Out of these, personally I tend to favor option (2), for the following reasons:

The regions to consider for the counting should be the same across runs to make them comparable; with that, (1) and (2) are preferable to (3)
Less modifications are better; with that, (2) is better than (1)

If performance is an issue, there are couple more considerations:

(1) and (2) could run as soon as the workflow starts and would surely be completed by the time counting could commence; the extensions in (3), on the other hand, could only be applied during the counting, so they would certainly increase the total runtime and an efficient algorithm here would be critical.
Longer references to pile up over also increase the time it takes to count (not sure with what complexity), so from that point of view, always extending is penalized over a data-dependent extension. However, with an extension of n = 10 (which, in my view, is plenty and - with it being the most common overhang both for 5p and 3p - seems like a good default), the maximum extension of the region would be 20 nts for (1) and (2), which I don't think would affect the runtime of the counting all that much. Also, with n = 10, ~40-70% of miRNAs would not need to be extended at all, when following (2), so whatever the impact is, it would likely be a lot less than what it would be for (1).

again, (2) seems like a middleground here, because even with setting n to 10 , ~40-70% of the pre-miRs would not be extended at all, and those that are, only by a maximum of 20nts
In both cases, I would make n (or m) configurable, within a reasonable range, say, 0 to 30 (max length of a miRNA and then some). In princple, we wouldn't need to put an upper bound, but performance may become an issue if n/m become too long, plus it's hard to imagine that anything reasonable would come out of setting a very high value for the extension in the context of this workflow.
What are your thoughts regarding the extension, @deliaBlue and @mzavolan? Let's try to decide that ASAP, so that we can go ahead writing the issues and planning their implementation :pray:

OK, good that we had a look. Since in previous discussions we came to the conclusion that too big a shift would mean that it makes little sense to call the variant an isomir, then we can go with option #2 that Alex proposed and extensions do not need to be longer than 10 nucleotides.

@deliaBlue: If you agree, then I think you can close this issue and we can go back to #7 and finish that up.

After a couple of modifications, the results differ from the last ones - check here - but still ~10-25% of the pre-miRs have an overhang equal or less than 5 nucleotides on at least one side and around 45% of them have an overhang of 10 or less nucleotides. Option 2 then, seems a good one.


Colonies

The model can handle it, I'm pretty sure, just have to figure out the weird relationships between Colony, ColonyTile, TradeFleet, etc.

well, I did that


aio-next

Description
The next version of the cli, a major update ( breaking change )

use current versions of node ( 14, 16, 18 )
use current oclif3 ( update tests, mocks, flags, requires to support it )
rewrite some promise based tests to be clean awaitables

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

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

Checklist:

[x] I have signed the Adobe Open Source CLA.
[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.

tests are failing because the plugins have incompatible peers as the updated versions are only pre-released.

I removed reviewers hoping that I could make this a draft pr ... but I don't see the button
Consider this a draft until I get the telemetry to stop blocking CI

Ran aio info and noticed a warning at the bottom about the current Node version not being supported, should this be updated?
  System:
    OS: macOS 12.1
    CPU: (10) arm64 Apple M1 Max
    Memory: 295.95 MB / 32.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.14.2 - /usr/local/bin/node
    Yarn: Not Found
    npm: 8.5.0 - /usr/local/bin/npm
  Virtualization:
    Docker: 20.10.14 - /usr/local/bin/docker
  npmGlobalPackages:
    @adobe/aio-cli-next: 8.3.0-pre.2022-07-26.sha-8913399a

  Proxies:
    http: (not set)
    https: (not set)
  CLI plugins:
    core:
      @adobe/aio-cli-next 8.3.0-pre.2022-07-26.sha-8913399a
      @adobe/aio-cli-plugin-app 8.6.1-pre.2022-06-25.2ab6c018
      @adobe/aio-cli-plugin-auth 2.6.0-pre.2022-06-07.d66e9d3c
      @adobe/aio-cli-plugin-certificate 0.4.0
      @adobe/aio-cli-plugin-config 3.0.1-pre.2022-06-08.bd8bc4be
      @adobe/aio-cli-plugin-console 3.4.2-next.1
      @adobe/aio-cli-plugin-events 1.1.6-pre.2022-06-23.21ddad9a
      @adobe/aio-cli-plugin-info 2.1.0-pre.2022-06-08.cb620207
      @adobe/aio-cli-plugin-runtime 5.4.0-pre.2022-04-28.734a6d2c
      @adobe/aio-cli-plugin-telemetry 0.4.0-pre.2022-06-06.03a0a836
      @oclif/plugin-autocomplete 1.3.0
      @oclif/plugin-help 5.1.12
      @oclif/plugin-not-found 2.3.1
      @oclif/plugin-plugins 2.1.0
      @oclif/plugin-warn-if-update-available 2.0.4
    user:
    link:
 ›   Warning: Node version not supported. Supported versions are 10, 12, and 14      <-----

Ran aio info and noticed a warning at the bottom about the current Node version not being supported, should this be updated?

Yup. https://github.com/adobe/aio-cli-plugin-info/blob/cb620207d70485cc9e5784d66708c77093d78467/src/commands/info.js#L122 looks like we hard-code this


Make Freezer usable with strict Content Security Policy

Hi there,
This is a small PR to ensure Freezer can be used with a strict Content Security Policy. At present, it cannot, because of a line in utils.js that evals a string: var global = (new Function("return this")());.
I fixed this by replacing the line with the same functionality as used by Browserify:
var global = typeof global !== 'undefined' ?
             global :
             typeof self !== 'undefined' ?
               self :
               typeof window !== 'undefined' ?
               window :
               {};

For background, you can read a detailed discussion of how to get the global Javascript object here:
https://www.contentful.com/blog/2017/01/17/the-global-object-in-javascript/
And browserify's use of this approach is here:
https://github.com/substack/insert-module-globals/blob/769f4bd08e01b77a620f2e2de1d2249c8311b0a2/index.js#L30
Many thanks for such a beautiful library!
Greg

@dantman I changed the indentation to match the rest of the file.

Thanks for noticing it @greghuc, nice catch! Also thanks for the make it pretty @dantman
I'll merge this for the next version


Bitcode support on iOS

Hi,
I noticed that your SDK don't support the bitcode.
Is it possible to plan the support on the iOS SDK?
Thanks

Hi @NicolasLourenco thanks for the message.  It is definitely on our backlog, but no ETA at the moment.


Getting receipt block mismatch

Hi! We just upgraded our graph node to 0.27.0 and deployed a new subgraph using the receipt: true feature in some of the handlers. The sync works for a while but then it stops syncing at block 21373261 (Sokol network).
This is from the logs:
Aug 05 09:17:05.140 INFO Applying 22 entity operation(s), block_hash: 0x01b3fa8fb115d18ee9f78e4acdbc58cf52e17cb863a617c7497f2d2df718b8c1, block_number: 21373178, sgd: 1, subgraph_id: QmTD59KigFww9aCNHDDvwMh8g6HxLfv4hZMFzFahdi7HFb, component: SubgraphInstanceManager
Aug 05 09:17:05.386 INFO Done processing trigger, gas_used:<PHONE_NUMBER>6, data_source: CardToken, handler: handleTransfer, total_ms: 239, transaction: 0x4577…b6a8, address: 0xb236…f7ee, signature: Transfer(indexed address,indexed address,uint256), sgd: 1, subgraph_id: QmTD59KigFww9aCNHDDvwMh8g6HxLfv4hZMFzFahdi7HFb, component: SubgraphInstanceManager
Aug 05 09:17:05.409 INFO Applying 9 entity operation(s), block_hash: 0x832ce6b0ac64b6163e8390377938f1e92aefe4395e92c95a8d3e9076b3085a30, block_number: 21373179, sgd: 1, subgraph_id: QmTD59KigFww9aCNHDDvwMh8g6HxLfv4hZMFzFahdi7HFb, component: SubgraphInstanceManager
Aug 05 09:17:27.198 INFO Syncing 1 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 1, blocks_behind: 1, latest_block_head: 27148399, current_block_head: 27148398, provider: poa-sokol-rpc-0, component: BlockIngestor
Aug 05 09:17:47.066 INFO Syncing 1 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 1, blocks_behind: 1, latest_block_head: 27148400, current_block_head: 27148399, provider: poa-sokol-rpc-0, component: BlockIngestor
Aug 05 09:17:53.194 INFO Syncing 1 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 1, blocks_behind: 1, latest_block_head: 27148401, current_block_head: 27148400, provider: poa-sokol-rpc-0, component: BlockIngestor
Aug 05 09:18:17.280 INFO Syncing 1 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 1, blocks_behind: 1, latest_block_head: 27148402, current_block_head: 27148401, provider: poa-sokol-rpc-0, component: BlockIngestor
Aug 05 09:18:41.414 INFO Syncing 1 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 1, blocks_behind: 1, latest_block_head: 27148403, current_block_head: 27148402, provider: poa-sokol-rpc-0, component: BlockIngestor
Aug 05 09:19:04.899 INFO Scanning blocks [21373252, 21373252], range_size: 1, sgd: 1, subgraph_id: QmTD59KigFww9aCNHDDvwMh8g6HxLfv4hZMFzFahdi7HFb, component: BlockStream
Aug 05 09:19:05.025 INFO Scanning blocks [21373253, 21373262], range_size: 10, sgd: 1, subgraph_id: QmTD59KigFww9aCNHDDvwMh8g6HxLfv4hZMFzFahdi7HFb, component: BlockStream
Aug 05 09:19:05.181 INFO Scanning blocks [21373263, 21373362], range_size: 100, sgd: 1, subgraph_id: QmTD59KigFww9aCNHDDvwMh8g6HxLfv4hZMFzFahdi7HFb, component: BlockStream
Aug 05 09:19:05.304 INFO Scanning blocks [21373363, 21374362], range_size: 1000, sgd: 1, subgraph_id: QmTD59KigFww9aCNHDDvwMh8g6HxLfv4hZMFzFahdi7HFb, component: BlockStream
Aug 05 09:19:05.359 INFO Done processing trigger, gas_used:<PHONE_NUMBER>1, data_source: DaiToken, handler: handleTransfer, total_ms: 213, transaction: 0x89d4…afe5, address: 0xfedc…30d1, signature: Transfer(indexed address,indexed address,uint256), sgd: 1, subgraph_id: QmTD59KigFww9aCNHDDvwMh8g6HxLfv4hZMFzFahdi7HFb, component: SubgraphInstanceManager
Aug 05 09:19:05.363 INFO Applying 6 entity operation(s), block_hash: 0xa4159a345ebee9d14ca8777b609c215475c6613e7ace3169cfdad5f03badb769, block_number: 21373261, sgd: 1, subgraph_id: QmTD59KigFww9aCNHDDvwMh8g6HxLfv4hZMFzFahdi7HFb, component: SubgraphInstanceManager
Aug 05 09:19:05.420 INFO receipt block mismatch, tx_hash: 0xb06d…a1d5, block_hash: 0x0219…2ed0, receipt_block_hash: 0x1e76…298d, sgd: 1, subgraph_id: QmTD59KigFww9aCNHDDvwMh8g6HxLfv4hZMFzFahdi7HFb, component: BlockStream
Aug 05 09:19:08.832 INFO Syncing 1 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 1, blocks_behind: 1, latest_block_head: 27148404, current_block_head: 27148403, provider: poa-sokol-rpc-0, component: BlockIngestor
Aug 05 09:19:33.160 INFO Syncing 1 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 1, blocks_behind: 1, latest_block_head: 27148405, current_block_head: 27148404, provider: poa-sokol-rpc-0, component: BlockIngestor
Aug 05 09:19:56.090 INFO Syncing 1 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 1, blocks_behind: 1, latest_block_head: 27148406, current_block_head: 27148405, provider: poa-sokol-rpc-0, component: BlockIngestor
Aug 05 09:20:21.553 INFO receipt block mismatch, tx_hash: 0x12a7…7460, block_hash: 0x3622…36e6, receipt_block_hash: 0x238d…c067, provider: poa-sokol-rpc-0, component: BlockIngestor
Aug 05 09:20:21.564 INFO receipt block mismatch, tx_hash: 0xda6d…f8ca, block_hash: 0x3622…36e6, receipt_block_hash: 0x238d…c067, provider: poa-sokol-rpc-0, component: BlockIngestor
Aug 05 09:20:21.572 INFO receipt block mismatch, tx_hash: 0xc7c5…fb6d, block_hash: 0x3622…36e6, receipt_block_hash: 0x238d…c067, provider: poa-sokol-rpc-0, component: BlockIngestor
...

Any ideas? What does this error mean?

It means that when requesting receipts for a recent block, the json-rpc server returned a receipt with a block hash that did not match the block we were originally requesting the receipt for. This can happen in normal operation when a reorg happens, but if the graph node cannot make progress then that means it is getting inconsistent data from json-rpc.

@leoyvens thank you but I'm still struggling to understand why is this happening. We're using a stable and reliable RPC node which works great, but after upgrading the graph node from 0.26.0 to 0.27.0 and specifying receipt: true for a couple of event handlers (to get the gasUsed), we start getting this error and the syncing stops.

hi @jurgenwerk - can you confirm the block where indexing stops? In the logs I see
Aug 05 09:19:05.420 INFO receipt block mismatch, tx_hash: 0xb06d…a1d5, block_hash: 0x0219…2ed0, receipt_block_hash: 0x1e76…298d, sgd: 1, subgraph_id: QmTD59KigFww9aCNHDDvwMh8g6HxLfv4hZMFzFahdi7HFb, component: BlockStream

But when I look at the block you mention (21373261), that block is successfully processed, so it seems to be encountering the error at the next block with a trigger - and our logs don't give the whole tx_hash or block_hash.
Could you run the Graph Node with GRAPH_LOG: trace and see if there is more information?

Try to set envirment:
export ETHEREUM_ANCESTOR_COUNT=1
export ETHEREUM_REORG_THRESHOLD=1

@gzliudan ETHEREUM_ANCESTOR_COUNT has actually been removed, just setting ETHEREUM_REORG_THRESHOLD is enough.

@leoyvens Yes, ETHEREUM_ANCESTOR_COUNT has been removed. Thank you very much.

Closing because we abandoned the upgrade to 0.27 and I am unsure what went wrong.


Possible to go full screen when video inside FlatList without having to buffer again?

Feature Request
What I want is the ability to go full screen when the video is inside a FlatList. I can't go full screen while the component is inside the FlatList so I need a new screen for the full screen video. If I were to create a new screen to place the full screen video in, I lose whatever I buffered when the video was in the FlatList.
Why it is needed
Scenario:
You present a feed of videos to the user. You have a button on each video to go full screen. The user presses the button and the user should be presented with the fullscreen video but shouldn't have to re-download/buffer the video again.
Possible implementation
Is it possible for components on seperate screens to share the same buffered video?

The same problem

+1

The same problem

Yes, please, any solution?

+1

+1

The same problem, any solution?

This feature is still needed... Can be linked to pip also, but needs architecte changes and Big changes on apps i think.
I explain the pip use case on Android:
When you go to pip, the whole activity goes to pip.
User wants to put the video in pip but continue browsing app catalog. Here we 2 activities... So the need is go be able to detach the player from an activity and reattach it to a second one...
A tricky use case, but usefull


fix bug in build deploy action.

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

Project coverage is 98.75%. Comparing base (196ce8d) to head (f051776).
Report is 1 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #106   +/-   ##
=======================================
  Coverage   98.75%   98.75%
=======================================
  Files          39       39
  Lines        1523     1523
=======================================
  Hits         1504     1504
  Misses         19       19

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


The Better Collada addon puts all the code in one file, is this a good idea?

Noting the recent discussion elsewhere regarding the Collada situation with Blender, I took a quick look at the code for the Better Collada addon and found that much of the code is in a file nearly 2000 lines long. I'm not really sure if that is such a good idea for the following reasons...

It becomes harder to maintain
It becomes more prone to bugs
It becomes more difficult to add functionality
It's more difficult to find certain pieces of code

I think in a sense, it would really help the cause of pushing the new exporter if the code can at leas, as a start, be split into different files where possible (so as to organize everything and make it easier to maintain/expand/fix). One example would be the common case of defining your functions in one file for use in another.
Just something to think about.

By the way, I'm talking about this file here
https://github.com/godotengine/godot/blob/master/tools/export/blender25/io_scene_dae/export_dae.py

I don't have any particular opinion, but it doesn't seem to be an issue to me. At any rate, this should be discussed at https://github.com/godotengine/collada-exporter.


Remove unused file-loader dependency?

Hi again :). I notice that although you mention file-loader in the static readme, and also have it installed in package.json, it's not actually used in the project.
git grep results for file-loader:

Would you like to remove it from the dependencies? I'd be happy to write a PR, and revise the readme to talk about file-loader as an option that a user has to install themselves.

file-loader is definitely necessary!
url-loader has file-loader as a peer dependency & it uses file-loader as its fallback.
And as the documentation says, you need file-loader to process & return the resolved path & filename, without it, you won't be able to resolve & build your assets.

Ah, a peer dependency 🙃. That's always confusing. Thanks!


Users thought key was a required parameter

Steps to Reproduce
Key is the first item in the parameter list of a widget, while it's not commonly needed. The last UX study participant initially thought key was required to create a Card, since key was the first thing he saw in the signature the IDE showed him, until he inspected the source of Card.

Can we consider moving key to the last of the parameter list? It's helpful to have more commonly used parameters come first. It should not affect API stability since key is a named parameter.
If changing the code is not a good idea, is it possible to change the presentation of constructor parameters in the IDE?
Flutter Doctor
[✓] Flutter (on Mac OS X 10.12.4 16E195, channel master)
• Flutter at /Users/taodong/Code/flutter_repos/flutter
• Framework revision a88379399e (3 hours ago), 2017-05-19 12:34:41 -0700
• Engine revision 82815836eb
• Tools Dart version 1.23.0-dev.11.11
[✓] Android toolchain - develop for Android devices (Android SDK 25.0.2)
• Android SDK at /Users/taodong/Library/Android/sdk
• Platform android-24, build-tools 25.0.2
• Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
• Java version: OpenJDK Runtime Environment (build 1.8.0_112-release-b06)
[✓] iOS toolchain - develop for iOS devices (Xcode 8.2.1)
• Xcode at /Applications/Xcode.app/Contents/Developer
• Xcode 8.2.1, Build version 8C1002
• ios-deploy 1.9.1
• CocoaPods version 1.2.0
[✓] Android Studio (version 2.3)
• Android Studio at /Applications/Android Studio.app/Contents
• Gradle version 3.2
• Java version: OpenJDK Runtime Environment (build 1.8.0_112-release-b06)
[✓] IntelliJ IDEA Community Edition (version 2017.1)
• Dart plugin version 171.4006
• Flutter plugin version 13.1

cc: @Hixie @pq

Maybe more generally flutter-intellij should show @required parameters first?  We certainly also can do manual ordering based on likely-hood of use. :) . FYI @devoncarew

Good catch. Thanks for bringing this up!

Manual ordering does change the order that IntelliJ displays the params in, so probably a good thing to do. Definitely possible to sort based on @required as well. Perhaps these should be listed first in the definition anyway?

👍
We could definitely sort @required first.  That said, is there any reason not to do that in the definition of Card?  Might be generally good style to recommend putting common (and especially required) parameters first in declarations (@munificent?).

Just to add to this, I also thought key was required. Not just because it is first, but because in the constructor signature it doesn't seem to have a default value like the other parameters. I guess Dart has a default implicit value of null or something, but I'm new to Dart (as I imagine most Flutter users are) and didn't know that and nothing in the docs I found says that you can leave it as null.
I was trying to use the Wrap layout, and first looked there for an example to see what key should be set to but there isn't one. Then I looked in the docs for Key but they don't really explain anything, other than that it is a unique key for widgets which I kind of guessed. Finally I realised that none of the other widgets take a key in the examples so maybe I can just leave it out. Tried it and it worked.
So to improve this you can:

Add basic examples to the API reference for all widgets/layouts showing at least how to create one (without using key).
Improve the Key documentation to explain what it actually is and that you can normally leave it as null.

cc @lukechurch who may have thoughts.
Great feedback @Timmmm.  Thank you!

@Timmmm for #2, can you clarify which of the following you looked at?

https://docs.flutter.io/flutter/widgets/Key-class.html
https://docs.flutter.io/flutter/widgets/Widget/key.html
https://docs.flutter.io/flutter/widgets/Wrap/Wrap.html
https://docs.flutter.io/flutter/widgets/Wrap-class.html
something else

For #1, I have a patch out which adds some sample code for Wrap:
https://github.com/flutter/flutter/pull/10214/files#diff-7f71460835520a1820d69cd0b6994c01R2396
It's just awaiting review before I can land it.

The request for more docs re: Keys is at https://github.com/flutter/flutter/issues/8818

@Hixie
I looked at all of those except https://docs.flutter.io/flutter/widgets/Widget/key.html ... which apparently has the best explanation!
Good work on the example. :-)

Cool, thanks. I'll make sure to make Key-class point to that. Taking this to #8818.

Might be generally good style to recommend putting common (and especially required) parameters first in declarations (@munificent?).

The language requires mandatory parameters appear before optional ones, so the style guide doesn't need to. (Neither the style guide nor the language know about @required, and the style guide generally avoids mentioning stuff that's not part of the language or core libraries.)
It's worded a little funny, but Effective Dart does say the most commonly passed optional positional parameters should appear earlier in the parameter list.
It doesn't say anything about named parameters since it doesn't matter as much with them, but maybe it should. Would you mind filing a tracking bug for that: https://github.com/dart-lang/site-www
I don't have much time for Effective Dart, but I'm hoping to do a big update before too long.

Seems reasonable to move key to the end (or near end) of the parameter list.
Consider this another +1 for moving @required into formal language semantics. Required named parameters pretty please :)

In Flutter we like to have the parameters be listed in the same order as the fields and the same order as the arguments.  (We're not very consistent about this for historical reasons, but that's the goal.)
The child argument is often required. This is one reason why we often have @required arguments after optional ones.

In Flutter we like to have the parameters be listed in the same order as the fields

Why does the user care about this?

It makes the code easier to read. In particular, it makes it easier to compare arguments, parameters, and fields so that you can tell if you've included all the ones you want to include. For example, we also try to have the same order in hashCode and operator == implementations. Having the same order makes it much more obvious when you've missed one (just earlier today, I found a bug that would have been easier to find if we hadn't had the same list of identifiers in four different orders in the same file...).
Anyway, long story short, users care because fewer bugs means a better user experience. :-)

So what's the suggestion for code completion to not show Key as the first parameter?

I agree that IDEs would serve the users well by having the @required named arguments first. I would probably have the @required arguments first, alphabetically, followed by the others, alphabetically.

Great feedback!  I'm curious if it would be surprising if the order was different than defined in the source.  (I'm thinking of feedback regarding adaptive menus.)  Either way, I'm curious why this isn't done in the source.  Wouldn't it benefit documentation if required params came first?  Or is there another rationale in how optional named params are ordered?
Relatedly, I see that the source part of the API docs has the required annotations

but not the summary at the top

Are there plans to make the required bits pop out a bit more? cc @jcollins-g

Looking back at @munificent's comment:

It's worded a little funny, but Effective Dart does say the most commonly passed optional positional parameters should appear earlier in the parameter list.

This seems to add a little more fuel to the sort required params first in source proposal?
On the other hand, I see @Hixie wrote:

In Flutter we like to have the parameters be listed in the same order as the fields and the same order as the arguments.

Which I get from an implementation perspective but not so much for documentation (but maybe they're orthogonal).
@InMatrix @lukechurch : any more thoughts from a usability perspective?

dart-lang/dartdoc#1432 seems relevant to this.

Yes, dart-lang/dartdoc#1432 is relevant here. IMO, we should fix that issue first, and then also make sure required parameters are consistently presented in IntelliJ. Right now, they are not.
Let's take IconButton as an example:
As I type "new IconButton", I won't see what's required in the autocomplete box:

If I'm lucky to hit tab to complete the signature, the IDE does cleverly populate the two required parameters for me. But I appreciate this because I already know these two parameters are required. To a new user, it might not be clear why these two parameters are more important than others, given the tooltip below showing all the params without indicating these two are required.

If I didn't hit tab but finished typing "IconButton()", I can manually open the autocomplete box but then the list doesn't show me what's required, nor default/inherited values if they existed.

I also agree with the @Timmmm's comment. It's often hard to determine whether a parameter has a default value. That requires a separate fix. But making required parameters more prominent and hard to miss will help users calm down when they deal with any non-required parameters.
Re: adaptive menus
The issues with adaptive menus are a little different from the potential inconsistency between the order of params in source and the order of those in the IDE. Adaptive menus change the order of menu items dynamically based on the frequency of use at runtime for each individual. In contrast, the re-ordering proposal we're discussing here will be done at design time and will be the same for all the users.
Given most widgets seem to have no more than a couple of required parameters (correct?), I would say the benefit is likely to outweigh the impact of inconsistency with the order in source. That said, @Hixie's rationale against changing parameter order in source seems to be mostly relevant to framework developers and advanced users who need to write new Flutter widgets, no?

As I said earlier:

[In IDEs] I would probably have the @required arguments first, alphabetically, followed by the others, alphabetically.

seems related dart-lang/linter#678

FWIW a hacky stab at fixing this is in flight: https://dart-review.googlesource.com/c/sdk/+/38346.
Here's how it affects creating LayoutIds:

(Note that key gets sorted last. 🕺 )

Landed in https://github.com/dart-lang/sdk/commit/1399a5f511907f63b104f78257af7982b7fe8dfc 👍

Nice work - I'm really impressed how much effort you guys are putting into making Flutter easy to use. Makes a nice change from Android.

Thanks @pq !
BTW, how does this work? How does it know to suggest Key at the end?

@sethladd : it's really simple actually.  We're following @eseidelGoogle's suggestion and simply sorting required params first; a happy result is that key being truly optional lands at the end.

Thanks for the kind words @Timmmm!

@pq can we visually show (somehow, maybe with actually the literal @required) the required-ness of the parameters, in the code-complete pop-up?
it's not obvious which are required, and which are optional.

Asking another way: how will our developers know what is required and what is optional? Is there another UI hint somewhere?
(I believe our challenge is to clearly indicate what is required when code completing. We think that's important because if you finish code completing a constructor, and then you get warnings, you're unhappy and now you have to go back and resolve the warning. Ideally, the journey of completing a constructor happens once, as you are adding at least required parameters.)

We provide a hint when a required parameter is missing.
We sort required parameters first when code completing inside an argument list.
We've talked about trying to do something in the completion list such as bolding the required parameters, but I don't know whether that's possible or whether we've looked into it.

Can you elaborate on what more will need to be done here, if anything, for us to consider this fixed?

@Hixie : I guess all that remains is a decision on whether to add a @required prefix to required params in the popup or whether sorting them first is sufficient.

@pq: As an alternative to displaying @required, can we reduce the contrast of optional parameters?
In addition, I think we can display @required when the autocomplete box is invoked within an expanded constructor:

There is enough real estate in this case.

I'm not sure about changing the style within the completion though I love the idea.  I was imagining bolding required params would be nice.  So, something like:
Thing({Widget child, Color color});
where "child" is required and "color" is not.
I know it's easy to change the style of the entire lookup text but I'm not sure we can have different styles within it.
cc @alexander-doroshko for thoughts

LookupElementBuilder has a bunch of standard decorations: bold, strikeout, underlined, tail text, type text, icon, foreground color. If it's not enough there're a few more options available if you use LookupElementBuilder.withRenderer().

Cool.  Thanks @alexander-doroshko!
Looking ahead,

adding a @required prefix could happen quickly (as it's all in server)
custom rendering would take longer (and is on the IDEA side)

If folks elect to go with (1), I can knock that out pronto.  Otherwise, I think we should open a feature request on the Dart Plugin for (2).  Alternatively we can stick w/ (0) and leave it as is.

@pq would love a mockup of adding @required, thank you!
(I'll take you up on the offer for "could happen quickly" :)

😄
Quick mock:

@sethladd : Happy to run on "real" Flutter classes.  Just tell me what you'd like to see!

Whoa, bonus points for animated gif!!
Works for me. Now it's super clear what I need to do to have a correct-on-the-first-try constructor call.
Later, when we figure out how to control colors/fonts in there, we can play more with the aesthetics.
I'd say SHIP IT!

Groovy.
Landed in: https://github.com/dart-lang/sdk/commit/3dd7eae4c8d0f77aa76b6222d039d473b8bf8261
@DanTup, @alexander-doroshko : this should "just work" out of the box but please let me know if you see any issues.
We can revisit, down the road, if/when we want to refine rendering.

Thanks for the quick turnaround!

@pq Where are those args in the completion coming from? Are they being added to the new displayText field? Currently in Code we don't display arguments in completion labels (we just do (...)), however since we append that on to the end of the label from the server, if this is new text being added into displayText (or even completion) then we might end up appending further parens/args to the end. I tried looking at the CLs above but couldn't figured out exactly what the change is.

@DanTup : the args are in the parameters property of the Element coming back from server. Looking at how it's done in IntelliJ will probably help...  See DartServerCompletionContributor.java#L291:
final String parameters = element.getParameters();

(and beyond).
This particular fix doesn't involve displayText at all.  (Though it probably should!)

Aha, I was confused because I remembered using an array. Looks like we only use that string in the detail (additional info the user can expand, not the completion text nor the display text) and we parse from parameterNames for the completion text:

So, assuming the order of parameterNames hasn't changed, I don't think it'll make any difference to Dart Code (except the ordering in the additional info).

This particular fix doesn't involve displayText at all. (Though it probably should!)

I think now we have displayText it'd be good to review the completion/displayText for existing items - Dart Code has a bunch of custom logic here that I'd love to just ditch and show raw values from the server (we'd have to agree on what's best, but I'm we can manage that). That said, because of all of that custom logic (above) we'd need to coordinate changing it (probably just a bump in the analysis server version would be good enough for me) to avoid displaying weird things to users as the change rolls out.

@DanTup 👍 Absolutely.  Doing work on the server side and populating displayText appropriately is very much the plan.  (FWIW there's similar logic on the IntelliJ side and it would be great to make the cause for it to go away as well with one fell swoop.)

@pq I just reviewed my code, and it turns out there are only two minor tweaks we make to display text, most of the logic is the snippet handling and the "detail" (a bigger info window shown for the selected item).
The display text tweaks we make are:

Append () or (…) depending on whether there are parameters (except for getters, where we append neither)
Remove any trailing comma (flutter formatting triggers)

I think the bottom one probably makes sense in the server, but the top one I'm not sure - if other editors are adding parameters onto the end themselves (we don't, because we didn't want a really long line, hence the (…)) then this would break that.

Interesting.  We'll have to review what we do in IntelliJ as well.  Sounds like this isn't a huge deal either way though.  Thanks for following up!


Handle HTTPS in hostname change dialog

I realized that there are some wrinkles in changing the hostname when HTTPS is involved:

When we change the hostname with HTTPS enabled, we need to generate a new TLS key and cert with the new hostname assigned (see this PR). This process adds ~20s to the change hostname script.
If the user hasn't installed the device's CA certificate, /status requests to the new hostname will fail due to TLS errors because the new domain is untrusted.

For (1), I think there are two possibilities:

Change /api/hostname to use the websockets channel. I believe WebSockets is more suited to long-running requests, though I'm not positive.
Change /api/hostname to an asynchronous API, similar to /api/update

It wouldn't have to be as complicated as /api/update because that API has to account for the whole backend restarting between requests, whereas the hostname change won't restart the backend

For (2), can we distinguish between a failed network connection and a failed TLS connection? If not, we should detect if the current scheme is https and suggest that as a reason for the failure to auto-redirect.

Actually, false alarm. I realized there's a simpler solution.
Instead of regenerating the TLS key immediately, we can create a systemd service that does it on next boot. That should keep the /api/hostname request fast (maybe 1s of delay). (2) is still an issue, but it's much less of a priority in isolation. I'll track that in a separate bug.

👍 this solution coincides with how the hostname change comes into effect anyway (i.e. on next reboot, and not immediately).


Not located file in compress and trim (No such file or directory)

Hello!
I use componente ImagePicker to select image/video/photo and it work, but I received the path of vídeo this component and try to use in "ProcessingManager.trim" or "ProcessingManager.compress" but result in error. I finded strange because I used in "ProcessingManager.getVideoInfo" and it worked.
Error:
Object {
"e": [Error: compress error: failed. ffmpeg version 3.3.5 Copyright (c) 2000-2017 the FFmpeg developers  built with gcc 4.8 (GCC)  configuration: --target-os=linux --cross-prefix=/Users/kesha/Projects/ffmpeg-android/toolchain-android/bin/arm-linux-androideabi- --arch=arm --cpu=cortex-a8 --enable-runtime-cpudetect --sysroot=/Users/kesha/Projects/ffmpeg-android/toolchain-android/sysroot --enable-libx264 --enable-pthreads --disable-debug --disable-ffserver --enable-version3 --enable-hardcoded-tables --disable-ffplay --disable-ffprobe --enable-yasm --disable-doc --disable-shared --enable-static --enable-nonfree --disable-network --enable-gpl --enable-ffmpeg --enable-small --disable-filters --enable-filter=copy --enable-filter=trim --enable-filter=crop --enable-filter=scale --enable-filter=format --pkg-config=/Users/kesha/Projects/ffmpeg-android/ffmpeg-3.3-pkg-config --prefix=/Users/kesha/Projects/ffmpeg-android/build/armeabi-v7a --extra-cflags='-I/Users/kesha/Projects/ffmpeg-android/toolchain-android/include -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-strict-overflow -fstack-protector-all' --extra-ldflags='-L/Users/kesha/Projects/ffmpeg-android/toolchain-android/lib -Wl,-z,relro -Wl,-z,now -pie' --extra-cxxflags= --extra-libs='-lx264 -lm'  libavutil      55. 58.100 / 55. 58.100  libavcodec     57. 89.100 / 57. 89.100  libavformat    57. 71.100 / 57. 71.100  libavdevice    57.  6.100 / 57.  6.100  libavfilter     6. 82.100 /  6. 82.100  libswscale      4.  6.100 /  4.  6.100  libswresample   2.  7.100 /  2.  7.100  libpostproc    54.  5.100 / 54.  5.100file:///data/user/0/com.younner.winkmeup/cache/ExperienceData/%2540faelsolucoes%252FWinkMeUp/ImagePicker/aa32b2bb-e16a-43b8-bd4e-26492110d6c2.mp4: No such file or directory],
}
Example file path: file:///data/user/0/com.younner.winkmeup/cache/ExperienceData/%2540faelsolucoes%252FWinkMeUp/ImagePicker/aa32b2bb-e16a-43b8-bd4e-26492110d6c2.mp4
I created an APP to Android and iOS:
react-native = 0.50.3
react = 16.0.0
react-native-video-processing = 1.13.0
I use this path in my APP without problems. Why didn't component not find the file ?
This component not working IN RN 0.5x ?
Thanks,
Rafael Dorneles

This component not working IN RN 0.5x ?

In Android, react-native 0.51 + react-native-image-picker 0.26.7, same error.
When call ProcessingManager.compress, crash in V/MediaMetadataRetrieverJNI: setDataSource
12-08 10:24:58.350 5650-5650/? V/MediaMetadataRetrieverJNI: setDataSource
12-08 10:24:58.358 5650-5650/? A/libc: Fatal signal 6 (SIGABRT), code -6 in tid 5650 (vw.amarok.forum)

Call ProcessingManager.getVideoInfo is same error.
const OptionImagePickerVideo = {
    title: 'Vídeo',
    mediaType: 'video',
    storageOptions: {
        skipBackup: true,
        path: 'images',
    }
};

//Select video from Google Photos
ImagePicker.launchImageLibrary(OptionImagePickerVideo, (response) => {
            //response.uri return -> content://com.google.android.apps.photos.contentprovider/-1/2/content%3A%2F%2Fmedia%2Fexternal%2Ffile%2F442/ORIGINAL/NONE/1988160128

            ProcessingManager.getVideoInfo(response.uri).then(({duration, size}) =>
                 console.log(duration, size)
             );

           //OR
            ProcessingManager.compress(source, {width:360, height:640}).then((data) => {
                console.log(data);
            }).catch(e => {
                console.log(e);
            });
});

omegatiger in your case I belive to be you path, verify the format that start uri. In my uri is igual the documentation but only works getVideoInfo, verify my uri. Other functions not works. :(

I'm seeing the same thing as @omegatiger, but I'm still on RN 0.48. Any ideas?

If your video should be loaded over internet then you should first download that video then call compress method

I'm not sure how to process this souce
content://com.google.android.apps.photos.contentprovider/-1/2/content%3A%2F%2Fmedia%2Fexternal%2Ffile%2F442/ORIGINAL/NONE/1988160128

Hii @shahen94 ,
My knowledge is limited on the subject, but I used the react-native-fetch-blob class, where they made an implementation to get the absolute url from the file.
https://github.com/wkh237/react-native-fetch-blob/blob/6bde5167b435e23e334377aa3bb62e8cf7c7e188/android/src/main/java/com/RNFetchBlob/Utils/PathResolver.java
I do not know if this is really the problem.

Using the "fetch" (react-native) function, I can send the file "content: //com.google.android.apps.photos.contentprovider/-1/2/content%3A%2F%2Fmedia%2Fexternal%2Ffile % 2F442 / ORIGINAL / NONE /<PHONE_NUMBER>" to the backend.
So I believe the file exists.

Hi @shahen94 ,
I use packeges ImagePicker and DocumentPicker of EXPO to get files local, but next select the file this module sends the video to directory created by module. I beleve that not have permission to access. But is very strange that function getVideoInfo located file return yours informations, already for functions trim end compress sayed not found this file.
Functions are all of the module ProcessingManager (getVideoInfo , trim , compress).
Example file path local: file:///data/user/0/com.younner.winkmeup/cache/ExperienceData/%2540faelsolucoes%252FWinkMeUp/ImagePicker/aa32b2bb-e16a-43b8-bd4e-26492110d6c2.mp4

Hi @shahen94 ,
I resolved my problem using package "DocumentPicker" of EXPO to select my video and next I used package "react-native-get-real-path" to get path real. With the path real I used in your package and all works it.
Thanks

I am using react-native-image-picker too, and it return path which is not readable for ProcessingManager.compress. Any solution @shahen94 @faelsolucoes ?
Here react-native-image-picker response
{
  path: '/storage/emulated/0/DCIM/Camera/VID_20180201_234922.mp4',
  uri: 'content://media/external/video/media/22414'
}

Hello shahen94,Use component react-native-get-real-pathto get real Path.You need to use in Android after receive return ImagePicker.showImagePickerExample: let newUri = await RNGRP.getRealPathFromURI(response.uri);In iOS is not necessary.Good workRafael DornelesEm 1 de fev de 2018 5:17 PM, Pir Shukarullah Shah<EMAIL_ADDRESS>escreveu:I am using react-native-image-picker too, and it return path which is not readable for ProcessingManager.compress. Any solution @shahen94 @faelsolucoes ?
Here react-native-image-picker response
{
path: '/storage/emulated/0/DCIM/Camera/VID_20180201_234922.mp4',
uri: 'content://media/external/video/media/22414'
}
—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.

I am trying to handle a local file and fail (I am getting 'setDataSource failed').
Tried various file paths, including putting the mp4 file in the same folder of the component:
source={./sample.mp4}
and accessing the file located in /sdcard/Download/small.mp4:
source={'file:///sdcard/Download/sample.mp4'}
Any idea?

You should try react-native-image-picker. See post #30

Hi @faelsolucoes , Can you help me?
if I want just to compress and Trim video on Android and iOS? Do I have to install ffmpeg library? or just npm react-native-video-processing ?
Thanks!
Matt.

For those still having problem with files on Android that starts with content://. Try installing react-native-fs and then apply the following function to get path:
import RNFS from 'react-native-fs';
...
const getPath = async (url) => {
    const destPath = `${RNFS.TemporaryDirectoryPath}${Math.floor(
      Math.random() * 999999
    )}`;
    await RNFS.copyFile(url, destPath);
    const res = await RNFS.stat(destPath);
    return res.path;
  };


Bluetooth: controller: Fix Data Length Update implementation

The Data Length Update implementation reused the flags used
by Encryption Procedure which caused invalid Encryption
Procedure sequence under conditions where Data Length Update
Procedure collide with Encryption Setup initiated by the
peer central device.
Signed-off-by: Vinayak Kariappa Chettimada<EMAIL_ADDRESS>

Codecov Report

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

@@           Coverage Diff           @@
##           master   #10229   +/-   ##
=======================================
  Coverage   53.03%   53.03%
=======================================
  Files         214      214
  Lines       26176    26176
  Branches     5642     5642
=======================================
  Hits        13883    13883
  Misses      10024    10024
  Partials     2269     2269

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 7ba6736...ba1a0fa. Read the comment docs.