DRAFT: Merge shopify-cli-extensions into cli

This is a dry run merging the shopify-cli-extensions repo into cli. All of shopify-cli-extensions lives in an eponymous top-level directory. We may decide on another structure, but the merge does seem to have worked. It is based on the steps detailed here. History does appear to be intact.

WHY are these changes introduced?
As cli and shopify-cli-extensions are tightly coupled and CLI 2.0 is deprecated, the decision was made to merge these two repos for ease of release.

WHAT is this pull request doing?
This branch was created by:

Cloning a new copy of cli
Adding a remote for shopify-cli-extensions
Creating a rewrite branch based on shopify-cli-extensions/main
Rebasing the rewrite branch on cli/main
Pushing the rewrite branch upstream (to draft this PR)

The CLA failures are due to @t6d & @rmshopify needing to sign the Contributor License Agreement.

This looks good.
I think for the moment is OK to have it all in a root folder, but we'd want to reorganize everything under packages, maybe packages/extensions/ or a new extension-packages 🤔
probably extract the node-packages from the current folder and treat the go code as a new package.

I'm happy to re-run the process using a different structure.


Publicly shareable developer profile URLs

Implemented feature to publicly share developer URL using public profile key. Will implement feature #646

[x] Add a new column to the database, developers.public_profile_key
[x] Unhide hidden information on a developers profile page if this key matches from the key param (e.g. /developers/abc123?key=xyz987)
[x] Add a new button next to “Edit” when viewing your own developer profile titled “Share”. When clicked:

[x] Generate the public profile key via Secure Random (if not already generated)
[x]  Copy the full URL (with key param) to the clipboard

Pull request checklist

[ ] My code contains tests covering the code I modified
[x] I linted and tested the project with bin/check
[ ] I added significant changes and product updates to the changelog

@joemasilotti This PR is still in progress as need to add relevant test cases but can you please review the implemented code and provide feedback for any changes. Thanks

Can you please merge in main? #666 should fix the JavaScript bug in Chrome.

Done.. Thanks @ferryphang for the fix.
It is working fine now in chrome though Firefox it is still throwing below error
Error invoking action "click->clipboard#copy"

ReferenceError: ClipboardItem is not defined

I didn't test on Firefox – thanks for calling that out. It looks like the ClipboardItem API isn't support on that browser.
However, Mozilla's docs reference using document.execCommand("copy"), even though it is deprecated. This gist looks like it should work with that API, but it does require a bit of additional JavaScript.
@sarvaiyanidhi, can you test on Chrome for now? If not, I can take a pass at implementing the Firefox-specific behavior.
Either way, I'll start reviewing the PR now.

Thank you for the feedback. Have gone through comments and will make necessary changes.
Will also add required test cases and update PR for further review.

Thank you for the input. I will get the mentioned changes done soon and push code for further review.

This looks great! All that's left is the following:

We need tests for PublicProfile. Feel free to add this to a new test class Users::PublicProfile (or similar). I'm OK with coupling the testing logic to the User model for now.

@joemasilotti Have added pending PublicProfile test cases but let me know if I need to update anything as I have just added basic checks in it. Most of the scenarios were covered in other related files so I was not sure what else to update in this.


RDKTV-10965 Reducing the CEC retries

RDKTV-10965 Addressed CEC retry count

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

Closing older PRs. Please rebase and submit on latest sprint branch.


Method Annotations

Well detailed description of the change :

Initial pass at method annotation implementation. Method annotations have the same expectations as class annotations where they're not brought up from an inherited class.
This is a breaking change as the previous class field of annotations is now classAnnotations with an additional field methodAnnotations
Underlying class structure to carry the annotations:
// class annotations
{
    "ResourceController": "/api/v1"
}

// method annotations
{
    "methodName": {
        "Get": "/assets",
        "BasicAuth": nil
    }
}

Resolves: #
#464
Type of change:

[ ] Bug fix

[x] New feature

[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Housekeeping

[x] Tests have been updated to reflect the changes done within this PR (if applicable).

[x] Documentation has been updated to reflect the changes done within this PR (if applicable).

Preview (Screenshots) :

Might need some assistance @Jason2605 . All tests and examples are passing locally but not in CI and not sure wht the failure is there. Output seems to be cut off.

Sorry @briandowns been away for the new year! Thanks for working on this, I haven't forgotten, I'll try to get around to seeing why the tests aren't passing

Yeah for me running in the debug build im getting a segfault when running the annotation tests, will investigate further

Something I've noticed from a "correctness" standpoint is this is technically legal:
class Test {
    @Test
    @Test1
    @Test2
    @Test3
}

print(Test.methodAnnotations); // {"__annotatedMethodName": {"Test3": nil, "Test1": nil, "Test": nil, "Test2": nil}}

It is an edge case scenario but it would be good if this resulted in a compile time error since there's no method, what do you think?

I "think" we're all set.

Legend, thank you very much for this!

Thanks! Was a fun challenge. And thanks for the guidance and feedback through the process.


Installing mxnet on PowerPC

Note: Providing complete information in the most concise form is the best way to get help. This issue template serves as the checklist for essential information to most of the technical issues and bug reports. For non-technical issues and feature requests, feel free to present the information in what you believe is the best form.
For Q & A and discussion, please start a discussion thread at https://discuss.mxnet.io
Description
(Brief description of the problem in no more than 2 sentences.)
We are having troubles with installing mxnet on powerPC
Environment info (Required)
Platform: Power9
OS: Redhat Linux
Cuda: 10.1
Python: python2.7
We tried to install the mxnet-cu101 package for python2.7 on our powerpc machine, but pip cannot find the version:
"ERROR: Could not find a version that satisfies the requirement mxnet-cu101 (from versions: none)
ERROR: No matching distribution found for mxnet-cu101"

What should we do?
We wanted to run it with python, should we have to build it from source and use python bindings?
Or do you have version for powerpc? :)

Thank you!

Sorry, but we are not officially supporting PowerPC. Please try compiling yourself.

Currently, MXNet pip package only support Cent OS 7 or above, Ubuntu 14.04 or above. It may work on other Linux distribution however not gauranteed.

@mxnet-label-bot add [question]

@marcoabreu Hello, is there any guide we can follow for building mxnet on power9 ?

You may follow https://mxnet.apache.org/get_started/ubuntu_setup  in analogy

Yeah, this guide helped us too.

You may follow https://mxnet.apache.org/get_started/ubuntu_setup in analogy

If the guide needs any extension to cover PowerPC, feel free to open a PR. Thanks

@leezu @Talgin , Thanks for helping guys, It worked !
But there is little problem i got, my progress takes 1 sec on 1080ti on 64 bit intel, 1.2 sec on v100 on ppc64.
v100 on ppc should be faster than 1080ti on 64 bit. You guys have any idea ?

@leezu @Talgin no idea guys how can i fix this ? :(

You need to investigate and find some minimal example that shows the problem. For example, by using the benchmark scripts https://github.com/apache/incubator-mxnet/tree/master/benchmark/opperf

@pasa13142, we had the same problem, training was slower on power9 with Tesla V100  than on my workstation. I do not remember if they found a reason, but our server management service said that ppc was not originally made to do such things (training) :) Like they are good at calculation, maybe some kind of server operations, but they (ibms ppc) do not have much experience with GPUs.
I would also be happy if you share the solution, if you found one.

Thank you, if i find out, i'll update, but unfortunately signs are not good on ibms ppc :(

@Talgin hey! Which math library did you select for powerpc ? And does it work ?

Hi, @pasa13142! We used numpy, scikit-learn, pandas and many other. Installation was without problems and they worked OK. Have you found something interesting? :)

Hi, @pasa13142
Try to directly connect your monitor to the server (not with ssh), sometimes the network can cause fluctuations.


Right Sliding

How to change it to slide from the right

Well ,first of all you need to change the gravity of drawerLayout to RIGHT. Then to allow calling side menu on navigation button you should call toolbar.
toolbar.setNavigationOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View view) {
if(drawerLayout.isDrawerOpen(Gravity.RIGHT)){
drawerLayout.closeDrawer(Gravity.RIGHT);
}else
{
drawerLayout.openDrawer(Gravity.RIGHT);
}
}
});
that's will doo the trick , you sould be able to call the side menu as by  draging it from right, and by clicking the navigation button


Zoning without symmetry misses assemblies

Looking at using the zoning capabilities for a full core, and we've found that only 1/3 symmetric cores seem to be correctly assigning assemblies to zones. The default symmetry option is 3
https://github.com/terrapower/armi/blob/3d9050f657036e5057ba56345bf7d36146f8f916/armi/reactor/zones.py#L27-L36
but the core symmetry does not appear to be used when creating Zone objects, even though the Zones object is instantiated with the core
https://github.com/terrapower/armi/blob/3d9050f657036e5057ba56345bf7d36146f8f916/armi/reactor/zones.py#L538-L546
The problem is that some assemblies do not have any zone information attached to them.  But all 313 assemblies exist somewhere in this zoneData dictionary
>>> sum(map(len, zoneData.values()))
313

Metadata

ARMI version: 3d9050f
Python 3.7
FFTF model: terrapower/fftf-isothermal-model@793fd8e

I am adding these points to our existing "zones" redesign discussion:   https://github.com/terrapower/armi/issues/563
It is my impression that only a couple of downstream projects actively use Zones right now, and other than those, most people would prefer a rehaul.
If anyone disagrees with that assessment, feel free to correct me.

Thanks @john-science. I'll put some comments in that issue

I am currently working on exposing Zoning strategies to plugins.  This is part of the larger Zone redesign being discussed here:
https://github.com/terrapower/armi/discussions/811

There has been a complete overhaul of the Zoning system. here
ARMI no longer comes with all these bespoke, crazy zones.  It just exposes a way for people to define their own zones.
As such, the code this bug refers to has been removed.


Adding stricter Sub account check for quota check

Pull Request Test Coverage Report for Build 4664

0 of 0   changed or added relevant lines in 0 files are covered.
7 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.006%) to 89.246%

Files with Coverage Reduction
New Missed Lines
%

applications/osb-broker/src/api-controllers/middleware/index.js
7
88.24%

Totals

Change from base Build 4662:
-0.006%

Covered Lines:
9386

Relevant Lines:
10155

💛  - Coveralls


dag: cycle time metric

Would be interesting to add some Prometheus metrics around the dag generation/size. The first one that came to mind was cycle time to build cold as well as cycle time with updates.
// cc @rosskukulinski

I always love data :).  Not required for beta-1 milestone, but could consider for 0.6 release based on performance testing done for Gimbal 0.3 release.

Great minds think alike :)
Is this a duplicate of #496 ?


updating to Rails 5.1

Updating to the latest gems

Coverage decreased (-91.3%) to 4.482% when pulling f424b9c323340a03c258da84a73893fff537b6ea on sergio-ocon:updating_gems into 617efdf2de615755273e5c375b652406b9ff4572 on propedeutica:master.

Coverage decreased (-91.3%) to 4.462% when pulling d0aa611ae0a1ef77684f33d7168bc62b4c482019 on sergio-ocon:updating_gems into 617efdf2de615755273e5c375b652406b9ff4572 on propedeutica:master.

Coverage decreased (-91.3%) to 4.462% when pulling 510d106fc73f17a295c0a9fffc3e9c5aad8499c0 on sergio-ocon:updating_gems into 617efdf2de615755273e5c375b652406b9ff4572 on propedeutica:master.

Coverage decreased (-91.3%) to 4.462% when pulling a1b5d732f3186547af53b327d998c94873a87e68 on sergio-ocon:updating_gems into 617efdf2de615755273e5c375b652406b9ff4572 on propedeutica:master.

Coverage decreased (-91.3%) to 4.462% when pulling 1d2365e4aba3769fbddd078d1c48f66e176bac7f on sergio-ocon:updating_gems into 617efdf2de615755273e5c375b652406b9ff4572 on propedeutica:master.

Coverage increased (+0.01%) to 95.814% when pulling 50372b5600356a3f2d16a7f6fedfa22af206ff3b on sergio-ocon:updating_gems into 617efdf2de615755273e5c375b652406b9ff4572 on propedeutica:master.


[MXNET-679] Improved CMakeLists.txt

Description
Part of https://github.com/apache/incubator-mxnet/pull/11148
Checklist
Essentials

[x] The PR title start starts with [MXNET-679]
[x] Changes are complete
[x] Code is well-documented
[x] To the my best knowledge, examples are not affected by this change

Changes

[x] Renamed cmake/ChooseBlas.cmake to cmake/ChooseBLAS.cmake
[x] Renamed USE_MKLML_MKL to USE_MKLML
[x] Formatted CMakeLists.txt
[x] Added documentation for BLAS options
[x] Cleaned up CUDA language detection

@lebeg Can you check failing builds?

@lebeg could you re-trigger CI?

@lebeg please update the PR as per the comments.

@lebeg Could you please re-trigger the CI again since some tests are failing and can you please address the comments? Thank you!

@lebeg Can you rebase with the current master branch ? There seems to be a conflict.
Is this PR good to go after that ?

It seems that there are more problems. I'm closing this for now as I don't have time for it right now. It would be really great to see somebody picking it up from here.


mass claim tips

https://github.com/lbryio/lbry-redux/pull/380

@ seanyesmunt In the 0.5 release notes this PR should be linked, but the link is going to #5387 :)


GraphQL: Add filter that only matches entities changed since a given block

To support use cases where it is necessary to find out what has changed since a given block, we should offer a changed_since_block: $block filter that only matches entities that have been added or updated since $block. For completeness, it would also be good if that somehow included entities that have been deleted since $block, but it's not clear how 'this was deleted' could be indicated in the GraphQL response.

Closing as a subset of https://github.com/graphprotocol/graph-node/issues/2958 (though maybe I should have elaborated this issue 🤔 )

Re-opening this, as we may actually want to tackle this more constrained use-case first

Proposed implementation:

Extend the where top-level filter to include a _change_block_gte field (leading underscore in order to avoid collisions)

The following would return all things as of block 1,234, which changed since block 1,000

things(block: { number: 1,234 }, where: { _change_block_gte: { number: 1,000 }) {
  id
}

This would not include deleted entities.

@lutter I am interested in if you envisaged this functionality going here, or elsewhere (as a new top-level field?)
cc @dotansimha @kamilkisiela

@azf20 I started working on a PR for this. Started from the GraphQL area of the codebase. I noticed that input Block_height is already exists, I guess I can use it as where: { _block: Block_height }?
This way user can query with where: { _block: { number: "XYZ" }} or where: { _block: { number_gte: "XYZ" }}?
Or should I use only _change_block_gte option under where?

@dotansimha that is a very good point - I hadn't thought about the fact that Block_height already has number_gte, which fits perfectly with what we want to do. I think i would call it _change_block rather than _block to make it clear what the entities are being filtered on (the block when they last changed). What do you think @lutter?
You can probably take quite a lot from the existing block top-level filter (which is different, as it defines the state for the overall query, i.e. "query the data as of block 1000", but will use a lot of the same information that will be helpful here)

@dotansimha that is a very good point - I hadn't thought about the fact that Block_height already has number_gte, which fits perfectly with what we want to do. I think i would call it _change_block rather than _block to make it clear what the entities are being filtered on (the block when they last changed). What do you think @lutter? You can probably take quite a lot from the existing block top-level filter (which is different, as it defines the state for the overall query, i.e. "query the data as of block 1000", but will use a lot of the same information that will be helpful here)

I don't think we can reuse the Block_height input type here, since it adds other filter capabilities, too, like { number: NNN } and { hash: 0xdeadbeef } which doesn't really make sense in the where clause. I think we have to add just the _change_block_gte field as a special case.

It is an increase in the scope, but I think number and hash do make sense as values for the where clause, i.e.
where: {_change_block: {number: 100} }

Would get all entities which changed in that one block (excluding deletions)?

I'll start with just where: { _chane_block: { number_gte: 100 }} as separate input, and we can always extend the input type there (or, switch to use a different one) before merging.
So I'll continue with that, and then we can discuss about different block filter in parallel.

@azf20 @lutter @Jannis I created a PR fix adding this new filter: https://github.com/graphprotocol/graph-node/pull/3014  , do you think https://github.com/graphprotocol/graph-node/issues/2958 is also needed? (I guess it is? Because you can now filter base on that data, but you can't tell what is the actual change_block of each record found?)

thanks @dotansimha - as discussed this morning I think we can wait on #2958, based on feedback on #3014 we can establish whether having the change_block available for each record is useful

@dotansimha moving this to awaiting release as it was merged?

This can cause problems when there is a subgraph that can "delete" entities. For example: not returning entities with a "balance" of 0. A "complete query" (requesting latest block) won't return entities with balance of 0. But if we do 2 queries, one a year ago, and one today using _change_block, there could be an entity with some balance a year ago, but not today. It won't return the recent one with a balance of 0, and thus we won't know that we should delete it.
I think this should be explained in the documentation, as it can be unexpected behaviour for people expecting something like subscriptions.

Hi @daviddavo I think that is a good point, that would be unexpected - @dotansimha @lutter interested in what your take is here?


Upload stalling with HTTPS

Probably similar to #1147
1. What version of Caddy are you running (caddy -version)?
0.9.5
2. What are you trying to do?
 What is your entire Caddyfile?
tus.example.com {
  proxy localhost:3001 { #adress of the tus server
    transparent
  }
}

4. How did you run Caddy (give the full command and describe the execution environment)?
caddy.exe
on windows 10
5. What did you expect to see?
Upload of 10MB file coimpleting fine over https
6. What did you see instead (give full error messages and/or log)?
When trying on http, the upload works fine.
On https, the upload stalls at about 60%. From the client side, the JS doesn't send (no more progress events)
I don't know how I could dig deeper to debug this situation: any input is appreciated!

If I pause the upload, tus is capable of writing what has been sent until now: if I then resume the upload, everything works fine (the last 4MB are uploaded successfully)

This may be related to default timeouts set in 0.9.5 (they will be disabled in next release)
try
tus.example.com {
timeouts 0
proxy localhost:3001 { #adress of the tus server
transparent
}
}

This may be related to default timeouts set in 0.9.5 (they will be disabled in next release)
try

But then it should also fail on http (not only on https), no?
Anyway, I will try it tomorrow

@oliverpool  ohh sorry didnt notice that, but it may be worth a try anyway.

I have the exact same problem.
If I set timeouts none my client just hangs forever. Then if I upload with raw IP:port, everything goes fine. Also using 0.9.5.

@Unknwon Is timeouts 0 or timeouts none set?

@mholt yes,
domain.com {
        timeouts {
                read none
        }
        proxy / localhost:8086
}

And just realize same for download, hangs on about 16.1MB.

@Unknwon You've only set the read timeout to 0, set all of them to 0 and try again.

Sorry about multiple comments so quickly, roll back to 0.9.4 immediately solved the problem.

You've only set the read timeout to 0, set all of them to 0 and try again.

At first I didn't set any timeouts, and it just hangs on upload about 13.8MB until it timeout.

roll back to 0.9.4 immediately solved the problem.

That's interesting. Would you be able to spare a few minutes to help debug this since I have nothing to reproduce this with from this issue so far?
Just brainstorming here... if you could try before these commits/PRs (like bisect?) and see if any of them are the culprit:

https://github.com/mholt/caddy/pull/1358
https://github.com/mholt/caddy/commit/ae10122f7e3459214acaf3826c7e473a52d3dda8
https://github.com/mholt/caddy/pull/1314
https://github.com/mholt/caddy/commit/4babe4b201eef3e9794851b74f734a03338f7a20
https://github.com/mholt/caddy/commit/153d4a5ac62ffcef77df8ad29ae13e7d68b188b6

@mholt sure, but probably half an hour later...

I can't enable HTTPS for local fake domain for all sorts of reason, it is giving me hard time to debug. And HTTP seems working fine.

@Unknwon Even with tls self_signed for localhost? Should make it much easier.
@oliverpool Would you please be able to try Caddy at those commits/PRs I linked to above and see which one causes it?

@mholt & @Unknwon : I found a preciser cause !
It seems to be the write timeout (tests with version 0.9.5):

when the write timeouts is set to none, everything works fine (http & https)
when the write timeouts is unset (or set to some value smaller than my upload duration) strange things happen:

https: the upload simply stalls (no more progress whatsoever). When I interrupt the upload, the end of the request is sent to my tus server and everything seems fine
http: the upload goes to the end, but the tus server doubly receives the request and only the last one is sent back to my browser (which is a failure because the first one was properly proceeded by the tus server)

So a simple workaround is to correctly set the timeouts :smile:
But there might still be a bug regarding what happens when a timeout occurs.

According to https://blog.cloudflare.com/exposing-go-on-the-internet/, there is a bug regarding readTimeout for http/2: https://github.com/golang/go/issues/16450 in Go 1.7.
I will try to compile caddy with go 1.8 and update my bug report.

Compiled with go 1.8 (go version go1.8 windows/amd64):
The write timeout seems to be ignored: everything works fine for http and for https (no stall / no double request).

@oliverpool Ah, excellent. I forgot about that bug mentioned in the blog post! 😁 Oops.
Okay, so for now, disable timeouts completely on Caddy 0.9.5 if you're having this problem. The next version will be built on Go 1.8 so that should resolve the bug (and default timeouts will be disabled anyway).
Thanks for figuring it out! :tada:

I will just use the one I compiled it with go 1.8 ;-)
Thank you for your support!

I can confirm this issue with 0.9.5. with https, upload fails after some time (502), with http, it just infinitely waits.
Downgrading to 0.9.4 helped.
Can I help debugging this issue?

Can I help debugging this issue?

Did you try with Go 1.8 ?

I'm using abiosoft/caddy docker image. No clue which go is it using, but Dockerfile looks like it's downloading the official binary from caddyserver.com.

Well then you will have to wait a bit (https://github.com/mholt/caddy/issues/1480#issuecomment-283030700 from mholt):

Okay, so for now, disable timeouts completely on Caddy 0.9.5 if you're having this problem. The next version will be built on Go 1.8 so that should resolve the bug (and default timeouts will be disabled anyway).

This may be a known issue with default timeouts.
Try
Timeouts none

In your caddyfile

Is this something ongoing? I cant upload files above certain size. Also 'limits' directive Parse error: Unknown directive 'limits'.
Is there any way how to go around this?

@krisak which version of Caddy are you using ?
If this is happening with version 0.10.3, it might be a good idea to open a new issue.

 I will try to update and see whats going on.


refactor(talos): Use names in patches instead of indexes

This is required to be able to select configs (patches) by name.
You can use moved blocks to migrate the servers: e.g.:
moved {
  from = module.talos.hcloud_server.control_planes[0]
  to   = module.talos.hcloud_server.control_planes["control-plane-1"]
}
moved {
  from = module.talos.hcloud_server.workers[0]
  to   = module.talos.hcloud_server.workers["worker-1"]
}

BREAKING CHANGE: Use moved to migrate.

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


Clientside Validation for LookupEditor

Thanks for this awesomeness and for adding the order/detail example. I have been working with Serenity for about a week and already amazed at what features are provided.
I have a question on clientside validation of the LookupEditor as used in your "New Order" form (*Customer). When a LookupEditor is a required field and not given a value before submission, clientside validation does not occur and instead server side validation throws an error in Turkish. Do you have any suggestions regarding where to best solve this issue? Thanks again sb

Oops, it is probably a bug related to a recent jquery.validate upgrade. It wasn't like this before. I'll fix it and Turkish leftover error.

Ok, located the problem. It is not jquery.validate upgrade actually, but Select2.js 3.5.2.
Select2 3.5.2 is incompatible with jquery.validate. I'll downgrade it to 3.5.1 in next version of Serene.
Before it is released, a quick fix for your problem can be to open package manager console and type:

Update-Package Select2.js -Version 3.5.1

Also, i localized Turkish texts that i forgot in DataValidation.cs.

You are a legend :) thanks so much for the quick fix and support!!!


Typo in Startup

correct "button of config.py" to "bottom of config.py"

You're right, this commit fixes it.
47df080038b528005335d280a3198ff9cf8870c5


Install with packer

Is it possible? I'm using:
  use { 'Donaldttt/fuzzyy'}

And Packer shows it's installing it with no warnings or errors. But none of the Fuzzy* commands actually work:
Not an editor command: FuzzyFiles

Am I missing something? I'm using Neovim, if that matters.

If my understanding is correct then this plugin will not work in neovim because it is written in Vim9. Of course @Donaldttt  can clarify formally.

Yes, Neovim doesn't support vim9script. You have to use vim with version 9+ to use this plugin.


[docs] “Database Management” touch-up

The Issue
The Database Management page uses a heading called “Discussion” that consists not of a discussion, but a massive bulleted list.
How This PR Solves The Issue
This liberates the useful nuggets of information from their list and groups them into more useful headings, with linking and minor language nitpicks we must expect from me at this point.
Manual Testing Instructions
Preview changes locally or inspect the automatic build.
Automated Testing Overview
n/a
Related Issue Link(s)
n/a
Release/Deployment Notes
n/a

Thanks so much for this and the others, will get it reviewed in the next couple of days. Trying to get out from under big manual testing load on my WSL2 PR.

Pull whenever you’d like!


lookup api.loophole.cloud: no such host

Registering your domain... Error! Post "https://api.loophole.cloud:443/api/site": dial tcp: lookup api.loophole.cloud: no such host
7:18PM ERR Something unexpected happened, please let developers know
7:18PM FTL Post "https://api.loophole.cloud:443/api/site": dial tcp: lookup api.loophole.cloud: no such host

Hey @DarKWinGTM, I was just trying whether enabling IPv6 in the loophole backend will break anything. And yes, it did. You were very quick to notice. I already reverted it and loophole should be working normal again. Can you confirm?

It might be that your DNS provider is caching the broken entries for a little longer. The TTL for the DNS record was set to just 1 minute and should be gone since ~15 minutes already. Can you try resolving api.loophole.cloud on your end?
% dig +short api.loophole.cloud <IP_ADDRESS>
<IP_ADDRESS>
% curl https://api.loophole.cloud
{"version":"0.0.1"}%

Here the confirmation that loophole cli works for me:
% loophole path .
Loophole - End to end TLS encrypted TCP communication between you and your clients

There is new version available, to get it please visit https://github.com/loophole/cli/releases/tag/1.0.
Registering your domain... Success!
Starting local file server Success!
Starting local proxy server...  Success!
Initializing secure tunnel...  Success!

Forwarding https://REDACTED.loophole.site -> .
Press CTRL + C to stop the service
Logs:
1:33PM INF Awaiting connections...
1:33PM INF Succeeded to accept connection over HTTPS
1:33PM INF Succeeded to accept connection over HTTPS
1:33PM INF Succeeded to accept connection over HTTPS
1:33PM INF Succeeded to accept connection over HTTPS

@DarKWinGTM that's very strange that Google DNS (<IP_ADDRESS>) is not resolving it for you. Did it change in the meantime?
When using some website to resolve the endpoint, it works as well: https://dnschecker.org/all-dns-records-of-domain.php?query=api.loophole.cloud&rtype=ALL&dns=google (A record must be available for IPv4 to work and AAAA for IPv6 should not be set):

Hi @DarKWinGTM we had an issue with our servers and just fixed them. It should work again. Please let me know if you are still running into issues.

@DarKWinGTM please try again now. We had a node failure at night.

@DarKWinGTM which exact command did you use to start your tunnel? Will look into it and come back to you

@DarKWinGTM 500s should be gone now :)

Hello.
The issues should be resolved. Please try again.
Best regards,
Łukasz

On 2 May 2023, at 05:11, DarKWinGTM @.***> wrote:
Initializing secure tunnel... Error! ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
10:10AM INF SSH Connection failed, retrying in 10 seconds... (Attempt 1/5)
—
Reply to this email directly, view it on GitHub https://github.com/loophole/cli/issues/218#issuecomment-1530810011, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC2I4NH5MSVOZIVALKIW42LXEB3N7ANCNFSM6AAAAAAVYCTRNI.
You are receiving this because you commented.


feat: make the prefix in the solution optional across resource names

Description
Allows a consumer to provide either:

prefix + name of a resource / group
name of a resource / group

Release required?

[ ] No release
[ ] Patch release (x.x.X)
[ ] Minor release (x.X.x)
[ ] Major release (X.x.x)

Release notes content

Run the pipeline
If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.
Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:
/run pipeline

Checklist for reviewers

[ ] If relevant, a test for the change is included or updated with this PR.
[ ] If relevant, documentation for the change is included or updated with this PR.

For mergers

Use a conventional commit message to set the release level. Follow the guidelines.
Include information that users need to know about the PR in the commit message. The commit message becomes part of the GitHub release notes.
Use the Squash and merge option.

/run pipeline

/run pipeline

/run pipeline

@MatthewLemmond can you confirm if did a test not passing prefix to confirm this works as expected?

here is a run that didn't have a prefix provided and it successfully created the resource group without a prefix (failed due to name conflict on the bucket) so this serves as a proof of concept that it's working without the prefix being passed in

/run pipeline

/run pipeline

/run pipeline

:tada: This PR is included in version 1.4.0 :tada:
The release is available on:

GitHub release
v1.4.0

Your semantic-release bot :package::rocket:


Perform batch size check before converting scales

If batch size 2 is used, it fails with
scale = np.asscalar(cuda.to_cpu(scale))
  File "...numpy/lib/type_check.py", line 482, in asscalar
    return a.item()
ValueError: can only convert an array of size 1 to a Python scalar

Proposed outcome:
By reordering the checks, the ValueError would be raised before the conversion, avoiding this error.
System:
numpy       1.14.2
chainer     5.1.0
chainercv   0.11.0

Thank for sending the PR!


[Feature] Support apiVersion parameter in sub-client

When there are two-level clients , the top-level client has no operations with apiVersion paramter, but there are operations which has api-version parameter in sub-client.
e.g.
@versioned(Versions)
@service({
  title: "hello world",
})
@doc("This is a sample typespec project.")
@server(
  "{unbrandedTypeSpecUrl}",
  "Endpoint Service",
  {
    unbrandedTypeSpecUrl: string,
  }
)
namespace UnbrandedTypeSpec;

@route("/hello")
@doc("hello world.")
op hello(): void;

interface ClientWithApiVersion {
  @route("/WithApiVersion")
  @doc("Return hi again")
  @get
  @convenientAPI(true)
  WithApiVersion(@header p1: string, @query apiVersion: string): void;
}

How apiVersion be defined?

Option 1:
bump apiVersion field to the top-level client, and it will not be a paramter in the GetAccessor method
//parent client
public partial class UnbrandedTypeSpecClient
{
        private readonly Uri _endpoint;
        private const string AuthorizationHeader = "my-api-key";
        /// <summary> A credential used to authenticate to the service. </summary>
        private readonly ApiKeyCredential _keyCredential;
        private ClientWithApiVersion _cachedClientWithApiVersion;
        private string _apiVersion;

       public virtual ClientWithApiVersion GetClientWithApiVersionClient()
        {
            return Volatile.Read(ref _cachedClientWithApiVersion) ?? Interlocked.CompareExchange(ref _cachedClientWithApiVersion, new ClientWithApiVersion(Pipeline, _keyCredential, _endpoint, _apiVersion), null) ?? _cachedClientWithApiVersion;
        }
}

//sub-client
public partial class ClientWithApiVersion
{
        private readonly Uri _endpoint;
        private const string AuthorizationHeader = "my-api-key";
        /// <summary> A credential used to authenticate to the service. </summary>
        private readonly ApiKeyCredential _keyCredential;
        private readonly string _apiVersion;

        /// <summary> Initializes a new instance of ClientWithApiVersion for mocking. </summary>
        protected ClientWithApiVersion()
        {
        }

        internal ClientWithApiVersion(ClientPipeline pipeline, ApiKeyCredential keyCredential, Uri endpoint, string apiVersion)
        {
            _endpoint = endpoint;
            Pipeline = pipeline;
            _keyCredential = keyCredential;
            _apiVersion = apiVersion;
}

Option 2:
apiVersion only be the field of the sub-client, and there will be an paramter in the GetAccessor method
//parent client
public partial class UnbrandedTypeSpecClient
{
        private readonly Uri _endpoint;
        private const string AuthorizationHeader = "my-api-key";
        /// <summary> A credential used to authenticate to the service. </summary>
        private readonly ApiKeyCredential _keyCredential;
        private ClientWithApiVersion _cachedClientWithApiVersion;

       public virtual ClientWithApiVersion GetClientWithApiVersionClient(string aipVersion)
        {
            return Volatile.Read(ref _cachedClientWithApiVersion) ?? Interlocked.CompareExchange(ref _cachedClientWithApiVersion, new ClientWithApiVersion(Pipeline, _keyCredential, _endpoint, apiVersion), null) ?? _cachedClientWithApiVersion;
        }
}

//sub client
public partial class ClientWithApiVersion
{
        private readonly Uri _endpoint;
        private const string AuthorizationHeader = "my-api-key";
        /// <summary> A credential used to authenticate to the service. </summary>
        private readonly ApiKeyCredential _keyCredential;
        private readonly string _apiVersion;

        /// <summary> Initializes a new instance of ClientWithApiVersion for mocking. </summary>
        protected ClientWithApiVersion()
        {
        }

        internal ClientWithApiVersion(ClientPipeline pipeline, ApiKeyCredential keyCredential, Uri endpoint, string apiVersion)
        {
            _endpoint = endpoint;
            Pipeline = pipeline;
            _keyCredential = keyCredential;
            _apiVersion = apiVersion;
}

I prefer to Option 1. because apiVersion is the service apiVersion, it should be in ClientOptions, and should not alllow to set value other than the one in the ClientOptions


Handle the "unsure" annotations

We also receive annotations that the experts who annotated the data are unsure about.
We could try the following:

Treat them as full labels
Treat them as full labels but with less of a penalty in the loss for getting them wrong (tunable)
Smooth the labels to be 0.5 for these masks

Each of these options should be tested and examined in isolation on various sizes of the training set (probably need cross validation).

It looks like some annotations only have "unsure" as the label. This means that we should definitely be including it in our training somehow.


Completly ignore Microsoft Teams Notification window

Microsoft Teams on macOS appears to use incorrect roles for it's Notification windows, they get assigned role AXWindow and subrole AXStandardWindow despite being essentially popup notifications. Only the title seems to differ.
This causes problems on bsp layouts where an invisible blank space gets considered a window and causes tiling.
Is there a way to write a rule that can ignore these windows completely but still tile the main window?
Query info:
[{
	"id":246837,
	"pid":70829,
	"app":"Microsoft Teams",
	"title":"Group | Microsoft Teams",
	"frame":{
		"x":1.0000,
		"y":27.0000,
		"w":838.0000,
		"h":1022.0000
	},
	"level":0,
	"role":"AXWindow",
	"subrole":"AXStandardWindow",
	"movable":1,
	"resizable":1,
	"display":1,
	"space":3,
	"visible":0,
	"focused":0,
	"split":"vertical",
	"floating":0,
	"sticky":0,
	"border":0,
	"shadow":1,
	"zoom-parent":0,
	"zoom-fullscreen":0,
	"native-fullscreen":0
},{
	"id":247747,
	"pid":70829,
	"app":"Microsoft Teams",
	"title":"Microsoft Teams Notification",
	"frame":{
		"x":841.0000,
		"y":27.0000,
		"w":0.0000,
		"h":0.0000
	},
	"level":0,
	"role":"AXWindow",
	"subrole":"AXStandardWindow",
	"movable":1,
	"resizable":0,
	"display":1,
	"space":3,
	"visible":0,
	"focused":0,
	"split":"vertical",
	"floating":1,
	"sticky":0,
	"border":0,
	"shadow":1,
	"zoom-parent":0,
	"zoom-fullscreen":0,
	"native-fullscreen":0
}]

Duplicate of #74

Thanks, will try out the rules mentioned in #74


Add heading bookmarked toggle

Closes #1422. This (relatively) simple PR will allow people to write #heading(bookmarked: false) to prevent the heading from appearing in the exported PDF's outline (doesn't affect PNG export). It does so by simply checking for the property in the PDF outline generation step of the export.
Note that the bookmarked option is not linked to the outlined option, and defaults to true for all headings. I thought of having a bookmarked: auto default which would set it to whatever outlined is, but I decided against it (for now) as I think it's better (and more predictable) to just disable bookmarking explicitly. Feel free to present different opinions in the replies.
Added some docs (feel free to change them as you like).
I also added bookmarked: false to a heading in the outline test to ensure it doesn't have any additional implications. (I also wanted to make sure we had the bookmarked option in some test in case someone accidentally breaks it in the future, I guess.)

Important: When nesting a bookmark: true heading under a bookmark: false one, as the bookmark parent is missing, child headings will be appended as children to the latest heading instead. Perhaps we should change this behavior to ensure immediate children would become top-level headings instead?

Perhaps we should change this behavior to ensure immediate children would become top-level headings instead?

That would probably make more sense. Do you think it is simple to implement?

Perhaps we should change this behavior to ensure immediate children would become top-level headings instead?

That would probably make more sense. Do you think it is simple to implement?

It might require some changes in the algorithm to build in the tree, but I'm not exactly sure yet. I will take a look.

Alright! I think I did it. The actual code changes were few, but I tried to add very explicit comments in the code explaining the algorithm (which only had a few tweaks). In summary, I made it so descendants of skipped headings can be placed in the outline at most as deep as the least deep skipped heading in their direct ancestry. That is, the least deep descendants become brothers of the least deep skipped heading, and the children of those descendants remain being their children (and the nesting structure, in general, is kept).
Things should be fine now as per my local tests, but feel free to test it a bit on your own PDFs as well.

In other words, children of skipped headings are "promoted".

This makes sense, as it matches what happens if headings of a bigger level are used before a heading with a smaller level is used.

Note that the bookmarked option is not linked to the outlined option, and defaults to true for all headings. I thought of having a bookmarked: auto default which would set it to whatever outlined is, but I decided against it (for now) as I think it's better (and more predictable) to just disable bookmarking explicitly. Feel free to present different opinions in the replies.

I strongly disagree: As a user, I would expect the PDF bookmarks to be the same as the outline. Putting outlined: false on a heading communicates the intent of it being an unimportant/hidden heading. It would be very surprising to see that show up in the PDF bookmarks anyway.

In other words, children of skipped headings are "promoted".

would it make sense to have this behaviour for outlined: false parents? i.e.
#outline(indent: 1em)
= 1
=== 1.0.1
== 1.1
=== 1.1.1
#heading(level: 2, outlined: false)[1.2]
=== 1.2.1

would currently yield the outline

though I'd argue that 1.2.1 is under 1 but not under 1.1. and should behave like 1.0.1 In the end, pdf outline and actual outline should behave the same.

Note that the bookmarked option is not linked to the outlined option, and defaults to true for all headings. I thought of having a bookmarked: auto default which would set it to whatever outlined is, but I decided against it (for now) as I think it's better (and more predictable) to just disable bookmarking explicitly. Feel free to present different opinions in the replies.

I strongly disagree: As a user, I would expect the PDF bookmarks to be the same as the outline. Putting outlined: false on a heading communicates the intent of it being an unimportant/hidden heading. It would be very surprising to see that show up in the PDF bookmarks anyway.

Well, I guess you have a point when we consider that PDF bookmarks aren't immediately visible e.g. in the Typst web editor (as the preview is done by exporting to PNG). I wonder if this could be better solved with some sort of "bookmark preview". Either way, the Typst built-in outline is generally more visible.
My thoughts, however, were mostly regarding how, if you can specify outlined: false, then you can also specify bookmarked: false. And, indeed, in the future, when we are able to apply conditional sets to elements themselves (i.e., when something like #show heading.where(outlined: false): set heading(bookmarked: false) works), you'd be able to specify such a pattern yourself. I just didn't want to introduce this sort of coupling between options with fear of it sounding arbitrary (and making it harder to get rid of this coupling in individual documents).
Still, I think that this case might be different, and it could be better UX in general to just have bookmarked be associated with outlined, as the two things are, in general, quite related. I'll be happy to hear more opinions regarding this.

In other words, children of skipped headings are "promoted".

would it make sense to have this behaviour for outlined: false parents? i.e.
/* snip */
though I'd argue that 1.2.1 is under 1 but not under 1.1. and should behave like 1.0.1 In the end, pdf outline and actual outline should behave the same.

Hmmm, this is actually an interesting thought. However, I think that bookmarks are already different from the outline, since e.g. placing a level 3 heading before any parent heading is even placed does nest it in the outline, but not in the bookmarks. I think changing the outline itself would be out of scope for this PR, but it's still interesting to think: should we keep the old and seemingly (and also arguably) "buggy" behavior of bookmarks for consistency with outlines? Or should we just use my algorithm change for the bookmarks but keep outlines as they are (and maybe later discuss if changing them is worth it)? I'd like to hear more opinions here too.

I do not have a strong opinion on this at the moment, feel free to make a decision and tell me when this is ready for merging.

I do not have a strong opinion on this at the moment, feel free to make a decision and tell me when this is ready for merging.

Alright. I think I'll take the following position then:

I'll implement bookmarked: auto and have it be the default (with auto just corresponding to the value of outlined). I think that, in the end, this will lead to more predictable behavior for the average user.
I'll probably keep the 'promotion' algorithm, as it is more consistent with the old behavior of bookmarks (e.g. when the first heading was orphaned). We can eventually change this back if needed, or even change outline if it is deemed necessary. For this PR, however, I think this will be good enough for now.
With this, we'll get the most important feature of this PR - being able to control whether headings are bookmarked or not - into Typst more quickly, without much hassle.

Ready for merging?

Ready for merging?

Should be pretty much ready now! Feel free to change comments, documentation, and so on.

Thank you!


Sunflowers problem

The sunflowers plants from the plantlife modpack is going to be a seriously (big) problem.
The spawn doesn't seems to be limited per chunck, so the sunflowers grows, grows, and grows again...
I can see right now chunck (100x100 areas) completely full of Sunflowers !
This problem needs to be fixed as soon as possible !
We can now found areas like this...

(EDIT : maybe @VanessaE can help us ?)

Aouch. Maybe should you remove all those after having implemented a fix number per area

Are you sure they expanded recently in this area ?  I used to constantly destroy tens of them near my house weeks ago but their expansion seems to have stopped now.

I think their expansion is with a condition "if any other sunflowers are near", the initial spawn isn't the reason of this impressive invasion :/

I've long since fixed this in git, and don't see the out-of-control spreading on my local worlds anymore.
Can someone else confirm please?

The MFF server runs the latest version of plantlife_modpack, i can see your fix in commits section on your repository.
But even with this fix, the amazing spawn is always here, maybe strange ?

This section was probably generated long ago.
You should try to regenerate. (it reminds me I have to disable riesenpilz's biome which has appeared, and I don't know why...)

I can confirm what Vanessa said: I planted 10 sunflowers in a plain on my working copy of the MFF repository, and let the game roll for 30 minutes in the area. Only 7 additional sunflowers grew. It's far from being out of control. For me it was fixed some time ago.

Thanks, mgl512; sounds like it could still use a small tweak but it's good enough for now.
Besides, they won't spread outside of the usual fertile-land perlin map anyway.

I generated some sunflowers on a test map, just as @mgl512 did, and after some time spent playing around them, and a long idle of my avatar, there weren't much of them. These areas have been generated just after plantlife introduced sunflowers. Since, their mapgen's parameters were modified.
Just regenerate the lands to wipe the sunflowers off.

Ok, i moved the issue tag to Minetest 0.4.13-Release because i can't do a /deleteblocks without an upadte of the minetest_core game on the server

Resolved because we changed our mapgen


Imported dashboards from v6.1 do not display any results in v7.0

The attached dashboard was initially created in v6.1 and imported into v7.0, after which the "New Table Created in v7.0" was created in v7 to show the differences.
StroomConfig.zip
Issues seen:

Unable to rename the original Table (appears to rename but saving and reopening resets the name to "Table";
The old table shows no rows when run, whilst the new table shows many rows;
The old table only shows rows once the EventTime column is removed.  This is not specific to EventTime - if importing a table with multiple columns, it will only show an output when only StreamId and EventId remain;
If the EventTime column is removed and immediately replaced without saving in between, the table displays correctly;
Same issue occurs when extraction pipeline is set to "None".

Fixed as part of #1396

Have the same issue importing a dashboard created in v7.0-beta.31 into b.32.

I think I've fixed this but have a feeling that Unable to rename the original Table (appears to rename but saving and reopening resets the name to "Table"; occurs intermittently. Please perform further testing.


Multiple instances of hyprlock should not be allowed to start

Thanks for creating hyprlock :)
I'm running it with sway and swayidle as follows:
exec swayidle \
    timeout 600 'hyprlock --quiet' \
    timeout 15 'if pgrep --exact hyprlock; then swaymsg "output * power off"; fi' resume 'swaymsg "output * power on"' \
    lock 'hyprlock --quiet --immediate' \
    before-sleep 'hyprlock --quiet --immediate' \
    after-resume 'swaymsg "output * power on"'

The idea behind this config:

After 5 min of inactivity, lock the screen
After 15 sec of inactivity, check if lock screen is running - if so, turn off displays (save my OLEDs from burning...)
If commanded to do so by loginctl or system suspend, lock the screen immediately

Now the fun part - hyprlock can be started multiple times (and does nothing when started after the first instance btw) and that indeed happens when I command the lock. After the 5 min of inactivity, another instance of hyprlock is created. Now, when I unlock the screen I still have some hyprlock instance running in the background which I don't see - but I could spot it because after 15 sec my screens are turned off :smile:
hyprlock should have a "locking mechanism" (pun intended) to allow running only one instance.
Related: #351

it should just exit if another lock is running tho

it should just exit if another lock is running tho

@vaxerski I'm on v0.3.0 version and I can easily reproduce this even without swayidle:
$ hyprlock & hyprlock & hyprlock
... first lock starts, rest goes to the bg
$ pgrep hyprlock
... I see 2 pids here after unlocking

Could be worked around with pgrep hyprlock || hyprlock until fixed.


Endless loading with ws://<IP_ADDRESS>:8090 on web wallet

In OpenLedger wallet, changing to <IP_ADDRESS>:8090 gives an endless loading error.
It should be loaded or if it's wrong behavior, changing to <IP_ADDRESS>:8090 should be impossible.

<IP_ADDRESS>:8090 should have been removed as a solution for #444

It was removed so clayop must have added it himself. This issue is different though, it's because using an insecure (ws) websocket is not allowed by the browser from a secure domain like https://bitshares.openledger.info.
I'll make sure we enforce a wss url from secure domains, that way you'll end up on the init error page if the api you enter is incorrect.


A few small cleanups

Hopefully nothing controversial.
Renames mask_valid_data to mask_invalid_data, ie. what it actually does, but leave the old function in place with a deprecation warning, for now.

Looks like ingest is still using from_sources_extents - I might have lied to you...
File "/home/travis/build/data-cube/agdc-v2/datacube/scripts/ingest.py", line 199, in _make_dataset
    valid_data=GeoPolygon.from_sources_extents(sources, tile.geobox))
AttributeError: 'function' object has no attribute 'from_sources_extents'


Add flock(2) support

Adds basic support for calling flock().
I could see going further and adding the equivalent of std::sync::Mutex's MutexGuard for automatic unlocking at the end of scope. Not sure if that would fit with the rather low-level nature of Nix, though.

Indeed, determining the scope of nix is tricky...
Anyway, thanks for the PR!


Join Giveaway with 10sec timelimit

await asyncio.sleep(randint(100, 200))
what should I change ?

#19


ImportError: DLL load failed while importing cv2

I have a problem "ImportError: DLL load failed while importing cv2: The specified module could not be found"
Information about my attempted installation
Python 3.8.10 (tags/v3.8.10:3d8993a, May  3 2021, 11:48:03) [MSC v.1928 64 bit (AMD64)] on win32
MSVC: Microsoft Visual Studio 2019
OS: Win 10
CMake gui: 3.29.2
Source cv2 files version: 4.5.0
I'm compiling opencv from source and it's all working fine, but when instantiating cv2, I get the "Import DLL .... " error occurred.
Python 3.8.10  opencv 4.5.0 opencv_contrib-4.5.0
What is the DLL file that failed to load? Why is this happening?
Also I would like to know if it is possible to make opencv implement CUDA acceleration by compiling opencv source code in the python case. If it is possible how to implement it?
Thank you,
Anthony of Sydney

The provided information is not enough to debug the issue. Two instances of OpenCV package may cause dll mix. Please ensure that you remove the first instance, when tries another one.

You case also trace OpenCV loading process by setting sys.OpenCV_LOADER_DEBUG = 1 before OpenCV import.

This could also be a duplicate of either https://github.com/opencv/opencv-python/issues/771, https://github.com/opencv/opencv-python/issues/856 and/or https://github.com/opencv/opencv-python/issues/976


environment configuration

I just took my first step in scientific research focused on 3D face reconstruction. Specific module details about the environment configuration were not found in the article and code.So could you please send me the details of the environment configuration of the article if possible(including python, tensorflow, cuda, cudnn ubantu version, etc.)? I would be very appreciated if receiving the reply.Thank you very much !

I develop the code using python 2.7, tensorflow 1.3, cuda 9.0, ubuntu16.04

I have seen it on GitHub.Your kind assistance on this are very much appreciated.Please forgive me for disturbing your busy work.
在 2019-09-06 20:50:00，"tranluan"<EMAIL_ADDRESS>写道：
Closed #17.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.


Added more data for box players including pro opponent, opponent rank…

This add features for #44, #43 and #32. These are big changes to box_score and free_agents function in the League Object

Codecov Report

Merging #51 into master will decrease coverage by 2.62%.
The diff coverage is 94.91%.

@@            Coverage Diff             @@
##           master      #51      +/-   ##
==========================================
- Coverage   95.61%   92.98%   -2.63%
==========================================
  Files          12       12
  Lines         456      499      +43
==========================================
+ Hits          436      464      +28
- Misses         20       35      +15

Impacted Files
Coverage Δ

ff_espn_api/box_score.py
100% <100%> (ø)
:arrow_up:

ff_espn_api/box_player.py
100% <100%> (ø)
:arrow_up:

ff_espn_api/league.py
92.41% <91.89%> (-5.16%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 060dad1...cdedc72. Read the comment docs.


Docker Error:unauthorized: authentication required.

I have following error when I run bash docker/scripts/dev_start.sh
Do we need docker username in apollo2.0?
4d233f0f8483: Waiting
6e03bccc2355: Waiting
docker: unauthorized: authentication required.
See 'docker run --help'.
Error response from daemon: No such container: apollo_dev

Seems no need, works fine for me.
Please re-try with -C option to see what will happen.

@zhxt Do you mean bash docker/scripts/dev_start.sh -C

@westeast yeah, since I have seen that you're from Beijing, too :-)
ps, you can find me at #apolloauto channel on freenode IRC. (AD :-D)


Delete common crd-csi-node-info.yaml and fix usage of helm3.

What type of PR is this?
/kind documentation
/kind test
What this PR does / why we need it:
Test whether blobfuse-csi-driver can pass e2e test after deleting crd crd-csi-node-info.
Which issue(s) this PR fixes:

Fixes #167
Special notes for your reviewer:
Release note:
none

/ok-to-test

/test pull-blobfuse-csi-driver-verify

if crd-csi-node-info.yaml is really not needed, we need to remove it from https://github.com/kubernetes-sigs/blobfuse-csi-driver/tree/master/deploy too, pls make the change only in master version in the first PR.

@Sakuralbj pls remove crd-csi-node-info.yaml in azure disk, azure file and smb csi drivers too, thanks.


Add shared cache, some small fixes

Problem: if we're uploading to 2+ Clickhouse servers from a single carbon-clickhouse instance - we are inherently caching tree/series/tags 2+ times in memory, which sucks.
This PR adds an ability to specify a global cache bucket for a table, which will be shared between the tables and effectively cache only one copy of the data.
By default it's empty which is a backwards-compatible setting.
Also:

Change homemade FNV hashing in CMap to xxHash64
Some build fixes: currently you cannot do gox-build on non-linux-amd64 machines due to use of the binary to generate default config. Just put empty config file instead.
Version bump

Some build fixes: currently you cannot do gox-build on non-linux-amd64 machines due to use of the binary to generate default config. Just put empty config file instead.

I will think about this problem separately. Please remove this fix from PR, it is backward incompatible. This code is used in release process by packages.sh script

Version bump

Don't do this please. Before release, I want to return the Date column to graphite_tree table as backward compatibility option

This PR adds an ability to specify a global cache bucket for a table, which will be shared between the tables and effectively cache only one copy of the data.

If the metric has been inserted into the table A, it will not be inserted into the table B. What's the point of this?


CIV-6057

Fix Exception (http 500) - java.lang.NullPointerException - 5 uk.gov.hmcts.reform.civil.utils.DocmosisTemplateDataUtils.fetchApplicantName
Before creating a pull request make sure that:

[X] commit messages are meaningful and follow good commit message guidelines
[X] README and other documentation has been updated / added (if needed)
[X] tests have been updated / new tests has been added (if needed)

Please remove this line and everything above and fill the following sections:
JIRA link (if applicable)
https://tools.hmcts.net/jira/browse/CIV-6057
Change description
Fix Exception (http 500) - java.lang.NullPointerException - 5
uk.gov.hmcts.reform.civil.utils.DocmosisTemplateDataUtils.fetchApplicantName
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[X] No

Please resolve conflicts


smp_ros: 1.0.0-0 in 'kinetic/distribution.yaml' [bloom]

Increasing version of package(s) in repository smp_ros to 1.0.0-0:

upstream repository: https://github.com/ksatyaki/smp_ros.git
release repository: https://github.com/ksatyaki/smp_ros-release.git
distro file: kinetic/distribution.yaml
bloom version: 0.6.4
previous version for package: null

Holding for Melodic release.

Tip: If you want he API of your package to be automatically generated and available on docs.ros.org, you can add a doc section to this file (you can have a look at how the other packages do it for an example)

I deliberately left out the documentation. Not all parts of the code are properly documented at the moment. Since it is not my package, it is hard for me to correct all the documentation. So I will add documentation bit by bit as I use it more and more.


Support importing cloudflare_tiered_cache

Current Terraform and Cloudflare provider version
Latest
Description
Cannot import
$ terraform import 'cloudflare_tiered_cache.default' <zone-id>

│ Error: resource cloudflare_tiered_cache doesn't support import

Use cases
Migrating from deprecated resource argument to new resource
Potential Terraform configuration
resource "cloudflare_tiered_cache" "default" {
  cache_type = "generic"
  zone_id    = "<redacted>"
}

References
https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs/resources/tiered_cache

This issue has been closed as we are now tracking this internally with service teams directly. If you would like an update or to be notified when/if the product ships with this change, please reach out to Cloudflare Support or your account team who can watch the internal feature request for you.


Improved local tx error messages (RIPD-720)

Failed local built transactions report the specific error.

Consider also updating the code in NetworkOPs.cpp to get the reason and display it for debugging purposes, and then remove the one-argument version of passesLocalChecks.

@josh-ripple, @scottschurr: does this get a pass?

@nbougalis: I'm waiting for the comments to be addressed.

@nbougalis: Yup, me too.

Sounds good - thanks!

Feedback addressed, thanks all.
ping @josh-ripple @scottschurr

I found some very minor nits, but nothing that desperately needs to be addressed.  It'll be really nice to have better visibility of these errors.  Nice work, Mickey.
:+1:

Only minor nits here and there - nothing to write home about. :+1:

Addressed feedback, thanks guys.
The Transaction ctor does not throw (didn't before) so I simplified some of the calling code.

:+1:

:+1:


Add option to ignore guard clauses in ReturnCount rule

This PR is in relation to the issue #1868
The following changes have been done:

Add option to ignore guard clauses in ReturnCount rule by using the config excludeGuardClauses, default value of the config is false
The guard clauses include two types, namely if condition and Elvis operator
The guard clauses are only ignored if they are the first statement in a function
Fun fact: one of the commit fixes ReturnCount debt in ReturnCount.kt file :)

@schalkms, thanks for the prompt review. I have made the required changes and replied to the comments. Please look into the changes when possible.
It would be great to see this PR getting merged :)

This looks great! I haven't reviewed in detail but tests passing is very promising.
I'd also like to see tests that ensure this sort of pattern is excluded by the config option too:
fun testFun(testVal: String?) {
  require(testVal != null)
  check(testVal != null)
  if (testVal != null) return
}

Essentially if require and check precede the guard clauses then the guard clause should not affect return count. Can you please add some tests for this? Or maybe we can leave this out for the first iteration.

I would recommend let's do the support for guard clauses followed by require and check in the next iteration, possibly as a part of a follow-up issue? I would be happy to pick it up.
I had a few questions with regards to the same, which we can discuss upon in the follow-up issue.

This looks great! I haven't reviewed in detail but tests passing is very promising.
I'd also like to see tests that ensure this sort of pattern is excluded by the config option too:
fun testFun(testVal: String?) {
  require(testVal != null)
  check(testVal != null)
  if (testVal != null) return
}

Essentially if require and check precede the guard clauses then the guard clause should not affect return count. Can you please add some tests for this? Or maybe we can leave this out for the first iteration.

Thanks for your review @3flex!
I would recommend doing the support for guard clauses followed by require and check functions in the next iteration, possibly as a part of a follow-up issue? I would be happy to pick it up.
I had a few questions with regards to the same, which we can discuss upon in the follow-up issue.

Codecov Report

Merging #1889 into master will decrease coverage by 0.05%.
The diff coverage is 68.75%.

@@             Coverage Diff              @@
##             master    #1889      +/-   ##
============================================
- Coverage     80.49%   80.43%   -0.06%
- Complexity     1957     1968      +11
============================================
  Files           326      326
  Lines          5495     5506      +11
  Branches       1014     1020       +6
============================================
+ Hits           4423     4429       +6
  Misses          543      543
- Partials        529      534       +5

Impacted Files
Coverage Δ
Complexity Δ

...itlab/arturbosch/detekt/rules/style/ReturnCount.kt
84.44% <68.75%> (-9.68%)
20 <13> (+11)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 521e968...1d1c2cc. Read the comment docs.

Some paths are not examined.
Please take a look at our test coverage report for ReturnCount.
https://codecov.io/gh/arturbosch/detekt/pull/1889/src/detekt-rules/src/main/kotlin/io/gitlab/arturbosch/detekt/rules/style/ReturnCount.kt?before=detekt-rules/src/main/kotlin/io/gitlab/arturbosch/detekt/rules/style/ReturnCount.kt

Some paths are not examined.
Please take a look at our test coverage report for ReturnCount.
https://codecov.io/gh/arturbosch/detekt/pull/1889/src/detekt-rules/src/main/kotlin/io/gitlab/arturbosch/detekt/rules/style/ReturnCount.kt?before=detekt-rules/src/main/kotlin/io/gitlab/arturbosch/detekt/rules/style/ReturnCount.kt

I had to revert one of the suggested cleanups to fix this issue.
Everything else looks good, thanks @3flex and @schalkms for your detailed reviews and suggestions.
Please merge this PR when the builds are successful :)


🐛 [storage-resize-images] No longer maintaining aspect ratio

[REQUIRED] Step 2: Describe your configuration

Extension name: _ (storage-resize-images)
Extension version: _(0.2.2)
Configuration values (redact info where appropriate):

_
Cloud Functions location
europe-west2
Cloud Storage bucket for images
southern-digisuite.appspot.com
Sizes of resized images
1503x902
Deletion of original file
true
Make resized images public (Optional)
true
Cloud Storage path for resized images (Optional)
Parameter not set
Paths that contain images you want to resize (Optional)
/digisuites//properties//floorplan
List of absolute paths not included for resized images (Optional)
Parameter not set
Cloud Storage path for failed images (Optional)
Parameter not set
Cache-Control header for resized images (Optional)
Parameter not set
Convert image to preferred types
false
Output options for selected formats (Optional)
Parameter not set
Sharp constructor options for resizing images (Optional)
Parameter not set
GIF and WEBP animated option (Optional)
false
Cloud Function memory
1024
Backfill existing images
false
_

[REQUIRED] Step 3: Describe the problem
Steps to reproduce:

What happened?

We have several firebase projects that all use the image resizing tool, all the projects have the exact same configurations but have different versions of the resizing tool extension. On our latest project we have noticed that the newer version of the resizing tool is not maintaining the aspect ratio of the original images uploaded.  We are uploading images that are 1000x1000 pixels. On our latest projects the images are converted to 1000x902 and on the previous projects the same images are converted to 902x902 as we are expecting.

Expected result
Images resized 902x902
Actual result
Images resized 1000x902

Hi! It seems that the default behavior was changed in this commit:
https://github.com/firebase/extensions/commit/9653f60cdec0f5dadeae3282ec86e153ad715378
To work around this issue, you need to modify the config by adding
{"fit":"inside"}
in the "Sharp constructor options for resizing images" field.

@Negativchik Brilliant, that fixed the issue. Thanks a lot for your help!
I wasn't able to find the update in the documentation, perhaps was a recent change.


PVector instead of float[]

In functions like getLookAt(), getRotations and getPosition() return a float[] array. It would be much more useful if it returned a PVector.

That's probably true, but there's no way to undo that long-ago decision. :)


Create TestCaseMixin so that TestCase and TransactionTestCase have ac…

…cess to the same helper functions.

Closes: #1949

Adds TestCaseMixin and moves the functions from TestCase to the Mixin.
TODO

[x] Explanation of Change(s)
[ ] Attached Screenshots, Payload Example
[ ] Unit, Integration Tests
[ ] Documentation Updates (when adding/changing features)
[ ] Example Plugin Updates (when adding/changing features)
[ ] Outline Remaining Work, Constraints from Design

@smk4664 Can we have this target next instead of develop? Hopefully minimize the potential impact to developers and CI on patch releases for those doing extensive jobs testing.

@smk4664 Can we have this target next instead of develop? Hopefully minimize the potential impact to developers and CI on patch releases for those doing extensive jobs testing.

I guess, but I really need this in order to fix tests for Nautobot-plugin-welcome-wizard.  We use TransactionTestCases in one of the views because it calls a job, and the TransactionTestCase does not have access to the helper functions I am trying to add here in the mixin.  This worked when testing prior to Nautobot 1.3.x as Nautobot 1.3.0 requires that Job tests use TransactionTestCase.  That is why I categorized the ticket as a bug and I am trying to introduce the fix in 1.3.x instead of having to wait for 1.4.

@smk4664 Can we have this target next instead of develop? Hopefully minimize the potential impact to developers and CI on patch releases for those doing extensive jobs testing.

I guess, but I really need this in order to fix tests for Nautobot-plugin-welcome-wizard. We use TransactionTestCases in one of the views because it calls a job, and the TransactionTestCase does not have access to the helper functions I am trying to add here in the mixin. This worked when testing prior to Nautobot 1.3.x as Nautobot 1.3.0 requires that Job tests use TransactionTestCase. That is why I categorized the ticket as a bug and I am trying to introduce the fix in 1.3.x instead of having to wait for 1.4.

The concern is that since this is missing helper functions (TransactionTestCase itself isn't broken, it just lacks implementation of all methods of TestCase) that in the meantime other users implemented this in setup themselves and that may pose conflicts. Their CI may fail on a patch release.


Added a link to the data registry in the Understanding Azure Maps Tran…

Added a link to the data registry in the Understanding Azure Maps Transactions article.

@eriklindeman

Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

@Jak-MS.  I approve this PR, @eriklindeman is OOF. cc' @stevemunk


Free account upgraded to pay-as-you-go when user request invoice

There are these documents.
Avoid charges with your Azure free account
https://docs.microsoft.com/en-us/azure/billing/billing-avoid-charges-free-account
Upgrade your Azure free account or Azure for Students Starter account
https://docs.microsoft.com/en-us/azure/billing/billing-upgrade-azure-subscription
Pay for your Azure subscription by invoice
https://docs.microsoft.com/en-us/azure/billing/billing-how-to-pay-by-invoice
But customer created free account and they changed to subscription by invoice. This account became pay-as-you-go and they were charged. I hope document mention this behavior. I appreciate if someone agreed that this is something wrong.

@hiroyuts Please submit feedback by clicking on the button at the doc's bottom.


About gb projects not being 'go get'-able

Just came across this line in the documentation on this page http://getgb.io/docs/project/:
gb projects are also not go getable as they do not follow the convention required by go get.

I am assuming this statement means more literally that 'gb projects can be retrieved, but not correctly installed, using go get'.

I was just wondering about this too.
One could create a plugin gb-get that actually creates a project directory and checks all the dependencies out to vendor/src.
something like this perhaps?
if [ -n "$1" ]; then
  echo "project is required"
fi
project="$1"
mkdir -p "src/$project"
git clone "$project" "src/$project"

GOPATH=./vendor:. go get -u $project/...

perhaps a better approach to this is something like what people do with the gh-pages branch.
You have a develop branch. when you're ready to release, you push to a subtree which is actually your master branch
develop branch:
.
├── develop
│   ├── src
│   │   └── github.com
│   │       └── something
│   │           └── useful
│   └── vendor
│       └── src
│           └── github.com
│               ├── stretchr
│               │   └── testify
│               └── tav
│                   └── golly
└── master -> develop/src/github.com/something/useful

I think this keeps it all in one repo, allows for repeatable builds and hopes for the best when you do go get.
For github you can set the default branch to develop and go get would still get the master branch.

@jbuberel

I am assuming this statement means more literally that 'gb projects can be retrieved, but not correctly installed, using go get'.

You are correct. This is a poor turn of phrase. What I was trying to say is using go get to fetch a repository containing a gb project will place the source in a layout that the go tool won't understand.
The second part of your question is, #49 and sort of covered in http://getgb.io/faq/library/.
What I should do is add an example to the examples section with graphs and arrows showing which pieces of a library project need to be transplanted (or embedded) into a downstream project.

@casualjim please see http://getgb.io/faq/why-not-wrap/ and also the long sprawling discussion in #42. Long story made short, if you want to wrap the go tool, use godep.

@casualjim

perhaps a better approach to this is something like what people do with the gh-pages branch.
You have a develop branch. when you're ready to release, you push to a subtree which is actually your master branch

This sounds a little tangental to the original question. You're starting to describe a process where Go programmers could release their code, which is not something that is commonly done at the moment.
I'm not saying this is not a good thing, just that it is unrelated to Jason's question. Could I ask you to take this tangent to a new issue ?

@jbuberel I wanted to keep http://getgb.io/rationale/ short, it's already too long for most casual readers, do you think that sentence can be addressed in place, or would it be better to write a faq/ and link to it from that page?

Actually I think it's the same as what's answered in the faq.

Both could probably do with some word smithing. Patches accepted (sincerely)
On Wed, May 13, 2015 at 8:05 AM, Ivan Porto Carrero <
<EMAIL_ADDRESS>wrote:

Actually I think it's the same as what's answered in the faq.
—
Reply to this email directly or view it on GitHub
https://github.com/constabulary/gb/issues/78#issuecomment-101436098.

https://github.com/constabulary/getgb.io/pull/13

Closing this issue for the moment.


updating to use secrets

@bparees ptal

lgtm.

wait you missed updating the DB DC.

@bparees this one should be fixed now

you missed the dbadminpassword in the DB dc.

@bparees this one should be good now

lgtm


Merge alcoholic beverage (FOODON_00001579) with beverage alcohol FOODON_03310661 ?

This is just a suggestion but I think 'alcoholic beverage' (FOODON_00001579) should be merged with 'beverage alcohol' (FOODON_03310661 )?
As far as I can tell, these refer to the same thing, but possibly one was imported from somewhere?
Anyways, for my purposes, 'alcoholic beverage' is what I want and will change it on my end.

Thank you for drawing attention to this issue. After reviewing these (and other terms) I don't think we should merge the suggested terms as "alcoholic beverage" is broad enough to encompass non-distilled and distilled beverages whereas "beverage alcohol", and it's almost identical counterpart "beverage (alcoholic, distilled)", are specifically distilled beverages. The former two only differ because "beverage alcohol" has the quality 'fully heat-treated' in an rdfs:comment SIREN DB annotation (but it doesn't actually show up in description relationships).
I think we should merge "beverage alcohol" and "beverage (alcoholic, distilled)" and rename it something along the lines of "alcoholic beverage (distilled)". I'll include the "heat treated" quality from "beverage alcohol" because true spirit distillation always involves heat treatment. They could also possibly be combined with "distilled spirit" which is already a subclass of "alcoholic beverage".
There are spirits that are said to be treated with cold/freeze distillation but that is a misnomer because it is not actually distillation but rather a solution enrichment/concentration via fractional freezing. Thus, I could also add "alcoholic beverage (fractional freezing)" or "alcoholic beverage (cold distilled)" to cover this category.
SUGGESTION 1)
"alcoholic beverage" encompasses distilled and non-distilled alcohol.
"alcoholic beverage (distilled)" refers to true distilled alcohol, has heat-treated quality. Can be combined with "distilled spirit".
"alcoholic beverage (cold distilled)" refers to fractional freezing, non-true cold distillation alcohol isolation processes.
SUGGESTION 2)
"alcoholic beverage" encompasses distilled and non-distilled alcohol.
"alcoholic beverage (distilled)" refers to any distilled alcohol. Can be combined with "distilled spirit".
"alcoholic beverage (heat distilled)" refers to true distillation alcohol isolation processes AND is a subclass of "alcoholic beverage (distilled)".
"alcoholic beverage (cold distilled)" refers to fractional freezing, non-true cold distillation alcohol isolation processes AND is a subclass of "alcoholic beverage (distilled)".
With either suggestion, I'll be sure to review annotations on all the terms to make sure they are comprehensive and clear.

Renaming 'beverage alcohol' would be good. I am okay (indifferent) to the other mergers suggested, but I highly recommend adding a specific definition to clarify some of what you said.
For my use, I needed 'alcoholic beverage' (but accidentally selected 'beverage alcohol' ) and 'beer'.  After reasoning, I was confused as to why 'beer' was not a child of 'beverage alcohol'.
So, in whichever version you go with, consider the Descendents when choosing the structure.

Thanks for doing this!

This is now in our foodon-edit.owl draft

loaded up live.


Update project dependencies

What is the rationale here? Does the current version of the plugin not work with newer versions of the other tools?

@sjrd Just maintaining the project up-to-date so that people can know that they can safely use the latest version of Vite


8453 Experiments

Experiments with #8453

Does this work?

Nope 😞
Might need to find some backup on this one, the answer may be really simple but I've never seen anything like it and the generated .d.ts for RQ seems correct


Client Side Authentication Issue

It seems as though something has changed in the AppConfigCredential.signRequest method. Here's what I have:

The NPM package @azure/app-configuration version 1.0.1
Using TypeScript
Connecting using const client = new AppConfigurationClient('<connection string>');

In the logs, I'm seeing the following:
core.js:6228 ERROR Error: Uncaught (in promise): TypeError: Object(...) is not a function
TypeError: Object(...) is not a function
    at AppConfigCredential.signRequest (appConfigCredential.js:23)
    at<EMAIL_ADDRESS>(signingPolicy.js:20)
    at<EMAIL_ADDRESS>(signingPolicy.js:24)
    at<EMAIL_ADDRESS>(generateClientRequestIdPolicy.js:24)

Issue moved to Azure/azure-sdk-for-js #9585 via ZenHub