MSFT_xWebsite support for FTP websites

The MSFT_xWebsite currently lacks support for managing FTP websites. I would like to bring a vote for implementing this.

Seems like a good idea to me.

I was planning to support FTP bindings in pull request #69 but decided to postpone it. It requires to rework the logic behind the site's Started/Stopped state.
For example if a site has both FTP and HTTP bindings, when you want the Website to be Stopped, the FTP site will be still Started. As soon as my PR is merged, I will be able to start working on it.

Hello! Any update on this? Last comment is 3 months old. I wonder if @SNikalaichyk had the time to have a look into this. Thanks

Hi @gigi81,
Unfortunately no.

@nzspambot ,
No. Please feel free to implement it.

So to show a bit of ignorance, how does this differ from changing a binding/port on a website (something that could be added to xWebsite) and needing to spawn its own resource? I'm good with either one as long as it makes sense.

Wouldn't it be a bit of both though? I'm thinking the former sounds pretty good though.

Waiting for PR https://github.com/PowerShell/xWebAdministration/pull/202.

The PR #202 was closed. Shouldn't we close this issue too?

I have reopen the PR and labeled it abandoned and hopefully the author wish to continue the work on it, otherwise I hope another contributor want to continue the work.

The PR has been closed again, should it be opened again so someone else can work on this. This functionality would be really helpful.

I think someone else can continue the work and send in a new PR. Can anyone pick up PR #202?
See this how to continue working on an abandoned PR.
https://github.com/PowerShell/DscResources/blob/master/GettingStartedWithGitHub.md#how-to-continue-working-on-a-pull-request-pr-when-an-author-contributor-is-unable-to-complete-it


BaseRecalibrator made to fit the skeleton, including local and cloud tests.

new version of BaseRecalibratorDataflow that fits into the skeleton framework
new command-line BaseRecalibratorDataflow that uses the same code
tests and test inputs for BaseRecalibrator. They pass, locally and on the cloud.
fix for issue #791 via a new genomics-dataflow-java release
smaller changes, like == -> .equals in SequenceDictionaryUtils and using getInstance() to follow the singleton pattern.

Looks like Travis is failing because org.broadinstitute.hellbender.engine.dataflow.transforms.composite.RefBasesForReadsUnitTest.refBasesTest[1] runs out of memory. Not sure if that's my fault.

Will review first thing Monday morning (am out today). Recommend working on getting tests passing in the mean time (both the failing test(s) in this branch and cloud tests in general).

I cannot reproduce the failure for PairReadsWithRefBasesUnitTest.testPairReadsWithRefBasesWithCustomWindowFunction locally. Here it runs fine.

Well, looks like that was a flaky test! My push didn't touch anything related to that code, and yet that test passes now. Great!
When running this branch locally, all of the cloud and bucket tests pass. So the best way to fix those tests is to review this branch and get it in.

Review complete -- back to @jean-philippe-martin . Since there were a couple of serious bugs (in ReferenceDataSourceFromReferenceBases and BaseRecalibratorFn) as well as a few significant holes in test coverage (ReferenceDataSourceFromReferenceBases and RefAPISource. getReferenceSequenceDictionary()), I think we should do a quick second-round review once the first-round comments are addressed.

Thank you very much for the excellent review!

Fixing the tests failures. Some simple ones (test groups now "_todo", rename test inputs on git too). One of them is weird, and only reproduces with the command line... after many minutes of running...

It's fine that you deleted the test class for BaseRecalibratorWorker when that class was deleted, but since BaseRecalibratorWorker has now been transformed into BaseRecalibratorFn, do you think we need direct tests for BaseRecalibratorFn itself, or is it adequately covered via the main BQSR tests?

Second-pass review complete -- back to @jean-philippe-martin. After addressing the comments from this round and fixing failing tests, feel free to rebase/merge when ready.

Excellent point about BaseRecalibratorFn, I've put the corresponding tests back in.

Rebased. Tests pass on my machine... hopefully they'll pass on Travis as well.

sigh. And no report, either.

Total time for cloud tests: 10min, 29s.
Travis timeout: 10min

Marking cloud test as "todo" for now so I can merge.

http://docs.travis-ci.com/user/build-timeouts/#Build-times-out-because-no-output-was-received
use that to extend the waiting time.
On Aug 18, 2015 9:13 PM, "JP Martin"<EMAIL_ADDRESS>wrote:

Marking cloud test as "todo" for now so I can merge.
—
Reply to this email directly or view it on GitHub
https://github.com/broadinstitute/hellbender/pull/812#issuecomment-132408527
.

@lbergelson OK, trying that.

It's green! Miracle! Merging :-)


Remove macOS 10.13 from the build matrix

We support N-2 macOS releases so 10.13 can be dropped now that Big Sur
is out.
Signed-off-by: Tim Smith<EMAIL_ADDRESS>

Putting this on hold pending releng work to get macOS 10.14 builders working.


Doesn't work with sites behind a login

For instance, a private dev site.

I'm trying to use wraith with a django site where all the pages requires login.  My attempt at a script for before_capture runs but I'm not getting any screens captured.  If I run without the script I get images of the login screen.  Can anyone suggest what I'm doing wrong or if there is a better way?  I've looked at the cookie option but django generates a session with the user authentication inside, so it seemed a good idea to use the normal login form if possible:
module.exports = function (casper, ready) {

           casper.echo(casper.page.url);

    // if it wants me to login then do
    if (casper.exists('#username') && casper.exists('#password')) {

        casper.echo('login required');

        casper.fill('#login-form', {username: 'testing', password: '1234567'}, true);

        var next = casper.page.url.split("next=");
        var nexturl = 'http://<IP_ADDRESS>:8000' + next[1];

        casper.echo('redirecting to '+nexturl);

        //require('utils').dump(casper.page);

        casper.open(nexturl);

        casper.then(function () {
            setTimeout(ready, 10000);
        });
    }
}

Output is:
(board)iMacs-iMac:_testing phoebebr$ wraith history configs/history.yaml
DEBUG: #################################################
DEBUG:   Wraith version:     3.1.0
DEBUG:   Ruby version:       ruby 2.0.0p481 (2014-05-08 revision 45883) [universal.x86_64-darwin14]

DEBUG:   ImageMagick:        Version: ImageMagick 6.9.2-10 Q16 x86_64 2015-12-21 http://www.imagemagick.org

DEBUG:   PhantomJS version:  1.9.6

DEBUG:   CasperJS version:   1.0.0

DEBUG: #################################################
DEBUG:
Config validated. No serious issues found.
Creating Folders
SAVING IMAGES
DEBUG: casperjs  '/Library/Ruby/Gems/2.0.0/gems/wraith-3.1.0/lib/wraith/javascript/casper.js' 'http://<IP_ADDRESS>:8000/' '320,600x768,768,1024,1280' 'shots/home/MULTI_casperjs_dev.png' 'body' '/Users/phoebebr/Development/commshub/_testing/javascript/login.js' 'false'
DEBUG: casperjs  '/Library/Ruby/Gems/2.0.0/gems/wraith-3.1.0/lib/wraith/javascript/casper.js' 'http://<IP_ADDRESS>:8000/dashboard' '320,600x768,768,1024,1280' 'shots/dashboard/MULTI_casperjs_dev.png' 'body' '/Users/phoebebr/Development/commshub/_testing/javascript/login.js' 'false'
http://<IP_ADDRESS>:8000/accounts/login/?next=/

login required

redirecting to http://<IP_ADDRESS>:8000/

http://<IP_ADDRESS>:8000/accounts/login/?next=/dashboard/

login required

redirecting to http://<IP_ADDRESS>:8000/dashboard/

The docs don't seem to mention this, was any progress ever made in this issue?


Import dependencies

Hi,
I added some dependencies to my project, but the feature is not appearing.
Ex: MetisMenu.js, -> it is inside my node_modules but when I use the elements it appears as if it did not.
With jquery-slimscroll it was the same thing.
to try to escape this problem, I copied inside a folder lib o .js and in my module I am doing:
require("../lib/metisMenu.js");
but I have many dependencies, where and how would it be right?

I think you need to include a bit more about your configuration. Show us a piece of the code where you try to import the node_modules files you are referring to.
Include any errors you may be receiving related to your issue, and feel free to use some formatting to make it easily readable for anyone passing by. This makes it easier to help you, and in turn, helps others figure out similar issues.
Suggest this issue gets closed until it is updated with more background information.


CA Year-End Payroll rates

Docs Build status updates of commit 4407ae7:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

dynamics-gp/payroll/CAN18YETax.md
:white_check_mark:Succeeded
View

dynamics-gp/payroll/media/FED2022.JPG
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Supplementary characters in the parameters might cause errors when calculating hash values

Resources with sup. are rejected
To Reproduce

Create a patient with supplementary characters

{
  "resourceType": "Patient",
  "id": "example",
  "name": [
    {
      "family": "𐌁𐌂𐌃𐌄"
    }
  ]
}

Observe error response

Failed to call access method: org.springframework.dao.InvalidDataAccessApiUsageException: Trailing high surrogate at end of input; nested exception is java.lang.IllegalArgumentException: Trailing high surrogate at end of input
Expected behavior
Resource is created and success response is returned

Fixed by #2397


refactor: Remove observability/adot-amp-* examples; users can referto the terraform-aws-observability-accelerator project

What does this PR do?

Remove observability/adot-amp-* examples; users can referto the terraform-aws-observability-accelerator project

Motivation

Updating what observability examples will be shown under the EKS Blueprints project versus the Observability Accelerator

More

[ ] Yes, I have tested the PR using my local account setup (Provide any test evidence report under Additional Notes)
[ ] Yes, I have added a new example under examples to support my PR
[ ] Yes, I have created another PR for add-ons under add-ons repo (if applicable)
[ ] Yes, I have updated the docs for this feature
[x] Yes, I ran pre-commit run -a with this PR

Note: Not all the PRs require a new example and/or doc page. In general:

Use an existing example when possible to demonstrate a new addons usage
A new docs page under docs/add-ons/* is required for new a new addon

For Moderators

[ ] E2E Test successfully complete before merge?

Additional Notes

the examples that have been removed or renamed will fail - this is expected

Should we add a readme with a reference to observability accelerator ?


Fixed the dropdown pane's alignment in RTL mode #7560

This PR fixes the top and bottom dropdown pane's alignment in RTL mode #7560

@gakimball It's been long time since I sent this PR, there was no conflict but now there is..

@abdullahsalem I'll worry about dealing with the conflict and hopefully get this in soon.  I need to get some test cases together for RTL to make sure we don't have any regressions or other issues (and to help us moving forward), and then I'll get this merged.  Thanks for putting this together.

@kball To help us test RTL, I added a third CSS file, foundation-rtl.css, to the available assets. So you can load that the same way we're loading the flexbox-specific CSS in our visual tests. ba19d189c60f818971ea40f94d0e5495239e52c2

OK, I pulled this fix over, built a test, verified this works and fixes the dropdown issues.  Going to close this PR as it was easier to do in a new branch than resolve the conflicts, but the change is in 6.2-stable.

Thanks @kball and @gakimball
I've just noticed your replies.

@gakimball @kball I would appreciate it if you take a look at my comment here. I haven't tested the new commits yet, but I believe that piece of code should be removed.


I've got some installation issue

After I have done with bower install -> include scripts -> not yet included in module
this happens in my console
angular-spinner.js:15 Uncaught TypeError: Cannot read property 'module' of undefinedfactory @ angular-spinner.js:15(anonymous function) @ angular-spinner.js:136(anonymous function) @ angular-spinner.js:138
main.controller.js:21

If I add to the app.module the angularSpinner dependency are simply not defined.
I think the problem is from the angular-spinner.js source.
thank you.

Hi @heygema ,
Thanks for reporting
We've decided to refactor the whole base code because of the many requests of webpack and amd compatibility issues, and we're using already webpack in master branch (+TypeScript).
When we publish the new release in the next days you won't encounter any installation issues

Thanks for your concern, webpack is awesome.

Absolutely!


Scaling up the cos-proxy ends up with non-leaders erroring

Bug Description
COS Proxy tries to write to application data even from units that are not currently the leader. This makes them crash.
To Reproduce

Deploy COS Proxy
Scale it to two
💣

Environment
N/A
Relevant log output
unit-cos-proxy-5: 16:16:53 ERROR unit.cos-proxy/5.juju-log downstream-grafana-dashboard:614: Uncaught exception while in charm code:
Traceback (most recent call last):
  File "./src/charm.py", line 431, in <module>
    main(COSProxyCharm)
  File "/var/lib/juju/agents/unit-cos-proxy-5/charm/venv/ops/main.py", line 436, in main
    _emit_charm_event(charm, dispatcher.event_name)
  File "/var/lib/juju/agents/unit-cos-proxy-5/charm/venv/ops/main.py", line 144, in _emit_charm_event
    event_to_emit.emit(*args, **kwargs)
  File "/var/lib/juju/agents/unit-cos-proxy-5/charm/venv/ops/framework.py", line 354, in emit
    framework._emit(event)
  File "/var/lib/juju/agents/unit-cos-proxy-5/charm/venv/ops/framework.py", line 830, in _emit
    self._reemit(event_path)
  File "/var/lib/juju/agents/unit-cos-proxy-5/charm/venv/ops/framework.py", line 919, in _reemit
    custom_handler(event)
  File "/var/lib/juju/agents/unit-cos-proxy-5/charm/lib/charms/grafana_k8s/v0/grafana_dashboard.py", line 1688, in _update_remote_grafana
    grafana_relation.data[self._charm.app]["dashboards"] = json.dumps(stored_data)
  File "/var/lib/juju/agents/unit-cos-proxy-5/charm/venv/ops/model.py", line 1473, in __setitem__
    self._validate_write(key, value)
  File "/var/lib/juju/agents/unit-cos-proxy-5/charm/venv/ops/model.py", line 1459, in _validate_write
    raise RelationDataAccessError(
ops.model.RelationDataAccessError: cos-proxy/5 is not leader and cannot write application data.

Additional context
No response

Will be closed in #44


uint64_t4 missing from Metal backend

According to the Metal spec, there is no uint64_tN type. However, there are ulong4's which are 32 bytes total (8 bytes per component).
At the moment, Slang appears to map vec<uint64_t, 4> to uint64_t4, which is causing certain shaders to generate compilation errors. This is causing the tests for PR #5020 to fail.
Could we have vectors of 64-bit integers map to Metal's ulongN types?

Looks like we can fix this by adding a little logic to slang-emit-metal.cpp: https://github.com/shader-slang/slang/pull/5020#issuecomment-2350105204
I'll should be able to fix this.

PR #5020 has a fix for this issue as part of the bitfield intrinsics. Once that’s merged, we can close this issue.

This is fixed. We now always emit long for int64_t and ulong for uint64_t on metal.


chore(besu): remove web3-eea typings file

In the newer version of web3-eea, they authors provide a d.ts file, so we do not need to maintain our own version of it.
Depends on https://github.com/ConsenSys/web3js-eea/pull/166 (not just merged but also released/published)

@petermetz Hello Peter I'll be taking this ticket too. Thank you


Getting started not working

Describe the Issue
I'm trying this action in an empty repository and I'm not able to make it working. It says something about missing permissions but it's not specifying which one is missing.
I put the attached workflow in main branch, then I opened a pull request and commented it with
.ping | LOG_LEVEL=debug,CPU_CORES=4

Action Configuration
name: "command demo"

# the workflow to execute on is comments that are newly created
on:
  issue_comment:
    types: [ created ]

# permissions needed for reacting to IssueOps commands on issues and PRs
permissions:
  pull-requests: write
  issues: write
  checks: read

jobs:
  demo:
    runs-on: ubuntu-latest
    steps:
      # execute IssueOps command logic, hooray!
      # this will be used to "gate" all future steps below
      - uses<EMAIL_ADDRESS>        id: ping
        with:
          command: ".ping"

      # run your custom logic for your project here - example seen below

      # conditionally run some logic here
      - name: ping command
        if: ${{ steps.ping.outputs.continue == 'true' }}
        run: echo 'Got comment in PR \#${{ steps.ping.outputs.issue_number }} with params ${{ steps.ping.outputs.params }}'

Relevant Actions Log Output
Run<EMAIL_ADDRESS>##[debug]checking if the context of 'issue_comment' is valid
🧮 detected parameters in command: LOG_LEVEL=debug,CPU_CORES=4
##[debug]raw allowlist value: false
##[debug]no allowlist provided, all users are allowed
Error: GraphqlResponseError: Request failed due to following response errors:
 - Resource not accessible by integration
    at /home/runner/work/_actions/github/command/v1.2.2/node_modules/@octokit/graphql/dist-node/index.js:113:1
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at prechecks (/home/runner/work/_actions/github/command/v1.2.2/src/functions/prechecks.js:129:1)
    at run (/home/runner/work/_actions/github/command/v1.2.2/src/main.js:78:1)
Error: Request failed due to following response errors:
 - Resource not accessible by integration

Extra Information
It would be very useful if the action uses some core.debug calls in its codebase to better track issues like this one. At the moment even with debug mode there is no output from the action itself.

Using this exact yaml:
name: "command demo"

# the workflow to execute on is comments that are newly created
on:
  issue_comment:
    types: [ created ]

# permissions needed for reacting to IssueOps commands on issues and PRs
permissions:
  pull-requests: write
  issues: write
  checks: read

jobs:
  demo:
    runs-on: ubuntu-latest
    steps:
      # execute IssueOps command logic, hooray!
      # this will be used to "gate" all future steps below
      - uses: github/command@main
        id: ping
        with:
          command: ".ping"

      # run your custom logic for your project here - example seen below

      # conditionally run some logic here
      - name: ping command
        if: ${{ steps.ping.outputs.continue == 'true' }}
        run: echo 'Got comment in PR \#${{ steps.ping.outputs.issue_number }} with params ${{ steps.ping.outputs.params }}'

Commenting on this pull request: https://github.com/GrantBirki/actions-sandbox/pull/127#issuecomment-2537972642
I get results that are expected: https://github.com/GrantBirki/actions-sandbox/actions/runs/12291435545/job/34300203115

I'm not sure why you are getting that error but it is almost always related to your workflow not having the correct permissions block (or a bug in my code).

I made it work by adding the contents: read permission while playing with github/branch-deploy, it explicitly mentioned it in the errors compared to command.


Upgrade AMI to Centos 6.7

http://wiki.centos.org/Manuals/ReleaseNotes/CentOS6.7

CentOS 6.7 is not officially released, see release notes and
http://wiki.centos.org/AdditionalResources/Repositories/CR.
On Jul 27, 2015 10:44 PM, "Alex Rothberg"<EMAIL_ADDRESS>wrote:

http://wiki.centos.org/Manuals/ReleaseNotes/CentOS6.7
—
Reply to this email directly or view it on GitHub
https://github.com/awslabs/cfncluster/issues/60.

Closing this, as 6.7 will be supported when released as part of regular CfnCluster updates.


Migrate to GuardRunnable

Summary:

Deprecates Guard.invoke
Adds GuardRunnable and Guard.to_runnable

Scheduled for v0.4.5
Still needs tests!

TODO:

[ ] Test with langchain-core 0.2.x


Adjusted fc.util.extent to be component #646

Also includes the include and pad methods. Note: pad will only scale number ranges, for the moment. If we want to implement scaling other types of range (e.g. date) then I see this as a separate issue.
Post review TODO list:

[x] remove d3.functior
[x] make use of include
[x] try supporting Date, if it is easy to do

[ ] remove d3.functior
[ ] make use of include
[ ] try supporting Date, if it is easy to do

Nice job @owennw

Sorry, I know I'm commenting late on this but I've only just spotted it when browsing the site (I'm really liking all the new documentation). Did you consider making fields part of the configuration of the component?

That crossed my mind too, but I couldn't decide whether the fields were effectively part of the input data to the component, rather than component state.
Other than juggling the bracket locations, can you see any other benefits to making the fields a property of the component?

Static versus dynamic configuration (most of the time)
Removal of unnamed parameter
Unlikely to want an include which affects both dimensions e.g. date and
price
On Tue, 27 Oct 2015 23:21 Colin Eberhardt<EMAIL_ADDRESS>wrote:

That crossed my mind too, but I couldn't decide whether the fields were
effectively part of the input data to the component, rather than component
state.
Other than juggling the bracket locations, can you see any other benefits
to making the fields a property of the component?
—
Reply to this email directly or view it on GitHub
https://github.com/ScottLogic/d3fc/pull/674#issuecomment-151673307.

Removal of an unnamed parameter

That's a very good point, moving from this:
fc.util.extent()(data, ['high', 'low'])

to this:
fc.util.extent().fields('high', 'low')(data)

certainly improves the API. I'd also simplify the API so that the fields property only supports a variable argument list.

Unlikely to want an include which affects both dimensions e.g. date and price

I'm unsure what this implies. An extent is for a single dimension of the data -- the extent for the other dimension could use an include too. How does changing the API affect that?

Unlikely to want an include which affects both dimensions e.g. date and price
I'm unsure what this implies. An extent is for a single dimension of the data -- the extent for the other dimension could use an include too. How does changing the API affect that?

I think what Chris means is that currently you can currently construct an extent as follows:
var extentWithInclude = fc.util.extent().include(20)

Then you can apply it to multiple dimensions
var xDomain = extentWithInclude(data, 'x');
var yDomain = extentWithInclude(data, 'y');

However, how realistic is this as an example? How often are you going to want to have an extent with the same value included for multiple dimensions?
I don't think there is a single example of this in our current codebase.

Might be worth considering not making it varargs. I think that's the d3
standard (e.g. scale range/domain) to permit returning the same thing from
the "getter"
On Wed, 28 Oct 2015 09:38 Colin Eberhardt<EMAIL_ADDRESS>wrote:

Unlikely to want an include which affects both dimensions e.g. date and
price
I'm unsure what this implies. An extent is for a single dimension of the
data -- the extent for the other dimension could use an include too. How
does changing the API affect that?
I think what Chris means is that currently you can currently construct an
extent as follows:
var extentWithInclude = fc.util.extent().include(20)
Then you can apply it to multiple dimensions
var xDomain = extentWithInclude(data, 'x');
var yDomain = extentWithInclude(data, 'y');
However, how realistic is this as an example? How often are you going to
want to have an extent with the same value included for multiple dimensions?
I don't think there is a single example of this in our current codebase.
—
Reply to this email directly or view it on GitHub
https://github.com/ScottLogic/d3fc/pull/674#issuecomment-151780878.

So something like fc.util.extent.fields(['high', 'low'])(data)?


How to change the right menu ?

I want to make the right menu different from the left menu in appearance.I want to create a listview below the right menu item. For that,should i need to create another xml or add new items to the existing residemenu_item and add it to right menu using DIRECTION_RIGHT ?Please help...

make new ResiduMenu variable i guess, of course with new ResiduMenuItem variable and add the newResiduMenu behavior to right, like this :
newResideMenu.addMenuItem(RightItem, ResideMenu.DIRECTION_LEFT);
*note : both menu and item must be different for the left and right
thanks


api: added playbackPolicy to create stream req & stream object

@gioelecerati can we close / merge this?

@gioelecerati can we close / merge this?

Going to close it, as playback policies are more complex anyway, so if we need this change we will do it differently


Version 1.2.7 does not work with Version 2 of the nuPyProp Tables

Here is what the program reports, note Ver 3 of the tables do work:
Traceback (most recent call last):
  File "/Users/jkrizman/anaconda3/bin/nuspacesim", line 8, in <module>
    sys.exit(cli())
  File "/Users/jkrizman/anaconda3/lib/python3.7/site-packages/click/core.py", line 1128, in __call__
    return self.main(*args, **kwargs)
  File "/Users/jkrizman/anaconda3/lib/python3.7/site-packages/click/core.py", line 1053, in main
    rv = self.invoke(ctx)
  File "/Users/jkrizman/anaconda3/lib/python3.7/site-packages/click/core.py", line 1659, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/Users/jkrizman/anaconda3/lib/python3.7/site-packages/click/core.py", line 1395, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/Users/jkrizman/anaconda3/lib/python3.7/site-packages/click/core.py", line 754, in invoke
    return __callback(*args, **kwargs)
  File "/Users/jkrizman/anaconda3/lib/python3.7/site-packages/nuspacesim/apps/cli.py", line 199, in run
    write_stages=write_stages,
  File "/Users/jkrizman/anaconda3/lib/python3.7/site-packages/nuspacesim/compute.py", line 143, in compute
    tau = Taus(config)
  File "/Users/jkrizman/anaconda3/lib/python3.7/site-packages/nuspacesim/simulation/taus/taus.py", line 87, in __init__
    self.pexit_grid = NssGrid.read(file, path="/", format="hdf5")
  File "/Users/jkrizman/anaconda3/lib/python3.7/site-packages/nuspacesim/utils/grid.py", line 76, in __call__
    return registry.read(self._cls, *args, **kwargs)
  File "/Users/jkrizman/anaconda3/lib/python3.7/site-packages/astropy/io/registry.py", line 527, in read
    data = reader(*args, **kwargs)
  File "/Users/jkrizman/anaconda3/lib/python3.7/site-packages/nuspacesim/utils/grid.py", line 327, in hdf5_nssgrid_reader
    griddata = f[path]["__nss_grid_data__"][()]
  File "h5py/_objects.pyx", line 54, in h5py._objects.with_phil.wrapper
  File "h5py/_objects.pyx", line 55, in h5py._objects.with_phil.wrapper
  File "/Users/jkrizman/anaconda3/lib/python3.7/site-packages/h5py/_hl/group.py", line 305, in __getitem__
    oid = h5o.open(self.id, self._e(name), lapl=self._lapl)
  File "h5py/_objects.pyx", line 54, in h5py._objects.with_phil.wrapper
  File "h5py/_objects.pyx", line 55, in h5py._objects.with_phil.wrapper
  File "h5py/h5o.pyx", line 190, in h5py.h5o.open
KeyError: "Unable to open object (object '__nss_grid_data__' doesn't exist)"

We have elected to reformat the v2 (and v1) tables and drop the no regen data.


Can't contribute to translations, yet

I translated most of the Weblate resources just now and realized I don't have permissions to do so…
https://hosted.weblate.org/user/kingu/ is the account.
If it is just because of the current reason it is locked,
https://docs.weblate.org/en/latest/admin/continuous.html?highlight=webhook#automatically-receiving-changes-from-github and adding https://github.com/weblate is probably what you want. :)

@blanchardjeremy thanks so much.
What language were you translating to?
We were actually only just now trying out weblate and hadn't settled on it as a solution. Did you do the translations inside weblate? Do you have them saved somewhere?
We're also trying out Crowdin as well.

@blanchardjeremy nb_NO. (Norwegian Bokmål).
Crowdin is COVID-20, in software form. The project is shown in the list of projects one can add from https://hosted.weblate.org/accounts/profile/#notifications
Got the translations open in the Zen editor, hopefully they can be saved once the project opens or permissions are granted.

@comradekingu, thanks for contributing!
Weblate is great, but it keeps creating merge conflicts for itself and offers zero way to fix them manually, even if they would be trivial to fix (in 99% of the cases just a simple "use your version" would be the solution). So it sometimes automatically locks itself or I need to do it manually during a merge window.
It's been unlocked since this issue was opened (and locked again, and unlocked again, and so on :)), so this now seems to be moot. Let me know if you still encounter problems.


Added Minecraft Launcher version <IP_ADDRESS>.

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?

Microsoft Reviewers: Open in CodeFlow

https://github.com/microsoft/winget-pkgs/pull/2902#issuecomment-669287422
https://github.com/microsoft/winget-pkgs/pull/1544#issue-427349985

https://github.com/microsoft/winget-pkgs/pull/2902#issuecomment-669287422
https://github.com/microsoft/winget-pkgs/pull/1544#issue-427349985

Using the PC Launcher linked as it is now always complains that the user should be using the MS Store launcher, but that is not reachable from winget for some reason...

Apps that rely on Xbox stuff (i.e. Gamepass, Live, etc) aren’t available via the msstore source. I’ve been meaning to open a ticket about that…

Issue created: https://github.com/microsoft/winget-cli/issues/1833


Configuration fetch time error in Apollo UI instance list

[x] I have checked the discussions
[x] I have searched the issues of this repository and believe that this is not a duplicate.
[x] I have checked the FAQ of this repository and believe that this is not a duplicate.

Describe the bug

Configuration fetch time error in Apollo UI instance list, The currently displayed releaseDeliveryTime

To Reproduce

Create the app, publish the configuration
Pull the configuration
Observation panel configuration fetch time

Expected behavior
Should show when the configuration was pulled instead of when it was published, Or here we can keep the release time and the configuration fetch time
Additional Details & Logs

Version: 2.0.1

I believe this field does show the configuration fetched time...
e.g. You may retrieve the demo configuration via http://<IP_ADDRESS>:8080/configs/100004458/default/application and see te instance list in http://<IP_ADDRESS>/config.html?#/appid=100004458

e.g. You may retrieve the demo configuration via http://<IP_ADDRESS>:8080/configs/100004458/default/application and see the instances list in http://<IP_ADDRESS>/config.html?#/appid=100004458

There is a problem with this test, when instance A already exists in the database, instance A fetches the configuration again, and the configuration fetch time will not be updated.

There is a problem with this test, when instance A already exists in the database, instance A fetches the configuration again, and the configuration fetch time will not be updated.

This I think is by design, see line 112.
https://github.com/apolloconfig/apollo/blob/b1f78b4cc708b6a1cdd68fb6dccf0d77471a805e/apollo-configservice/src/main/java/com/ctrip/framework/apollo/configservice/util/InstanceConfigAuditUtil.java#L107-L122

private static final long OFFER_TIME_LAST_MODIFIED_TIME_THRESHOLD_IN_MILLI = TimeUnit.MINUTES.toMillis(10);//10 minutes

Configuration fetches within ten minutes do not update the configuration fetch time. This can explain the second record below, but the configuration fetch time of the first record is actually not easy to explain

Another example

This is because of the following logic, which is to reduce the database burden to write the records.
https://github.com/apolloconfig/apollo/blob/b1f78b4cc708b6a1cdd68fb6dccf0d77471a805e/apollo-configservice/src/main/java/com/ctrip/framework/apollo/configservice/util/InstanceConfigAuditUtil.java#L72-L73
https://github.com/apolloconfig/apollo/blob/b1f78b4cc708b6a1cdd68fb6dccf0d77471a805e/apollo-configservice/src/main/java/com/ctrip/framework/apollo/configservice/util/InstanceConfigAuditUtil.java#L91-L99

I have a few points

Can the memory cache expiration time be adjusted to be shorter, say 5 minutes? Because the following logic is not too complicated and will not cause any major load problems, right?
move instanceConfig.setReleaseDeliveryTime(auditModel.getOfferTime()); to the following would it be better

Can the memory cache expiration time be adjusted to be shorter, say 5 minutes?

I think we can make this expiration time a configurable item. The original idea is to reduce the database write burden considering there are tens of thousands of instances.

move instanceConfig.setReleaseDeliveryTime(auditModel.getOfferTime()); to the following would it be better

I believe it's not correct to move this line down, as the release delivery time means the time when this instance first retrieves the config, not the last retrieve time.

I think we can make this expiration time a configurable item. The original idea is to reduce the database write burden considering there are tens of thousands of instances.

yes i think so too

I believe it's not correct to move this line down, as the release delivery time means the time when this instance first retrieves the config, not the last retrieve time.

So, back to my question at the beginning. Is it incorrect to use releaseDeliveryTime for configuration acquisition time?

I still think ReleaseDeliveryTime is better as it's the first time the instance fetches the configuration.
However, I'm interested in why you think it's incorrect. Would you please help to describe the actual scenario?

Because of the logic discussed earlier, when a configuration is not re-released. ReleaseDeliveryTime is not updated no matter how many times the configuration has been fetched and when it was fetched, which results in seeing unintuitive configuration fetch times on the UI.

ReleaseDeliveryTime is the time when the instance first fetches the configuration. I understand what you want to show is the last fetch time instead of the first fetch time, or show them both?
The first fetch time(ReleaseDeliveryTime) is important as it shows the user when the configuration is effective on the application side.
The last fetch time is also important as it indicates the instance's heartbeat time. However, as I mentioned before, to ease the database write burden, the last modified time will not be updated to the database each time the instance fetches the configuration. It will be updated to the database only when the instanceConfigReleaseKeyCache times out(which may take up to 24 hours). So there is no accurate last fetch time to display, which is why it's not shown in the UI.
I'm not sure how important the last fetch time is, but we need to figure out a solution to display the correct last fetch time if we do want to show it in the UI.

ReleaseDeliveryTime is the time when the instance first fetches the configuration

If so, I understand why it is currently designed this way

However, most people are still confused by the '配置获取时间', or will we have a more meaningful field description?

However, most people are still confused by the '配置获取时间', or will we have a more meaningful field description?

Yes, I'm open to a more meaningful label.

Did not think of a suitable name。Would a '配置生效时间' be more appropriate?

Would a '配置生效时间' be more appropriate?

I think this label is OK.


Revise "what is monero" page

The current "What is Monero" should go further in explaining the most important qualities that set Monero apart from other assets.
Note: the proposed revision should be mostly judged for content, not for style. It needs a further redesign. I'm not good at that part.
Notice that the proposed version very clearly focuses on Monero's advantages in a way that immediately convey that Monero is not a shitcoin. It also contains calls for actions at the bottom:
"Join Community": https://www.getmonero.org/community/hangouts/
"Get Monero": https://www.getmonero.org/community/merchants/#exchanges
"Show me the full details": https://www.getmonero.org/resources/about/
Current

Proposed

We can leave the video card at the bottom. I'm indifferent about that.
Conflicts with #1480. Related to #1483 #1485 #1486

as a possible alternative, this page could also be linked from the homepage only (e.g. the "Learn why it's the standard"), and keep the current What is Monero page (possibly with certain revisions that can be addressed separately)?

The suggestions you are proposing are basically entire redesigns and some would require long discussions before being implemented. I agree with some of the changes, but implementing them would take a lot of time and resources
Beside, some of these pages were refreshed not long ago and the text changed. I wouldn't make another (more intrusive) redesign any time soon.

On the merit of this issue, i like the idea of adding engagement buttons, but beside the fact that the text of the page is being changed by #1481 (so shouldn't be changed again any time soon), i don't like the content of those bullet points. They don't really explain what Monero is (which is the point of the page) and some of the content seems to be redundant with the 'About' page (points 3 and 4).

@erciccione would you be able to provide some additional comments on your reasoning for:
"Beside, some of these pages were refreshed not long ago and the text changed. I wouldn't make another (more intrusive) redesign any time soon." and "(so shouldn't be changed again any time soon)"?
Is this due to resource constraints or some other reason? Asking because I believe that the frequency of re-design shouldn't be the sole factor that prevents a re-design from occurring, if that re-design is going to serve the needs of the project in a way that provides more benefit than it costs.

I believe that the frequency of re-design shouldn't be the sole factor that prevents a re-design from occurring

@tallest-man it's not. I'm ok with aimed redesigns if there are useful improvements suggested and it's not just a "i like this text better" kind of situation. Beside that, two important additional factors should be considered:

The new strings will need to be translated again. The text of some pages were changed not long ago. Nobody suggested improvements at the time, so the changes went in as they were. Then, translators started to work on these new strings. Some of these translators were also funded through CCS proposals. Changing strings means translators' work will be wasted. Now think that (almost) every page on this website is available in 13 languages and how many people you need to translate everything (even if for most people translations simply happen, there is a huge amount of work and coordination in the background between me and the translators. Without even considering the work necessary on Weblate itself).
The proposed changes will need to be implemented by somebody. I'm ok with applying the changes if people want them, but that would take out time from other important works that are still in progress (like converting the entire user guides and moneropedia to translate them on Weblate). Even if somebody else would take care of making the changes, reviewing them will still take considerable time.

To reiterate: I'm ok with making substantial changes, but only when really necessary. Also, the amount of resources to invest (for translators, reviewers and committers) should be considered.
In this case, personally i'm ok with adding the buttons or changing the header, even if i don't consider that a priority or something particularly useful, but i don't like the new content (as explained in my comment above) that is being proposed and i don't think it worth spending so much time and resources for it.

This is actually a duplicate of #1480. Please continue the discussion there.


Skipping or clicking new word when team points is 1 less than winning shows N/A on word

Something wrong with the point calculation and generating a new word

Can not reproduce anymroe, not sure what happened.


switch to Hoek instead of lodash

Hoek is already integral to Hapi, so it avoids loading a new library.

+1, also can you help with something later @sibartlett


includes method lets you use one query to load two associations

This isn't ready for merge yet but opening the PR to raise awareness. It needs some features, maybe some API tweaks, and a lot of cleanup. QueryProxy is doing too much, there may be another class hiding in there.
ActiveRecord has at least three different methods that let you load two associations at once: :eager_load, :preload, and :includes. Going with :includes here cause it feels the most natural.
Very easy to use, inspired by AR but a little different. students = Student.where(name: 'Lauren').includes(:lessons). It builds a Cypher MATCH and then OPTIONAL MATCH to get the lessons, then stores the results in each parent node's association cache. When you then do students.each { |lauren| lauren.lessons }, it retrieves the results from the association cache and doesn't have to do a query!
A nice bonus is that you can chain any QueryProxy methods onto includes. Student.where(age: 19).includes(:lessons).rel_where(grade: 'A+'). The downside here is that, at the moment, you would get to those results by rewriting that same query in your view: student.lessons.rel_where(grade: 'A+').
To do:

includes_with_rel
Allow passing of arguments to set node and rel identifier so you have more control over filtering
And a bigger one...

Should it put filtered results in the root association so you don't have to call the filter again when returning? When you do Student.where(age: 19).includes(:lessons).rel_where(grade: 'A+'), would you expect it to show the filtered results when you do student.lessons or would you expect to have to do student.lessons.rel_where(grade: 'A+') again? I kind of think it should be in :lessons, I already told it I wanted to filter... This would be easy enough to implement, we just need to decide if it's the most obvious way of handling it.

Also, JRuby... come on!

Coverage decreased (-0.04%) when pulling 1144794e18b9ba83e8ced64caf14d67b23eb8adc on preload into c11d95828605b2058416d71e27e505ec57e760cb on master.

So... I think I want to skip the whole filter-association-details part of this for now so we can merge. Filterable includes can be part of another method or a tweak down the road.

The big change tonight is that I removed a lot of code in the effort to make it not allow filtering of included association matches, forgetting that it would just apply the results to the OPTIONAL MATCH created to preload and then stash the results in the base association. In other words, doing this:
lessons = Lesson.all.includes(:teachers).where(age: 30)
lessons.each do |lesson|
  lesson.teachers do |teacher|
    # something here
  end
end

...will not result in an extra query to the database, the filtered match will already be accessible in each lesson's teachers association cache. This looks like a weird default but in practice, it was exactly what I expected to happen every time I was testing this feature, since I feel like includes(:teachers) implies that whatever you preload and filter will be in there.
This update also brings support to first and last.
Assuming nobody HATES this, I'd like to merge and we can play around with it. We have something going at work where we can use this immediately and I'd like to see how it feels in an app. Brian, maybe you can do the same?

Coverage decreased (-0.01%) to 98.53% when pulling fd4438e969f6eac8f80c12f2ebf1b1860cc448c5 on preload into 530d83e365546c0956c132731034245ecca63ab7 on master.

Coverage decreased (-0.01%) to 98.53% when pulling fd4438e969f6eac8f80c12f2ebf1b1860cc448c5 on preload into 530d83e365546c0956c132731034245ecca63ab7 on master.

Coverage decreased (-0.0%) to 98.54% when pulling 8405b2568f94310a46037cb5b33886efdc914388 on preload into 530d83e365546c0956c132731034245ecca63ab7 on master.

Coverage decreased (-0.0%) to 98.54% when pulling f2c18ce8701c73ca0c3d2869f4fa274ad73d99f2 on preload into 530d83e365546c0956c132731034245ecca63ab7 on master.

Coverage decreased (-0.07%) to 98.47% when pulling d4dd994c7e8e018250d05406f9c27a81964dbec8 on preload into 530d83e365546c0956c132731034245ecca63ab7 on master.

Coverage decreased (-0.07%) to 98.47% when pulling d4dd994c7e8e018250d05406f9c27a81964dbec8 on preload into 530d83e365546c0956c132731034245ecca63ab7 on master.

Coverage decreased (-0.07%) to 98.47% when pulling d4dd994c7e8e018250d05406f9c27a81964dbec8 on preload into 530d83e365546c0956c132731034245ecca63ab7 on master.

Coverage decreased (-0.07%) to 98.47% when pulling d4dd994c7e8e018250d05406f9c27a81964dbec8 on preload into 530d83e365546c0956c132731034245ecca63ab7 on master.

Coverage decreased (-0.07%) to 98.47% when pulling 09996fedfc12c8668767273c5432210c1dc8f052 on preload into 530d83e365546c0956c132731034245ecca63ab7 on master.

Coverage decreased (-0.07%) to 98.48% when pulling 18f7f22985e8799d9aacf69445582b937cbfe5ea on preload into 530d83e365546c0956c132731034245ecca63ab7 on master.

I'm closing this until I'm closer to being ready to merge.


Fixed incorrect link on access-with-azure-ad.md

The link to how to change your directory in azure AD was wrong.

Thanks @scottstout!


Unable to set a boolean @default

Describe the bug
On defining a field in the Prisma datamodel with a type of Boolean, am trying to set a default to false. reading the docs suggests that the correct syntax is Boolean @default(value: "false") noting that the boolean default value is defined as a string.
The following error is thrown when I set the default value as a string:
✖ The value "false" is not a valid default for fields of type Boolean.

When I set the default value as false - omitting the quotes, prisma deploys successfully but does not set the value correctly to false for each row in the DB.
To Reproduce
Steps to reproduce the behavior:

Add a field on a type in Prisma datamodel.prisma
Set the type as either Boolean @default(value: "false") or Boolean @default(value: false).
Deploy prisma instance
Observe

Expected behavior
Should set the value for all rows for the newly added field to false
Versions (please complete the following information):

Connector: Postgres
Prisma Server: 1.32.2
prisma CLI: prisma/1.34.0 (darwin-x64) node-v10.4.1
OS: MacOS Mojave

Update: Noticed that to ensure the field is set to the default value, you have to make it required?


Why create new Hasher per invocation

I am reading your code and for every public method invocation of HasherImpl you create a new HasherImpl which I have no clue why. Do you mind explaining?

I don't have any relationship to this project except for using. Looking at source to the impl it stores very sensitive data within the object.
So given the nature of what is contained within the object creating a new object for each invocation the usage of the previous object can be discarded via GC much more quickly leaving less footprint/room for successful attack vector.

Exactly the opposite actually, when you create a new object matching the current one with new values and discard the current one it will wait for GC to delete the current one leaving now 2 instances of the sensitive data which grows every new instance.

No matter, you have to wait for GC to discard objects unless you manually call GC (just the nature of the jvm). If you keep a reference to the HasherImpl it will never be discarded and possibly previous references may also never be discarded unless all previous references are set null.
Outside of that fact making a single reference to the impl would also make it not thread safe if the internal state is changing from external references (which is the only way you could update those internal values if there was only one reference)
The current impl is the most secure and is also thread safe.

Hi all. First of all thanks for the comments and the interest.
HasherImpl and VerifierImpl hold references to sensitive data (e.g. the reference to byte[] password) and do not copy its content. Client code (i.e. your application) is responsible for clearing the byte[] when hashing/verification is completed.
Jargon2 even provides a convenience abstraction in the form of the ByteArray API to help client code deal with conversions from char[] to byte[] or from a String to byte[] etc, and having headaches with keeping track of sensitive data copies. It goes one step further by allowing you to have the source array cleared when ByteArray lifecycle ends.
In this snippet from the documentation:
char[] password = somehowGetPassword();
try (ByteArray passwordByteArray = toByteArray(password).clearSource()) {
    // use passwordByteArray with Hasher or Verifier
}
// Internal byte[] copy AND the source char[] (password variable) are zeroed-out here

any leftover HasherImpl and VerifierImpl objects that were created inside the try block simply point to empty arrays.
I remember it was one of my design goals to handle sensitive data responsibly and I was being extra careful in not making copies or wiping them internally after use. The only place I could not achieve this is with normalization where I could not find a library that does the same. This was clearly documented and normalization is optional, anyway.
So, with correct use, all these intermediate HasherImpl and VerifierImpl which you loose reference to (but are still in the heap until GC) point to byte[]s that are already wiped out.
Of course, bugs are possible and if you believe that the above is not always the case, write a client code snippet that you believe leaves unwiped sensitive data in the heap. I'll examine it as soon as possible.

For the initial question "Why create new Hasher per invocation?":
I wanted to design and idiomatic fluent API that is simple and flat. It must be used in a certain way, though. Creating a new HasherImpl object on every API call is a result of this decision.
You can also check my long answer to https://github.com/kosprov/jargon2-api/issues/2
In any case, creating a new HasherImpl object and copying references is extremely cheap and to put into some perspective: You're about to allocate a huge amount of RAM to do CPU intensive calculations. The cost of 2 or 3 additional objects is negligible in terms of both RAM and CPU.

@k3mist I am well aware of how the Garbage Collector works, also no it doesn't after a hash it does not set the password to null (tho I think you mean if they don't create a variable for it, it would discard it when the object is discarded).  Also thread-safety can probably be better achieved with synchronized.
@kosprov Thank you for your detailed answer and for making such a well made project, sadly I still don't understand why you need it instead of using return this; but until you change it I'll continue and use: this code I made to use the backend instead of the hasher which sadly requires me to also add a dependency to the jargon2-api for Type and Version.
This also has the advantage that a new Jargon2Backend isn't created every hash.

If you make proper use of the API and you write a component like the PasswordHasher CDI bean described in the README file, when you call its public methods PasswordHasher#encodedHash(char[]) or PasswordHasher#verifyEncoded(String, char[]) the password char[] is wiped out. The char[] will be automatically filled with zeroes before those methods end and there will be no sign of the user password any more. Period.
PasswordHasher#encodedHash(char[]) creates 1 HasherImpl copy and PasswordHasher#verifyEncoded(String, char[]) creates 2 VerifierImpl copies. That's less than 1KB of garbage. Argon2 will allocate 5 or 6 orders of magnitude more RAM than this "unecessary" 1KB.

... sadly I still don't understand why you need it instead of using return this;

If you want to understand why a new copy of the HasherImpl or VerifierImpl must be created, read my analysis on https://github.com/kosprov/jargon2-api/issues/2. Just trust me that return this is gonna give wrong results.

but until you change it I'll continue and use...

Instead of using NativeRiJargon2Backend directly, I suggest you use the low-level API. You still get the benefit of a decoupled backend.

This also has the advantage that a new Jargon2Backend isn't created every hash.

There is always 1 and only 1 instance of an automatically discovered backend. No new backend instances are created when HasherImpl or VerifierImpl copies are created.


Complete UI for Leaderboards

This issue tracks the UI we have for showing leaderboards.
Definition of done

[ ] Leaderboards are shown per submission rather than per version (as they are now)
[ ] Clicking a link in the leaderboard takes you to the submission page for that submission
[ ] The latest scores are displayed for each submission
[ ] Pagination of the leaderboard works as you would expect

Going to remove "pagination" as a feature, and just put everything on one page but sorted correctly.

DoD completed, marking as closed.


[Feature Request] Create ics file for upcoming events.

Overview
Fetch all the upcoming events in the discord server and send an ics file of it.
Details
We could base the code on what Cubie developed for Pandora: https://github.com/Cubie87/Pandora/blob/master/src/ical.py
Why would this feature be useful?
So that people can easily add upcoming CS Club events to their calendar.
Additional Notes
No response

I am willing to do this!


Custom Derive generated ops are too restrictive

Currently, the code generated by the custom_derive! statements will result in Prime types being returned. This doesn't make sense for the most part, i.e a prime + 1 is not guaranteed to be prime.
Expected behaviour would be returning ramp Int values instead.
Doesn't seem like custom_derive supports specifying output types which makes this a little bit harder to do.

I came to this realization recently when working on a separate project that uses pumpkin: that it makes more sense to work with Ints rather than Primes. I'm actually in the process now of refactoring the code to return Ints (and alter the API just a bit). I should be pushing up some changes soon!

b6134a6


StockManager.allocate_stock - adds twice the quantity it is supposed to

When an order is placed, the stock manager allocates twice the quantity it is supposed to.
The problem seems to be with  the F() expression.
stock.quantity_allocated = F('quantity_allocated') + quantity
If I replace that line with
 stock.quantity_allocated += quantity
then my problem is fixed. (Though I imagine performance is worse)
I tested the issue from Django Shell and could replicate the error by doing:
from saleor.product.models import Stock
s = Stock.objects.get(pk=94)
s.quantity_allocated
Stock.objects.allocate_stock(s, 1)
If you reload the shell, the quantity allocated value has changed by two instead of one.
Can anyone else replicate the problem ?
Will there also be an issue with deallocate stock ?

I've added a test in code that verifies that stock is allocated correctly. Can you provide steps to reproduce?

Thanks, my installation passes all the tests.
However when I test the stock allocation manually from shell, it still increase by double the amount it should.
I am using PostgresSQL as my database.
Is it possible that the problems are related to DB engine used?

Sorry, I misread the test results.
Running the tests with an sqlite test DB I get the following:
assert stock.quantity_allocated == 1
E       assert 2 == 1
E        +  where 2 = <Stock:  - Warehouse 2>.quantity_allocated
It seems I'm getting the same problems in production with PostgresSQL and in tests with SQLite.

The quantity allocated is set to an expression on the stock record. Are you sure you don't accidentally save the record twice? Due to how Django ORM works each save would increase the number further.


[Monitoring V1 UI] Prevent deploy when Prometheus Operator already exists

This is the equivalent of https://github.com/rancher/dashboard/issues/1167 that needs to be backported to Monitoring V1's UI experience as well. Users should be warned or prevented when deploying Monitoring V1 onto a cluster where a Prometheus Operator is deployed.
For more context, see the original ticket.

The enhancement is validated on mater-head ec04f78 with the latest UI
Instead of preventing users from installing monitoring v1 when v2 is installed, Rancher shows a warning message on the cluster monitoring page
when the namespace cattle-monitoring-system does not exist in the cluster

when the namespace cattle-monitoring-system is created  in the cluster

This issue is reopened because of the following 2 reasons:

the link of the deprecated word is broken (404 error): https://rancher.com/docs/rancher/v2.x/en/reference/deprecation

The warning in the project monitoring does not change when the namespace cattle-monitoring-system exists in the cluster. Can we make it behave the same as the cluster monitoring page?

@jiaqiluo Im adding the warning to the project page now. The link tot he docs is not published yet and will not go live until 2.5 drops so it is going to 404 until then. I dont think that should block the ticket.

the bug fix is validated in rancher:master-head 2ae933e
Now the warning in the project monitoring page changes depends if the namespace cattle-monitoring-system exists or not


updates

Ran Plan for dir: infra workspace: default
Show Output

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
+ create

Terraform will perform the following actions:

  # module.bucket.aws_s3_bucket.this will be created
+ resource "aws_s3_bucket" "this" {
      + acceleration_status         = (known after apply)
      + acl                         = (known after apply)
      + arn                         = (known after apply)
      + bucket                      = (known after apply)
      + bucket_domain_name          = (known after apply)
      + bucket_regional_domain_name = (known after apply)
      + force_destroy               = false
      + hosted_zone_id              = (known after apply)
      + id                          = (known after apply)
      + object_lock_enabled         = false
      + policy                      = (known after apply)
      + region                      = (known after apply)
      + request_payer               = (known after apply)
      + tags_all                    = (known after apply)
      + website_domain              = (known after apply)
      + website_endpoint            = (known after apply)

      + cors_rule {
          + allowed_headers = (known after apply)
          + allowed_methods = (known after apply)
          + allowed_origins = (known after apply)
          + expose_headers  = (known after apply)
          + max_age_seconds = (known after apply)
        }

      + grant {
          + id          = (known after apply)
          + permissions = (known after apply)
          + type        = (known after apply)
          + uri         = (known after apply)
        }

      + lifecycle_rule {
          + abort_incomplete_multipart_upload_days = (known after apply)
          + enabled                                = (known after apply)
          + id                                     = (known after apply)
          + prefix                                 = (known after apply)
          + tags                                   = (known after apply)

          + expiration {
              + date                         = (known after apply)
              + days                         = (known after apply)
              + expired_object_delete_marker = (known after apply)
            }

          + noncurrent_version_expiration {
              + days = (known after apply)
            }

          + noncurrent_version_transition {
              + days          = (known after apply)
              + storage_class = (known after apply)
            }

          + transition {
              + date          = (known after apply)
              + days          = (known after apply)
              + storage_class = (known after apply)
            }
        }

      + logging {
          + target_bucket = (known after apply)
          + target_prefix = (known after apply)
        }

      + object_lock_configuration {
          + object_lock_enabled = (known after apply)

          + rule {
              + default_retention {
                  + days  = (known after apply)
                  + mode  = (known after apply)
                  + years = (known after apply)
                }
            }
        }

      + replication_configuration {
          + role = (known after apply)

          + rules {
              + delete_marker_replication_status = (known after apply)
              + id                               = (known after apply)
              + prefix                           = (known after apply)
              + priority                         = (known after apply)
              + status                           = (known after apply)

              + destination {
                  + account_id         = (known after apply)
                  + bucket             = (known after apply)
                  + replica_kms_key_id = (known after apply)
                  + storage_class      = (known after apply)

                  + access_control_translation {
                      + owner = (known after apply)
                    }

                  + metrics {
                      + minutes = (known after apply)
                      + status  = (known after apply)
                    }

                  + replication_time {
                      + minutes = (known after apply)
                      + status  = (known after apply)
                    }
                }

              + filter {
                  + prefix = (known after apply)
                  + tags   = (known after apply)
                }

              + source_selection_criteria {
                  + sse_kms_encrypted_objects {
                      + enabled = (known after apply)
                    }
                }
            }
        }

      + server_side_encryption_configuration {
          + rule {
              + bucket_key_enabled = (known after apply)

              + apply_server_side_encryption_by_default {
                  + kms_master_key_id = (known after apply)
                  + sse_algorithm     = (known after apply)
                }
            }
        }

      + versioning {
          + enabled    = (known after apply)
          + mfa_delete = (known after apply)
        }

      + website {
          + error_document           = (known after apply)
          + index_document           = (known after apply)
          + redirect_all_requests_to = (known after apply)
          + routing_rules            = (known after apply)
        }
    }

  # module.bucket.aws_s3_bucket_public_access_block.this will be created
+ resource "aws_s3_bucket_public_access_block" "this" {
      + block_public_acls       = true
      + block_public_policy     = true
      + bucket                  = (known after apply)
      + id                      = (known after apply)
      + ignore_public_acls      = true
      + restrict_public_buckets = true
    }

  # module.bucket.aws_s3_bucket_server_side_encryption_configuration.this[0] will be created
+ resource "aws_s3_bucket_server_side_encryption_configuration" "this" {
      + bucket = (known after apply)
      + id     = (known after apply)

      + rule {
          + bucket_key_enabled = true

          + apply_server_side_encryption_by_default {
              + sse_algorithm = "aws:kms"
            }
        }
    }

  # module.bucket.aws_s3_bucket_versioning.this will be created
+ resource "aws_s3_bucket_versioning" "this" {
      + bucket = (known after apply)
      + id     = (known after apply)

      + versioning_configuration {
          + mfa_delete = (known after apply)
          + status     = "Enabled"
        }
    }

Plan: 4 to add, 0 to change, 0 to destroy.
╷
│ Warning: Experimental feature "module_variable_optional_attrs" is active
│
│   on .terraform/modules/bucket/modules/aws-s3-bucket/versions.tf line 17, in terraform:
│   17:     module_variable_optional_attrs
│
│ Experimental features are subject to breaking changes in future minor or
│ patch releases, based on feedback.
│
│ If you have feedback on the design of this feature, please open a GitHub
│ issue to discuss it.
╵

:arrow_forward: To apply this plan, comment:

atlantis apply -d infra

:put_litter_in_its_place: To delete this plan click here
:repeat: To plan this project again, comment:

atlantis plan -d infra

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

:fast_forward: To apply all unapplied plans from this pull request, comment:

atlantis apply

:put_litter_in_its_place: To delete all plans and locks for the PR, comment:

atlantis unlock

atlantis apply

Ran Apply for dir: infra workspace: default
Show Output
module.bucket.aws_s3_bucket.this: Creating...
module.bucket.aws_s3_bucket.this: Creation complete after 3s [id=terraform-20220914185256265900000001]
module.bucket.aws_s3_bucket_public_access_block.this: Creating...
module.bucket.aws_s3_bucket_versioning.this: Creating...
module.bucket.aws_s3_bucket_server_side_encryption_configuration.this[0]: Creating...
module.bucket.aws_s3_bucket_public_access_block.this: Creation complete after 0s [id=terraform-20220914185256265900000001]
module.bucket.aws_s3_bucket_server_side_encryption_configuration.this[0]: Creation complete after 1s [id=terraform-20220914185256265900000001]
module.bucket.aws_s3_bucket_versioning.this: Creation complete after 2s [id=terraform-20220914185256265900000001]
╷
│ Warning: Experimental feature "module_variable_optional_attrs" is active
│
│   on .terraform/modules/bucket/modules/aws-s3-bucket/versions.tf line 17, in terraform:
│   17:     module_variable_optional_attrs
│
│ Experimental features are subject to breaking changes in future minor or
│ patch releases, based on feedback.
│
│ If you have feedback on the design of this feature, please open a GitHub
│ issue to discuss it.
╵

Apply complete! Resources: 4 added, 0 changed, 0 destroyed.

Locks and plans deleted for the projects and workspaces modified in this pull request:

dir: infra workspace: default


owners including users not specified in options is surprising (and feature request to be able to change behavior)

The docs on owners i can find are
https://kangalioo.github.io/poise/master/poise/attr.command.html
owners_only: Restricts command callers to the list of owners specified in framework options
https://kangalioo.github.io/poise/master/poise/struct.FrameworkOptions.html#structfield.owners
User IDs which are allowed to use owners_only commands
I think in both of these places it would probably be good to mention it adds the user that created the bot if it's not in owners already.
It would also be nice to have the option to disable that functionality.
https://kangalioo.github.io/poise/master/src/poise/framework/builder.rs.html#164

That's fair, sorry for the trouble.
Fixed in 271877e1ff5ef9f5d0369e4f2786a9744069f763. You can now do .initialize_owners(false) in the framework builder to disable this behavior


Helicone Support

Hello! Can we add support for Helicone to Chatbot UI?
I can help cut the PR, it should be really simple. You just need to add the ability to enable Helicone and store the Helicone API key.
We have a few customers of Helicone asking for this, it should be a simple lift.
I assume we can attach a new element to the profile object like proxyProvider or something and then configure it within the settings panel.

You need to do something like this PR: https://github.com/mckaywrigley/chatbot-ui/pull/1510
Can you create a pull request?

Hi @fkesheh actually all we need to do is set the OPEN_API_BASE. Do you know if I can do this easily somewhere?

You will need to change these api/chat files like these one and attach a new base API for it
https://github.com/mckaywrigley/chatbot-ui/blob/main/app/api/chat/openai/route.ts

Perhaps you can also try to set OPENAI_BASE_URL in .env.local - I believe OpenAI library picks that automatically
https://github.com/openai/openai-node/blob/70d2bb37fae06e685f73a98db3eca6e540c8ed01/src/index.ts#L31


Partition assignment and offset semantic

Description
I am trying to understand how to structure my program in regard to offsets management.

First thing to notice is that current implementation of confluent kafka client is using librdkafka function rd_kafka_consume0, which save offset first and then return message to the consumer:
https://github.com/edenhill/librdkafka/blob/72b4e4169d7e1e2229595083bf31149fa01277cb/src/rdkafka.c#L2053
As result, offset is saved before processing is complete, which means that message loss is possible.
Is it correct conclusion that "enable.auto.commit" can cause lost messages?

 If I turn "enable.auto.commit" off, and will call StoreOffsets from async handler and will call Commit() from a timer, then I would replicate autocommit in my async handler and will achieve "at least once" guarantee?

My question though is, are StoreOffset and Commit() thread safe? There is no notion about tread safety of those functions in documentation.

I am having hard times understanding concept of Consumer.OnPartitionsAssigned. Documentation says "You should typically call the Consumer.Assign", but why? In English this API reads as "Upon partition asiignment you need to assign partitions" which is nonsense. If partitions have been assigned, why do I have to assign them? My only possible explanation is that OnPartitionsAssigned is in fact "OnOffsetDiscovered" and driver would not assign discovered partitions automatically.

Bottom line is, i do not understand what is going on, nor reasoning behind this API.
Checklist
Please provide the following information:

[x] Confluent.Kafka nuget version: 0.11.4

i totally agree this is quite confusing and needs much better documentation.

that is apparently the case
yes - you can turn enable.auto.commit off, use StoreOffsets after you've handled a message and use Commit from a timer to achieve at least once guarantees.
2b. yes - those operations are thread safe.
I don't like these names either and i've been thinking of changing them in v1.0. you are right - there's the notion of being assigned a set of partitions in the consumer group, and assigning to a set of partitions to actually read from. the same terminology is used for both. usually they will be the same, but this is not enforced/required. The semantics are also confusing here - but I think they are necessary in order to provide complete flexibility (i'm all ears for better ideas though).

it does in fact sound like you're got it pretty well figured out :-)

To add to what Matt said:
You can use StoreOffsets in conjunction with enable.auto.commit=true where you set enable.auto.offset.store=false which disables the offset store you pointed out in the librdkafka source (before passing message to app), allowing you to decide yourself when the message offset should be stored (locally in memory) for future commit (auto or manual). This way your last manually stored offset for each partition will be automatically committed by the consumer using the existing auto.commit.interval.ms timer.
OnPartitionsAssigned is triggered on group rebalance when your consumer has received a new partition assignment from the group leader, but prior to the consumer fetching committed offsets for those partitions - this allows the application to perform its own offset selection or storage logic. If you're happy to use the default behaviour of using the committed offsets you don't need to set an OnPartitionsAssigned delegete. But if you do you must call Assign() to let the consumer know you've handled the assignment, allowing you to set a manual starting offset for each partition.

Is enable.auto.commit=true and enable.auto.offset.store=false really working for asynchronous processing when Consumer.StoreOffset(Message<TKey, TValue> message) can be called out-of-order? Is there a magic in auto commit that knows what is the maximum offset that can be committed? That is, largest offset from the last one committed without any gaps.

The last offset to be stored will be the one that is committed - Kafka has no in-built mechanism for handling per-message acks.

That was my concern. In such case, the last offset to be stored has to be the largest contiguous processed offset and it is up to the application to ensure this if there is no magic in confluent-kafka-dotnet library,right? I don't see an easy way to handle this when processing messages async short of inefficient approach of processing N messages at time and waiting for all of them to successfully complete.
If I want to have a pool of workers that can continuously process messages then this becomes a daunting task when I look at Kafka spout implementation codebase.
Say application is processing 10 messages async and the auto commit interval kicks with messages with the following offsets processed in the following order: 9,8,7,4,5,6,1,2 and 3,10 have not completed yet. Ideally offset 2 should be committed but then there are a lot of other considerations with handling 3 and 10 and processing new messages.

yes, you'd need some sort of ordered list/map thing to keep track of each message individually.
in some scenarios, it may work to increase the number of partitions (and have one consumer per partition).
this is one thing traditional messaging systems give you that Kafka doesn't. but traditional messaging systems are also much slower of course.

Maybe set it up so as to process messages in batches allow a new batch to start up before a previous one has completed. Doing the commit offset bookkeeping on the scale of a batch would make it more efficient (i've not done this at all, just thinking out loud).

Asynchronous does not necessary mean out of order.

Asynchronous does not necessary mean out of order.

I meant completion order of processing offsets in asynchronous processing


"Păltiniș", "Cuzlău", "Horodiștea" and "Slobozia" are listed in the drop-down menu

Description:
"Păltiniș", "Cuzlău", "Horodiștea" and "Slobozia" are listed in the drop-down menu alongside its corresponding county and commune, according to the law
Precondition:
The website is up an running.

Step 2
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 3
Type "Cuzlău" in the search bar.

Expected results
The location is listed in the drop-down menu as "Cuzlău, Botoșani (Păltiniș)".

Step 4
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 5
Type "Horodiștea" in the search bar.

Expected results
The location is listed in the drop-down menu as "Horodiștea, Botoșani (Păltiniș)".

Step 6
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 7
Type "Slobozia" in the search bar.

Expected results
The location is listed in the drop-down menu as "Slobozia, Botoșani (Păltiniș)".


Update tapir-core, tapir-json-zio, ... to 1.10.13

About this PR
📦 Updates

com.softwaremill.sttp.tapir:tapir-core
com.softwaremill.sttp.tapir:tapir-json-zio
com.softwaremill.sttp.tapir:tapir-netty-server

from 1.10.8 to 1.10.13
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.softwaremill.sttp.tapir" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "com.softwaremill.sttp.tapir" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, version-scheme:early-semver, commit-count:1

Superseded by #553.

Superseded by #556.


Question: How do I manually Ack a message in dotnet core?

User Case: an EF error/timeout occurs while executing my function. Any other error occurs, I do not want to loose the message. Therefore I want to only manually Ack messages that have been successfully processed.

Needs some design exploration. Probably needs an approach similar to service bus where customers can specify messageHandlingOptions like below
{
  "version": "2.0",
  "extensions": {
    "rabbitMq": {
      "messageHandlerOptions": {
        "autoComplete": false
      }
    }
  }
}

This seems like a "must have" feature.
Queue handling without the possibility of abandoned messages with re-sends, doesn't really seem like queue handling. More sort of like "spray and pray" IMHO.

did this ever get worked on?


Warning: Unexpected input(s) 'id', valid inputs are ['version', 'token']

How to get rid of this warning:

We followed this example:

The id is not part of with. It should look like this:
- uses: azure/setup-helm@v1
  id: install
  with:
    version: 3.6.3
    token: ***

instead of this:
- uses: azure/setup-helm@v1
  with:
    version: 3.6.3
    id: install
    token: ***

I tend to put the id field right after uses or name because i think it improves readability.