[CT-3289] [Feature] warnings for user-inputted configs that are very similar to Real ones

Is this your first time submitting a feature request?

[X] I have read the expectations for open source contributors
[X] I have searched the existing issues, and I could not find an existing issue for this feature
[X] I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion

Describe the feature
Users can pass whatever custom configs they want. There have been issues because of this before...
https://github.com/dbt-labs/dbt-core/issues/5605
https://github.com/dbt-labs/dbt-core/issues/4280
https://github.com/dbt-labs/dbt-core/issues/2606
where folks are trying to add a Real config, but have a small typo that causes it to go undetected.
We should add a warning for supplied configs that are very similar to Real ones:

Warn on known common mistakes like:

'materialization' instead of 'materialized'
'error' instead of 'error_if'
'test' instead of 'tests'

Warn on typos of expected keys like 'materialied' instead of 'materialized'. There are fancy but easy to implement ways like "edit distance" to detect this.

(og thinking from @peterallenwebb and @jtcohen6)
Describe alternatives you've considered
No response
Who will this benefit?
No response
Are you interested in contributing this feature?
No response
Anything else?
No response

Instead, we could throw a warning anytime you supply a config that we don't actually use. (see original conversation about this)
If I have a config that dbt doesn't use:
models:
  - name: some_model
    invalid_key:
      - something
    columns:
      - name: id
        my_personal_key:
          - something_else

We should emit a warning like "my_personal_key is not recognized as a dbt config within models/columns" - probs need to wordsmith that ;)
We should provide the ability to silence this warning if it is indeed intentional, ideally for that specific instance. Similar in spirit to:

https://github.com/dbt-labs/dbt-core/issues/9644
https://github.com/dbt-labs/dbt-core/issues/9164

We could suggest what they may have intended to type "did you mean materialized instead of materialied?" if we wanna get fancy with it.

+1 to this from Jenna

+1 from me as well.
I literally spent hours recently debugging why incrementalisation doesn't work properly on one model, only to find out I typed unqiue_key in the config.
In the meantime, what's the best practice to guard against such errors?

dbt_project.yml isn't called out here, but it should be included too I think! cf https://github.com/dbt-labs/dbt-jsonschema/issues/179


haskellPackages.doctest-discover: Disable tests

Motivation for this change
The source package is missing a required file. See:

https://github.com/karun012/doctest-discover/issues/22
https://github.com/karun012/doctest-discover/issues/23

Things done

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

[ ] NixOS
[ ] macOS
[X] other Linux distributions

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

Process question: How do we remind ourselves to remove this again once upstream has patched the problem?

I'm subscribed to both upstream bugs, so I can revert this.

doctest-discover-<IP_ADDRESS> has hit hackage, so if we get a hackage snapshot update before this merges, it becomes redundant.

I note that doctest-discover is currently pinned in configuration-hackage2nix.yaml, so I guess we have to wait for stackage to update, then update nixpkgs to pick this up?

Note that doctest-discover_0_2_0_0 is already in haskell-updates.

That's handy, but this package is still unbuildable. It's a bit silly to offer it.

@endgame I did move the override from configuration-nix.nix to configuration-common.nix because the former is only for fixing build failures due to Nix. Also see the documentation on the top of that file.

@basvandijk Thank you. Should the blank-canvas fixes move across too, then? (They require a browser and do not run automatically.) If so, I will prepare another PR.

@endgame yes I think the blank-canvas overrides should move as well.


A typescipt error was detected during the build.

I detected the following typescipt error during the build.
\node_modules\javascript-obfuscator\src\utils\Utils.ts(24,53)
  **TS2345: Argument of type 'string | undefined' is not assignable to parameter of type 'string'.

Type 'undefined' is not assignable to type 'string'.**
Expected Behavior

Be able to build
Current Behavior

An error has occurred.
Steps to Reproduce

1.　Using webpack-obfuscator in webpack
Your Environment

Obfuscator version used:
The version I'm using is as follows

<EMAIL_ADDRESS>└──<EMAIL_ADDRESS>
Node version used:
node -v
v14.17.0

Minimal working example that will help to reproduce issue

I have modified the source as follows to avoid the error.
public static buildVersionMessage(version?: string, buildTimestamp?: string): string {
        const isUnknownVersion = !version || !buildTimestamp;

        if (isUnknownVersion || buildTimestamp === undefined) {
            return 'unknown';
        }

        const buildDate: string = new Date(parseInt(buildTimestamp, 10)).toISOString();

        return `${version}_${buildDate}`;
    }

Hi. Please update your dependencies. Current master version uses<EMAIL_ADDRESS>and compiles it without errors.


Enable the util crate's include-exclude feature when necessary

This fixes the issues seen when using the v2 cargo feature resolver.
Fixes https://github.com/pyros2097/rust-embed/issues/150
See https://github.com/pyros2097/rust-embed/issues/150#issuecomment-909832104 for an explanation.

LGTM. Thanks @AzureMarker .


Hash key ending in = needs a hashrocket

Fix for bug introduced by 89e5eb317eb97ea6ff2a06bc797e8a7f6e52b234.
For example when creating stubs or mocks, sometimes we have a hash key that ends with the equals sign:
let(:foo) { double("Foo", set?: true, :changes= => true) }

Changing the :changes= to use 1.9 hash syntax raises a
"SyntaxError: unexpected ':'"

Coverage decreased (-0.0%) to 99.65% when pulling 6d3c0ca012da4b3c3af726ee4ec41b6a87fcd924 on bquorning:hash-keys-ending-in-= into c80ab2be9fc3b8c50427568484098a4998297c3f on bbatsov:master.

:+1: This will do for now.


changed clippy appearance time to half a minute :)

:D no one ever hovers there for 2 minutes XD

Can you squash please?

Squashed :)


tk-38 / Add Compass icon to nav bar

add this  icon to navbar before the currency compass text on the left hand side

https://icons.getbootstrap.com/icons/compass/


Split DeviceRequestPrompt class

Get the DeviceRequestPrompt class ready for the bidi protocol

Class doesn't have a base class


Fix some issues on Windows with removed context filenames

This makes some fixes to https://github.com/sourcegraph/cody/pull/2653 for Windows where the paths were appearing incorrectly (wrong slash direction, or not detected as part of the workspace so showing as absolute paths).
This PR is targetting @sqs rm-filename branch since it's fixed to unmerged changes.
Test plan

Run pnpm test:e2e on Windows and verify all is green

Thanks!

will merge then incorporate into my branch


Package name conflict

Hi,
I try to use both "spring.xsuaa" and "token.client" with a project using java  9 modules.
I ran into the following issue:

java: module entities reads package com.sap.cloud.security.xsuaa from both spring.xsuaa and token.client

It is because the two modules define the same package.
Do you provide modules which work with this java feature? For example be combining the classes into into one module?
Do you plan to disentangle you package structure?
Many thanks, Holger

Hi Holger, at the moment, there are no plans to add module support to this lib, sorry.
Closing this as Github Issue section is no longer maintained.


Ignore exception thrown when no SAML2Client is present

Howdy, any activity on this to make sure we can merge? have you had a chance to review build failures?


fixkeep cast operator if cast a varchar to another longer varchar in LogicalSetOperator

Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

run buildall

谢谢您的来信，您的邮件已收到！


Fix typo

Why:
Because « authorizing a GiHub » is confusing.

What's being changed (if available, include any code snippets, screenshots, or gifs):
A variable, that was not the most accurate one for the context.
Check off the following:

[x] I have reviewed my changes in staging, available via the View deployment link in this PR's timeline.

For content changes, you will also see an automatically generated comment with links directly to pages you've modified. The comment won't appear if your PR only edits files in the data directory.

[x] For content changes, I have completed the self-review checklist.

@ledoyen Thanks so much for submitting a PR! I'll get this triaged for review :zap:


v2.7.0

Release Notes
2.7.0
Features

Added a script to make galleries out of kings, opponent kings, etc.
Added a config option for entering the URLs of the those galleries and to use that link if it exists instead of outputting all the names in twitch.
!accept now returns a reason for not accepting a user into the team.
Rejecting users from !accept when puzzle rating is > 1000 over their max game rating or if their account is less than 30 days old.

Bug Fixes

Fixed a bug with adding @ in a user's name with !shoutout command.
Fixed an issue where the Spotify service now also returns 200 when a song is found.

Rejecting users from !accept when puzzle rating is > 1000 over their max game rating or if their account is less than 30 days old.

Users who spend considerable time working on puzzles may naturally have a significantly higher puzzle rating than their regular game rating. This discrepancy does not necessarily indicate any malicious intent or attempt to manipulate the system. Therefore, I request the  to reconsider this rule (or set it higher). because it inadvertently affect users who are actively working on puzzles.
In my case, I play chess puzzles every day, mostly unrated, and sometimes I play rated games. When I feel confident and come across a puzzle that piques my interest, I focus my full attention on solving it.
So my puzzle rating is 2243, while my (not old) chess 960 rating is 1354. This discrepancy does not necessarily indicate any malicious intent or attempt to manipulate the system, but rather demonstrates the time and effort invested in solving puzzles. Thanks.


Add FAQ section

I've added a FAQ section. Also I know someone else was working on an FAQ as well (i guess I beat them to it).
I added a direct link to the stable releases for the lazy people in the downloads section.
The only issue I'm having is the pink waves overlapping the box (screenshot of that below) but I tried using  position:relative; z-index: 100; and I think it only made a little difference (oh well). It would be way worse on mobile, but the rest of the pages are just as botched.

BTW VSCode did the formatting, I didn't myself.

Looks like a good base. I'll edit it a bit and get it merged when possible. It might be a little while though as due to IRL circumstances though, sadly.

Good work, thanks for your patience


[Question] Vue: How to get/set language outside of a component, e.g. from a vuex store action ?

Thanks

I'm afraid thats not really possible and not even intended. Depends how you work with the store, however either you can store the language in the store and force Tolgee to use the same one. Or leave the language up to Tolgee and work with it only outside the store as store actions should be pure. We generally don't want to expose Tolgee instance globally as that might be limiting for the future.


add opensuse-15.2 and opensuse_tumbleweed

:)

Now I should be done here.

So far, tested on:
* opensuse 15.2: works (after updating running requirements in [cbe02bf](https://github.com/dianagudu/motley_cue/commit/cbe02bfa21b078af2cb838109f339fbad3a49440))

* opensuse tumbleweed: python links not fully adjusted:

  * on install: `Package was packed for python3.8 adjusting symlinks for installed python3.7`
  * lib folder link adjusted: `/usr/lib/motley-cue/lib/python3.7 -> /usr/lib/motley-cue/lib/python3.8`
  * however, python executable still points to different version not present on the system:
    ` /usr/lib/motley-cue/bin/python -> /usr/bin/python3.8`

Strange. This is how it looks for me:
root@susetw:~# rpm -i motley-cue-0.1.1-1.x86_64.rpm
For loop: PYTHONDIR: python3.8
PKG_PYTHONDIR: python3.8
/var/tmp/rpm-tmp.nqqr2h: line 35: semodule: command not found
/var/tmp/rpm-tmp.nqqr2h: line 36: semodule: command not found
/var/tmp/rpm-tmp.nqqr2h: line 37: semodule: command not found
/var/tmp/rpm-tmp.nqqr2h: line 38: setsebool: command not found
Created symlink /etc/systemd/system/multi-user.target.wants/motley-cue.service → /lib/systemd/system/motley-cue.service.
Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service → /usr/lib/systemd/system/nginx.service.
root@susetw:~# cd /usr/lib/motley-cue/lib
root@susetw:/usr/lib/motley-cue/lib# ls
python3.8/
root@susetw:/usr/lib/motley-cue/lib# cd ../bin/
root@susetw:/usr/lib/motley-cue/bin# ls -l python*
lrwxrwxrwx 1 root root 18 May 12 13:57 python -> /usr/bin/python3.8*
lrwxrwxrwx 1 root root  6 May 12 13:57 python3 -> python*
lrwxrwxrwx 1 root root  6 May 12 13:57 python3.8 -> python*

I.e. I'll have to remove the selinux commands and then should be fine.

Please retry with this rpm:
http://marcus.hardt-it.de/motley-cue-0.1.1-1.x86_64.rpm

It works now. It was actually an issue with the image I used for the VM and not properly updating via zypper dup, so my python version was 3.7.

Ok; So this one can be merged.
I got comments on pam-ssh-oidc that I'll fix.
RPM build will see fundamental changes, but I'll develop them on pam-ssh-oidc first


Section docs use old webpack version

"webpack": "^1.11.0",

The latest stable release of webpack is 1.12.9. Why do you say we are not up to date?

The latest stable release of webpack is 1.12.9. Why do you say we are not up to date?


Add 🪸 to committers

Purpose / why
Adding myself as a committer.
Verification
I'm in the table
Interested Parties

@Islandora/documentation
@Islandora/committers

Checklist
Pull-request Reviewer
Pull-request reviewer should ensure the following:

[ ] Does this PR link to related issues?
[ ] Does the proposed documentation align with the Islandora Documentation Style Guide?
[ ] Are the changes accurate, useful, free of typos, etc?

Person Merging
The person merging should ensure the following:

[ ] Does mkdocs still build successfully? (This is indicated by TravisCI passing. To test locally, and see warnings, see How To Build Documentation.)
[ ] If pages are renamed or removed, have all internal links to those pages been fixed?
[ ] If pages are added, have they been linked to or placed in the menu?
[ ] Did the PR receive at least one approval from a committer, and all issues raised have been addressed?

Per tradition, new committers commit themselves in. Since we dropped the ball on making this PR, @joecorall we invite you break the don't-merge-your-own PR rule, and click the green button here. -Tech Call


Add demo site to repo about

It would be easier to find the link to the demo if it was displayed in the repo about part, like this:

@alshedivat you are the only one with permission for this.

done


support inverse relationship

Let's say we have: a User has many Comments -> to model this we will create a relation column named client on the Comment table, this is good but we want to fetch each user with their comments.
Currently, we can declare the inverse relation by creating a relation column of type many named comments on the User table then we set its value to an array of comments, this is good as a workaround but it's not ideal
An ideal solution could be to introduce a new relation called Inverse other than Single and Many, to declare a column of this relation type we specify the target table and a column, an inverse relation should be auto-calculated when a record is created on the other side and it should not be updated manually

Please check https://pocketbase.io/docs/expanding-relations/#indirect-expand.
?filter and ?sort support for indirect relations is already in the roadmap.

that is great! except I don't know why using comments(post) instead of just comments in the results?

Because you can have more than one reference to the collection.

Okay that makes sense to me


Update usage.mdx

import 'package:firebase_messaging/firebase_messaging.dart';
is the correct import ant clould_messaging
Description
Replace this paragraph with a description of what this PR is doing. If you're modifying existing behavior, describe the existing behavior, how this PR is changing it, and what motivated the change.
Related Issues
Replace this paragraph with a list of issues related to this PR from the issue database. Indicate, which of these issues are resolved or fixed by this PR. Note that you'll have to prefix the issue numbers with flutter/flutter#.
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]).
This will ensure a smooth and quick review process. Updating the pubspec.yaml and changelogs is not required.

[ ] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[ ] My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
[ ] All existing and new tests are passing.
[ ] I updated/added relevant documentation (doc comments with ///).
[ ] The analyzer (flutter analyze) does not report any problems on my PR.
[ ] I read and followed the Flutter Style Guide.
[ ] I signed the CLA.
[ ] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
[ ] No, this is not a breaking change.

This is no longer required and the latest version is already up to date. I'm going to go ahead and close this PR. Thanks for sending it up though.


Fix Build issue hopefully

lol stop creating multiple pull requests

haha yeah didn't mean to do that 👍


[Messages] Don't turn on the screen after unread timeout expires

Closes #1873

I didn't add an option for this because I think it is wrong that the screen turns on when the unread timeout expires but I'm open to discussion :-)

Yes! This has been bugging me without even realising!

Thanks!


Change bedrock hammer to have steel handle

Just a texture suggestion: the bedrock hammer is crafted with shaft units instead of sticks but has a wood handle on the texture. Could you change it to be a steel handle?

Yeah that makes sense, I made the texture before looking into the item itself. Will do tomorrow.


Not possible to obtain access token (PAC) for authenticated context, unsupported operation

We need to obtain detailed security information about authenticated user via GSSAPI.
As the part of NETLOGON_VALIDATION_SAM_INFO4 structure (response to NETLOGON_NETWORK_INFO from DC, part of processing AUTHENTICATE_MESSAGE from client by server, see [MS-APDS], "4.1 NTLM Pass-Through Authentication" for example) all the details of authenticated user are delivered to server. We need this from server side (after a call to gss_accept_sec_context) to identify the user (userSID, SIDs of all groups, etc).
It seems like gssntlmssp library doesn't have this option yet ("The operation or option is not
available or unsupported" is returned for gss_get_name_attribute for example). Can we add it as a new feature?
Possible ways to inquire this information from the context via GSSAPI are:

gss_get_name_attribute with "urn:mspac:" name (also can get sub-parts, like "urn:mspac:logon-info")

gss_inquire_sec_context_by_oid with EXTRACT_PAC_AUTHZ_DATA_FROM_SEC_CONTEXT_OID

See gssapi_pac.c code of samba for usage example: https://github.com/encukou/samba/blob/master/auth/kerberos/gssapi_pac.c
Also opencifs LsaMapSecurityGetPacInfoFromGssContext here: https://github.com/BeyondTrust/pbis-open/blob/master/lsass/interop/lwmapsecurity/lwmapsecurity-lsass.c

The only problem I see in using things like EXTRACT_PAC_AUTHZ_DATA_FROM_SEC_CONTEXT_OID is that we do not get a MS-PAC from a NTLM negotiation.
The MS-PAC is attached to a kerberos ticket by the KDC and that's why GSSAPI/Krb5 can offer it.
In most cases that info is synthesizes on Windows via a number side calls to the LSASS subsystem and RPCs to a Windows DC (for non local accounts).
I would be open to add interfaces to pull that information out when gssntlmssp is used in conjunction to Winbindd on a samba managed machine though.
Se the current Winbindd backend as an example of how to interface there.

Yes, you are right, MS-PAC is slightly different than NETLOGON_VALIDATION_SAM_INFO4 structure and reporting proper PAC requires additional data collecting. So I agree - let's use winbindd API to get what we can and provide some interface to inquire it via GSSAPI.
I see that winbind_srv_auth() already makes request and gets wbcAuthUserInfo data structure with list of SIDs - this is actually what we need to receive. So we don't even need additional requests for that...
I have reused the concept of handling session key in this flow and added list of ntlm_raw_sid into gss context. Also I think that gss_inquire_sec_context_by_oid can be used to request custom buffer from gssntlmssp (added private OID to header).
I tried to push my new branch but probably I miss write permissions (Error: Permission to gssapi/gss-ntlmssp.git denied to kvv81). So please see my patch (for master) here:
get_sids.patch.gz
Items that can be improved:

We can take into account that each SID is variable-size structure and store only used bytes (8+4*sub_authority_count), not all 68. This will reduce memory consumption.
We can allocate sids buffer in gsstlm context dynamically, not statically with pre-defined maximum size (additional code for cleanup will be needed)

Please clone the repository, push in your clone, and then open a PR from there.
I definitely do not want to add fixed size structures, but I really need to see what you propose first.

Fixed by PR #36


circleRating and date added

#391  Rating and Date
I am adding circlerating with different color  and date of movie in carousels card.
Closes: #391
Description of Changes
CircleRating of movie shows the average of the movie.
For example:
Checklist:

[x] My code adheres to the established style guidelines of this project.
[x] I have conducted a self-review of my code.
[x] I have included comments in areas that may be difficult to understand.
[x] I have made corresponding updates to the project documentation.
[x] My changes have not introduced any new warnings.

Screenshots

Original
Updated

Please provide any necessary screenshots to illustrate the changes made.

@sourabhsikarwar please authorized PR I am creating new PR .

@BhartiNagpure It is having merge conflict. kindly resolve

@sourabhsikarwar resolve conflicts review it.


 However, this means that every time I deploy to my S3 bucket, I need to invalidate objects in CloudFront. This pull request automates that process.

This looks excellent, thank you!

@spenczar: I've moved the code into a invalidate_cloudfront() method, as you suggested. Thanks for the feedback!
Here's the documentation for CloudFront invalidation, and here's the documentation for CloudFront pricing. The established best practice (as far as I'm aware) is to not bother invalidating deleted objects from CloudFront, because AWS doesn't charge for keeping objects in CloudFront, only for accessing them -- and it does charge for doing object invalidation (after the first 1000 objects per month). Therefore, it's cheaper to make things immutable -- once an object goes into CloudFront, it's never modified, and updated versions are put into CloudFront with a new URL.
Does that make sense?

While that makes sense from a cost-management perspective at large scale, I don't think it's the right policy with Lektor-based projects. If someone deletes a blog post and then calls lektor publish, I think they expect their blog post to disappear from the internet ASAP.
I guess we'll do a tiny bit of wasted work for people who are removing (say) static assets like images or javascript or stylesheets. But the expected workflow with Lektor is a static site whose assets probably don't get deleted super often. If someone is deleting thousands of objects per month, I think they are the exceptional case, and even then we've only cost them a relatively small amount - we're not going to be accidentally charging people a thousand bucks or anything.
Let's just invalidate everything in the diff set, including deleted objects. I think this is least likely to surprise people.

@spenczar: Would it make more sense to just invalidate everything on every deploy, then? Especially since I just found this in the documentation:

The charge to submit an invalidation path is the same regardless of the number of objects you're invalidating: a single object (/images/logo.jpg) or all of the objects that are associated with a distribution (/*). For more information, see Amazon CloudFront Pricing.

We just just invalidate /* on every deploy, which is easy and cheap. If the developer doesn't want that to happen, then can just not put their CloudFront distribution ID in the .lektorproject

Oh, I think that sounds good. It's way simpler, which is great. One note: it should be /{self.key_prefix}* because the developer might have things under a key prefix in their bucket.

@spenczar: Got it -- I've updated the code again. As an aside, I don't know anything about key prefixes, and I don't see anything about that in the README. Can you double-check that I'm doing it right?

Looks great! Yeah, key prefixes should be documented, I'll add that in another commit.
Thanks for this!


test compilation failure on FreeBSD 12+

on FreeBSD-12 with clang 8.0.1 (and their ld), I get:
ld -nostdlib -z max-page-size=0x1000 -static  -T /usr/home/hannes/.opam/4.09.0/.opam-switch/build/solo5-bindings-hvt.0.6.2/bindings/hvt/solo5_hvt.lds /usr/home/hannes/.opam/4.09.0/.opam-switch/build/solo5-bindings-hvt.0.6.2/bindings/hvt/solo5_hvt.o test_tls.o manifest.o -o test_tls.hvt
ld: error: test_tls.o has an STT_TLS symbol but doesn't have an SHF_TLS section

when attempting to link test_tls
and it looks the "opam install" always triggers a testbuild...
this is a workaround which disables test_tls on FreeBSD

I'll look into it. Must be something that changed in between clang 8.0.0 -> 8.0.1 or 11.3-RELEASE -> 12 as I just updated the FreeBSD CI templates to 11.3-RELEASE and clang 8.0.0, and don't see this problem there.

@hannesm:
What FreeBSD version are you referring to here, exactly? A freshly upgraded 11.3-RELEASE has clang 8.0.0, and a freshly upgraded 12.0-RELEASE has clang 6.0.0. If you are referring to something that's in current, then I can't test that as it's a moving target.

I use these days the stable/12 branch of FreeBSD (FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on LLVM 8.0.1)), the same (8.0.1) was merged into releng/12.1, so it'll be included in the 12.1 release (according to the roadmap rc1 was just built -- and it is available on ftp.freebsd.org (below the beta3 images)).
I don't understand enough bats magic, but would propose to just disable the TLS test on FreeBSD (since there aren't any users thereof afaik).

I don't want to disable tests without having at least some idea about what is actually causing the problem. Will wait for 12.1-RELEASE to come out and then come back to this.

as an update here, FreeBSD 12.1 is now released

Superseded by #436.


User-friendly Documentation on Sagemaker Instances and Service Limit Increase

Lately running into too many Sagemaker issues. Is there any unambiguous documentation on Sagemakers Instances? I could glean the following from different sources:

Sagemaker Instances, Sagemaker being a managed service, have nothing to do with EC2 instances.

Unlike EC2 console, Sagemaker console has no option to view limits or increase limits. One has to go directly to the support page and select instance limit increase and pick Sagemaker as the service. But must one run into Resource Limit Exceeded errors before to find out instance limits?

Sagemaler notebook instances are different from the training, deployment instances.

Not every algorithm in Sagemaker supports every(training/deployment) instance type. It doesn't make sense for XGboost to be GPU accelerated.

I wonder if all of this is documented anywhere at all, in simple language. It'd be immensely helpful to have it included in a one-page document that shown up prominently to users of Sagemaker, at least new ones.

Thank you for your feedback.
You can find the default service quotas (aka limits) for any AWS Service including Amazon SageMaker on AWS Service Quotas page. Follow the instructions on the page to navigate to SageMaker default quotas page.  You can also discover this documentation from Amazon SageMaker Developer Guide. Visit the Supported Regions and Quotas page for details.
Regarding instance types supported for each algorithm, you can find this information for each built-in algorithm in SageMaker Developer Guide.
Hope this is helpful.


Self Hosted ntfy Server with Basic Auth (via Nginx Reverse Proxy) not supported via Mobile App

:lady_beetle: Describe the bug
I could be doing something wrong I'm sure, but I've got a ntfy deployed on my home server and it works great because I've set up the Nginx basic auth to not be applied from requests from my local network.
However when I leave my home and my IP is now one from a nearby tower (or any external one), basic auth doesn't appear to work correctly using the mobile app, but I can easily point to my hosted service through the browser and authenticate without any issue (so configuration wise, i feel as though i'm good).
I was hoping the logic would simply be<EMAIL_ADDRESS>
But this just turns into a Reconnecting... setup until i return back into my local network.

How can the mobile app recognize Basic Auth?
:computer: Components impacted
Android App
:bulb: Screenshots and/or logs
Screenshots shown above
:crystal_ball: Additional context
n/a

Just my two cents:
AFAIK for HTTP-Basic-Auth the credentials go in a separate menu, this should be similar to this screenshot:

Please also note, that the endpoint "/file/" must not have HTTP-basic-auth enforced by the reverse-proxy: https://github.com/binwiederhier/ntfy/issues/893#issuecomment-1731314679

Thanks for your post, unfortunately That didn't work. 😔
I would additionally upgrade this bug to include http-auth for files too then. Exposing ntfy to the internet with file upload access wide open is not ideal under any circumstance.

I add the server.yml and the haproxy.conf config i am using. In my setup it works well and indeed blocks/redirects unauthenticated users. The /file/ endpoint is not used for uploading, just for downloading AFAIK and the filename is changed to same random string which serves the same purpose as a token or additional Authentication: header.
In addition i also configured the same user in NTFY, so both (Reverse-Proxy and also in addition NTFY) check if the user is valid.
HTH
haproxy.conf
########################################################################
#
# Configuration file for HAProxy in front of NTFY
#
# Docu:
#  https://www.haproxy.com/documentation/hapee/latest/onepage/
#  https://www.haproxy.com/blog/websockets-load-balancing-with-haproxy
#  https://delta.blue/blog/haproxy-timeouts/
#  https://www.haproxy.com/documentation/haproxy-configuration-tutorials/authentication/basic-authentication/
#  https://www.haproxy.com/documentation/haproxy-configuration-tutorials/client-ip-preservation/add-x-forward-for-header/
#
# Testing the config:
#  haproxy -f /etc/haproxy/haproxy.cfg -d
# Restarting the service:
#  service haproxy restart
########################################################################

global
	maxconn 100
	user nobody
	group nogroup
	daemon
	nosplice

#default settings:
defaults
	mode http
	timeout connect 1s
	timeout client 60s
	timeout http-request 10s
	timeout http-keep-alive 10s
	timeout server 60s
	timeout server-fin 10s
	timeout tunnel 120s
	timeout client-fin 10s
	retries 2

# List of username and passwords we accept:
#  Plaintext Passwords: user myUsername insecure-password myPassword
#  Hash only with mkpasswd from packet "whois":
#   - Generate: mkpasswd -m sha-256 myPassword
#   - Add entry: user myUsername password myPasswordHashFromAbove
userlist mycredentials
	user Torxgewinde password $HASH_abcdefghijklmnopqrstuvwxyz_HASH$

# TCP frontend with TLS/SSL
frontend frontend_ntfy_proxy
	#
	# create combined_certs with this command:
	# cat server-cert.pem server-key.pem > combined_certs
	#
	bind [::]:443,:443 ssl crt /etc/haproxy/example.quicksrv.de.combined ssl-min-ver TLSv1.3

	# add header X-Forwarded-For:
	# This is needed or otherwise to NTFY all interactions count as a single interaction
	option forwardfor

	# try to push everything to https/wss encrypted connections:
	http-request redirect scheme https unless { ssl_fc }
	http-request redirect code 301 location https://%[hdr(host)]%[capture.req.uri] unless { ssl_fc }
	http-request deny unless { ssl_fc }

	# Everything must be authenticated except for /file/ endpoint
	# See: https://github.com/binwiederhier/ntfy/issues/893#issuecomment-1731314679
	http-request auth unless { http_auth(mycredentials) } or { path_beg /file/ }

	#is it a websocket?
	acl for_websocket hdr(Upgrade) -i websocket
	acl for_websocket hdr(Connection) -i upgrade
	use_backend backend_ntfy_ws if for_websocket

	#everything else is handled as HTTP request
	default_backend backend_ntfy_http

# Default backend to contact NTFY
backend backend_ntfy_http
	#add header to signal which backend handled the request
	http-response set-header X-Torxgewinde "backend_ntfy_http"

	#forward request to this server, this is where FHEMWEB listens
	server NTFY_SERVER_HTTP <IP_ADDRESS>:8080

# NTFY websocket backend
backend backend_ntfy_ws
	#add header to signal which backend handled the request
	http-response set-header X-Torxgewinde "backend_ntfy_ws"

	#reject/deny if the following checks do not match
	acl hdr_connection_upgrade hdr(Connection) -i upgrade
	acl hdr_upgrade_websocket hdr(Upgrade) -i websocket
	acl hdr_websocket_key hdr_cnt(Sec-WebSocket-Key) eq 1
	acl hdr_websocket_version hdr_cnt(Sec-WebSocket-Version) eq 1
	http-request deny if !hdr_connection_upgrade !hdr_upgrade_websocket !hdr_websocket_key !hdr_websocket_version

	server NTFY_SERVER_WS <IP_ADDRESS>:8080

# ntfy server config file
#
# Please refer to the documentation at https://ntfy.sh/docs/config/ for details.
# All options also support underscores (_) instead of dashes (-) to comply with the YAML spec.

# Public facing base URL of the service (e.g. https://ntfy.sh or https://ntfy.example.com)
#
# This setting is required for any of the following features:
# - attachments (to return a download URL)
# - e-mail sending (for the topic URL in the email footer)
# - iOS push notifications for self-hosted servers (to calculate the Firebase poll_request topic)
# - Matrix Push Gateway (to validate that the pushkey is correct)
#
base-url: "https://example.quicksrv.de"

# Listen address for the HTTP & HTTPS web server. If "listen-https" is set, you must also
# set "key-file" and "cert-file". Format: [<ip>]:<port>, e.g. "<IP_ADDRESS>:8080".
#
# To listen on all interfaces, you may omit the IP address, e.g. ":443".
# To disable HTTP, set "listen-http" to "-".
#
listen-http: "<IP_ADDRESS>:8080"
# listen-https:

# Listen on a Unix socket, e.g. /var/lib/ntfy/ntfy.sock
# This can be useful to avoid port issues on local systems, and to simplify permissions.
#
# listen-unix: <socket-path>
# listen-unix-mode: <linux permissions, e.g. 0700>

# Path to the private key & cert file for the HTTPS web server. Not used if "listen-https" is not set.
#
# key-file: <filename>
# cert-file: <filename>

# If set, also publish messages to a Firebase Cloud Messaging (FCM) topic for your app.
# This is optional and only required to save battery when using the Android app.
#
# firebase-key-file: <filename>

# If "cache-file" is set, messages are cached in a local SQLite database instead of only in-memory.
# This allows for service restarts without losing messages in support of the since= parameter.
#
# The "cache-duration" parameter defines the duration for which messages will be buffered
# before they are deleted. This is required to support the "since=..." and "poll=1" parameter.
# To disable the cache entirely (on-disk/in-memory), set "cache-duration" to 0.
# The cache file is created automatically, provided that the correct permissions are set.
#
# The "cache-startup-queries" parameter allows you to run commands when the database is initialized,
# e.g. to enable WAL mode (see https://phiresky.github.io/blog/2020/sqlite-performance-tuning/)).
# Example:
#    cache-startup-queries: |
#       pragma journal_mode = WAL;
#       pragma synchronous = normal;
#       pragma temp_store = memory;
#       pragma busy_timeout = 15000;
#       vacuum;
#
# The "cache-batch-size" and "cache-batch-timeout" parameter allow enabling async batch writing
# of messages. If set, messages will be queued and written to the database in batches of the given
# size, or after the given timeout. This is only required for high volume servers.
#
# Debian/RPM package users:
#   Use /var/cache/ntfy/cache.db as cache file to avoid permission issues. The package
#   creates this folder for you.
#
# Check your permissions:
#   If you are running ntfy with systemd, make sure this cache file is owned by the
#   ntfy user and group by running: chown ntfy.ntfy <filename>.
#
cache-file: "/var/cache/ntfy/cache.db"
cache-duration: "720h"
# cache-startup-queries:
# cache-batch-size: 0
# cache-batch-timeout: "0ms"

# If set, access to the ntfy server and API can be controlled on a granular level using
# the 'ntfy user' and 'ntfy access' commands. See the --help pages for details, or check the docs.
#
# - auth-file is the SQLite user/access database; it is created automatically if it doesn't already exist
# - auth-default-access defines the default/fallback access if no access control entry is found; it can be
#   set to "read-write" (default), "read-only", "write-only" or "deny-all".
# - auth-startup-queries allows you to run commands when the database is initialized, e.g. to enable
#   WAL mode. This is similar to cache-startup-queries. See above for details.
#
# Debian/RPM package users:
#   Use /var/lib/ntfy/user.db as user database to avoid permission issues. The package
#   creates this folder for you.
#
# Check your permissions:
#   If you are running ntfy with systemd, make sure this user database file is owned by the
#   ntfy user and group by running: chown ntfy.ntfy <filename>.
#
# auth-file: <filename>
# auth-default-access: "read-write"
# auth-startup-queries:
auth-file: "/var/lib/ntfy/user.db"
auth-default-access: "deny-all"

# If set, the X-Forwarded-For header is used to determine the visitor IP address
# instead of the remote address of the connection.
#
# WARNING: If you are behind a proxy, you must set this, otherwise all visitors are rate limited
#          as if they are one.
#
behind-proxy: true

# If enabled, clients can attach files to notifications as attachments. Minimum settings to enable attachments
# are "attachment-cache-dir" and "base-url".
#
# - attachment-cache-dir is the cache directory for attached files
# - attachment-total-size-limit is the limit of the on-disk attachment cache directory (total size)
# - attachment-file-size-limit is the per-file attachment size limit (e.g. 300k, 2M, 100M)
# - attachment-expiry-duration is the duration after which uploaded attachments will be deleted (e.g. 3h, 20h)
#
attachment-cache-dir: "/var/cache/ntfy/attachments"
attachment-total-size-limit: "10G"
attachment-file-size-limit: "1G"
attachment-expiry-duration: "720h"

# If enabled, allow outgoing e-mail notifications via the 'X-Email' header. If this header is set,
# messages will additionally be sent out as e-mail using an external SMTP server.
#
# As of today, only SMTP servers with plain text auth (or no auth at all), and STARTLS are supported.
# Please also refer to the rate limiting settings below (visitor-email-limit-burst & visitor-email-limit-burst).
#
# - smtp-sender-addr is the hostname:port of the SMTP server
# - smtp-sender-from is the e-mail address of the sender
# - smtp-sender-user/smtp-sender-pass are the username and password of the SMTP user (leave blank for no auth)
#
# smtp-sender-addr:
# smtp-sender-from:
# smtp-sender-user:
# smtp-sender-pass:

# If enabled, ntfy will launch a lightweight SMTP server for incoming messages. Once configured, users can send
# emails to a topic e-mail address to publish messages to a topic.
#
# - smtp-server-listen defines the IP address and port the SMTP server will listen on, e.g. :25 or <IP_ADDRESS>:25
# - smtp-server-domain is the e-mail domain, e.g. ntfy.sh
# - smtp-server-addr-prefix is an optional prefix for the e-mail addresses to prevent spam. If set to "ntfy-",
#   for instance, only e-mails to<EMAIL_ADDRESS>will be accepted. If this is not set, all emails to
#<EMAIL_ADDRESS>will be accepted (which may obviously be a spam problem).
#
# smtp-server-listen:
# smtp-server-domain:
# smtp-server-addr-prefix:

# Web Push support (background notifications for browsers)
#
# If enabled, allows ntfy to receive push notifications, even when the ntfy web app is closed. When enabled, users
# can enable background notifications in the web app. Once enabled, ntfy will forward published messages to the push
# endpoint, which will then forward it to the browser.
#
# You must configure web-push-public/private key, web-push-file, and web-push-email-address below to enable Web Push.
# Run "ntfy webpush keys" to generate the keys.
#
# - web-push-public-key is the generated VAPID public key, e.g. AA1234BBCCddvveekaabcdfqwertyuiopasdfghjklzxcvbnm1234567890
# - web-push-private-key is the generated VAPID private key, e.g. AA2BB1234567890abcdefzxcvbnm1234567890
# - web-push-file is a database file to keep track of browser subscription endpoints, e.g. `/var/cache/ntfy/webpush.db`
# - web-push-email-address is the admin email address send to the push provider, e.g<EMAIL_ADDRESS># - web-push-startup-queries is an optional list of queries to run on startup`
#
# web-push-public-key:
# web-push-private-key:
# web-push-file:
# web-push-email-address:
# web-push-startup-queries:

# If enabled, ntfy can perform voice calls via Twilio via the "X-Call" header.
#
# - twilio-account is the Twilio account SID, e.g. AC12345beefbeef67890beefbeef122586
# - twilio-auth-token is the Twilio auth token, e.g. affebeef258625862586258625862586
# - twilio-phone-number is the outgoing phone number you purchased, e.g. +18775132586
# - twilio-verify-service is the Twilio Verify service SID, e.g. VA12345beefbeef67890beefbeef122586
#
# twilio-account:
# twilio-auth-token:
# twilio-phone-number:
# twilio-verify-service:

# Interval in which keepalive messages are sent to the client. This is to prevent
# intermediaries closing the connection for inactivity.
#
# Note that the Android app has a hardcoded timeout at 77s, so it should be less than that.
#
# keepalive-interval: "45s"

# Interval in which the manager prunes old messages, deletes topics
# and prints the stats.
#
# manager-interval: "1m"

# Defines topic names that are not allowed, because they are otherwise used. There are a few default topics
# that cannot be used (e.g. app, account, settings, ...). To extend the default list, define them here.
#
# Example:
#   disallowed-topics:
#     - about
#     - pricing
#     - contact
#
# disallowed-topics:

# Defines the root path of the web app, or disables the web app entirely.
#
# Can be any simple path, e.g. "/", "/app", or "/ntfy". For backwards-compatibility reasons,
# the values "app" (maps to "/"), "home" (maps to "/app"), or "disable" (maps to "") to disable
# the web app entirely.
#
#web-root: "/"
web-root: disable

# Various feature flags used to control the web app, and API access, mainly around user and
# account management.
#
# - enable-signup allows users to sign up via the web app, or API
# - enable-login allows users to log in via the web app, or API
# - enable-reservations allows users to reserve topics (if their tier allows it)
#
enable-signup: false
enable-login: false
# enable-reservations: false

# Server URL of a Firebase/APNS-connected ntfy server (likely "https://ntfy.sh").
#
# iOS users:
#   If you use the iOS ntfy app, you MUST configure this to receive timely notifications. You'll like want this:
#   upstream-base-url: "https://ntfy.sh"
#
# If set, all incoming messages will publish a "poll_request" message to the configured upstream server, containing
# the message ID of the original message, instructing the iOS app to poll this server for the actual message contents.
# This is to prevent the upstream server and Firebase/APNS from being able to read the message.
#
# - upstream-base-url is the base URL of the upstream server. Should be "https://ntfy.sh".
# - upstream-access-token is the token used to authenticate with the upstream server. This is only required
#   if you exceed the upstream rate limits, or the uptream server requires authentication.
#
# upstream-base-url:
# upstream-access-token:

# Rate limiting: Total number of topics before the server rejects new topics.
#
# global-topic-limit: 15000

# Rate limiting: Number of subscriptions per visitor (IP address)
#
# visitor-subscription-limit: 30

# Rate limiting: Allowed GET/PUT/POST requests per second, per visitor:
# - visitor-request-limit-burst is the initial bucket of requests each visitor has
# - visitor-request-limit-replenish is the rate at which the bucket is refilled
# - visitor-request-limit-exempt-hosts is a comma-separated list of hostnames, IPs or CIDRs to be
#   exempt from request rate limiting. Hostnames are resolved at the time the server is started.
#   Example: "<IP_ADDRESS>,ntfy.example.com,<IP_ADDRESS>/24"
#
visitor-request-limit-burst: 60
visitor-request-limit-replenish: "5s"
# visitor-request-limit-exempt-hosts: ""

# Rate limiting: Hard daily limit of messages per visitor and day. The limit is reset
# every day at midnight UTC. If the limit is not set (or set to zero), the request
# limit (see above) governs the upper limit.
#
visitor-message-daily-limit: 1000

# Rate limiting: Allowed emails per visitor:
# - visitor-email-limit-burst is the initial bucket of emails each visitor has
# - visitor-email-limit-replenish is the rate at which the bucket is refilled
#
# visitor-email-limit-burst: 16
# visitor-email-limit-replenish: "1h"

# Rate limiting: Attachment size and bandwidth limits per visitor:
# - visitor-attachment-total-size-limit is the total storage limit used for attachments per visitor
# - visitor-attachment-daily-bandwidth-limit is the total daily attachment download/upload traffic limit per visitor
#
# visitor-attachment-total-size-limit: "100M"
# visitor-attachment-daily-bandwidth-limit: "500M"

# Rate limiting: Enable subscriber-based rate limiting (mostly used for UnifiedPush)
#
# If enabled, subscribers may opt to have published messages counted against their own rate limits, as opposed
# to the publisher's rate limits. This is especially useful to increase the amount of messages that high-volume
# publishers (e.g. Matrix/Mastodon servers) are allowed to send.
#
# Once enabled, a client may send a "Rate-Topics: <topic1>,<topic2>,..." header when subscribing to topics via
# HTTP stream, or websockets, thereby registering itself as the "rate visitor", i.e. the visitor whose rate limits
# to use when publishing on this topic. Note: Setting the rate visitor requires READ-WRITE permission on the topic.
#
# UnifiedPush only: If this setting is enabled, publishing to UnifiedPush topics will lead to a HTTP 507 response if
# no "rate visitor" has been previously registered. This is to avoid burning the publisher's "visitor-message-daily-limit".
#
# visitor-subscriber-rate-limiting: false

# Payments integration via Stripe
#
# - stripe-secret-key is the key used for the Stripe API communication. Setting this values
#   enables payments in the ntfy web app (e.g. Upgrade dialog). See https://dashboard.stripe.com/apikeys.
# - stripe-webhook-key is the key required to validate the authenticity of incoming webhooks from Stripe.
#   Webhooks are essential up keep the local database in sync with the payment provider. See https://dashboard.stripe.com/webhooks.
# - billing-contact is an email address or website displayed in the "Upgrade tier" dialog to let people reach
#   out with billing questions. If unset, nothing will be displayed.
#
# stripe-secret-key:
# stripe-webhook-key:
# billing-contact:

# Metrics
#
# ntfy can expose Prometheus-style metrics via a /metrics endpoint, or on a dedicated listen IP/port.
# Metrics may be considered sensitive information, so before you enable them, be sure you know what you are
# doing, and/or secure access to the endpoint in your reverse proxy.
#
# - enable-metrics enables the /metrics endpoint for the default ntfy server (i.e. HTTP, HTTPS and/or Unix socket)
# - metrics-listen-http exposes the metrics endpoint via a dedicated [IP]:port. If set, this option implicitly
#   enables metrics as well, e.g. "<IP_ADDRESS>:9090" or ":9090"
#
# enable-metrics: false
# metrics-listen-http:

# Profiling
#
# ntfy can expose Go's net/http/pprof endpoints to support profiling of the ntfy server. If enabled, ntfy will listen
# on a dedicated listen IP/port, which can be accessed via the web browser on http://<ip>:<port>/debug/pprof/.
# This can be helpful to expose bottlenecks, and visualize call flows. See https://pkg.go.dev/net/http/pprof for details.
#
# profile-listen-http:

# Logging options
#
# By default, ntfy logs to the console (stderr), with an "info" log level, and in a human-readable text format.
# ntfy supports five different log levels, can also write to a file, log as JSON, and even supports granular
# log level overrides for easier debugging. Some options (log-level and log-level-overrides) can be hot reloaded
# by calling "kill -HUP $pid" or "systemctl reload ntfy".
#
# - log-format defines the output format, can be "text" (default) or "json"
# - log-file is a filename to write logs to. If this is not set, ntfy logs to stderr.
# - log-level defines the default log level, can be one of "trace", "debug", "info" (default), "warn" or "error".
#   Be aware that "debug" (and particularly "trace") can be VERY CHATTY. Only turn them on briefly for debugging purposes.
# - log-level-overrides lets you override the log level if certain fields match. This is incredibly powerful
#   for debugging certain parts of the system (e.g. only the account management, or only a certain visitor).
#   This is an array of strings in the format:
#      - "field=value -> level" to match a value exactly, e.g. "tag=manager -> trace"
#      - "field -> level" to match any value, e.g. "time_taken_ms -> debug"
#   Warning: Using log-level-overrides has a performance penalty. Only use it for temporary debugging.
#
# Check your permissions:
#   If you are running ntfy with systemd, make sure this log file is owned by the
#   ntfy user and group by running: chown ntfy.ntfy <filename>.
#
# Example (good for production):
#   log-level: info
#   log-format: json
#   log-file: /var/log/ntfy.log
#
# Example level overrides (for debugging, only use temporarily):
#   log-level-overrides:
#      - "tag=manager -> trace"
#      - "visitor_ip=<IP_ADDRESS> -> debug"
#      - "time_taken_ms -> debug"
#
# log-level: info
# log-level-overrides:
# log-format: text
# log-file:

My request is to support basic auth at a global level. This allows users who want to add their own security around their self hosted version of ntfy.sh to do so.
I'm just trying to park my instance behind a secure reverse proxy i manage. I want to store the basic auth credentials in the connection info just like other platforms allow.
I get that there are individual topics built in with an internal user list controlled through ntfy, but that restricts me from leveraging PAM or other amazing centralized solutions you get from keeping auth outside of ntfy and one layer back.
My request: please just support basic auth in the connection string.  All requests should just include the header from that point forward (including files)
Authorization: Basic <base64>

I agree that auth should additionally be supported through the URL (i.e. https://user:pass@host). UnifiedPush apps often seem to create a random topic automatically and don't allow credentials to be customized, so the current auth implementation can't be used.

I agree with @caronc since things like basic, server-wide auth is desireable and supporting that even rudimentary is quite useful.

The backend could thus be transparent (espechally when done via a reverse proxy) so any kind of SSO / PAM could be leveraged without requiring ntfy to support them directly.

This is espechally important since the App doesn't support proxy configurations so one can't simply use i.e. Orbot and do Cookie Auth on Tor...


#622 allow defining schema format other than default

Please see issue #622

I was thinking twice about "AsyncApi Schema object"
If i remove this again that would allow:

having avro schema for header
having avro schema for parameters

And the complexity will grow:
messageId: userSignup
name: UserSignup
title: User signup
summary: Action to sign a user up.
description: A longer description
contentType: application/json
tags:
  - name: user
  - name: signup
  - name: register
headers:
  schemaFormat: application/vnd.aai.asyncapi;version=3.0.0
  schema:
    type: object
    properties:
      correlationId:
  	    description: Correlation ID set by application
  	    type: string
      applicationInstanceId:
  	    description: Unique identifier for a given instance of the publishing application
  	    type: string
payload:
  schemaFormat: application/vnd.aai.asyncapi;version=2.2.0
  schema:
    type: object
    properties:
      schema:
        user:
          $ref: "#/components/asyncApiSchemas/userCreate"
        signup:
          $ref: "#/components/asyncApiSchemas/signup"

Do we really want that?

i still wait for response. needs to be discussed in next spec 3 meeting as it seams

how can we get any progress in this discussion?
@jonaslagoni may be a dedicated discussion?

Support for custom schema in header section was add.
Any comments from community?

Support for custom schema in header section was add. Any comments from community?

We should add a line somewhere mentioning there is no support for mixed schemas.

In today spec3.0 call https://youtu.be/hN6aE3Ebn08?t=1105
We came up with 3 options.
And a problem that will be solaved lated:

parameters support only basic types. And should not be speced with a full blown AsyncApi spec. A subtype is required.

Option 1a:
A separated component section.
Renaming asyncApiSchemas to schemas.
channels:
  userSignUp:
    address: 'users.{userId}'
    messages:
      userSignUp:
        $ref: '#/components/messages/userSignUp'
    parameters:
      userId:
        $ref: '#/components/parameters/userId'
components:
  messages:
    userSignUp:
      headers:
	    $ref: '#components/schemas/MyHeaderSchema'
      payload:
	    $ref: '#components/schemas/MyPayloadSchema'
  schemas:
    MyHeaderSchema:
      // schemaFormat is not set == default: application/vnd.aai.asyncapi;version=3.0.0
      schema:
        $ref: '#components/asyncApiSchemas/MyPayloadSchema'
    MyPayloadSchema:
      schemaFormat: 'application/vnd.apache.avro+yaml;version=1.9.0'
      schema:
        $ref: '#components/asyncApiSchemas/MyPayloadSchema'
  asyncApiSchemas: // in spec < 3.0 this was named "schema"
    MyHeaderSchema:
      type: object
      properties:
  	    applicationInstanceId:
          description: Unique identifier for a given instance of the publishing application
          type: string
    MyPayloadSchema:
      type: object
      properties:
        username:
          type: string
        email:
          type: string
  parameters:
    userId:
      description: The ID of the user.
      schema:
        type: string

Option 1b:
A separated component section.
Add new multiFormatSchemas component.
channels:
  userSignUp:
    address: 'users.{userId}'
    messages:
      userSignUp:
        $ref: '#/components/messages/userSignUp'
    parameters:
      userId:
        $ref: '#/components/parameters/userId'
components:
  messages:
    userSignUp:
      headers:
	    $ref: '#components/multiFormatSchemas/MyHeaderSchema'
      payload:
	    $ref: '#components/multiFormatSchemas/MyPayloadSchema'
    userSignIn: // inline insted of using `multiFormatSchemas`
      headers:
        schema:
	      $ref: '#components/schema/MyHeaderSchema'
      payload:
        schemaFormat: 'application/vnd.apache.avro+yaml;version=1.9.0'
        schema:
	      $ref: '#components/schema/MyPayloadSchema'
  multiFormatSchemas:
    MyHeaderSchema:
      // schemaFormat is not set == default: application/vnd.aai.asyncapi;version=3.0.0
      schema:
        $ref: '#components/schemas/MyPayloadSchema'
    MyPayloadSchema:
      schemaFormat: 'application/vnd.apache.avro+yaml;version=1.9.0'
      schema:
        $ref: '#components/schemas/MyPayloadSchema'
  schemas: // in spec < 3.0 this was named "schema"
    MyHeaderSchema:
      type: object
      properties:
  	    applicationInstanceId:
          description: Unique identifier for a given instance of the publishing application
          type: string
    MyPayloadSchema:
      type: object
      properties:
        username:
          type: string
        email:
          type: string
  parameters:
    userId:
      description: The ID of the user.
      schema:
        type: string

Option 2:
components.schemas get a new format.
schemaFormat: 'application/vnd.apache.avro+yaml;version=1.9.0'
--> is optional. Default is async api schema in version of the spec.
schema:
$ref: 'https://schema.server.com/schemaXyz#/schema'
--> as components.schemas in spec < 3.0
OR
$ref: 'https://schema.server.com/schemaXyz#/schema'
--> schema is optional. Default is async api schema in version of the spec.
Problem for the parser is, that $ref is only permitted to point to sub schemas with exact the same schemaFormat.
Mixing async api 2 and 3 is not permitted.
Mixing async and openapi is not permitted.
Mixing openapi and avro is not permitted.
channels:
  userSignUp:
    address: 'users.{userId}'
    messages:
      userSignUp:
        $ref: '#/components/messages/userSignUp'
    parameters:
      userId:
        $ref: '#/components/parameters/userId'
components:
  messages:
    userSignUp:
      headers:
	    $ref: '#components/schemas/MyHeaderSchemaA'
      payload:
	    $ref: '#components/schemas/MyPaloadAvroSchema'
    userSignIn:
      headers:
	    $ref: '#components/schema/MyHeaderSchemaB'
      payload:
	    $ref: '#components/schema/MyPaloadAsyncApiSchema'
  schemas: // can be of type "AsyncApi Schema object" or "Multi Format Schema Object"
    MyHeaderSchemaA:
      // schemaFormat is not set == default: application/vnd.aai.asyncapi;version=3.0.0
      schema:
        type: object
        properties:
          applicationInstanceId:
            description: Unique identifier for a given instance of the publishing application
            type: string

    MyHeaderSchemaB:
      // "schema" is missing so "AsyncApi Schema object" in version of document is assumed
      type: object
      properties:
  	    applicationInstanceId:
          description: Unique identifier for a given instance of the publishing application
          type: string

    MyPaloadAvroSchema:
      schemaFormat: 'application/vnd.apache.avro+yaml;version=1.9.0'
      schema: // refference to external schema server
        $ref: 'https://schema.server.com/schemaXyz#/schema'
    MyPaloadAsyncApiSchema:
      schema:
        properties:
  	      username:
  	        type: string
		  address:
		    $ref: '#components/schemas/address/schema'
    address:
      schema:
        type: object
        properties:
  	      town:
  	        type: string
  	      zip:
  	        type: string
  	      street:
  	        type: string
  parameters:
    userId:
      description: The ID of the user.
      schema:
        type: string

Option 3:
components.schemas get a new sub level for each sub schema level.
channels:
  userSignUp:
    address: 'users.{userId}'
    messages:
      userSignUp:
        $ref: '#/components/messages/userSignUp'
    parameters:
      userId:
        $ref: '#/components/parameters/userId'
components:
  messages:
    userSignUp:
      headers:
	    $ref: '#components/schemas/asyncapi/MyHeaderSchema'
      payload:
	    $ref: '#components/schemas/application~1vnd.apache.avro;version=1.9.0/MyPaloadAvroSchema'
    userSignIn:
      headers:
	    $ref: '#components/schema/MyHeaderSchemaB'
      payload:
	    $ref: '#components/schema/asyncapi/MyPaloadAsyncApiSchema'
    asyncApi2.4Sample:
      headers:
	    $ref: '#components/schema/MyHeaderSchemaB'
      payload:
	    $ref: '#components/schemas/application~1vnd.aai.asyncapi;version=2.4.0/MyPaloadAsyncApiSchema'
  schemas:
    asyncapi: // well defined alias for async api in same version as defined in `info.version`.
       It seems the best in terms of DX and doesn't look like a hack to me.

Is there any reason to have schemaFormat optional?

To make it as easy as possible for AsyncApiSchema users

@GreenRover but either a user are using AsyncAPI Schema object, or they are not.
If they are using the AsyncAPI Schema object it makes no sense to indent it within a .schema.
If they are not using the AsyncAPI Schema object they would specify both schema and schemaFormat, right? 🤔
I just see the optional schemaFormat variant as providing more confusion 🤔

I.e. this is the optimal document in my eyes:
  schemas: // can be of type "AsyncApi Schema object" or "Multi Format Schema Object"
    MyHeaderSchemaA:
      type: object
      properties:
        applicationInstanceId:
          description: Unique identifier for a given instance of the publishing application
          type: string
    MyHeaderSchemaB:
      type: object
      properties:
        applicationInstanceId:
          description: Unique identifier for a given instance of the publishing application
          type: string
    MyPaloadAvroSchema:
      schemaFormat: 'application/vnd.apache.avro+yaml;version=1.9.0'
      schema: // refference to external schema server
        $ref: 'https://schema.server.com/schemaXyz#/schema'
    MyPaloadAsyncApiSchema:
        properties:
          username:
            type: string
          address:
            $ref: '#components/schemas/address'
    address:
        type: object
        properties:
          town:
            type: string
          zip:
            type: string
          street:
            type: string

@jonaslagoni you are right. And won the version "2b"
I updated my comment (5 days ago)
@derberg Please choose between 2a and 2b

The examples are here:
https://github.com/asyncapi/spec/pull/910#issuecomment-1507518263
The difference:
2a allows:
  schemas: // can be of type "AsyncApi Schema object" or "Multi Format Schema Object"
    MyHeaderSchemaA:
      // schemaFormat is not set == default: application/vnd.aai.asyncapi;version=3.0.0
      schema:
        type: object
        properties:
          applicationInstanceId:
            description: Unique identifier for a given instance of the publishing application
            type: string

    MyHeaderSchemaB:
      // "schema" is missing so "AsyncApi Schema object" in version of document is assumed
      type: object
      properties:
        applicationInstanceId:
          description: Unique identifier for a given instance of the publishing application
          type: string

and 2b only:
  schemas: // can be of type "AsyncApi Schema object" or "Multi Format Schema Object"
    MyHeaderSchemaB:
      // "schema" is missing so "AsyncApi Schema object" in version of document is assumed
      type: object
      properties:
        applicationInstanceId:
          description: Unique identifier for a given instance of the publishing application
          type: string

So 2b give you one way less to solace the same problem.

2a 🚀
so basically example from Jonas -> https://github.com/asyncapi/spec/pull/910#issuecomment-1512959172
(@jonaslagoni MyPaloadAsyncApiSchema is missing type: object right?)

@derberg well, technically it's not required to include type, but it would make sense to include it yes 😄

@derberg type: object is missing. I fixed it in my comment. @jonaslagoni copied it from me.

well, technically it's not required to include type, but it would make sense to do so yea 😄

@jonaslagoni oh, I wasn't aware

But the example from jonas ist 2b not 2a!

how come? it has example with inline AsyncAPI Object and example with schemaFormat and Multi Format Object using Avro 🤔

@derberg This is the essence of "Option: B" can have at component.schema either a: "Multi Format Object" or "AsyncApi schema"

2b for me. I don't see the value of having an optional schemaFormat. Also, would like to add that schemaFormat and schema MUST be required (both) if any of them is present.

@derberg Do you also go with 2b?

2b keeps retro compatibility with v2 with the cost of adding complexity on tooling, which is completely ok. However, I'm not against it but I'm concerned about the fact you can declare AsyncAPI Schemas in two forms (even after applying @fmvilas suggestion). Could it add confusion to the final user?:
1
schemas:
    MyHeaderSchemaB:
      type: object
      properties:
        applicationInstanceId:
          description: Unique identifier for a given instance of the publishing application
          type: string

2
schemas:
    MyHeaderSchemaB:
      schemaFormat: 'application/vnd.aai.asyncapi;version=3.0.0'
      schema:
        type: object
        properties:
          applicationInstanceId:
            description: Unique identifier for a given instance of the publishing application
            type: string

Sorry, I'm not sure I understand what "In case that a Schema Object the schemaFormat will be assumed as..." means.

@dalelane  This was phrase was modified in mean while. Better now?

Sorry, I'm not sure I understand what "In case that a Schema Object the schemaFormat will be assumed as..." means.

@dalelane This was phrase was modified in mean while. Better now?

Where was it changed? I don't see any changes to the pull request.

@dalelane  Ok i found this sentence and changed it now as suggested

Changed the PR title to meet the requirements.

/rtm


Setup Github actions to test on unix system

@rwinterschlaf until then let me know if I should run tests for a PR on MacOS/POSIX. Or are you already working in Windows subsystem for Linux?

Thanks @FlxVctr ! Would be good if you could do this - I am working in my usual Windows setup, so no Linux in sight.

Long term it might be good to try this: https://smo-wiki.leibniz-hbi.de/Windows-Linux-Subsystem-dev-setup

Since these are up and running now, I'll close the issue.


Comment on: File

FileClass.md

Enter your comment here:
wrong:
$txt:=$myFile.getText("UTF-8", Document with LF)
correct:
$txt:=$myFile.getText("UTF-8"; Document with LF)

thanks, the error is fixed now


Vi not taking full height after closing split pane

[x] I am on the latest Hyper.app version
[x] I have searched the issues of this repo and believe that this is not a duplicate

OS version and name: macOS Sierra 10.12.3
Hyper.app version:  1.3.1
Link of a Gist with the contents of your .hyper.js: .hyper.js
Relevant information from devtools (CMD+ALT+I on Mac OS, CTRL+SHIFT+I elsewhere): None
The issue is reproducible in vanilla Hyper.app: Yes

Issue

When open and closing a split pane on Hyper, Vi does not take the full height.
As you can see in the following video, I split Hyper horizontally, close the new created pane. When opening Vi, the process takes only half the height available.

Reloading Hyper with Cmd + R fixes it.

Duplicate of #1676.


multiple copies of the OpenMP runtime have been linked into the program

🐛 Bug

To Reproduce
Steps to reproduce the behavior:

Open napari
Try to open an image
Software crash

OMP: Error #15: Initializing libiomp5md.dll, but found libiomp5md.dll already initialized.
OMP: Hint This means that multiple copies of the OpenMP runtime have been linked into the program. That is dangerous, since it can degrade performance or cause incorrect results. The best thing to do is to ensure that only a single OpenMP runtime is linked into the process, e.g. by avoiding static linking of the OpenMP runtime in any library. As an unsafe, unsupported, undocumented workaround you can set the environment variable KMP_DUPLICATE_LIB_OK=TRUE to allow the program to continue to execute, but that may cause crashes or silently produce incorrect results. For more information, please see http://www.intel.com/software/products/support/.
Environment

Please copy and paste the information at napari info option in help menubar here:
napari: 0.4.12
Platform: Windows-10-10.0.19043-SP0
Python: 3.9.7 | packaged by conda-forge | (default, Sep 29 2021, 19:15:42) [MSC v.1916 64 bit (AMD64)]
Qt: 5.15.2
PyQt5: 5.15.6
NumPy: 1.20.3
SciPy: 1.7.3
Dask: 2021.12.0
VisPy: 0.9.4

OpenGL:

GL version: 4.6.0 NVIDIA 456.71
MAX_TEXTURE_SIZE: 32768

Screens:

screen 1: resolution 2560x1080, scale 1.0
screen 2: resolution 1050x1680, scale 1.0

Plugins:

Measurements (skimage regionprops): 0.2.5
Utilities (skimage regionprops): 0.2.5
console: 0.0.4
napari-allencell-segmenter: 1.1.3
napari-tools-menu: 0.1.7
ome-types: 0.2.9
platelet-unet-watershed: 0.0.3
scikit-image: 0.4.12
svg: 0.1.5=

@AuSpotter napari doesn't include any compiled code, so this is unlikely to be a napari issue. I suspect it's rather scikit-image. Can you tell us more about how you installed napari, and what kind of image you're opening?

Seeing Python packaged by conda-forge but PyQt at version 5.15 (back in 2021) makes me think that a combination of conda and pip install commands was used to get to this point (which is not supported). It should work with a fresh environment created like this:
$ conda create -n napari -c conda-forge napari
$ conda activate napari
$ napari


TYpo "@job_login"→"@job_login"

https://docs.microsoft.com/en-us/sql/relational-databases/replication/administration/upgrade-replication-scripts-replication-transact-sql-programming?view=sql-server-2017

@hyoshioka0128 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

This pull request is for the Live branch. We can't merge to Live. Would you resubmit your changes to the master branch? Thanks.

Hi @hyoshioka0128 , thank you so much for your contribution, and for making docs better! You've actually identified an issue in our docs - these parameters should be in code blocks, and if they are, there is no escape character necessary. I am updating all of these within a bulk update which will supersede this PR. As such, I will proceed with closing out this PR, but please feel free to reply should you need anything further.
Thanks!
Masha from the SQL Docs team


Json comments are not processed

@aurambaj I noticed that comment like this in JSON is not being processed as expected:
{
  // comment
  "hello": "Hello!"
}

How should we handle when we have both comment // comment and "note": "comment"?

This doesn't work. Let me fix it again.


Fixes #26480 : Prevent color leak due to dragging of table row in settings and custom profile fields

Fixes: #26480
Screenshots and screen captures:
These are screenshots and screen captures after i have made the changes:-

https://github.com/zulip/zulip/assets/119888263/833d835e-9fcd-438c-9057-d1523c41ce9c

Self-review checklist

[ ] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[ ] Explains differences from previous plans (e.g., issue description).
[ ] Highlights technical choices and bugs encountered.
[ ] Calls out remaining decisions and concerns.
[ ] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[ ] Each commit is a coherent idea.
[ ] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[ ] Visual appearance of the changes.
[ ] Responsiveness and internationalization.
[ ] Strings and tooltips.
[ ] End-to-end functionality of buttons, interactions and flows.
[ ] Corner cases, error conditions, and easily imagined bugs.

I had adjusted the background color value which was causing the problem
@timabbott  Kindly review the PR and please tell me weather any changes needed!!
Thank You : )

@timabbott
I had made the PR for #26480
kindly review it and please tell me whether any changes needed!!

@amanagr
It would be great if you can review this PR
and let me know if any changes needed
Thank You: )


Is it possible that you see blank areas only on iOS, but not on low-spec Android device?

Hi, I am using the latest version 1.4.0. And my list works perfectly fine on Android device, even if its spec is low.
But on every iOS device, I see blank areas on simple scrolls.
I am truly confused by this bug.
Do you have any clue about what is causing this phenomenon?

Can you share a video? On iOS max scroll speed is a lot higher than Android so sometimes offset can change beyond our render window. But that's an edge case that you shouldn't be able to reproduce easily.
On Android, there shouldn't be any blanks

This is happening for me only on simulator but working fine on real iOS device. Not sure if this is same for @TaichiAkimoto

I finally found out that, on iOS, scrollEventThrottle significantly degrades performance.
If you remove scrollEventThrottle, list scrolls magically smooth.

It'd be great if you could provide reproduction steps. Then we can take a look at this and either try to find a solution or at least document this.


Need a right click menu on files to launch apps

This is probably a task for @mauriel133. When a user right clicks a file, any apps that have been registered to that file type should appear in a right click "Open With" menu. This should follow the same approach as the current resource level "Open With" menu in terms of formatting a URL string that launches the app with any customized URL string parameters. The only difference is that instead of passing the resource ID only, you will pass the resource ID AND the file ID. We already have a working ability to RECEIVE such an app launch in HydroShare GIS. @shawncrawley will post a note to this issue indicating the specific format of the URL string.

Here is an example URL endpoint for HydroShare GIS that will launch a specific file from within a resource:
https://apps.hydroshare.org/apps/hydroshare-gis/?res_id=74a0ffbcff494cb985b061b3fc14f2f2&res_type=GenericResource&res_fname=UtahLake.jpg
It uses the res_fname parameter. However, I'm leaning more towards changing that parameter to just res_file, instead of res_fname... But for now it is res_fname. Any thoughts on that?

Actually in our current model, the app developer can use any variable name they want in the URL string (res_file or res_fname, etc). That is specified by the app developer. The only thing that matters is the variables that are specified in the URL which can include:
${HS_RES_ID}
${HS_RES_TYPE}
now we need to add
${HS_RES_FILE}
For example for SWAT Share the URL is specified like this:
https://mygeohub.org/groups/water-hub/swatshare?src=hs&res_id=${HS_RES_ID}&op=run
at run time, the "Open With" button replaces ${HS_RES_ID} with the resource id of the resource that launched the app.
For HydroShare GIS it is like this:
https://apps.hydroshare.org/apps/hydroshare-gis/?res_id=${HS_RES_ID}&res_type=${HS_RES_TYPE}
at run time the "Open With" button replaces both ${HS_RES_ID} and ${HS_RES_TYPE} with the resource ID and type.
So to specify a specific file within a resource one would simply embed the ${HS_RES_FILE} variable in the app definition.
Shawn's example file launcher URL would then look like this:
https://apps.hydroshare.org/apps/hydroshare-gis/?res_id=${HS_RES_ID}&res_type=${HS_RS_TYPE}&res_fname=${HS_RS_FILE}
So... @mauriel133  and @horsburgh. If you guys were to make this small change in the file explorer all you would need to do is

When user right clicks a file, check which apps are associated with that file's file extension and list them in an "Open With" menu
When a user clicks one of the apps to launch it, you replace ${HS_RS_ID}, ${HS_RS_TYPE} and ${HS_RS_FILE} with the appropriate values and launch the URL.

@mauriel133 and @horsburgh we could try to add this code here at BYU @zhiyuli  could do it. But I'm afraid to mess around in your file/folder viewer. What do you suggest?

@danames

When user right clicks a file, check which apps are associated with that file's file extension and list them in an "Open With" menu

Does our current implementation has the ability to associate a web app with a file type? If not then that needs to be implemented first before @mauriel133 can work on the front-end changes as needed by this issue.

@aphelionz could you guide me through the work on this. Do we have a way to associate file types and web apps now? If so, where can I find the URL syntax?

Also a question for @alva and @pkdash

This is a question for @danames @zhiyuli and the data model for the app resource type.  This is a bit of a chicken and egg situation as the URL pattern needs to use information from new fields in the app resource.  Issues #1609, #1161 and this need to be coordinated.

@dtarb @danames
I just got my HS dev environment working again (have been working on NWM Tethys apps in the past months) and I am learning Pabitra's implementations of "file-type" and "composite res". Should be able to pick up WebApp Res work very soon.

@zhiyuli Let me know if you have any question related to file type as you try to link file types to web apps.

@danames @zhiyuli, @pkdash is available to help with this so please coordinate what is best for him to do versus @Maurier and @zhiyuli

Hi all, thanks for all the discussion on 1609. At the moment we're going to
have @zhiyuli take the lead on this. He will coordinate with @pkdash.
Ultimately we'll pass our UI design through @Maurier for input and
improvement. Hope this will work... - @danames
On Tue, Oct 17, 2017 at 7:09 PM David Tarboton<EMAIL_ADDRESS>wrote:

@danames https://github.com/danames @zhiyuli
https://github.com/zhiyuli, @pkdash https://github.com/pkdash is
available to help with this so please coordinate what is best for him to do
versus @Maurier https://github.com/maurier and @zhiyuli
https://github.com/zhiyuli
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/hydroshare/hydroshare/issues/1609#issuecomment-337429969,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADT89LTZMZMGQohx5T_YLnlxX-L5YrzYks5stU-7gaJpZM4K2K-Z
.

Email from @danames 10/25/17
From: Dan Ames<EMAIL_ADDRESS>Sent: Wednesday, October 25, 2017 2:27 PM
To<EMAIL_ADDRESS>Pabitra Dash<EMAIL_ADDRESS>Subject: [HydroShare-Dev] Following up on open with discussion
The file-based open with click, launches an app using a URL pattern the app developer specifies.
There is an option to include variables in the app launching URL pattern:
Existing Variables:

HS_RES_ID this is the resource ID of the resource the file is part of.
HS_RES_TYPE this is the type of the resource
HS_USER_NAME this is the user name, but should not be avoided

New Variables for file based app launching:

HS_FILE_TYPE this is the type of the file the user clicked
HS_FT_FID this is the ID to the file type instance - the topic of a lot of our conversation today. Here's more explanation of it

Pabitra implemented file types such that he has a global counter in HydroShare that increments every time someone makes a new file of a certain type. Each file type has its own global counter. In Drew's demo, his netcdf file came up with ID =1. That is because he was working on his local instance of HydroShare. However in HydroShare proper there are likely to be many NetCDF instances. It doesn't matter who created it, or what resource it lives in, they all have a unique identifier. In other words, David may own NetCDF files 1-100. Drew owns 101, I own 102 through 150, etc. These unique identifiers are the most efficient method to quickly find a file instance in HydroShare and they don't every change once they are assigned. Because of this, we'll probably continue to use these numbers to identify file instances in HydroShare during an app launch.
The real problem here: we need to have file instance based access via API. This does not exist yet. Also when it is implemented, we need to have a means to confirm the ownership of the file that is requested by an app via API.
Sorry of this is a bit too detailed or esoteric for many of you, but I just wanted to clarify a bit about these ID's. Having said that, perhaps, Pabitra would want to change how he identifies file instances in HydroShare, or perhaps he could give us a function call that we could use to convert Local File Path/Name to his Global ID. Then it would make sense to change the App launching pattern to include File/Path name....
Thoughts?

I am not supportive of a new unique file type numbering system.  Also, as you note, it needs a new API.  I suggest instead just using the API we already have.  For example you can access a file in a file type in a composite resource like
http://www.hydroshare.org/resource/64fb0a478974411caea3335e2d07975c/data/contents/logan/logan.tif
The system already delivers files like this.

One FileType instance includes all required "component files" to compose a
specific FileType, and is assigned with one Logical FileType ID.
Do we want apps to able to download one FileType instance (say
GeoFeatureFileType: *.shp, *shx, *dbf) from a composite resource instead of
the whole resource bag?
If yes, we should use this Logical FileType ID as it refers to all
"component files".
On Wed, Oct 25, 2017 at 3:28 PM, David Tarboton<EMAIL_ADDRESS>wrote:

I am not supportive of a new unique file type numbering system. Also, as
you note, it needs a new API. I suggest instead just using the API we
already have. For example you can access a file in a file type in a
composite resource like
http://www.hydroshare.org/resource/64fb0a478974411caea3335e2d0797
5c/data/contents/logan/logan.tif
The system already delivers files like this.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/hydroshare/hydroshare/issues/1609#issuecomment-339477127,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJmqR0f1e9iRv9lDrYFyhHjC7q5DWOUgks5sv6figaJpZM4K2K-Z
.

It would be great to hear from Pabitra. As we discussed on the call today, it seems like it would be better to reference files by name. We already have API functionality for this, including access control and authorization. But we do have the challenge that referencing an individual file may not reference all of the needed files that make up  a “logical file” like a geographic feature dataset (shapefile).
In our current implementation, the files making up a “logical file” are grouped within an element within the science metadata called a “dataset”, so we are storing the association among the files in a “logical file”. However, I don’t know if we have any REST API functionality for exposing this in a way that one can retrieve a list of all of the files contained within a “logical file” through the REST API. The global counter described by Dan is only stored in Django and isn’t part of the resource map or science metadata (that I know of) - so I'm doubting it would be part of our API. One could likely achieve the same functionality to get a list of all of the files contained within a "logical file" by passing in one of the file names within that "logical file" versus passing the global counter for the "logical file".
Pabitra – do you have thoughts on the best way to access a “logical file's” content (i.e., all of it's files) from a composite resource via the REST API so it can be launched into an APP?
I could see it happening this way:

A user right clicks on a file within a composite resource (e.g., a .shp file or a .nc file) to launch it into an appropriate app
A URL is constructed according to the pattern that Dan highlighted – except that instead of using the HS_FT_FID the URL would pass the file name.
When fielding the request in the URL, the APP can determine the type of file based on the HS_FILE_TYPE so it knows whether it needs to retrieve only the file in the URL or all files that participate with the file in the URL as part of its “Logical File”
The APP sends a request to the HydroShare REST API to retrieve a list of files associated with the file in the URL (e.g., the list of all files in the “Logical File”) – not sure if this exists yet in our API
The App then retrieves each of the files in “logical file’s” list of files via the existing REST API.

Not sure about 4 and 5.

@horsburgh
A web app can either pass the logical file type and its ID, or the full path of one of the files in the logical file group to get a list of files in that file type. We need to decide which one we prefer. We don't have at this point a REST endpoint (#4 of the user step) for the web app to make that call. We have the REST API for item#5 which is retrieving any file from HydroShare and that has nothing to do with file type.
The other REST API I think we need soon is to retrieve all metadata (in json format) for a given file type instance.

Given that the logical file IDs are only stored in Django, my vote would be to use the full path of one of the files in the logical file group. But, whether we use the file path or logical file ID (or potentially both?), it looks like we would need to have at least one new REST API endpoint to get the list files in a logical file by passing in a logical file ID or the full path of one of the files in the logical file. The existing file retrieval endpoint could then be used to retrieve the individual files (which I think is preferred because it already exists and already implements access control and authorization).
I agree that it would be useful at some point to have a REST endpoint to retrieve the metadata for a logical file.

I still am a bit uncomfortable with automatically moving my files into a folder. I can't think of any other operating system that would do this. All other OS's leave the files where the user puts them. Likewise, I can't think of any other OS that would require the right-click-set-as-geographic-feature step. Other OS's just see the files there and know that they are of a certain type based on file extension(s). Even ArcGIS doesn't require you to mark a shape file as such before you can use it. It just sees the shp/shx/dbf together and logically groups them and only shows one file.
Can we implement this approach instead?

@danames - there's a whole bunch of discussion here about launching files within a composite resource into an app (and a bunch of other stuff). I believe that this discussion is superseded by the new composite resource functionality and issue #2576 which hasn't been implemented yet. Can we close this older issue and instead focus on #2576?

@danames @horsburgh is this close-able as a duplicate or part of 1.16?

I think we need to @sblack-usu to comment here because I believe he's been working on this. I hope the answer is yes, this will be addressed by the new composite resource functionality for 1.16.

@sblack-usu is addressing this in PR #2767


[zh-cn]Update patch-releases.md

en: https://kubernetes.io/releases/patch-releases/
update follow on : https://kubernetes.io/zh-cn/releases/patch-releases/

Thanks.
/lgtm
/approve


not good when I use BERT for seq2seq model in keyphrase generation

Hi,
recently, I am researching about Keyphrase generation. Usually, people use seq2seq with attention model to deal with such problem. Specifically I use the framework: https://github.com/memray/seq2seq-keyphrase-pytorch, which is implementation of http://memray.me/uploads/acl17-keyphrase-generation.pdf .
Now I just change its encoder part to BERT, but the result is not good. The experiment comparison of two models is in the attachment.
Can you give me some advice if what I did is reasonable and if BERT is suitable for doing such a thing?
Thanks.
RNN vs BERT in Keyphrase generation.pdf

not yet, I will try. But I think rnn decoder should not be such bad.

not yet, I will try. But I think rnn decoder should not be such bad.

emmm，maybe u should used mean of  last layer to initialize decoder, not  the last token representation of last layer.
I am also very concerned about the results of using transformer decoder. If you are done, can you tell me? Thank you.

I think the batch size of RNN with BERT is too small. pleas see

https://github.com/memray/seq2seq-keyphrase-pytorch/blob/master/pykp/dataloader.py
line 377-378

I don't know what you mean by giving me this link. I set to 10 really because of the memory problem. Actually, when sentence length is 512, the max batch size is only 5, if it is 6 or bigger there will be memory error for my GPU.

not yet, I will try. But I think rnn decoder should not be such bad.

emmm，maybe u should used mean of last layer to initialize decoder, not the last token representation of last layer.
I am also very concerned about the results of using transformer decoder. If you are done, can you tell me? Thank you.

You are right. Maybe the mean is better, I will try as well. Thanks.

May i ask a question? R u chinese?23333

Cause for one example, it has N targets. We wanna put all targets in the same batch. 10 is too small that the targets of one example would  be in different batches probably.

I know, but ... the same problem ... my memory is limited .. so ...
PS. I am Chinese

I know, but ... the same problem ... my memory is limited .. so ...
PS. I am Chinese

i am as well hahaha

是不是语料的问题，bert是在wiki上训练的。我用kp20k训练了一个mini bert，在测试集上的accuracy目前是80%，你要不要试试用我这个作为encoder？

这个80%具体是什么数值这么高？f1 score吗？ 你的encoder能不能发来看一下呢 谢
waynedane<EMAIL_ADDRESS>周三下午11:14写道：

是不是语料的问题，bert是在wiki上训练的。我用kp20k训练了一个mini
bert，在测试集上的accuracy目前是80%，你要不要试试用我这个作为encoder？
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/huggingface/pytorch-pretrained-BERT/issues/59#issuecomment-442482124,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHCjdIT1G6Icse3LK2SZXO194JJTiM1Qks5uzqhMgaJpZM4Y3HWV
.

accuracy 是masklm和nextsentence两个任务的，不是key phrase generation，我没说清楚，抱歉。我的算力有限，两块p100,  快一个月了，目前还没训练完。80%是当前的表现。

你提到的mini bert 是什么意思？

我大概理解你的意思了，你相当于是用kp20重新预训练一个bert，不过这样做... 感觉确实蛮麻烦。

是的，用的是 Junseong Kim的代码：https://github.com/codertimo/BERT-pytorch ，模型规模比谷歌的BERT-Base Uncased都小很多。这个是L-8 H-256 A-8.我把目前训练的checkpoint和vocab文件发给你

但是你这个checkpoint，我的这个版本能直接用吗，还是说我必须装你的那个版本的代码？

你可以发到我邮箱<EMAIL_ADDRESS>， 谢

但是你这个checkpoint，我的这个版本能直接用吗，还是说我必须装你的那个版本的代码？

可以根据Junseong Kim 的代码创建一个bert model然后加载参数，不一定得安装

好的把。那你把checkpoint 发给我试试。

Hi guys,
I would like to keep the issue of this repository focused on the issues with the package it-self.
I also think it's better to keep the conversation in english so everybody can participate.
Please move this conversation to your repository: https://github.com/memray/seq2seq-keyphrase-pytorch or emails.
Thanks, I am closing this discussion.
Best,

OK. got it.

accuracy 是masklm和nextsentence两个任务的，不是key phrase generation，我没说清楚，抱歉。我的算力有限，两块p100, 快一个月了，目前还没训练完。80%是当前的表现。
<EMAIL_ADDRESS>

hi, @whqwill  I have some doubts about the usage manner of bert with RNN.
In bert with RNN method, I see you only consider the last term's representation (I mean the TN's) as the input to RNN decoder, why not use the other term's representation, like T1 to TN-1 ? I think the last term's information is too less to represent all the context information.


Support shallow cloning

Currently, we don't support shallow cloning. It's worth investigating to see if it's possible to do this without too much work.

Closing due to age. (Also, it doesn't seem like there is demand for this.)

shallow clone is very useful for repos that have large (or many) artifacts/blobs which git stores changes to as entirely new files rather than as file differences. over time these repos can get quite large if there are many edits to the artifacts/blobs. repos with these characteristics are common for documentation or research paper focused projects
creating a shallow clone can be very convenient way to speed up cloning a repo with these characteristics when you just need the latest version
it would be wonderful if you could add shallow clone to support this, many thanks

Happy to keep this open, but it's unlikely that I'll have time in the near future to work on this. Happy to accept a PR.

got it, thx

Again, closing due to age. I am not planning on implementing this, and no external contributor has gotten to it in 9 years 🙃


IonSlider::getSlider() was silently deprecated

Ionic version:

[x] 2.x

I'm submitting a ...  (check one with "x")

[x] bug report

Current behavior:
IonSlider::getSlider() has been deprecated and returns void, but this was never mentioned in the release notes.
Expected behavior:
Update the release notes to mention this breaking change. I believe this happened in v2.0.0.

This issue was moved to driftyco/ionic-site#1003


Watch script is not watch and instead is dev

Do you want to request a feature or report a bug?
Bug.
What is the current behavior?
README shows script for starting dev server as yarn watch but in package.json we have
"scripts": { //...
    "dev": "preact watch"  //...
},

If the current behavior is a bug, please provide the steps to reproduce.
Install preact-cli create a new project with preact create --yarn test-app test

What is the expected behavior?
Either in the docs we should have yarn dev or in the package.json we should have "watch": "preact watch",
Please mention other relevant information.

node version: v8.5.0
npm version: 5.3.0
yarn version: 1.1.0
Operating system: Ubuntu 16.04.3 LTS

I think you got confused somewhere:
Here it shows yarn start for running dev server.

@reznord: @wescoder is correct for the 1.4.1 release. We have yarn watch written in the README but all examples ship dev command.
@wescoder: Sorry for the inconvenience, but this is no longer applicable moving forward. We appreciate you taking the time to submit this, though!

@wescoder Oh my bad. Sorry for the inconvenience.
Just for further clarification on scripts:
npm run start or yarn start: Runs serve or dev, depending on NODE_ENV value. Defaults to dev server
npm run dev or yarn dev: Run a development, HMR server
npm run serve or yarn serve: Run a production-like server
npm run build or yarn build: Production-ready build

Oh I see it is correct in master branch indeed, thanks.
I'm closing this.


extcodesize check bypass for mockCall

Component
Forge
Describe the feature you would like
Adding an extcodesize check bypass when mocking functions. Functions that have no return data are still subject to an extcodesize check (see https://github.com/ethereum/solidity/issues/12204). This makes it challenging when working with external integrations in a non forked environment (mocked calls still revert because extcodesize == 0).
Currently, my local solution is to fill junk bytes at a target address before mocking:
function mockCall(address where, bytes memory data) internal {
        cheats.etch(where, "0xdeadbeef");
        cheats.mockCall(where, data, abi.encode());
}

It would be nice to have this feature integrated into foundry that way mockCall covers all possible scenarios. Just not sure if my solution is ideal because it leaves junk bytecode at addresses.
Additional context
No response

Check out all the discussion in https://github.com/foundry-rs/forge-std/issues/46 around how foundry should handle mocking, including questions about what should be upstreamed to foundry and what should be part of forge-std. The discussion has stalled, but would love your input there, as this is one of things covered.

I'm not entirely sure how we can solve this specific issue in Forge, I'd love some input. Here are some different approaches and the issues I see with them:

We could write junk data to the address ourselves and reset it after - however, this makes the contract completely unuseable for anything than the mocked function, which is obviously not ideal.
We could try to bypass extcodesize checks smartly, but this requires us to basically look ahead and do some "fake" execution every time we hit an extcodesizecheck to see if we're about to call a mocked function.

It seems like your scenario is using mockCall on an empty address which is why you're having this issue, but a lot of people also use mockCall on an address that has a bytecode, where they only mock one or two functions that should still work as intended.
For your use case specifically, can I suggest doing the vm.etch in setUp? That should clean up your test a bit, I assume.

Thanks @mds1, must have missed it the first time around, but I'll take a look at the discussion there!
And @onbjerg thanks for response. My suggestions would either be:

Improve error messaging to show a call has failed due to an extcodesize check. (currently just reverts without any message)
Write junk data to an address when mocking if we detect no code at an address. Really there shouldn't be a scenario where mocking fails.

For your use case specifically, can I suggest doing the vm.etch in setUp? That should clean up your test a bit, I assume.

Yeah this is a good call, we will do this for now.

How is the state of this issue? Encountered the same problem when trying to mock a function that does not return.
Was able to solve it with the solution used by @JChiaramonte7 adding vm.etch(where, '0xdeadbeef'); on setUp, but would be nice to have this option already included on mockCall for the cases where there are no return params

Hasn't been a priority because there is so much else to look at. I think the solution is pretty simple, so I'll take a look at it now since it was bumped

PR is up, should be good for the nightly tonight :)