lgtm: fix "unreachable except block" warning

Gotta get that arbitrary A+ code quality rating from LGTM

Thanks, I'll include it.  Will be in the next runtime files update


Reduce idle visualizer CPU load

I'm very sorry if this isn't the place for this. I have no technical understanding of coding (Please bear with me.)
I'm on latest Rainmeter (non-Beta) and Monstercat Visualizer. Settings left as is.
With visualizer.ini loaded, my CPU load on Rainmeter.exe increases by 7% (total 10%) when no media player is running.

Any way to reduce idle load?

Do you have dynamic colors active?
Because these settings use a lot of CPU power.
Also please send your OS, Rainmeter version and skin version. Also please send a screenshot from the debug log of Rainmeter (https://docs.rainmeter.net/manual/user-interface/about/)

You're right, CPU load reduced significantly when I unticked dynamic colors.
May I ask why exactly CPU load is so high with dynamic colors even without any media player active?
Is it possible for you to implement a switch (dynamic and static color) based on if any media player is running, just like the hide feature? Wouldn't this solve the idle CPU load issue?
Thanks very much, I also attached the logs if these are any relevant.
OS: Windows 10 Pro x64 latest build and updates
Rainmeter version: 4.0.0 r2746 64 bit
Skin version: v1.5.3

Because the colors get updated every 10ms and every time a update happens the plugin needs to load the file for the covers. I'm currently working on optimizing the skin so maybe one of the next few updates will help with the issue.
You can also try to reduce the sound resolution to 1024 or 2048 and try if you still got high cpu usage.

Also the settings skin (where you can adjust the skin) is currently really unoptimized and probably one of the main issues with performance.

I think I'll make that fork I was talking about before and attempt to bring down cpu

It seems most of the issues are resolved with the last update, so i'm gonna close this issue for now. If you still have any improvements which i can do, please make a pull request with the changed files and i will check them out.


Get data for testing.

Get data of a real polygon and real minimum and maximum circle radius.

Sent by whatsapp.


Dev install failing, no matching distribution for pyside2

Describe the bug
Super minor but running pip install -e .[dev] locally fails for me with
ERROR: Could not find a version that satisfies the requirement pyside2 (from versions: none)
ERROR: No matching distribution found for pyside2

Not sure if this is an M1 thing or if the package is just misspecified

can you install pyside with pip install pyside2? are you on py3.11?

Yeah that's what's causing the fail (for whatever reason), 3.10 still for me!
(superqt) ➜  superqt git:(listview) ✗ python -V
Python 3.10.8
(superqt) ➜  superqt git:(listview) ✗ pip install pyside2
ERROR: Could not find a version that satisfies the requirement pyside2 (from versions: none)
ERROR: No matching distribution found for pyside2

yeah, all the mac wheels specify intel: https://pypi.org/project/PySide2/#files
... so I assume that's it
anyway, not a superqt issue :)


Documentation

I am opening this PR to facilitate feedback on the documentation. It is not by any means done. I have developed an index of sorts to the contents of what we need and want to document.
@daniel-thom and @kdheepak the code in make.jl is not conventional to support a combination of Literate generated Markdowns and regular Markdowns.

I am leaving this PR at this state since the amount of changes is very large. The main objective of this sprint to make documentation is adding the documentation of the model library we have and a good welcome page.
@daniel-thom the functions to auto-generate the markdown entries is a bit ugly. Any feedback is welcome.

I tried to build the docs locally but got an error
~/r/PowerSystems.jl> julia --project=docs/ docs/make.jl --color=yes
ERROR: LoadError: UndefVarError: Topology not defined
Stacktrace:
 [1] top-level scope at /Users/nick/repos/PowerSystems.jl/docs/make.jl:35
 [2] include(::Function, ::Module, ::String) at ./Base.jl:380
 [3] include(::Module, ::String) at ./Base.jl:368
 [4] exec_options(::Base.JLOptions) at ./client.jl:296
 [5] _start() at ./client.jl:506
in expression starting at /Users/nick/repos/PowerSystems.jl/docs/make.jl:35

I was hoping to be able to review by reading the rendered version of the docs.
I wonder if we can use set push_preview=true in deploydocs in docs/make.jl so that the docs build on PRs (e.g. for this PR would be visible at https://nrel-siip.github.io/PowerSystems.jl/previews/PR577/)
We'd need to set compat  to Documenter = "0.25" in docs/Project.toml

I tried to build the docs locally but got an error
~/r/PowerSystems.jl> julia --project=docs/ docs/make.jl --color=yes
ERROR: LoadError: UndefVarError: Topology not defined
Stacktrace:
 [1] top-level scope at /Users/nick/repos/PowerSystems.jl/docs/make.jl:35
 [2] include(::Function, ::Module, ::String) at ./Base.jl:380
 [3] include(::Module, ::String) at ./Base.jl:368
 [4] exec_options(::Base.JLOptions) at ./client.jl:296
 [5] _start() at ./client.jl:506
in expression starting at /Users/nick/repos/PowerSystems.jl/docs/make.jl:35

I was hoping to be able to review by reading the rendered version of the docs.
I wonder if we can use set push_preview=true in deploydocs in docs/make.jl so that the docs build on PRs (e.g. for this PR would be visible at https://nrel-siip.github.io/PowerSystems.jl/previews/PR577/)
We'd need to set compat to Documenter = "0.25" in docs/Project.toml

You need to point the docs to the local PowerSystems version since Topology wasn't originally exported.

On developer/testing file I got confused. Maybe one more comment could help.

Run a subset of tests in the REPL:

How would one reset ARGS to default? If you guys feed this is irrelevant for the time being feel free to ignore.

Thanks for adding push_preview! Makes it easier to review :)

You need to point the docs to the local PowerSystems version since Topology wasn't originally exported.

thanks! I'm used to there being a docs/Manifest.toml 😊
After running
~/r/PowerSystems.jl>
julia --project=docs/ --color=yes -e 'using Pkg; Pkg.develop(PackageSpec(path=".")); Pkg.update();'

the docs build without error.
Although with a lot of warnings e.g.
┌ Warning: 97 docstrings potentially missing:
...
│     PowerSystems.add_service! :: Tuple{System,StaticReserveGroup,Array{Service,1}}
...
│     PowerSystems.System
...

AFAICT, these docstrings are  infact missing from the docs (even though they exist in the src). Am i overlooking them somewhere? Could they be included as part of this PR?

@nickrobinson251 I looked over some of those and many of those are for the internal AP (not the case of add_service. I agree that we need to go over the code and add more docstrings but I don't think that we can get it done for this PR which focused on the documentation of the model library. The next one will intend to document the functions in base.jl and their use to manipulate System

Yah, i was just think of the ones that already have docstrings in the src code, but which weren't (yet) in the docs.  Maybe there are a few others like that? Thanks for adding System! 😊
I'll read through things a bit more now 😄

Yah, i was just think of the ones that already have docstrings in the src code, but which weren't (yet) in the docs. Maybe there are a few others like that? Thanks for adding System! 😊
I'll read through things a bit more now 😄

Yeah, I made some tests on how the documentation looked and read several blogs on how to go about it and I went with this concept based on the fact that we expect users who are modelers and Power Systems engineers (like me) and will need more hand-holding.

Document the public API with the appropriate examples close to each other.
Document the Library of structs and their files separately.
Make the generic API section just for the internal functions for those interested in going deeper into the codebase.

Point 2 is what makes the documentation slightly harder to code since I couldn't find a way to tell the documenter to autogenerate the docstrings for all public methods but leave out the getter and setter functions from the library. At the same time, I wanted an automated way to generate those upon the addition of new structs.

The Quick Start Guide is currently blank.  I know that this is not expected to be complete.  Would it be simple to add a link to the SIIP examples page for now?


Support multiple image tags in generate/build commands

🚀 Feature Description
As a fan of the docker-metadata action, I'd like to be able to plug in the tag outputs to aspirate, in order to quickly push multiple tags at once. E.g. if I have a version 1.2.3, I can push tags 1.2.3, 1.2, and latest in one go.
✔ Goals

[ ] Support passing multiple tags with --container-image-tags or maybe multiple --container-image-tag entries

🧰 Possible Solution

--container-image-tags can match to the ContainerImageTags MSBuild property

Currently it's not possible to use this property even when defining it in the csproj file, as Aspirate will still put in -p:ContainerImageTag="latest", which conflicts and causes a build error. The two versions are mutually exclusive.

🚧 Blocked by

Nothing hopefully?

Great idea - I'll implement Monday

Sorry - I completely forgot about this - was on my todo list
Just been released in 0.6.15 - you can supply multiple tags to both build and generate
latest tag is always included, and is used in manifest generation though.


The web browsable API does not render correctly

Issue Type

Bug report

Expected Behavior

The Web browsable version of the API should render correctly in a web browser.
Current Behavior

The CSS, javascript and static files required to render the API in HTML are not found (the requests return 404s)
Possible Solution

Steps to Reproduce (for bugs)

Open a web browser
Go to http://api.requestyoracks.org/

Your Environment

Version used: 0.1.3
Browser Name and version: Chrome 66.0.3359.139 or Firefox 59.0.2
Operating System and version (desktop or mobile): OSX

This was fix in the deployment using the nginx-ingress-controller instead of the GCE L7 controller.


Motioneye 0.10.0 , motion fails to start error, no camera feed anymore

The problem
Hi,
just updated my addon to 0.10.0 , i use it only for 1 local attached USB camera, but it doesnt worj anymore, no more feed
Environment

Add-on with the issue: 0.10.0
Last working add-on release (if known):  0.9.0
Operating environment (OS/Supervised):  HassOS

Traceback/Error logs
WARNING: Connect error on fd 14: ECONNREFUSED
 WARNING: Connect error on fd 14: ECONNREFUSED
 WARNING: Connect error on fd 14: ECONNREFUSED
 WARNING: Connect error on fd 14: ECONNREFUSED
 WARNING: Connect error on fd 14: ECONNREFUSED
 WARNING: Connect error on fd 14: ECONNREFUSED
 WARNING: Connect error on fd 14: ECONNREFUSED
 WARNING: Connect error on fd 14: ECONNREFUSED
 WARNING: Connect error on fd 14: ECONNREFUSED
 WARNING: Connect error on fd 14: ECONNREFUSED
[23/Sep/2020:22:40:23 +0200] 200 -(<IP_ADDRESS>) GET /picture/1/current/?_=1600893618411&_username=admin&_signature=cdca49ff4fe8af2a241afde955e056cfdb488633 HTTP/1.1 (Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.121 Safari/537.36)
 WARNING: Connect error on fd 14: ECONNREFUSED
[23/Sep/2020:22:40:23 +0200] 200 -(<IP_ADDRESS>) GET /picture/2/current/?_=1600893618411&_username=admin&_signature=4844726a6a1ee0e32e6b49c15828dcd7990577ee HTTP/1.1 (Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.121 Safari/537.36)
 WARNING: Connect error on fd 13: ECONNREFUSED
   ERROR: motion not running, starting it
   ERROR: failed to start motion: motion failed to start
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/motioneye/server.py", line 325, in checker
    motionctl.start()
  File "/usr/lib/python2.7/site-packages/motioneye/motionctl.py", line 129, in start
    raise Exception('motion failed to start')
Exception: motion failed to start
   ERROR: motion not running, starting it
   ERROR: failed to start motion: motion failed to start
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/motioneye/server.py", line 325, in checker
    motionctl.start()
  File "/usr/lib/python2.7/site-packages/motioneye/motionctl.py", line 129, in start
    raise Exception('motion failed to start')
Exception: motion failed to start
   ERROR: motion not running, starting it
   ERROR: failed to start motion: motion failed to start

Update to v0.10.1


Fails with new browsers (firefox/chrome)

Minimal example
In a javascript
  //-- Is the clipboard supported?
  if(Clipboard.isSupported()) {
    $(".__ClipboardCopy").show();
  }
  else {
    $(".__ClipboardCopy").hide();
  }

  //-- Connect to any copy buttons...
  this.theClipboard = new Clipboard('.__ClipboardCopy');

In the html:

Expected behaviour
Clicking on the resulting link does not copy the text into the clipboard.
When I connect toe success event, I see the values all present correctly. regardless of the browser
Actual behaviour
It fails silently (meaning everything appears to work, however the text being copied never shows up in the clipboard.
Browsers affected
Doesnt work in Firefox 58.0.1 64 bit.
Doesnt work in Chrome Version 63.0.3239.132 (Official Build) (64-bit)
Works with Edge and IE.

This fails for me in Chrome Version 63.0.3239.132 (Official Build) (64-bit) but works in Safari Version 11.0.3 (126<IP_ADDRESS>.1).

Hey @JohnBergman @frodopwns @josephfusco, @jlahijani, @hannesb, @philcook, @carlosgomez2, @brucek @christianseel, I need your help to understand the real problem here.
I opened clipboardjs.com on the following browsers and ran Clipboard.isSupported() on the console, here's the result:
Do you get something different than this?

Might be related to this problem: If you use jQuery dialogs, you have to set the container property in the Clipboard constructor to an element of the dialog. If you stay with the default behavior (container set to document.body), execCommand('copy') will not work with some browsers.
That's what I found out when trying to use clipboard.js with Serenity (great platform btw.)

Problem turned out to be model window specific for me. Solved here: https://github.com/zenorocha/clipboard.js/pull/368.

Got it. In that case, I'm going to close this issue. Thanks guys!


Header name X-Forefront-Antispam-Report is replaced with CIP

Parsing EXO headers will add CIP as header and X-Forefront-Antispam-Report header name is missing .
CIP is not the header name.
Who is looking/searching directly for this might be distracted

Can you paste in text a set of headers which reproduce this? I didn't repro with my attempt.

yesterday it worked with any header.
Today tested with some and the behavior is:

X-Forefront-Antispam-Report is not shown anymore in "Other headers", but listed as source header see bellow:

so today that CIP instead of X-Forefront-Antispam-Report is not anymore in the other headers, but the header itself is named "source header"

Is this expected new design change? Any reasons to do this?
Shouldn't be kept as "X-Forefront-Antispam-Report" in "Other headers"?
Attached the header from last test.
test header.txt

by the way: "X-Forefront-Antispam-Report-Untrusted" looks good under "other headers"
test header2.txt

I'm still not understanding what you're saying is wrong about how it's rendered.

X-Forefront-Antispam-Report is not shown anymore in "Other headers", but listed as source header see bellow:
Yes - are you saying that's wrong?

so today that CIP instead of X-Forefront-Antispam-Report is not anymore in the other headers, but the header itself is named "source header"
Yes - the contents of the X-Forefront-Antispam-Report header are the source for that section, so I included them verbatim as the source header. Are you saying that's wrong? Why do you call out that the header value start with CIP? Is that not correct?

Is this expected new design change?
Not sure how to answer this. I mean - I wrote the code, so I guess I expected to do it? But if you're saying something is wrong about it I'd like to understand the issue before I commit to saying it's the expected design.

Any reasons to do this?
I realized there were fields in the antispam reports that weren't getting parsed out. Some of them were documented, some weren't. The documented ones get parsed out and the remaining ones are unknown fields. In case anything about the parsing is wrong, I also show the original header untouched.

Shouldn't be kept as "X-Forefront-Antispam-Report" in "Other headers"?
After the work I did on the antispam report parsing, the extra copy down in other headers became redundant, so I removed it. I did the same with the received headers, to, from, subject etc that all appear in their own sections. None of them belong in Other so I removed them. Are you saying this was the wrong choice?

Figured out what's going on. If you go look for message headers in OWA right now, all leading spaces are stripped. So while the header in proper RFC format should look like this:

from OWA, it looked like this:

with no leading spaces. To any header parser, this looks like a new header named CIP.
This is a bug in OWA that likely affects parsing of several headers. I'll have to see if I can do anything to handle this bad data better.

BTW - this only affects standalone with user supplied header text. Add-in pulls the headers itself and has no problem.

Has there been any action on this item? I can concur that this is an issue when pulling the message header manually from OWA. Is there anything that I can do to rattle the cage for the OWA team on this? Has there been any acknowledgement or interest? Thanks.

Has there been any action on this item? I can concur that this is an issue when pulling the message header manually from OWA. Is there anything that I can do to rattle the cage for the OWA team on this? Has there been any acknowledgement or interest? Thanks.

Is there anything that I can do to rattle the cage for the OWA team on this?

You'd need to report the issue to the OWA team first.

I opened a ticket in mid February through Office 365 Partner Support. It was eventually elevated to the product team. The product team hasn't officially reported back on the ticket yet, but according to my testing, message headers are now formatting correctly via OWA and can be parsed by MHA.


fix #11

review @iTakeshi @DavidDudson @dveim

Merging this, since there are no comments. If you guys have additional thoughts, let me know here or on gitter.

@xeno-by  I apologise, I looked at the code and it was fine. I was going to do some testing first before replying.
When will this be in 3.0.0 snapshot? I want to start using it :)

It already is :) I'll now look into the multiple expansion thing.

@xeno-by My apologies for the late response. Although the code worked fine, I was just wondering if we could remove the boilerplate: val q"new $_($greeting)" = this. I'm still trying on it and I'll send a new PR when it become available.
Thanks

@iTakeshi I understand that it would be nice to have a simpler syntax, but then it won't quite work with the general design for inline macros described.
For example, what if an inline method defines a def macro and not a macro annotation? In that case, the prefix of the call (the part that corresponds to this) may not be of the form new Something(something). Then, the proposed shortcut will no longer work.
Another illustration of this is provided in https://gist.github.com/xeno-by/9d7a709b1ba7c2ee64cfedcc5d264bd5#intuition. What do you think?

@xeno-by Even though I understand your concern, but I think it's still worth considering a solution to provide a way to reduce boilerplates, especially for this case because annotation macro is one of the most broadly used form of macro implementation. Simpler syntax also encourage users to upgrade their code to use new style inline macros instead of legacy blackbox/whitebox.
I'm racking my brain to find an ideal solution which solves both my concern: reducing boilerplates and your concern: generality.


Minor English grammar errors in logs

PHP Version: 8.2   | Shopware Version: <IP_ADDRESS>  | Affected area / extension: Platform(Default)

Expected behaviour:
Sorry in advance. I have no idea where to report this otherwise:
Using "does not exist" would be correct.
Actual behaviour:
"does not exists" is incorrect English.

How to reproduce:
Search code for "does not exists".
Thanks.

[public] Shopware automated response: This issue is linked to the internal issue: NEXT-39460
[created from NEXT-39460, comment 510578]

Hey there, thanks for your detailed description of the issue.
Feel free to provide a fix that corrects the typos. However, we do not consider this a bug and won't prioritize it.
Also note that it seems to be not a shopware exclusive "issue" as some of the usages you found are from dependencies we use and not shopware itself, e.g. symfony.


Add Functionality to show which folders a given Group/User has access to

Currently the only way to find out is to create a temp user, add it to the group and try it out.  Even harder for  user perms without speaking to the user.
"needs a View as user dropdown feature so you can look at the main tree as a specific user/grp, or in the user/grp perms edit screen have a little tree that shows what is visible"
Would need some idea of permissions in the results otherwise a "Use=all" perm would show everything but the user/group could see nothing.

We could potentially have a Document Permissions screen that is a bit similar to the app perms one.  I.e. have the table of Users/Groups at the top (with a tab for Users/Groups), then underneath have a table that lists all items that the user/group has >=1 doc perm for.  The table would have a column for each perm type and a quick filter so you could filter it by different perm types.  The table would need nesting/folding to mimic the explorer tree.
The screen could also show pipe filter ownership, i.e. list all pipelines and their filters that the user owns, maybe with the ability to change ownership of a filter.

Relates to #1000

Relates to #207 (in terms of proc filter ownership)

This would also assist with deleting users. Currently a FK constraint prevents a user record from being deleted until all permissions for that user are removed.

This would also assist with deleting users. Currently a FK constraint prevents a user record from being deleted until all permissions for that user are removed.

Raised #3662 for this.  Shouldn't need to have to manually delete all the perms.


feat: add reddit into social share

Thanks for the PR @megatheikal ! Really appreciate the contribution! 🙌🏼


feat: add launchers and documentation for distributed setup

Added documentation and launchers for the distributed setup. Feel free to suggest improvements.

If you want, I can also change the apptainer redis setup to a bash script to locally compile redis (since most HPC clusters don't allow installing packages, it has to be one of the two)


Stackdriver: don't write cumulative metrics if they haven't changed

Is your feature request related to a problem? If so, please describe it.
Trying to minimize Stackdriver costs.
We have a cumulative metric that only changes rarely, but we'd still like to track it. The default settings seem to be that the cumulative metric is written every minute after the first time it's recorded to a non-zero value.
Describe the solution you'd like.
Don't write cumulative metrics to Stackdriver if there was no change from the most recent write.
Describe alternatives you've considered.

not track the relevant metrics
reduce the reporting interval for that metric (it looks like the Stackdriver exporter has a single reporting interval for all metrics)
change from a cumulative metric to a non-cumulative metric - we're measuring time, and dropping intermediate values does not seem attractive

Additional context.
https://cloud.google.com/stackdriver/pricing#monitoring-costs

Technically, this also applies to other metrics but cumulative metrics are 10x more expensive than normal ones.

We believe that this change would reduce our metric volume (and costs) by 2-3x, and we could work on the implementation if there's interest in merging something like this.

Please note that OpenCensus is not being actively developed anymore, and we are not accepting new feature requests.
The project has been replaced with the OpenTelemetry project: https://opentelemetry.io/, so you may be interested in contributing there instead.
As you mentioned, the current workaround is to increase the reporting interval among others. You may also be interested in a more detailed breakdown for a similar issue: https://github.com/census-ecosystem/opencensus-go-exporter-stackdriver/issues/270#issuecomment-657440772

So the old one is deprecated and the new one doesn't work yet? We're not going to switch to a 'beta' API for our production code, and we need to have this fixed now, so I went ahead, forked it, and then patched our fork. I can send you a PR or not, but based on your response I take it the answer is not.


Is there a way to add invariants as in the GUI?

Hi, thanks for this really nice plugin. I am learning TLA+ and PlusCal and in the guides we defined invariants as part of the PlusCal and then use the GUI to mark them as invariants. Is there a way to achieve something similar here?
I am also open to pluscal or TLA+ tips. Whats the best way of expressing an invariant in pluscal? Maybe having a label at the end of the algorithm which thus will be part of every state of the spec?
begin
  ... algorithm
  VerifyInvariant:
    assert Invariant;

Related: https://github.com/tlaplus/vscode-tlaplus/issues/159

The VSCode extension does not have a model editor.  You will have to write TLC's configuration files by hand
An invariant is true in every state, but only asserted at the label VerifyInvariant in your example.  Define your invariant in PlusCal's define block or after its TLA+ translation, and add INVARIANT Invariant in TLC's configuration file

Great! Thanks. For any other noobs with the same questions. When you run the TLC with TLA+: Check model with TLC TLC will auto-generate a .cfg file with the same name as your .tla file. In this file you can add the INVARIANT MyInvariant at the bottom and for any consecutive runs of TLC it will also check that invariant.
Thanks @lemmy!


Revise message codecs for Dart 2.0 fixed-size integers

In Dart 2.0, int type is going to be a fixed-size 64-bit integer. See https://github.com/dart-lang/sdk/blob/master/docs/language/informal/int64.md for details.
Flutter message codecs support sending/receiving large integers, so we might consider revising this API to better fit fixed-size integers (either drop support for large integers, or use the new Dart BigInt class).
This change updates message codecs test to stop using large integer literals (which are illegal in Dart 2.0)
/cc @mravn-google @cbracken @floitschG

I suggest we drop support for large integers in the codec, as it was included there only because Dart's int wasn't fixed size.
What is the timeline for this change to Dart? Is there any real risk that we'll have to back out of it? (I'm trying to understand when it would be a good time to remove the codec's large int support. I want to do it ASAP so that few users will come to depend upon it -- unless we have reason to doubt that the Dart change is going to happen within a reasonable time frame.)


Function syntax highlighting

Added syntax highlighting for functions and function calls. It does not change the highlighting of the built in functions such as yield, rand_range, ceil ect.

Just tested the patch locally, it looks good. However, I wonder if we should add an option to disable function highlighting? It's a relatively big visual change as functions are used everywhere, so maybe some users would like to keep the previous behaviour?
It's of course possible to define the function colour to be the same as the text colour, but a checkbox for that could be useful too. I don't have a strong opinion myself, just wanted to gather some feedback.

@akien-mga I think it's fine as is. If someone doesn't like it, they can just change to the Text Color, as you mentioned. Another option is to make the Function Color the same as normal Text Color by default.

Ok, let's merge and we'll add more options if someone complains :)


goog.forwardDeclare does not work with new type inference

Consider the following code:
var goog = {}
goog.forwardDeclare = function (x) {}
/** @const */ var x = {}
/** @constructor */ x.Foo = function () {}

goog.forwardDeclare('x.Foo2')

/** @param {x.Foo|x.Foo2} y */
function foo(y) {
}
foo(1)

If I run the compiler with old type inference, I get the warning
input0:11: WARNING - actual parameter 1 of foo does not match formal parameter
found   : number
required: (null|x.Foo|x.Foo2)

If I run the compiler with new type inference, I get the warning:
input0:8: WARNING - A union type that includes ? is equivalent to ?
/** @param {x.Foo|x.Foo2} y */

how can i get new type inference to process this code correctly?
for reference, here is the debugger link:
http://closure-compiler-debugger.appspot.com/#input0%3Dvar%2520goog%2520%253D%2520%257B%257D%250Agoog.forwardDeclare%2520%253D%2520function%2520(x)%2520%257B%257D%250A%252F**%2520%2540const%2520*%252F%2520var%2520x%2520%253D%2520%257B%257D%250A%252F**%2520%2540constructor%2520*%252F%2520x.Foo%2520%253D%2520function%2520()%2520%257B%257D%250A%250Agoog.forwardDeclare('x.Foo2')%250A%250A%252F**%2520%2540param%2520%257Bx.Foo%257Cx.Foo2%257D%2520y%2520*%252F%250Afunction%2520foo(y)%2520%257B%250A%257D%250Afoo(1)%26input1%26conformanceConfig%26externs%26refasterjs-template%26includeDefaultExterns%3D1%26CHECK_SYMBOLS%3D1%26CHECK_TYPES%3D1%26CHECK_TYPES_NEW_INFERENCE%3D1%26CLOSURE_PASS%3D1%26MISSING_PROPERTIES%3D1

Should be fixed at commit 8297e5cbc811fdcedf50acce814ffe410cd7f40d. I'm guessing it's not part of the release yet and you're not using head?

cool, thanks


Java version increase

https://github.com/Tkko/flutter_smart_auth/blob/2786f7b8cba8b9033fd8223bb8d88e2ff300614d/android/build.gradle#L36
Why is the java version so high?
Many packages are not yet on this version and we are having problems in most projects.
I suggest setting it to the following values
compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_8
    targetCompatibility JavaVersion.VERSION_1_8
}

kotlinOptions {
    jvmTarget = '1.8'
}

Hi @mbfakourii, good point. The official packages like SharedPreferences and ImagePicker are using VERSION_11 so it's better to set the same version, WDYT?

@mbfakourii  here is the PR you can review if you want.

Fixed in v3.1.0


Convector Framework

Proposal to include Convector Framework to Hyperledger Labs.

@walmon : It looks like your second commit failed to include the -s option to include the DCO signoff. Can you follow the instructions at https://github.com/hyperledger-labs/hyperledger-labs.github.io/pull/48/checks?check_run_id=25950638 to correct this?

The DCO needs to be addressed of course but otherwise I've looked into this before and I think it's a very interesting piece that fits well within the labs. Being the sponsor, I'll leave it to others to approve.

+1 via email.
Sent from my iPhone

On Oct 30, 2018, at 4:22 PM, Arnaud J Le Hors<EMAIL_ADDRESS>wrote:
The DCO needs to be addressed of course but otherwise I've looked into this before and I think it's a very interesting piece that fits well within the labs. Being the sponsor, I'll leave it to others to approve.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Thanks @tkuhrt @lehors @vipinsun, I fixed the DCO problem with the PR. But I saw the current repo (that we want to keep) has DCO issues as well, please give me 1 or 2 days to fix it so that we can continue using Convector's repo.

@walmon : Let us know. Getting the DCO corrected in the source repo will allow us to bring it over; otherwise, we will need to have you manually pull the source code over to a new repo.

+1

@tkuhrt : done, we signed every commit on the source repo to reuse it. https://github.com/worldsibu/convector

I checked git log for both master and develop and I see log items that are not signed off.

@walmon unless you really want to carry over all of the history you do have the option to make a single commit with sign-off and be done with this. It's up to you.

@walmon : Yes, we did mean -s. In order to transfer the https://github.com/worldsibu/convector repository over to the Hyperledger-Labs organization, someone with Admin permissions in the worldsibu organization will need to transfer the repo to Github user tkuhrt. Then I can transfer the ownership into the hyperledger-labs organization.

@walmon : Any update on the transfer for the repository?

Hello everybody, I'm sorry I forgot to write here after talking with Arnaud last year. We had a lot of doubts regarding the Labs and this is a really important project for us, so you may imagine that we have to be really careful. So initially we decided to stop the application.
But we think that the Hyperledger Project can really benefit from Convector and the other way around. So we'd like to continue with the process. We'd love to see Convector graduate into a full-blown Hyperledger project, so it'd be great to know who to reach for us to focus on that.
We tried to transfer it to tkuhrt but we got an error since there's already a copy in your account @tkuhrt.
tkuhrt/convector already exists and You can only transfer a repository from an organization to yourself at this time

Let me know!

If the DCO issue is resolved transfer it to me, @ryjones
Thanks

Done @ryjones !

Done @ryjones !


Fixes and more sources

(1) Adds a bunch of new sources from https://github.com/funnel-io/product/issues/4502
(2) Adds a few underscores for sources & orgs where Google wants them.

Great!
@johannes-funnel could you also check "Reshift digital" they mentioned? It's missing org and icon

Merged upstream in https://github.com/googledatastudio/ds-data-registry/pull/113 🎉


[magento] Update EoL for 2.4, 2.3

According to https://www.adobe.com/content/dam/cc/en/legal/terms/enterprise/pdfs/Magento-Open-Source-Software-Maintenance-Policy.pdf
Open Source 2.3
End of Magentoprovided bug fix maintenance: July 2021
End of Magento-provided security maintenance: September 2022
Open Source 2.4.0-2.4.3
End of Magentoprovided bug fix maintenance: November 2022
End of Magento-provided security maintenance: November 2022

Do you mind splitting up 2.4.0-2.4.3 into 4 separate rows? Will be cleaner on the API.

Split up done and also fixed the urls to release notes.


Unable to use letsencrypt certification generation

Trying to use the registry with Letsencrypt builtin automatic certification generation fails with following error:

Error 403 - urn:acme:error:unauthorized - Account creation on ACMEv1 is disabled. Please upgrade your ACME client to a version that supports ACMEv2

As Letsencrypt as announced here the account creation using API v1 is impossible since November 2019. It would be good to refactor registry to use the new ACMEv2 API to create account.

In the meantime, anyone who needs to start a registry manually with Lets Encrypt... click Details:

Run certbot in standalone mode to generate certificates:
$ sudo certbot certonly --standalone

...

 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/example.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/example.com/privkey.pem

...

Files inside /etc/letsencrypt/live/example.com are symlinks! So you can't just mount the domain-specific folder when starting the container.
Instead you need to mount the whole letsencrypt-folder in order to keep the symlink paths intact. Relevant options for docker run:
  -e REGISTRY_HTTP_ADDR="<IP_ADDRESS>:443" \
  -v /etc/letsencrypt:/etc/letsencrypt \
  -e REGISTRY_HTTP_TLS_CERTIFICATE=/etc/letsencrypt/live/example.com/fullchain.pem \
  -e REGISTRY_HTTP_TLS_KEY=/etc/letsencrypt/live/example.com/privkey.pem \
  registry:2

Note that, as usual with certbot standalone, you should also remember to add a cronjob to run certbot renew automatically.

Five months and not so much as peep re a documented feature that simply doesn't work as advertised? Boooo.

Got the same issue here
msg="register: acme: Error 403 - urn:acme:error:unauthorized - Account creation on ACMEv1 is disabled. Please upgrade your ACME client to a version that supports ACMEv2 / RFC 8555. See https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430 for details."

I was able to get this to work on June 25, 2020.  But I had to recompile the registry binary and update the image with it.

To recompile the registry executable, make a directory, change to it, and run this:

mkdir fixme
cd fixme
docker run --rm -v $(pwd):/mnt -it golang:alpine /bin/bash -c "apk update; apk upgrade; apk add --no-cache bash git openssh;go get github.com/docker/distribution/cmd/registry; mkdir /mnt/bin; cp -v /go/bin/registry /mnt/bin"

To build a registry image that works, use this Dockerfile from the directory you created:

FROM registry:latest
COPY ./bin/registry /bin/registry

For the devs, the probable quick fix here is to rebuild your 1.8 image with current golang libraries; I think that the library that enables Let's Encrypt has recently been updated to use the ACME 2.0 protocol and we just need to recompile against it.

I was able to get this to work on June 25, 2020. But I had to recompile the registry binary and update the image with it.

To recompile the registry executable, make a directory, change to it, and run this:

mkdir fixme
cd fixme
docker run --rm -v $(pwd):/mnt -it golang:alpine /bin/bash -c "apk update; apk upgrade; apk add --no-cache bash git openssh;go get github.com/docker/distribution/cmd/registry; mkdir /mnt/bin; cp -v /go/bin/registry /mnt/bin"

To build a registry image that works, use this Dockerfile from the directory you created:

FROM registry:latest
COPY ./bin/registry /bin/registry

Trying to run that i get:
docker: Error response from daemon: OCI runtime create failed: container_linux.go:345: starting container process caused "exec: "/bin/bash": stat /bin/bash: no such file or directory": unknown.

Ditto

@dorgan and @robogeek, I goofed the shell to use.  I updated the docker command; it now uses /bin/sh, not /bin/bash. I verified that it works on Ubuntu 2004 on Windows, so it should behave itself on any *nix system now. You also don't need the additional mkdir and cd statements, as long as you don't mind a ./bin directory in your current dir when running the docker command.

@wilminator  I did not get the /bin/bash error.  Instead I got the error at the top about ACME v1.

@robogeek, I want to know if you tried using the stock registry image or if you tried my fix. Thanks.

I used registry:latest

To complete @wilminator answer: the docker container was unable to reach the DNS in my setting, so I added the --network host option, and it worked like a charm.

To recompile the registry executable, make a directory, change to it, and run this:

docker run --rm -v $(pwd):/mnt --network host -it golang:alpine /bin/sh -c "apk update; apk upgrade; apk add --no-cache bash git openssh;go get github.com/docker/distribution/cmd/registry; mkdir /mnt/bin; cp -pv /go/bin/registry /mnt/bin"

To build a registry image that works, use this Dockerfile from the directory you created:

FROM registry:latest
COPY ./bin/registry /bin/registry

I then ran
docker build --tag registry:fixed .
and used the registry:fixed image.

Hello, I've just been affected by this. As discussed above, LetsEncrypt are deprecating ACMEv1. As part of the process they're running brown-outs. I just so happened to be setting up a private docker repository when they started one.
Come on Docker! Get upgraded to ACMEv2 already!

Hello, I've just been affected by this. As discussed above, LetsEncrypt are deprecating ACMEv1. As part of the process they're running brown-outs. I just so happened to be setting up a private docker repository when they started one.
Come on Docker! Get upgraded to ACMEv2 already!

Trying to implement the answer from @wilminator and I'm getting the following output. I know next to nothing about golang, so I'm not sure where to even begin. Any help would be greatly appreciated.
go: downloading github.com/docker/distribution v2.7.1+incompatible
go: downloading github.com/Azure/azure-sdk-for-go v0.2.0-beta
go: downloading github.com/Azure/azure-sdk-for-go v52.3.1+incompatible
go: downloading github.com/Shopify/logrus-bugsnag v0.0.0-20171204204709-577dee27f20d
go: downloading github.com/aws/aws-sdk-go v1.37.28
go: downloading github.com/bshuster-repo/logrus-logstash-hook v1.0.0
go: downloading github.com/bugsnag/bugsnag-go v1.9.0
go: downloading github.com/bugsnag/bugsnag-go v2.1.0+incompatible
go: downloading github.com/denverdino/aliyungo v0.0.0-20210222084345-ddfe3452f5e8
go: downloading github.com/docker/go-metrics v0.0.1
go: downloading github.com/docker/libtrust v0.0.0-20160708172513-aabc10ec26b7
go: downloading github.com/garyburd/redigo v1.6.2
go: downloading github.com/gorilla/handlers v1.5.1
go: downloading github.com/gorilla/mux v1.8.0
go: downloading github.com/mitchellh/mapstructure v1.4.1
go: downloading github.com/ncw/swift v1.0.53
go: downloading github.com/opencontainers/go-digest v1.0.0
go: downloading github.com/opencontainers/image-spec v1.0.1
go: downloading github.com/sirupsen/logrus v1.8.1
go: downloading github.com/spf13/cobra v1.1.3
go: downloading github.com/yvasiyarov/gorelic v0.0.7
go: downloading golang.org/x/crypto v0.0.0-20210220033148-5ea612d1eb83
go: downloading golang.org/x/oauth2 v0.0.0-20210220000619-9bb904979d93
go: downloading google.golang.org/api v0.41.0
go: downloading google.golang.org/cloud v0.79.0
go: downloading google.golang.org/cloud/storage v1.14.0
go: downloading gopkg.in/yaml.v2 v2.4.0
go: downloading rsc.io/letsencrypt v0.0.3
go get: google.golang.org/cloud@none updating to
<EMAIL_ADDRESS>parsing go.mod:
        module declares its path as: cloud.google.com/go
                but was required as: google.golang.org/cloud
cp: can't stat '/go/bin/registry': No such file or directory

Trying to implement the answer from @wilminator and I'm getting the following output. I know next to nothing about golang, so I'm not sure where to even begin. Any help would be greatly appreciated.
go: downloading github.com/docker/distribution v2.7.1+incompatible
go: downloading github.com/Azure/azure-sdk-for-go v0.2.0-beta
go: downloading github.com/Azure/azure-sdk-for-go v52.3.1+incompatible
go: downloading github.com/Shopify/logrus-bugsnag v0.0.0-20171204204709-577dee27f20d
go: downloading github.com/aws/aws-sdk-go v1.37.28
go: downloading github.com/bshuster-repo/logrus-logstash-hook v1.0.0
go: downloading github.com/bugsnag/bugsnag-go v1.9.0
go: downloading github.com/bugsnag/bugsnag-go v2.1.0+incompatible
go: downloading github.com/denverdino/aliyungo v0.0.0-20210222084345-ddfe3452f5e8
go: downloading github.com/docker/go-metrics v0.0.1
go: downloading github.com/docker/libtrust v0.0.0-20160708172513-aabc10ec26b7
go: downloading github.com/garyburd/redigo v1.6.2
go: downloading github.com/gorilla/handlers v1.5.1
go: downloading github.com/gorilla/mux v1.8.0
go: downloading github.com/mitchellh/mapstructure v1.4.1
go: downloading github.com/ncw/swift v1.0.53
go: downloading github.com/opencontainers/go-digest v1.0.0
go: downloading github.com/opencontainers/image-spec v1.0.1
go: downloading github.com/sirupsen/logrus v1.8.1
go: downloading github.com/spf13/cobra v1.1.3
go: downloading github.com/yvasiyarov/gorelic v0.0.7
go: downloading golang.org/x/crypto v0.0.0-20210220033148-5ea612d1eb83
go: downloading golang.org/x/oauth2 v0.0.0-20210220000619-9bb904979d93
go: downloading google.golang.org/api v0.41.0
go: downloading google.golang.org/cloud v0.79.0
go: downloading google.golang.org/cloud/storage v1.14.0
go: downloading gopkg.in/yaml.v2 v2.4.0
go: downloading rsc.io/letsencrypt v0.0.3
go get: google.golang.org/cloud@none updating to
<EMAIL_ADDRESS>parsing go.mod:
        module declares its path as: cloud.google.com/go
                but was required as: google.golang.org/cloud
cp: can't stat '/go/bin/registry': No such file or directory

Truth be told, I'm not a golang guy either; I just make the computers work ;)
It looks like an upstream Google cloud library was updated 4 hours before your post google-cloud-go and they renamed the library. Since the go.mod configuration file for registry still uses the old name, go panics because it downloaded a module that has a different name than what it was expecting.
The devs for this project probably need to fix their requirements file to use the new name of the Google Cloud module. I have submitted a ticket #3377, and if I have time will try to offer a patch to fix it.

Hello,
With some help from my issue respondents (@milosgajdos and @wy65701436), I was able to get a working registry executable built that supports ACME v2.
docker run --rm -v "C:\Users\me\docreg:/mnt" -it golang:alpine /bin/sh -c "apk update&& apk upgrade&& apk add --no-cache bash git openssh make&& cd /opt&& git clone https://github.com/docker/distribution&&cd /opt/distribution&& make binaries&& mkdir /mnt/bin; cp -v bin/registry /mnt/bin"
Does this work for you?

@wilminator That does! Thanks for tracking it down.

This is affecting me as well. What can I do to help move this forward?

Everyone, I have an answer. TL,DR: If we want Docker to fix their registry image, this is the wrong place to post this. Go to registry incompatible with Let's Encrypt #96 and post there.
I did some more digging because this project has quite a few recent commits. Also, the one-liner above to launch a container to compile the registry binary shows that the project itself works fine- we get a working binary.
The problem most of us are facing is that the Docker registry image has a two year old version of the registry binary baked in, and this repo does not control that binary.
@gsaraf To fix this we need to use an issue with the main Docker GitHub repo and propose a merge into docker/distribution-library-image and hope they compile that down into a new image for us. The location this updated binary needs to get stashed is at https://github.com/docker/distribution-library-image/tree/master/amd64. However, this is the "wrong" way to fix this. The reality is that they should recompile their own source tree to fix this issue; it looks like we need to prod them to do it.
See registry incompatible with Let's Encrypt #96 and upvote like is suggested in the comments. We can also clone the repo, run their update, confirm their updated binary is ACME v2 compliant, and submit a merge request. However, I'm not holding my breath to see if their source is v2 compatible without any hacking.

A better solution would be to stop relying on this link and docker official account and just published an updated image in a new official distribution account in docker hub.
While it is convenient to just have to use image registry:2, I don't mind switching to distribution/registry:2 if I can get an up-to-date image out of the box.

Still not fixed? 3 years have passed...

Would you like to open a PR @denissabramovs ?

Nope, why would i? I just installed certbot myself, issued certs through it and configured crontab.

Would you like to open a PR @denissabramovs ?

I don't think it is possible to open a PR that performs a clean compilation of the project using a recent go toolchain and deploy it…

What are you missing in the toolchain that prevents you from doing this work @Jean-Daniel?

What I am saying is that only the project maintainers can decide to release a new version and publish it (which is all that is needed to fix this issue, as go 1.18 is compatible with recent acme protocol). No PR can do that for you.

So I guess the request is probably for a new version to be tagged/released (and to make sure the official release binaries for it are built with Go 1.18+)? :sweat_smile:

Damn still no solution for this? 😥

Still an issue

@creekorful with the new release cut last night https://github.com/distribution/distribution/releases/tag/v3.0.0-alpha.1 would you mind taking it for a spin and test it.

Closing for the lack of noise from the OP. Feel free to reopen.


renderdoc: 0.34pre -> 0.91

Motivation for this change
Upstream got updated.
Things done

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

[x] NixOS
[ ] macOS
[ ] Linux

[ ] 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 nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Couldn't test qrenderdoc since it apparently insists on building against Qt 5.9.0 whereas KDE plasma is using 5.9.1 and it claims those are not compatible. If someone knows how to work around that, any help is very appreciated.

Figured out the Qt problem (mismanaged user channel was leaking) and everything's peachy again with #29790

This builds fine actually
Result in /tmp/nox-review-225khxqw
total 0
lrwxrwxrwx 1 demo users 58 22 nov.  00:10 result -> /nix/store/vw8zzbzp7315sl0mg2fpq71rwb238n7c-renderdoc-0.91

This broke the sandboxed and Hydra builds because the package attempts to download files during the build: https://hydra.nixos.org/build/65599152


Add support for blog Pin to Top

Add the priority attribute to blog posts and sort the blogs based on the value.

It is assumed that the lower the value, the higher the priority.
If empty, the default is to sort by release/modification time.

Implementation wise is relatively straightforward - add a new priority field to contentlayer and sort by priority and date.
Design wise is where it is tricky as I feel that there should be a change or notice to indicate that a particular post is pinned. Not sure if the current layout is the best for this. If you implement it on your end end, happy to add it to the list of blogs as a reference, but I don't think I will add it to the general repository.

Hi!
Another solution could be to add a featured section, with a "featured" field (instead of priority) set to true when needed.
If you want to implement this without making too many changes within the application, I think the best would be to create a "Featured" layout, and then import it into the desired page inside the app folder.
I think it is even possible not to show this new layout if there is no featured post, so the integration within the current application would be rather smooth.
Should be quite straightforward as well!

Hi!
Another solution could be to add a featured section, with a "featured" field (instead of priority) set to true when needed.
If you want to implement this without making too many changes within the application, I think the best would be to create a "Featured" layout, and then import it into the desired page inside the app folder.
I think it is even possible not to show this new layout if there is no featured post, so the integration within the current application would be rather smooth.
Should be quite straightforward as well!

Sounds like a good idea, I'll try it!

Hi!
Another solution could be to add a featured section, with a "featured" field (instead of priority) set to true when needed.
If you want to implement this without making too many changes within the application, I think the best would be to create a "Featured" layout, and then import it into the desired page inside the app folder.
I think it is even possible not to show this new layout if there is no featured post, so the integration within the current application would be rather smooth.
Should be quite straightforward as well!

Sounds like a good idea, I'll try it!

Hi again, if you want to have a look, I just implemented this on my i18n template!

Hi!
Another solution could be to add a featured section, with a "featured" field (instead of priority) set to true when needed.
If you want to implement this without making too many changes within the application, I think the best would be to create a "Featured" layout, and then import it into the desired page inside the app folder.
I think it is even possible not to show this new layout if there is no featured post, so the integration within the current application would be rather smooth.
Should be quite straightforward as well!

Sounds like a good idea, I'll try it!

Hi again, if you want to have a look, I just implemented this on my i18n template!

Woah, what a neat implementation! I will refer it, you really saved me a lot of trouble, thank you!


[REVIEW] krshdev

GitHub Profile Link
@krshdev - I just need a PFP review to see Eddie's reaction lol

This made me laugh!! Thank you !!


Question about tag scheme

Hi UKP team,
I want to try different tag scheme in my work.
Could you tell me if there is any difference between IOBES and BIOES in your implementation?
Thanks,
Peng

Hi @PengLU1101 ,
you can find an explanation of the different encodings in this paper:
https://arxiv.org/abs/1707.06799
The network supports BIO, IOB, and IOBES encoding. The names of these encodings are not really fixed in literature. Our BIO encoding is sometimes called IOB and in other cases it is called IOB2. Quite confusing.
IOBES and BIOES is usually the same encoding.
For our implementation I recommend the BIO encoding: B- notes the start of a tag, I- are the following tokens of the same tag and O is used for every token that has no tag.

Hi @PengLU1101 ,
you can find an explanation of the different encodings in this paper:
https://arxiv.org/abs/1707.06799
The network supports BIO, IOB, and IOBES encoding. The names of these encodings are not really fixed in literature. Our BIO encoding is sometimes called IOB and in other cases it is called IOB2. Quite confusing.
IOBES and BIOES is usually the same encoding.
For our implementation I recommend the BIO encoding: B- notes the start of a tag, I- are the following tokens of the same tag and O is used for every token that has no tag.

Thanks so much.


[Ubuntu] Fails to run when dotnet is installed outside ~/dotnet -  System.ComponentModel.Win32Exception (2): An error occurred trying to start process

Problem
I was getting the following error
Analyzing project(s)...Unhandled exception. System.ComponentModel.Win32Exception (2): An error occurred trying to start process '/home/i/dotnet/dotnet'
with working directory '/home/mustakim/code/just-an-email'. No such file or directory
   at System.Diagnostics.Process.ForkAndExecProcess(ProcessStartInfo startInfo, String resolvedFilename, String[] argv, String[] envp, String cwd, Boolean setCredentials, UInt32 userId, UInt32 groupId, UInt32[] groups, Int32& stdinFd, Int32& stdoutFd, Int32& stderrFd, Boolean usesTerminal, Boolean throwOnNoExec)
   at System.Diagnostics.Process.StartCore(ProcessStartInfo startInfo)
   at DotNetOutdated.Core.Services.DotNetRunner.Run(String workingDirectory, String[] arguments) in /home/runner/work/dotnet-outdated/dotnet-outdated/src/DotNetOutdated.Core/Services/DotNetRunner.cs:line 29
   at DotNetOutdated.Core.Services.DependencyGraphService.GenerateDependencyGraph(String projectPath) in /home/runner/work/dotnet-outdated/dotnet-outdated/src/DotNetOutdated.Core/Services/DependencyGraphService.cs:line 30
   at DotNetOutdated.Core.Services.ProjectAnalysisService.AnalyzeProject(String projectPath, Boolean runRestore, Boolean includeTransitiveDependencies, Int32 transitiveDepth) in /home/runner/work/dotnet-outdated/dotnet-outdated/src/DotNetOutdated.Core/Services/ProjectAnalysisService.cs:line 28
   at DotNetOutdated.Program.<OnExecute>b__74_0(String path) in /home/runner/work/dotnet-outdated/dotnet-outdated/src/DotNetOutdated/Program.cs:line 179
   at System.Linq.Enumerable.SelectManySingleSelectorIterator`2.ToList()
   at DotNetOutdated.Program.OnExecute(CommandLineApplication app, IConsole console) in /home/runner/work/dotnet-outdated/dotnet-outdated/src/DotNetOutdated/Program.cs:line 179
   at McMaster.Extensions.CommandLineUtils.Conventions.ExecuteMethodConvention.InvokeAsync(MethodInfo method, Object instance, Object[] arguments)
   at McMaster.Extensions.CommandLineUtils.Conventions.ExecuteMethodConvention.OnExecute(ConventionContext context, CancellationToken cancellationToken)
   at McMaster.Extensions.CommandLineUtils.Conventions.ExecuteMethodConvention.<>c__DisplayClass0_0.<<Apply>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at McMaster.Extensions.CommandLineUtils.CommandLineApplication.ExecuteAsync(String[] args, CancellationToken cancellationToken)
   at McMaster.Extensions.CommandLineUtils.CommandLineApplication.Execute(String[] args)
   at DotNetOutdated.Program.Main(String[] args) in /home/runner/work/dotnet-outdated/dotnet-outdated/src/DotNetOutdated/Program.cs:line 129

From the error it was obvious that it's looking for dotnet executable in my home directory ~/dotnet/dotnet. However the default installation of dotnet is in /usr/share/dotnet folder (I installed it from the Microsoft package source by running sudo apt install dotnet-sdk-7.0) .
I fixed the issue by creating a softlink in the above folder.
Solution
cd ~/
ln -s /usr/share/dotnet dotnet

Suggestion
It would be nice if the tool detected the location of the dotnet executable. There might be better ways but the one I can think of is running which dotnet (in Linux + Mac) or where dotnet (in Windows) first that should return the path of the executable.

Similar issue, but it tries to use /usr/lib/dotnet/dotnet:
Analyzing project(s)...Unhandled exception. System.ComponentModel.Win32Exception (2): An error occurred trying to start process '/usr/lib/dotnet/dotnet' with working directory '/home/pavel/w/my-project/src'. No such file or directory
   at System.Diagnostics.Process.ForkAndExecProcess(ProcessStartInfo startInfo, String resolvedFilename, String[] argv, String[] envp, String cwd, Boolean setCredentials, UInt32 userId, UInt32 groupId, UInt32[] groups, Int32& stdinFd, Int32& stdoutFd, Int32& stderrFd, Boolean usesTerminal, Boolean throwOnNoExec)
   at System.Diagnostics.Process.StartCore(ProcessStartInfo startInfo)
   at DotNetOutdated.Core.Services.DotNetRunner.Run(String workingDirectory, String[] arguments) in /home/runner/work/dotnet-outdated/dotnet-outdated/src/DotNetOutdated.Core/Services/DotNetRunner.cs:line 29
   at DotNetOutdated.Core.Services.DependencyGraphService.GenerateDependencyGraph(String projectPath) in /home/runner/work/dotnet-outdated/dotnet-outdated/src/DotNetOutdated.Core/Services/DependencyGraphService.cs:line 30
   at DotNetOutdated.Core.Services.ProjectAnalysisService.AnalyzeProject(String projectPath, Boolean runRestore, Boolean includeTransitiveDependencies, Int32 transitiveDepth) in /home/runner/work/dotnet-outdated/dotnet-outdated/src/DotNetOutdated.Core/Services/ProjectAnalysisService.cs:line 28
   at DotNetOutdated.Program.<OnExecute>b__74_0(String path) in /home/runner/work/dotnet-outdated/dotnet-outdated/src/DotNetOutdated/Program.cs:line 179
   at System.Linq.Enumerable.SelectManySingleSelectorIterator`2.ToList()
   at DotNetOutdated.Program.OnExecute(CommandLineApplication app, IConsole console) in /home/runner/work/dotnet-outdated/dotnet-outdated/src/DotNetOutdated/Program.cs:line 179
   at McMaster.Extensions.CommandLineUtils.Conventions.ExecuteMethodConvention.InvokeAsync(MethodInfo method, Object instance, Object[] arguments)
   at McMaster.Extensions.CommandLineUtils.Conventions.ExecuteMethodConvention.OnExecute(ConventionContext context, CancellationToken cancellationToken)
   at McMaster.Extensions.CommandLineUtils.Conventions.ExecuteMethodConvention.<>c__DisplayClass0_0.<<Apply>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at McMaster.Extensions.CommandLineUtils.CommandLineApplication.ExecuteAsync(String[] args, CancellationToken cancellationToken)
   at McMaster.Extensions.CommandLineUtils.CommandLineApplication.Execute(String[] args)
   at DotNetOutdated.Program.Main(String[] args) in /home/runner/work/dotnet-outdated/dotnet-outdated/src/DotNetOutdated/Program.cs:line 129

I have .NET installed with apt from official Microsoft repositories.
> which dotnet
/usr/bin/dotnet

We faced the issue too, but for us, the problem was not related to dotnet-outdated, but rather due to the fact that after the installation of dotnet, the path variable pointing to the tool location is available the next time you log in with your shell.
dotnet-outdated can be instructed to the location of the tool by using the environment variable DOTNET_HOST_PATHDOTNET_HOST_PATH`. We used it in the past, before we moved our pipelines to containers.
In the latter case, the path is manually amended when building the container.


Blog: Reading data from external sources into a DataFrame

Read from External Sources

text file
database
scrape the web
read from pdf

Preview: https://deploy-preview-46--ayush-blog.netlify.app/ looks good. Merging.


No BINSTAR_TOKEN present on AppVeyor

python ci_support\upload_or_check_non_existence.py .\recipe conda-forge --channel=main
Using Anaconda Cloud api site https://api.anaconda.org
No BINSTAR_TOKEN present, so no upload is taking place. The distribution just built is not already available on conda-forge's main channel.
Build success

PS: @pelson this is probably affecting more packages.

My initial suspicion was the changes to conda-smithy recently, but the change looks to be only additive in this area: https://github.com/conda-forge/conda-smithy/compare/v0.6.0...v0.7.2#diff-d780142cb5b4b67f7a8fd097e056bba6R162
This will take a little time to investigate - I'll prioritise this issue over the next 24hrs. :+1:

The conda-forge.yml is a bit suspicious:
    BINSTAR_TOKEN: !!binary |
      TVA0aFpZeWxEeVVXRXNydDN1M2NvZDJzYkZlUndVemlIMDJtdlFPZGJqc1RPL2wxeUl4RGtQLzc2
      clNJamNHQw==

Looks like there are a few like this, though certainly not all of them:
grep "\!\!binary" * -r
awesome-slugify-feedstock/conda-forge.yml:    BINSTAR_TOKEN: !!binary |
bdw-gc-feedstock/conda-forge.yml:    BINSTAR_TOKEN: !!binary |
django-autoslug-feedstock/conda-forge.yml:    BINSTAR_TOKEN: !!binary |
django-debug-toolbar-feedstock/conda-forge.yml:    BINSTAR_TOKEN: !!binary |
django-extensions-feedstock/conda-forge.yml:    BINSTAR_TOKEN: !!binary |
django-typed-models-feedstock/conda-forge.yml:    BINSTAR_TOKEN: !!binary |
django_polymorphic-feedstock/conda-forge.yml:    BINSTAR_TOKEN: !!binary |
djangorestframework-feedstock/conda-forge.yml:    BINSTAR_TOKEN: !!binary |
eigen-feedstock/conda-forge.yml:    BINSTAR_TOKEN: !!binary |
freexl-feedstock/conda-forge.yml:    BINSTAR_TOKEN: !!binary |
json-c-feedstock/conda-forge.yml:    BINSTAR_TOKEN: !!binary |
libatomic_ops-feedstock/conda-forge.yml:    BINSTAR_TOKEN: !!binary |
libffi-feedstock/conda-forge.yml:    BINSTAR_TOKEN: !!binary |
libmatio-feedstock/conda-forge.yml:    BINSTAR_TOKEN: !!binary |
libunistring-feedstock/conda-forge.yml:    BINSTAR_TOKEN: !!binary |
luigi-feedstock/conda-forge.yml:    BINSTAR_TOKEN: !!binary |
netcdf-cxx4-feedstock/conda-forge.yml:    BINSTAR_TOKEN: !!binary |
opencv-feedstock/conda-forge.yml:    BINSTAR_TOKEN: !!binary |
pytest-benchmark-feedstock/conda-forge.yml:    BINSTAR_TOKEN: !!binary |
pytest-django-feedstock/conda-forge.yml:    BINSTAR_TOKEN: !!binary |
regex-feedstock/conda-forge.yml:    BINSTAR_TOKEN: !!binary |
requests-toolbelt-feedstock/conda-forge.yml:    BINSTAR_TOKEN: !!binary |
setuptools_scm-feedstock/conda-forge.yml:    BINSTAR_TOKEN: !!binary |
sox-feedstock/conda-forge.yml:    BINSTAR_TOKEN: !!binary |

Turns out to be the difference between py2 and py3 from https://github.com/conda-forge/staged-recipes/pull/217.
I'll get a fix into conda-smithy asap.

OK, we shouldn't be getting any more feedstocks which have this problem. Time for some PRs...

Here they come: https://github.com/conda-forge/libmatio-feedstock/pull/2

Thanks for the quick fix @pelson!


extremely slow processing when using a custom dataset

processing a custom dataset loaded as .txt file  is extremely slow,  compared to a dataset of similar volume from the hub
I have a large .txt file of 22 GB which i load into HF dataset
lang_dataset = datasets.load_dataset("text", data_files="hi.txt")
further i use a pre-processing function to clean the dataset
lang_dataset["train"] = lang_dataset["train"].map(             remove_non_indic_sentences, num_proc=12, batched=True,  remove_columns=lang_dataset['train'].column_names), batch_size=64)
the following processing takes astronomical time to process, while hoging all the ram.
similar dataset of same size that's available in the huggingface hub works completely fine. which runs the same processing function and has the same amount of data.
lang_dataset = datasets.load_dataset("oscar-corpus/OSCAR-2109", "hi",  use_auth_token=True)
the hours predicted to preprocess are as follows:
huggingface hub dataset:  6.5 hrs
custom loaded dataset: 7000 hrs
note: both the datasets are almost actually same, just provided by different sources with has +/- some samples, only one is hosted on the HF hub and the other is downloaded in a text format.
Steps to reproduce the bug
import datasets
import psutil
import sys
import glob
from fastcore.utils import listify
import re
import gc

def remove_non_indic_sentences(example):
    tmp_ls = []
    eng_regex = r'[. a-zA-Z0-9ÖÄÅöäå _.,!"\'\/$]*'
    for e in listify(example['text']):
        matches = re.findall(eng_regex, e)
        for match in (str(match).strip() for match in matches if match not in [""," ", "  ", ",", " ,", ", ", " , "]):
            if len(list(match.split(" "))) > 2:
                e = re.sub(match," ",e,count=1)
        tmp_ls.append(e)
        gc.collect()
    example['clean_text'] = tmp_ls
    return example

lang_dataset = datasets.load_dataset("text", data_files="hi.txt")

lang_dataset["train"] = lang_dataset["train"].map(
            remove_non_indic_sentences, num_proc=12, batched=True,  remove_columns=lang_dataset['train'].column_names), batch_size=64)

## same thing work much faster when loading similar dataset from hub

lang_dataset = datasets.load_dataset("oscar-corpus/OSCAR-2109", "hi", split="train", use_auth_token=True)

lang_dataset["train"] = lang_dataset["train"].map(
            remove_non_indic_sentences, num_proc=12, batched=True,  remove_columns=lang_dataset['train'].column_names), batch_size=64)

Actual results
similar dataset of same size that's available in the huggingface hub works completely fine. which runs the same processing function and has the same amount of data.
`lang_dataset = datasets.load_dataset("oscar-corpus/OSCAR-2109", "hi", use_auth_token=True)
the hours predicted to preprocess are as follows:
huggingface hub dataset:  6.5 hrs
custom loaded dataset: 7000 hrs
i even tried the following:

sharding the large 22gb text files into smaller files and loading
saving the file to disk and then loading
using lesser num_proc
using smaller batch size
processing without batches ie :  without batched=True

Environment info

datasets version: 2.2.2.dev0
Platform: Ubuntu 20.04 LTS
Python version: 3.9.7
PyArrow version:8.0.0

Hi !
My guess is that some examples in your dataset are bigger than your RAM, and therefore loading them in RAM to pass them to remove_non_indic_sentences takes forever because it might use SWAP memory.
Maybe several examples in your dataset are grouped together, can you check len(lang_dataset["train"]) and lang_dataset["train"].data.nbytes of both datasets please ? It can also be helpful to check the distribution of lengths of each examples in your dataset.


Forseti requests[security] version conflicts

Tested with current Terraform Forseti module at head, commit cf59de4
Got this error at forset startup
Traceback (most recent call last):
File "/usr/local/bin/forseti", line 30, in
sys.exit(load_entry_point('forseti-security==2.25.1', 'console_scripts', 'forseti')())
File "/usr/local/lib/python3.6/dist-packages/pkg_resources/init.py", line 490, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "/usr/local/lib/python3.6/dist-packages/pkg_resources/init.py", line 2862, in load_entry_point
return ep.load()
File "/usr/local/lib/python3.6/dist-packages/pkg_resources/init.py", line 2461, in load
self.require(*args, **kwargs)
File "/usr/local/lib/python3.6/dist-packages/pkg_resources/init.py", line 2484, in require
items = working_set.resolve(reqs, env, installer, extras=self.extras)
File "/usr/local/lib/python3.6/dist-packages/pkg_resources/init.py", line 792, in resolve
raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.VersionConflict: (requests 2.23.0 (/usr/local/lib/python3.6/dist-packages), Requirement.parse('requests[security]==2.21.0'))

@gkowalski-google ptal whenever you get a chance

Hi @xingao267, sorry for the delay. I did look into this, but I was not able to repro. Can you provide any specifics about how you are running into this error?

@gkowalski-google thanks for looking into this, it seems this error might be just a one-off or fixed from upstream.
Now I'm getting a different error when the forseti scan run invokes config validator. You can probably reproduce it by manually triggering a forseti scan run with config validator enabled.
[forseti-security][2.25.1] google.cloud.forseti.scanner.scanner(run): Error running scanner: ConfigValidatorScanner: 'Traceback (most recent call last): File "/usr/local/lib/python3.6/dist-packages/forseti_security-2.25.1-py3.6.egg/google/cloud/forseti/scanner/scanners/config_validator_util/validator_client.py", line 196, in reset self.stub.Reset(validator_pb2.ResetRequest()) File "/usr/local/lib/python3.6/dist-packages/grpc/_channel.py", line 565, in __call__ return _end_unary_response_blocking(state, call, False, None) File "/usr/local/lib/python3.6/dist-packages/grpc/_channel.py", line 467, in _end_unary_response_blocking raise _Rendezvous(state, None, None, deadline) grpc._channel._Rendezvous: <_Rendezvous of RPC that terminated with: status = StatusCode.INTERNAL details = "Not supported" debug_error_string = "{"created":"@1593613332.600850846","description":"Error received from peer ipv6:[::1]:50052","file":"src/core/lib/surface/call.cc","file_line":1052,"grpc_message":"Not supported","grpc_status":13}" > During handling of the above exception, anothe Traceback (most recent call last): File "/usr/local/lib/python3.6/dist-packages/forseti_security-2.25.1-py3.6.egg/google/cloud/forseti/scanner/scanners/config_validator_util/validator_client.py", line 196, in reset self.stub.Reset(validator_pb2.ResetRequest()) File "/usr/local/lib/python3.6/dist-packages/grpc/_channel.py", line 565, in __call__ return _end_unary_response_blocking(state, call, False, None) File "/usr/local/lib/python3.6/dist-packages/grpc/_channel.py", line 467, in _end_unary_response_blocking raise _Rendezvous(state, None, None, deadline) grpc._channel._Rendezvous: <_Rendezvous of RPC that terminated with: status = StatusCode.INTERNAL details = "Not supported" debug_error_string = "{"created":"@1593613332.600850846","description":"Error received from peer ipv6:[::1]:50052","file":"src/core/lib/surface/call.cc","file_line":1052,"grpc_message":"Not supported","grpc_status":13}" > During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/local/lib/python3.6/dist-packages/forseti_security-2.25.1-py3.6.egg/google/cloud/forseti/scanner/scanner.py", line 119, in run scanner.run() File "/usr/local/lib/python3.6/dist-packages/forseti_security-2.25.1-py3.6.egg/google/cloud/forseti/scanner/scanners/config_validator_scanner.py", line 203, in run for flattened_violations in self._retrieve_flattened_violations(): File "/usr/local/lib/python3.6/dist-packages/forseti_security-2.25.1-py3.6.egg/google/cloud/forseti/scanner/scanners/config_validator_scanner.py", line 178, in _retrieve_flattened_violations self.validator_client.reset() File "/home/ubuntu/forseti-security/.eggs/retrying-1.3.3-py3.6.egg/retrying.py", line 49, in wrapped_f return Retrying(*dargs, **dkw).call(f, *args, **kw) File "/home/ubuntu/forseti-security/.eggs/retrying-1.3.3-py3.6.egg/retrying.py", line 206, in call return attempt.get(self._wrap_exception) File "/home/ubuntu/forseti-security/.eggs/retrying-1.3.3-py3.6.egg/retrying.py", line 247, in get six.reraise(self.value[0], self.value[1], self.value[2]) File "/usr/local/lib/python3.6/dist-packages/six.py", line 703, in reraise raise value File "/home/ubuntu/forseti-security/.eggs/retrying-1.3.3-py3.6.egg/retrying.py", line 200, in call attempt = Attempt(fn(*args, **kwargs), attempt_number, False) File "/usr/local/lib/python3.6/dist-packages/forseti_security-2.25.1-py3.6.egg/google/cloud/forseti/scanner/scanners/config_validator_util/validator_client.py", line 203, in reset raise errors.ConfigValidatorResetError(e) google.cloud.forseti.scanner.scanners.config_validator_util.errors.ConfigValidatorResetError: <_Rendezvous of RPC that terminated with: status = StatusCode.INTERNAL details = "Not supported" debug_error_string = "{"created":"@1593613332.600850846","description":"Error received from peer ipv6:[::1]:50052","file":"src/core/lib/surface/call.cc","file_line":1052,"grpc_message":"Not supported","grpc_status":13}" >

@xingao267 Are you using Forseti v2.25.1 or the main branch? In Forseti v2.25.1 there is a call to Config Validator to reset, which is no longer needed or supported in later versions of CV. This call was removed from Forseti in April. If you need to use a later version of CV, then you'll need to use the main branch of Forseti or at least a commit after that PR.

I switched the forseti_version to master in the module call, and got the following error:
  "serverMessage": "Error running scanner: ConfigValidatorScanner: 'Traceback
(most recent call last):\n  File
\"/usr/local/lib/python3.6/dist-packages/forseti_security-2.25.1-py3.6.egg/google/cloud/forseti/scanner/scanners/config_validator_util/validator_client.py\",
line 176, in review\n    return self.stub.Review(review_request).violations\n
File \"/usr/local/lib/python3.6/dist-packages/grpc/_channel.py\", line 565, in
__call__\n    return _end_unary_response_blocking(state, call, False, None)\n
File \"/usr/local/lib/python3.6/dist-packages/grpc/_channel.py\", line 467, in
_end_unary_response_blocking\n    raise _Rendezvous(state, None, None,
deadline)\ngrpc._channel._Rendezvous: <_Rendezvous of RPC that terminated
with:\n\tstatus = StatusCode.INTERNAL\n\tdetails = \"Received RST_STREAM with
error code 2\"\n\tdebug_error_string =
\"{\"created\":\"@1593734664.508265031\",\"description\":\"Error received from
peer
ipv6:[::1]:50052\",\"file\":\"src/core/lib/surface/call.cc\",\"file_line\":1052,\"grpc_message\":\"Received
RST_STREAM with error code 2\",\"grpc_status\":13}\"\n>\n\nDuring handling of
the above exception, another exception occurred:\n\nTraceback (most recent call
last):\n  File
\"/usr/local/lib/python3.6/dist-packages/forseti_security-2.25.1-py3.6.egg/google/cloud/forseti/scanner/scanner.py\",
line 119, in run\n    scanner.run()\n  File
\"/usr/local/lib/python3.6/dist-packages/forseti_security-2.25.1-py3.6.egg/google/cloud/forseti/scanner/scanners/config_validator_scanner.py\",
line 200, in run\n    for flattened_violations in
self._retrieve_flattened_violations():\n  File
\"/usr/local/lib/python3.6/dist-packages/forseti_security-2.25.1-py3.6.egg/google/cloud/forseti/scanner/scanners/config_validator_scanner.py\",
line 180, in _retrieve_flattened_violations\n    for violations in
self.validator_client.paged_review(cv_assets):\n  File
\"/usr/local/lib/python3.6/dist-packages/forseti_security-2.25.1-py3.6.egg/google/cloud/forseti/scanner/scanners/config_validator_util/validator_client.py\",
line 122, in paged_review\n    violations = self.review(paged_assets)\n  File
\"/home/ubuntu/forseti-security/.eggs/retrying-1.3.3-py3.6.egg/retrying.py\",
line 49, in wrapped_f\n    return Retrying(*dargs, **dkw).call(f, *args,
**kw)\n  File
\"/home/ubuntu/forseti-security/.eggs/retrying-1.3.3-py3.6.egg/retrying.py\",
line 206, in call\n    return attempt.get(self._wrap_exception)\n  File
\"/home/ubuntu/forseti-security/.eggs/retrying-1.3.3-py3.6.egg/retrying.py\",
line 247, in get\n    six.reraise(self.value[0], self.value[1],
self.value[2])\n  File \"/usr/local/lib/python3.6/dist-packages/six.py\", line
703, in reraise\n    raise value\n  File
\"/home/ubuntu/forseti-security/.eggs/retrying-1.3.3-py3.6.egg/retrying.py\",
line 200, in call\n    attempt = Attempt(fn(*args, **kwargs), attempt_number,
False)\n  File
\"/usr/local/lib/python3.6/dist-packages/forseti_security-2.25.1-py3.6.egg/google/cloud/forseti/scanner/scanners/config_validator_util/validator_client.py\",
line 183, in review\n    raise
errors.ConfigValidatorAuditError(e)\ngoogle.cloud.forseti.scanner.scanners.config_validator_util.errors.ConfigValidatorAuditError:
<_Rendezvous of RPC that terminated with:\n\tstatus =
StatusCode.INTERNAL\n\tdetails = \"Received RST_STREAM with error code
2\"\n\tdebug_error_string =
\"{\"created\":\"@1593734664.508265031\",\"description\":\"Error received from
peer
ipv6:[::1]:50052\",\"file\":\"src/core/lib/surface/call.cc\",\"file_line\":1052,\"grpc_message\":\"Received
RST_STREAM with error code 2\",\"grpc_status\":13}\"\n>\n'"

Hi @xingao267 , I got the same error for a while:
To fix it:
change The target field from "organizations/**" ------> "organization/*"
The change is remove the "s" at the end of organizations and the one of the starts

@xingao267 Any update on this? I have been doing some testing with the latest patch release (2.25.2) and I didn't have any issues with CV. It seems like you need this glob support, which will be available with v2.26.0.

I tried the main branch and got some other error a while ago, and didn't got bandwidth to debug it further. I'll try with the next Forseti release version. Yes, I do need the proper CV glob support (https://github.com/forseti-security/config-validator/issues/142 and https://github.com/forseti-security/config-validator/issues/145). Will those be included in v2.25.2? If not, when will v2.26.0 be released?

The v2.25.2 patch release will just contain the fixes for the model creation. Current estimate for v2.26.0 is the 2nd half of August.

@gkowalski-google thanks for the update. good to know. I can wait for the v2.26.0 version or try with main branch again when I get a chance.

@xingao267 I am able to reproduce the error you saw with the Received RST_STREAM  with error code 2. More details on this bug: https://github.com/forseti-security/forseti-security/issues/3798.

@xingao267 Do you want to use this ticket to track that Forseti v2.26.0 supports the glob target matching?

@gkowalski-google i'm not using this ticket to keep track of Forseti v2.26.0 supporting glob target matching. We can close this, and I'll use #3798 to keep track of the other issue.


Daemon mode causes stuttering when two monitors are connected

Firstly, great project. mons is exactly what I needed to manage multiple monitors using i3wm.
To the issue I am having: running mons in daemon moden with two monitors cause a small stuttering each dozen of seconds, that is quite noticiable when watching a video. The issue seems to be xrandr itself, that causes this stuttering when two monitors are enabled, however if only one monitor is connected there is no problem. To easily reproduce the problem, you can run in a terminal;
while true; do xrandr; done

With two monitor connected, open a video in YouTube for example. The frame rate is completely choppy. Of course, mons runs xrandr in a much slower rate (each 3 seconds it seems by looking at the code), however it is still distracting.
I don't know a good solution. Maybe this could be fixable in xrandr itself, maybe not. Or there could be another way to query the connected monitors instead of using xrandr. Any ideas?

Which version are you using ?

Looks good, however I am getting the following warning though:
./mons: line 244: warning: command substitution: ignored null byte in input

And btw, there is another interesting file in this directory:
$ cat /sys/class/drm/card0-eDP-1/enabled
enabled

$ cat /sys/class/drm/card0-HDMI-A-1/enabled
disabled

In fact, this seems to be a good choice for detecting connect/disconnect monitors, since my eDP entry is enabled and HDMI were disabled in the above case.

Warning message, but does it work ?
Try to replace this:
[ -n "$(cat "$edid")" ] && i=$((i+1))

With this:
[ -n "$(<"$edid")" ] && i=$((i+1))

$ pacman -Qo /usr/bin/sh
/usr/bin/sh is owned by bash 4.4.012-2

Btw, even changing the line I get the same error. This seems to work though:
    # Daemon mode
    if $aFlag ; then
        prev=0; i=0
        while true; do
            for status in /sys/class/drm/*/status; do
                [ "$(<"$status")" = "connected" ] && i=$((i+1))
            done
            if [ "$i" -eq 1 ] && [ "$i" != "$prev" ]; then
                "${XRANDR}" --auto --dpi "${dpi}"
            fi
            prev="$i"; i=0
            sleep 2
        done
    fi

Sold !
I had chosen edid to avoid extending the door for non-monitor devices.
Hoping that the check on status file (which is more generic) does the job.

Thanks @Ventto.


[fix] Removed use of has_permission() #114

Fixes #114

Coverage remained the same at 99.133% when pulling 0d35efbdd538009beb7cfb8e5c3629e9677efaf1 on issues/114-remove-has_permission into 7a63afcb39cdb4c56903cc5fd8599517da7de8ac on master.


Use hooks instead of build command for mcm-provider-local

How to categorize this PR?

/area dev-productivity
/kind enhancement
What this PR does / why we need it:
Hooks can now be used to generate the needed patch file for imageVectorOverwrite.
This removes the need to call ko outside of skaffold.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Release note:

NONE

Thanks for the PR! Just a small nit: aren't local variables supposed to be lowercase and only env vars uppercase?

I've made a habit of naming all bash variables with full uppercase, but what you're saying does make sense and avoids some possible collisions with env vars. It's important for us to be consistent so I'll follow this naming convention, thanks!

/lgtm

/retest

/retest


Upgrade Django to >=1.8

Cabot is currently running on Django 1.6 which has been unsupported since April 1, 2015, Django 1.7 is also now out of support.
I've started a fork to try and do this but having some issues around the changes to the migrations process (using Django's own migrations instead of South), has anyone else had any success in doing this?

Seems like this would be addressed by the monster that is #349 ...
@JeanFred any thoughts?

@markunsworth Did you ever start any work on this?

Only what is in that commit, I was hoping (and praying) that #349 would make it's way in to master. Looks like that has blocked due to the size though, so may need to be revisited.
I'm unlikely to find the time or impetus to work on it any time soon though as we're mainly using the new Grafana plugin and alerting system now.

@rewolf Yes, #349 was just too big to be easily reviewable. We may be able to dedicate some resources internally to upgrade Django but can’t make any commitments just now. I’ll keep that issue updated. Thanks for your patience and your interest!

Since 0.8.0 cabot is on django 1.8


proposal: cmd/go: module aliases

Proposal Details
Importing a Go module is tied to a DNS domain. Should the developer of a module loose ownership of that domain, then the module must be migrated to a different domain. All consumers must follow at the same time, otherwise a binary might end up with a mixture of old and new code under different names, which can cause failures (new module A is used and configured by the binary, old module B used by some dependency is not).
Kubernetes is currently facing that challenge because the .io domain might go away and all modules are called k8s.io/<something>. It is not certain that anything needs to be done, but if something needs to be done, then it might take years to be ready - so let's discuss now.
Can Go support such a transition more gracefully?
One possibility would be to let a module define one or more aliases in its go.mod:
module k8s.io/api
alias k8s.dev/api

If such a module gets imported via the alias, the compiler should not complain and treat it as if it had been imported under the official module name. Nothing would change in the vendor directory (in particular not some mass renaming of files). In https://pkg.go.dev, the alias could be a redirect to the original name. Deep links into the documentation of a package remain valid.
Obviously this only makes sense if the original domain is guaranteed to disappear or not to be used anymore. If the module author transfers a domain, they have to migrate and cannot use the old module name anymore because the new owner of the domain might decide to publish its own modules there. If Go should detect such a conflict is TBD.

CC @matloob @samthanawalla
Another approach might be to extend the import path support we already have (see go help importpath).  We could change the go command so that lookups in the top-level .io domain are automatically translated to, say, io.go.dev, which would respond with meta tags redirecting a known set of packages.

related: #26904 but with a replacement pushed up from the dependency.

Since the main module needs a new enough version of the old module anyway to be able to use this, I think the module should instead just commit to its new identity, and setup old modules to forward any declarations to the new module. Something like #32816 can later automate the cleanup.

Since the main module needs a new enough version of the old module anyway to be able to use this, I think the module should instead just commit to its new identity, and setup old modules to forward any declarations to the new module.

Are you suggesting that we should start publishing everything under new names and replace the content of the old modules with wrappers of the new modules, using type aliases to ensure compatibility? That would be a lot of work and fragile because functions and global variables cannot be aliased.

global vars that are modified would be unfortunately left out (all the more reason to avoid them...)

Too late. We already have them. :cry:

but functions can be wrapped

This changes stack unwinding, which is relevant in a few cases.
But the main point is that this is highly unpractical. We would have to support these wrappers across multiple releases until we can be relatively sure that everyone has migrated to the new names. Doing it once manually would already be too much work, doing it repeatedly is out of the question completely unless we can come up with a code generator which does all of this automatically and get it integrated into the release processes of several different repos (yes, plural).

I am sympathetic to this use-case, but I have a reservation: This seems to amount to a similar effect as a replace directive, but placed somewhere other than the main module. That seems potentially confusing, and contrary to the current idea that only the main module gets to perform replacements that affect the compiled program.

A variation I thought about is to treat this more like a deprecation, where no automatic aliasing occurs but the toolchain announces that the module address has been deprecated during installation, perhaps similar to the current message about a version having been retracted:
go: warning: k8s.io/api has moved to k8s.dev/api
go: consider temporarily adopting the new name as a replacement for the old name until all imports are updated:
        replace k8s.io/api v1.0.0 => k8s.dev/api v1.0.0

This gives a downstream maintainer a notification that this module is being renamed, but doesn't automatically change the meaning of any module addresses already in the program. Instead, it just guides the downstream maintainer toward a solution that they control in their own go.mod.
Adding a replace directive like suggested in the error message would then get the intended effect of allowing both names to be used together in the same program until all transitive dependencies have been updated to use k8s.dev/api, at which point the main module would no longer depend on k8s.io/api at all and the replace directive can be removed along with its associated require directive.
This could perhaps be combined with a new rule that prohibits using both the old and the new name in the same go.mod unless there's a replace directive, so that transitive dependencies that lead to both names would force the maintainer of the main module to add the replace directive and then the maintainers of both k8s.io/api and k8s.dev/api can assume that no program could ever have packages from both module addresses compiled in together.
With that additional rule it would remain valid to depend only on k8s.io/api without needing a replace (generating a warning, as described above) to retain backward compatibility with already-published dependents, but including both would require the downstream maintainer to reconcile the conflict with a replace directive until all their upstreams have converged on using the new module path.
This does admittedly put some burden on dependents of the module that is being renamed, but that means that they will end up with a clear record in their go.mod that something unusual is going on. This burden would only be felt once they upgrade an upstream past the version where the alias directive was added to its go.mod, either directly or indirectly, and would be relieved once all of their upstreams have agreed to use the new module path.
(in the above I've used "upstream" to mean "a module mentioned in a require directive in your go.mod, either direct or indirect", and "downstream" to represent the opposite relationship.)

This gives a downstream maintainer a notification that this module is being renamed,

"consider temporarily adopting" might not be strong enough: if a program mixes old and new module, there are bound to be regressions. Definitely the program size increases, but the most common and problematic case will probably be including k8s.io/klog/v2 and k8s.dev/klog/v2. One or the other will not work properly, depending on what gets used by the binary.

This could perhaps be combined with a new rule that prohibits using both the old and the new name in the same go.mod unless there's a replace directive,

That would prevent this problem. If we go down this path, then I think this will be required.

This does admittedly put some burden on dependents of the module that is being renamed,

Indeed. To put this into perspective, k8s.io/klog/v2 is imported 16627 times. I believe that's packages, but the list of affected projects and modules is still very long. And that's just one of the affected modules! k8s.io/apimachinery is even worse.
Looking at individual projects, some would need 16 (https://github.com/helm/helm/blob/main/go.mod) or 20 (https://github.com/istio/istio/blob/master/go.mod) replace statements.
If this is how it needs to be done, it would probably cause quite a bit of work for the entire ecosystem.

would be relieved once all of their upstreams have agreed to use the new module path

Obsolete replace statements do not get removed by go mod tidy. Cleaning up will be more work, or (more likely) will be forgotten.

I have more concerns about this:
We currently delegate module identity to DNS. By allowing an identity to be disconnected from that, we potentially introduce a land grab competition for pretty, short names:
module github.com/my/package
alias yaml // use as import "yaml"

This also allows for potentially hostile takeovers of module functionality via supply chain attacks. E.g.
In your code:
// you're sure this is code you've written
import "corp.example.com/authz"

in some deeply nested dependency that you didn't think to review:
module evil.example.com
alias corp.example.com/authz
// with code to bypass authz checks

If we were to allow module aliasing, I think it should only be allowed with a replace directive in the main module. (so #26904)

Probably worth mentioning, that in case of an alias:
module github.com/my/package
alias yaml // use as import "yaml"

The behavior of a program might change slightly (because of import order (init))

@seankhliao: ack, how to do this securely is a problem. The situation that we are facing right now is that we are still in control of the old domain and want to prepare for the transition while we have it. We would start publishing identical content under both domains (or rather, forward to the same github.com/kubernetes/<repo>) and tell everyone that they must migrate their import statements before loosing the domain.
Once it's lost, import statements with k8s.io are no longer valid and cannot be resolved.
Perhaps that can be used to make this secure? The alias could trigger only if something imports k8s.io/api and k8s.io/dev and both are the same. That way a module can never shadow some other, unrelated module.
We may have to consider whether we want to use module k8s.io/api and k8s.dev/api as alias or the other way around. Probably it should be module k8s.dev/api with k8s.io/api as alias, because we will start doing that once we know that we want to switch. At that point, k8s.dev is the official domain.
My original thinking was that we could continue using k8s.io as official name even when not owning that domain anymore. But that's probably not possible unless Go permanently treats k8s.dev as a secure replacement.
@mateusz834: right, import order could be relevant. But I'm less worried about that.

Isn't this just #60696?
As someone who changed Github usernames, I would like it if #60696 were implemented. As it is, I'm just slowly rolling out v2 of all of my modules so that I can move things off of the old username to the new one.

If I understand it right, #60696 is about helping consumers of a package update their go.mod automatically during a dependency update with go get -u. It doesn't seem to support using both names at the same time in a binary, which is what would be needed here (a dependency imports k8s.io/klog/v2, binary imports k8s.dev/klog/v2 -> both must be the same package).


Fix precision discrepancy

A while back, we changed convert_type (the kind that operates on arrays)
to use a float as intermediate when appropriate, and double for certain
bigger types, instead of always using double no matter what. This sped up
certain buffer conversions substantially.
But at that time, we neglected to adjust the 1-at-a-time variety of
convert_type to use the same logic. This led to occasional discrepancies
between the math of type converting a whole buffer versus doing it one
element at a time. Only for certain values, and generally just one
LSB. But that's enough to have some strange inconsistencies.
Unfortunately, one place that this can crop up is in computing SHA-1
hashes, including maketx -- for certain textures where the source is
uint8 and must be converted to float internally for the MIPmap resizing,
a single bit flip in an LSB can actually change the SHA-1 hash that is
placed in the header in order to detect duplicate textures. This can
happen even if the final pixel values (once converted back to uint8 for
output) are still 100% correct, because for better or for worse, the
hashing is done on the intermediate float buffer of the first
level. This only happens for certain files, containing certain values,
and thus I think it's worth the occasional failing to detect a duplicate
texture (only if you mix old-maketx and new-maketx textures in a single
ImageCache), in order to have more stable consistency with the floating
point conversion.

LGTM


why can't I click on the button inside the zoomist-image container?

@cotton123236 why can't I click on the button inside the zoomist-image container? I tried clicking on the button inside the zoomist-wrapper container and it works, but then I can't zoom into button. What can I do to be able to both zoom in and click on the button?
Codesandbox example
Originally posted by @ukizet in https://github.com/cotton123236/zoomist/issues/33#issuecomment-1837603432
Sry for another created issue but i really wanna use zoomist in my project.

HEY @ukizet ,
That is because .zoomist-image is set to pointer-events: none; to prevent some events on dragging (like clicking  tag on dragging).
You can add .zoomist-container .zoomist-image { pointer-events: auto; } in your css file to make those buttons works, but it may cause some effects while dragging.

@cotton123236 ty for response.


New release

Currently if you try to import that repo it automatically grabs the release v0.0.15 which is not compatible with go-ethereum releases after 1.9.25. However it seems like that this issue was already addressed a few months ago.
So would it be possible to make a new release?

For everyone else running in this issue in the meantime: go get github.com/alethio/web3-multicall-go@9249f76c1578cf90b7bc239049b858b9db3633fa grabs the latest changes :)

and how do you import it ? I get import error when I install it this way ...  Thanks !

At the time I opened that issue, I defined the exact commit of the library in the go.mod file. However in the meantime I forked the repository to https://github.com/jon4hz/web3-multicall-go, made some small changes and create a new release.

thanks ! If I run the example with ETH RPC and ETH addresses it works, but when I switch to, for example Fantom it fails. My program is setup to accept any network, but this library fails when I switch. Is there something that I have to add to the library for other ERC20 based networks to work as well ? Maybe there is something hardcoded for ETH only ? The multicall contract I'm using is the same as the one you use on the example but on Fantom. Thanks for keeping this up. If changes are required for other networks I might subnmit a PR on your fork ? Thanks

The multicall contract address is hardcoded but you can simply pass in a string when creating the multicall client like this:
contract := "0xContractAddress"
multicall.New(eth, multicall.ContractAddress(contract))

The contract is deployed on the following networks:
BSC: 0x6Cf63cC81660Dd174A49e0C61A1f916456Ee1471
Polygon: 0x8a233a018a2e123c0D96435CF99c8e65648b429F
Fantom: 0x08AB4aa09F43cF2D45046870170dd75AE6FBa306
BSC Testnet: 0xD3c6D8dAa57dfD38609047447cccDEF7Db6631b5
Ropsten: 0x5Efdd3fb0ab27A307FE806f5c7CEDd3217b3904a

thanks for this, will take a look asap !