luci-app-statistics: CPU plugin does not display information by CPU

19.07-SNAPSHOT
Here is my config

And the chart displays combined usage instead of "By CPU"

Could you post your generated collectd and uci config?

From luci_statistics
config statistics 'collectd_cpu'
option enable '1'

Hah, so once I save it I get these and then two more charts (one per CPU show up). They are empty at this time.I also see "cpu-0" and "cpu-1" folders under the red directory.
config statistics 'collectd_cpu'
option enable '1'
option ReportByCpu '1'
option ReportByState '1'
option ValuesPercentage '0'

Ok is this now solved?

Assume this works as expected.
If not, feel free to reopen this issue.

It is gonna be broken on a fresh install again: two configuration parameters are missing in luci_statistics and collectd is not collecting the relevant data. Luci assumes the wrong defaults for the missing values.
It is working for me now, but a greenfield install will be broken until the user saves that page.

I do not see a way to reopen this issues. It is up to you guys.

Fixed in master


Added more Not Fancy challenges

Added more challenges and edited the README.md file

Hey @Nima-Ra, i'm going to close this branch since I merged the other branch with your challenges in it 😄


Which is the correct statement

On this page it states that VS Enterprise and Pro users have Basic +testplans included in their subscriptions.
But the VS pricing page https://visualstudio.microsoft.com/vs/pricing/ seems to suggest that only Enterprise has the testplans addition?

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

ID: 73fdf4b3-7ff5-f9ab-d28c-45e804b314de
Version Independent ID: e916c6aa-2ca5-1517-614c-091fb5b7572b
Content: Buy Basic + Test Plans access - Azure DevOps
Content Source: docs/organizations/billing/buy-basic-plus-test-plans.md
Product: devops
Technology: devops-billing
GitHub Login: @chcomley
Microsoft Alias: chcomley

Hi @realolap, Thanks for reaching out. There isn't a discrepancy - the confusion is perhaps with "Test."
Basic + Test Plans is included with…
Visual Studio Enterprise
Visual Studio Test Professional
MSDN Platforms
But not…
Visual Studio Professional
Thanks again and please let us know if you have any further questions.


Store time zone information with drinks, sessions

Kegbot uses django's timezone support (USE_TZ = True), which means DateTimeField columns are stored as UTC and localized to a timezone when rendering.
For a Kegbot system, the time zone is not static: SiteSettings.timezone can be changed at any time. Consider a system that recently moved from New York to San Francisco: it is impossible to know what the true localtime of a Drink or DrinkingSession was, since we only store the UTC time (and not SiteSettings.timezone) and localize on demand.

Fixed as #199.


Feature/date normalization

Attempts to convert a string value to a Date object:

Parses EDTF values, returns an appropriate EDTF object if a match is found; otherwise...
Parses values in %m*%d*%Y format and returns a Date object if appropriate; otherwise...
Parses values that match any of Date#parse's supported formats.

If the value is not a String or is parsed as invalid by all parsers, the original value is returned unaltered.

:+1:.
Did you look at Timeliness at all for handling the parsing? (I know that's what BPL is using in bpl_enrich, and I don't know if we should be that concerned about speed, etc. up front.)

Most of the stuff in Timeliness is already handled by Date.parse (at least as far as Dates go).
See EDTF aware work, here:
https://github.com/dpla/KriKri/blob/ab06c194c26516f4f601d82a1c055fc86abd587f/lib/krikri/util/extended_date_parser.rb


Python 3 upgrade

The default branch in the molo-iogt repository is the develop branch, which is currently 34 commits ahead of master.
Many of the recent commits on the develop branch have failing tests.
The GitHub repository doesn't have any tags or releases, I assume we don't know for sure which version is currently used in production, but it seems reasonable to assume (at least initially) that the master branch is deployed to production and this is the branch that we should initially focus on upgrading to Python 3?
@nathanbaleeta: Does this sound correct to you?
@volloholic: Do we need to check this assumption?
Also, in order to test the upgrade thoroughly we ideally need a test database - is it possible to get hold of a production backup (we then need to be careful to remove any user accounts - we don't want a dev system to accidentally email anyone etc.)
We could do the Python 3 upgrade from the current latest commit (on the develop branch), but this latest version may not have been fully tested - it has failing tests and it could have regressions.

@isedwards I have followed up with Laurie to get confirmation will feed back as soon as I hear

Just check the Molo repo on the previous vendor's github and it looks like the master branch is quite stale with about 1312 commits behind develop branch as shown below:
https://github.com/praekeltfoundation/molo-iogt/tree/master
I also checked the unicef github repo from which the production docker images seem to be generated from and it shows the branch being checked out is {IOGT_VERSION=a6e3f08}. The link below shows more detail:
https://github.com/unicef/unicef-molo-iogt/blob/develop/Dockerfile

Update of progress on IOGT Python 3 Upgrade
The molo-iogt repository contains plenty of customisation (templates, style sheets, language translations etc.), but there is not a lot of Python code.
In addition, the code is already valid Python 3 and the automated tests already run in both Python 2.7 and Python 3.6.
However, the site is likely to be running on Python 2 in production.
Another key issue is that the codebase is currently pinned to a number of old dependencies that are no longer supported (e.g. Django 1.11.29 and wagtail 1.13.4).
So, in addition to switching over to Python 3, the main task will be to start to upgrade the dependencies once we have a test database to make sure that everything continues to behave as expected.
We need to upgrade the dependencies until we reach Django 2.2 LTS and Wagtail 2.7 LTS. There will be a number of breaking changes that we'll need to investigate.

The current IoGT codebase uses Molo for scaffolding a Django application  with sensible defaults, packages and configuration. From pip list, noticed several key features are bundled using Molo including commenting, polls & surveys etc.
However Molo requires Python (version 2.6 or 2.7) to be installed and this applies as well to the latest version released on August 13, 2020(molo.core 10.2.7).
As part of the upgrade plan, it would be good to investigate further whether we shall continue supporting Molo or have to drop it considering it requires Python (version 2.6 or 2.7) which we are planning a migration from to Python 3.*

The summary at pypi.org/project/molo.core that say "Molo requires Python (version 2.6 or 2.7) to be installed" is incorrect.
It looks like the maintainers have not updated the package description recently.
We've seen ourselves that the molo dependencies run on Python 3.
We've also looked at the molo.core changelog and documented the following in #3:

The version of molo.core that we are currently using is 6.10.3. The releases notes show:

Python 3 is supported from version 6.3.0 onwards.
Support for Python 2 is removed from version 8.0.0 (which also upgrades to Wagtail 2)

The summary at pypi.org/project/molo.core that say "Molo requires Python (version 2.6 or 2.7) to be installed" is incorrect.
It looks like the maintainers have not updated the package description recently.
We've seen ourselves that the molo dependencies run on Python 3.
We've also looked at the molo.core changelog and documented the following in #3:
The version of molo.core that we are currently using is 6.10.3. The releases notes show:

Python 3 is supported from version 6.3.0 onwards.
Support for Python 2 is removed from version 8.0.0 (which also upgrades to Wagtail 2)

Makes sense now, thanks @isedwards


keepalive does not work with device names which including spaces ["Nexus6P" vs. "Nexus 6P"]

So after https://github.com/ianperrin/MMM-NetworkScanner/commit/6d5d1b198875bc298304d7624cbec08f90413f90 keepalive works as intended, but only when I name the device without a space in it, for example Nexus6P vs Nexus 6P
When I name the device Nexus 6P as soon as android does its sleep wifi business where MMM-NetworkScanner no longer finds it for a bit the screen turns off.
If I name it Nexus_6P this behavior is no longer seen. In fact, I see when android drops the wifi connection temporarily, because MMM-NetworkScanner now says NO DEVICES ONLINE, however because of the working keepalive is long enough it stays on until android decides to refresh some feed or pull emails or what have you where it needs an active wifi connection again
Btw - I've found 5min (300s) is an adequate time for Android phones to keep MMM-NetworkScanner to keep the screen on and not have intermittent screen off time due to Androids erratic wifi behavior.
Config:

        {
                module: "MMM-NetworkScanner",
                position: "bottom_left",
                config: {
                    devices: [
                            { macAddress: "A0:28:ED:69:8B:20", name: "Nokia_7P", icon: "mobile"},
                            { macAddress: "04:D6:AA:7C:B4:85", name: "Samsung_S8", icon: "mobile"}
                        ],
                    showUnknown: false,
                    showOffline: false,
                    keepAlive: 300,
                    updateInterval: 10,
                    residents: "Nico_7P",
                    occupiedCMD: {notification: "REMOTE_ACTION", payload: {action: "MONITORON"}},
                    vacantCMD  : {notification: "REMOTE_ACTION", payload: {action: "MONITOROFF"}}
                }
        },

Now I do not have a degree in CS or anything, but my little experience with programming leads me to believe the variable for the device name just simply wasn't wrapped in quotes somewhere. Therefore the space breaks out of the variable too early and therefore breaks the keepalive functionality. Just my guess though. Thought it might at least lead someone onto the correct track..

So just to be clear here- the issue is the monitor is turning off / on when it's not supposed to be?
If so- I suspect a mismatch between your devices & residents. With your current configuration, NetworkScanner will never realize any residents (Nico_7P) are on the network, because you don't have a device configured with the name "Nico_7P".
Personally, I don't use the occupiedCMD & vacantCMD options, but I have several devices configured with spaces in their name, and I haven't had issues otherwise.

Ah sorry that was a typo after I copied and pasted, the devices and residents are the same.


added a JS DOM book from DigitalOcean

What does this PR do?
Add resource(s)
For resources
Description
This book provides basic understanding of DOM. Each chapter can be followed independently of the others (can be useful as a quick reference).
Why is this valuable (or not)?
As a beginner to embrace Javascript, this book helps me better understand DOM as well as reviewing my HTML knowledge. This ebook is based on the DOM tutorial on DigitalOcean Community and is easy to follow. I use it as a guide for quick revision.
How do we know it's really free?
This ebook is licensed under Creative Commons copyright which means it's free for the public to use.
For book lists, is it a book? For course lists, is it a course? etc.
This is an eBook in PDF format.
Checklist:

[x] Read our contributing guidelines
[x] Search for duplicates.
[x] Include author(s) and platform where appropriate.
[x] Put lists in alphabetical order, correct spacing.
[x] Add needed indications (PDF, access notes, under construction)

Follow-up

Check the status of GitHub Actions and resolve any reported warnings!

super addition.
Thanks, and welcome to free-programming-books!

Good day Eric,
Thanks for the opportunity ! :smiley:
Glad my first PR went through woohooo !  :sparkles:
Cheers


fix: test commit title convention

Signed-off-by: Adi Ludmer<EMAIL_ADDRESS>Pull Request
Description
Please provide a brief description of the changes made in this pull request.
Related Issue(s)
If this pull request addresses or relates to any open issues, please mention them here using the syntax Fixes #<issue_number> or Resolves #<issue_number>.
Checklist
Before submitting this pull request, please ensure that you have completed the following tasks:

[ ] Reviewed the Contributing Guidelines for the Piper project.
[ ] Ensured that your changes follow the coding guidelines and style of the project.
[ ] Run the tests locally and made sure they pass.
[ ] Updated the relevant documentation, if applicable.

Testing Instructions
Please provide clear instructions on how to test and verify the changes made in this pull request.
Additional Information
Add any additional information or context that would be helpful in understanding and reviewing this pull request.

@qadiludmer I think that issue here is that lint-commit shows that the problem in PR title while the problem in the commit message


Fix sprite crunch at half-pixels

Rounds the canvas item position before rendering it.
Fixes #84632

Out of curiosity, why is this only done when the filter mode is Linear and not Nearest?

Out of curiosity, why is this only done when the filter mode is Linear and not Nearest?

My bad, I just found out that I mixed up Linear and Nearest. I meant to do this on Nearest only.
Nearest:
Capture vidéo du 2024-01-04 13-54-09.webm
Linear (I don't want to round up, because it will look like nearest if I round up (without the pixelated inbetweens):
Capture vidéo du 2024-01-04 13-54-35.webm

I think this should be tucked behind a check for rendering/2d/snap/snap_2d_transforms_to_pixel.
For performance reasons we should cache the result of course and add a method to enable pixel snapping inside the rendering server.

#84380 is better suited to fix https://github.com/godotengine/godot/issues/84632.


feat(no index): remove index from api list

Changes

Remove the extraneous /index from the api list

Preview

Live: https://remove-index.firebaseapp.com/docs/ts/latest/api/
Live: https://remove-index.firebaseapp.com/docs/js/latest/api/

Before

After

CLOSES:

https://github.com/angular/angular.io/issues/1359

@petebacondarwin @naomiblack

merged. live!


Improve support for non-master main branches

This commit improves Cargo's support for git repositories whose "main
branch" is not called master. Cargo currently pretty liberally assumes
that if nothing else about a git repository is specified then master
is the branch name to use. Instead now Cargo has a fourth option as the
desired reference of a repository named DefaultBranch. Cargo doesn't
know anything about the actual name of the default branch, it just
updates how git references are fetched internally.
This commit is motivated by news that GitHub is likely to switch away
from the default branch being named master in the near future. It
would be a bit of a bummer if from now on everyone had to type
branch = '...', so this tries to improve that!
Closes #3517

r? @ehuss
(rust_highfive has picked a reviewer for you, use r? to override)

Related to #3517 I assume

:umbrella: The latest upstream changes (presumably #8363) made this pull request unmergeable. Please resolve the merge conflicts.

Does crater's support for building git repositories (other than those represented by crates.io) extend to building repositories with git dependencies? If so, we could run this through crater.
I think, given appropriate announcement in advance, we could make this change. (Nit: we might wish to spell it HEAD rather than DefaultBranch.)

Thanks for fixing this! Just ran into this bug after renaming my main branch.

@joshtriplett that's a good point! I do believe a crater run would be possible if we'd like.

@bors: r=ehuss
@ehuss I agree that this seems unlikely to cause many issues in practice, I think we should be ready to revert this if anything comes up though.

:pushpin: Commit 4c02977c219ef79b5eb09cb1fb39c4068de61559 has been approved by ehuss

:hourglass: Testing commit 4c02977c219ef79b5eb09cb1fb39c4068de61559 with merge 16a1b0bcb3150fda94d9e47ac05f38dc0c9bc3ed...

:broken_heart: Test failed - checks-azure

@bors: retry

:hourglass: Testing commit 4c02977c219ef79b5eb09cb1fb39c4068de61559 with merge 160318faac7d03267c86dd40245be0e99b4accd3...

:broken_heart: Test failed - checks-azure

@bors: retry

:hourglass: Testing commit 4c02977c219ef79b5eb09cb1fb39c4068de61559 with merge f2aba14d07ff2f383a71d07576efbf7c1b73157c...

:sunny: Test successful - checks-azure
Approved by: ehuss
Pushing f2aba14d07ff2f383a71d07576efbf7c1b73157c to master...


Will Ubuntu 18.04 LTS Bionic Beaver be supported?

Are there plans to support Ubuntu 18.04 LTS Bionic Beaver? Any ETA?

@fasterforward There is a slight chance that it will be in the next stable release, which is targeted for July. Unfortunately we are time and resource constrained and it is at the bottom of our priority list for the July release. Most likely it will be in the one after that, which is targeted for January 2019.
Regards,
David

July, really? This is ridiculous.

@kaliberx Thanks for the feedback. I'd like to point out that:

Ubuntu 18.04 (production/RTM) has not even released yet (it's scheduled for April 26). A July support date would mean we prioritized this into a two month window for completing any code and test infrastructure changes required for production support (on top of other work being done).
The PHP drivers have a dependency on ODBC drivers which themselves have to support 18.04 first.

That does seem to be an issue with msodbcsql, which underscores the fact that we can't support 18.04 until the underlying ODBC driver supports it. The ODBC driver devs will be made aware of this error, @savvidevs, thanks for pointing it out.

For more information about the libcurl issue in Ubuntu 18.04, see the corresponding discussion on Launchpad.

until this is fixed on the odbc-side, you can install the libcurl4 from here https://launchpad.net/~xapienz/+archive/ubuntu/curl34 which will provide a libcurl3 as well and make it possible to install everything

Please make this a higher priority. There are MANY libraries that require libcurl4 on 18.04 and it is becoming harder and harder to delay use of them. Support for the newest LTS version should be high priority.
@Catscrash can you elaborate on this any more?

Hi @thsmrtone1 and @Catscrash , rest assured that ODBC driver has this libcurl issue fixed and will be ready in July, as @David-Engel has mentioned above. Please stay tuned for their blog announcement.

Please check the latest v5.3.0 release
Should any of you have any other problem or issue with Ubuntu 18.04, which requires the latest ODBC 17.2, please create a new issue.


Stretch sidebar to fit Italian menu item

OS: Windows 10, MacOS
Issue Descriptions: Having an Italian account, there's an item with a rather long text (Upgrade to family plan). As you can see in the screenshot, the icon gets resized, and the text takes all the space possible without leaving any right margin.

It would be great if it could be stretched a bit, 20 pixels or so could be enough.
Steps to Reproduce:
1- Start Play Music Desktop Player
2- Log in with an Italian account
3- Open the sidebar

This is a GPM issue that doesn't really give us many "safe" options to fix.
However you can fix this yourself with the custom styles settings in "Desktop Settings".  A CSS file with this in it
#drawer {
  width: 300px !important;
}

Should do the trick for you 👍

I would have loved a more "permanent" solution, but that's ok. By the way, I preferred to use
#drawer {
  min-width: 310px;
}

Anyway, while importing the CSS, I had another idea, but I'd like to ask an opinion before I start a new issue.
I think it would be easier to allow direct input of CSS instead of reading it from file. I don't know how long are the content of these files usually, but for a simple fix like this it really makes little sense to create a file just for it.

@lorthirk Inputting CSS directly into a text box means we would have to support things like CSS indenting / highlighting and other such things for it to be good UX.
If we only allow files (which aren't too hard to create let's be honest) then it's up to the user to choose an editing experience that helps with that.  Also normally people use custom CSS for a lot more than a 3 line fix 😆

Well, I didn't say that creating a file is hard, but that I think that there are easier way :)
Anyway, I agree with your other reasons.


Feature Request: AbortController shortcut syntax

ref: https://developer.mozilla.org/en-US/docs/Web/API/AbortController

😶

A request-abort is much needed, especially for React/Vue projects.
Please provide a solution.

It does support AbortController. $fetch accepts options whatever  you passed in: https://github.com/unjs/ohmyfetch/blob/main/src/fetch.ts#L127.
For example:
  const controller = new AbortController();
  const signal = controller.signal;
  $fetch(url, { signal });

  controller.abort();

It's not very good, but there's no problem with the wo
usage
const request = useRequest()
const getList = async () => request('../',{method:'POST'})

useRequest
export const  useRequest = () => {
  const controller = new AbortController()
  const signal = controller.signal

  const run = async (url: string, config: FetchOptions) =>
   $fetch(url, {
      ...config,
      signal,
    }).catch((e) => {
      if (e.message !== "Failed to execute 'fetch' on 'Window': The user aborted a request. ()") {
        throw e
      }
      return new Promise(() => {})
    })

  onUnmounted(() => {
    console.log('onUnmounted:request')

    controller.abort()
  })
  return run
}

AbortController already works like @xuxucode has posted. I tried it. I think we can close this!

Indeed. AbortController is supported univerally. I was keeping issue open if we can make a better shortcut syntax for ofetch for canceling requests..

In case it could help as inspiration, vueuse provides an abort() function from its version of useFetch()
https://github.com/vueuse/vueuse/blob/main/packages/core/useFetch/index.ts#L359
https://vueuse.org/core/useFetch/#aborting-a-request
The AbortController instance is created internally.

We expose an auto polyfilled version of AbortController with https://github.com/unjs/ofetch/pull/268

In case it could help as inspiration, vueuse provides an abort() function from its version of useFetch() https://github.com/vueuse/vueuse/blob/main/packages/core/useFetch/index.ts#L359 https://vueuse.org/core/useFetch/#aborting-a-request

I would also prefer to have a simple abort() function


Is there a way to avoid call chain separation when ActiveMQ use pull mode？

Why do you submit this issue?
[x] Question or discussion

Question

What do you want to know?
Is there a way to avoid call chain separation when ActiveMQ use pull mode？

Yes, you could. You need to use @Trace or another way to create a local span, scoping the MQ pull and other OP(s) as child spans.


[OTLP Log] Gateway performance evaluation

Description
In order to go with the targetted architecture as outlined in https://github.com/kyma-project/telemetry-manager/issues/556, it is crucial to understand if bigger cluster setups can be realized even without having an auto scaling of the gateway in place. If that is not the case, an alternative setup might be possible where the agent is encompassing the all gateway logic additional and pushs directly to the target.
Goal
Understand how much a typical gateway setup can handle, assuming the ideal backend. Is the performance that well already, that anyway backends cannot handle this high volume of logs?
Criterias

High log volume tests are executed with a two replica gateway setup doing similar logic as in the metric gateway
Results are documented as well as conclusions on if a non-auto-scaling gateway setup is tolerable for the MVP

Reasons

Attachments

Release Notes

Come up with a sizing definition for a single gateway instance:

needs to be able to handle the maximum load accepted by a "regular" CLS instance

use the same log definition as used by CLS

Push logs using telemetrygen

https://github.com/kyma-project/telemetry-manager/pull/1318


How to improve the speed of obtaining the serial number of the disk

I use the 'disLayout' to get the serial number of filesystem, but it 'console.log' the serial number after 2 seconds. How can I improve the speed.

@zj1838277795 I guess, you are working on a windows platform, right?
WMIC is quite slow but the only possibility to obtain all the informations we want in systeminformation. Currently I do not really see a possibility to speed this up.

This value changes really rarely. In application can be cached by any id or index.

@SymbolCsaba @zj1838277795 : I agree, I would only call diskLayout() once and cache the value. I guess the problem would be still the FIRST call, right? If you use this e.g. to get a hardware ID, you want to get back a value as soon as possible. If this is your use case, consider using the other functions like si.uuid()


Firmware update

it's been working flawlessly for a few months. I'm so happy you made this plugin.
I now notice it says
Installed version v2.03<PHONE_NUMBER>)
Latest version v2.10<PHONE_NUMBER>)

And it comes from your own web server: https://www.denolle.fr/bayrol/update.json
Having had some issues with the Bayrol Salt, I would appreciate to be free to upgrade it without them always sending me to a professional 1 hour away from my home.   Did you find a way to get the latest firmwares continuously?
I particularly appreciate your plugin because it shows me in graphs what I suspected.
My reading jumps suddenly for a few days and gets back slowly to previous value. your Plugins makes it even more obvious with the history available.  now when it happens, I disable the production or after a few days I will be off the charts, and indeed I see the graph proving me right. Next summer I am ready to ask them to address it.

Hi @chriscatuk, thanks for your feedback, I appreciate.
The only way I found to get latest firmwares is to parse https://www.bayrol.fr/support-technique/automatic-salt,https://www.bayrol.fr/support-technique/automatic-cl-ph pages and build the update.json file on top of it, no url provided by Bayrol so far.
Regards,

thank you, I see we can download the latest firmware from that page you shared: https://www.bayrol.fr/support-technique/automatic-salt
I'll close the issue as it was not an issue


Bump transitive dependency for Component Detection step

For quite some time component detection has failed on some insecure transitive dependencies, this fails nuget publication
https://dev.azure.com/dnceng/public/_build/results?buildId=1472129&view=logs&j=0bc77094-9fcd-5c38-f6e4-27d2ae131589&t=2331deb8-a2c0-52bb-dfb1-18607764ad9e&l=8156
In the latest .net build only one remained. This aimed to fix that by forcing an updated version through direct dependency.

This would fix #1196

As it happens, I have a change (#1220) aimed, in part, to address the issue as well. It should be done, changes-wise, but requires testing to ensure I haven't terribly broken anything, and I've just not yet been able to do.

Thanks @philliphoff. Following your change,
System.Text.Encodings.Web now resolves to 5.0.1 which doesn't have the known security issue.
Although still no new nuget published, due to too many changes?
[WARN] Component Governance needs more time to analyze alerts for newly introduced components. The build output may not reflect all alerts. The service will continue processing outside of the build, and any additional alerts will appear in the Compliance tab for tracked pipelines. See https://docs.opensource.microsoft.com/tools/cg/buildtask.html for more information.
I'll switch my team to this version and report any issue.

I'm closing this PR as it now redundant.


chore: release 2.1.2

:robot: I have created a release *beep* *boop*
2.1.2 (2019-06-13)
Bug Fixes

docs: move to new client docs URL (#257) (fccfb8d)

This PR was generated with Release Please.

Release is at https://github.com/googleapis/nodejs-video-intelligence/releases/tag/v2.1.2

The release build has started, the log can be viewed here. :sunflower:

:egg: You hatched a release! The release build finished successfully! :purple_heart:


Add SignalR to article comparing gRPC with HTTP APIs

I believe a comparison with SignalR should also be done.

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

ID: 8321e4f0-1d12-c4cd-76af-a7df9ca2e732
Version Independent ID: c9e71059-2e31-3de3-eb26-0946cfe0ec3d
Content: Comparing gRPC services with HTTP APIs
Content Source: aspnetcore/grpc/comparison.md
Product: aspnet-core
GitHub Login: @JamesNK
Microsoft Alias: jamesnk

Totally my first thought when reading this.  How does this (gRPC) differ/compare to SignalR?

I think the Alternative Framework Scenarios explains it pretty well. gRPC can't be used in browser senarios, as well as not being made for broadcasting messages.

Can I also bug about adding a comparison to WCF?

cc @Rick-Anderson - i think there's merit to an overall-encompassing messaging article in the ASP.NET docset, that would cover (and potentially provide guidance-per-scenario) for SignalR, gRPC, and so on. This feels like a broader-scoped goal than just for SignalR. Is this something your team would own or would that be something the PG would need to author and submit for review?

From #19940 by @PingPongSet

Is it possible to provide comparison between SignalR and gRPC?
For example, why is SignalR not used in MicroServices in backend services?
What is the difference in client server communication in areas of browsers and mobile apps?
Document details


feat(rest_plugin): adding volume rebuild history

cherry-pick :
https://github.com/openebs/mayastor-control-plane/pull/596

bors merge


StepDescriptor API to signal that we should allow the Execution to attach actions before persisting flownodes

Detail TBD when other PRs are up to link to this one
For downstreams, deployed as:
<dependency>
            <groupId>org.jenkins-ci.plugins.workflow</groupId>
            <artifactId>workflow-step-api</artifactId>
            <version>2.13-deferactionwrite2-20170901.210414-1</version>
        </dependency>

TODO:

[ ] Show use by steps that attach a ton of actions

Closing, feel free to reopen it if you start working on it again.


Real time debug logs

Please describe what you would like to see in this project
Display real-time logs outputted from a plugin when the --debug flag in set.
Please describe your use case
It is needed for plugins which have a long run time such as kube-burner and web-burner plugins.

@janosdebugs i believe it's required both during standalone execution and workflow execution, should I create an issue on the engine repo as well.
an unrelated question: what happens if multiple plugins output real-time logs during a workflow run?


⚠ Bofrost.at has degraded performance

In 5fa2d12, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 2639 ms

Resolved: Bofrost.at performance has improved in 5ec0147.


Atom is freezing on invalid syntax

Since the last update from 5.0.0 to 6.0.0, Atom is completely freezing when a syntax problem occur. You can reproduce the bug by creating a less file containing this code:
&::before,
&::after {
  content: '';
  position: absolute;
  left: 0;
}

When you comment the line &::after {, the syntax is now broken and Atom is freezing...
This is a critical bug.
Thanks for your feedback :wink:

Hi!
Thanks for the report!
I think I've tracked in down to an upstream dependency of lesshint (postcss-selector-parser) which hangs on invalid selectors. I'll see if the new version of that fixes the issue.

<EMAIL_ADDRESS>should fix this issue. If not, please let me know!

Thanks for the fix, I will try tomorrow and give a feedback soon. 👍

Hi @jwilsson!
It seem's that the issue is now fixed, big thanks!
:wink: :beers:

Hi @jwilsson,
Since this fix, the linter is throwing errors, sometimes... here is the detailed error from the Atom developer console:
C:\Users\xavier\.atom\packages\linter\lib\linter-registry.js:159
[Linter] Error running lesshint Error: Column start (6) greater than line length (5) for line 21
    at generateRange (C:\Users\xavier\.atom\packages\linter-lesshint\node_modules
    \atom-linter\lib\index.js:181:11)
    at file:///C:/Users/xavier/.atom/packages/linter-lesshint/index.js:96:35
    at Array.map (<anonymous>)
    at Object.<anonymous> (file:///C:/Users/xavier/.atom/packages/linter-lesshint/index.js:90:31)
    at Generator.next (<anonymous>)
    at step (C:\Users\xavier\.atom\packages\linter-lesshint\index.js:9:273)
    at <anonymous>

:confused:

@xavierfoucrier Hmm, do you have some Less code that's always triggering that error?

@xavierfoucrier I managed to track it down to an issue in lesshint<EMAIL_ADDRESS>should resolve this issue. Please let me know if it doesn't!

Fixed! Thanks for the patch :coffee:


The project without tests

We need more tests as we have no tests :D :D :dancer:

you mean "testing"?
we need more people to use this good project first, then add a label "waiting to be tested" on PRs

:) We have only one person who is trying to **** us with opening issues and still, there is no PR
I think the project should be covered by tests and must be improved with best practices in order to get more attention.

The basic idea is now for me:

Try official MySQL Docker container
Install autoxtrabackup in this container
Then write unit tests to run inside this container :dancer:

ok automated tests?
i only know about travis, to verify if everything works at a basic level

@ShahriyarR Do you have a test framework in mind? I'm not familiar with them either but wouldn't mind learning/contributing.

I am going to use pytest and docker container for running tests.
I have already started to prepare docker env and wrote some wrapper code on this here:
https://github.com/ShahriyarR/MySQL-AutoXtraBackup/tree/bugfix_issue388
The thing is we are missing unit tests and of course functional tests overall.
So what you can do is - pick backup or prepare code and start to write unit tests for methods.

Nearly all the most important changes are done. The procedure to add more tests much more simple now.
As it can take a month to cover all the tests I am going to merge current changes to release_v2.0 branch and try to continue to other important missing things.

Merged. Now closing.
Will open separate issues for each missing test type:
Prepare, Restore, Backup etc.


Returning user sees last saved page on dashboard

User Story
As a returning user, after I login, I want to know what page I was last on on so that I can orient myself.
Acceptance Criteria
Given that a returning user logs back in with a BCeID that has been used before, when they click login, then they will be directed to the landing page which will have a section that says the last page they pressed "Continue" on.

Per Rachel- Not implement as part of RTP


Pathfinding Bug

I tried using nav-agent on CDN and it behaves weird. but when i import the nav agent directly from the file in this repo it behaves normally.

maybe it is because the pull request #336  is not yet in the CDN.

Yes, i think you're right. I tried it again with aframe version below 1.0 and it works flawlessly


Add a command-utility for interacting with clusters

This includes:

Monitoring cluster status (#11)
Retrieving information about nodes (#18)
Retrieving information about jobs
Setting flagpoles (#19)

See also #23 for URI patterns


Python version

Currently we only support python 3.6, since we use f'{string}' syntax. On many platforms python3.6 isn't readily available (e.g. raspberry pi, on which I haven't even been able to compile it so far) - don't we want to support 3.4 too?

Would you ever want to run this on such a system?
Dynamic typing may also require newer system.

Do not underestimate the number of people toying around with these systems. Also, for example Ubuntu 16.04 does not provide a means to easily install 3.6.

Are we willing to lose dynamic typing in order to support python2.x?

No! Python 2 is history in my opinion. All these older systems do provide 3.4 or 3.5.

I'll make a branch and see how much I have to change to be able to run in 3.4. Then we can decide.

I am curious to hear about systems where it is easy to install python 3.4 but not 3.6. I am fine with more support if we only loose the f"{}" notation.

Ubuntu 16.04 doesn't have a python3.6 package available


./uload not working

Every time i try to unload hack it doesn't get uload and when i quit csgo from console it take 1-2 min for csgo to close can you please look at it.

Will take a closer look tommorow.

https://pastebin.com/NAf061Ya

Yes it's not working.

Try now. If ./update will not work, try redownloading with --recursive.

Fixed, closing.

yep its working fine thanks :+1:


feat(app): add support for new source languages

:tada: This PR is included in version 2.37.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


fix kvm infops

Codecov Report

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

@@           Coverage Diff           @@
##           master     #257   +/-   ##
=======================================
  Coverage   16.29%   16.29%
=======================================
  Files          15       15
  Lines        1062     1062
=======================================
  Hits          173      173
  Misses        878      878
  Partials       11       11

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 26d994a...c540548. Read the comment docs.


Operator needs service account csi-rbd-nodeplugin-sa but rolebindings includes as ceph-csi-operator-csi-rbd-nodeplugin-sa

Describe the bug
currently, the operator code needs service account csi-rbd-nodeplugin-sa sa but rolebindings include as ceph-csi-operator-csi-rbd-nodeplugin-sa,
So either we need,

Change the service account to add prefix ceph-csi-operator

Remove prefix ceph-csi-operator from the roles and rolebindings and clusterrolebindings.

A clear and concise description of what the bug is.
Need a discussion on what change we should pick, and collect different views.
Environment details

Image/version of ceph-csi-operator :
Image/version of Ceph-CSI driver :
Kubernetes cluster version :
Ceph cluster version :

Steps to reproduce
Steps to reproduce the behavior:

Setup details: '...'
Deployment to trigger the issue '....'
See error

Actual results
Describe what happened
Expected behavior
A clear and concise description of what you expected to happen.
Logs
Additional context
Add any other context about the problem here.
For example:
Any existing bug report which describe about the similar issue/behavior

The service account names as defined currently, for example csi-cephfs-ctrlplugin-sa, are nice and simple. Can we keep the simple names as the default? Why would we need a ceph-csi-operator prefix on the name? This would make a name of ceph-csi-operator-csi-cephfs-ctrlplugin-sa which seems unnecessarily long and redundant as the default.
If someone wants to include a second driver in the namespace, they could set their own service account name and configure the serviceAccountName to use an alternate. Isn't that the purpose of that field already to allow setting a non-default option? So we can keep the default option without the prefix. Let's optimize for the common case of one driver in the namespace.

@travisn This is because of the way how we are installing, if we install using the kustomize this is expected.

@parth-gr note we do have the option to specify the service account names for both the controller plugin and node-plugin in the Driver CR and the OperatorConfig CR which you can use.

Reopening as now its not fixed but a way was provided to generate the CSI RBAC with expected names but we still need to fix the prefix part for the operator

Closing this one as its fixed now.


module vault-elb is not idempotent

I'm creating ELB for vault with this:
module "vault_elb" {
  source                      = "git::git@github.com:hashicorp/terraform-aws-vault.git//modules/vault-elb"
  internal                    = true
  name                        = "${var.country}-${var.stage}-vault-elb"
  vpc_id                      = "${module.network-getter.vpc_id}"
  subnet_ids                  = "${module.network-getter.private_subnet_ids}"
  allowed_inbound_cidr_blocks = ["${data.aws_vpc.main.cidr_block}"]
}

everything applies with no problem. Thank you guys!
But after invoking terraform plan once again I see the following:
Terraform will perform the following actions:
  ~ module.vault_elb.aws_elb.vault
      availability_zones.#:          "3" => "0"
      availability_zones.1305112097: "us-east-1b" => ""
      availability_zones.3569565595: "us-east-1a" => ""
      availability_zones.986537655:  "us-east-1c" => ""

Plan: 0 to add, 1 to change, 0 to destroy.

$ terraform version
Terraform v0.10.7

99% of the time, these sorts of issues are bugs in Terraform itself. The vault-elb module is setting availability_zones to an empty list by default; my guess is that after creating the ELB, AWS fills in the AZ data automatically, so next time you run plan, Terraform figures that the empty AZ list means "remove all AZs".
Perhaps file a bug in the AWS provider?

data "aws_subnet" "private" {
  id = "${var.private_subnets}"

  count = "${length(var.private_subnets)}"
}

module "vault_elb" {
....blah-blah-blah....
  availability_zones          = "${data.aws_subnet.private.*.availability_zone}"
}

@kostyrev this may be a workaround for your problem :-)
@brikis98 maybe this should be used as a default value for availability_zones argument. This datasource is available since version 0.9.5 which is minimal in your case. Proof: https://github.com/hashicorp/terraform/blob/v0.9.5/website/source/docs/providers/aws/d/subnet.html.markdown
Guys, what do you think?

@kchugalinskiy Nice workaround. I'd welcome a PR for that!

@brikis98 and here we go: https://github.com/hashicorp/terraform-aws-vault/pull/20

Thx @kchugalinskiy! Fixed by #20. Available in https://github.com/hashicorp/terraform-aws-vault/releases/tag/v0.0.7.

Unfortunately, I had to revert the fix in #20 due to the issue explained in #21. That means that for now, the elb module will always show a diff when you run plan. It's harmless and can be safely ignored. I've filed a bug with the Terraform AWS provider about this: https://github.com/terraform-providers/terraform-provider-aws/issues/2156.

I understand the issue, but can we solve this faster by not worrying about what Hashicorp might do with issue?
aws_elb states clearly in the docs:

Exactly one of availability_zones or subnets must be specified: this determines if the ELB exists in a VPC or in EC2-classic.

Yes, Hashicorp could enhance aws_elb resource to accept a null value for one or the other but not both arguments.
But, is anyone seriously using Vault in EC2-classic VPC setup? It's been deprecated for all new AWS accounts since 2013-12-04. I would say the answer is close enough to no that removing the availability_zones would be safe and expedient to resolving this issue. Things are so bad right now you can't eve get this module to work as it just bars up a big fat red error.

Things are so bad right now you can't eve get this module to work as it just barfs up a red error.

Wait, what error were you seeing? I'm aware of a diff showing up every time, but you could safely ignore it. Are you seeing something else now?

The problem is that the first terraform apply works, but subsequent applys show the availability_zones.#:          "3" => "0" diff and it fails because of a restriction in ELBs where you can't remove all AZ at the same time (i.e. you can't be with 0 AZs). This is a restriction on the actual Amazon resource, not on the AWS Terraform provider.
I think I agree with @holybit, can we consider removing support for EC2-classic?

it fails because of a restriction in ELBs where you can't remove all AZ at the same time

Hmm, I wonder if something changed? I don't think this would cause an error before. Simply running apply despite the log output used to work just fine, making no actual changes.
At any rate, if this is the case, I'd welcome a PR to remove the availability_zones param.

I'm submitting two alternative PRs for this shortly. I'll let the maintainers decide which approach they prefer :)

This should now be fixed by #44. Thx @patoarvizu!


Split error messages in http-cache rule

Analyzing http-cache performance issues it seems that http-cache rule do not work properly in that case.

Checking out the response headers cache-control, it is really setting the correct values. See below:

Currently the http-cache will show the same message if you don't have a long max-age and/or you are missing the immutable directive.
To avoid confussion I think we should split this in 2 messages:

Static resources should have a long cache value (31536000)
Static resources should use the immutable directive

@sonarwhal/core, @kshyju, @qzhou1607 what do you think?

TIL, chrome does not support immutable!  😆


"Naming collision detected" on start

Found a "Naming collision detected" on launch, where a fbjs file is collides with another fbjs files ...
Error building DependencyGraph:
 Error: Naming collision detected: app/node_modules/fbjs/flow/include/CSSCore.js
 collides with app/node_modules/fbjs/lib/CSSCore.js

react-native -v
react-native-cli: 0.1.8
react-native: 0.18.0-rc

I am running into the same problem

I solved this issue by erasing fbjs from react native's node_modules folder.

I ran into this same issue when updating from react-redux 3 to 4. I tried @fsp's solution but it didn't fix it. I ended up blowing up the whole node_modules folder and reinstalling, and then doing what @fsb said, which fixed the issue for me.
I'm using 0.18-rc (but I've switched between 0.18-rc, 0.17 and master a number of times recently, so it's possible my node_modules folder was in a weird/inconsistent state).

Happens on  rm -rf node_modules && npm install with 0.18.0-rc

Having the exact same issue with the fbjs package. Removing it manually did not fix it for me, because a conflict still exists but then in the node_modules/fbemitter directory.

I am also having this issue and none of the above solutions worked at all, even with npm cache clear.

Try upgrading to npm@3. Does it work then (after deleting node_modules and npm installing again?

I'm also running into a similar naming collision error when trying to upgrade to 0.18.1. Mine shows as follows:
[10:33:06 AM] <END>   Crawling File System (1352ms)
[10:33:06 AM] <START> Building in-memory fs for JavaScript
[10:33:06 AM] <END>   Building in-memory fs for JavaScript (335ms)
[10:33:06 AM] <START> Building in-memory fs for Assets
[10:33:06 AM] <END>   Building in-memory fs for Assets (310ms)
[10:33:06 AM] <START> Building Haste Map
[10:33:07 AM] <START> Building (deprecated) Asset Map
[10:33:07 AM] <END>   Building (deprecated) Asset Map (159ms)
Error building DependencyGraph:
 Error: Naming collision detected: /Users/jason.merino/Code/MyApp/node_modules/fbjs/flow/include/warning.js collides with /Users/jason.merino/Code/MyApp/node_modules/fbemitter/node_modules/fbjs/lib/warning.js
    at HasteMap._updateHasteMap (HasteMap.js:132:13)
    at HasteMap.js:103:28
    at tryCallOne (/Users/jason.merino/Code/MyApp/node_modules/promise/lib/core.js:37:12)
    at /Users/jason.merino/Code/MyApp/node_modules/promise/lib/core.js:123:15
    at flush (/Users/jason.merino/Code/MyApp/node_modules/asap/raw.js:50:29)
    at nextTickCallbackWith0Args (node.js:452:9)
    at process._tickCallback (node.js:381:13)

I have done the following and it still shows up:
rm -rf node_modules
npm cache clean
npm i
Here's my current setup
npm 3.3.12
react native 0.18.1

Ok yeah @jasonmerino probably the version of fbjs that "fbemitter" wants doesn't match the version that react-native requires, so even npm3 installs it twice. This is a problem we need to get solved.

Thanks @corbt! Yeah, I was thinking that was odd that npm3 still had some nested dependencies, but a version mismatch makes sense.

Same problem here on:
npm 3.3.12
react native 0.18.1
Error: Naming collision detected: /Users/master/Pomodoro/node_modules/reactfire/node_modules/react/lib/BeforeInputEventPlugin.js collides with /Users/master/Pomodoro/node_modules/react/lib/BeforeInputEventPlugin.js

After deleting the BeforeInputEventPlugin from "node_modules/reactfire/" dir I get
Error: Naming collision detected: /Users/master/Pomodoro/node_modules/reactfire/node_modules/react/lib/CSSCore.js collides with /Users/master/Pomodoro/node_modules/fbjs/lib/CSSCore.js

@fsp thanks! I was able to fix this by removing the fbjs directory. I hope there is a proper solution soon.

is this also an issue with v0.19.0-rc ?

Still having the same issue either using npm2 or npm3

I'm getting a new error in my project after installing babel-preset-react-native and adding it to my .babelrc file. The odd thing is that it's complaining about a package.json file which, obviously, doesn't use the @providesModule comment.
Error building DependencyGraph:
 Error: Naming collision detected: /Users/jason.merino/Code/MyApp/node_modules/babel-preset-react-native/node_modules/react-transform-hmr/package.json collides with /Users/jason.merino/Code/MyApp/node_modules/react-native/node_modules/react-transform-hmr/package.json
    at HasteMap._updateHasteMap (HasteMap.js:132:13)
    at HasteMap.js:112:32
    at tryCallOne (/Users/jason.merino/Code/MyApp/node_modules/react-native/node_modules/promise/lib/core.js:37:12)
    at /Users/jason.merino/Code/MyApp/node_modules/react-native/node_modules/promise/lib/core.js:123:15
    at flush (/Users/jason.merino/Code/MyApp/node_modules/react-native/node_modules/promise/node_modules/asap/raw.js:50:29)
    at doNTCallback0 (node.js:417:9)
    at process._tickCallback (node.js:346:13)

Getting the same error over here as well. Looks like fbemitter and react-native are both including the same warning.js and this causes it to barf up.
Error: Naming collision detected:
node_modules/fbemitter/node_modules/fbjs/lib/warning.js
collides with
node_modules/react-native/node_modules/fbjs/lib/warning.js

This seems.... avoidable.
I'm new to React and React Native (and npm actually), any ideas?
Thanks.

@joshuapinter The consensus seems to be adding a postinstall script to your package.json file that removes all fbjs folders in node_modules that is not at the top level. Check this gist out for help on that.
This also assumes that you have installed fbjs as a dependency in your project.

i'm using react-native v0.19.0 & npm3 and I still get the same error.
the only thing that worked for me was using the hack mentioned by @jasonmerino.

By the way, what's with 0.19.0? Last I checked it was an official release and all of a sudden it's back to 0.18.0?

@jasonmerino Thanks for the advice. I created the postinstall script and did a fresh npm install. Now I'm getting this:
Error: Naming collision detected:
node_modules/fbjs/flow/include/toArray.js
collides with
node_modules/fbjs/lib/toArray.js

Any ideas?
Many Thanks!

Does anyone know if downgrading to react-redux 3.1.2 and using react native 18 still works?

@ericmasiello, yes it works, I had to do that.

Having the same issue over in https://github.com/dancormier/react-native-swipeout/issues/65

@joshuapinter What worked for me (react native 0.19, npm 3.6.0) was to pin fbjs to 0.6.1 and ensuring that only the top level fbjs was present (following https://github.com/facebook/react-native/issues/5467)
npm uninstall fbjs
npm install<EMAIL_ADDRESS>find . -name 'fbjs' -print (delete all fbjs directories except the one at the top level)

Hope this helps. I really love React Native, but upgrades are certainly not good for the hairline :-)

Voila!
Thanks @arunabha!
I see this with Rails and Bundler from time to time but I didn't expect it with only a few modules in the package.

Check here to solve this issue. :clap::+1::smiley:

@iTonyYo It doesn't work for me.
my npm version is 3.3.12; my react-native is 0.20.0.
I try rm -rf node_modules/ & rm -rf $TMPDIR/react-* & find . -name 'fbjs' -print | grep "\./node_modules/fbjs" -v | xargs rm -rf & even change all the fbjs dependencies to 0.7.2,
but it's still not work...

Run your packager with a --resetCache flag.
$ ./node_modules/react-native/packager/packager.sh start --resetCache

It isn't just fbjs that is throwing the error, its also react
Running npm dedupe got it past the "Naming collision detected"

@license2e can you please write a step by step solution? (& specify versions, etc...)

Thanks to everyone for the suggested fixes provided in this thread.
As of the upcoming 0.22 release, fbjs and react are consumed from npm, not vendored, so most of these issues should go away. Please give 0.22.0-rc4 a try!
To keep issues focused on current bugs, we're closing this issue.
Feel free to continue the discussion here for earlier versions, or reopen should this issue come back using 0.22.0. Thanks!

getting same error.
Error building DependencyGraph:
Error: Naming collision detected: E:\react-native demo\demo-app-master\node_modules\react-native\node_modules\fbjs\lib\CSSCore.js collides with E:\react-native demo\demo-app-master\node_modules\react\node_modules\fbjs\lib\CSSCore.js
at HasteMap._updateHasteMap (E:/react-native demo/demo-app-master/node_modules/react-native/packager/react-packager/src/DependencyResolver/DependencyGraph/HasteMap.js:132:13)
at E:/react-native demo/demo-app-master/node_modules/react-native/packager/react-packager/src/DependencyResolver/DependencyGraph/HasteMap.js:103:28
at tryCallOne (E:\react-native demo\demo-app-master\node_modules\promise\lib\core.js:37:12)
at E:\react-native demo\demo-app-master\node_modules\promise\lib\core.js:123:15
at flush (E:\react-native demo\demo-app-master\node_modules\asap\raw.js:50:29)
at _combinedTickCallback (internal/process/next_tick.js:131:7)
at process._tickCallback (internal/process/next_tick.js:180:9)


RAW: wrong default value for use_camera_matrix?

in rawinput.cpp, oiio sets use_camera_matrix to 0 by default, but the libraw default should be 1 (which means "use the camera matrix for DNG only").
ref: http://www.libraw.org/docs/API-datastruct-eng.html#libraw_output_params_t

another bug:
            m_spec.erase_attribute("raw:Exposure", TypeDesc::STRING);

should be TypeDesc::FLOAT

Right. Fix coming up.

Proposed fix: #1629


Too many arguments passed in line 30 of index.js

Hello,
I found an issue in your index.js file.
If you look at getElement function you can see this line is passing in 6 arguments, but the function only requires 5.
let newPos = calcPosition(e,chartInstance,datasetIndex,index,x,y)

Hey @gspeach,
thanks for the code review! I just merged the required change in https://github.com/chrispahm/chartjs-plugin-dragdata/pull/28. Beware that I also had to rename the package name (chartjs-plugin-dragdata instead of dragData) to adhere to the official chartjs-plugin-id conventions. The API didn't change, though (still dragData: true). Just make sure to keep that in mind when upgrading to v1.0 and importing this plugin.
Thanks again,
Christoph

Thanks!


pixijs reverse mask

how to use pixijs reverse mask

What do you mean by reverse mask?

What do you mean by reverse mask?

yes

What do you mean by reverse mask?

yes

yes

What do you mean by reverse mask?

yes

This doesn't make any sense.

This doesn't make any sense.


Sender::send_all can't be used with other streams

It is impossible to call send_all on a Sender obtained by channel(_), because the method requires that the SinkError of Sender implements From<T> for the Stream's error type. Yet Sender's error, SendError, has no public constructors, nor any other way to produce a value.
This may be related to #401.

You could use Sink::forward instead. Which is basically the same, but with a reverse conversion. And you can use it on a stream that has a Void (or void-like) error type, by providing diverging closure in map_err.

Stream::forward has the same problems as Sink::send_all. Namely, the error types must be compatible (they aren't, and it's impossible to produce an error type compatible with SinkError).
And I can't have panics anywhere in my code or executable.

Something along the lines of this, should work, as long as you can construct stream error:
some_stream.forward(sender.sink_map_err(|_| ErrorFromStream::construct(_)))

And if you can't construct both, you can do map_err for both:
some_stream.map_err(|_| CommonErro::StreamIssue).forward(sender.sink_map_err(|_| CommonErr::SinkIssue))

I tried:
handle.spawn(sink.clone().send_all(
	stream.then(|res| {
		Ok(res)
	}).map_err(|_| unreachable!())
).then(|_| Ok(())));

but it claims type annotations are needed for the map_error. There is no type that could possible.
And I cannot do something like ErrorFromStream::construct(_) because there is no way to construct futures::sync::mpsc::SendError. It has no public constructors.

You can just insert the a type annotation:
handle.spawn(sink.clone().send_all(
	stream.then(|res| {
		Ok(res)
	}).map_err(|_| -> YourErrorType { unreachable!() })
).then(|_| Ok(())));

And reiterating
enum CommonErr {
  StreamIssue,
  SinkIssue,
}

some_stream.map_err(|_| CommonErr::StreamIssue)
  .forward(sender.sink_map_err(|_| CommonErr::SinkIssue))

Should work for any stream or sink. I would recommend to put some log invocations into the closures, though.
Alternatively, you can do make less obvious thing:
handle.spawn(some_stream.map_err(|_| ())
  .forward(sender.sink_map_err(|_| ())));

That is: mapping both error types to a nil () which handle.spawn actually expects.

Thanks for the report! It sounds like this doesn't really have much to do with traits and is moreso about the errors and how they're constructed? It's pretty standard to not provide constructors for errors (to make it more conservative) and instead unifying error types with crates like failure. Does that work in your case?

Closing due to inactivity. @alexcrichton provided a potential solution. If this does not work, please let me know and I can reopen the issue. Thanks!


New instrument request

Instrument Manufacturer
Gill
Instrument Model
WindSonic Option 2
Instrument Serial Number
unknown
Instrument Scientist Name
Joshua Hampton
Instrument Scientist ORCID
https://orcid.org/0000-0001-7430-8655
Instrument Owner (and ROR ID)
National Centre for Atmospheric Science (https://ror.org/01wwwe276)
If "Other" selected above, please type the owner and ROR ID (if known) below.
No response
NCAS Observatory
CVAO
Instrument description
This is a 2D wind sonic anemometer mounted at the top of a 10 metre tower, outputting U and V wind speeds.

ID: ncas-sonic-6
Descriptor: NCAS Sonic Anemometer unit 6
Data product: mean-winds
Category: Winds
Host: Leeds
Previous IDs: none

looks good.