Have metrics disabled by default, or completely removed

You need to leave the metrics disabled by default and then at least ask users, first time they activate the editor, whether they would allow it to be enabled.
I for one will not allow spyware to run on my box, hence I disable or remove such applications, but Atom doesn't provide a clue in the application, so if someone haven't seen the FAQ, they don't know.
This is a problem because Atom is then collecting data WITHOUT consent, even if it is in the FAQ and even if the user has downloaded the application.
Besides, I find the whole concept of tracking users with the excuse of collecting useful data ridiculous!
In the entire history of Open Source this has never been needed and users are extremely helpful in sharing information, data, and reports about bugs, how they use the application, and other stuff.
The metrics package in Atom should to be removed from the default install, and then you can leave the package for anyone who want to install it by himself from the installation menu. Or as suggested, leave it OFF at first.
Another important point is that Atom is NOT simply collecting statistical data! If that where the case there certainly is no need to create a SHA1 of each installation MAC address. That is NOT collecting statistical data, that is specific and individual surveillance, which is unacceptable.

I guess putting a notice in Welcome.md might help, or do what lots of applications do on first startup: ask for permission (I'm guessing this is possible with Squirrel?).
About your point with 'this has never been needed':  There are currently 68 open issues with the more-information-needed tag (and that's not counting issues where it was removed after the needed info was added).  I'd guess at least half of the issues don't include the OS or Atom version, and half of the issues coming from Notifications don't include reproduction steps.

It should atleast be as "opt in", people need to make the choice when using the application the first time, and collecting SHA1 of MACs are unacceptable too! These can be reversed using rainbow tables.
Atom can generate a unique uuid on first time usage and use that instead!
And data, are they send encrypted? If not, they should be.
There's a whole bunch of problems with the approach of the metrics package.

This needs to be opt-in, not opt-out. This is a massive privacy issue otherwise.

Also relevant:
https://github.com/atom/metrics/issues/16#issuecomment-36307675

+1
Pretty sneaky "feature" that is well hidden in the Metrics package. Just respect your users and disable the package by default.

To help us improve Atom, we anonymously track usage metrics. See the atom/metrics package for details on what information is tracked and for instructions on how to disable it.

I don't believe "anonymously" is correct here: Google Analytics will get my IP number, and they likely save it. IPs are certainly personally identifiable information.
I'm also uneasy about using the MAC address for "anonymous" identification, as well as the fact that a desktop application is tracking my moves by default. Furthermore, the welcome notice text has really poor contrast on my screen.

Also, there is a more general issue open for this already:
https://github.com/atom/atom/issues/5669

So be it. There is a pretty good reason to keep data collection disabled. Big companies (like Google) have repeatedly abused consumer trust. Why should we allow this abuse?
Our data belongs to us. No one else and certainly not to the big privacy abusers.

I don't believe "anonymously" is correct here: Google Analytics will get my IP number, and they likely save it. IPs are certainly personally identifiable information.

Unless you have a way of systematically / categorically disabling Google (and Yandex and others) Analytics across the Internet, I assure you that some Google Analytics instance already has data based on your IP address.
I just want to reiterate that Atom's metrics code is completely open source, so you can see for yourself exactly what data is being collected, and you can always disable it as it's just another package.
From the Readme, this is what is being collected:

A unique identifier that is generated by computing the SHA-1 of the machine's MAC address.

The screen width and height
The version of Atom being used
The name of each item opened in a pane such as EditorView, SettingsView, and MarkdownPreviewView
Exception messages (without paths)
Commands run (save core commands)
The amount of time the current window was open for
The amount of time the current window took to load
The amount of time the app took to launch
Deprecations: package name and version of each deprecation

I've also opened a PR for a new cross-platform "About Atom" that reiterates the notice about metrics, so it can be more apparent after users dismiss the Welcome Guide.

@mnquintana, I do systematically disable as many third party trackers as possible, using both Ghostery and Noscript where possible.
I don't have a problem with Github knowing all of that, but I don't see why Google should. Why should Google even know which editor I'm using?
I appreciate that you're trying to inform about the tracking, but if possible I'd suggest linking to the package settings page (Settings>Packages>Metrics), where you could give the same information as on the web page, with the advantage of have the Disable button right there.

I was wondering where the metrics package was in my installation, but seems like the Webupd8 team already removed it! Great move I'd say.
https://launchpad.net/~webupd8team/+archive/ubuntu/atom
http://www.ubuntuupdates.org/package/atom/trusty/main/base/atom
(For anyone else wondering why they can't find the damned package.

I'd feel less creeped out by the metrics if you made the data you gathered available.  I was happy to participate in Debian's popcon because it's in the open and produced useful results.
I'm definitely not happy to participate in this though.  And I dislike that I'm obligated to mention it when recommending Atom to friends.  "Yes it's a great editor, but be careful: it sends data back to the mothership."

I'd second that notion.
@mnquintana Do you know whether the statistics gathered via the metrics package are going to be made publicly available somewhere?

This is outrageous. Such a sneaky move.

@alvarouc Let's not get our panties in a twist.
It's hardly outrageous or sneaky when it is clearly documented and shown to the user.
See this comment above and this screenshot as well.
The question at this point is rather whether the default assumption should be changed to an opt-in approach, or otherwise if the metrics package could be made more visible to people to make up their minds about disabling it or not from the beginning.

oh, there is this information - dark gray text on black background ... :unamused:
this must be opt-in with a clear yes/no popup

@uok disabling the package by default really isn't an option, like @batjko mentioned above:

To be sure, disabling the package by default is the same as decommissioning it entirely.
Very few people will make an effort to enable it, even if asked, which makes collecting statistics on a tiny minority all but useless.

You got to ask yourself WHY very few people would opt in.....
Disabling the metrics by default is actually a very good option, until a there is a more privacy friendly option around. Such as: Ditching Google, don't use MACs.

I'm not sure that Google being the middleman is the main gripe people have about this.
Rather, the entire notion of collecting information about their usage, no matter how anonymized it may be, has a bad connotation to them and of course not without good reason.
So any product engaging in such statistics gathering has a rather heavy burden of proof as to its benevolence, and even though I personally don't particularly care, perhaps the devs haven't taken that challenge seriously enough so far.
Some extra effort to increase transparency regarding the data being collected could go a long way to put people's minds at ease.

So, atom developers do not want to remove the metrics package as a default. Then lets generate more awareness of this issue.

So, atom developers do not want to remove the metrics package as a default.

I feel this statement, while strictly accurate, is potentially misleading. It is correct that the Atom team does not want to remove the metrics package from the default installation. Whether metrics are opt-in or opt-out is a separate issue from that.

Where do I opt out from metrics? The only place this info was found is the welcome panel. This info needs to be easier to find, whether it's opt-in or opt-out.

Where do I opt out from metrics?

See https://atom.io/packages/metrics:

If you do not want this information reported, you can disable this package. Open the Settings View by running the Settings View: Open command from the Command Palette, go to the Packages section, and then find and disable the Metrics package.

Cool. Really glad to see this is on the Quality Initiative roadmap and will be improved upon in near future :+1:

just installed atom yesterday and it looks quite nice. I know it is free and no one forces me to use it - so I understand that the coders can do whatever they like BUT
The issue of default packages like:

metrics:  Reports usage information to Google Analytics
exception-reporting:  Reports uncaught Atom exceptions to bugsnag.com
and who knows what else?  just installed it yesterday

is a bit of an turn of for some users like myself.
Just wanted to give a feedback of a maybe new user for the
The Quality Initiative #7995

@peter1000 As you can see from all the above, these points have been made very clearly and I'm pretty sure the focus in the future will be to raise awareness of these packages in the first instance.
Let's see what the quality initiative comes up with first of all.

The problem is not awareness, the problem is how to opt out of exception reporting, for instance.

@Zireael07 That's a different question though. This issue was about the metrics package and the opt-out of that has been made clear.
So the remaining question is whether this has to be made even clearer.
If you're worried about exception-reporting to bugsnag, I'd recommend opening a new issue on that one (if there isn't one already).

@batjko I think metrics and exception-reporting can share this issue since the way to disable them is the same.

In which case the title should probably be changed.
On Tue, Aug 4, 2015, 14:19 Wliu<EMAIL_ADDRESS>wrote:

@batjko https://github.com/batjko I think metrics and
exception-reporting can share this issue since the way to disable them is
the same.
—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/4966#issuecomment-127605932.

At our university we've had a few request for Atom, we aren't able to let users install this or install it on lab machines unless we can disable the gathering of metrics completely when we install. We also must prevent users from ever turning it on. The risk of exposing HIPA and FERPA types of data is too high. There are too few details listed on the Git repository for the Metrics package. What is reporting of "Commands run"? Is this essentially my .bash_histroy? If so you may be collecting mistyped passwords and lots of path information. By Reporting the name of each open pane what is being reported. Is this going to report the full path of a file I might have open? The description of exactly what data is being collected is very lacking. Allowing users to send current config data when reporting an issue would be acceptable but blindly accepting constant reporting is not acceptable.

What is reporting of "Commands run"? Is this essentially my .bash_histroy?

No no. It is reporting atom commands run. Like tree-view:toggle and things like that.

By Reporting the name of each open pane what is being reported. Is this going to report the full path of a file I might have open?

It reports the type of pane. So an open file reports TextEditorView, and a project search result tab reports ResultsPaneView.

Unable to disable metrics due to crashes in settings view :(

In Europe it may be illegal, the law says that before collecting user data, you must first get the consent. It is not enough to opt-out.
It was not even aware that they were collecting data, investigating another package that made him I've noticed.
I'm sad that the world of developers there is no respect for the privacy of others.

Just offer a simple and convenient way that works to disable it (in general and in future versions of Atom too). While I agree that privacy is an important issue, it seems to recieve too much attention compared to other things (such as being able to easily write/share/publish) code.
One comment about the "From the Readme, this is what is being collected"
Some people never read readmes (I am guilty of that as well, in many cases), so it would be useful/helpful if there are additional notifications or popups in the preference section setter dialogue, or a link to the part where this is documented. Should be trivial thanks to github since we can anchor line-tags too.

First of all, almost ALL applications that want to collect metrics ask the users FIRST if they want these metrics to be collected or not: a simple pop up the first time you start the app with a clear Yes/No.
Second, in Europe it is illegal to collect users metrics without user consent.
Last but not least: instead of apologizing you pretend to be right!

Since it is impossible to make them understand that they must respect the privacy, it is best to add to /etc/hosts
<IP_ADDRESS> www.google-analytics.com
<IP_ADDRESS> google-analytics.com
<IP_ADDRESS> ssl.google-analytics.com
You can get a full list here:
http://pgl.yoyo.org/adservers/
And ultimately completely uninstall Atom.

@FranBar  Leaving your unnecessarily passive-aggressive tone aside... As mentioned many times on this issue and the welcome screen in the application, one can simply disable the package in question and be done with it.
No need to mess with your hosts file, or insult the developers.

@batjko But isn't the whole point of this is that it shouldn't need be disabled in the first place?

Yes, the villain of this film I am :-)

By the moment you decide to disable it, atom already took your mac address
and god knows what else
On Nov 5, 2015 7:14 AM, "FranBar"<EMAIL_ADDRESS>wrote:

Yes, the villain of this film I am :-)
—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/4966#issuecomment-154069079.

I wonder how this matter can even be questionable... In a lot of countries (for example in all the European ones), this is illegal. So there is simply no question, it's a violation of users privacy and must be removed. Cheers.

atom already took your mac address
and god knows what else

Atom no longer "takes" your MAC address in v1.1.0.  In fact, metrics never even stored it (it encrypted it first), but now you can be extra-confident that it doesn't.  As for what else, you can view all the types of info that it collects here.

Just ask for the damn permissions. So it is neither opt-in nor opt-out.

@FranBar Honestly?
But I respect that most people are very much concerned about it. All I am saying is that, as long as people are made aware of this package existing (and what info it collects) when they first install or use the product, and are given the option to not be subject to that data collection, then it's become much much less of a real problem than overly excitable people want to keep believing it is.
Let's level here... we're talking about intelligent people, mostly developers, arguably the most tech-aware type of human being that walks the earth!  And you're seriously telling me that these people either can't be trusted to (or are utterly unable) to read the introduction text on a welcome page and make up their own minds what to do about it? Gimme a break.
This sanctimonious fake-outrage about something this minor is bordering on trolling my my eyes.
Having said that, though... If it's true that the data collection - as it is being done by the metrics package right now (!) - is illegal in some places (and I am not convinced until someone can point out exactly which part of it makes it so), then it is best to remove it (since the alternative, an opt-in model, would render it completely useless as I mentioned earlier).
Not because it's truly morally necessary (it isn't), but because it's common sense to not break the law.

@batjko If deep down you think the same...

@batjko hi, excuse me a question, but why an opt-in would make it useless if it is what all the other companies are doing?
About the legal thing, I will ask to a friend of mine (who is a lawyer) to give me a source of this. I'm an engineer, not a lawyer, but it's perfectly legit that you ask for a source of this, so I will get it as soon as possible.
About trust and data collection: some people may be ok with giving the data to "you" (GitHub), but may not be ok to give it to Google (after all the data pass from them first, then it goes to you).
FYI in Europe there is also (and it's very annoying, being applied to every website) a law that oblige every website to show the message "This website contains cookies and may collect stats etc...", so the situation is exactly the same.

European law:
http://ec.europa.eu/justice/data-protection/data-collection/index_en.htm
Github agrees to do it, so can a lawsuit:
"EU and Swiss Safe Harbor
... we have committed to cooperate with data protection authorities located within Switzerland or the European Union ..."
https://help.github.com/articles/github-privacy-policy/

This example of what makes Netbeans comply with European legislation:
Before:

After:

Finally it should be clearly informed what information is being collected:
http://netbeans.org/about/usage-tracking.html

This example is like my current editor (kdevelop) respects the privacy:
...
Nothing! no external connection at all!
:-)

but why an opt-in would make it useless if it is what all the other companies are doing?

Squirrel does not have an installer GUI, so no checkboxes during installation.  Currently there's no way to toggle settings from URIs (such as the atom:// handler), so the only way to manually enable metrics if it were disabled by default would be to click on the "Metrics" link on the Welcome page (provided they read it - as is evident further up in this issue not many people bother to read the Welcome page) and then enable it.  This is arguably exactly what people who want to disable metrics are doing, but bear in mind those who want to disable metrics usually are a lot more proactive and willing to go through whatever it takes then those who don't care either way.

bear in mind those who want to disable metrics usually are a lot more proactive and willing to go through whatever it takes then those who don't care either way.

So that's a reason for making it opt-out?  That's...  disturbing.
I hope the Atom team is making a lot of money off these metrics because it's scaring potential users away.

@andreagrandi The reason opt-in would become fairly useless, if not totally, is that most people wouldn't bother actively enabling it, even if just out of pure laziness.
So those users who do, will be only a tiny proportion of the whole user base, and thus the information you get from it, is merely anecdotal (which could be useful to some extent, granted). In other words: If the devs are after truly representative information about their users, this wouldn't give it to them.
Btw, I'm not sure the cookies law applies here (I'm based in England, I get harassed by that stupidity of a law several times a day).
But I see your point in terms of it being similar and something of a guideline to what European laws expect of product developers.
@FranBar Thanks for the links.
The first page talks about rights and duties regarding the collection of "personal data", referring for details to the Data Protection Directive. Now, I have not yet read the whole thing, but maybe you know: Does it include a definition of what personal data legally includes?
And do your Atom screen width and recent exception messages get mentioned?

Yes, the IP is a private data, whatever is in my computer is private. In fact simply using Google Analytic is regulated in the EU and requires prior consent.

Everyone, I think this is getting out of hand. It is going around in circles and I don't believe the two camps are in any danger of shifting their positions on this. A few things:

I, and I believe everyone else here, respect people's choice to disable the metrics package or simply uninstall Atom altogether. Everyone has to make a decision as to how best to protect their own privacy.
Regarding whether or not things are illegal, I don't believe anyone involved in the discussion is a lawyer in any jurisdiction. I'm certain that GitHub, on the other hand, has a legal department that could advise or has already advised them on what the actual boundaries are. So let's leave the law to the lawyers.
I would encourage everyone here to refer to the Code of Conduct because I personally feel that the comments here are coming close to the "insulting/derogatory comments" clause under the Code. I want to leave this Issue open to comments but only if it will result in civil and constructive discussion ... not back and forth that will only end in name-calling.

Thanks for listening and being passionate about Atom.

In your country may be not, but in Europe it is illegal with absolute certainty.
And I have not insulted anyone at all.

In your country may be not, but in Europe it is illegal with absolute certainty.

Again, let's leave this to Github's legal department.

And I have not insulted anyone at all.

No one's saying you have...just that the general direction of the discussion was getting close to it.

@50Wliu  I say this clearly @batjko. Now @lee-Dohm again emphasizes the issue of insult, I ignored it the first time.

@lee-dohm you're saying GitHub's lawyers have looked at the issue and decided it's legal in Europe?

@bronson, I was very careful in my wording:

GitHub ... has a legal department that could advise or has already advised them

Disclaimer: I am not an employee of GitHub nor a member of the Atom Core team. I'm just an enthusiastic volunteer.

@bronson Please re-read what @lee-dohm wrote;

[..] I'm certain that GitHub, on the other hand, has a legal department that could advise or has already advised them on what the actual boundaries are. So let's leave the law to the lawyers. [..]

He did not claim any such thing.

Gotcha.  But why bring them into the discussion if they're not actually being used?

Moreover you will understand that everything that affects freedoms (civil rights) make these debates are heated.
Not the same discuss whether the code should be more clear that fast, that they are doing do it on my privacy.

Is it true that anyone, expecially a developer, can always disable it if he/she wants, but I see two issues:

How is someone supposed to know about this "Metrics" package? I've been using Atom since January 2015 and I only knew about this matter a few days ago thanks to a friend of mine who tweeted about it.

Disabling the package after is too late, because it will have already transmitted user data.

I really hope this conversation remains constructive until the issue is resolved, and I hope Atom developers will be able to escalate the problem to the right department.
 You are doing an amazing job with Atom and I thank you for this, but users privacy matters too and I would expect you to have respect for it.
Thanks

But why bring them into the discussion if they're not actually being used?

Nobody here is:

A lawyer of any kind
Knows whether or not the lawyers have already been consulted

So there is no point in any of us discussing something so contentious which we are not qualified to answer definitively.

You are doing an amazing job with Atom and I thank you for this, but users privacy matters too and I would expect you to have respect for it.

Thank you. Yes, we all agree that user's privacy matters and that it should be respected. We are disagreeing on how "respect" should be built into the product.

How is someone supposed to know about this "Metrics" package? I've been using Atom since January 2015 and I only knew about this matter a few days ago thanks to a friend of mine who tweeted about it.

There's a notice shown on the initial Welcome screen (you can see an image of it in one of the first posts).

@lee-dohm a disagreement is not a problem, you can't make everyone happy :)
What you (I'm assuming you work for GitHub, if not, I speak to anyone here who does) could do is:

escalate this to the GitHub legal department
explain them our concerns and double check what is and what is not legal

If it's not 100% legal, please implement an opt-in, if it is... well, at that point is up to you.
After this, whatever is the response from legal department, please publish a statement where you explain/clarify your (GitHub) position about this.
Does this sound reasonable to you?
Cheers

@50Wliu I honestly didn't see that, or I would have disabled it a long time ago. I'm not a UI/UX expert, but maybe a dark gray color on a nearly black background doesn't make it easy to read it.

I'm assuming you work for GitHub

As I stated above, I don't work for GitHub (nor does anyone with the "Collaborator" tag on their posts, to my understanding).

Ok, I "may" know someone who works at GitHub then :)
I won't name him here, but I will contact him personally and see what we can do all together. Thanks

We appreciate your passion and feedback. We are consulting the legal department over the concerns raised here and are determining what action to take to address the opt-in/opt-out concerns.

That's great news @benogle.
Just a personal note: I've contributed to Atom and have recommended it to coworkers but I'm really discouraged that this is still an issue in 1.1.  I expect to warn friends about Windows 10, Zynga, and AdMob's applications, not GitHub's.
One day either this issue will be closed WONTFIX, or GitHub will become proactive and transparent about its metadata collecting.  Really hoping for the latter.
Until then, maybe the Atom team could produce a blog post analyzing the metrics it has collected?  I'm really interested to hear the sorts of decisions that it's influencing.

@batjko Who cares if it becomes useless though? The (core/official) developers will be sad that they get less or negligible usage statistics, so? What, will the quality/development of atom severely degrade because of the lack of usage statistics? At least it would then be opt-in, which imo should be considered more important than being able to get metrics, don't you think?

@vyp Well, since we're using a very useful product for free, and get constantly ongoing improvement being developed for it by the core devs, it's not wrong to care whether those devs get supported in their efforts, be it by allowing them to collect some data or otherwise.
As I mentioned above, personally I don't care about the data that the metrics package collects, as it's really minor stuff, and so I have no problem offering it up. So who cares? I kinda do.
But is it a problem if you don't? Not really. Especially if you contribute in other ways, no one can fault you for also offering constructive criticism. That's important, too.

As I mentioned above, personally I don't care about the data that the metrics package collects, as it's really minor stuff [...]

This must have been gone over before.. but:
https://github.com/atom/metrics#collected-data

A unique UUID v4 random identifier is generated according to [RFC4122][RFC4122]
The screen width and height
The version of Atom being used
The name of each view class or atom configuration file opened in a pane, e.g. EditorView, SettingsView,
MarkdownPreviewView, and UserKeymap. No other pane item information is collected.
Exception messages (without paths)
Commands run (save core commands)
The amount of time the current window was open for
The amount of time the current window took to load
The amount of time the app took to launch
The app's release channel (stable, beta, dev)
Deprecations: package name and version of each deprecation

That is.. extraordinarily minor. Atom has even taken the time to sanitize exception messages (by removing paths). Microsoft collects more. Ubuntu collects more. Almost every website collects more.
If it were me.. I'd collect a lot more:

Properties of each file opened: file type, size, number of lines, longest line, time to open, time to save
A ping to track active usage and how long that looks like
Properties of each "ctrl-p" search result: number of results, time to search, length of search term, position of file in list chosen
Properties of each "find" search result: number of files in results, number of results, time to search, length of search term, number of results visited.
Name and version of each package used (and if its disabled)
Number of windows opened
How long a window is open for before it is closed (more of active usage)
How long a window is idle for (more of active usage)

@batjko Well yes I can definitely see why people would choose to turn it on to help the core developers. Being opt-in is not at odds with because such users can just, opt-in. Basically my view is the ideal of nothing should be phoning home by default. Yes it's great that it's free (for whatever definition of free you mean, gratis or libre), but that still doesn't excuse it collecting usage info by default. As in, it doesn't make it 'perfect' for my 'ideals', and I want to it to be 'perfect', because why not? Or rather, what are the developers really missing out on if it becomes opt-in? If it's just these metrics, then really they should be, in my opinion, making it opt-in because they don't risk 'scaring off' users, and thus potential contributors. (Because you know, how are these metrics really useful to atom?)
But I think the only way they can 'justify' keeping it opt-out is if Google is paying them a significant enough amount of money to keep it opt-out (because obviously google knows that making it opt-in will potentially make it useless as you say). Because that way if they make it opt-in, they lose money, meaning atom will have less manpower/developers working on it, potentially causing its development to deteriorate. (My personal opinion would be that that doesn't matter since it's free software anyway so the community can keep it going, but I can still understand justifying keeping it opt-out because of money.)
But if you just don't agree with my ideal that nothing should be phoning home by default, then I guess we'll have to agree to disagree and leave it at that.
@mehcode

That is.. extraordinarily minor. Atom has even taken the time to sanitize exception messages (by removing paths). Microsoft collects more. Ubuntu collects more. Almost every website collects more.

I don't think this is right. Just because they do "wrong" (in my opinion) things more, doesn't excuse another entity from doing "wrong" things less...
Okay, Microsoft collects more, great, but what about those who don't use Windows, then that's a moot point for them. Same with Ubuntu. Yes basically every website engages in 'tracking', but really atom is the only editor I've heard that engages in tracking usage stats by default (so far). Maybe there are more editors that do this which I haven't heard of, but I certainly don't think it is the norm, is it?

Do not forget:
https://github.com/atom/exception-reporting
It does not inform the user at all.

While lawyers give their benedict, use common sense.
Wikipedia talk about metrics:
https://en.wikipedia.org/wiki/Atom_(text_editor)
The community talk about metrics:
(Is only one example, much more in google)
https://aur4.archlinux.org/packages/atom-editor/
Package teams, removes metrics and exception-reporting:
https://launchpad.net/~webupd8team/+archive/ubuntu/atom/+sourcepub/5647473/+listing-archive-extra
To find out what users are saying, metrics are not required, you only have to go to:
https://github.com/atom/atom/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-desc
to realize that is one of the most contentious issues

@FranBar Looks to me like it does:
https://github.com/atom/exception-reporting/blob/master/lib/reporter.coffee#L130-L133
I think all the valid points on both sides have been well made by now.
In the end, as @lee-dohm and @benogle mentioned, it is up to Github and their legal team to provide the legal guidance, on the basis of which the developers can decide to take further steps one way or another.

Btw, for anyone reading who really wants this to be disabled by default before installing, you could theoretically just maintain a .patch file, and apply the patch before building and installing, assuming it's as simple as flipping an option/switch (I don't know). Chances are that other people already do this (I don't know again), or if distributions like Debian package atom, chances are they have patched atom to stop this by default. Of course, that doesn't solve this issue, but there's nothing more anyone can do (I think) if Github chooses to keep it opt-out, except for just completely not using atom of course.

Saying that everyone collects your data is like saying everyone likes to
steal so we do the same
On Fri, Nov 6, 2015 at 5:17 AM, vyp<EMAIL_ADDRESS>wrote:

Btw, for anyone reading who really wants this to be disabled by default
before installing, you could theoretically just maintain a .patch file,
and apply the patch before building and installing, assuming it's as simple
as flipping an option/switch (I don't know). Chances are that other people
already do this (I don't know again), or if distributions like Debian
package atom, chances are they have patched atom to stop this by default.
Of course, that doesn't solve this issue, but there's nothing more anyone
can do (I think) if Github chooses to keep it opt-out, except for just
completely not using atom of course.
—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/4966#issuecomment-154395562.

Yes basically every website engages in 'tracking', but really atom is the only editor I've heard that engages in tracking usage stats by default (so far). Maybe there are more editors that do this which I haven't heard of, but I certainly don't think it is the norm, is it?

Is there a difference between an editor and a website? Does it matter? This is a strange argument.
Basically every website engages in "tracking" for the sole purpose of informing marketing (and often support).  Atom is tracking anonymized data for the sole purpose of understanding how you use the editor in order to improve it. This information is worth far, far more than charging for the editor. It helps drive development and inform support.

Saying that everyone collects your data is like saying everyone likes to steal so we do the same

What I'm attempting to say is that Atom collects anonymized data for a purpose. It's far different from stealing.. Are you missing any possessions afterwords?

What I'm attempting to say is that Atom collects anonymized data for a

purpose. It's far different from stealing.. Are you missing any possessions
afterwords?

I am missing my privacy and freedom

—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/4966#issuecomment-154477245.

@mehcode

Is there a difference between an editor and a website? Does it matter? This is a strange argument.

Yes. Maybe this is getting blurred with in-browser editors these days, but disregarding that, there is a difference between websites tracking your website visits and editors reporting on what you're doing in the editor.

It's far different from stealing.. Are you missing any possessions afterwords?

Missing the point, it's not that getting usage stats is stealing, it's that it is a 'bad' thing to do (by default), and other people doing bad things does not excuse us from doing bad things as well. So say if they are groups of bad people who actively engage in killing the innocent, it doesn't give us an excuse to kill only a few innocent, saying "oh well, all these other groups do a lot worse than us, so it's not that bad!". But really the point should be that killing even one innocent person is bad, so it's still not okay to do it. Yes, obviously tracking usage statistics is not the same as murder, I'm not saying it is.
So yes, to agree with this view, you have to agree that phoning home by default is a fundamentally 'bad' thing to do to others. Maybe getting paid a lot of money (by google) justifies this for atom, which I still may not agree with but at least I can understand where they're coming from. But I don't understand keeping it opt-out if that isn't the case, because it doesn't seem like usage statistics alone are all that useful (as in worth it to risk scaring off potential users, and thus contributors). Maybe I'm wrong about that though.

+1

This is not how open software is suppose to be.  Maybe you need to talk to Mozilla on how to do things correctly.  You need to at least prompt the user and inform them you are phoning home for any reason.

@mnquintana  A way to disable tracking exists it is called Ghostery in Firefox browser.  You can also block certain DNS entries.

This really should be a community driven effort to engineer a high conversion rate opt-in experience. There's some resistance, such as there's no good place to put that opt-in, and the quality of statistics.  We should replace the complains with an effort to solve the problem of knowledge based improvement of atom editor in a privacy respecting manners.

For example there can be a "Help us improve Atom" notification with the opt-in check box.
That notification can appears at first start and a few key moment like on errors, install of new packages and updates. Notification would state it send a bit of information from the past too, that way maybe we can rebuild the error.
I'm OK with HelpUs notification being a bit naggy. Small nag is far ahead silent data capture without consent. (And it may not be the case, the emotional reaction is no different) Disabling metric package could kill the nags.

As far as the legal side is concerned, the legal team will have the last word.

But my intuition is this: see all those websites that say "This website use cookies, by using this website you agree to the privacy policy". So basically as long as it is obvious enougth, using the product can be an opt-in agreement. Don't want the cookie ? don't use the website.  Compared to that, opt-out while being able to use the product is an privacy improvement. Opt-in using a checkbox would be even better.

In case anyone still doubts the legality of collecting "anonymous" data in Europe:
http://www.bbc.com/news/technology-34765937

@FranBar And most website deel with this the following way: A large bar at the top that say, this site use cookies, by using the site you agree to the privacy policy.
No cookie, no website.
Using the site = opt-in, not using it = opt out.
So atom position is at least as good as that. If it's not it would simply be a question of making the thing more visible.

@jeancroy it's hard for me to interpret...  Are you saying that Atom should have a large bar at the top talking about data collection?

What i'm saying is that an opt-in process does not HAVE to be a check box.
It can be anything as long as it's clear enough.
Using the product can be treated as an opt-in process for the law.
Now the definition of clear enough is a bit unclear, but for website it looks like top bar is a norm.

The point is that before obtaining permission, you can not send cookies, store data, collect information, etc. let alone if they are "anonymous", supposedly registered users gave permission on register.
European law clearly says "unambiguously given his or her consent", any system that meets this requirement serves, simply indicate this on the privacy page do not comply.

Yeah if plenty of user feel cheated when discovering this, it may not be "unambiguous" enough.

Identifiers "anonymous" (is evil), imagine a user in a search engine.
Day 1, the user searches for "politically incorrect term 1" The search engine creates an identifier "anonymous10001" and send a cookie.
Day 2, the user searches for "politically incorrect term 2" search engine already knows is "anonymous10001"
Day 3, the user decides to register a search engine service, by the cookie is known to be "anonymous10001" so the record can be stored like this:
User = "John Doe"
Interests = "politically incorrect term 1", "politically incorrect term 2"
Same for anything other than a search engine and send some kind of identifier.

Even if true in principle, thing like startup time and commands that
occurred before an error, don't really fall into your political example.
On Fri, Nov 13, 2015, 11:09 FranBar<EMAIL_ADDRESS>wrote:

Identifiers "anonymous" (is evil), imagine a user in a search engine.
Day 1, the user searches for "politically incorrect term 1" The search
engine creates an identifier "anonymous10001" and send a cookie.
Day 2, the user searches for "politically incorrect term 2" search engine
already knows is "anonymous10001"
Day 3, the user decides to register a search engine service, by the cookie
is known to be "anonymous10001" so the record can be stored like this:
User = "John Doe"
Interests = "politically incorrect term 1", "politically incorrect term 2"
Same for anything other than a search engine and send some kind of
identifier.
—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/4966#issuecomment-156475068.

@FranBar, as I stated before, we are going to leave the law to the lawyers. We've gotten plenty of feedback on this issue. Everyone has had a chance to make their case. GitHub is talking to their legal department (who are qualified to talk about the law). If this devolves into discussion about the law again, I am going to lock the comments.

@lee-dohm No, you're wrong, I can speak perfectly on any subject that I know the law or another, I understand that you may not.

Thanks everyone for your passion and feedback. Please subscribe to this issue for further updates.

We have talked to our lawyers. The plan is currently to add in a notification of some kind with a one click metrics disable. Metrics will not be sent to analytics until the notification is dismissed. Timeline is uncertain as we are nearing the holidays and many people are out, but it is near the top of our list.

Pull request for opt-in telemetry is now open at https://github.com/atom/atom/pull/12281

#12281 and related PRs have been merged.  At the current pace of development metrics should be disabled by default starting in Atom 1.11.0.


[Bug]: Unable to migrate already created widget between launchers

Describe the problem

Create "Photos" source widget. For example, I picked marked as "Favorites" photos from "Google Photos" through the DocumentUI file picker, then app was downloading those photos for quite some time. Now it appears that the photos stored in app's cache after downloading and the widget is saved in "My widgets" bottom tab, so there shouldn't be any problem adding the same widget to a different launcher, but:

After changing home launcher, and trying to re-add that same widget using the app ("Edit" or "Duplicate" widget and then "Add to home screen"), is shows as empty widget with red "missing file" icon on a home screen (see screenshot)

Device model
Redmi Note 10 Pro
Android version
Android 13 QPR3, Custom ROM
App version
1.16.2
Additional information

I use Lawnchair 14 launcher just moved to a different version (Lawnchair 14 Beta 2 to 14 Beta 3 Play Store) instead, so wanted to migrate the widget instead of just redownloading it all over again. Hope anything could be done to resolve this issue

Hi @Username1-a, thanks for reporting this issue. The details provided should help with trying to reproduce the issue on my end to fix it. I'll get back to you once I have more information.

@Username1-a after a brief investigation, it seems that there's a problem with the "Duplicate" function overall, and it's not related to the launcher migration. I'll have it patched in the next release which should be coming out soon.


relocate /var/lib/hyper to a zfs

How to relocate /var/lib/hyper directory to somewhere else by changing hyper configuration without symlinking (ln -s /tank/HYPER /var/lib/hyper)?

https://github.com/hyperhq/hyper/blob/master/package/dist/etc/hyper/config#L3-L4

@laijs Thanks for the useful pointer.

After changing the Root= parameter to the new location hyperd service did not get killed:
# /etc/init.d/hyperd status
 * hyperd is running
# service hyperd stop
 * Stopping hyperd: hyperd                                                                                [ OK ]
# service hyperd status
 * hyperd is running
# killall hyperd
hyperd: no process found

Is /mnt/tank/HYPER/ a fresh new (empty) dir when the config is being changed?
What's the behavior of the same operations for the recent hyperd/hyperctl?

Is /mnt/tank/HYPER/ a fresh new (empty) dir when the config is being changed?

Nope I stopped the hyperd service, copied all from /var/lib/hyper /mnt/tank/HYPER with all acl's saved with -a, and made changes to the config file accordingly and restarted the hyperd daemon.
What's the behavior of the same operations for the recent hyperd/hyperctl?
# hyperctl list
hyperctl ERROR: An error occurred trying to connect: Get http://%2Fvar%2Frun%2Fhyper.sock/v0.5.0/list?item=pod: dial unix /var/run/hyper.sock: connect: no such file or directory

You can find why the hyperd exit from the log /var/log/hyper/hyperd.INFO /var/log/hyper/hyperd.ERROR.
The Root directory should be empty (except the kernel, hyper-initrd etc) when the first time it is relocated.

@laijs I know this is an old thread but I am new and get the same error when I run hyperctl info:
hyperctl ERROR: An error occurred trying to connect: Get http://%2Fvar%2Frun%2Fhyper.sock/v0.8.1/list?item=pod: dial unix /var/run/hyper.sock: connect: no such file or directory
and here is the log as you suggested:
Log file created at: 2017/06/24 20:57:49
Running on machine: localhost
Binary: Built with gc go1.8.3 for linux/amd64
Log line format: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg
I0624 20:57:49.122851   18247 config.go:38] config file: %!(EXTRA string=/etc/hyper/config)
I0624 20:57:49.123234   18247 config.go:72] [/etc/hyper/config] config items: &types.HyperConfig{ConfigFile:"/etc/hyper/config", Root:"/var/lib/hyper", Host:"", GRPCHost:"", StorageDriver:"", VmFactoryPolicy:"", Driver:"qemu", Kernel:"/var/lib/hyper/kernel", Initrd:"/var/lib/hyper/hyper-initrd.img", Bridge:"", BridgeIP:"", DisableIptables:false, EnableVsock:true, DefaultLog:"", DefaultLogOpt:map[string]string{}, logPrefix:"[/etc/hyper/config] "}
I0624 20:57:55.170355   18247 daemon.go:215] The hypervisor's driver is qemu
I0624 20:57:56.299793   18247 migration.go:23] Migrate lagecy persistent pod data, found: 0, migrated: 0
I0624 20:57:56.310088   18247 hyperd.go:189] Hyper daemon: 0.8.1 v0.4.0-912-g7a07c71
I0624 20:58:37.811799   18247 daemon.go:357] The daemon will be shutdown
I0624 20:58:37.811826   18247 daemon.go:358] Shutdown all VMs

@bruceherve looks the daemon is shutdown before you run hyperctl info
I0624 20:58:37.811799 18247 daemon.go:357] The daemon will be shutdown

And you may open new issue if you find any issues.


Add support for load cell / weight sensors

Currently, there is no support for Load cell or weight sensors in the Sensor type and standardized SI values. Is there a plan to add support or open to contributing to add support?
I am looking to add support for NAU7802 to wippersnapper

Open to contributions and pull requests, feel free to tag me!

Leaving this open for revisiting as we add the HX711 in the near distant future.
Currently we are adding the NAU7802, but there is not yet the ability to set gain, or zero offset (TARE), or calibration offset, so those features would be required before some SI units could be utilised.
There was a discussion when adding the NAU7802 about having a raw force unit, https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/pull/577#discussion_r1581259960
but not sure if that's better than just a unitless_float type that would encompass non SI things.


iOS: Move to iOS standard pull-to-refresh

The old pull to refresh is broken on iOS 10.

Hey David, any chance we could get this in this week? iOS 10 drops today and I'd love to get this one fixed.

Yes, since it's urgent I should be able to do that today.

Sweet, thanks for the prompt fix!

This is still somewhat broken; the behavior of the pull-to-refresh is not standard as the spinner disappears immediately instead of sticking around until the refresh completes, which makes me wonder if it worked (I'm not used to looking down at the bottom of the screen to see progress).  It's really in the uncanny valley of UI for me and has been infuriating to use.  I may or may not get to this myself, but if anyone else has a chance I'd appreciate it...

Yeah, I noticed that too. I think it should disappear once the "On its way..." is finished (like it used to).

Do you want me to have a go at fixing it?

Please. I'm crazy overloaded with life right now.


Alias world_to_viewport for easier migration

Objective
When someone searches in rustdoc for world_to_screen, they now will
find world_to_viewport. The method was renamed in 0.8, it would be
nice to allow users to find the new name more easily.

bors r+


问下作者，代码是否需要改动才可运行！

System.InvalidOperationException: Endpoint Host.Controllers.JobController.GetAllJob (Host) contains CORS metadata, but a middleware was not found that supports CORS.
Configure your application startup by adding app.UseCors() inside the call to Configure(..) in the application startup code. The call to app.UseAuthorization() must appear between app.UseRouting() and app.UseEndpoints(...).
at Microsoft.AspNetCore.Routing.EndpointMiddleware.ThrowMissingCorsMiddlewareException(Endpoint endpoint)
at Microsoft.AspNetCore.Routing.EndpointMiddleware.Invoke(HttpContext httpContext)
at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
at Swashbuckle.AspNetCore.SwaggerUI.SwaggerUIMiddleware.Invoke(HttpContext httpContext)
at Swashbuckle.AspNetCore.Swagger.SwaggerMiddleware.Invoke(HttpContext httpContext, ISwaggerProvider swaggerProvider)
at Host.Startup.<>c.<b__5_0>d.MoveNext() in C:\Users\Administrator\Desktop\quartzui-dev\QuartzNetAPI\Host\Startup.cs:line 91
--- End of stack trace from previous location where exception was thrown ---
at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)
HEADERS
Connection: keep-alive
Content-Type: application/json
Accept: application/json, text/plain, /
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9
Host: localhost:8100
Referer: http://localhost:8100/
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin

CORS ?
您使用的是哪个分支？

https://github.com/zhaopeiym/quartzui/blob/dev/QuartzNetAPI/Host/appsettings.json#L19
AllowedHosts  用来配置跨域访问的地址。我用dev分支测试 是没有问题的。
你可以调试下 https://github.com/zhaopeiym/quartzui/blob/dev/QuartzNetAPI/Host/Startup.cs#L42
@xb594328980


Switch keyboard after sentence delimiter and a newline

After typing a sentence delimiter, inserting a new line should switch back to the alphabetical keyboard.

This is actually not that straightforward in the native keyboards. For instance, if you type a . then a new line, it switches, but if you then move the cursor after the . and enter a new line, it doesn't.
So it seems like the native keyboard keeps track of the latest keypresses, which KeyboardKit doesn't. However, I have added so that it always does this for sentence delimiter and newline, and think it feels good enough.


dev-cmd/bump-{cask,formula}-pr: args.message is before the default

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew typecheck with your changes locally?
[x] Have you successfully run brew tests with your changes locally?

"Append" is the wrong word for the --message arg description since the bump-formula-pr --message gets added at the start.

Review period will end on 2022-11-22 at 00:00:00 UTC.

Review period skipped due to critical label.


⚙ Add Checkbox to turn off/on Face Detection ⚙

Closed and moved to https://github.com/AYIDouble/Muh/issues/3


[fix-12687]when timeout_notify_strategy is null, modify timeout_notify_strategy

when timeout_notify_strategy is null, modify timeout_notify_strategy is 1000, prevention maps to valid values
close #12687

Codecov Report

Merging #12689 (5ed5509) into dev (6766ec0) will decrease coverage by 0.04%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##                dev   #12689      +/-   ##
============================================
- Coverage     39.18%   39.13%   -0.05%
+ Complexity     4207     4205       -2
============================================
  Files          1044     1045       +1
  Lines         39673    39653      -20
  Branches       4564     4547      -17
============================================
- Hits          15544    15517      -27
- Misses        22361    22373      +12
+ Partials       1768     1763       -5

Impacted Files
Coverage Δ

...erver/master/processor/queue/TaskEventService.java
69.64% <0.00%> (-10.72%)
:arrow_down:

...r/plugin/registry/zookeeper/ZookeeperRegistry.java
43.54% <0.00%> (-6.46%)
:arrow_down:

...hinscheduler/plugin/alert/script/ScriptSender.java
70.58% <0.00%> (-1.64%)
:arrow_down:

...r/plugin/task/sqoop/parameter/SqoopParameters.java
51.19% <0.00%> (-1.20%)
:arrow_down:

...cheduler/plugin/alert/dingtalk/DingTalkSender.java
34.13% <0.00%> (-0.78%)
:arrow_down:

...rver/master/runner/task/BlockingTaskProcessor.java
75.86% <0.00%> (-0.55%)
:arrow_down:

...inscheduler/plugin/registry/etcd/EtcdRegistry.java
50.69% <0.00%> (-0.35%)
:arrow_down:

.../dolphinscheduler/plugin/task/datax/DataxTask.java
36.62% <0.00%> (-0.26%)
:arrow_down:

.../dolphinscheduler/plugin/task/spark/SparkTask.java
72.56% <0.00%> (-0.25%)
:arrow_down:

...dolphinscheduler/service/storage/impl/S3Utils.java
0.00% <0.00%> (ø)

... and 18 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

public enum TaskTimeoutStrategy {

    /**
     * 0 warn
     * 1 failed
     * 2 warn+failed
     */
    WARN(0, "warn"),
    FAILED(1, "failed"),
    WARNFAILED(2, "warnfailed");

}

Because the default is WARN, maybe it's not a bug.


Visitor sees Landing page (section D/#155111468 ) - Work in Progress

Pivotal Tracker Story ID: [#155111468]

Pre-Submission Checklist:

[x] Your pull request targets the master branch of calltocode.org
[x] Your branch is updated with the latest changes on master
[ x] Your branch passes linting, building and all new and existing tests with command yarn test
[x ] Your branch passes the end-to-end tests with command yarn e2e
[x ] The story that this pull request addresses is referenced above by ID

Post-Submission Checklist:

[x] Your branch has no conflicts with master (find this out at the bottom of your pull request)
[x ] Address any reviews on your pull request, as it will be unable to be merged until it is approved

Description of Changes:

TODO:

This is only the frontend of landing page D. Sergio will be working on the backend part. Work in progress.
here is the screenshot

replaced by https://github.com/CodeForSocialGood/calltocode.org/pull/209


update jakoch/phantomjs-installer to v2.1.1-p07

Changes in the installer

indicate the need for php-ext bzip2 (solves extraction issue)
change of the download URL (this solves bitbucket issues)
CDN / mirror support
override platform requirements (package for other os)
easy access to the PhantomBinary via class constant (could be useful for this project)

CHANGELOG - README

Closing. Didn't see https://github.com/jonnnnyw/php-phantomjs/pull/131


How to regenerate wg0.conf from DB

I know this might not be the intended usage of this tool, but I would like to be able to create a new file in /db/clients/x.json and be able to restart wireguard-ui and have it be added to wg0.conf.
For some reason I have created the file and restarted wireguard-ui, it doesnt update wg0.conf. If I delete wg0.conf, and then restart wireguard-ui, it will regenerate the file with the new client.
Can you help me with this use case?

I also do not really understand the naming convention for the id? cg4d6mr0sq8auot174ig From attempting to look at the code, it appears to be some kind of hash, but I cannt tell if it MUST be a hash, or it could be anything.

If I understand you correctly you are trying to edit the client db and want this to be reflected in the wg0.conf file?
Try this:

start wireguard-ui
copy or create a new .json in db/clients/,
browse to "Wireguard Clients" in wireguard-ui and refresh the site
click "Apply Config"

This should then create a corresponding entry in your wg0.conf. I tested it with this client file thisisaclientid.json:
{
        "id": "thisisaclientid",
        "private_key": "yourkeyhere",
        "public_key": "yourpublickeyhere",
        "preshared_key": "yourkeyhere",
        "name": "your_new_client_id",
        "email"<EMAIL_ADDRESS>        "allocated_ips": [
                "<IP_ADDRESS>/32"
        ],
        "allowed_ips": [
                "<IP_ADDRESS>/32"
        ],
        "extra_allowed_ips": [],
        "use_server_dns": true,
        "enabled": true,
        "created_at": "2023-05-08T12:14:18.813915466Z",
        "updated_at": "2023-05-08T12:14:18.813915466Z"
}

Which creates this wg0.conf for me:
# ID:           thisisaclientid
# Name:         your_new_client_id
# Email<EMAIL_ADDRESS># Created at:   2023-05-08 12:14:18.813915466 +0000 UTC
# Update at:    2023-05-08 12:14:18.813915466 +0000 UTC
[Peer]
PublicKey = yourpublickeyhere
PresharedKey = yourkeyhere
AllowedIPs = <IP_ADDRESS>/32

Please be aware that I am unsure if this is working as intended and that those changes might break stuff!


improve parallel processing

right now the why runs get parallelized is a terrible hack.
-> rewrite 'experiment_handling.py' to depend directly on mpi4py

until now, only the compute function relies on mpi4py. As a consequence, if an experiment is run in a parallel environment, all other functions (resave plot etc.) are run in parallel without any use - corrupting log files, wasting wall time and and in the worst case messing with the output.
This is urgent.

Proposed improvements in #7

opened an issue for the parameter combinations that don't terminate (#8)


Event counts show 'unknown' when they are 0 for a time period

If there are 0 events in the last day, get_events should return 0. I think it's returning None since Home Assistant renders 'unknown'.

Hmm, looks like that's coming from this line, which implies we're getting an exception when parsing. I'm quite far from my zoneminder install for the next several weeks, but when I get back I can take a look and see if there's a definitive way to pull a 0 out of there.
https://github.com/rohankapoorcom/zm-py/blob/develop/zoneminder/monitor.py#L160


[8.x] Adds a --register option when using the make:provider command

Hi guys,
Hope you're all well.
This PR is a small QOL improvement when using the php artisan make:provider command. It allows you to specify a --register option (or -r for shorthand) that will automatically add an entry in your config/app.php file.
The logic for inserting this into the file is taken from Telescope's InstallCommand: https://github.com/laravel/telescope/blob/4.x/src/Console/InstallCommand.php, with some modifications to make it more generic.
Usage
Usage is identical to before, but now you can add the register option if desired:
php artisan make:provider MyVeryOwnServiceProvider --register
# Or
php artisan make:provider MyVeryOwnServiceProvider -r

The provider will be inserted under the RouteServiceProvider that ships with Laravel.
Thanks for all your hard work 🥳
Kind Regards,
Luke

Hey Luke! This looks great. I usually register my providers in alphabetical order, to follow the others - any chance that could be the default behaviour here?

Decided to move to the more up-to-date and simpler Jetstream way of handling this: https://github.com/laravel/jetstream/blob/8cc54788c657142053a2e6becb4e406109830f8a/src/Console/InstallCommand.php#L474

@danharrin we certainly could do that. Will wait and see what the team say; I know that their official packages don't do that, so don't want to assume.

Also, think the tests might need re-starting; the failures seem to be non-related (to do with Redis and zstd compression)

I feel --install has been the common term for this usage. At first read of the PR title, I assume --register related to Service Provider's register() method.

@crynobone good call. Will update 👍

Thanks for your pull request to Laravel!
Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.
If possible, please consider releasing your code as a package so that the community can still take advantage of your contributions!
If you feel absolutely certain that this code corrects a bug in the framework, please "@" mention me in a follow-up comment with further explanation so that GitHub will send me a notification of your response.

Hello @lukeraymonddowning.
I think it doesn't make sense to put namespace under the RouteServiceProvider namespace.
What if we had changed the namespace of RouteServiceProvider or, what if we want to put the provider's namespace in alphabetical order or under all of the previous namespaces.

Thanks for your pull request to Laravel!
Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.
If possible, please consider releasing your code as a package so that the community can still take advantage of your contributions!
If you feel absolutely certain that this code corrects a bug in the framework, please "@" mention me in a follow-up comment with further explanation so that GitHub will send me a notification of your response.


Create gitignore

Reasons for making this change:
TODO
Links to documentation supporting these rule changes:
TODO
If this is a new template:

Link to application or project’s homepage: TODO

What is the purpose of this.....


Unable to finish IOS bundle only.

Build/Submit details page URL
https://expo.dev/accounts/rashidbilgrami/projects/MAKCO/builds/590a3572-3319-48a2-ac84-f44a083b4635
Summary
I am using Windows 10, VS Code, and expo to build my app. I have used eas build --platform ios and I got the error on IS build which is listed below. Note (The Android setup was created successfully and running well)
Managed or bare?
Managed
Environment
expo-env-info 1.2.0 environment info:
System:
OS: Windows 10 10.0.19045
Binaries:
Node: 18.2.0 - C:\Program Files\nodejs\node.EXE
npm: 10.2.4 - D:\Software Installation\nodejs\npm.CMD
Watchman: 20231008.002904.0 - C:\ProgramData\chocolatey\bin\watchman.EXE
npmPackages:
expo: ~50.0.7 => 50.0.7
react: 18.2.0 => 18.2.0
react-native: 0.73.4 => 0.73.4
Expo Workflow: managed
Error output
Error
❌  error: EMFILE: too many open files, open '/var/folders/p2/2788nfhd7xq3pnnk81v00sf00000gn/T/metro-cache/23/3cebb16a1fc862eae5a66e0c1e2bdd74cde6abc8fe2d2102149a2f83c63a8db04db3e5'
▸  ARCHIVE FAILED
▸ The following build commands failed:
▸     PhaseScriptExecution Bundle\ React\ Native\ code\ and\ images /Users/expo/Library/Developer/Xcode/DerivedData/MAKCO-aviodkdgldlyytchkkbsbnekvgwu/Build/Intermediates.noindex/ArchiveIntermediates/MAKCO/IntermediateBuildFilesPath/MAKCO.build/Release-iphoneos/MAKCO.build/Script-00DD1BFF1BD5951E006B06BC.sh (in target 'MAKCO' from project 'MAKCO')
▸ (1 failure)
ARCHIVE FAILED
The following build commands failed:
PhaseScriptExecution Bundle\ React\ Native\ code\ and\ images /Users/expo/Library/Developer/Xcode/DerivedData/MAKCO-aviodkdgldlyytchkkbsbnekvgwu/Build/Intermediates.noindex/ArchiveIntermediates/MAKCO/IntermediateBuildFilesPath/MAKCO.build/Release-iphoneos/MAKCO.build/Script-00DD1BFF1BD5951E006B06BC.sh (in target 'MAKCO' from project 'MAKCO')
(1 failure)
Reproducible demo or steps to reproduce from a blank project
The code is for some important project if you want i will send you the zip file  but here is the url for the git library

Did you found any solution?

I have recreated a new fresh project and tried to create a package and it was successfully created an IOS package.
After installing the packages one by one and testing the IOS package I found the problem in the following packages
"deprecated-react-native-prop-types": "^5.0.0",
"patch-package": "^8.0.0",
I have no idea why I installed it even though I don't require the properties of any of my components. Any I found that this "deprecated-react-native-prop-types": "^5.0.0", required Patch-Pacakge, and patch pacakge is not supporting the expo version that I have.
So I exclude these libraries or Package and boom!!! finally, I got the IOS package.
** NOTE **
This is not necessary that you have the same library or package file issues. You have to check one by one and check which package is creating a problem.
In my case, the same issue arrived in the local machine but when I cleared the cache the app worked well IOS compiled with npx expo-doctor and the doctor threw this error while the Android has a different approach which is why the Android app was created successfully.


TypeError: Cannot read property 'length' of null

Steps to reproduce
Using Docker version 1.3.2, build 39fa2fa
docker pull bfoote/docker-dns
cd docker
cp ../config/config.js.example ./config/config.js
(edit some stuff)
./run_docker.sh hostname ./config/config.js;

Outpt
$ ./run_docker.sh hostname ./config/config.js;                                                                                [master]
using config file ./config/config.js
docker-dns
docker-dns
docker run -d -t -h hostname --name docker-dns -p <IP_ADDRESS>:53:53/udp -v /var/run/docker.sock:/var/run/docker.sock -v /home/cristian/.docker-dns/docker-dns/docker/log:/var/log/supervisor -v /home/cristian/.docker-dns/docker-dns/docker/./config/config.js:/opt/docker-dns/config/config.js bfoote/docker-dns

    try this out to test if it worked:

       dig -t SRV \* @<IP_ADDRESS>

       dig -t SRV _domain._udp\* @<IP_ADDRESS>

    logs are available at ./log/docker-dns.log

    please send pulls and patches, especially to update
    the config/etc-services file

    Thanks!

    ben

The logfile contains
[DD] info Loading config from /opt/docker-dns/config/config.js

/opt/docker-dns/lib/docker-inspect.js:78
                self.log.debug(self.name, "inspecting " + containers.length +" containers");
                                                                    ^
TypeError: Cannot read property 'length' of null
    at /opt/docker-dns/lib/docker-inspect.js:78:55
    at /opt/docker-dns/node_modules/dockerode/lib/docker.js:192:5
    at Modem.buildPayload (/opt/docker-dns/node_modules/dockerode/node_modules/docker-modem/lib/modem.js:154:19)
    at ClientRequest.<anonymous> (/opt/docker-dns/node_modules/dockerode/node_modules/docker-modem/lib/modem.js:139:10)
    at ClientRequest.emit (events.js:95:17)
    at Socket.socketErrorListener (http.js:1551:9)
    at Socket.emit (events.js:95:17)
    at net.js:440:14
    at process._tickCallback (node.js:419:13)

closing

Hi,
I'm sorry for not giving a reply earlier.
After editing /etc/resolv.conf it seems that I am able to ping containers with their name:
[~/.docker-dns/docker-dns]$ docker run -d -t \
     --privileged=true \
     --name docker-dns -p <IP_ADDRESS>:53:53/udp \
     -v /var/run/docker.sock:/var/run/docker.sock  \
     -v /home/cristian/.docker-dns/docker-dns/docker/log:/var/log/supervisor \
     -v /home/cristian/.docker-dns/docker-dns/docker/./config/config.js:/opt/docker-dns/config/config.js  \
      bfoote/docker-dns
5d9b5cddcbf6a8f5241a2caac41694300ecfe0626f0a649b82fc41984daf15f0
[~/.docker-dns/docker-dns]$ docker ps
CONTAINER ID        IMAGE                      COMMAND             CREATED              STATUS              PORTS                    NAMES
5d9b5cddcbf6        bfoote/docker-dns:latest   "supervisord -n"    About a minute ago   Up About a minute   <IP_ADDRESS>:53->53/udp   docker-dns
[~/.docker-dns/docker-dns]$ ping 5d9b5cddcbf6.public.dockerA.docker.local
ping: unknown host 5d9b5cddcbf6.public.dockerA.docker.local
[~/.docker-dns/docker-dns]$ sudo nano /etc/resolv.conf
[~/.docker-dns/docker-dns]$ ping docker-dns
PING 5d9b5cddcbf6.local.dockerA.docker.local (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=64 time=0.063 ms
64 bytes from <IP_ADDRESS>: icmp_seq=2 ttl=64 time=0.084 ms
[...]
64 bytes from <IP_ADDRESS>: icmp_seq=13 ttl=64 time=0.097 ms
64 bytes from <IP_ADDRESS>: icmp_seq=14 ttl=64 time=0.159 ms
^C
--- 5d9b5cddcbf6.local.dockerA.docker.local ping statistics ---
14 packets transmitted, 14 received, 0% packet loss, time 22006ms
rtt min/avg/max/mdev = 0.043/0.100/0.161/0.032 ms
```
and if I start another container
```
$ docker run -i -t  cristiancantoro/hadoop-mrjob /etc/bootstrap.sh -bash
[...]
```
then I can ping it as well:
```
[~/.docker-dns/docker-dns]$ docker ps
CONTAINER ID        IMAGE                                 COMMAND                CREATED             STATUS              PORTS                                                                                NAMES
e0d2cb635c0b        cristiancantoro/hadoop-mrjob:latest   "/etc/bootstrap.sh -   4 minutes ago       Up 4 minutes        50010/tcp, 8042/tcp, 50070/tcp, 8031/tcp, 49707/tcp, 50075/tcp, 8033/tcp, 22/tcp, 8040/tcp, 8088/tcp, 50090/tcp, 50020/tcp, 8032/tcp, 8030/tcp   sharp_yonath
5d9b5cddcbf6        bfoote/docker-dns:latest              "supervisord -n"       10 minutes ago      Up 10 minutes       <IP_ADDRESS>:53->53/udp                                                                                docker-dns
[~/.docker-dns/docker-dns]$ ping sharp_yonath
PING e0d2cb635c0b.local.dockerA.docker.local (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=64 time=0.098 ms
64 bytes from <IP_ADDRESS>: icmp_seq=2 ttl=64 time=0.045 ms
[...]
64 bytes from <IP_ADDRESS>: icmp_seq=12 ttl=64 time=0.056 ms
^C
--- e0d2cb635c0b.local.dockerA.docker.local ping statistics ---
12 packets transmitted, 12 received, 0% packet loss, time 20008ms
rtt min/avg/max/mdev = 0.041/0.055/0.098/0.019 ms
```

*But* (and that's quite a big but) if I do so I lost the ability to resolve domains from the internet so if I ping, say, [google.com] this is what I get:
```
[~/.docker-dns/docker-dns]$ ping google.com
ping: unknown host google.com
```
I need to have this line in my (host's) `resolv.conf`
```
nameserver <IP_ADDRESS>
```
but if I put it there then everything else stops working and I can not ping `docker-dns` or other containers anymore.

Furthermore it seems that my conrtainers have lost the ability to resolve urls, for example if I do (in the container above named `sharp_yonath`:
```
bash-4.1# yum update
Loaded plugins: fastestmirror, keys, protect-packages, protectbase
Determining fastest mirrors
Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=os error was
14: PYCURL ERROR 6 - "Couldn't resolve host 'mirrorlist.centos.org'"
[...]
```

but the container is able to contact the internet using IP addresses (`<IP_ADDRESS>` is one IP address for [google.com]):
```
bash-4.1# ping google.com
ping: unknown host google.com
bash-4.1# ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=55 time=197 ms
64 bytes from <IP_ADDRESS>: icmp_seq=2 ttl=55 time=291 ms
64 bytes from <IP_ADDRESS>: icmp_seq=3 ttl=55 time=1258 ms
64 bytes from <IP_ADDRESS>: icmp_seq=4 ttl=55 time=574 ms
^C
--- <IP_ADDRESS> ping statistics ---
5 packets transmitted, 4 received, 20% packet loss, time 4211ms
rtt min/avg/max/mdev = 197.909/580.777/1258.440/415.115 ms, pipe 2
bash-4.1# ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=56 time=13.9 ms
64 bytes from <IP_ADDRESS>: icmp_seq=2 ttl=56 time=17.9 ms
64 bytes from <IP_ADDRESS>: icmp_seq=3 ttl=56 time=24.0 ms
64 bytes from <IP_ADDRESS>: icmp_seq=4 ttl=56 time=13.6 ms
64 bytes from <IP_ADDRESS>: icmp_seq=5 ttl=56 time=16.9 ms
^C
--- <IP_ADDRESS> ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4151ms
rtt min/avg/max/mdev = 13.614/17.276/24.036/3.769 ms
```

Also, I can not find a way to restore the ability of my containers to resolve urls.
Any ideas?

Hello again!
docker-dns is not a "forwarding dns resolver"
Any domain names which docker-dns does not know about will not resolv.
Before showing you a couple options I'll add the caveat that dns setups can be tricky and what might work in one environment may not work in another.
add multiple dns servers to /etc/hosts
nameserver <IP_ADDRESS>
nameserver <IP_ADDRESS>
search public.dockerA.docker.local

run a more robust dns server in front of docker-dns such as dnsmasq
add these lines to dnsmasq
server=/public.dockerA.docker.local/<IP_ADDRESS>
server=<IP_ADDRESS>

In addition you should have an understanding of how the dns environment get constructed inside the containers....
https://docs.docker.com/articles/networking/
The --dns and --dns-search arguments passed to the docker daemon at system startup  populates the /etc/resolv.conf inside each container.
I had thought of providing dns forwarding features in docker-dns, but it's a slippery slope, and life is too short to get mired in RFC documents. :)
Please do post back here to share your ventures.

A quick update.
Following the advice in this AskUbuntu post I disabled dnsmasq and restarted the newtwork manager.
Here's how my new /etc/resolv.conf looked like after reconnecting:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver <IP_ADDRESS>
nameserver <IP_ADDRESS>
search unitn.it

(unitn.it is the network of my university where I am now).
Then I added the following:
nameserver <IP_ADDRESS>
nameserver <IP_ADDRESS>
nameserver <IP_ADDRESS>
nameserver <IP_ADDRESS>
search unitn.it
search local.dockerA.docker.local

and both local and external DNS resolution work.
[~/.docker-dns/docker-dns]$ ping docker-dns
PING 04f275bbaa40.local.dockerA.docker.local (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=64 time=0.083 ms
64 bytes from <IP_ADDRESS>: icmp_seq=2 ttl=64 time=0.050 ms
^C
--- 04f275bbaa40.local.dockerA.docker.local ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.050/0.066/0.083/0.018 ms
[~/.docker-dns/docker-dns]$ ping google.com
PING google.com (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from wg-in-f138.1e100.net (<IP_ADDRESS>): icmp_seq=1 ttl=47 time=34.5 ms
64 bytes from wg-in-f138.1e100.net (<IP_ADDRESS>): icmp_seq=2 ttl=47 time=34.8 ms
64 bytes from wg-in-f138.1e100.net (<IP_ADDRESS>): icmp_seq=3 ttl=47 time=35.9 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 34.555/35.100/35.924/0.630 ms

The last question that I have is: how can I configure everything such taht I do not have to modify manually resolv.conf every time? As the file itself says, it gets rewritten every time the Network manager starts a new connection.

this is one of the tricky parts
your /etc/resolv.conf is getting manipulated by resolvconf, and possibly with the help of a dhcp client

(I have seen  now the answer you posted while I was writing my other comment. I will try to firstly understand it :sweat_smile: and then try again).

I think that the easiest solution is to add the line:
search public.dockerA.docker.local

to the file:
/etc/resolvconf/resolv.conf.d/base

In this way the NetworkManager produces a (/etc/)resolv.conf file which has the correct search domain (in addition to the ones you obtain from other sources, say DHCP) and this seems to actually work, i.e. the host can ping containers using their name and the outside world is also reachable.
For completeness, ,my attempt at configuring dnsmasq failed. I had put this lines:
server=/public.dockerA.docker.local/<IP_ADDRESS>
server=<IP_ADDRESS>

in file called docker-dns in /etc/dnsmasq.d`, but I wa not able to ping containers·
(Also, for reference, note that using the full dnsmasq with NetworkManager on Ubuntu has some known problems.)
My last point would be to point out that I cannot ping a container (say docker-dns from inside another container), this seems reasonable since I wasn't unable to tell to dnsmasq on the host to lock for the public.dockerA.docker.local (right? Am I making sense?)


[DONOT MERGE] just cla test

What type of PR is this?

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?

Additional documentation e.g., usage docs, etc.:

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


Accept regex when registering urls

Also prepare repo for VersionBot
change-type: minor

@wrboyce @flesler @CameronDiver @afitzek I'm adding you as reviewers since you all maintain/work on components that use requestmock in the their test framework. In summary, this will allow registering regex urls like
endpoint = new RegExp("http://#{_.escapeRegExp(www.test.com)}/application/[1-9][0-9]*")

requestMock.register 'get', endpoint, (args, cb) ->
  cb(null, statusCode: 200, 'OK')

so that all requests that satisfy the regex like

request.get('www.test.com/application/1')
request.get('www.test.com/application/2')
etc.

will be mocked

Published<EMAIL_ADDRESS>


Addings Stats to allowed_lazy_attributes of tm.ltm collections

Several tm.ltm collections provide endpoints to batch obtain stats for all items in the collection.
Adding Stats to the allowed_lazy_attributes list gives access to these endpoints.
This PR covers Nodes, Pools, Rules, Virtuals and Virtual Addresses.

Travis build errors from upstream files ... no idea how to get rid of them.
Trying a fresh fork with a new PR.


[Text Analytics] AnalyzeOperationWithErrorTest failing in nightly runs

Text Analytics nightly test runs are failing with:

Error message
Expected string length 21 but was 3. Strings differ at index 0.
Expected: "InvalidParameterValue"
But was:  "401"
-----------^
Stack trace
at Azure.AI.TextAnalytics.Tests.AnalyzeOperationTests.AnalyzeOperationWithErrorTest() in /mnt/vss/_work/1/s/sdk/textanalytics/Azure.AI.TextAnalytics/tests/AnalyzeOperationTests.cs:line 502

at Azure.AI.TextAnalytics.Tests.AnalyzeOperationTests.AnalyzeOperationWithErrorTest() in /mnt/vss/_work/1/s/sdk/textanalytics/Azure.AI.TextAnalytics/tests/AnalyzeOperationTests.cs:line 502

For more details check here:

https://dev.azure.com/azure-sdk/internal/_build/results?buildId=2636774&view=results

@jsquire for notification.

This is a duplicate of https://github.com/Azure/azure-sdk-for-net/issues/35452.


DCD Frontend: Add name field to Drainage Strategy

Github Pull Request: https://github.com/equinor/dcd/pull/475


Remove controller runtime

Remove the controller-runtime dependency from the project.
Simplifies upgrading k8s dependencies going forward.
Depends-on: #265

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 3 (0.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+4.08%) to 57.956%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/reconciler/iploop.go
0
3
0.0%

Totals

Change from base Build<PHONE_NUMBER>:
4.08%

Covered Lines:
845

Relevant Lines:
1458

💛  - Coveralls

FWIW, everything installs normally as a user, and works with my current test. OK to proceed. Thanks Miguel :+1:


Support function-generating macros

Hello,
first off, thanks for this crate, it's really useful to avoid some boilerplate. One thing which easy-ext can't seem to do yet is handle impl-blocks with macros inside them, like so:
macro_rules! getter_setter {
        ($type:ty, $name:ident, $key:literal) => {
        paste::item! {
            pub fn [< get_ $name >] (&self) -> $type {
                self.get::<$type>($key)
            }
        }
        paste::item! {
            pub fn [< set_ $name >] (&self, value: $type) {
                self.set::<$type>($key, &value).unwrap();
            }
        }
}

#[easy_ext::ext]
impl MyType {
    getter_setter!(u32, user_age, "user-age");
}

It'd be great if easy-ext also supported those so boilerplate can be minimised even more.

I'm not sure if this is possible because the outer macro is expanded first.
Instead, you can do the almost equivalent by calling the macros in reverse order.

macro_rules! getter_setter {
    ($type:ty, $name:ident, $key:literal) => {
        paste::item! {
            #[ext]
            impl MyType {
                pub fn [< get_ $name >] (&self) -> $type {
                    self.get::<$type>($key)
                }
                pub fn [< set_ $name >] (&self, value: $type) {
                    self.set::<$type>($key, &value).unwrap();
                }
            }
        }
    };
}

getter_setter!(u32, user_age, "user-age");

Ah, that does work as long as an anonymous trait name works. In my case I need to define a trait name so I can import the trait in other modules, but then the different trait definitions collide with each other unfortunately:
macro_rules! getter_setter {
    ($type:ty, $name:ident, $key:literal) => {
        paste::item! {
            #[ext(MyTypExt)]
            impl MyType {
                pub fn [< get_ $name >] (&self) -> $type {
                    self.get::<$type>($key)
                }
                pub fn [< set_ $name >] (&self, value: $type) {
                    self.set::<$type>($key, &value).unwrap();
                }
            }
        }
    };
}

getter_setter!(u32, user_age, "user-age");
getter_setter!(u32, user_height, "user-height"); // conflict because MyTypeExt is defined again

One of the workarounds for that problem is to combine the name of the ext trait by using paste (or pass the name of the ext trait as a macro argument).
macro_rules! getter_setter {
    ($type:ty, $name:ident, $key:literal) => {
        paste::item! {
            #[ext( [<MyType $name:camel Ext>] )]
            impl MyType {
                pub fn [< get_ $name >] (&self) -> $type {
                    self.get::<$type>($key)
                }
                pub fn [< set_ $name >] (&self, value: $type) {
                    self.set::<$type>($key, &value).unwrap();
                }
            }
        }
    };
}

getter_setter!(u32, user_age, "user-age");
getter_setter!(u32, user_height, "user-height");

Generating many traits can be a problem, but it's probably not too annoying if separating them into modules.
use ext::*;

mod ext {
    macro_rules! getter_setter { ... }
    getter_setter!(...);
    getter_setter!(...);
    ....
}

Yeah, it's a bit unfortunate that I need to import more traits then but I suppose that works, thanks :)


Dependencies for spring5 and credentials-support removed

Hello,
I'm working on the DGC project in vienna, perhaps it's useful for others, that the dependencies for credentials-support, which pulls spring5 are removed from the project

Hello,
fyi, the tests run all ok
Best Regards
DI Johannes Marchart
IT-Services der Sozialversicherung GmbH
Software Governance
Mobile Developer
Johan-Böhm-Platz 1
A - 1020 Wien
M: +43<PHONE_NUMBER>
@.***
FN: 255932x, Handelsgericht Wien

Von: Martin Lindström @.***>
Gesendet: Montag, 3. Mai 2021 12:54:56
An: DIGGSweden/dgc-java
Cc: Marchart Johannes; Author
Betreff: Re: [DIGGSweden/dgc-java] Dependencies for spring5 and credentials-support removed (#22)
@martin-lindstrom commented on this pull request.
We need the credentials-support library for HSM/PKCS#11 support, so I will not merge this PR.
However, I will make sure that Spring isn't required and exlude those dependencies and add them explicitly as optional. In that way you can still initialize a DefaultDGCSigner using the DefaultDGCSigner(final PrivateKey signerKey, final X509Certificate signerCertificate) constructor or simply implement an implementation of your own choice.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/DIGGSweden/dgc-java/pull/22#pullrequestreview-650252250, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKADTFKFNB7AMZ6OUK3XABLTLZ6IBANCNFSM44ARSE6Q.

Se PR https://github.com/DIGGSweden/dgc-java/pull/25


Fix autolinking with React Native 0.69

CLI version 8 removed the react-native link command https://github.com/react-native-community/cli/pull/1537 which breaks this library. This PR removes configuration and documentation related to it.

@oblador Can you publish v9.2.0 on npm?

Messed up the automation, should be released now

Thank you!


Moving UpdateAdaptiveQuality based on Unity version

@TrebuhD  I'm spinning this up since the mainline repo seems like it's not going to accept updates. Are you okay with this?

Go ahead!


"h5ad" format can not generate correct result

Thank you for your great work!
Here is my code:
python -u /public/home/DPYY_tonghy/SequencingCancerFinder-master/infer.py
--ckp=model_epoch92.pkl
--matrix=epi.h5ad
--out=/public/home/DPYY_tonghy/Cancer-finder/out.csv --threshold=0.5
I'm trying to test it on my own data, the format is "h5ad".
However, I got the result like:
(scf) [DPYY_tonghy@430931 Cancer-finder]$ python -u /public/home/DPYY_tonghy/SequencingCancerFinder-master/infer.py --ckp=model_epoch92.pkl --matrix=epi.h5ad --out=/public/home/DPYY_tonghy/Cancer-finder/out.csv --threshold=0.5
begin 0
begin 1
begin 2
sample  predict
0        LINC00115      1.0
1           FAM41C      1.0
2        LINC02593      1.0
3           SAMD11      1.0
4            NOC2L      1.0
...            ...      ...
23284     KRTAP9-4      1.0
23285  TRBV20OR9-2      1.0
23286  TRBV25OR9-2      1.0
23287       TRAJ60      1.0
23288    LINC01737      1.0
Why did the output.csv get the Gene_names instead of Cell_names as result?

This looks like an error.
In the code processing, h5ad will first be processed into an expression matrix using the scanpy.read_h5ad function, and then the subsequent processing will be the same as for tsv and other files.
Is your data a normal expression matrix after being processed with scanpy.read_h5ad?
In my test, my data looks like this:
import scanpy as sc
adata = sc.read_h5ad('data/train/domain_2.h5ad')
adata.to_df()

cell1
cell2
...
cell20

LINC00115-1
0
0
...
0

SAMD11-1
0
0
...
1

...
...
...
...
...

EIF1AY
0
0
...
0

The output result is as follows:
python -u infer.py --ckp=checkpoints/sc_pretrain_article.pkl --matrix=data/train/domain_2.h5ad --out=out.csv --threshold=0.5
begin 0
     sample  predict
0    cell_2      0.0
1    cell_3      0.0
2    cell_4      0.0
3    cell_5      0.0
4    cell_6      0.0
5    cell_7      0.0
6    cell_8      0.0
7    cell_9      1.0
8   cell_10      0.0
9   cell_11      0.0
10  cell_12      1.0
11  cell_13      0.0
12  cell_14      1.0
13  cell_15      0.0
14  cell_16      1.0
15  cell_17      0.0
16  cell_18      1.0
17  cell_19      1.0
18  cell_20      0.0

Actually, I did find a minor bug related to indexing in the h5ad file...
Fixing the bug will take some time.
I suggest using .csv as a temporary replacement.
I hope this helps you.

adata.to_df()
| FAM87B| LINC00115| FAM41C| LINC02593| SAMD11 |
|--------|--------|--------|--------|--------|
| N5846_n1_AAACCTGCAATGGATA-1| 0.0| 0.0| 0.0| 0.0|
| N5846_n1_AAACGGGCAATCTACG-1| 0.0| 0.0| 0.0 | 0.0|
| N5846_n1_AAAGATGCAGATGGCA-1| 0.0| 0.0| 0.0| 0.0|
| N5846_n1_AAAGATGGTTCCACAA-1| 0.0| 0.0| 0.0| 0.0|
| N5846_n1_AAATGCCGTTCACCTC-1| 0.0| 0.0| 0.0| 0.0|
Here 's my adata
Thanks a lot! I will try


the problem of en-de

Hello,When I run the en-de model, I find that my bleu is lower than in the paper, then I would like to ask if your validation set is newtest2014?

Do you mean the pretrained models? This is what I see:
python generate.py \
  data/data-bin/wmt14.en-de.newstest2014/ \
  --path wmt14.en-de.fconv-py/model.pt \
  --gen-subset test --remove-bpe
(...)
| Generate test with beam=5: BLEU4 = 25.71, 56.8/31.2/19.5/12.6 (BP=1.000, ratio=1.022, syslen=60585, reflen=59297)

The paper reports single-model performance of 25.16 for this model on newstest2014 (Table 1).

Sorry, I was wrong,I want to ask if your development set on en-de is newstest2013?

The validation set is held out from the training data, we do not currently provide newstest2013.

thank you for your replay.I follow your en-de model setting,the wmt14‘s En-De data is 4468840 sentences and newstest2013(3000 sentences) is ued as a development set.The BLEU scores on newstest2014 is 23.78.So I wonder if something is worry。

Did you figure this out? I find that the newstest2014 (2737) provided by Stanford does not match the original one (3003 sentences) released by WMT14 En-De.


Revisit how we configure RE2 regex engine

See https://github.com/envoyproxy/envoy/pull/9171.
It turns out that program size can change between RE2 versions. Our original intention here was to have some kind of knob that would let users know if a configured regex is "too expensive." We should revisit if there are better ways of doing this.
cc @junyer @ramaraochavali @jmarantz

@howardjohn FYI. We may have to revisit how we configure this in Pilot depending on how this goes.

Just to be clear, my intention was not to stop Envoy from using program size. The RE2 fuzzer, for example, uses program size and program fanout as "cost" signals. It's barely more advanced than looking at the length of the pattern string, but it does enable one to draw a line in the sand.
The memory budget is another mechanism of constraint. Most of it goes to the DFA state cache, which does permit a CPU–RAM tradeoff to be made, but that's just another way of saying that an expensive regular expression must be paid for in some way. It's worth configuring in combination with the other limits – especially if the default (8MiB) seems unnecessarily generous to you.

FWIW, I did some experiments and each .* increases the program size by 15, so one rule of thumb is that a program costs ~50 + 15 for each .*. I don't know what that means for execution time.

At the risk of derailing into inside baseball, https://github.com/google/re2/commit/6a86f6b3f4a6d797886cd4cf6bca73ed25b2d00a reduced the cost of . and will be in the next release of RE2. (I wanted https://github.com/envoyproxy/envoy/pull/9171 in place so that the Envoy tests wouldn't suddenly break.)

Another example from the field:
[2020-02-10 07:28:58.295][1][warning][config] [source/common/config/grpc_mux_subscription_impl.cc:82] gRPC config for type.googleapis.com/envoy.api.v2.RouteConfiguration rejected: regex '/static/[a-zA-Z0-9._-]{0,200}/[a-zA-Z0-9._-]{0,200}' RE2 program size of 2013 > max program size of 1000. Increase configured max program size if necessary.

I had hardcoded our ingress controller on the assumption that no one would need more than 1000 🙄
@mattklein123 Would you take a patch to remove the limit? I can see that it makes sense for some operational patterns, but when end users get to specify the regex directly, we don't always have a good feedback mechanism to report the problem.

@mattklein123 Would you take a patch to remove the limit? I can see that it makes sense for some operational patterns, but when end users get to specify the regex directly, we don't always have a good feedback mechanism to report the problem.

Can't you just set the limit to effectively unlimited (close to max int) in your product?

But this doesn't fix the root problem, where product owners don't notice this until a customer complains. As more people move away from envoy.config.route.v3alpha.RouteMatch.hidden_envoy_deprecated_regex, they may NOT realize the new SafeRegex field has a default limit that is fairly low (like me). And they will not see this discussion until after a customer complains.
We can at least make it clear in the documentation that exceeding this size will result in a config validation fail exception and the entire config will be rejected. This will make it more obvious that affect this arbitrary value has.
I can remove the limit or make the documentation clearer if needed.

I can remove the limit or make the documentation clearer if needed.

I will defer to @jmarantz here who originally requested the limit. I do like the idea of a limit of some type as this is an indication that the user may be doing something they probably should not be. Whether the limit becomes a warning, becomes unlimited, etc. I'm not sure.

From the perspective of someone running Envoy as a managed proxy for customers, I want to bound the amount of CPU they can consume. So I want there to be a limit that can be enforced in the engine.
It seems reasonable though to interpret a limit of 0 or -1 or INT_MAX or whatever to be unlimited and just not do the check in that case, and whoever owns the control-plane can default their setting to that. But it would effectively the same thing I think just to have the control-plane default to a very high number and leave the check in. Then no core functional change is needed, and in either case a control-plane change is needed.
Seem reasonable?

Yeh, we previously bumped the limit to 1000 and now bumped it to 1m.
From a control-plane PoV, I'd ideally want to have no effective limit and have envoy report some information about regex cost. I can expose that information in any number of ways.
One of the issues here is that it is not clear to me what program size means in terms of CPU and memory cost. For example,
$ ./re2sz '/static/[a-zA-Z0-9._-]{0,200}/[a-zA-Z0-9._-]{0,200}'
program size is 2013
$ ./re2sz '^/static/[a-zA-Z0-9._-]+/[a-zA-Z0-9._-]+'
program size is 15

Is the first regex really 100x more expensive (in some dimension) than the second?

The former compiles to bytecode containing 400 copies of the [a-zA-Z0-9._-] character class whereas the latter compiles to bytecode containing 2 copies of it. The former has the /static/ prefix attached whereas the latter has it detached. Both of these differences have effects on the number of program instructions and implications for the memory footprint of the DFA.

I'm very open to changes here, but it seems like it's going to be hard to satisfy everyone so maybe we need some more config? What about an option to just warn if a program is above a certain size and/or have a stat which outputs the max loaded regex program size for monitoring?

Assigning this over to @LisaLudique who is going to make relevant changes her w/ runtime config, warn, error, etc.


inconsistent package with igibson

Thanks for the awesome package and looking forward to using it in my project.
However, seems some of the package imported in the BEHAVIOR code is not consistent with igibson main repo.
For example:

in behavior_imitation_replay.py, from igibson.activity.activity_base import iGBEHAVIORActivityInstance, but in the igibson main repo, this subpackage does not exist: https://github.com/StanfordVL/iGibson/tree/master/igibson
in behavior_env_metrics.py, from igibson.envs.behavior_mp_env import BehaviorEnv, in igibson repo under envs pkg, there is no behavior_env here: https://github.com/StanfordVL/iGibson/tree/master/igibson/envs

Please let me know how to fix these import problem, thanks

Hi, behavior_env has been deprecated. We will clean up the outdated reference in the next release. Sorry for the trouble!


clj-kondo: init at 2019.07.31-alpha

Motivation for this change
Add clj-kondo, a linter for clojure
Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

This pull request has been mentioned on Nix community. There might be relevant details there:
https://discourse.nixos.org/t/how-to-compile-and-package-an-app-with-graalvm/3662/3

No idea why I'm getting that error from grahamcofborg, locally works

No idea why I'm getting that error from grahamcofborg, locally works

I suspect it is evaluation on Darwin.
Try to
- platforms = platforms.unix;
+ platforms = graalvm8.meta.platforms;

@volth you are right, it was the evaluation on Darwin
Thanks a lot for your help with this PR, now looks a lot better :)

This pull request has been mentioned on Nix community. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/53

@GrahamcOfBorg build clj-kondo

This pull request has been mentioned on Nix community. There might be relevant details there:
https://discourse.nixos.org/t/increase-ofborg-timeout/3762/1

@jlesquembre Thanks for your patience.


Get date from GPS to use for filename

Date is found in xxRMC message in field #9 as ddmmyy
ex: $GPRMC,083559.00,A,4717.11437,N,00833.91522,E,0.004,77.52,091202,,,A,V*57
Create new file on startup named "data_ddmmyy.csv" or something like that.

Done. Due to filename length limitations the filename includes DDMMYY format as well as a 2-digit record number. The file format version is included in the file extension.