Inv 0.19.2.final

Another attempt at getting this past Travis..

@metlos, @jmazzitelli,  travis gave up after 2 hours and 243 retries, so it doesn't seem like waiting longer is the answer to whatever problem there is...  I can restart the job but not sure if that is useful...

On 23 Sep 2016, at 14:16, Jay Shaughnessy wrote:

@metlos, @jmazzitelli,  travis gave up after 2 hours and 243 retries,
so it doesn't seem like waiting longer is the answer to whatever
problem there is...  I can restart the job but not sure if that is
useful...

Not at all.
I talked to Lukas earlier

apparently the agent (or its counterpart) is trying to inform the bus
that it is shutting down, which fails as the topic is gone
It may be that the TCP linger option is on, which will keep port 8080
in close wait, while something else is trying to start up on the same
port

Perhaps we can better order subsystem startup/shutdown so that things
are torn down in the order we want.
It may or may not help to wait a few seconds between test runs that
start/stop WildFly. We could also try to use different port-offsets so
that a new server does not step on a still open 8080

What is the status of this one @metlos ?

I stopped looking into this actually...

So it can be closed?

It depends on @jmazzitelli if he wants to use Travis for his CI... ;)

we got it to go green on inventory 1.0.0.Final in another PR. closing this


Metal SkSurface has sample count = 1

Code: https://github.com/flutter/engine/blob/e0d515369fac81e34c2d48f39c6ca766096add54/shell/gpu/gpu_surface_metal.mm#L70
The documentation says that that value should be 0 to disable MSAA.
I tried switching the value to 0 but it crashes with an assert:
../../third_party/skia/src/gpu/GrTextureRenderTargetProxy.cpp:183: fatal error: "assert(surface->asRenderTarget()->numSamples() == this->numSamples())"

Out of date with Impeller


Glyphs are always shown as coe points

Everything seems to be reported as code points now:

I can't reproduce this, what script were you using here?

It works now, may be it was a cache issue.


How to do Forms Validation on Blazor?

Is it possible in Blazor's current implementations to do form validations as in ASP.NET Core?

Blazor does not contain specific functions for form validation. However, with its existing data binding features, you should be able to implement any validation logic. Are you missing specific features?

We do plan to add some additional features around forms and validation. These are tracked by #17

I've written a blog on forms validation: https://blogs.u2u.be/peter/post/blazor-forms-validation Maybe this gets you started.


Wiki -> Stories -> Autocompletion no longer links to an existing page

Bug Report or Feature Request (mark with an x)
- [ X] bug report -> please search issues before submitting
- [ ] feature request

Command (mark with an x)
None
Versions
Current
Repro steps
Go to Wiki in the github repo. Click "Stories" in right side menu. Click "Autocompletion" in left side list.
The log given by the failure
"Could not find version "autocompletion" " is displayed in a blue bar at the top of the page.
Desired functionality
"Autocompletion" links to wiki page about autocompletion

@filipesilva I would like to work on this issue.

@kartik-budhiraja go ahead!

Still the case.

ng complete no longer exists see https://github.com/angular/angular-cli/issues/11043


Change LED-color

Hi,
with 1.0.2 my LED color in standby is green and when i move a rfid-tag to the reader, it flashes blue.
With 1.3.1 my led color in standby is blue and changes to green when i move a rfid-tag near my reader.
Is there a way to set the color for standby and reading by myself?

I'm closing this for now, please feel free to reopen if you want additional help.

Why do you close this? Is there an answer somewhere or have you changed something in the code?

What you can do is checking for the output GPIO for your led and find if there any changes were made, then you may edit source code according to your needs. I think there are tools available for git to inspect the difference between versions.

Let me know if this case should be remained opened. Kind regards.

Maybe you can add this to the next version, so that users can change the led color inside the configuration webif?
Sadly i´m no programmer and i don´t know how to change something in github and build my own source code...


Replace duplicated code with reusable components

This will be a part of our ethos while developing the new Vue.js client for Observatory. I'm marking this as closed in an effort to keep at client-focus tasks in observatory-client


depresolve: use newer tools/go/vcs package to resolve import paths

This changes the ResolveDep method to use the vcs.RepoRootForImportPath
method to resolve external package import paths, which is more stable
than the earlier gosrc.Get call. Additionally, this new call does not
incur a GitHub API request.
This change also makes it so that the Unit name of the resolved dep is
modified to have the base set to the root of the clone URL of the repo.
This ensures that the ref is resolved to the proper def, since the
def will not have a custom import path in its unit name when graphed by
srclib-go (since srclib-go does not have information about a repo's
custom import paths).
For eg, the golang.org/x/net/context.Context def will have the def key:
Repo: github.com/golang/net
Unit: github.com/golang/net/context
UnitType: GoPackage
Path: Context
Note how the Unit name is 'github.com/golang/net/context' and not
'golang.org/x/net/context'. This change ensures that refs to such defs
are always resolved correctly.

@shurcooL I have a feeling that you will like this change 😄

since the def will not have a custom import path in its unit name when graphed by
srclib-go (since srclib-go does not have information about a repo's
custom import paths).

Are we choosing this path because the alternative - providing the import path corresponding to repo root to srclib-go - is very hard to achieve? Or another reason?

That's correct. Going the other way will involve a bigger change at srclib
level. That is probably the better long term solution.
On Apr 26, 2016 10:48 AM, "Dmitri Shuralyov"<EMAIL_ADDRESS>wrote:

since the def will not have a custom import path in its unit name when
graphed by
srclib-go (since srclib-go does not have information about a repo's
custom import paths).
Are we choosing this path because the alternative - providing the import
path corresponding to repo root to srclib-go - is very hard to achieve? Or
another reason?
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/sourcegraph/srclib-go/pull/86#issuecomment-214825759

1 comment, otherwise LGTM


JETAnalyzer: report undefined static parameters

fixes #285
fixes #586

Codecov Report
Attention: 6 lines in your changes are missing coverage. Please review.

Comparison is base (0443cb6) 90.31% compared to head (c249e4c) 90.58%.

Files
Patch %
Lines

src/analyzers/jetanalyzer.jl
70.00%
6 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #588      +/-   ##
==========================================
+ Coverage   90.31%   90.58%   +0.27%
==========================================
  Files          10       10
  Lines        2953     2964      +11
==========================================
+ Hits         2667     2685      +18
+ Misses        286      279       -7

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


Is it possible to include sub sections of a page in the navigation?

Hi,
I am looking into using this plugin and I think it would dramatically reduce the amount of time I would need building a page 'by hand'. One of the thing I need is the ability to add links to sub section of a page and not just the page itself. I read over the docs on 11ty docs page but not sure if this could be done. I was wondering if anybody might have a solution for this?
Thank you very much!

Hi @khoivan88,
what do you mean by subsection? Something below a headline?
Or a
?
How would the navigation be rendered in the ideal case?
Perhaps markdown-it-anchor with a custom configuration would get you there?

Hi @Ryuno-Ki ,
Sorry for the confusion, I just meant some div with different id on the same page.
So, for example I have this page1.html:
...

...

...

...

I was wondering if there is a way with this plugin that when I list the navigation I can get:
- Page 1:
   - Div 1
   - Div 2

If you're trying to add an anchor link to a section of a page, have a look at the Overriding the URL example in the documentation.
If I understand your use-case correctly, you can create a new template with something like this:
eleventyNavigation:
key: Anchor Link
url: /page1#page1-div1
permalink: false
This will add a link to the navigation that will anchor link to the element on the page with the specified ID. permalink: false ensures that an html page isn't generated for this placeholder template. Not the cleanest solution since a file is required for each anchor link in the navigation, but you might be able to do something clever with a data file and pagination if you plan on having lots of anchor links in your navigation.

Hi @bjmiller121 ,
Thank you very much for your suggestion. I ended up just use this TOC plugin to list all of the heading inside each page: https://www.npmjs.com/package/@thedigitalman/eleventy-plugin-toc-a11y


Hazelcast event table extension

Hazelcast event table extension will allow Siddhi to hold large number of events in-memory in a distributed manner.

@lasanthafdo

scr-plugin removed since it's no longer required (because now it uses osgi annotations instead of javadoc scr tags).
resolution:=optional directive was removed and added the needed dependencies with versions.

@dilini-muthumala

Version of Siddhi, Hazelcast, OSGi were added to the parent pom as properties.

@grainier As discussed offline, let's move hazelcast dependency (and others with version element) under dependency management section in the super pom (which is Siddhi pom). After doing that, we don't need to specify versions in siddhi-extension-event-table pom.

@lasanthafdo

Added class level comment to HazelcastOperatorParser
Removed unnecessary new lines in HazelcastOperatorParser.

@dilini-muthumala

Rearranged dependencies as mentioned above

@dilini-muthumala

Removed hazelcast-table-config.xml since it's no longer required.

@lasanthafdo

In test cases, moved assertions out of the callback implementation.


Close button - Uncaught TypeError

I'm opening a popup after an Ajax success. The popup opens fine but hitting the close button closes the popup, but not the overlay and gives an Uncaught TypeError. Any idea why?
Clicking the overlay will close the popup and the overlay correctly.
 $.ajax({
    type : 'post',
    url : '/mailapi/',
    dataType : 'json',
    data : data,
    success : function (d) {
        $.magnificPopup.open({
            items: {
                src: '#crc-thanks',
            },
            type: 'inline'
        }, 0);
    }
});

This was a mistake on my part, there was another call in the code that was breaking it.


How to create the new transitive edges when a direct edges is added?

I don't find any documented methods to add direct edges. I just used Relation.create.

And you are correct in doing so @amadeuspagel. The gem is designed to be working without the application using it having to do anything special. The default AR methods are supposed to be fine.


HA_MQTT target stops broadcasting after a few hours

I have setup a Pi Zero W to act as a gateway to feed my regular server which runs HA.
It works neatly, good job really, nodejs is not officially supported anymore but that's fine. I installed v15.13.0. It's the only thing the Pi does.
I have setup 4 Ruuvitags with a Home Assistant (MQTT) target.
The problem is that after a couple of hours (I have seen anywhere between 2 and 30 hours) all MQTT broadcasts will stop except for one tag.

The logs confirm that (only that one tag is logged being broadcast), as well as my MQTT server.
According to the web interface (and logs), all tags are still being read correctly (BT -> Gateway is good), only the broadcast (publishing) to MQTT fails

Some interesting bits:

Turning off and on the target is enough to put things back in order
Same behavior if I make one target per tag (instead of one for the four), eventually only one tag will be sent to MQTT
The only tag which keeps broadcasting is the first one which was discovered

Extra info: I broadcast at a 60 seconds interval
I did another experiment where I have one Home Assistant (MQTT) target (first in the list) and a regular MQTT target. After a couple of hours all stopped broacasting except the first tag via the Home Assistant (MQTT) target. Turning off and on the regular MQTT target allowed it to work again (the Home Assistant (MQTT) target remain not working except for that one tag, until I also turn it off and on again).
Any idea on where in the code I could add a debug line which would show the tags being iterated for broacasting to MQTT and which would show they are skipped ?

More debugging:
It appears that the tags which stop broacasting are entering the branch:
if (1 * target.interval > 0 && Date.now() - tagField.ts > 1000 * target.interval) in index.js


[HOLD for payment 2023-06-29] Context menu doesn't close after clicking on "Reply in thread" as unauthenticated user in public rooms

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Open a public room as an unauthenticated user (https://staging.new.expensify.com/r/8813851443373010)
Right-click on a comment to display the context menu
Click on "Reply in thread"

Expected Result:
The user is redirected to the sing-in page, and the context menu should be closed
Actual Result:
The context menu is still open
https://github.com/Expensify/App/assets/6829422/e6563810-5cef-497d-939e-f490d5893791
Workaround:
Just click on one of the options, but that could case an undesired behavior
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number:
Reproducible in staging?:
Reproducible in production?:
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
Expensify/Expensify Issue URL:
Issue reported by:
Slack conversation:
View all open jobs on GitHub

Looks like @fedirjh reviewed the PR and is eligible for PR review payment. @fedirjh I sent you an offer on Upwork


improve checking for undesirable keyring backend

It seems like the 'keyring' module is going through a phase of heavy
development, so we do a little bit of backwards compatability here. Eventually
we can probably pin the version of 'keyring' required to >= 8.0.

Reporting and fixing would have taken the same amount of time. Should probably be merged before: #40
@karolyi please review (and merge if no comments).

FWIW: here are the recent keyring releases: https://github.com/jaraco/keyring/releases

how about this as for checking package versions? we could hardwire keyring versions just like it's happening now with undesirable backends:
http://stackoverflow.com/a/4939465

Python 2:
In [1]: import pkg_resources

In [2]: pkg_resources
Out[2]: <module 'pkg_resources' from '/Users/laszlokarolyi/Work/immoscout/afp-cli/venv/lib/python2.7/site-packages/pkg_resources/__init__.pyc'>

In [3]: pkg_resources.get_distribution('keyring')
Out[3]: keyring 8.1.1 (/Users/laszlokarolyi/Work/immoscout/afp-cli/venv/lib/python2.7/site-packages)

In [4]: pkg_resources.get_distribution('keyring').version
Out[4]: '8.1.1'

Python 3:
In [1]: import pkg_resources

In [2]: pkg_resources.get_distribution('keyring')
Out[2]: keyring 8.2 (/Users/laszlokarolyi/Work/immoscout/afp-cli/venv3/lib/python3.5/site-packages)

In [3]: pkg_resources.get_distribution('keyring').version
Out[3]: '8.2'

In [4]: pkg_resources
Out[4]: <module 'pkg_resources' from '/Users/laszlokarolyi/Work/immoscout/afp-cli/venv3/lib/python3.5/site-packages/pkg_resources/__init__.py'>

so it works in both versions, and seems more elegant. the only drawback is, you'll have to install the packages via pip, since it takes the versions from their dist-info, I take it.

I was thinking more along the lines of pinning the version in the build.py so when people upgrade with pip -U they automatically get new version. Still need to check for the fail backend though.

If keyring itself is subject to huge changes, pinning the version is probably a better idea indeed (so we could avoid future breakages caused by changed depended module functionalities), but using pkg_resources in the code itself IMO is still a good idea, looks better than using the magic properties __class__ and __name__.

Using the __class__ and __name__ serves a different purpose than checking the version with pkg_resources. The first means we can use old versions but avoid selecting undesirable backends, which the older keyring implementations will fall back to, i.e. the backends from the file module.
The second checks that a specific package is installed with a specific version. It will not allow us to check that the fail backend  (i.e. 'keyring.backends.fail.Keyring) is used.
As for checking the backend availability, we could alternatively catch the exception that is raised when we call get_password:
In [3]: keyring.get_password('afp', 'vhaenel')
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
<ipython-input-3-fd4fc97143b8> in <module>()
----> 1 keyring.get_password('afp', 'vhaenel')

/data/home/vhaenel/anaconda/lib/python2.7/site-packages/keyring/core.pyc in get_password(service_name, username)
     40     """Get password from the specified service.
     41     """
---> 42     return _keyring_backend.get_password(service_name, username)
     43
     44

/data/home/vhaenel/anaconda/lib/python2.7/site-packages/keyring/backends/fail.pyc in get_password(self, service, username, password)
     16
     17     def get_password(self, service, username, password=None):
---> 18         raise RuntimeError("No recommended backend was available")
     19
     20     set_password = delete_pasword = get_password

RuntimeError: No recommended backend was available

However this is a runtime exception and I'm not sure catching that is such a good idea since it may also signify other things and isn't specific to not finding a recommended backend.

fair enough. I'm new to keyring, so it is how it is.
merging.

The initial reason for building the checks for the backends was, that for older keyring implementations (pre 8.0), it would by default select an unencrypted backend and simply store your plaintext password on disk. This would happen on linux/ubuntu if the gi module was not available. This module contains the python bindings for the PyGobject introspection which can not be installed via pip but only via apt. So, for example, this would happen if you made a virtualenv without using --site-packages with afp-cli and installed keyring. Hence I built this hacky check to make sure that naive users wouldn't store their password unencrypted on disk.
Newer versions of keyring (>8.0) no longer have such behaviour and instead raise the runtime exception mentioned above if they couldn't find a desirable backend. The desirable backends are now:
        keyring.backends.kwallet.DBusKeyring
        keyring.backends.OS_X.Keyring
        keyring.backends.SecretService.Keyring
        keyring.backends.Windows.WinVaultKeyring

as stated on: https://github.com/jaraco/keyring/blob/master/CHANGES.rst
Added all this, comes the fact, that the keyring module is still considerd an experimental feature of the afp-cli ans is in fact not yet listed in the dependencies of the build.py and as such will not be installed or upgraded automatically...

So, perhaps moving forward would mean:
a) Making the keyring dependency non-optional
b) Pinning the version of keyring to >=8.0
c) Catch the RuntimeError to determine if no backend could be found (or convince the authors of keyring to raise a better exception and then catch that)
What do you think?

Definitely. As a temporary solution, we could pin keyring to a specific version which is known to work, and put an issue (pull-request even if one has time for that), to implement a proper fallback/exception, which is still secure, or not use it at all.

@jaraco ?

Not sure what the question is. Here's my best recommendation.

The easiest way to be compatible with older versions is to require both keyring and keyrings.alt.
If keyring is an optional dependency, use this technique to detect that a usable keyring is available (works on all modern versions, including 7.x).

I think the question is more along the lines of:
https://github.com/jaraco/keyring/issues/201

I.e. we want to detect if no real keyring is available. E.g. GnomeKeyring not available because PyGobject not installed or available.


[#24] Cannot handle non-payload WebSocket events

Signed-off-by: Thomas Diesler<EMAIL_ADDRESS>

This has now been rebased on your stuff

OK, lets compromise, please have a look at: https://github.com/hyperledger-labs/acapy-java-client/pull/32
There I added the exception handling to the tenant aware handler, as this is new code I do not care so much about changing behaviour. For the existing EventHandler I need some more time to play around and think this through as it somewhat breaks the existing contract.
Also the contract in the existing code is that the handler implementation never receives null, I therefore changed your code so that this never happens because null becomes "{}", so instead of null an empty object is pushed. So your changes here shouldn't be needed.
I hope this works for you.


Handle multiple arguments

Hello,
Would it be possible to handle multiple arguments like the ipc of electron should do?
See the relevant documentation here and here.
If you are willing to accept a pull request, I could do it, but you should expect some breaking changes.

Hi, @pikanezi.
It's good idea.
But ipc-promise is return Promise, I think interface similar to Promise.

Hi @sasaplus1
The return type would always be a promise, it would only allow such constructions:
app.on("ready", () => {
    ipcPromise.on("addDetective", (name, address) => {
        return new Promise((resolve, reject) => {
            try {
                const [id, created_time] = db.saveDetective(name, address);
                resolve(id, created_time);
            } catch (e) {
                reject();
            }
            resolve();
        });
    });
});

// Renderer process
ipcPromise.send("addDetective", "Sherlock Holmes", "221B Baker Street")
    .then((id, created_time) => {
        console.log(`${id} created at ${created_time}`);
        return null;
    })
    .catch(e => {
        console.warn(e);
        return null;
    });

Here "addDetective" takes two parameters and resolves to two parameters, whereas ipc-promise allows only one parameter

Hi, @JonathanPicques.
                resolve(id, created_time);

Can I pass two arguments to Promise.resolve()? I tried pass two arguments to Promise.resolve() in Chrome DevTools Console, it result is below:
> Promise.resolve(100, 200).then(console.log.bind(console));
100

I think Destructuring is better than pass multiple arguments in this module.


Add pause() and resume() methods to core.tcpsocket typescript API.

Freedom 0.6.21 introduces these new methods, which we would now like to try to use.

Comments from the review on Reviewable.io
Reviewed files:

package.json @ r1
third_party/freedom-typings/tcp-socket.d.ts @ r1

Comments from the review on Reviewable.io

LGTM


Aurelia Dialog, cannot find ./118.html

I'm submitting a bug report

Library Version:
1.0.0-beta.3.0.1

Please tell us about your environment:

Operating System:
Windows 10

Node Version:
6.2.0

NPM Version:
3.10.3

JSPM OR Webpack AND Version
webpack 2.1.0-beta.22

Browser:
Chrome 54

Language:
ESNext

Current behavior:
When I attempt to open my Aurelia dialog I am getting the following message: Unhandled rejection Error: Cannot find module './117.html'.  I attempted to create a gist, but aurelia-dialog is missing from the dependencies.  Instead, I included a link to my project below.  On my login page I wired up the submit button to pop open the dialog box, this is when the error is happening.  Login.js is referenced below.  This seems to be a bug unless I have something configured incorrectly.
NOTE:  The project I am using came from a clone of aurelia-esnext-webpack located in the skeletons repo.
Documentation Location: https://github.com/aurelia/dialog
Project Location: https://github.com/jdemeuse1204/Aurelia-Modal-Issue
Login.js Location: https://github.com/jdemeuse1204/Aurelia-Modal-Issue/blob/master/src/viewmodels/login.js
Login link: http://localhost:9000/#/Login
Expected/desired behavior:
Dialog should open with no errors.

What is the expected behavior?
Just looking for the modal to open

What is the motivation / use case for changing the behavior?
I can use bootstrap modals, but I would much rather use Aurelia dialog's instead :)

Not a problem with the dialog itself, check #213.

I checked the #213 and got the modal to work.
Code:
// viewModal had to be change from Confirm (from import) to 'modals/confirm', please note any relative path will not work
// it must be an absolute path
  this.dialogService.open({ viewModel: 'modals/confirm', model: modalModel }).then(response => {
            debugger;
            if (!response.wasCancelled) {
                console.log('good - ', response.output);
            } else {
                console.log('bad');
            }
            console.log(response.output);
        });

I was using a relative path and that was not working, using the absolute path to the modal worked.  @StrahilKazlachev is there a webpack plugin or any configuration to fix this?

I'm not a webpack guy. Probably @niieani can point you to the appropriate resources.

@niieani do you know or can you point me in the direction of anyone who would know of any webpack configuration changes or plugin's that would help with this issue?

Closing this issue since its a bug with webpack.  Using the string path instead of the actual object from the import worked

@jdemeuse1204 not sure what's the cause. But with the new experimental webpack skeleton (soon to be released) the problem might not exist.

Thank you @niieani, once it is released I can test it out and see if the issue still exists


Elevation control didn't show up

The elevation control in the web GUI does not show up. 8009563b0f7638459006fe6c306dcb579ad5203c was the reason. In GHRequest.prototype.init = function (params) parameter  this.vehicle was still used, although the assignment was removed. So this should be changed into 'params.vehicle'.
The same is true below in 'GHRequest.prototype.initVehicle = function (vehicle) {` where 'this.vehicle' needs to be replaced with 'vehicle'.

Thanks!


We seem to be missing a case in our docs where hot restart is required

From user feedback: (https://github.com/flutter/flutter/issues/9761#issuecomment-299022368)
This page may need to be fleshed out... it is not immediately apparent to me that my situation fell under any of the three cases listed here that hot reload doesn't cover, as all I modified was a build function.
https://flutter.io/intellij-ide/#hot-reloads-vs-full-application-restarts
and then "it might be helpful to say something about how hot restart is also a good idea if you make changes to the member data stored in your State. Recreating your States ensures that old classes won't accidentally be used."

@mit-mit can you help us with these docs?

Resolved with https://flutter.io/hot-reload/


feature: Show is the class mandatory or not

This feature has been added, will be pushed later today.


undefined method `helper_method' for ActionController::API

Hi,
i am in process of upgrading Rails from 5.0.2 to 5.1 (currently on 5.0.3), but i am having problems with t_t as described in the title. Actually, I also upgraded Draper from 3.0.0-pre1 to 3.0.0.
If i leave Draper on pre-release, then everything is fine, if i go to stable release, t_t breaks.
Error:
.../gems/t_t-1.2.1/lib/t_t/rails.rb:20:in 'block in <module:Helper>': undefined method 'helper_method' for ActionController::API:Class (NoMethodError)
Is there any chance you could fix this? Thx

Hi. Sure - I'll fix it ASAP. Support of rails 5.1 is a key priority

check out v1.2.2

Perfect. Works flawlessly 👍


quick_log dependency

It's been more than 2 months now that quick_log moved to version >= 1.0.0
Can you update the dependencies, or remove the upper limits?

just pushed 2.2.2 which sets the bounds to be >= 1.0.0 and <2.0.0. Hope that helps.

Thanks!


Uncaught SyntaxError: Unexpected token case

[Enter steps to reproduce:]

...
...

Atom: 1.43.0 x64
Electron: 4.2.7
OS: Microsoft Windows 10 Enterprise Evaluation
Thrown From: Hydrogen package 2.13.1
Stack Trace
Uncaught SyntaxError: Unexpected token case
At C:\Users\Tor

Not enough information.


ForEach-Object breaks paths in FileInfo

Reproducible on 6.0.2
When a file in a directory is passed to ForEach-Object, it loses its subpath
Steps to reproduce
Setup:
New-Item -ItemType Directory -Name "Subdir"
"File content" > "Subdir/myFile.txt"

Now for the bug:
dir . -Recurse -File | % {Get-Content $_ }

Expected behavior
Should see the content of myFile.txt:
File content

The results should be identical to dir . -Recurse -File | Get-Content
Actual behavior
Error:
Get-Content : Cannot find path '/var/tmp/pstest/File.txt' because it does not exist.
At line:1 char:26
+ dir -Recurse -File  | % {Get-Content $_ }
+                          ~~~~~~~~~~~~~~
+ CategoryInfo          : ObjectNotFound: (/var/tmp/pstest/File.txt:String) [Get-Content], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetContentCommand

The Subdir subdirectory seems to be ommitted from the path of the file that Get-Content tries to find. This does not happen when not using ForEach-Object.
Environment data

Name                           Value
----                           -----
PSVersion                      6.0.2
PSEdition                      Core
GitCommitId                    v6.0.2
OS                             Darwin 17.6.0 Darwin Kernel Version 17.6.0: Tue May  8 15:22:16 PDT 2018; root:xnu-4570.61.1~1/RELEA...
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

@yevster Get-Content -Path takes a string argument so the FileInfo object in $_ gets converted to a string when it's passed to the cmdlet. Now the .ToString() of a FileInfo object is just the filename, not the full path so it won't work for files not in the current directory. If you use the FullName property on the object as in
 dir . -Recurse -File | % {Get-Content $_.FullName }

it will work as expected and you'll see the content of the file.

@yevster:

As @BrucePay  states, -Path (and -LiteralPath) are bound as strings when values are passed as arguments, and whether a System.IO.DirectoryInfo  or System.IO.FileInfo instance stringifies to a mere name (as in your case) or a full path varies - it depends on the specifics of the Get-ChildItem / Get-Item command.

By contrast, when such instances are passed via the pipeline, their .PSPath property is bound to -LiteralPath, which works reliably.

This problematic behavior is discussed in #6057, along with a potential solution.

It is recommended to change get-content. Let -LiteralPath and -path, bind Property FullName, when piped.

@chuanjiao10: Piping System.IO.DirectoryInfo and System.IO.FileInfo instances already works as expected (at least if emitted by PS provider cmdlets): their .PSPath property binds to -LiteralPath, and .PSPath is like .FullName, but with a provider-name prefix.
The problem is with passing such instances as arguments, where stringification is applied, and whether that stringification returns the full path varies by command and can therefore not be relied upon.
Using $_.FullName is an effective workaround, but it shouldn't be necessary and the need for it regularly trips users up.
#6057 suggests applying the pipeline's by-property-value binding logic to direct argument passing as well, which would solve the problem.

@BrucePay it's a little bit more insidious than that: ToString() returns whatever was passed to the FileInfo ctor; sometimes a name, sometimes a full path.


ChefFSDataStore.exists_dir? is slow on large repositories

@jkeiser I was able to trace the additional slowness during depsolve to the exists_dir? check.
If the cookbook repository is large then the exists_dir? operation is slow because it iterates the entire cookbook file system.  In the example repository https://github.com/tpodom/slow-repo the exists_dir? takes 0.36 seconds to execute.  Since this method is executed during the depsolve process it results in walking the entire file system multiple times.
The scenario that is slow is when exists_dir? is called on a cookbook directory because it calls list on the cookbooks root.  list then walks all of the cookbooks but each cookbook in turn calls its own children to check can_upload?.
There are two potential improvements I can think of.  One is to modify eixsts_dir? to instead check the single path.  Another potential improvement would be to rewrite ChefRepositoryFileSystemCookbookDir::can_upload? to have it exit early if it finds any child since it's just checking size > 0.

@jkeiser is this the same as the perf bug as the one you fixed in 12.5.0, or is this another one?

This is def another one, seeing (and currently debugging) this as well on 12.9.41. What's (essentially, at the end) a (per cookbook) Dir.exists? takes about 60s on a not so large collection of cookbooks.

@lamont-granquist I came across the same situation while working on chefignore file lookup per instance get created multiple times for ChefRepositoryFileSystemCookbookDir class per cookbook in children traversal, so we can also improve that as well.


BUG 2153675: osd: Fix osd-prepare-job for encrypted cluster

Description of your changes:
osd: re-open encrypted disk during osd-prepare-job if closed
This commit implements this corner case during osd-prepare job.
The encrypted block is not opened, this is an extreme corner case
The OSD deployment has been removed manually AND the node rebooted
So we need to re-open the block to re-hydrate the OSDInfo.

Handling this case would mean, writing the encryption key on a
temporary file, then call luksOpen to open the encrypted block and
then call ceph-volume to list against the opened encrypted block.
We don't implement this, yet and return an error.

When underlying PVC for osd are CSI provisioned, the encrypted device
is closed when PVC is unmounted due to osd pod being deleted.
Therefore, this may occur more frequently and needs to be handled.
This commit implements the fix for the same.
Signed-off-by: Rakshith R<EMAIL_ADDRESS>(cherry picked from commit https://github.com/red-hat-storage/rook/commit/bde286ef495fa456513f73ccd2e20b48b8f9d380)
osd: remove stale dm device during osd-prepare-job
During osd-prepare-job,
The encrypted device is found to be closed in some cases when
the OSD deployment has been removed manually accompanied
by any of following cases:

node reboot
csi managed PVC being unmounted etc

while re-opening the block to re-hydrate the OSDInfo,
the dm device <pvc-name>-block-dmcrypt clashes with
the one used by OSD pod which is stale by now.
This commit adds cmd to remove this stale dm device.
Error with output "No such device" is ignored.
Signed-off-by: Rakshith R<EMAIL_ADDRESS>(cherry picked from commit https://github.com/red-hat-storage/rook/commit/24fa9ed935b3287acaf2867c58d015f5addd1b43)
Which issue is resolved by this Pull Request:
Resolves #
Checklist:

[ ] Commit Message Formatting: Commit titles and messages follow guidelines in the developer guide).
[ ] Skip Tests for Docs: If this is only a documentation change, add the label skip-ci on the PR.
[ ] Reviewed the developer guide on Submitting a Pull Request
[ ] Pending release notes updated with breaking and/or notable changes for the next minor release.
[ ] Documentation has been updated, if necessary.
[ ] Unit tests have been added, if necessary.
[ ] Integration tests have been added, if necessary.

/bugzilla refresh
/cc @travisn @BlaineEXE @red-hat-storage/rook-admins
cc @sunilheggodu

/lgtm
/approve


Added missing / in README example

In a usage example, there was a missing / in View closing tag
I've put it back where it belongs! ;)
Have a nice day!

Thanks! Merged :)


chore: add travisci badge to readme

What does this PR do?
Travis CI is an interface for vetting build structures. It determines if a build passes or fails. It comes with a badge to indicate the type of build.
Description of Task to be completed?

Setup a .travis.yml file in the root directory.
config the travis file and include all the settings.
Add travis badge to readme file

Any background context you want to provide?
Travis integration is kind of integration known as continuous integration.
What are the relevant pivotal tracker stories?
Integrate Travis CI badge and attach badge to readme

Great job with the implementation. I see however that the build is "Done, but with warnings."
Plus the test execution explodes at some point. Let's try to fix this so we don't push the problem to the next person.


The referenced command does not exist in the Az module: Get-AzureServiceAvailableExtension

Hello, the command referenced to retrieve the schema does not exist in the current Az module.
Get-AzureServiceAvailableExtension
Also there is no guidance on where to install the module from.
Direct link:
https://docs.microsoft.com/en-us/azure/azure-monitor/agents/diagnostics-extension-schema-windows#public-configuration-file-schema

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

ID: 332c2bb9-4c11-e250-c6d0-1b93a3fd9b4f
Version Independent ID: 03103c43-be85-9d3f-e819-e5b6a15edfc3
Content: Windows diagnostics extension schema - Azure Monitor
Content Source: articles/azure-monitor/agents/diagnostics-extension-schema-windows.md
Service: azure-monitor
Sub-service: agents
GitHub Login: @bwren
Microsoft Alias: bwren

@bwarren18 Thank you for bringing this to our notice, we will review and get back to you at the earliest.

@bwarren18 My sincere apologies for delay in getting back to this thread. I am further validating this with our internal team and will keep you updated at the earliest.

@bwarren18 are you trying to get a list of available extensions in a region or a list of extensions on a VM?

@MsGabsta  We have had issues with deploying diagnostics extension using ARM templates and want to ensure our code is correct and using the proper schema.
The link included in the original post says to use the following command to get the PaaSDiagnostics schema.
(Get-AzureServiceAvailableExtension -ExtensionName 'PaaSDiagnostics' -ProviderNamespace 'Microsoft.Azure.Diagnostics').PublicConfigurationSchema | Out-File –Encoding utf8 -FilePath 'C:\temp\WadConfig.xsd'
The command does not work because it is not included in the Az module and it is not clear where to install it from.
Thank you.

@Lukeout I am here to help with updating the documentation for this issue and need assistance.
Does the PowerShell command for downloading the public configuration file schema definition need to be updated and/or does guidance on where to install the module from need to be added?

#reassign:guywi-ms

#reassign: @Lukeout

For technical support, please see the following support channels:
Microsoft Azure Monitor Q&A question page
https://docs.microsoft.com/answers/topics/24223/azure-monitor.html
Create a support ticket
Get support for your Azure services
https://azure.microsoft.com/support/create-ticket/
Because this issue requires scoping and follow-up, we are closing this GitHub issue. #please-close


Change repo fork from GB to JB?

Currently, this repository is forked from Goldbox. However, if we wanted to, we could change it to be forked from Jummbox instead. This might make merging easier in the future.
This could be done via Github Support:
https://support.github.com/request/fork

Not sure who to assign/what labels to put so for now I'll just leave it blank


support throw duplicate row during realtime ingestion in RealtimePlumber

When pulling streaming data, we don't always ingest data without duplicate, like the upper streaming failover and write part of same data again.
So we add a config to allow to check duplicate row when ingest if we really want more accurate data.
how it works:

add a dedupColumn config in RealtimeTuningConfig, which is the primary key of the data
In RealtimePlumber, sink is bound to an interval, then maintain a Set inside the sink to hold all values of dedupColumn, so dedup doesn't happen across sinks
when sink.add(InputRow) called, check the value of dedupColumn of this inputRow whether it is in the Set, if so, reject with return rowCount as -2
RealtimeManager increase the ingest/events/duplicate count metric
the dedup Set is cleared when the sink is no longer writable:
5.1 when mergeAndPush which is called at fix rate
5.2 when got a new sink then try to clearDedupCache for the older sink in case merge process is slow in 5.1

Why need a primary key?
If we compare each columns to distinguish duplication, we need to setup a sink level timeAndDims which costs lots of heap memory.
Instead we ask user to prepare a 'pk' column as dedupColumn (usually, pk is built on several columns like {timestamp, user_id, item_id, order_id}) in their ETL process like in storm, spark, flink, user is glad to do so to gain the ability of dedup,
Of course, 'pk' is no need to be in dimension list, it's only for dedup.
Limitation:
if the dedupColumn is string type column, whose value maybe md5, use it's long type hashcode (use BKDRHash algorithm) instead to judge whether it is a duplicate row, so there's very small change to throw away a row which is not duplicate. But I think it is worth to do this trade off to reduce heap cost to avoid OOM if maxRowsInMemory is a big number.

@kaijianding thanks. I have a follow-up question. The motivation of this PR is to remove duplicate rows, but the implementation checks only one column which looks not enough to check duplication. Is this useful only when there is a unique column like primary key?

@jihoonson yes, it need a primary key.
If we compare each columns to distinguish duplication, we need to setup a sink level timeAndDims which costs lots of heap memory.
We ask our user to prepare a 'pk' column(usually, pk is built on several columns like {timestamp, user_id, item_id, order_id}) in their ETL process like in storm, spark, flink, user is glad to do so to gain the ability of dedup, then druid uses 'pk' as dedupField to do dedup, of course, 'pk' is no need to be in dimension list, it's only for dedup.

@kaijianding can you please add short design overview like that reviewers and druid user can understand how does this work without reading thousand line of codes? Also might be very good to highlight what are the overhead of the proposed architecture/what are the principal caveats ...Thanks!

@b-slim @jihoonson design overview added.
@jihoonson use IncrementalIndexAddResult now

@kaijianding thanks.

@b-slim even though the latest change looks good to me now, I hadn't finished my review yet when this PR was merged. Please give other reviewers some time before merging.

@kaijianding sorry for that but i thought you have said you are done at least that is how  i read looks good time me

@kaijianding looks good to me overall. Left two comments. Also please address @b-slim's comment and resolve conflicts.

@b-slim sorry for making you confused. I think we should be careful until reviewers explicitly gives a +1 or approves a PR.

@kaijianding Is the dedup feature only supported for stream pull ingestion? or I can use it with stream push/tranquility as well?

@ankujain this feature is implemented in RealtimePlumber and sink, so it should not care about how firehose is implemented, pull or push


github/workflows/upload-to-pypi: install wheel

Should fix the workflow.

It works: https://github.com/cobrateam/splinter/runs/6846405335


[Feature]: Smoothing Maps

Guidelines

[X] I agree to follow this project's Contributing Guidelines.

Description
I have been thinking about better ways to do map analysis recently. I think the way we are identifying particles with the signal/noise is pretty unique. I have been concerned though that noise isn't being well removed and some small particles are being totally lost due to them having just a few strong pixels. I think that smoothing of the spectra spatially and/or smoothing of the signal/noise spatially could help with this.
I found this package that has a matrix smoother we could use:
https://search.r-project.org/CRAN/refmans/oce/html/matrixSmooth.html
Source code is in cpp:
https://github.com/dankelley/oce/blob/develop/src/matrix_smooth.cpp
Problem
Spectra are spatially highly variable.
Proposed Solution
Spatial spectral smoothing or signal/noise smoothing spatially.
Alternatives Considered
current status quo is raw feature analysis.

Some other options than pure mean are gaussian smooth:
https://search.r-project.org/CRAN/refmans/soundgen/html/gaussianSmooth2D.html
This mmand package is pretty universal, could replace imagr:
https://github.com/jonclayden/mmand?tab=readme-ov-file#skeletonisation
https://rdrr.io/cran/mmand/man/gaussianSmooth.html
https://github.com/jonclayden/mmand

Put a little work into the mmand option, the gaussian smooth strategy looks the best so far.
#' @rdname def_features
#'
#' @importFrom imager label as.cimg
#' @importFrom data.table as.data.table setDT rbindlist data.table
#' @export
def_features.OpenSpecy <- function(x, features, ...) {
    if(is.logical(features)) {
        if(all(features) | all(!features))
            stop("features cannot be all TRUE or FALSE because that would indicate ",
                 "that there are no distinct features", call. = F)

        features_df <- .def_features(x, features)
    } else if(is.character(features)) {
        if(length(unique(features)) == 1)
            stop("features cannot all have a single name because that would ",
                 "indicate that there are no distinct features", call. = F)

        features_df <- rbindlist(lapply(unique(features),
                                        function(y) .def_features(x, features == y))
        )
    } else {
        stop("features needs to be a character or logical vector", call. = F)
    }

    obj <- x
    x <- y <- feature_id <- NULL # workaround for data.table non-standard
    # evaluation
    md <- features_df[setDT(obj$metadata), on = c("x", "y")]
    md[, feature_id := ifelse(is.na(feature_id), "-88", feature_id)]
    md[, "centroid_x" := mean(x), by = "feature_id"]
    md[, "centroid_y" := mean(y), by = "feature_id"]

    obj$metadata <- md

    return(obj)
}

#' @importFrom grDevices chull
#' @importFrom stats dist
.def_features <- function(x, binary, name = NULL) {
    # Label connected components in the binary image
    binary_matrix <- matrix(binary, ncol = max(x$metadata$x) + 1, byrow = T)
    labeled_image <- imager::label(imager::as.cimg(binary_matrix),
                                   high_connectivity = T)

    # Create a dataframe with feature IDs for each true pixel
    feature_points_dt <- data.table(x = x$metadata$x,
                                    y = x$metadata$y,
                                    feature_id = ifelse(binary_matrix,
                                                        labeled_image, -88) |>
                                        t() |> as.vector() |> as.character())

    # Apply the logic to clean components
    cleaned_components <- ifelse(binary_matrix, labeled_image, -88)

    # Calculate the convex hull for each feature
    convex_hulls <- lapply(
        split(
            as.data.frame(which(cleaned_components >= 0, arr.ind = TRUE)),
            cleaned_components[cleaned_components >= 0]
        ),
        function(coords) {coords[unique(chull(coords[,2], coords[,1])),]
        })

    # Calculate area, Feret max, and feature IDs for each feature
    features_dt <- rbindlist(lapply(seq_along(convex_hulls), function(i) {
        hull <- convex_hulls[[i]]
        id <- names(convex_hulls)[i]
        if(nrow(hull) == 1)
            return(data.table(feature_id = id,
                              area = 1,
                              perimeter = 4,
                              feret_min = 1,
                              feret_max = 1)
            )

        # Calculate Feret dimensions
        dist_matrix <- as.matrix(dist(hull))
        feret_max <- max(dist_matrix) + 1

        perimeter <- 0
        cols = 1:nrow(hull)
        rows = c(2:nrow(hull), 1)
        for (j in 1:length(cols)) {
            # Fetch the distance from the distance matrix
            perimeter <- perimeter + dist_matrix[rows[j], cols[j]]
        }

        # Area
        area <- sum(cleaned_components == as.integer(id))

        feret_min = area/feret_max #Can probably calculate this better.

        data.table(feature_id = id,
                   area = area,
                   perimeter = perimeter,
                   feret_min = feret_min,
                   feret_max = feret_max
        )
    }), fill = T)

    # Join with the coordinates from the binary image
    if (!is.null(name)) {
        features_dt$feature_id <- paste0(name, "_", features_dt$feature_id)
    }

    feature_points_dt[features_dt, on = "feature_id"]
}

map <- read_extdata("CA_tiny_map.zip") |> read_any()

signal <- sig_noise(map, metric = "sig_times_noise")

heatmap_spec(map, z = signal)

signal_matrix <- matrix(signal, ncol = max(map$metadata$x) + 1, byrow = T)

smooth_signal_matrix <- gaussianSmooth(signal_matrix, sigma = c(1,1))
display(signal_matrix)
display(smooth_signal_matrix)
k <- shapeKernel(c(3,3), type="box")
display(medianFilter(signal_matrix, k))

smooth_thresholded <- threshold(smooth_signal_matrix, method = "kmeans")
display(smooth_thresholded, col=rainbow(max(signal_components,na.rm=TRUE)))

k <- shapeKernel(c(3,3), type="box")
smooth_components <- components(smooth_thresholded, k)

display(smooth_components, col=rainbow(max(smooth_components,na.rm=TRUE)))

library(loder)
library(mmand)
B <- readPng(system.file("images", "B.png", package="mmand"))
k <- shapeKernel(c(3,3), type="diamond")

display(B)
display(skeletonise(B,k,method="lantuejoul"), col="red", add=TRUE)

Available in 75411f12f685fe4a62e26cfbb239bb6eca7bba9d for both 2d and 3d


Add withContiguousStorageIfAvailable implementation to WebSocketMaskingKey

Motivation:
Add withContiguousStorageIfAvailable implementation to WebSocketMaskingKey because it's faster and contiguous storage is trivially available. Fixes #1234.
Modifications:

Implement WebSocketMaskingKey.withContiguousStorageIfAvailable
Make it @inlinable, requiring promoting WebSocketMaskingKey.key to internal
so renamed to _key.
Added tests using MaskingKey to WebSocketFrameEncoderBenchmark

Result:
Writing WebSocketMaskingKey into ByteBuffer is about 2x faster.

@swift-nio-bot test perf please

@swift-nio-bot test perf please


addOptparseApplicativeCompletionScripts is upstream

I think the nixpkgs bump is new enough.

Nice! Is it any different from ours?
On Wed, Nov 14, 2018, 19:13 John Ericson<EMAIL_ADDRESS>wrote:

I think the nixpkgs bump is new enough.
You can view, comment on, or merge this pull request online at:
https://github.com/obsidiansystems/obelisk/pull/315
Commit Summary

addOptparseApplicativeCompletionScripts is upstream

File Changes

M default.nix
https://github.com/obsidiansystems/obelisk/pull/315/files#diff-0
(22)

Patch Links:

https://github.com/obsidiansystems/obelisk/pull/315.patch
https://github.com/obsidiansystems/obelisk/pull/315.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/obsidiansystems/obelisk/pull/315, or mute the thread
https://github.com/notifications/unsubscribe-auth/ABGlYA3aK0eUfxsyUb8HFemMZLgS7s40ks5uvLGWgaJpZM4Ye1Qr
.

I upstreamed it before, and then turns out someone had already written one so they were combined. Pretty sure it's still basically the same.

I'm not sure we should be switching to one that's deprecated.  https://github.com/NixOS/nixpkgs/blob/8d275f6d17c4c1db16c1cb18965308a790da8c63/pkgs/development/haskell-modules/lib.nix#L359

I confess I didn't want to switch to a newer nixpkgs less Hydra get stuck with a mass rebuild. It's just a rename so it's semantically fine.


[package:vm_service] Missing implementations for some ext.dart.io extensions

The DartIOExtension extension Is missing a few key extensions such as a way to query all open files
ext.dart.io.getHttpEnableTimelineLogging, // Implemented
ext.dart.io.setHttpEnableTimelineLogging, // Implemented
ext.dart.io.getSocketProfile, // Implemented
ext.dart.io.startSocketProfiling, // Implemented
ext.dart.io.pauseSocketProfiling, // Implemented
ext.dart.io.clearSocketProfile,  // Implemented
ext.dart.io.getVersion, // Implemented
ext.dart.io.getOpenSockets, // ?
ext.dart.io.getSocketByID, // ?
ext.dart.io.getOpenFiles,  // ?
ext.dart.io.getFileByID // ?

Related: #41455
/cc @bkonyi

The implementation is in sdk/lib/io/io_resource_info.dart

@ZichangG I should've provided some context, sorry for that. I'm working on third party dart dev tooling and I'm looking for a protocol reference or for an implementation that is meant to be consumed outside of dart.io. The implementation you linked to is internal to dart.io only.
We'd like to not depend on a reverse-engineered protocol that might change any time without further notice. Since vm_service contains part of ext.dart.io, I expected to find a complete client there. This issue is about adding the missing extensions to vm_service.

These extensions will be available in package:vm_service v5.1.0 once this CL lands.


fix: pusher attempt delete

Checklist
If a non-shallow receipt is received before the allowed 6 attempts, then with the current implementation, the key never gets deleted causing a leak.

[ ] I have read the coding guide
[ ] My change requires a documentation update and I have done it
[ ] I have added tests to cover my changes.

Description

Motivation and context (Optional)

Related Issue (Optional)

Screenshots (if appropriate):

This change is

I'm not entirely sure that this is desirable behavior. At some point we've turned on the skip list for successful pushes too, which should in theory result in (some) disjoint path traversal for repeated successful pushes of the same chunk. The key doesn't leak since it has a TTL and there are timely cleanups on the skip-list.

I'm not entirely sure that this is desirable behavior. At some point we've turned on the skip list for successful pushes too, which should in theory result in (some) disjoint path traversal for repeated successful pushes of the same chunk. The key doesn't leak since it has a TTL and there are timely cleanups on the skip-list.

@acud I think you were looking at a closed PR. This PR is related to the pusher package :)

oops wrong pacakge. sorry you're right. i'll review again


Revise .gitignore

This will revise .gitignore to include format.patch and local Makefile.
ONE-vscode-DCO-1.0-Signed-off-by: SaeHie Park<EMAIL_ADDRESS>

From draft #14


Server lockup

my environment running ArangoDB
I'm using the latest ArangoDB of the respective release series:

[ ] 2.8
[ ] 3.0
[ x ] 3.1.11
[ ] self-compiled devel branch

On this operating system:

[ ] DCOS on

[ ] AWS
[ ] Azure
[ ] own infrastructure

[ ] Linux

[ x ] Debian .deb
[ ] Ubuntu .deb
[ ] SUSE   .rpm
[ ] RedHat .rpm
[ ] Fedora .rpm
[ ] Gentoo
[ ] docker - official docker library
[ ] other:

[ ] Windows, version:
[ ] MacOS, version:

My setup is 3 nodes each with their agency, primary and coordinator. Each server has 128GB. The problem is that the server keeps locking up after a certain amount of time. The biggest collection I have is about 130k items. Replication factor is 2 and I tried shard sizes of 2 to 16 (to see if the problem was shard related).
Coordinator logs appear to have some errors like below:
2017-02-23T11:45:49Z [39143] ERROR {cluster} ClusterComm::performRequests: got no answer from shard:s6201182:/_db/app/_api/collection/s6201182/count with error 4
2017-02-23T11:45:49Z [39143] WARNING while trying to unregister query<PHONE_NUMBER>: timeout, cluster node: 'PRMR-8b5e149c-1d46-45f8-a53a-8920f9d04771', shard: 's6201176', endpoint: 'tcp://arangodb:20002', error: 'timeout in cluster operation'
Primary log:
2017-02-23T07:22:31Z [39024] ERROR synchronizeOneShard: long call to syncCollection for shard s3100018 {"barrierId":"23126536","lastLogTick":"23106707","collections":[{"id":"2100009","name":"s3100018"}]} start time:  Thu Feb 23 2017 07:12:12 GMT+0000 (UTC) end time:  Thu Feb 23 2017 07:22:31 GMT+0000 (UTC)
2017-02-23T08:37:32Z [39024] WARNING retrying failed HTTP request for endpoint 'tcp://arangodb_server:20002' for replication applier in database '_system' - retries left: 1
2017-02-23T08:43:39Z [39024] ERROR failed to instantiate the query: Error message received from shard '' on cluster node 'CRDN-8042326a-6401-486c-b9e2-409bb6eeee54': query ID not found (while executing)
2017-02-23T09:05:09Z [39024] ERROR initializeCursor lead to an exception
2017-02-23T09:05:09Z [39024] ERROR initialize lead to an exception
Agencies appear to be fine. I don't think the coordinators are the problem. The Primary/DbServer is the one locking up especially since I see it pegging the CPU during the lockup times.

I have a theory to explain this. To confirm: Can you tell me what type of AQL queries are and have been running on that cluster? Are there any that run into an error or get aborted?
The delay of about 10 minutes on the primary server in the synchronizeOneShard function indicates that something waits for a part of a distributed query to be cleaned up (the timeout there is currently 10 min).
So, to find this bug, we need to find an AQL query that leaves parts of the distributed query engine hanging around on some DBserver.

Common AQL query on the largest collection (130k documents):
LET device = document(devices, @bindVar1) FOR interface IN interfaces FILTER interface.device == @bindVar0 SORT interface.name RETURN interface
AQL queries on smaller collections
LET device = document(devices, @bindVar0) FOR peer IN bgp_peers FILTER device._id == peer._from SORT peer.peer_state RETURN peer
LET device = document(devices, @bindVar0) FOR ifaceLink IN interface_links FILTER ifaceLink._from == device._id RETURN ifaceLink
These are the only read operations executed in parallel from different clients. These are quick since there are indexes, but when lockups happen then they fail or take long
Write operations are using the updateDocument and insertDocument operations in the arangodb-java-driver, but I assume those are not AQL.
The write operations tend to result in ArangoDBException during this time with "Error 1457 - time
out in cluster operation"

I went back to 3.1.7 and 3.1.0 to see if the problem manifests and yes it does.

I tried to see if batching updates and creates would help alleviate issues with the servers. I started using arangodb-java-driver's updateDocuments and insertDocuments and now I get "Error 18 lock timeout" and 57 cpu load with 2395 cpu% as reported in htop by the primary.

I ovesubscribed the cpus with a higher thread count and lowered it since then. I also disabled returning new/old in the update/create options for the java driver. While the cpu has decreased dramatically since then.. still locking up. I'm giving up on my side. Hopefully new developments will take hold.

Looks like a new version will be released that addresses this, thanks for all the help guys!

We aim to include the fix in 3.1.13, I will close the issue when that is published.

ArangoDB 3.1.13 is available for download.


sd-image: remove populateFirmwareCommands in favor of firmwarePartitionContents

This converts sdImage.populateFirmwareCommands into a
derivation that can be used to obtain firmware partition contents.
For example for sd-image-armv7l-multiplatform,
given a test_firmware.nix file containing
{
  imports = [
    <nixpkgs/nixos/modules/installer/sd-card/sd-image-armv7l-multiplatform.nix>
  ];
  nixpkgs = {
    crossSystem.system = "armv7l-linux";
    overlays = [
    ];
  };
}

we can now do
nix-build '<nixpkgs/nixos>' \
  -A config.sdImage.firmwarePartitionContents \
  -I nixos-config=./test_firmware.nix

Description of changes
See above. Prior discussion at https://github.com/NixOS/nixpkgs/pull/241534#issuecomment-1764896962
Resolves https://github.com/NixOS/nixpkgs/issues/108048
CC @samueldr @SFrijters
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[x] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Cool, looks promising. I also tried it with aarch64-linux and it generates some familiar stuff!
But I'm not good enough with this to put down a firm approval.
If I understand it correctly, the 'manual' update process would now be to build this derivation and copy everything to the boot/firmware partition?

Somewhat of a side note: if you are going to move towards a proper update mechanism, would it make sense to add an equivalent to boot.loader.raspberryPi.firmwareConfig again - i.e. some parameter that can append to config.txt?
Although I (hopefully) have my RPi LED customization sorted with device tree overlays, the dtparams approach was a lot more user friendly (and more widely documented if you search for a way to do it).

If I understand it correctly, the 'manual' update process would now be to build this derivation and copy everything to the boot/firmware partition?

Exactly. We can try adding a (semi-)automated update mechanism that would do that for us - i.e. something like
mkdir -p /boot/firmware
mount /boot/firmware
... copy (if newer / diffferent hashes or so) ...
umount /boot/firmware

Somewhat of a side note: if you are going to move towards a proper update mechanism, would it make sense to add an equivalent to boot.loader.raspberryPi.firmwareConfig again - i.e. some parameter that can append to config.txt? Although I (hopefully) have my RPi LED customization sorted with device tree overlays, the dtparams approach was a lot more user friendly (and more widely documented if you search for a way to do it).

Possibly, I'm not a fan of these RPi specific mechanisms but sometimes it seems necessary to adjust config.txt by hand and this would overwrite the changes. You can already provide a custom sdImage.populateFirmwareCommands (or sdImage.populateFirmware derivation with this patch) if you only import sd-image.nix module.
This looks a bit weird tho - why would you have sd-image.nix imported and configure sdImage options on installation where there's no SD at all - so this is a good point to consider. Seems like a more generic module / namespace is needed (and sd-image-* could default to that).
We sure can get there but ideally in backwards compatible manner.

Yeah, these things would make more sense to me if they're not referencing anything SD card related at all.
Then something like foo.firmware.populateFirmwareCommands could use the option foo.firmware.extraFirmwareConfig by default to append something (nothing by default), so if you use extraFirmwareConfig you still get the basic stuff for free, but if you know what you're doing you can override populateFirmwareCommands in its entirety.
I don't know too much about (the implementation of) modules - would it otherwise be possible to use an overlay (nix overlay, not device tree overlay) to use prev.populateFirmwareCommands and then append to that? It would be less user friendly than having the extra config option, but if we're trying to discourage it anyway...
Alternatively, just updating the documentation/NixOS on RPi wiki would help (I can probably do something with that). But it would be good to settle on the desired way forward first.

Long infodump, sorry...
Don't hesitate to ask for more precisions.
About the SD card build API
The SD card building API should be considered semi-private and fine enough to break (with proper mkRemovedOption use).
So this change here is generally acceptable, as long as it's not plumbed for any automatic updating, nor recommended to automatically plumb by end-users.
Having better semantics for the different bits involved here is a general win, I guess.
About automatically updating firmware
I've had the discussion a couple of times about automatically updating the firmware, and the situation is kinda hard.
This is something that lives outside of the lifecycle of generations; in other words, you cannot use the generations menu to go back to a previously working generation, when things break.
“But the bootloader has that problem too!” might be your first instinct. It's true. But it's also the boundary at which NixOS operates. Anything that runs prior to or the bootloader depends on outside of the lifecycle of generations is a no-go zone. And the bootloader is managed only because of the implicit requirements of it existing for the lifecycle of generations to even be a thing.
Now, all of that is thinking generally, this includes your boring standard Laptop UEFI firmware, and other spicier options.
The overall way we should support such things is by supporting standard (enough) methods to update firmware. The example here is fwupd/LVFS.
About board-specific hacks and workarounds
It would be undesirable to add again specific patterns for a given board. Here the Raspberry Pi.
Like alluded to previously, we should aim to support "standard" methods to manage those bits. So no, we shouldn't add any at this point in time. The aim should be to, at some point, drop this, but it's not planned for the near future.
As hinted previously (if you read between the lines) we should aim to support composing the "base" NixOS system on top of external projects (any one of them!) rather than pre-bake device-specific images.
This holds for all ecosystems, not specific to Raspberry Pi, nor for ARM.
About this particular example and the future
Things are in motion with Tow-Boot to make it well-supported generally with fwupd/LVFS.
This would include the Raspberry Pi family of devices, in the future.
So, one way to have this all work will be a future where NixOS has no knowledge of the Raspberry Pi firmware or that it needs to be updated, but instead relies on an external Platform Firmware provider, and then fwupd/LVFS to update the platform firmware, irrespective of the board. (But not limited to a specific one!)

This is something that lives outside of the lifecycle of generations; in other words, you cannot use the generations menu to go back to a previously working generation, when things break.

“But the bootloader has that problem too!” might be your first instinct. It's true. But it's also the boundary at which NixOS operates. Anything that runs prior to or the bootloader depends on outside of the lifecycle of generations is a no-go zone. And the bootloader is managed only because of the implicit requirements of it existing for the lifecycle of generations to even be a thing.

I would like to see this communicated more clearly to the user at the very least. I assume this information is buried in the documentation somewhere, but I generally expected that if something is an option in a NixOS module, that a change will actually get applied.
As it is, I get a warning that boot.loader.raspberryPi is going to be removed, but I think it is equally important to warn that changing the relevant options to conform to the modern way of doing things will not actually get you to the desired state (unlike in virtually every other case in NixOS?).

The SD card building API should be considered semi-private and fine enough to break (with proper mkRemovedOption use).
So this change here is generally acceptable, as long as it's not plumbed for any automatic updating, nor recommended to automatically plumb by end-users.
Having better semantics for the different bits involved here is a general win, I guess.

Thanks for the pointers, updated to deprecate the old option. I'm not sure if it warrants a changelog entry since the deprecation message you get is pretty good I think.

About automatically updating firmware
I've had the discussion a couple of times about automatically updating the firmware, and the situation is kinda hard.
This is something that lives outside of the lifecycle of generations; in other words, you cannot use the generations menu to go back to a previously working generation, when things break.
“But the bootloader has that problem too!” might be your first instinct. It's true. But it's also the boundary at which NixOS operates. Anything that runs prior to or the bootloader depends on outside of the lifecycle of generations is a no-go zone. And the bootloader is managed only because of the implicit requirements of it existing for the lifecycle of generations to even be a thing.

Good point, I've stripped the commit message of hints about automated firmware updates as we can figure that out later. It is probably better to not try to have a fully automated solution and instead opt for semi-automated one - i.e. having a script in path that can be called manually to perform the update. Not quite sure where should this live for now (getting back to this it surely is nixos-hardware in case of RPi or specific board support projects living outside of nixpkgs).

Now, all of that is thinking generally, this includes your boring standard Laptop UEFI firmware, and other spicier options.

I'm currently trying to do something similar for old Lenovo X200 running coreboot where the update mechanism is using flashrom :smiley: so I'll think about that some more for sure.

The overall way we should support such things is by supporting standard (enough) methods to update firmware. The example here is fwupd/LVFS.
About board-specific hacks and workarounds
It would be undesirable to add again specific patterns for a given board. Here the Raspberry Pi.
Like alluded to previously, we should aim to support "standard" methods to manage those bits. So no, we shouldn't add any at this point in time. The aim should be to, at some point, drop this, but it's not planned for the near future.

Completely agree although it seems hard to draw a line of what should be in nixpkgs and what should go to e.g. nixos-hardware. Like we can't drop raspberrypifw as sd-image builder depends on it. Reading the discourse post, I see where this goes and this also sounds to good to me (so not as hard after all!).
It is pretty weird that our multiplatform/generic images are at the same time RPi specific. I wouldn't go as far as removing SD card images and the tooling since it is very useful (and widely used I think) but removing RPi specifics from generic images is a good idea. We can do this in discrete steps

move the RPi specifics from generic images into RPi specific files
move these into nixos-hardware
drop (move into nixos-hardware) the rest of the RPi specific cruft like raspberrypifw, device-tree_rpi and RPi kernels
profit by not having to support (or explain to users why it is bad) all the weird mixtures of unsupported configurations like using mainline kernel with device-tree_rpi

As hinted previously (if you read between the lines) we should aim to support composing the "base" NixOS system on top of external projects (any one of them!) rather than pre-bake device-specific images.
This holds for all ecosystems, not specific to Raspberry Pi, nor for ARM.

:+1:
The situation with RPi is quite unfortunate and it shouldn't have a special treatment because of its popularity. The RPi foundation reinvented a lot stuff to make things seemingly more user friendly at the expanse of creating a massive confusion about how the things should be done (were done previously) in a standard manner (dtparams, GPIO, booting..).

About this particular example and the future
Things are in motion with Tow-Boot to make it well-supported generally with fwupd/LVFS.
This would include the Raspberry Pi family of devices, in the future.
So, one way to have this all work will be a future where NixOS has no knowledge of the Raspberry Pi firmware or that it needs to be updated, but instead relies on an external Platform Firmware provider, and then fwupd/LVFS to update the platform firmware, irrespective of the board. (But not limited to a specific one!)

Quite interesting and I certainly support your efforts and can possibly help with some stuff despite the fact I'm not really into UEFI  - I don't have single computer running UEFI at the moment as I don't see any advantage in doing so (no need for secure boot, only reason I found it interesting was that it would allow me running systemd-boot which would allow for bootcounting and automated rollbacks but even that seems possible with just uboot nowadays).
I'll soon get my hands on Pi5 and more Pi4s so I can try UEFI/Tow-Boot!

Alternatively, just updating the documentation/NixOS on RPi wiki would help (I can probably do something with that). But it would be good to settle on the desired way forward first.

That is more than welcome @SFrijters and I want to do the same after we figure out the way forward.

It is pretty weird that our multiplatform/generic images are at the same time RPi specific. I wouldn't go as far as removing SD card images and the tooling since it is very useful (and widely used I think) but removing RPi specifics from generic images is a good idea.

There is one main reason for this: it's because it is otherwise really inconvenient to add the Platform Firmware for the Raspberry Pi after the fact. Most other platforms, at worse, "just" look at specific offsets on the same storage device, so you can "just" splat the platform firmware there if you don't have better options... But the Raspberry Pi requires a "real" partition. So adding it after the fact requires steps that are way harder to get right.
But you're right, and this is where I want to go: Have it all be agnostic.
Though you might be thinking about it thinking that "we want a generic SD card image"... We might not (but still provide useful tooling for end-users).
The ideal solution here is to always rely on a "manual" install method to the target storage, rather than pre-baked filesystems, as those have various issues down the line. So the actual goal is to "stop providing generic SD images" altogether, and instead rely solely on generic standards-based boot methods, e.g. UEFI.
So the "ideal" (realistic) future for Raspberry Pi (and other platforms without dedicated storage for the platform firmware) would be:

Acquire a platform firmware [EDKII, Tow-Boot, U-Boot, unimportant]
Write SD card with that platform firmware
Write USB drive with UEFI iso
Boot with both inserted
Install to SD card taking care of leaving the platform firmware stuff intact

Now, that doesn't help for "large scale deployment of images", but this is the kind of problem that is not ARM-specific nor Raspberry Pi specific, and require better semantics around producing disk images within NixOS :).

There is one main reason for this: it's because it is otherwise really inconvenient to add the Platform Firmware for the Raspberry Pi after the fact. Most other platforms, at worse, "just" look at specific offsets on the same storage device, so you can "just" splat the platform firmware there if you don't have better options... But the Raspberry Pi requires a "real" partition. So adding it after the fact requires steps that are way harder to get right.

If the partition stays there (even if it's empty, which currently there's no way to disable it) than it is pretty easy to grab firmware (the mechanism provided in this PR makes it less troublesome) and add it to the image manually (mounting it after dding, losetup, guestfish..).
This only affects aarch64 image which is the only one currently built by Hydra I think and even that one is kind-of semi-official since it is only linked from nixos.wiki. Removal of the RPi specific firmware would make it a bit more inconvenient as you can't just grab an image built by Hydra and dd it to sdcard but you would need to perform additional step if you want to use it on RPi, which would cause some confusion for users used to the current method.
Shouldn't be a blocker but the failure mode is not ideal a la it was working before why it suddenly doesn't. So yes, I see why you would want to get rid of the image(s) entirely.

Now, that doesn't help for "large scale deployment of images", but this is the kind of problem that is not ARM-specific nor Raspberry Pi specific, and require better semantics around producing disk images within NixOS :).

There's another reason which is more important for me (I always build my own images anyway as I have many armv7l devices) and that is the ability to fully describe the working image using Nix. I just build the image, dd, put it in the device and call it a day. The specification is fully contained in Nix and doesn't require additional steps nor documentation.
I agree about better semantics and was wondering about that as well - the sdImage module is a bit weird since it is not included in NixOS modules by default (I've did that manually yesterday to test the generated documentation and deprecation message, but I've had to comment out fileSystems and boot.postBootCommands to not break the host).
I think we can use NixOS containers as an inspiration and have a similar mechanism - sdImage*s* that would allow configuring bunch of them and have them built on nixos-rebuild. Even if they are just a script that would spit out a path to the image (but it also opens up a possibility to have a flasher script and probably much more).
Now the interesting thing is - what about having all the things - sdImage, PXE, virtualization, deployment tools (nixops, Nixus, morph) integrated.. I've had this idea couple years ago - describe all your systems within one configuration and specify what backends you want for them. This would allow us to describe a system once and have all these goods available as simple knobs.
I wonder if there were prior efforts in this direction.

After further consideration I also don't think removing/moving any of the RPi packages from nixpkgs to nixos-hardware is a good idea

there are no guidelines for this
it would require consensus of all involved parties
nixos-hardware doesn't really have packages (although it has an overlay for device tree to use dtmerge which is perfectly fine and RPi specifics could be provided by that as well)

The device specific SD profiles seem easier to migrate.
I thought I should state this here so it doesn't look like some conspiracy discussed in unrelated PR.

Finally related to this PR

I've tested all the code paths by building x86 SD images (null is handled correctly, fails when the output is not a directory, copies the paths if it is).
Tested the deprecation message and generated documentation, it looks like this:

       - The option definition `sdImage.populateFirmwareCommands' in `/etc/nixos/machines/duck/configuration.nix' no longer has any effect; please remove it.
       Use sdImage.firmwarePartitionContents instead.

       For example, if your sdImage.populateFirmwareCommands were:

         ''
           cp ${pkgs.myBootLoader}/u-boot.bin firmware/
         ''

       You need to conver it to a derivation creating a directory:

         pkgs.runCommand "myFirmware" {} ''
           mkdir $out
           cp ${pkgs.myBootLoader}/u-boot.bin $out/
         ''

man:
       sdImage.firmwarePartitionContents
           Directory representing /boot/firmware partition on the SD image.

           Type: null or path

           Default: null

           Example:

               pkgs.runCommand "myFirmware" {} ''
                 mkdir $out
                 cp ${pkgs.myBootLoader}/u-boot.bin $out/
               ''

           Declared by:
               <nixpkgs/nixos/modules/sd-image-test.nix>

I have not tested on a real device (only with UbootQemuX86, since cross compilation is failing on systemd and I don't want to get into that right now.
Outstanding questions:

Do we want a changelog entry as well?
https://github.com/NixOS/nixpkgs/pull/261857/commits/33f9c8aaffdce5738eaf17403e974a915a81a3e6 changes semantics of couple of options which previously had undefined type into types.lines that allows merging these (prior to this they would fail if defined multiple times I think). It seems sensible to me to allow merging for them but PTAL

Now the interesting thing is - what about having all the things - sdImage, PXE, virtualization, deployment tools (nixops, Nixus, morph) integrated.. I've had this idea couple years ago - describe all your systems within one configuration and specify what backends you want for them. This would allow us to describe a system once and have all these goods available as simple knobs.

Realized that this can be probably already done by passing nixosConfigurations from flakes around.

Just FYI, I have now actually deployed the result of this derivation to my Pi and I'm now succesfully booting with U-Boot (and the device overlays that started the whole journey for me indeed work).
One more question though: nixos-init, kernel.img, initrd, cmdline.nix are files that are still sitting in my /boot and they are not included in this firmware, and they have not been updated by the system rebuild with boot.loader.generic-extlinux-compatible. Am I right in assuming these were only necessary for boot.loader.raspberryPiand they are now safe to remove? I see that different initrd and image files are referenced by/boot/extlinux/extlinux.conf` but I'm not sure what the other two do exactly.

Just FYI, I have now actually deployed the result of this derivation to my Pi and I'm now succesfully booting with U-Boot (and the device overlays that started the whole journey for me indeed work).

Cool!

One more question though: nixos-init, kernel.img, initrd, cmdline.nix are files that are still sitting in my /boot and they are not included in this firmware, and they have not been updated by the system rebuild with boot.loader.generic-extlinux-compatible (also a folder /boot/old). Am I right in assuming these were only necessary for boot.loader.raspberryPi and they are now safe to remove? I see that different initrd and image files are referenced by /boot/extlinux/extlinux.conf but I'm not sure what the other two do exactly.

Yes those are exactly the artifacts of the previous builder https://github.com/NixOS/nixpkgs/blob/03ed4abc345e78320d74da3208ba38f6f5243edb/nixos/modules/system/boot/loader/raspberrypi/raspberrypi-builder.sh#L79-L99 so safe to delete.  All that is now handled by uBoot which loads extlinux.conf

Rebased due to mdDoc removals


Click targets in flutter applications do not behave like those in other desktop applications

Steps to Reproduce
import 'package:flutter/material.dart';

void main() {
  runApp(
    MaterialApp(
      home: Scaffold(
        body: Builder(
          builder: (context) => ElevatedButton(
            onPressed: () {
              ScaffoldMessenger.of(context).showSnackBar(const SnackBar(content: Text('button pressed')));
            },
            child: const Text(
              'button',
            ),
          ),
        ),
      ),
    ),
  );
}

Click and hold on the button, move the cursor by a small distance, and release the button. The click will not be registered by the button. On every other desktop application, the click is registered as long as the mouse down and mouse up happened on the same element. It is very common for users to move the mouse a little when clicking on something and even a one pixel movement will make the click noop on flutter applications.
[✓] Flutter (Channel stable, 2.5.3, on Pop!_OS 21.04 5.13.0-7614-generic, locale en_US.UTF-8)
    • Flutter version 2.5.3 at /home/fctorial/Desktop/software/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 18116933e7 (2 weeks ago), 2021-10-15 10:46:35 -0700
    • Engine revision d3ea636dc5
    • Dart version 2.14.4

[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
    • Android SDK at /home/fctorial/Android/Sdk
    • Platform android-31, build-tools 31.0.0
    • Java binary at: /home/fctorial/.nix-profile/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.12+0-adhoc..source)
    • All Android licenses accepted.

[✓] Chrome - develop for the web
    • Chrome at google-chrome

[✓] Linux toolchain - develop for Linux desktop
    • Ubuntu clang version 12.0.0-3ubuntu1~21.04.2
    • cmake version 3.18.4
    • ninja version 1.10.1
    • pkg-config version 0.29.2

[!] Android Studio (not installed)
    • Android Studio not found; download from https://developer.android.com/studio/index.html
      (or visit https://flutter.dev/docs/get-started/install/linux#android-setup for detailed instructions).

[✓] IntelliJ IDEA Ultimate Edition (version 2021.2)
    • IntelliJ at /home/fctorial/Desktop/software/idea-IU-212.5284.40
    • Flutter plugin version 61.2.4
    • Dart plugin version 212.5486

[✓] Connected device (2 available)
    • Linux (desktop) • linux  • linux-x64      • Pop!_OS 21.04 5.13.0-7614-generic
    • Chrome (web)    • chrome • web-javascript • Google Chrome 95.0.4638.54

! Doctor found issues in 1 category.

@fctorial or @darshankawar can you provide some more detail about the current and expected behavior? If you can, a small video or gif of what you expect to see vs what you are seeing?
I suspect that the reason here is not that the movement causes it to be ignored, but the timing: it might be interpreted as a long click if you hold the button down, and if there's no long click handler on the button then it does nothing.
If that's the case, we should probably investigate what should happen in that case so as to still allow long click detection, but send a regular click if there's no long click handler (which is how I think it currently works, but I'm not sure).

We too have this issue. Any potential work arounds?


Timeframe >12 months?

My PSTN usage reports are exactly 12 months old - we've been using SfB and Teams for much longer. Is this a limitation, or is there a way to access older PSTN usage reports?

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

ID: 78ade1a4-092c-1132-44df-ee2c683fdd33
Version Independent ID: 396b1aee-2f40-9895-9b00-07e38d11d31b
Content: Microsoft Teams analytics and reporting - Microsoft Teams
Content Source: Teams/teams-analytics-and-reports/teams-reporting-reference.md
Service: msteams
GitHub Login: @LanaChin
Microsoft Alias: v-lanac

@BhaskinsWR Thank you for submitting feedback and contributing to the docs. We are currently investigating this.

Hi @BhaskinsWR, thank you for your feedback.
@LanaChin could you kindly help with this information? Thanks!

@LanaChin Following up on this issue. Could you please help us on this? thanks!

Any update? Need anything from me?
Bill Haskins
Wainhouse Research, LLC | Boulder, CO | USA
+1<PHONE_NUMBER>
email: bhaskins<EMAIL_ADDRESS>| web: www.wainhouse.comhttp://www.wainhouse.com/
[image001]https://insight.wainhouse.com/
From: Manuela Scanu<EMAIL_ADDRESS>Sent: Sunday, December 29, 2019 8:19 PM
To: MicrosoftDocs/OfficeDocs-SkypeForBusiness<EMAIL_ADDRESS>Cc: Bill Haskins<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [MicrosoftDocs/OfficeDocs-SkypeForBusiness] Timeframe >12 months? (#3436)
@LanaChinhttps://github.com/LanaChin Following up on this issue. Could you please help us on this? thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/OfficeDocs-SkypeForBusiness/issues/3436?email_source=notifications&email_token=ANZKLVMUVJGTPTH2E7J6743Q3FSC5A5CNFSM4JOGWXIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHZPOCQ#issuecomment-569571082, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANZKLVPRFWJGEQEQMEA5FM3Q3FSC5ANCNFSM4JOGWXIA.

@BhaskinsWR no thank you. We are trying to get this information from Product Group.

Thanks!
Bill Haskins
Wainhouse Research, LLC | Boulder, CO | USA
+1<PHONE_NUMBER>
email: bhaskins<EMAIL_ADDRESS>| web: www.wainhouse.comhttp://www.wainhouse.com/
[image001]https://insight.wainhouse.com/
From: Dario Woitasen<EMAIL_ADDRESS>Sent: Thursday, January 2, 2020 11:10 AM
To: MicrosoftDocs/OfficeDocs-SkypeForBusiness<EMAIL_ADDRESS>Cc: Bill Haskins<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [MicrosoftDocs/OfficeDocs-SkypeForBusiness] Timeframe >12 months? (#3436)
@BhaskinsWRhttps://github.com/BhaskinsWR no thank you. We are trying to get this information from Product Group.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/OfficeDocs-SkypeForBusiness/issues/3436?email_source=notifications&email_token=ANZKLVLJ3WMGPZ7NVVCEDSTQ3YUXZA5CNFSM4JOGWXIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH67IOQ#issuecomment-570291258, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANZKLVPI3YPXEFK3YAIYA6TQ3YUXZANCNFSM4JOGWXIA.

@BhaskinsWR  we don't store the data for more than 12 month. The reports also scrubbed (phone number obfuscated) after 30 days. This is to comply with regulations. If you need the reports for longer time, please download the reports. Sorry for inconvenience but this is the only way to comply with multiple regulations around the globe.

Thanks for the follow-up. Honestly the response is a little weird – I’d think this data should be managed by my O365 security and compliance settings, not system-level global regulatory requirements. Not your issue, and I appreciate the clarity.
Bill Haskins
Wainhouse Research, LLC | Boulder, CO | USA
desk: +1<PHONE_NUMBER>tel:+17203364966 | mobile: +1<PHONE_NUMBER>tel:+13039026861
email: bhaskins<EMAIL_ADDRESS>| web: www.wainhouse.comhttp://www.wainhouse.com/
[WROI]https://insight.wainhouse.com/Home/NewReports
From: Nikolay Muravlyannikov<EMAIL_ADDRESS>Sent: Sunday, February 2, 2020 1:54 PM
To: MicrosoftDocs/OfficeDocs-SkypeForBusiness<EMAIL_ADDRESS>Cc: Bill Haskins<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [MicrosoftDocs/OfficeDocs-SkypeForBusiness] Timeframe >12 months? (#3436)
@BhaskinsWRhttps://github.com/BhaskinsWR we don't store the data for more than 12 month. The reports also scrubbed (phone number obfuscated) after 30 days. This is to comply with regulations. If you need the reports for longer time, please download the reports. Sorry for inconvenience but this is the only way to comply with multiple regulations around the globe.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/OfficeDocs-SkypeForBusiness/issues/3436?email_source=notifications&email_token=ANZKLVMKPVZ4KF46J2VR24LRA4XFJA5CNFSM4JOGWXIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKSAWXI#issuecomment-581176157, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANZKLVLPCXBETQNEC3XS3PLRA4XFJANCNFSM4JOGWXIA.

Thank you @NMuravlyannikov. Closing this issue.

So just to be clear, we are able to check PSTN Usage reports for upto 12 months? Is there anyway to manage this retention period i.e. reduce it or is 12 months by default?
Many Thanks
John


CLA bot seems to be running against issue comments

Describe the bug
After making a comment on an issue on a repo with the CLA bot, it sent me an email that it had failed.
https://github.com/Roblox/testez/actions/runs/172094273
This did not stop me from commenting BTW.
Expected behavior
The CLA bot probably shouldn't run at all for issues and issue comments.

I believe you need to remove the [issue_comment] section in the script:
on:
  issue_comment:
    types: [created]

I believe you need to remove the [issue_comment] section in the script:
on:
  issue_comment:
    types: [created]


FR: option to disable notifications

When not wanting to use discord, it errors on a blank config, which I thought would be enough to disable.
`INFO[0000] Using config file: ./checkrr.yaml
INFO[0000] Sonarr integration not enabled. Files will not be fixed. (if you expected a no-op, this is fine)  Sonarr Connected=false Startup=true
INFO[0000] Radarr integration not enabled. Files will not be fixed. (if you expected a no-op, this is fine)  Radarr Connected=false Startup=true
INFO[0000] Lidarr integration not enabled. Files will not be fixed. (if you expected a no-op, this is fine)  Lidarr Connected=false Startup=true
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x758fe9]
goroutine 1 [running]:
github.com/aetaric/checkrr/check.(*Checkrr).connectNotifications(0xc000004280?)
/opt/radarrplugins/checkrr/check/checkrr.go:205 +0x89
github.com/aetaric/checkrr/check.(*Checkrr).Run(0xc000004280)
/opt/radarrplugins/checkrr/check/checkrr.go:60 +0x277
main.main()
/opt/radarrplugins/checkrr/main.go:86 +0x574
`

@mgaulton 2.0.1 is rolling out to fix this. Thanks for the heads up. Was missing a nil check.


int_jira__issue_calendar_spine performs slowly on snowflake

Is there an existing feature request for this?

[X] I have searched the existing issues

Describe the Feature
The model 'int_jira__issue_calendar_spine' is performing slowly on snowflake - taking about 10-15 minutes depending on the run.
Our instance has about 600M records for this table.
The query plans show that all records are being deleted/inserted for each run.
Should this be materialized as a table instead?
14:51:31  1455 of 1614 OK created sql incremental model AV_int_jira.int_jira__issue_calendar_spine  [SUCCESS 650585743 in 597.48s]
Shouldn't only a small % be loaded with incremental strategy not 99%?
Describe alternatives you've considered
Fork the repo and change myself ... but that requires upkeep :(
Are you interested in contributing this feature?

[X] Yes.
[ ] Yes, but I will need assistance and will schedule time during your office hours for guidance.
[ ] No.

Anything else?
No response

Hi @jschintz-windriver! Thanks for raising this and glad to take a look. I don't believe it should be behaving delete+insert if incremental. Can you share more info on your configs, version of the package, and specific warehouse you are using?

Hi @jschintz-windriver, just following up!

@fivetran-reneeli Sorry for the delay!
Some info about our deployment

dbt v 1.6X
snowflake warehouse
package: fivetran/jira version: 0.15.0

Thanks @jschintz-windriver!
I am wondering if there's something in your project yml that's overriding the config set in the model. Because given line 7, it shouldn't be exhibiting that behavior.
incremental_strategy = 'merge' if target.type not in ('snowflake', 'postgres', 'redshift') else 'delete+insert'
And this model should be materialized as incremental based on this line. So after your initial run, so you should see, for example this line of code compiling.
where cast( date_day as date) >= (select min(earliest_open_until_date) from
Would you be able to share your dbt_project.yml?

@fivetran-reneeli The icnremental logic is indeed compiling - I just don't think its performant for large databses.
I made a suggested change in my fork and opened a PR in your repo.
Do you see any issues with including this new logic?
It reduced the model load time from 10 minutes to 2 with our deployment.
https://github.com/fivetran/dbt_jira/pull/113

Hi @jschintz-windriver, our team looked into this, and can confirm we see the same long loading issue with the model. Thank you for opening the PR! When we went through this we saw some opportunities to make this more performant, but this will be helpful as a starting point as we tackle this.

@fivetran-reneeli Thanks so much for the update and taking the time to help us out.
Let me know if there's any testing on my part that could be useful.

Hi @jschintz-windriver I just wanted to reach back out and let you know this update is still on our roadmap. At the moment it is seeming like we will be able to pick this up and dive deeper in improving the model's performance after the holidays.
We will be sure to share more updates in this thread once we pick up this ticket.

Hello @jschintz-windriver! We wanted to let you know we've been working on a fix for this issue of slow runtime, and we believe we've made several optimizations to the dbt_jira models that should significantly improve performance on incremental runs. You can see the changes that were applied to these models here and an explanation for these changes in the CHANGELOG additions.
Can you test these changes on the following branch by attempting a dbt incremental run and see how your models perform and whether there are any issues? Once we get confirmation that this branch works for your purpose, we can get these changes merged into the package.
 - git: https://github.com/fivetran/dbt_jira.git
    revision: bugfix/optimize-calendar-spine
    warn-unpinned: false

Hi @jschintz-windriver ! Just bumping this back up for visibility. Can you test this branch when possible? We don't want to move forward with pushing this fix until we have validation that this is improving the performance of your calendar spine.


Add melt support when query-planning is enabled

Depends on https://github.com/dask/dask-expr/pull/1049

Can you add to the API docs as well?

thx