[BUG] QuickSetup production script throws an error (sh: ts-node: not found)

OS: Windows 11 x64
node: 17.3.0
npm: 8.3.0
Steps to produce error:

open git-bash
run sh setup.sh

after above commands script throws an error on console: sh: ts-node: not found

It seems like ts-node is missing which means that npm dev dependencies are missing.
https://github.com/joeygoksu/prime-nestjs/blob/3b9bb3244c78b2e26d81e264beceaf2965998294/setup.sh#L38
Temporary solution:

Go into the docker container
Run npm install or yarn command inside of the container
Run the migration script

For the future:
The new version will be released in 1-2 days. (includes new bash script) Thanks for letting us know.

It seems like ts-node is missing which means that npm dev dependencies are missing.
https://github.com/joeygoksu/prime-nestjs/blob/3b9bb3244c78b2e26d81e264beceaf2965998294/setup.sh#L38
Temporary solution:

Go into the docker container
Run npm install or yarn command inside of the container
Run the migration script

For the future:
The new version will be released in 1-2 days. (includes new bash script) Thanks for letting us know.

Any update on new release 😇

It's been a busy month but I will have a chance to update a couple of things next few days.

@joeygoksu Love your repo, hope it receives better support and care! You're awesome.

Still have this error

I know it's been ages, but I just fixed the error with https://github.com/josephgoksu/prime-nestjs/commit/526dc5a45e6805dd84738e55d14f34909290a042 :)


Custom widget for flow JSON

Description
On our blog we often have a Flow for copying in raw JSON. Usually accompanied by a screenshot of that flow. It would be great if we have a nice UX around the combination.
Maybe the first iteration is displaying the screenshot with an obvious copy button for readers to copy the JSON to the clipboard?
/cc @joepavitt
Epic/Story
No response
Have you provided an initial effort estimate for this issue?
I can not provide an initial effort estimate

Closed by https://github.com/node-red/flow-library/pull/100


Tag requirements at known working versions

This is a change that is long overdue, and was proposed months ago by @ooblioob in #45 as an attempt to tag versions at a known working state (rather than picking whatever the latest version is).
I'm giving this another go, with a few differences from #45:

The requirements.txt actually had a few updates since #45 was introduced, this PR accounts for those so there are no merge conflicts
The requirements-test.txt is also updated
A few versions are bumped forward because the versions specified are no longer available via PYPI

The specific driver for this PR is that Travis builds are currently failing for #50 because some items in requirements-test.py require Django >= 1.6 (travis link).  This PR should not be merged until Travis tests are passing.

Reviewed with @sleitner, no known issues in our testing.


Assignment_2_submission

What changes are you trying to make? (e.g. Adding or removing code, refactoring existing code, adding reports)
Adding code to read and display data from first file, perform data summarization and detect errors in patient data
What did you learn from the changes you have made?
Adding code to read and display data from first file, perform mean/max/min data summarization and the check zeros function
Was there another approach you were thinking about making? If so, what approach(es) were you thinking of?
No
Were there any challenges? If so, what issue(s) did you face? How did you overcome it?
It took me a while to work out that the all_paths code at the very top was a markdown rather than python and had to be copied and pasted.
How were these changes tested?
Executed code after each new section completed.
A reference to a related issue in your repository (if applicable)
Checklist

[X] I can confirm that my changes are working as intended

Accidently tried to merge into the DSI main repository.


[Feature Request] Response control on API calls

[Issue Description]
Filtering transaction based on contract address and the method name does not return the call parameters of each of the returned transaction. We are trying to get all the parameters used to call the method.
It makes sense to trim out less important data points like call parameters. But having to loop through each transaction and calling the transaction details API for each of the transaction hash individually is not efficient.
[Feature Description]
Would it be possible for end users to have some control over what is returned in the response?
Just for example:

Adding a new parameter ?include=call_param adds call parameters to the response list.
Adding a new paramter ?include=response_data adds response data to the response list
Adding a new paramter ?include=call_param,response_data adds response data and call parameters to the response list

Included the data field to the api list response, feature should be available soon and will be on by default (no extra parameters needed)


Tagui visual automation issue on Remote Desktop server

Hi,
Here what I observed:
Locally using windows 10 -->using 100 % magnification -- my script working fine as intended
RDP to Remote server via RDP --> to a machine with Windows Server 2019 (I have 100 % magnification at local machine , so that when RDP it the target VM also use same magnification)
setup all python tagui there, ran same program with visual automation, its not moving cursor to inteded places..clicking at wrong places...
Locally same program works fine.
so is there any limitation of tagui python with version of windows  ? or on RDP it wont work properly
please suggest..

Closing this issue as this sounds like is for TagUI for Python and not this TagUI project, and I saw your duplicated issue over there - https://github.com/tebelorg/TagUI-Python/issues/70


Unable to add webos-tv to existing config file

Hi,
i have an existin homebridge config file wiht only my Denon reciever in it which works fine and i have been experimenting with trying to get my lg c7 webos tv to work as well
i have gotten my config file to be a valid json in jsonlit validator but when i replace my config filw contents with it and restart homebridge in terminal on my Mac i get a bunch of red errors i do not understand at all
i had previously installed the webos-tv plugin and webos 3 but never used them, not sure if this is causing an issue
mobile tv is on for wifi waking
below is my config file which is valid and also a screen shot of the errors
could you please help me to get this woking as id greatly appreciate it
{
"bridge": {
"name": "Homebridge",
"username": "CC:22:3D:E3:CE:51",
"port": 51826,
"pin": "031-45-154"
},
"description": "This is an example configuration file for homebridge denon plugin",
"hint": "Always paste into jsonlint.com validation page before starting your homebridge, saves a lot of frustration",
"accessories": [{
"accessory": "marantz-volume",
"name": "Stereo Volume",
"host": "<IP_ADDRESS>:8080"
},
{
"accessories": [{
"accessory": "webostv",
"name": "LG C7 TV",
"ip": "<IP_ADDRESS>",
"mac": "7C:1C:4E:E1:E3:AO",
"keyFile": "/homebridge/plugin-webos-tv/KeyFile",
"pollingInterval": 10,
"inputs": [{
"appId": "com.webos.app.hdmi1",
"name": "HDMI 1"
},
{
"appId": "com.webos.app.hdmi2",
"name": "HDMI 2"
},
{
"appId": "com.webos.app.hdmi3",
"name": "HDMI 3"
},
{
"appId": "youtube.leanback.v4",
"name": "YouTube"
}
],
"showInputButtons": true,
"volumeControl": "buttons",
"channelControl": false,
"mediaControl": false,
"channelButtons": [2, 3, 5, 7, 8],
"notificationButtons": [
"Motion detected - living room",
"Motion detected - kitchen"
],
"remoteControlButtons": [
"HOME",
"LIST",
"EXIT"
],
"soundOutputButtons": [
"tv_speaker",
"external_optical",
"headphone"
],
"remoteSequenceButtons": [{
"sequence": ["HOME", "RIGHT", "RIGHT", "RIGHT", "ENTER"],
"name": "screen_share_seq"
},
{
"sequence": ["VOLUMEUP", "VOLUMEDOWN", "MUTE", "MUTE"],
"name": "volume_seq",
"interval": 1000
}
]
}]
}
]
}

I guess that there should be only one accessories list but you have multiply so i am guessing this is your issue. Besides that i am pretty sure that it has nothing to do with this plugin...


Region cropping problem

This branch is ready to merge with master branch. Please test first and then merge.

Regarding the CI failures, I believe you should try to update/renew your CircleCI build cache. Also adding some pip install -U pip would be advisable:
You are using pip version 9.0.1, however version 19.3.1 is available.

Is it save to merge a PR for which the continuous integration tests failed? Is it save for users to update their working installation?

problem was related to circleci not finding tensorflow 2.0
should be fixed


update prep_* and plot_* functions called from r2dii.plot

see https://github.com/RMI-PACTA/r2dii.plot/pull/543
r2dii.plot has had a breaking change, whereby prep_*() functions have been extracted from plot_*() functions, necessitating corresponding updates where the plots are being generated.
The new structure needs to be implemented in generate_individual_outputs(), which calls all plot_*() functions.

this was addressed in #66


Works for Hiccup Data?

Your online masterpiece (http://pretty-print.net/#/format/edn) seems to have done an excellent job of pretty-printing my Hiccup data; i just wanted to confirm with you that you intended it for that kind of use...?
I would also be interested in the data size limit (the biggest i've submitted is 36,479 characters).

Issue #1 :)

We don't enforce a size limit as we just haven't found a use case for enforcing one yet.  Let us know if you have any other questions or concerns.

Thanks!


Enable the invoke_model_with_response_stream API

This API is a streaming API—I tested it manually, an E2E test an example are forthcoming. I also removed the unused config service from the smoketest and added bedrock-runtime.
Motivation and Context
This API is suppressed by default because it's an event stream API
Description
Testing
https://gist.github.com/rcoh/ce61429303a56fefd65ba05bd36d28fc works

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

I also removed the unused config service from the smoketest and added bedrock-runtime.

It's not unused. In fact, it's testing codegen for awsJson1_1: https://github.com/awslabs/smithy-rs/blob/main/aws/sdk/aws-models/README.md


'terminus site create' could return the resulting UUID and site name

In terminus 1.0, psite-create returned the UUID and site name.  This was really useful in multistep scripts when I wanted to perform further operations on the site I'd just spun up (e.g. add team members).  I could do this without making another call to psite-info
// We want the output that comes via STDERR
  $psite_create_cmd = "$drush -y psite-create $cloned_site_name --product=$product_uuid --organization=$organization_uuid --nopoll 2>&1";
  print $psite_create_cmd . "\n";
  exec($psite_create_cmd, $output, $return);
  if ($return !== 0) {
    print "Error: Problem creating target site. Check the following before trying again:\n";
    print "Do you need to use -T? See help (-h)\n";
    print "Have you logged into Terminus?\n";
    print "Does the new site (e.g., sitename-ob) you're trying to create already exist on Pantheon?\n";
    exit(1);
  }

  $target_site_uuid = "";
  foreach ($output as $out) {
    // When we redirect 2>&1 we get separate lines
    // print "output: $out\n";
    // output: Your new site "websolutions-bw15" is now building with UUID
    // output: "a158abab-7614-4b4f-9c7d-0940b21d049b".
    preg_match('/^Your new site "([^\"]+)"/', $out, $matches1);
    preg_match('/^"([a-z0-9-]+)"/', $out, $matches2);
    if (count($matches1) > 1) {
      $target_site_name = $matches1[1];
      print "\nTarget Site name: $target_site_name\n";
      continue;
    }
    if (count($matches2) > 1) {
      $target_site_uuid = $matches2[1];
      print "Target Site UUID: $target_site_uuid\n";
      continue;
    }
  }

We could improve on psite-create in these ways:

Return the data on STDOUT, not STDERR
Support --json to avoid the need for pregs
If returning this data should be optional, a --output switch could be added.

I think that is doable ... I wasn't aware that it was returning on STDERR.
Most commands in the new terminus support --json but I don't think the create command does so I can change that.
Not sure this is necessary. Bash users wanting to silence output can always redirect to /dev/null right?

I think that is doable ... I wasn't aware that it was returning on STDERR.

The old psite-create code was returning this data on STDERR.  I haven't seen inappropriate things returned on STDERR in 2.0 so far.

Not sure this is necessary. Bash users wanting to silence output can always redirect to /dev/null right?

Yeah. For sure.


Update UIMatch type to cover cases where loaderData is undefined

when using a UIMatch loaderData may be undefined in the scenario that the loader failed, so this makes the types a bit more safe making sure that consumers of the UIMatch type check for undefined

Closes: #

[ ] Docs
[ ] Tests

Testing Strategy:

Is this specifically for ErrorBoundary use-cases?

@brophdawg11 yep

I chatted with @mjackson on this and we agreed we don't want this to always have undefined on the types since that is incorrect the vast majority of the time - as data is always populated in components.
Additionally, match.data is unknown out of the box and only gets the loaderData when you effectively cast it via the generic:
let matches = useMatches();
let match = matches[matches.length - 1] as UIMatch<typeof loader>;

So I think in reality that is where the issue arises.  If you're using useMatches inside an ErrorBoundary, you shouldn't be saying "trust me, data is the typeof the loader" since that loader could have thrown.
I think the more accurate usage in boundaries is:
let matches = useMatches();
let match = matches[matches.length - 1] as UIMatch;
let data = match.data as SerializeFrom<typeof loader> | undefined

That way you're properly casting according to the error scenario.
If any TS ninjas want to look into making as UIMatch<typeof loader | undefined> achieve that - I think we'd potentially be open to that.  But for now I think the manual cast is the right solution.


Added my name and profile link

Added my name: Jackie in the div class="welcome"

@jackie1969  thnx for contributing , try this year aswell with updated repo and make sure to follow me and star this repo so that you don't miss updates regarding the new changes and issues during Hacktoberfest 2020.


fix: PASSWORD_RECOVERY event missing

What kind of change does this PR introduce?
Bug fix
What is the current behavior?
When resetting a user's password with an email template which has a URL defining the type value of recovery and using verifyOtp in dev code to process the token_hash and type, the SSR server client's onAuthStateChange function does not recognize the PASSWORD_RECOVERY event that verifyOtp uses in this case. Therefore the new session does not get saved to storage and the user is not logged in, in order to reset their password.
What is the new behavior?
User is logged in.
Additional context
Fixes #21

I'm not sure what's going on with the check-conventional-commits check.

Yeah I'm not sure - any chance you can rebase and push a commit with feat: or fix? Not sure if the merge commit I made is messing with the check

Thanks for the PR btw :)

Yeah I'm not sure - any chance you can rebase and push a commit with feat: or fix? Not sure if the merge commit I made is messing with the check

I'm sorry to say that I'm not familiar with that process. After a search, it seems you'd typically run the rebase command when on the branch, not main: git rebase main. But it gives me a merge conflict.

@j4w8n if you could do that it would be perfect. Feel free to tag me there - will approve ASAP.

Closing. Will recreate.


Getting timeout issue while connecting to gptkb indexer

Please provide us with the following information:

This issue is for a: (mark with an x)
- [ ] bug report -> please search issues before submitting
- [ ] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

I tried to run this demo on custom data. I use the existing openai resource group while deploying the app.
Indexing has been generated for custom data and app is deployed.

Any log messages given by the failure

When I try to query from application, I am getting following issue:
Error: (<urllib3.connection.HTTPSConnection object at 0x7b3b7f655600>, 'Connection to gptkb-7rbi3klczjkre.search.windows.net timed out. (connect timeout=300)')

Expected/desired behavior

OS and Version?

Windows 11

azd version?

azd version 1.1.0

Versions

Mention any other details that might be useful

Thanks! We'll be in touch soon.

Hm, interesting. Does this happen consistently, or just once? Is it working for you now?

Hi @pamelafox , The issue has been solved. It occurs because of firewall settings at my end


Ruby not enabled in Snapshot 137

Am I correct in expecting Ruby to be enabled, or has that changed (very) recently? After upgrading to the latest snapshot - 137 - Ruby is no longer enabled. This impacts anyone who uses the pre-built images, including Homebrew users.

Well, I think I'm wrong. I believe the Homebrew pre-built image of MacVim was incorrectly built w/o Ruby support. That's what the above screen shot was from - I incorrectly assumed it was due to a change in MacVim. My mistake.

yep, using Travis CI to ensure ruby support https://github.com/macvim-dev/macvim/blob/2a33867b14fe6639ed906c61aaa6852f391e0008/.travis.yml#L44

👍 I pulled down the latest release and confirmed Ruby is enabled. It's a problem with the Homebrew pre-compiled bottle for (at least) Sierra. Thanks.

@stevenharman A similar problem occurs when trying to update to snapshot 159. Any idea how it got solved back then?

@mvcouwen Please tell how do you installed MacVim? I can't reproduce it with official builds from GitHub.

@eirnym Actually, I don’t think there is any problem with MacVim itself. It seems more likely that there is a problem with Homebrew. There seems to be a Ruby mismatch when trying to build a bottle for MacVim on Mojave. See Homebrew/homebrew-core#45455

Please, look at #947 for the issue you have


fix: column comparision issue

Overview
resolves #595
I have tested this on jaffle shop. Changed case of payments_id column of stg_payments model and it didn't clear the description as described in the issue.
Checklist

[X] I have run this code and it appears to resolve the stated issue
[ ] README.md updated and added information about my change

does save also behave properly?

It will indeed be converted to the format that comes back from the database, generating potentially more changes in the yaml.
@anandgupta42 : WDYT?

does save also behave properly?

It will indeed be converted to the format that comes back from the database, generating potentially more changes in the yaml.
@anandgupta42 : WDYT?

AFA I understand, the best practice is for the docs to reflect the state of the database. In that case, does it not make sense to let the database be the source of the truth?


Random disconnections with SITL and INAV 8

I have noticed random disconnections with SITL and INAV 8.
The OSD suddenly disappears with the message "Unsupported Firmware" or "Unsupported Aircraft type"

Ahh, my fault.
I connected to MSP Displayport instead of MSP.
You have to configure a dummy MSP displayport to get HD OSD.


PyTorch Gradient Explainer

This is a partial solution to issue #191 , which is a PyTorch version of the gradient explainer. I would appreciate any feedback.
Something to note is that because the network is not defined before runtime in PyTorch, its much harder to see the results of interim layers as happens here:
https://github.com/slundberg/shap/blob/master/notebooks/gradient_explainer/Explain an Intermediate Layer of VGG16 on ImageNet.ipynb
Doing so would probably require a network to be split into two by the user.
I've also added a notebook demonstrating the changes; the results are less convincing than the intermediate layers, so @slundberg please let me know if they still make sense to you, or are indicative of a mistake.

Also, I see why explaining a middle layer is harder. I am not a pytorch expert, but it seems like once you run a forward pass you should have a fully defined computation graph. If you trace that back to a set of intermediate inputs perhaps you could grab the gradients and forward values flowing through them (which is all we need). But again, that's something to worry about after merging.

Hi @slundberg , thank you for your feedback!
I ran the MNIST example, and things seem a lot more reasonable; I replaced the Imagenet notebook with it.
I'll definitely take a look at getting intermediate outputs and autodetecting the framework.

Great! It seems like the intermediate outputs and framework auto-detection shouldn't change the API. So unless you would rather address those first, I can go ahead and merge what is here already (since it is all new functionality).


fix:  Welcome mailer stopped for non signup oauth

Description

This PR fixes the error introduced in https://github.com/appsmithorg/appsmith/pull/25854 which lead to sending of welcome mails even for non signup - oauth type requests.

PR fixes following issue(s)
Fixes #27054

if no issue exists, please create an issue and ask the maintainers about this first

Media

A video or a GIF is preferred. when using Loom, don’t embed because it looks like it’s a GIF. instead, just link to the video

Type of change

Bug fix

Testing

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Also list any relevant details for your test configuration.
Delete anything that is not relevant

[ ] Manual
[ ] JUnit
[ ] Jest
[ ] Cypress

Test Plan

Add Testsmith test cases links that relate to this PR

Issues raised during DP testing

Link issues raised during DP testing for better visiblity and tracking (copy link from comments dropped on this PR)

Checklist:
Dev activity

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] PR is being merged under a feature flag

QA activity:

[ ] Speedbreak features have been covered
[ ] Test plan covers all impacted features and areas of interest
[ ] Test plan has been peer reviewed by project stakeholders and other QA members
[ ] Manually tested functionality on DP
[ ] We had an implementation alignment call with stakeholders post QA Round 2
[ ] Cypress test cases have been added and approved by SDET/manual QA
[ ] Added Test Plan Approved label after Cypress tests were reviewed
[ ] Added Test Plan Approved label after JUnit tests were reviewed

/ok-to-test


When will Cloud Trust configuration on Intune be built-in?

When will the WHfB Cloud-Trust setting be a normal toggle in the configuration options, rather than a manual OMA-URI entry?

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

ID: f37c7491-e550-86a8-5897-61d1a22c6631
Version Independent ID: f37c7491-e550-86a8-5897-61d1a22c6631
Content: Hybrid Cloud Trust Deployment (Windows Hello for Business) - Windows security
Content Source: windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-trust.md
Product: m365-security
GitHub Login: @Gitprakhar13
Microsoft Alias: prsriva

Thanks @tom-tackett  for taking the time to provide feedback on Windows! This idea is an interesting feature, and I want to make sure it gets directly into the hands of the engineering team. Fortunately, we've got dedicated channels for that very purpose. :)
For more info, see [Send feedback to Microsoft with the Feedback Hub app] https://support.microsoft.com/en-us/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332.
I think it’s important that you submit it directly, because that allows you to receive notifications and more closely monitor the progress. I'm closing this issue as there's nothing actionable for docs at this time.

Sounds good, thanks
R. Tom Tackett | IT Infrastructure Manager | PCC Aerostructures
Phone: 1+<PHONE_NUMBER> | E-Mail: @.https://owa.pccaero.com/owa/redir.aspx?C=lF-PxWrx8E6M1h9tLLNUTszNuASi5M8IG0HaAk56zJONGgE4Lrawb0zEIJFtjaMCCTllem0HX-Q.&URL=mailto%3ARTTackett%40pccaero.com | Time Zone: Central (GMT -6)
From: Yogesh Kumar @.>
Sent: Thursday, November 17, 2022 8:31 AM
To: MicrosoftDocs/windows-itpro-docs @.>
Cc: Tackett, Tom @.>; Mention @.***>
Subject: [EXTERNAL] Re: [MicrosoftDocs/windows-itpro-docs] When will Cloud Trust configuration on Intune be built-in? (Issue #10528)
External Email

Thanks @tom-tackett [github.com]https://urldefense.com/v3/__https:/github.com/tom-tackett__;!!Nhky1-KV!qEs72SKhlygwjjan6mcLjCUo-A452PuTp97Ho_dFI5xRPLbedwJAYp-SCdw7xAt9B-kNrFgpEg6j4BSs_O9xjnt7FK3TQA$ for taking the time to provide feedback on Windows! This idea is an interesting feature, and I want to make sure it gets directly into the hands of the engineering team. Fortunately, we've got dedicated channels for that very purpose. :)
For more info, see [Send feedback to Microsoft with the Feedback Hub app] https://support.microsoft.com/en-us/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332 [support.microsoft.com]https://urldefense.com/v3/__https:/support.microsoft.com/en-us/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332__;!!Nhky1-KV!qEs72SKhlygwjjan6mcLjCUo-A452PuTp97Ho_dFI5xRPLbedwJAYp-SCdw7xAt9B-kNrFgpEg6j4BSs_O9xjns-lY1-0Q$.
I think it’s important that you submit it directly, because that allows you to receive notifications and more closely monitor the progress. I'm closing this issue as there's nothing actionable for docs at this time.
—
Reply to this email directly, view it on GitHub [github.com]https://urldefense.com/v3/__https:/github.com/MicrosoftDocs/windows-itpro-docs/issues/10528*issuecomment-1318723772__;Iw!!Nhky1-KV!qEs72SKhlygwjjan6mcLjCUo-A452PuTp97Ho_dFI5xRPLbedwJAYp-SCdw7xAt9B-kNrFgpEg6j4BSs_O9xjnsAec8yFg$, or unsubscribe [github.com]https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AWM2AKUXSCJRCBTVG6QEUODWIY6QZANCNFSM5VPA7YXA__;!!Nhky1-KV!qEs72SKhlygwjjan6mcLjCUo-A452PuTp97Ho_dFI5xRPLbedwJAYp-SCdw7xAt9B-kNrFgpEg6j4BSs_O9xjnsVRjSBUQ$.
You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>
This email and any attachments may contain confidential and proprietary information and must be treated as such. In addition, export or re-export of the information contained in or attached to this email may be prohibited under export control laws.
To review our Privacy Policy please visit: www.precast.com


Handle Dataproc Jobs better

Related to #790
The Dataproc cluster wrapper method we use creates 3 jobs (start, run, close). Of those only the run job is passed back, so the production-pipelines stage wrapper framework can only automatically set dependencies on one job. All other dependencies need to be gathered and fed forward into the wrapper, which is against the pattern established by the pipeline framework.
Proposal - the wrapper is altered to pass back a list of all jobs, not just the 'worker' job. This removes the special case where dependencies need to be fed forward into the wrapper. This will require some changes to RD, GATK-SV, gCNV, and Large-cohort pipelines, but only a trivial change to each (I believe all stages currently using dataproc only generate a single job, and the Stage implementation equally accepts return of a job or list of jobs).
This issue is primarily with cpg-utils, but requires a counterpart here

Mitigated by dropping DataProc almost everywhere


Acting as a peripheral

Hello,
I was wondering if you planned to manage Peripheral mode, so that a smartphone or tablet can send advertisements, can be connected from another BLE devices, etc.
Cheers.

Yes, https://github.com/xabre/xamarin-bluetooth-le/tree/ble-server
But we focus on a neat client API, in first place.

Actually we have a 'server' or 'peripheral' package planned. It's currently in development on a different branch (issue #29 :)). Will keep you up to date with it's progress.

Oh. Nice. I missed the other branches. Very cool. Thanks guys.

Just wondering what the state of the ble-server branch is? I'm hoping to connect a few iOS/Android devices together with one as a host and the others as peripherals but it kinda seems like it's not going to be possible with this plugin and the ble-server hasn't been touched for two years, with no code on the iOS side?


refactor(checkbox): ts to sfc

Description

Linked Issues
cc: #492
Additional context

useControllable.ts copy your code and used.


Add Scala CLI

[ ] 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?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?

[x] Does your manifest conform to the 1.4 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: codeflow:open?pullrequest=https://github.com/microsoft/winget-pkgs/pull/110242&drop=dogfoodAlpha

@microsoft-github-policy-service agree

@wingetbot waivers Add Validation-Executable-Error


Added cards to the home page.

Tested the Materialize grid and the "card" template.

I have created a terminal-like box with some interesting content ;) Hope I've added the second commit correctly.

Nice. Will merge in class.


Fix wrong datetime value when using non-Gregorian calendar

Store date time and date time offset using IS0-8601 format based on invariant culture.
Addresses #494

Rebased (and squashed) on top of release/2.1


The pic is self-explanatory. The mic button is overlapping the text on the webpage.

Other than that, great website!

Good catch!
Until this is fixed, if you're not using the mic button, today's update adds an option to hide it under Settings -> Speech.


Self hosted service auth check URL update

fixes #64
Dropping the username from the path seems to be sufficient to get me past the block.

Thanks for this @trevjonez!! I didn't notice you had made a PR and also made the fix myself, but I'll merge your PR instead!


Setting media.currentTime >= duration loads complete file

This doesn't seem to be an specific issue of cassette but with the HTML5 video/audio implementation in Chrome (where I'm testing) at least.
I created a minimal reproduction: https://codesandbox.io/s/lx18nkkoll. You can try using "Seek to duration" button and check in the network tab that it will begin downloading the whole file, whereas if you click "Seek to math.floor(duration)" button, the track will end immediately, as one would expect. See if you can recreate it.
Should cassette prevent this behaviour and if so, where do you think it's more appropriate to handle it?

Firefox on MacOS doesn't seem to have the issue.

Thanks again for flagging this. I'll look into it later.. might be a Chrome bug.

I just reproduced this issue, and I think I understand what's happening.
In Chrome (and in Firefox), when we seek to a new timestamp, under normal circumstances we load just a bit of the file to allow smooth playback for the next 30 seconds or so. For smaller files, this might be the whole thing, but for really long tracks like your podcasts, this will be a tiny percentage of the total length of the file.
But in Chrome as you've noted, the behavior is weird when we seek to a timestamp greater than or equal to the duration of the track. Chrome loads the entire segment of the track between the previous currentTime and the end of the track. So in your case you found that it loaded the whole track, but when I seek to the halfway point first and then to the end, it only loads half of the track.
However if that range is already loaded, then nothing will be loaded when you seek to the end. e.g. if you hit the "Seek to math.floor(duration)" button first and then the "Seek to duration" button, there won't be anything new to load between the previous currentTime and the end of the track, so you won't see any new events in the network tab. This behavior is normal and expected, I'm just pointing it out so we don't get confused when we can't trigger the bug multiple times without refreshing.
I'd like to have a minimal repro for this demonstrating how different ranges are loaded depending on the starting timestamp (so we can file a bug in Chromium). It might be useful to have multiple long audio files for this. Do you have any more media links you can share for a repro? Or if you'd like to prepare the repro yourself, I wouldn't mind 😄 . Whatever you have time for!

Actually, I think one file is enough for now. I'll work on the ticket for Chromium!

So I went through the effort to create a minimal repro here in jsfiddle: http://jsfiddle.net/bqhy156n/22/
And... I don't have the same issue anymore. Do you think I missed anything with the repro?
I tried looking through the Cassette code to figure out what might be wrong. I figured maybe something's not right in the code that's run on the ended media event, but I didn't have much luck going down that path. It seems like even if I cancel that event handler we still have the track load in the repro example.
If you feel like poking around, feel free! I'll come back to this later if it's still unsolved.

I don't have the issue either on that repro, I'll see if I can get it to reproduce tomorrow.

@danielr18 ok so after listening to this whole thing... actually could I have a link to a different podcast episode so the chrome developers don't think I'm insane? 😄

https://play.podtrac.com/npr-510298/npr.mc.tritondigital.com/NPR_510298/media/anon.npr-podcasts/podcast/npr/ted/2017/08/20170811_ted_tedpod-cdfe15c2-fc45-4e58-a72a-5f0863bc71ea.mp3?orgId=1&d=3142&p=510298&story=542621772&t=podcast&e=542621772&ft=pod&f=510298

© Copyright 2012-2018 NPR - For Personal Use Only

https://dts.podtrac.com/redirect.mp3/dovetail.prxu.org/serial/ea810ac6-a771-492f-b56a-e1b988903631/serial-s01-e12.mp3

© Copyright 2019 Serial Podcast

Serial is great! I'll use that ☺


Smooth scroll not working in sparkling theme

Smooth scroll in the sparkling theme is not working. Clicking on the menu link directly jumps to section. It works perfectly in twenty nineteen theme.
jQuery version - 3.3.1
Plugins installed:
WPBakery Page Builder
jQuery updater
Disable Gutenburg.

This is a known issue with the jQuery updater.
Go to plugin settings and change the "Selector(s)" option to:
a[href*='#']:not([href='#'])
Save changes and test your page.
This "fix" is already implemented and will be public in the next plugin version (1.6.5). You can download and use plugin's development version (which has this fix) if you want:
https://downloads.wordpress.org/plugin/page-scroll-to-id.zip

I tried the above solution but still no luck in sparkling theme. It's working fine in Twentynineteen theme. Below are the attached videos.
videos.zip

Go to plugin settings and enable/check the "Prevent other scripts from handling plugin’s links" option. Save changes and test.

Still the same. Browser shows error as follows:
Firefox: TypeError: a.selector is undefined[Learn More] page-scroll-to-id.min.js:2:13192
p http://localhost/one-page/wp-content/plugins/page-scroll-to-id/js/page-scroll-to-id.min.js:2
 http://localhost/one-page/wp-content/plugins/page-scroll-to-id/js/page-scroll-to-id.min.js:2
Chrome:   Uncaught TypeError: Cannot read property 'indexOf' of undefined
at p (page-scroll-to-id.min.js:2)
at page-scroll-to-id.min.js:2
Safari: [Error] TypeError: undefined is not an object (evaluating 'a.selector.indexOf')
p (page-scroll-to-id.min.js:2:13399)
(anonymous function) (page-scroll-to-id.min.js:2:16708)

Can you make a test by deactivating jQuery updater and see if it works?

I deleted that plugin but shows the same error.

Hey, I've found the issue. I'll post an update here asap.

OK. I've just pushed a fix for this issue in plugin's development version here:
https://downloads.wordpress.org/plugin/page-scroll-to-id.zip
Please (re)download/install/activate. After (re)activation, go to plugin settings and enable/check the "Prevent other scripts from handling plugin’s links" option. Save changes and test again. It should work now.
Let me know :)

That removed the error but the smooth scroll is still not working. Any idea why?

Not sure. I've installed in a test environment the latest WordPress, WPBakery Page Builder and Sparkling theme. Created few menu links and a couple targets (as described here) and everything works as expected.
Do you have "Prevent other scripts from handling plugin’s links" option enabled?
What links have you created and how did you created them?

Do you have "Prevent other scripts from handling plugin’s links" option enabled? - Yes
What links have you created and how did you created them? :
I have created custom links in Menu and given the link for first- #section1, second- #section2 and so on...
And have added id in the Row ID field as section1, section 2 and so on...
Selector in page scroll to id field : a[href*='#']:not([href='#'])
Excluded selector as provided in the plugin: a[href^='#tab-'], a[data-toggle].
Let me know if I am missing something.

Seems that everything you've done is correct. There must be a script that prevents "Page scroll to id" from scrolling the page but I can't tell which. Every test I've done with wpbakery and sparkling theme (and jQuery updater) works for me.
Is it possible for me to see your site? I'd probably be able to provide an exact solution if I could see which script causes the issue.

I have sent credentials to your mail<EMAIL_ADDRESS>

Thanks. I've just replied to you by email.

Many thanks, it worked. Thank you for your support. 👍
I have overridden its function in the child theme by this code:
add_action( 'init', 'remove_my_action');
function remove_my_action() {
remove_action( 'wp_footer','sparkling_make_top_level_menu_clickable',1 );
}
function sparkling_menu_clickable() {
if ( ! wp_is_mobile() ) {
?>

<?php
}
}
add_action( 'wp_footer', 'sparkling_menu_clickable', 1 );

Great. Glad I helped :)
I think you have a typo in your code. Change the line:
$('.navbar-nav > li.menu-item > a.not("a[href*='#']:not([href='#'])').click(function () {
to:
$('.navbar-nav > li.menu-item > a').not("a[href*='#']:not([href='#'])").click(function () {

Okay, thanks for the update. 👍


Optional s3 input artifact appears as empty directory

Summary
What happened: When an optional input artifact is not supplied, an empty directory is still placed at the given path. This causes unexpected errors if that optional artifact is usually a file.
What you expected to happen: The empty directory should simply not be created if the input artifact is not supplied.
This issue is very similar to: #1503
But it requires an S3 input artifact.
Diagnostics
What version of Argo Workflows are you running?
Reproduced on: 3.0.2 and 3.0.4
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  annotations:
    meta.helm.sh/release-name: md-updateserver
    meta.helm.sh/release-namespace: sohi-wl-d4114
  creationTimestamp: "2021-05-18T06:32:31Z"
  generateName: minimal-optional-directory-appears-example-
  generation: 3
  labels:
    app.kubernetes.io/managed-by: Helm
    workflows.argoproj.io/completed: "true"
    workflows.argoproj.io/phase: Error
  managedFields:
  - apiVersion: argoproj.io/v1alpha1
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          .: {}
          f:meta.helm.sh/release-name: {}
          f:meta.helm.sh/release-namespace: {}
        f:generateName: {}
        f:labels:
          .: {}
          f:app.kubernetes.io/managed-by: {}
      f:spec:
        .: {}
        f:entrypoint: {}
    manager: Go-http-client
    operation: Update
    time: "2021-05-18T06:32:31Z"
  - apiVersion: argoproj.io/v1alpha1
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:labels:
          f:workflows.argoproj.io/completed: {}
          f:workflows.argoproj.io/phase: {}
      f:spec:
        f:arguments: {}
        f:templates: {}
      f:status:
        .: {}
        f:artifactRepositoryRef: {}
        f:conditions: {}
        f:finishedAt: {}
        f:message: {}
        f:nodes: {}
        f:phase: {}
        f:progress: {}
        f:resourcesDuration: {}
        f:startedAt: {}
    manager: workflow-controller
    operation: Update
    time: "2021-05-18T06:32:42Z"
  name: qwe
  namespace: sohi-wl-d4114
  resourceVersion: "43226"
  selfLink: /apis/argoproj.io/v1alpha1/namespaces/sohi-wl-d4114/workflows/qwe
  uid: 15a78869-ee40-4690-ac90-331655631326
spec:
  arguments: {}
  entrypoint: plan
  templates:
  - container:
      args:
      - ls -la
      command:
      - sh
      - -c
      image: alpine:latest
      name: ""
      resources: {}
    inputs:
      artifacts:
      - name: opt
        optional: true
        path: /file.yaml
        s3:
          accessKeySecret:
            key: access-key
            name: minio
          bucket: hosting
          endpoint: minio:9000
          insecure: true
          key: file.yml
          secretKeySecret:
            key: secret-key
            name: minio
    metadata: {}
    name: plan
    outputs: {}
status:
  artifactRepositoryRef:
    default: true
  conditions:
  - status: "False"
    type: PodRunning
  - status: "True"
    type: Completed
  finishedAt: "2021-05-18T06:32:41Z"
  message: 'Error (exit code 1): pods "qwe" is forbidden: User "system:serviceaccount:sohi-wl-d4114:default"
    cannot patch resource "pods" in API group "" in the namespace "sohi-wl-d4114"'
  nodes:
    qwe:
      displayName: qwe
      finishedAt: "2021-05-18T06:32:38Z"
      id: qwe
      inputs:
        artifacts:
        - name: opt
          optional: true
          path: /file.yaml
          s3:
            accessKeySecret:
              key: access-key
              name: minio
            bucket: hosting
            endpoint: minio:9000
            insecure: true
            key: file.yml
            secretKeySecret:
              key: secret-key
              name: minio
      message: 'Error (exit code 1): pods "qwe" is forbidden: User "system:serviceaccount:sohi-wl-d4114:default"
        cannot patch resource "pods" in API group "" in the namespace "sohi-wl-d4114"'
      name: qwe
      phase: Error
      progress: 1/1
      resourcesDuration:
        cpu: 4
        memory: 4
      startedAt: "2021-05-18T06:32:31Z"
      templateName: plan
      templateScope: local/qwe
      type: Pod
  phase: Error
  progress: 1/1
  resourcesDuration:
    cpu: 4
    memory: 4
  startedAt: "2021-05-18T06:32:31Z"

time="2021-05-18T06:25:29.794Z" level=info msg="Processing workflow" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:25:29.798Z" level=info msg="Updated phase  -> Running" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:25:29.798Z" level=info msg="Pod node qwe initialized Pending" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:25:29.799Z" level=info msg="skip volume mount of opt (/file.yaml): optional artifact was not provided" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:25:29.815Z" level=info msg="Created pod: qwe (qwe)" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:25:29.847Z" level=info msg="Workflow update successful" namespace=sohi-wl-d4114 phase=Running resourceVersion=42058 workflow=qwe
time="2021-05-18T06:25:39.817Z" level=info msg="Processing workflow" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:25:39.817Z" level=info msg="Pod failed: Error (exit code 1): pods \"qwe\" is forbidden: User \"system:serviceaccount:sohi-wl-d4114:default\" cannot patch resource \"pods\" in API group \"\" in the namespace \"sohi-wl-d4114\"" displayName=qwe namespace=sohi-wl-d4114 pod=qwe templateName=plan workflow=qwe
time="2021-05-18T06:25:39.818Z" level=info msg="Updating node qwe status Pending -> Error" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:25:39.818Z" level=info msg="Updating node qwe message: Error (exit code 1): pods \"qwe\" is forbidden: User \"system:serviceaccount:sohi-wl-d4114:default\" cannot patch resource \"pods\" in API group \"\" in the namespace \"sohi-wl-d4114\"" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:25:39.818Z" level=info msg="Updated phase Running -> Error" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:25:39.818Z" level=info msg="Updated message  -> Error (exit code 1): pods \"qwe\" is forbidden: User \"system:serviceaccount:sohi-wl-d4114:default\" cannot patch resource \"pods\" in API group \"\" in the namespace \"sohi-wl-d4114\"" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:25:39.818Z" level=info msg="Marking workflow completed" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:25:39.818Z" level=info msg="Checking daemoned children of " namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:25:39.842Z" level=info msg="Workflow update successful" namespace=sohi-wl-d4114 phase=Error resourceVersion=42105 workflow=qwe
time="2021-05-18T06:25:39.847Z" level=info msg="cleaning up pod" action=labelPodCompleted key=sohi-wl-d4114/qwe/labelPodCompleted
time="2021-05-18T06:28:18.159Z" level=info msg="Processing workflow" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:28:18.173Z" level=info msg="Updated phase  -> Running" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:28:18.174Z" level=info msg="Pod node qwe initialized Pending" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:28:18.187Z" level=info msg="Created pod: qwe (qwe)" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:28:18.201Z" level=info msg="Workflow update successful" namespace=sohi-wl-d4114 phase=Running resourceVersion=42422 workflow=qwe
time="2021-05-18T06:28:28.187Z" level=info msg="Processing workflow" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:28:28.187Z" level=info msg="Pod failed: Error (exit code 1): pods \"qwe\" is forbidden: User \"system:serviceaccount:sohi-wl-d4114:default\" cannot patch resource \"pods\" in API group \"\" in the namespace \"sohi-wl-d4114\"" displayName=qwe namespace=sohi-wl-d4114 pod=qwe templateName=plan workflow=qwe
time="2021-05-18T06:28:28.187Z" level=info msg="Updating node qwe status Pending -> Error" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:28:28.187Z" level=info msg="Updating node qwe message: Error (exit code 1): pods \"qwe\" is forbidden: User \"system:serviceaccount:sohi-wl-d4114:default\" cannot patch resource \"pods\" in API group \"\" in the namespace \"sohi-wl-d4114\"" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:28:28.188Z" level=info msg="Updated phase Running -> Error" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:28:28.188Z" level=info msg="Updated message  -> Error (exit code 1): pods \"qwe\" is forbidden: User \"system:serviceaccount:sohi-wl-d4114:default\" cannot patch resource \"pods\" in API group \"\" in the namespace \"sohi-wl-d4114\"" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:28:28.188Z" level=info msg="Marking workflow completed" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:28:28.188Z" level=info msg="Checking daemoned children of " namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:28:28.205Z" level=info msg="Workflow update successful" namespace=sohi-wl-d4114 phase=Error resourceVersion=42473 workflow=qwe
time="2021-05-18T06:28:28.219Z" level=info msg="cleaning up pod" action=labelPodCompleted key=sohi-wl-d4114/qwe/labelPodCompleted
time="2021-05-18T06:30:40.896Z" level=info msg="Processing workflow" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:30:40.899Z" level=info msg="Updated phase  -> Running" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:30:40.900Z" level=info msg="Pod node qwe initialized Pending" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:30:40.907Z" level=info msg="Created pod: qwe (qwe)" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:30:40.926Z" level=info msg="Workflow update successful" namespace=sohi-wl-d4114 phase=Running resourceVersion=42735 workflow=qwe
time="2021-05-18T06:30:50.910Z" level=info msg="Processing workflow" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:30:50.910Z" level=info msg="Pod failed: Error (exit code 1): pods \"qwe\" is forbidden: User \"system:serviceaccount:sohi-wl-d4114:default\" cannot patch resource \"pods\" in API group \"\" in the namespace \"sohi-wl-d4114\"" displayName=qwe namespace=sohi-wl-d4114 pod=qwe templateName=plan workflow=qwe
time="2021-05-18T06:30:50.910Z" level=info msg="Updating node qwe status Pending -> Error" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:30:50.910Z" level=info msg="Updating node qwe message: Error (exit code 1): pods \"qwe\" is forbidden: User \"system:serviceaccount:sohi-wl-d4114:default\" cannot patch resource \"pods\" in API group \"\" in the namespace \"sohi-wl-d4114\"" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:30:50.911Z" level=info msg="Updated phase Running -> Error" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:30:50.911Z" level=info msg="Updated message  -> Error (exit code 1): pods \"qwe\" is forbidden: User \"system:serviceaccount:sohi-wl-d4114:default\" cannot patch resource \"pods\" in API group \"\" in the namespace \"sohi-wl-d4114\"" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:30:50.911Z" level=info msg="Marking workflow completed" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:30:50.911Z" level=info msg="Checking daemoned children of " namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:30:50.928Z" level=info msg="Workflow update successful" namespace=sohi-wl-d4114 phase=Error resourceVersion=42784 workflow=qwe
time="2021-05-18T06:30:50.951Z" level=info msg="cleaning up pod" action=labelPodCompleted key=sohi-wl-d4114/qwe/labelPodCompleted
time="2021-05-18T06:31:53.785Z" level=info msg="Processing workflow" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:31:53.787Z" level=info msg="Updated phase  -> Running" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:31:53.787Z" level=info msg="Pod node qwe initialized Pending" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:31:53.787Z" level=info msg="skip volume mount of opt (/file.yaml): optional artifact was not provided" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:31:53.794Z" level=info msg="Created pod: qwe (qwe)" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:31:53.803Z" level=info msg="Workflow update successful" namespace=sohi-wl-d4114 phase=Running resourceVersion=42914 workflow=qwe
time="2021-05-18T06:32:03.795Z" level=info msg="Processing workflow" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:32:03.795Z" level=info msg="Pod failed: Error (exit code 1): pods \"qwe\" is forbidden: User \"system:serviceaccount:sohi-wl-d4114:default\" cannot patch resource \"pods\" in API group \"\" in the namespace \"sohi-wl-d4114\"" displayName=qwe namespace=sohi-wl-d4114 pod=qwe templateName=plan workflow=qwe
time="2021-05-18T06:32:03.796Z" level=info msg="Updating node qwe status Pending -> Error" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:32:03.796Z" level=info msg="Updating node qwe message: Error (exit code 1): pods \"qwe\" is forbidden: User \"system:serviceaccount:sohi-wl-d4114:default\" cannot patch resource \"pods\" in API group \"\" in the namespace \"sohi-wl-d4114\"" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:32:03.796Z" level=info msg="Updated phase Running -> Error" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:32:03.796Z" level=info msg="Updated message  -> Error (exit code 1): pods \"qwe\" is forbidden: User \"system:serviceaccount:sohi-wl-d4114:default\" cannot patch resource \"pods\" in API group \"\" in the namespace \"sohi-wl-d4114\"" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:32:03.796Z" level=info msg="Marking workflow completed" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:32:03.796Z" level=info msg="Checking daemoned children of " namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:32:03.809Z" level=info msg="Workflow update successful" namespace=sohi-wl-d4114 phase=Error resourceVersion=42963 workflow=qwe
time="2021-05-18T06:32:03.850Z" level=info msg="cleaning up pod" action=labelPodCompleted key=sohi-wl-d4114/qwe/labelPodCompleted
time="2021-05-18T06:32:31.979Z" level=info msg="Processing workflow" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:32:31.981Z" level=info msg="Updated phase  -> Running" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:32:31.982Z" level=info msg="Pod node qwe initialized Pending" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:32:31.994Z" level=info msg="Created pod: qwe (qwe)" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:32:32.009Z" level=info msg="Workflow update successful" namespace=sohi-wl-d4114 phase=Running resourceVersion=43177 workflow=qwe
time="2021-05-18T06:32:41.994Z" level=info msg="Processing workflow" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:32:41.994Z" level=info msg="Pod failed: Error (exit code 1): pods \"qwe\" is forbidden: User \"system:serviceaccount:sohi-wl-d4114:default\" cannot patch resource \"pods\" in API group \"\" in the namespace \"sohi-wl-d4114\"" displayName=qwe namespace=sohi-wl-d4114 pod=qwe templateName=plan workflow=qwe
time="2021-05-18T06:32:41.995Z" level=info msg="Updating node qwe status Pending -> Error" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:32:41.995Z" level=info msg="Updating node qwe message: Error (exit code 1): pods \"qwe\" is forbidden: User \"system:serviceaccount:sohi-wl-d4114:default\" cannot patch resource \"pods\" in API group \"\" in the namespace \"sohi-wl-d4114\"" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:32:41.995Z" level=info msg="Updated phase Running -> Error" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:32:41.995Z" level=info msg="Updated message  -> Error (exit code 1): pods \"qwe\" is forbidden: User \"system:serviceaccount:sohi-wl-d4114:default\" cannot patch resource \"pods\" in API group \"\" in the namespace \"sohi-wl-d4114\"" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:32:41.995Z" level=info msg="Marking workflow completed" namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:32:41.995Z" level=info msg="Checking daemoned children of " namespace=sohi-wl-d4114 workflow=qwe
time="2021-05-18T06:32:42.019Z" level=info msg="Workflow update successful" namespace=sohi-wl-d4114 phase=Error resourceVersion=43226 workflow=qwe
time="2021-05-18T06:32:42.101Z" level=info msg="cleaning up pod" action=labelPodCompleted key=sohi-wl-d4114/qwe/labelPodCompleted

Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.

This seems sensible - did you test in v2.12 and see a different behavior?

No, I didn't test it in v2.12, I only tested it with 3.0.2 and 3.0.4.
Sorry but I'm relatively new to the argo-workflows project. Why specifically v2.12? Is that a special version I'm not aware of?
The bug I linket to is fixed in 2.5 and was reported in 2.3 so I don't get it.

I’d like to know if this is a regression. If so, it is higher priority to fix.

@shrgabor any update please?

Sorry @alexec, yes I think this is a regression.
I think the commit which break this was this: c8215f972502435e6bc5b232823ecb6df919f952
see workflow/controller/workflowpod.go:925
It changed HasLocation() to HasLocationOrKey() while adding the key-only artifacts feature.
I checked the fixes for the original problem and it does not test if the optional artifact has a key too.
I have to state that I'm very newbie in argo-workflows. I just tried to trace the breadcrumbs back to the original problem.
So that is why I'm giving you so uncertain answer.
I hope that helps solving the problem.

c8215f972502435e6bc5b232823ecb6df919f952

So that makes sense. We mount the volume at the path (rather than create an empty directory, but it looks like the same thing from the POV of the main container). This code does not check to see if the artifact actually existed.

This is a bind. The volumes are set-up by the controller, but the controller cannot know if the artifact will actually exist. Only the wait container can know this.

@shrgabor can you please confirm if you ran and reproduced the issue in v2.12? Or did you inspect the code changes and infer that it was a regression? It is not clear from your comments.

Gentle bump @shrgabor

Thanks for the bump, I was not monitoring this issue lately.

@shrgabor can you please confirm if you ran and reproduced the issue in v2.12? Or did you inspect the code changes and infer that it was a regression? It is not clear from your comments.
Sorry if I wasn't clear enough. I was inspecting the code changes only. I have never tested it in v2.12, and I have never said so.
I'm still confused about you asking that specific version.
I have to state that I don't have the resources to test it in that version.

Guys, please don't close it without any improvement! :)
At least link another issue which solves this issue.


Server Guide docs are out of date (?)

Based on the line import Location from 'react-router/lib/Location'; from https://github.com/rackt/react-router/blob/master/doc/00 Guides/Server Rendering.md ,  I'm getting Error: Cannot find module 'react-router/modules/Location'.
I'm unsure as how to proceed, as the new API doesn't have a simple Location object.
I did find a StaticLocation class:
var router = require('react-router');
loc = new router.StaticLocation('/');

Can anyone confirm this is the correct understanding?

What version of react-router are you using?

Getting the same problem after upgrading from 1.0.0-beta3 to 0.13.3

1.0-beta-3 is the newest.

Please don't read docs in the repo.
They are work in progress and don't reflect the stable version: https://github.com/rackt/react-router/commit/44a1692d97b95cd4f1cf995d97a55eb2da7dcd86.
Instead, read them on the website: http://rackt.github.io/react-router.
It defaults to the latest released version (0.13.3).


document the fact that duplicate name are not allowed

and some other rephrasings

Changes

Submitter Checklist

[ ] ♽  Run make test lint before submitting a PR (ie: with pre-commit, no need to waste CPU cycle on CI
[ ] 📖 If you are adding a user facing feature or make a change of the behavior, please verify that you have documented it
[ ] 🧪 100% coverage is not a target but most of the time we would rather have a unit test if you make a code change.
[ ] 🎁 If that's something that is possible to do please ensure to check if we can add a e2e test.
[ ] 🔎 If there is a flakiness in the CI tests then don't necessary ignore it, better get the flakyness fixed before merging or if that's not possible there is a good reason to bypass it. (token rate limitation may be a good reason to skip).

generated with https://github.com/d1egoaz/c3po.el :p


BUG Fully implement iterator protocol in PaginatedResponse

The PaginatedResponse provided iteration support, but didn't implement the __next__ method. This meant that the object itself was not an iterator. A small tweak can turn it into an iterator itself. Since the PaginatedResponse is returned when users provide an iterator=True argument to list endpoints, it seems reasonable for them to expect the returned object is an iterator.

@keithing , thanks for pointing that out. Given the test failure on the Python 2 Travis build, the iterator response never worked in Python 2. Our test had been wrapping the PaginatedResponse in an iter call. Without that, the Python 2 iteration broke. This PR fixes it.


Using TS generics (Diamond syntax <>) in SFC template fails in 3.2.34

Link to minimal reproduction
https://stackblitz.com/edit/vitejs-vite-83x6xy?file=src/App.vue
Steps to reproduce
Use generics in SFC template with diamond syntax <>
What is expected?
It was working just fine up until 3.2.34, this fork shows that it works fine with only a version change to 3.2.33 https://stackblitz.com/edit/vitejs-vite-dp1cf3?file=package.json
What is actually happening?
It throws an Unexpected token compilation error.
System Info
not relevant - repro is stackblitz

Any additional comments?
We've been using this syntax for typing slots in the template.

I suspect this bug was introduced in https://github.com/vuejs/core/commit/ccf92564d339cdee3947aecfba2e861c88864883


Issues with your latest APK

The updater at the IzzyOnDroid repo just reported multiple issues when pulling in your latest APK:
! repo/com.prostudio.urltopdfconverter_3.apk declares sensitive permission(s): android.permission.READ_EXTERNAL_STORAGE android.permission.MANAGE_EXTERNAL_STORAGE
! repo/com.prostudio.urltopdfconverter_3.apk: debuggable or testOnly set in AndroidManifest.xml
! com.prostudio.urltopdfconverter_3.apk (com.tawhid.webcapture) has no metadata!

OK, the last one means you've changed the packageName. That means it is an entirely new app, and direct updates to this version are not possible.
The first one means we'd have to add the mentioned permissions (with a short description what they are needed for) to your app's "green list" as otherwise they'd be shown as "warnings".
The one in the middle is the biggest problem here: apps for distribution must have NEITHER of the two set. Wondering how those come in, problem number 4 shows up:
Signer #1 certificate DN: C=US, O=Android, CN=Android Debug
Signer #1 certificate SHA-256 digest: b411f6432b53509f36236b18bee35e5d81de6b6ec5db4f0061f5ee9fe4875259
Signer #1 certificate SHA-1 digest: e134beef19d6f5ea9d6a6ca6010641ace8c03eb6
Signer #1 certificate MD5 digest: 0e102ad1d91636119597a960d87b49a2
Signer #1 key algorithm: RSA
Signer #1 key size (bits): 2048

The APK is signed using a debug key. That's not intended for distribution; please always sign release APKs with a release key!
As for the IzzyOnDroid repo, there's a 5th problem now: APK size increased by almost factor 10 from less than 5 MB to almost 40 MB (per-app size limit here is 30 MB). What happened there? For one, compared with the previous release, I see a load of native library directories, each containing about 5 MB for pdfdium. For 6 architectures. Are there really any Android devices running on MIPS? Even x86 is rather rare (or almost non-existent, if we ignore emulators for a little). 2 armeabi dirs (armeabi, armeabi-v7a)? Any devices for the former? All those *.so files are stored uncompressed inside the APK, so each dropped unnecessary ABI would mean 5+ MB saved. An APK with just the 2 ARM ABIs would probably be around 15 MB. Per-ABI APKs most likely around 10 MB each or less.
Can we get those issues solved? Thanks in advance!

Thank you, I will try to fix them as soon as possible.

1. I understand that changing the package name creates a new app. Given that, we should proceed with publishing this version as a new app. This will ensure that users can access the latest features and improvements.

About those permissions

Thanks for the details! As the minimal Android version required for your app is Android 6 (sdkVersion 23), I'd have thought you'd use SAF (Storage Access Framework) instead. The integrated PDFReader to open any PDF files on the device of course makes it reasonable to request full access.

we should proceed with publishing this version as a new app

If that's intended, that part of course is fine. But the crucial phe point is the debug key there – which is a show-stopper (see here for some background). And the APK size: with 36 MB, it's beyond the per-app limit at IzzyOnDroid (which is 30 MB). Hence my suggestion for split APKs.
So without those two issues fixed, we cannot proceed with publishing, sorry.

PS: shouldn't the change of the package name also be mentioned in the "what's changed" section on the release notes? :wink:

Hi, I've now resolved both concerns.

The APK has been signed with the release key.
I split the APKs.

Let me know if there anything else need to fix ☺
Best regards,
Tawhid Monowar

Thanks! Integrating that now. One finding by the scanners here:
SigningBlock blobs:
-------------------
0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)

This can easily be avoided with a minor addition to your build.gradle:
android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs.
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles.
        includeInBundle = false
    }
}

For some background: that BLOB is supposed to be just a binary representation of your app's dependency tree. But as it's encrypted with a public key belonging to Google, only Google can read it – and nobody else can even verify what it really contains. More details can be found e.g. here: Ramping up security: additional APK checks are in place with the IzzyOnDroid repo.

At IzzyOnDroid we support Reproducible Builds (see: Reproducible Builds, special client support and more at IzzyOnDroid).  I've tried to just keep in 2 ABIs, same result. Kept it untouched, same result. It seems it always builds only the full APK. Here's the output from the end of the build with the build.gradle left untouched:
BUILD SUCCESSFUL in 1m 38s
38 actionable tasks: 38 executed
+ find . -name '*.apk'
./app/build/outputs/apk/release/app-release-unsigned.apk

Just a single APK where I'd have expected 6. Taking a closer look: You didn't build from the commit the tag points to, did you? Because the build.gradle there has no splits defined.
OK, trying from d649b34384e2b93b13e309e070c83885fd48c3be then – the commit you've introduced the splits with. Better now; the additional libs are gone. But it's still not RB:
  -rw-r--r--  0.0 unx       56 b-       52 defN 1981-01-01 01:01:02 37fbe4f4 META-INF/com/android/build/gradle/app-metadata.properties
- -rw-r--r--  0.0 unx     1720 b-     1720 stor 1981-01-01 01:01:02 30f4a7ff assets/dexopt/baseline.prof
+ -rw-r--r--  0.0 unx     1720 b-     1720 stor 1981-01-01 01:01:02 40e8ea66 assets/dexopt/baseline.prof
  -rw-r--r--  0.0 unx      183 b-      183 stor 1981-01-01 01:01:02 344218f4 assets/dexopt/baseline.profm
- -rw-r--r--  0.0 unx  8971488 b-  3363363 defN 1981-01-01 01:01:02 a7a6afba classes.dex
+ -rw-r--r--  0.0 unx  8971496 b-  3363310 defN 1981-01-01 01:01:02 26eb0ceb classes.dex
  -rw-r--r--  0.0 unx     1532 b-      634 defN 1981-01-01 01:01:02 64b746bb classes2.dex

Looking at the Dex diff, it looks like the versionCode problem again when trying to build a single ABI:
       access        : 0x0019 (PUBLIC STATIC FINAL)
-      value         : 6003
+      value         : 3003
     #4              : (in Lcom/tawhid/webcapture/BuildConfig;)

But checking both APKs directly, versionCode matches for them: they both show 3003. So this must be something else. Last try: building from eb1b1dd503595e7aaa8935933591f53f5f4ea250 where you applied another minor change. No dice, same issue.
Funnily, when I build from that commit leaving all ABIs enabled, it is RB. I'll use it like that for now then – though that's a bit wasting resources…
We'd appreciate if you could help keeping your build reproducible. We've prepared some hints on reproducible builds for that. The first basic rule is: always build the APK from a clean tree at the commit the tag points to :wink: (please remember that for future releases – do not change the current ones as they've already been distributed now)
Thanks a lot!
cc @obfusk

@IzzySoft is this app live on F-Droid?

@licaon-kter can you summarize the issues? 🙂

@tawhidmonowar your app is live at IzzyOnDroid with the new appId and shows as Reproducible Build – so be welcome to pick a badge to link there e.g. from your Readme :smiley: The only open issue from our end (at IzzyOnDroid) is the signing block blob, which still needs fixing (see here for details):

@licaon-kter any other issues you see amiss for F-Droid?

@IzzySoft since it will be a new app, we will pursue 0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE) being removed
@tawhidmonowar that ^^^ aside, your "new" PDF stuff uses a lib from 8(!!!) years ago?  https://github.com/tawhidmonowar/WebCapture/blob/1.0.2/app/build.gradle#L46
which depends on https://github.com/DImuthuUpe/AndroidPdfViewer/blob/2.3.0/android-pdf-viewer/build.gradle#L41
which pulls random binaries like https://github.com/barteksc/PdfiumAndroid/tree/pdfium-android-1.5.0/src/main/jni/lib
fyi we disabled a bunch of apps using a newer version of that lib 2(!!) years ago: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/11496 per ref: https://divestos.org/misc/appsec.txt


RTL support

As I have tested this library does not support rtl direction. The positions are mirrored. How can it be fixed?

+1

+1

Yes @H-Shafiei  RTL does not support for the same. we are make sure above PR should be merge.


Bump plugin.yaml version to 0.4.0

It looks like the 0.4.0 release tarball has the wrong version number in plugin.yaml, making my helm plugin list command confusingly show the wrong number.
This PR corrects that, but you'd need to re-tag and re-release to fix. Or cut a 0.4.1.

I guess the version numbers in the README probably need bumping, too.

Yup. I noticed this earlier today, too. If you bump those versions too, then I'll merge.
Thanks!

@jzelinskie Crunched these down to one commit and rebased.

Thanks again!


Recent Activity (Repeated Reviews)

The Recent Activity Feed on the homepage should show the most recent reviews (in order).
Expected Behavior
There should not be repeated reviews on the recent activity feed.
Current Behavior
There are repeated reviews on the recent activity feed towards the end of the feed.
Ideas for Improvement
Modify the bootstrap code for the slider feature for recent activity regarding reviews to ensure there are not repeated items.
Steps to Reproduce

Click on a restaurant and "Write a Review".
Once your review is confirmed, go to the Home page and browse through the feed to see the duplicate.

Context (Environment)
As a user, I want to see the most recent activity on DineLine. However, I see the same review more than once.

Issue Fixed


Safer security group settings

what

Specify a name_prefix, rather than name
Ignore changes in the security group's name
Set the security group as create_before_destroy

why

SG name: The default security name is extremely generic and additionally conflicts with itself if the DB is rebuilt
SG ignore_changes: Security group rebuilds are generally disruptive and should be avoided
SG create_before_destroy: Minimise disruption when we do have to rebuild

references

Fixes #86

@alexjurkiewicz typically we don't use name_prefix AFAIK. This is because the label module (which is module.this.id in this case) allows for enough customization to create a unique enough name for any given scenario. If you need to rebuild a specific RDS cluster you can use the attributes input variable to accomplish creating a new one and then you can delete the old. Does that make sense?

Thanks for the feedback. Just making sure I'm clear: you are saying it's not a bug if the module fails while re-creating resources if the context is unchanged?

@alexjurkiewicz hm, putting it that way makes me re-think this.

I use this module a lot to create and destroy cluster and clones.
recreating has always the problem of conflicts depending if the destroy plan happen to be in the order that was supposed to be, although this happened mostly in the early days I do not see it very often but as like @Gowiem said using the label module is very easy to customize a name enough that you will not have a conflict.
could @alexjurkiewicz  please expand on the cases you have seen this? and maybe paste and output? I'm interested in reproducing it.
Thanks.

I created this module with the following context:
namespace = "myapp"
stage = "prd"
name = "auth"
It created a security group called "myapp-prd-auth". I thought that name
was a little generic, so I changed name => name_prefix. I could have also
added a hardcoded suffix of "-rds" but decided not to.
I then added create_before_destroy because IMO it is better default
behaviour for security groups.
On Fri, 4 Dec 2020 at 15:40, PePe Amengual<EMAIL_ADDRESS>wrote:

I use this module a lot to create and destroy cluster and clones.
recreating has always the problem of conflicts depending if the destroy
plan happen to be in the order that was supposed to be, although this
happened mostly in the early days I do not see it very often but as like
@Gowiem https://github.com/Gowiem said using the label module is very
easy to customize a name enough that you will not have a conflict.
could @alexjurkiewicz https://github.com/alexjurkiewicz please expand
on the cases you have seen this? and maybe paste and output? I'm interested
in reproducing it.
Thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cloudposse/terraform-aws-rds-cluster/pull/93#issuecomment-738560309,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAC4U5KV6RXNVCJKUSG3PLLSTBR3JANCNFSM4UKCFE4Q
.

I think the https://github.com/cloudposse/terraform-null-label gives enough flexibility to solve this problem, if you did not like the name then you could have added an attribute or something to change it to make it look like you wanted.

@alexjurkiewicz The idea of the naming scheme is that you specify enough information so that you can recognize the component being referenced from the generated id. In your example, I might choose the name "authdb", and then the SG name " "myapp-prd-authdb" makes sense to me. The point is that the security group is named the same as the cluster so that you can easily associate the two.
It is true that deleting security groups (or even worse, VPCs) can take a long time or fail completely. That is more of a consequence of what is in them than how they are named. If there is a genuine issue of things not being created or deleted in the correct order, we should fix that using depends_on, not paper over it.
That said, I'm not opposed to using name_prefix and create_before_destroy, but since it is not backward compatible and will cause everyone using the module to change their SGs using the old destroy before create behavior, I would not want to make it the default behavior. Unfortunately I do not see a way to add this feature in a way that will not disturb existing clusters, so it would have to be solving a serious problem for me to support it.

Why not support both name and name_prefix arguments using a variable switch?
 name        = var.use_name ? module.this.id : null
  name_prefix = var.use_name ? null :  module.this.id

Thanks for the feedback all.

That said, I'm not opposed to using name_prefix and create_before_destroy, but since it is not backward compatible and will cause everyone using the module to change their SGs using the old destroy before create behavior, I would not want to make it the default behavior. Unfortunately I do not see a way to add this feature in a way that will not disturb existing clusters, so it would have to be solving a serious problem for me to support it.

You are right, I think we can't break backwards compatibility with this change. That's why I added a lifecycle directive to ignore changes in the security group name. For people with this module already deployed, their security group won't change. If they ever rebuild from scratch, they'll get the new name style.

Thanks for the feedback all.

That said, I'm not opposed to using name_prefix and create_before_destroy, but since it is not backward compatible and will cause everyone using the module to change their SGs using the old destroy before create behavior, I would not want to make it the default behavior. Unfortunately I do not see a way to add this feature in a way that will not disturb existing clusters, so it would have to be solving a serious problem for me to support it.

You are right, I think we can't break backwards compatibility with this change. That's why I added a lifecycle directive to ignore changes in the security group name. For people with this module already deployed, their security group won't change. If they ever rebuild from scratch, they'll get the new name style.

You are right, I think we can't break backwards compatibility with this change. That's why I added a lifecycle directive to ignore changes in the security group name. For people with this module already deployed, their security group won't change. If they ever rebuild from scratch, they'll get the new name style.

The problem is that the introduction of the lifecycle directive itself will cause the current resource to be destroyed and recreated.

You are right, I think we can't break backwards compatibility with this change. That's why I added a lifecycle directive to ignore changes in the security group name. For people with this module already deployed, their security group won't change. If they ever rebuild from scratch, they'll get the new name style.

The problem is that the introduction of the lifecycle directive itself will cause the current resource to be destroyed and recreated.

Dang. I never realised that. I looked into alternate solutions here but couldn't find any. Thanks for your feedback.


then_concurrent / map_concurrent

Hi,
I'm sure I'm missing something, but I'm trying to find something like for_each_concurrent, but which will let me return a list of items too. then_concurrent doesn't exist; is there some other method that I'm missing? This is for a regular stream constructed with futures::stream::iter.
I.e., I'd like to do something like this:
let res = futures::stream::iter(files.iter())
  .then_concurrent(None, |file| tokio::spawn(async move { process(file) }).await.unwrap())
  .collect().await;

and have it process the files in parallel.

I think buffer_unordered/buffer + map/then works as such. See also #2609.


Visualizing Senders and Listeners

Had a look onto UnityEventVisualizer, which looks very useful especially for bigger projects.
Tried porting it, the issue was that this EventManager is dynamic instead of static and connections are made on runtime (which is why it is great).
I had the following ideas to solve it, but neither is really good:

Use a static code analyzer to check for AddListener and Raise in the code
Extend EventManager to give that information at runtime. This would however only work if all Event-Raises are executed etc... The picture would probably be incomplete in most of the cases

Do you have a better idea on how such a visualization could be implemented?

Just spent a few hours implementing this. Looks very good so far, PR incoming.


macro-ify

... and generate SoA implementations for up to eleven tuples.

Cool! :100:

Now quite outdated, though fixing it up shouldn't be hard if there's interest.


Serde M4 fails in micronaut-security

We had an issue in security with M3 whereby unknown properties in the json would cause deserialization to fail.
This was fixed in https://github.com/micronaut-projects/micronaut-serialization/pull/439 and M4 was released
Tried to update to use the new M4 of serde in https://github.com/micronaut-projects/micronaut-security/pull/1303, and we're getting test failures in the oauth module
https://ge.micronaut.io/s/xgizhyx4r22hq/tests/overview?outcome=failed
It seems to be a NPE in io.micronaut.json.convert.JsonConverterRegistrar.lambda$mapToObjectConverter$2 here
The error is shown (on a single line) in the build scan

My original PR was closed in favor of https://github.com/micronaut-projects/micronaut-security/pull/1304
Where @sdelamo extracted a form out to get the tests to pass with M4

I created an issue for what I found upgrading security to M4 https://github.com/micronaut-projects/micronaut-serialization/issues/441


Add NDK to Android Image

https://developer.android.com/ndk/index.html
I think this is worth adding. @marcomorain what do you think?
Would fix https://github.com/circleci/circleci-docs/issues/1876

Closed in favor of https://github.com/circleci/circleci-images/issues/73


Add new feature : Password on page

Hello World,
I would like to request a new feature.
It is possible to add a login/password (or just password) for a page (or page and post)
Regards,

Hello,
Why close without explication ?
Best Regard,

@SckyzO this a feature request for Ghost in general, not for Ghost Android (which is just the mobile app).

Ho Sorry :)
Thx :)


allow for hydration where all records are null

Previously this would error when all records attempting to be hydrated were null/not present in the scope. This was because the hydration logic would try and find a constructor that had at least one record that was present in the scope. This will fall back to selecting the first all-record-annotated constructor instead.

Codecov Report

Merging #62 (0cd359e) into main (1864a83) will increase coverage by 0.03%.
The diff coverage is 71.42%.

@@             Coverage Diff              @@
##               main      #62      +/-   ##
============================================
+ Coverage     79.20%   79.24%   +0.03%
+ Complexity      178      176       -2
============================================
  Files            20       20
  Lines          1236     1238       +2
  Branches        150      150
============================================
+ Hits            979      981       +2
  Misses          174      174
  Partials         83       83

Impacted Files
Coverage Δ

.../src/main/kotlin/io/provenance/scope/sdk/Client.kt
63.75% <71.42%> (+0.45%)
:arrow_up:

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 1864a83...0cd359e. Read the comment docs.


New CIF starting with "J" fix + Test suite

There you go!
https://github.com/javiertoledo/spanish_vat_validators/pull/7 and https://github.com/javiertoledo/spanish_vat_validators/pull/8 are also included in this PR.

🍻

Are you ok with releasing a new version?

Nice! Thanks to both! :tada: :tada:

Yeah, a new release would be nice! :)

New version released, thanks everyone! https://rubygems.org/gems/spanish_vat_validators/versions/0.0.6


Dgraph

The majority of the comments on the current benchmark 2018 suggest Dgraph as comparison and I fully agree on that, especially since Neo4J is known as a comparable slow graph database, while surely a widespread one.
I am very interested in a comparison to dgraph. :)

hi there, we're happy to provide support to make that happen!


📦 NEW: AI master chef

Updated chat example for master chef pipe

updated chat interface text in opening.tsx, readme.md, and header.tsx

Please let me know if more details are required

Please re-request the review once you make the changes.


Upgrade indexer-neon API

To move all major IO operations from NodeJS to Rust, indexer-neon API should cover all existed functionality, like:

creating and holding sessions
making search and holding results
detecting file types and including it into the session
etc

The first version of API is implemented in the scope of https://github.com/esrlabs/chipmunk/commit/2c598dea128ff894f77131649d9f37990760eedd

The first version of API is implemented in the scope of https://github.com/esrlabs/chipmunk/commit/2c598dea128ff894f77131649d9f37990760eedd


Texture-only block updates are incomplete

When a block is replaced with another block of the same shape, we try to keep the geometry and modify the texture. This only works as intended if the BlockMesh uses exclusively texture colors and not vertex colors, but it is not (even though the code looks like it is doing what it's supposed to); this is visible in the UI buttons having colors left over from the opposite toggle state.
This problem should be easy enough to fix if we can just add the right instrumentation to see what it's doing…
(Note that the UI buttons should also be setting their animation hint to indicate that they might be replaced; doing that would hide this bug.)

Fixed by 2a6d136700e64560fe96ac6bc2209199bbdcb986.
used_any_vertex_colors was not being set true for ordinary colored vertices, only the ones produced by failing to allocate a texture.


Update code-docs for readStyle and writeStyle

Title explains it all...
resolves https://github.com/terrestris/geostyler-openlayers-parser/pull/19#issuecomment-414202844

Nice. Thanks.


Queue sheet upload

Can a way to upload the information from the Queue sheet Column CH and CI to PEGR DB be created with a hyperlink to the sequencing replicates? This is to identify when a sample has been submitted more than once for sequencing for example to get more tags. This identifies samples that should be treated as one. We will need a mechanism to fix mistakes too.
Samples from run 578 were resequenced  in run 584
PEGR ID
32492=32697
32493=32698
32494=32699
32502=32700
Can this data be added in the PEGR Replicates region? See attached screen shot

Originally posted by @amg246 in https://github.com/seqcode/pegr/issues/260#issuecomment-1239872305

clean up sample.note
import from q-form
display
export q-form
CRUD in admin dashboard


thepeg: 2.1.2 -> 2.1.3

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/thepeg/versions.
These checks were done:

built on NixOS
/nix/store/2rb62aaw0nwqkcpkzs579bilyi5sa6jm-thepeg-2.1.3/bin/setupThePEG passed the binary check.
/nix/store/2rb62aaw0nwqkcpkzs579bilyi5sa6jm-thepeg-2.1.3/bin/runThePEG passed the binary check.
2 of 2 passed binary check by having a zero exit code.
2 of 2 passed binary check by having the new version present in output.
found 2.1.3 with grep in /nix/store/2rb62aaw0nwqkcpkzs579bilyi5sa6jm-thepeg-2.1.3
directory tree listing: https://gist.github.com/6c2d35516306fec51d9ede572a078eed
du listing: https://gist.github.com/939dc629473c5d502f221cb036db05a2

meta.description for thepeg is: '"Toolkit for High Energy Physics Event Generation"'.
cc @veprbl for testing.

Success on x86_64-linux (full log)
Attempted: thepeg
Partial log (click to expand)
shrinking /nix/store/2rb62aaw0nwqkcpkzs579bilyi5sa6jm-thepeg-2.1.3/lib/ThePEG/BudnevPDF.so.27.0.0
shrinking /nix/store/2rb62aaw0nwqkcpkzs579bilyi5sa6jm-thepeg-2.1.3/lib/ThePEG/ThePEGLHAPDF.so.25.0.1
shrinking /nix/store/2rb62aaw0nwqkcpkzs579bilyi5sa6jm-thepeg-2.1.3/lib/ThePEG/SimpleDISCut.so.27.0.0
shrinking /nix/store/2rb62aaw0nwqkcpkzs579bilyi5sa6jm-thepeg-2.1.3/lib/ThePEG/DalitzDecayer.so.27.0.0
shrinking /nix/store/2rb62aaw0nwqkcpkzs579bilyi5sa6jm-thepeg-2.1.3/lib/ThePEG/V2LeptonsCut.so.27.0.0
shrinking /nix/store/2rb62aaw0nwqkcpkzs579bilyi5sa6jm-thepeg-2.1.3/lib/ThePEG/setupThePEG-2.1.3
strip is /nix/store/j75dgadrff2d1fyc4fczmcgqkid2imdx-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/2rb62aaw0nwqkcpkzs579bilyi5sa6jm-thepeg-2.1.3/lib  /nix/store/2rb62aaw0nwqkcpkzs579bilyi5sa6jm-thepeg-2.1.3/bin
patching script interpreter paths in /nix/store/2rb62aaw0nwqkcpkzs579bilyi5sa6jm-thepeg-2.1.3
checking for references to /build in /nix/store/2rb62aaw0nwqkcpkzs579bilyi5sa6jm-thepeg-2.1.3...

Success on x86_64-darwin (full log)
Attempted: thepeg
Partial log (click to expand)
make[2]: Entering directory '/private/tmp/nix-build-thepeg-2.1.3.drv-0/ThePEG-2.1.3'
make[2]: Nothing to be done for 'install-exec-am'.
make[2]: Nothing to be done for 'install-data-am'.
make[2]: Leaving directory '/private/tmp/nix-build-thepeg-2.1.3.drv-0/ThePEG-2.1.3'
make[1]: Leaving directory '/private/tmp/nix-build-thepeg-2.1.3.drv-0/ThePEG-2.1.3'
post-installation fixup
strip is /nix/store/kdff2gim6417493yha769kh00n63lnrw-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/jhisxf5bq41pkqj6ndm1dvzv1igss6qk-thepeg-2.1.3/lib  /nix/store/jhisxf5bq41pkqj6ndm1dvzv1igss6qk-thepeg-2.1.3/bin
patching script interpreter paths in /nix/store/jhisxf5bq41pkqj6ndm1dvzv1igss6qk-thepeg-2.1.3
/nix/store/jhisxf5bq41pkqj6ndm1dvzv1igss6qk-thepeg-2.1.3

Failure on aarch64-linux (full log)
Attempted: thepeg
Partial log (click to expand)
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/9bvvva6z06l6acw4y2s0fvh1xvqxvp7m-graphicsmagick-imagemagick-compat-1.3.29
gzipping man pages under /nix/store/9bvvva6z06l6acw4y2s0fvh1xvqxvp7m-graphicsmagick-imagemagick-compat-1.3.29/share/man/
strip is /nix/store/jk6j4lh9v5mvjdbdc35sj0zffhhf6s56-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/9bvvva6z06l6acw4y2s0fvh1xvqxvp7m-graphicsmagick-imagemagick-compat-1.3.29/bin
patching script interpreter paths in /nix/store/9bvvva6z06l6acw4y2s0fvh1xvqxvp7m-graphicsmagick-imagemagick-compat-1.3.29
checking for references to /build in /nix/store/9bvvva6z06l6acw4y2s0fvh1xvqxvp7m-graphicsmagick-imagemagick-compat-1.3.29...
cannot build derivation '/nix/store/x85wmg620gm8c581ybiv3vvd09lnky3q-rivet-2.6.0.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/n9z0p8qa7qasmah7gbif2jp78f6qk49d-thepeg-2.1.3.drv': 2 dependencies couldn't be built
error: build of '/nix/store/n9z0p8qa7qasmah7gbif2jp78f6qk49d-thepeg-2.1.3.drv' failed

This needs to be merged together with bump to herwig 7.1.3


Bedrock

Wanted to get some feedback/thoughts on this potential addition to the model.

Idea is to establish some parameters to simulate "bedrock" in the modeled basins. This implementation introduces 3 new yaml parameters:

bedrock : a boolean that can be set to "True" to turn on the bedrock feature (default is False)
bedrock_depth : a float that sets the initial bedrock depth, new functions prevent model from eroding sediment below this depth
lithification : a boolean that can be set to "True" to do crude dynamic lithification of sediment (default is False). Basically it makes the value of bedrock_depth adjust dynamically with sea level, so if sea level rises 1m, the value of bedrock_depth is increased by 1m (e.g. if bedrock was 5m below sea level initially, it becomes 4m, "lithifying" any sediment deposited in that 1m of space that was previously reworkable)

Still need to run longer models and create some unit tests, but initial implementation doesn't add very much overhead to run times. But my general question is: Is this addition something we think would be useful to add to the pydeltarcm model?
The bedrock functionality influences the morphology as we might expect. Below is an example with a control (no bedrock) model, and a companion "shallow" bedrock model where the bedrock depth was set as the model basin depth (-5m). The original model with no limits on scouring incises a deep channel (deeper than -8m), whereas the model with bedrock is forced to develop wider channels.

Turned out to be a pretty small addition code-wise, so I am totally okay with not making this part of the core model and leaving it as a "hook" type of alternative implementation/model variant...

To do:

[x] add unit tests
[ ] some longer comparison scenarios to default case
[x] doc-strings for new functions/parameters
[ ] proper documentation about the feature

Codecov Report

Merging #116 (c699d80) into develop (dcd4f61) will decrease coverage by 2.37%.
The diff coverage is 44.44%.

@@             Coverage Diff             @@
##           develop     #116      +/-   ##
===========================================
- Coverage    80.35%   77.97%   -2.38%
===========================================
  Files           11       11
  Lines         1965     1821     -144
===========================================
- Hits          1579     1420     -159
- Misses         386      401      +15

Impacted Files
Coverage Δ

pyDeltaRCM/init_tools.py
99.38% <ø> (ø)

pyDeltaRCM/sed_tools.py
29.83% <14.28%> (-2.10%)
:arrow_down:

pyDeltaRCM/model.py
89.55% <75.00%> (-3.14%)
:arrow_down:

pyDeltaRCM/iteration_tools.py
93.30% <100.00%> (+0.03%)
:arrow_up:

pyDeltaRCM/shared_tools.py
44.82% <0.00%> (-5.18%)
:arrow_down:

pyDeltaRCM/water_tools.py
58.49% <0.00%> (-1.07%)
:arrow_down:

pyDeltaRCM/preprocessor.py
95.92% <0.00%> (-0.15%)
: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 dcd4f61...c699d80. Read the comment docs.

I think it's up to you if you want to make this part of the core model or not. I don't see any harm in it, and if it's something that people might use a lot, it should probably be in there for easy access, instead of someone having to build their own hook or new flavor.
That said, I also see the value in having a limited set of functionality in a core model, with lots of add-on variants. Your choice!

I looked through this, and the code looks fine to me, but I'm unsure whether it needs to be in the base model. I think it's a small enough addition (akin to subsidence?) that I think it's fine, but at some point we do have to encourage additions by subclassing.
To be honest, I think I'd advocate for subclassing, because it's not immediately clear to me that the need for bedrock will arise for many researchers, which I think should be the criteria for getting into the base model. It seems like a good example of a subclass to me, but I could be swayed.

I looked through this, and the code looks fine to me, but I'm unsure whether it needs to be in the base model. I think it's a small enough addition (akin to subsidence?) that I think it's fine, but at some point we do have to encourage additions by subclassing.
To be honest, I think I'd advocate for subclassing, because it's not immediately clear to me that the need for bedrock will arise for many researchers, which I think should be the criteria for getting into the base model. It seems like a good example of a subclass to me, but I could be swayed.

I looked through this, and the code looks fine to me, but I'm unsure whether it needs to be in the base model. I think it's a small enough addition (akin to subsidence?) that I think it's fine, but at some point we do have to encourage additions by subclassing.
To be honest, I think I'd advocate for subclassing, because it's not immediately clear to me that the need for bedrock will arise for many researchers, which I think should be the criteria for getting into the base model. It seems like a good example of a subclass to me, but I could be swayed.

I think we can revisit this later, but I agree, it could be a good candidate for subclassing. It does present a challenge to the typical subclass format in that this involves altering the jitted sediment routing so it could be a good example of how to subclass those routines, we will see.
I'm happy letting this just sit in the drafts for now, I am more focused on validating/checking our routing routines than trying to further complicate them at this time.

I looked through this, and the code looks fine to me, but I'm unsure whether it needs to be in the base model. I think it's a small enough addition (akin to subsidence?) that I think it's fine, but at some point we do have to encourage additions by subclassing.
To be honest, I think I'd advocate for subclassing, because it's not immediately clear to me that the need for bedrock will arise for many researchers, which I think should be the criteria for getting into the base model. It seems like a good example of a subclass to me, but I could be swayed.

I think we can revisit this later, but I agree, it could be a good candidate for subclassing. It does present a challenge to the typical subclass format in that this involves altering the jitted sediment routing so it could be a good example of how to subclass those routines, we will see.
I'm happy letting this just sit in the drafts for now, I am more focused on validating/checking our routing routines than trying to further complicate them at this time.


Status field internals documentation for creating new forms is confusing

Environment

Python version: *
Nautobot version: b4

Steps to Reproduce

Try to implement a new model w/ a status field
Go to implement a new model form by following the Status Internals documentation
Get confused because it doesn't mention that for models that inherit from nautobot.extras.models.StatusModel, you don't need to provide a form mixin.

Expected Behavior
The reader should be able to clearly understand that for base model forms. e.g. if my model is Foo, the base FooForm for create/update of an object only needs to inherit from base django.forms.ModelForm.

Observed Behavior
The instructions do not reference this explicitly. The reader seems to be directed to inherit from nautobot.extras.forms.StatusFilterFormMixin, which is incorrect and will lead to confusion.

@nautobot/core Since we are no longer implementing StatusModel in 2.0, instead preferring StatusField (https://github.com/nautobot/nautobot/pull/3785), is this still relevant?