Public files with the minus prefix are not included in the final build

Environment
https://stackblitz.com/edit/github-4pefag?file=package.json&view=editor
Reproduction
https://stackblitz.com/edit/github-4pefag?file=package.json&view=editor
Describe the bug

Create file "-test.txt" in public directory
Build project
The public directory does not contain a file "-test.txt"

Additional context
No response
Logs
No response

I'd say this is intended because - is the ignorePrefix. The JSDOC for it should be updated though.


Enable Psalm

Fixed a couple of identified issues. More will be able to be fixed when this package can be upgraded to PHP 7.3+.

Q
A

Documentation
no

Bugfix
no

BC Break
no

New Feature
yes

RFC
no

QA
no

Description
This PR fixes #16.
A few psalm issues were fixed, but i do also plan address #17 which will make it easier to solve issues with typehints instead of annotations.
Template comments require targeting the master branch? Only 2.3.x is showing up as available.

It looks like I will need to fix the PHP 7.3 support issue as well. Psalm dependencies require it or better.

Completing this PR is currently dependent on https://github.com/phpro/zf-doctrine-hydration-module/pull/47

Completing this PR is currently dependent on phpro/zf-doctrine-hydration-module#47

I notified the Laminas team about this in April:  https://github.com/laminas-api-tools/api-tools-doctrine/issues/15

My PR to that project does update everything as is without changing any functionality unless it was made incompatible with package changes.
At least as a short term route, we could hard fork and inherit from that going forward.
As a long term route I think the entire package should be deprecated. It seems to made up of two sets of functionality.

MongoODM overrides for https://github.com/doctrine/doctrine-laminas-hydrator If appropriate those could be merged into that project
Abstract factory to handle the hydrator mapping. This could be moved into this project.

I personally don't use this for the mongo parts so its a bit difficult to make any assessment on that. If this makes sense to get this project upgraded, I can push forward with that.

I'm all for forking so that https://github.com/phpro/zf-doctrine-hydration-module/pull/47 can be merged. For the long term what @datasage suggests seems to best way.

I'm all for forking so that https://github.com/phpro/zf-doctrine-hydration-module/pull/47 can be merged. For the long term what @datasage suggests seems to best way.

@netiul Its the least risky yes, in case other people are inadvertently relying on the parts not used by this library.

@netiul Its the least risky yes, in case other people are inadvertently relying on the parts not used by this library.

Closing in favor of #26. We've done incremental steps to migrate to GHA for CI, update laminas-coding-standards, update the minimum supported PHP version, and add PHP 8.0 as a supported version - which makes the Psalm additions easier.


[Bug]com.github.os72:protoc-jar-maven-plugin: Not generating grpc service stubs(example:PFunctionServiceGrpc)

Search before asking

[X] I had searched in the issues and found no similar issues.

Version
doris 1.0
What's Wrong?
now java udf not support,so i test remote udf。but i found i cant gen grpc service,only gen FunctionService,Types。not have
PFunctionServiceGrpc on plugin protoc-jar-maven-plugin
What You Expected?
generate PFunctionServiceGrpc
How to Reproduce?
No response
Anything Else?
No response
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Hello, have you solved this problem? I have encountered it too.


Handle resolve requests that include service URL

See https://github.com/CDLUC3/N2T/issues/33
Basically some resolve requests include the URL of the resolver as the start of the identifier. In these cases, remove the service URL portion and continue with remaining identifier.

Added a config option where a service URL pattern can be added. When present at the start of a pid, the service url portion is removed.


[Excel] (Worksheet) Add Worksheet.onProtectionChanged docs

Adding docs for a feature released with ExcelApi 1.14.

Docs Build status updates of commit 7ca7281:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs/excel/excel-add-ins-events.md
:warning:Warning
View
Details

docs/excel/excel-add-ins-worksheets.md
:warning:Warning
View
Details

docs/excel/excel-add-ins-events.md

Line 4, Column 10: [Warning: ms-date-invalid - See documentation] Invalid date format for 'ms.date': '12/06    /2021'. Must be a date in format M/D/YYYY, no more than 30 days from today.

docs/excel/excel-add-ins-worksheets.md

Line 500, Column 138: [Warning: file-not-found - See documentation] Invalid file link: '(/javascript/api/excel/excel.worksheet'.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit 32bec64:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/excel/excel-add-ins-events.md
:white_check_mark:Succeeded
View

docs/excel/excel-add-ins-worksheets.md
:white_check_mark:Succeeded
View

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

Docs Build status updates of commit 2bf2822:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/excel/excel-add-ins-events.md
:white_check_mark:Succeeded
View

docs/excel/excel-add-ins-worksheets.md
:white_check_mark:Succeeded
View

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

Docs Build status updates of commit d2c1c2a:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/excel/excel-add-ins-events.md
:white_check_mark:Succeeded
View

docs/excel/excel-add-ins-worksheets.md
:white_check_mark:Succeeded
View

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


Fix Imf/Iex/IlmThread namespaces in python bindings and website code

Use OPENEXR_NAMESPACE, IEX_NAMESPACE, ILMTHREAD_NAMESPACE instead of Imf, Iex, IlmThread, to support custom settings.
Address #1567.

This may be fine for now, but I feel like there is a more sensible way to structure the namespaces and namespace override options. I don't need to use these macros throughout the code in my other projects. There should only be two mentions of the "INTERNAL" namespaces -- once in the CMake to allow users a way to override it for a custom namespace, and then a second in a header that aliases the publicly visible namespace to that one. All user code, and all other internal code, ought to be able to safely say Iex::foo and it's fine, even though there is a custom namespace behind it all.

I've removed the explicit Iex:: namespace from the example website code, and added using namespace IEX_NAMESPACE to all.cpp (which doesn't appear on the website but is used by the build to confirm it compiles), which is at least for the moment consistent with the implicit using namespace IMATH_NAMESPACE and using namespace OPENEXR_IMF_NAMESPACE.
This compiles with both default and custom namespaces, so resolves #1567. Let's flag as a separate issue both cleaning up the namespace declarations and editing the example code to both show best practices as well as work under all build configurations.


Unable to access some gem5 resources when using Resource()

Summary:
The error "Resource with name 'resource_name' does not exist" occurs with some gem5 resources. This includes x86-matrix-multiply-omp, x86-bubblesort, x86-floatmm, riscv-bubblesort, and arm-bubblesort. The error can be replicated by attempting to obtain a resource with Resource("resource_name") in a Python script for setting up a simulation. The fix that I found for x86-matrix-multiply-omp was to change the url for x86-matrix-multiply-omp in the resources.json file. This would not work for x86-bubblesort and x86-floatmm, as they were entirely absent from resources.json.
Detailed:
When attempting to access a number of gem5 resources with Resource(resource_name), the following error occurs:
Exception: Error: Resource with name 'x86-matrix-multiply-omp' does not exist

At:
  build/X86/python/gem5/resources/downloader.py(362): get_resources_json_obj
  build/X86/python/gem5/resources/resource.py(168): __init__
  materials/testing-resources/x86_matrix_multiply_omp_example.py(22): <module>
  build/X86/python/m5/main.py(597): main

I used x86-matrix-multiply-omp for testing, but other affected resources include x86-bubblesort, x86-floatmm, and riscv-bubblesort.
I was able to get past this error message by changing the link in _get_resources_json_uri() to
https://raw.githubusercontent.com/gem5/gem5-resources/stable/resources.json. It now looks like this:
def _get_resources_json_uri() -> str:
    #return "https://resources.gem5.org/resources.json"
    return "https://raw.githubusercontent.com/gem5/gem5-resources/stable/resources.json"

After this change, an HTTP 404 error occurred. I attempted to access the url for x86-matrix-multiply-omp in resources.json and observed that no file was hosted there.
To fix this, I set the environment variable for "GEM5_RESOURCE_JSON" to the file path to my local copy of resources.json. Then, I changed the url in the json to a url from the gem5 resources website. The change to the environment variable was in the function definition of _get_resources_json(), in build/X86/python/gem5/resources/downloader.py.
old url:
{url_base}/test-progs/matrix-multiply-omp/x86-matrix-multiply-omp-20230127

where url_base is http://dist.gem5.org/dist/v22-1

new url:
http://dist.gem5.org/dist/develop/test-progs/matrix-multiply-omp/x86-matrix-multiply-omp-20230127

At this point, the script was able to obtain the resource.
I attempted to use the same fix for x86-floatmm and x86-bubblesort, but they were both absent from the json.

I think the linked pull request will fix this.

@erin-le : I think that just fixed the error. Can you try this again and co firm it works for you?

I'm a little confused here. have you been using v<IP_ADDRESS> this whole time or did you just recently upgrade? v<IP_ADDRESS> should use our mongo database, not the file hosted at https://resources.gem5.org/resources.json.

Both the issues described here are fixed with gem5/gem5-resources-website#6 and #153.


Sync to rancher charts

Related pr: https://github.com/rancher/charts/pull/1595

@aiyengar2 Please help to review this pr.

@aiyengar2 Please help to review this pr. It's the modification of the pr https://github.com/rancher/charts/pull/1595. We will release a new version and sync it to rancher charts.

Updated. Ask for a re-review. Thank you. @aiyengar2

LGTM
@yaocw2020 can you create an issue for harvester to later add support for deployment on hardened clusters and CIS scan support? We can prioritize that in a future release.

https://github.com/harvester/harvester/issues/1570


fix for a dead link

https://github.com/CBPP/cbppsubmit does not exist anymore.
Changed to https://github.com/CBPP.
Also added "for".

Awesome, thanks!


Add cotp to Apps using tui

Description
Hi, i wanted to add my command-line TOTP authenticator app to your list becouse i'm using tui-rs and it's pretty good.
Thanks for making this library.
Regards.
Checklist

[ x ] I have read the contributing guidelines.
[ x ] I have added relevant tests.
[ x ] I have documented all new additions.

Done in https://github.com/fdehau/tui-rs/pull/659


Config changes to reflect the default branch from master to main. Please merge to complete the default branch renaming job.

Auto branch renaming content.

Docs Build status updates of commit 2c50618:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error: GitBranchDeletedOrForcePushed] Cannot sync git repo to specified commit because branch d7cb8833-bac4-44c0-b387-5f6b556a6a03 has been deleted or has been force pushed

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


227 upgrade deconnection protocol

Part 2/2 of deconnection functionnality
Implement SigInt gestion on server side :

When a SigInt is catched, the current room tell to all his player to disconnect (Protocol 13).
The game status is passed to ENDED

Optimization of the room process loop :

When no active client left and no places remaining, room status is pass to ENDED
When no active client left but places remain, room status is pass to LOBBY
Add an anti-lag functionality inside movement system (When there is more than one second of elapsed time, no movement is applied)

Refactoring of the Frequency Component / System :

Move all the frequency operation inside the UpdateClock system
Creation of a templated function to update all frequencies derived component
Update old frequency to match the new system

Implementation of the AFK Gestion :

When a player does not make action in the last 10 seconds, the server kick him from the game (Protocol 13 + Erasing of his current game data)
Update the last interaction time for -> Shooting, Moving

Fixing some minor bugs :

A client can now connect multiple time on the same address + port after a kick / death
Erasing Room data of a client when his dead.

Change end game detection for client side :

Now, the room instance send a protocol 13 to the client to kick him from the game. (In future, we can pass data with protocol 13 to specify which type of kick is it)

Updating old testing :

Update of the Movement system testing
Update of the EnemiesGoesRandom testing

Everything is now much more smoother for player interaction with the room.

Codecov Report

Merging #235 (064d8c2) into master (619bd77) will decrease coverage by 1.15%.
The diff coverage is 19.23%.

:exclamation: Current head 064d8c2 differs from pull request most recent head 54b3f93.  Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Moved repeated constant declarations to a common location

Following up on moving all common constants to a common location instead of replicating them in each agent.

What's the deal with this PR @nordmark and @kalyan-nidumolu ? I kind of would like to see it merged.
LGTM from my side, btw.

Looking at a bunch of these but not all, turns out that many of them are only used by one agent. Hence it doesn't make sense to promote them to a common place.
If you look at client.go you'll find some more shared with diag.go but they are not used in more than those.
And at least two have become unused since you started this.
The appimg/baseosimg/certobj enum's (expressed as strings) can definitely be put in one place.
And picking one name for /config (as opposed to two different ones; IdentityDirname makes more sense than ConfigDirname IMHO) makes sense.

Moved back the following to individual files since they are local:

RwImgDirname = PersistDir + "/img"
checkpointDirname
PendingDirname = ImgCatalogDirname + "/pending"
FinalDirname = ImgCatalogDirname + "/verified"
PersistRktLocalConfigDir = PersistDir + "/rktlocal"
PersistRktLocalConfigAuthDir = PersistRktLocalConfigDir + "/auth.d"

Moved some others to the agent if they are only being used by 1 agent.
Similar to /config, the following location also has 2 names:
FinalDirname = ImgCatalogDirname + "/verified"
// VerifiedDirname - Location of verified App images. Read-only images
// named based on sha256 hash each in its own directory
VerifiedDirname = ImgCatalogDirname + "/verified"

which one is better? "VerifiedDirName" seems to be the better name??

@kalyan-nidumolu are you planning to take care of the duplicate names for the same constant so we can pull this?

Done..  Eliminated all direct duplicates.. There are a few derived ones that can be replaced as well, but will do that in a separate commit. Lets get this one in - The diff is getting bigger..

On 10/16/19 12:22 PM, kalyan-nidumolu wrote:

@kalyan-nidumolu commented on this pull request.

In pkg/pillar/types/locationconsts.go
https://github.com/lf-edge/eve/pull/254#discussion_r335664117:

DownloadDirname = PersistDir + "/downloads"

// ImgCatalogDirname - Location for App Images
ImgCatalogDirname = DownloadDirname + "/" + appImgObj
// VerifiedDirname - Read-only images named based on sha256 hash each
// in its own directory

// ObjectDownloadDirname - Location of downloaded objects
ObjectDownloadDirname = PersistDir + "/downloads"

Hmm.. Thinking was.. The same directory could be used for different
purposes.. So could use different names.. Fixed it by doing:
ObjectDownloadDirname = DownloadDirname

That argument doesn't make any sense to me. Everything we download is an
object. No reason to have two different global names for the same
directory.

Will look through some of these usages to see if it good to replace
ObjectDownloadDirname with DownloadDirname...

Please replace them all so we can get this PR done.
Erik

—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/lf-edge/eve/pull/254?email_source=notifications&email_token=AGNLQWAJBX2MPM2P3XOZHG3QO5SXFA5CNFSM4IUQRW22YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCIGKH7I#discussion_r335664117,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGNLQWE2NIOQESA7K7OTAC3QO5SXFANCNFSM4IUQRW2Q.

On 10/16/19 12:22 PM, kalyan-nidumolu wrote: @.**** commented on this pull request. ------------------------------------------------------------------------ In pkg/pillar/types/locationconsts.go <#254 (comment)>: > DownloadDirname = PersistDir + "/downloads" - // ImgCatalogDirname - Location for App Images - ImgCatalogDirname = DownloadDirname + "/" + appImgObj - // VerifiedDirname - Read-only images named based on sha256 hash each - // in its own directory + // ObjectDownloadDirname - Location of downloaded objects + ObjectDownloadDirname = PersistDir + "/downloads" Hmm.. Thinking was.. The same directory could be used for different purposes.. So could use different names.. Fixed it by doing: ObjectDownloadDirname = DownloadDirname
That argument doesn't make any sense to me. Everything we download is an object. No reason to have two different global names for the same directory.
Will look through some of these usages to see if it good to replace ObjectDownloadDirname with DownloadDirname...
Please replace them all so we can get this PR done. Erik
…
— You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#254?email_source=notifications&email_token=AGNLQWAJBX2MPM2P3XOZHG3QO5SXFA5CNFSM4IUQRW22YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCIGKH7I#discussion_r335664117>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGNLQWE2NIOQESA7K7OTAC3QO5SXFANCNFSM4IUQRW2Q.

Done..


mako sans IFD

Sorry, I'm not going to look into this myself. Just want to get notified if/when 😅.

This is noted in the FAQ https://github.com/catppuccin/nix#-faq under the IFD question.

Closed in favor of https://github.com/catppuccin/nix/issues/392


Maybe a bug?

The ablities of [Monk - Way of the Distant Hand] dont apply to Enchanted_Longbow/Enchanted_Shortbow, only original version can work
TEST.zip
.
May be annoying.
Previous request:
Is there anyway to make stacksize bigger (99 or 999)?
Would it be possible to make classes [LEARN ONE spell] instead of [UNLEARN ONE spell then LEARN TWO spells] when levelup?

We cannot reproduce on latest QA release. No plans to change stack size of change how spells are learned .


Invalid email error, empty email field using GitLab as provider

I am experiencing this issue (#60) as well. I am running in overlay mode and have one whitelisted e-mail address. Identity provider is GitLab. The e-mail field is empty causing a "Not Authorized" error.
Log file:
time="2020-02-17T15:22:03Z" level=debug msg="Starting with options: {\"LogLevel\":\"debug\",\"LogFormat\":\"text\",\"AuthHost\":\"\",\"CookieDomains\":[{\"Domain\":\"example.com\",\"DomainLen\":12,\"SubDomain\":\".example.com\",\"SubDomainLen\":13}],\"InsecureCookie\":false,\"CookieName\":\"_forward_auth\",\"CSRFCookieName\":\"_forward_auth_csrf\",\"DefaultAction\":\"auth\",\"DefaultProvider\":\"oidc\",\"Domains\":null,\"LifetimeString\":43200,\"Path\":\"/_oauth\",\"Whitelist\":[\"redacted@users.noreply.gitlab.com\"],\"Providers\":{\"Google\":{\"ClientID\":\"\",\"Scope\":\"\",\"Prompt\":\"\",\"LoginURL\":null,\"TokenURL\":null,\"UserURL\":null},\"OIDC\":{\"Config\":{\"ClientID\":\"redacted\",\"ClientSecret\":\"redacted\",\"Endpoint\":{\"AuthURL\":\"https://gitlab.com/oauth/authorize\",\"TokenURL\":\"https://gitlab.com/oauth/token\",\"AuthStyle\":0},\"RedirectURL\":\"\",\"Scopes\":[\"openid\",\"profile\",\"email\"]},\"IssuerURL\":\"https://gitlab.com\",\"ClientID\":\"redacted\"}},\"Rules\":{},\"Lifetime\":43200000000000,\"CookieDomainsLegacy\":null,\"CookieSecureLegacy\":\"\",\"ClientIdLegacy\":\"\",\"PromptLegacy\":\"\"}"

time="2020-02-17T15:22:03Z" level=info msg="Listening on :4181"

time="2020-02-17T15:24:23Z" level=debug msg="Authenticating request" headers="map[Accept:[text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8] Accept-Encoding:[gzip, deflate, br] Accept-Language:[en-US,en;q=0.5] Cookie:[_forward_auth=QukNvOaeDrdgPha876Pdn9EyRmLEfFcrJqqctDUO2MM=|1581995233|] Dnt:[1] Upgrade-Insecure-Requests:[1] User-Agent:[Mozilla/5.0 (X11; Linux x86_64; rv:73.0) Gecko/20100101 Firefox/73.0] X-Forwarded-For:[<IP_ADDRESS>] X-Forwarded-Host:[example.com] X-Forwarded-Method:[GET] X-Forwarded-Port:[443] X-Forwarded-Proto:[https] X-Forwarded-Server:[cd8bb7cff384] X-Forwarded-Uri:[/] X-Real-Ip:[redacted]]" rule=default source_ip=redacted

time="2020-02-17T15:24:23Z" level=error msg="Invalid email" email= source_ip=redacted

This is my docker-compose:
  traefik-oauth:
    container_name: traefik-oauth
    image: thomseddon/traefik-forward-auth:2.1-arm
    environment:
      - DEFAULT_PROVIDER=oidc
      - PROVIDERS_OIDC_ISSUER_URL=https://gitlab.com
      - PROVIDERS_OIDC_CLIENT_ID=<redacted>
      - PROVIDERS_OIDC_CLIENT_SECRET=<redacted>
      - SECRET=<redacted>
      -<EMAIL_ADDRESS>      - COOKIE_DOMAIN=example.com
      - LOG_LEVEL=debug
    networks:
      - proxy-net
    labels:
      - "traefik.enable=true"
      - "traefik.http.services.oauth-secured.loadbalancer.server.port=4181"
      - "traefik.http.routers.oauth-secured.entrypoints=web-secured"
      - "traefik.http.routers.oauth-secured.rule=Host(`auth.example.com`)"
      - "traefik.http.routers.oauth-secured.tls.certresolver=mytlschallenge"

These are my GitLab settings:

I should also note that my profile and e-mail address are all set to public on GitLab.
GitLab documentation states the following with regards to OpenID Connect:

Only the sub and sub_legacy claims are included in the ID token, all other claims are available from the /oauth/userinfo endpoint used by OIDC clients.

Source: https://docs.gitlab.com/ee/integration/openid_connect_provider.html

Encountered the same issue today.

It seems as if GitLab is not following the official OpenID connect implementation by exposing all other claims under the /oauth/userinfo endpoint (including e-mail address). Maybe a change on the side of traefik-forward-auth could account for this?
https://gitlab.com/gitlab-org/gitlab/issues/21560

I think it would be a better idea to allow GitLab trough oAuth2.

Hmm, that's a pain! I agree it would probably be easier to just add a customer gitlab provider as opposed to an extra workaround in the OIDC code.

Unfortunately, the same applies to GitHub.
There's an example of how OpenID Connect can still be used with GitHub, by providing the required endpoints manually: https://fusionauth.io/docs/v1/tech/identity-providers/openid-connect/github

Is this issue accepting PRs?
This is a relatively simple bug. GitLab provides a UserInfo endpoint (example from gitlab.com). According to the OIDC specs, when requesting claims using scopes,

The Claims requested by the profile, email, address, and phone scope values are returned from the UserInfo Endpoint [...]

Traefik Forward Auth does not currently query the UserInfo endpoint but expects the claims as part of the id_token:
https://github.com/thomseddon/traefik-forward-auth/blob/529e28d83bca652720db72906b24e6e41a3dbf82/internal/provider/oidc.go#L88-L101

GitLab will soon add the email claim to the ID token, which will make this obsolete for GitLab.

This should now be doable using the generic oauth provider, I'll test with gitlab this week, add some docs and update this issue

I have the same issue with GitHub also my X-Forwarded-User is empty.

Ahh sorry just read:

Note: as per Github's documentation, their /user endpoint only returns the user's email if it's publicly visible. As such, you will not be able to use the User Restriction features with the Github provider, unless all your users have their email addresses public.

@maxisme That paragraph is outdated. If the application has the email claim, it will be able to read the primary email address of the user even when that is not public.

@thomseddon Is it not possible to introduce another whitelist for github to check the login (username) or name instead of the email?

GitLab works fine for me with OIDC. This is the working base config:
env:
        DEFAULT_PROVIDER="oidc"
        PROVIDERS_OIDC_ISSUER_URL="https://gitlab.com"
        SECRET="${cookie_secret}"

service config for the traefik-forward-auth task (I'm on Nomad)
{
[...]
      namespace: traefik
[...]
      service {
        name = "traefik-forward-auth"
        provider = "nomad"
        port = "http"
        tags = [
          "traefik.enable=true",
          "traefik.http.middlewares.traefik-auth.forwardauth.address=https://auth.example.com",
          "traefik.http.middlewares.traefik-auth.forwardauth.authResponseHeaders=X-Forwarded-User",
          "traefik.http.routers.traefik-auth.entrypoints=websecure",
          "traefik.http.routers.traefik-auth.rule=Host(`auth.example.com`)",
          "traefik.http.routers.traefik-auth.tls=true",
          "traefik.http.routers.traefik-auth.tls.certresolver=letsencrypt"
        ]}
}

demo task:
    service {
      name = "demo-webapp"
      provider = "nomad"
      port = "http"
      tags = [
        "traefik.enable=true",
        "traefik.http.routers.demoapp-secure.rule=Host(`demoapp.example.com`)",
        "traefik.http.routers.demoapp-secure.entrypoints=websecure",
        "traefik.http.routers.demoapp-secure.tls=true",
        "traefik.http.routers.demoapp-secure.tls.certresolver=letsencrypt",
        "traefik.http.routers.demoapp-secure.middlewares=traefik-auth@nomad-traefik"
]}

the demoapp.example and auth.example.com (example.com is of course replaced my own domain) dns records are both public.
In GitLab I have created an app with the following scopes, it's more than needed here I think because I use it also for other apps: api,read_user,openid,profile,email
The redirect uri is this: https://demoapp.example.com/_oauth
Maybe it's a help for someone in the future


Test run returns > options(error=expression(NULL)) on Ubuntu

Hi.
I run the following code:
$r = new RCore(new CommandLineREngine('R'));
echo $r->run("5+3");

On my Mac it works as expected, but when I run it on Ubuntu server it returns just
> options(error=expression(NULL))

UPDATE
I've found out that there's something wrong with end of line.
If i run something like this:
echo $r->run("5+3\n");

then it returns both 'options(...' and the result of the operation in the returning string

Hi @ukebako,
I haven't tested the code in ubuntu, so there might be problems as you describe. Feel free to contributed to the repository by submitting a pull request if you find a robust and cross-platform solution to what you've discovered.

Same problem here. @ukebako did you eventually solve the issue?

Actually adding \n at the end of expression was enough for me. I just grab what I need from the output.

Thanks, @ukebako , the "\n" trick did work for me except the leading "options(error=expression(NULL))".
I was wondering whether you were able to remove that leading string.
But, anyhow, you trick helped a lot.

I commented out line 45 in CommandLineRProcess.php but I doubt that is the correct solution
fwrite($this->pipes[0], "options(error=expression(NULL))\n");

ohkay . how to make it work on fedora 24 too?


Improved logic for positioning of context submenus

removed display:inline style from context menu otherwise the width was
0
made the submenu appear left on right based on the available space
todo: RTL have to be done the same

solved #1310

Thank you :)


Support migration from Umbrel 0.5

Closing as complete - https://community.start9.com/t/howto-migrate-from-umbrel-0-5-x-to-embassy


Updates onp -> np in random, loops, optix and their tests

Looks good! I think some of these files may have changed in the meantime; can you rebase on master and force-update?

@jakevdp like this? Sorry, I'm not very proficient with git :/

No, something strange happened: it looks like you added your new changes to the most recent commit on master? I'm honestly not sure what's going on with your branch right now...

I tried rebasing :(, guess I can kill this PR and start again

What I meant is for you to run (assuming upstream points to http://github.com/google/jax and origin points to http://github.com/joaogui1.jax)
git fetch upstream master
git rebase upstream/master
git push -f origin master

But at this point, you've rewritten your history enough that that won't do the right thing...

In general things will be cleaner if you develop new features on a branch other than master

In general things will be cleaner if you develop new features on a branch other than master

yeah, I realized my mistake after I had already changed many files, should have fixed it before opening the PR, thanks for the tip!


Add OAuth2 html to flasgger routes

Even though the oauth2 redirect HTML is available in the template folders, there is no way to use them properly as they are not made available through Flask.
In this PR I made said HTML available through the blueprints as well as adding an "auth" configuration that can be read as the configuration for the Swagger UI ui.initOAuth to initialize it properly.

@billyrrr Any chance to get that ongoing?

Definitely. I will review it soon. Meanwhile, would you @GitTiago @piotrmoszkowicz  like to add some test cases / examples to show that the feature fails without this commit? Thank you.

@billyrrr Hi! I would like to come back to resolving that issue. What kind of test cases are you expecting me to write (because actually that's just adding a single route). Could you review it please?

Yep, I'll review it. Sorry for the delay. Should get to it today.

@GitTiago Thank you again for this useful feature contribution, but OAuth feature in Flasgger can be risky as the system was not fully tested for XSS attacks and other potential vulnerabilities. I want to do my best to ensure that this feature is included while not compromising the security (such as leaking production credentials). I believe the best plan would be to fork and create a repository called flasgger-oauth, and I can do everything that I can to make current Flasgger project extendable and compatible with your release. As I become more familiar with the OAuth features in swagger, I will merge your changes. Alternatively, I can include you as one of the maintainers of Flasgger, and you can merge the change as you see fit. What do you think?

Hello @billyrrr . I created this PR a longtime ago. I understand your concerns and why you would not merged it as it is.
All it is really doing is making available two pages already available in the repository as well as allow oauth to be configurable through the template.
That being said, while I appreciate the offer, I am not really currently available for becoming the maintainer of the repository nor to maintain a fork of it.
OAuth support is something that swagger ui provides and it was something that I had to work around at the time in order to use flasgger. I thought it might be useful to more people. I will leave it to you, and the community, to decide what to with the PR and issue.


When you stop an adapter, you have to refresh your browser before you see it has stopped

Describe the bug
In the Frank!Console, I stopped an adapter. The adapter stop button turned into an orange cog as expected. However, the orange cog was not automatically replaced by a green adapter start button. I had to refresh my browser before this happened.
Reporter
Martijn Dirkse
Category

Frank Console

To Reproduce
Steps to reproduce the behavior:

Start the Frank!Runner with some config.
Expand an adapter on the Adapter Status page.
Press its stop button.
Wait some time. The orange cog remains there.
Refresh your browser page. Only now you see the green adapter start button.

Expected behavior
The orange cog should turn into the green adapter start button automatically.
Screenshots

Environment:

Frank!Runner
Microsoft Edge
FF! 7.6-20200701.142340

Additional context
Add any other context about the problem here. (f.e. ladybug report / test adapter with larva test)

It seems to be working fine on all the applications I've tested. How long did you wait? Sometimes it can take longer then 5 seconds before it updates.

I have not seen this issue anymore.

I tested one more time and I did not reproduce the issue. I did this by loading Frank2Example3 and stopping and starting all adapters. I mean adapter 01 to adapter 04 inclusive.


Android webrtc stream often doesn't play

In the Android HA app, streams get into "Connected" state but fail to actually play about 50% of the time. Quitting the app and then coming back eventually will get it to work. On desktop Chrome, it seems to be 100% reliable.

This also seems to happen on mobile Chrome, so maybe it's an Android issue?

At this point, the browser tries to load the video stream. Problems often depend on the specific camera

I also noticed this issue with an Android Tablet and newer versions of webrtc.
With version 1.4.0 also the app fully kiosk browser crashes after some minutes if the stream is not displayed.

Maybe tablet performance is not enough for this technology

It's not a powerful tablet but sufficient for wall mounting. I revert to version 1.1.0 which is working.

Can you check 1.2 and 1.3?

1.2 is working. Now I try 1.3 but as I know here starts the issue that the stream is not showen in all cases but doesn't crash the fully kiosk browser.

What model is your tablet?

LIFETAB_P733X (LENOVO), Android version 5.0.2 (SDK 21). It was not so easy to find a tablet which looks similar to an GIRA G1 Controller ;-) .

Version 1.3.0 also works since yesterday.

Ditto...  I am experiencing this on every platform.  My Android tablets are powerful, and I see the same issue on my PC.  All instances are via Chrome browser.
It seems more frequent when I switch around between several cameras.
Are the connections being closed when views are not visible, and re-opened when they become visible?
For me, the problem is also more frequent over wifi than over ethernet (eg, on my PC).  Even if it is network traffic related, is it possible to be more aggressive about closing and reconnecting the stream when is pauses/disconnects (eg, more robust)?
It is still a great improvement over HA builtin streaming!!!


Http client

There are 2 parts to this PR (in 2 commits)

Clean up the HTTP server so that it reuses the existing machinery from Trace
Create an HTTP client for all the endpoints

I am actually unsure where to go from here. The client can't fit into Trace since that contains EmulatedWalletApi which is a wrapper around StateT WalletState. Basically I'm unsure how or where we now use this client?
Anyway, that would be the remit of another PR, I don't think it should stop this PR being merged.

I don't understand your question:

I am actually unsure where to go from here. The client can't fit into Trace since that contains EmulatedWalletApi which is a wrapper around StateT WalletState. Basically I'm unsure how or where we now use this client?

My initial thought was that we would do something like this:

process trace produces a MonadEmulator m => m a.
We provide functions to lift such a value into one of:

The in-memory interpretation provided by the main emulator module.
The implementation used by the HTTP backend.
A HTTP client implementation which makes calls to the backend.

That obviously doesn't work since MonadEmulator expects to operate in terms of the underlying state. So we want something that interprets the trace directly into a series of calls to the backend. The idea is still that you run exactly the same trace in any of the settings.

Okay, I think there's some confusion about what's going on here.
WalletAPI:
The wallet API is the API to the wallet. This includes actions that users can take with their wallets, and should return them errors etc. This is the thing that the real wallet will eventually implement, and which we're hoping to influence the design of. Most of the wallet endpoints in the HTTP server should be implementing this.
Trace:
This represents a series of events from the perspective of the smart contract system. That means it has a slightly different view: in particular, if wallet actions fail they just fail and that's the wallet's problem. The trace will continue just fine (as the real world would happily chug along if you submit a bad wallet action).
The only effect that wallet actions have in the Trace world is the side effect of adding transactions to the pending transaction pool. That's why their entry in the Event GADT has the signature that it does - you give us some action which produces no value (we could say it produces a value but we ignore it, I guess), and we get out the transactions that it produces (possibly none if it fails!).
Evaluating the WalletAction Events in a Trace therefore means evaluating the wallet action in your context, and then throwing away the error code and result and just getting the transactions.

Writing that has clarified my thinking too: we should not be evaluating Traces or Events in the HTTP backend, we should be evaluating wallet API actions. The emulator-specific endpoints are different, of course, since they deal with things that aren't in the wallet api, like assertions. But still, we shouldn't try to make the backend evaluate a Trace or even an Event (my bad for suggesting that we should!).
What does need to evaluate a Trace is HTTP-client based evaluator that will evaluate wallet actions using the HTTP wallet API, and then throw away the result value/error code and just return the new transactions.
--
Does that help?

Concretely, I think this means we should have an implementation of WalletApi in terms of the HTTP client. We could concievably then have a RestOfTraceAPI class (which would do things like validate transactions, run assertions etc.), implement that, and then write a generic Trace evaluator with both as a constraint.

OK, that helps, it's exactly what I thought before I started writing the code :-)
I was trying to re-use as much as possible but I think this PR has shown that that doesn't really work. I can refactor Types.hs a little bit in order to make some of the tools available but not use the trace stuff directly for the server.
Also it's easy to split up the API, it's already done actually, just need to make 2 http clients instead of 1 and then wrap up the wallet client behind the wallet API (my original intention).
So for this PR, I will put back the changes to the Trace stuff and change the HTTP server to not use it, I will also create a WalletAPI implementation for the http client and then perhaps see where we are. That will probably take me the rest of today anyway.

Cool, sorry for the mixed messages! I don't have this stuff quite loaded in my head at the moment.

One further thing that occurs to me: what we currently think of as WalletAPI is actually a combination of WalletUserAPI and WalletControlAPI. The user should not be able to tell the wallet that it's received a notification - that's controlled by the blockchain client it's using!
So we should probably break this up even more.

The user should not be able to tell the wallet that it's received a notification

It's walletRecvNotifications :: Wallet -> [Notification] -> Trace [Tx] so it requires a MonadEmulator constraint to run - I think the WalletAPI class can be implemented by a real wallet as it is (at least that was the intention behind splitting up the API into two parts in (CGP-377)[https://iohk.myjetbrains.com/youtrack/issue/CGP-377])

We should probably have a call or something to agree on a definition because I have been working with different assumptions about Trace. In particular

WalletAPI:
The wallet API is the API to the wallet. (...)

Agree

Trace:
This represents a series of events from the perspective of the smart contract system. (...)

Currently it is a series of events from the perspective of the emulator though. We can manipulate the global blockchain/mockchain state in a Trace, for example we we can say when a new block is created, and when wallets are notified of that.

The only effect that wallet actions have in the Trace world is the side effect of adding transactions to the pending transaction pool. (...)

Yes

Writing that has clarified my thinking too: we should not be evaluating Traces or Events in the HTTP backend, we should be evaluating wallet API actions. The emulator-specific endpoints are different, of course, since they deal with things that aren't in the wallet api, like assertions. But still, we shouldn't try to make the backend evaluate a Trace or even an Event (my bad for suggesting that we should!).

The intention behind this task (standalone mockchain) was to have an executable that implements the wallet HTTP API so that we can run plutus coordination code (compiled to JS) against it without having to rely on the real blockchain. But to achieve that the executable also needs to emulate the blockchain in order to give realistic responses for the wallet API. And the emulator in turn is controlled by Trace actions. If the standalone mockchain only implements the wallet API, but not the emulator API, then how do we advance the state of the blockchain?
So I think we should try to make the backend evaluate both WalletAPI and Trace actions, and that's what the two parts of the API in CGP-377 are about. If that's wrong then we need to change the task on YT. But again I think we should arrange a call to clarify this.

I think the WalletAPI class can be implemented by a real wallet as it is

Yes, but the real wallet shouldn't expose walletRecvNotification to a user! We want to segment those bits of the API.

Currently it is a series of events from the perspective of the emulator though. We can manipulate the global blockchain/mockchain state in a Trace, for example we we can say when a new block is created, and when wallets are notified of that.

Sure, that's more-or-less what I meant.

If the standalone mockchain only implements the wallet API, but not the emulator API, then how do we advance the state of the blockchain?

I definitely did not mean that it should only implement the wallet API, just that the bit which corresponds (will correspond) to the real wallet API should be clearly separate.
I agree having a call would be useful.

After talking with @michaelpj I think we can summarise the capabilities of the "standalone mockchain" as follows:

WalletAPI: Anything that can be run against a real wallet. Corresponds to

Part I in https://iohk.myjetbrains.com/youtrack/issue/CGP-377
Wallet.Emulator.Http.WalletAPI

Mockchain control API. Anything that controls the emulated blockchain. Corresponds to

Part II in https://iohk.myjetbrains.com/youtrack/issue/CGP-377 except walletRecvNotifications (see (3.) below)
Wallet.Emulator.Http.ControlAPI except the two "wallets" :> Capture "walletid" Wallet :> "notifications" endpoints

Wallet control API (new). The ability to notify a wallet of blockchain events. Represents communication from the cardano node to the wallet. This should be treated separately (perhaps a class NotifyWallet m) because in the future this might also be implemented by the real wallet for testing purposes (for example with a debug flag). This corresponds to

"emulator" :> "wallets" :> Capture "walletid" Wallet :> "notifications" :> "block-validation" :> ReqBody '[ JSON] Block :> Post '[ JSON] () and
"emulator" :> "wallets" :> Capture "walletid" Wallet :> "notifications" :> "block-height" :> ReqBody '[ JSON]
(the emulator bit should be replaced by wallet-control or similar)

The confusion was mostly about walletRecvNotifications which currently resides in the control API but should become its own API.
So for the PR this means:

https://github.com/input-output-hk/plutus/pull/214/files#diff-da394a94497e501c3cc7a1f43f3d9a81R66 should be type API = WalletAPI :<|> ControlAPI :<|> WalletControlAPI with the appropriate types (ie. merge AssertionsAPI into ControlAPI and extract the blockValidated and blockHeight endpoints into WalletControlAPI)
Revert the changes to the WalletAction constructor https://github.com/input-output-hk/plutus/pull/214/files#diff-66d9ee4fe6c0f85f4af266395458289bR203 - we care about the return values only if we use WalletAPI directly, not inside a Trace
Another issue that should be changed (unless it adds duplication) is that every wallet action is wrapped in a trace in runWalletAction. Example: https://github.com/input-output-hk/plutus/pull/214/files#diff-da394a94497e501c3cc7a1f43f3d9a81R112 Maybe it is possible to implement this in a way that doesn't require Trace.

In the future we should add an implementation of WalletAPI that uses a subset of the functions from https://github.com/input-output-hk/plutus/pull/214/files#diff-b7bde62939a8bbbc0fcb561c2975656aR4 and returns the correct results.

OK, I've made the changes suggested I think. I haven't wrapped up the client yet as I'm not quite sure how the classes will work but I'd prefer to keep that for the next PR as this is getting quite big. This PR should just now represent a refactoring of how the http server works as well as creating a client.
I will do a squash once it is approved.
In reality it was more of a learning experience for everyone :-)

Looks good now, I think you have to run generate.sh to update the nix expressions.

hydra is being silly, but this is failing the stylish haskell check: https://hydra.iohk.io/build/296337

oops, thought I'd run fixStylishHaskell already. pushed now.

Okay, this has in fact gone green.


Fixing README for Agentless scanning

renaming variables from 'agentless' to 'scanning' in README
updated the input and output variables
removing default value for scanning_account_id and making it a required variable, since now the value will be coming from the BE

removing default value for scanning_account_id and making it a required variable, since now the value will be coming from the BE

I accept the premise, but I remain uncertain this is actually a wise thing to do.  The degree to which these modules able to be invoked directly (without BE support) is a common ask, and the use cases are valid, IMO. However, we have never formally designed for this, and as such, support is hit or miss. This choice adds another miss.
Not advocated for hard coded constants of course, just trying to think of the big picture.

removing default value for scanning_account_id and making it a required variable, since now the value will be coming from the BE

I accept the premise, but I remain uncertain this is actually a wise thing to do. The degree to which these modules able to be invoked directly (without BE support) is a common ask, and the use cases are valid, IMO. However, we have never formally designed for this, and as such, support is hit or miss. This choice adds another miss.
Not advocating for hard coded constants of course, just trying to think of the big picture.

I see your point which we need to think about. However, my concern here is since this is a public repo shall we be mentioning our prod accountId, from security perspective?

I see your point which we need to think about. However, my concern here is since this is a public repo shall we be mentioning our prod accountId, from security perspective?

If this is a secret, then it should be treated that way -- scrubbed from the history of this repo, and changed. Ultimately it is not a secret of course. Disclosure of an account number is not actually a security issue, it just looks funny -- and it does. But, not delineating this distinction also says something -- not great.
This circumstance is actually more akin to using DNS names versus IPs. If such a thing as a globally unique account alias, publicly resolvable to the account ID, and controlled by the account owner, I doubt anyone would bat an eye, yet it'd be effectively the same exact thing. Normal AWS account aliases come close to this, but aren't readily "resolvable" by some standard mechanism.

I see your point which we need to think about. However, my concern here is since this is a public repo shall we be mentioning our prod accountId, from security perspective?

If this is a secret, then it should be treated that way -- scrubbed from the history of this repo, and changed. Ultimately it is not a secret of course. Disclosure of an account number is not actually a security issue, it just looks funny -- and it does. But, this distinction is important.
This circumstance is actually more akin to using DNS names versus IPs. If such a thing as a globally unique account alias, publicly resolvable to the account ID, and controlled by the account owner, I doubt anyone would bat an eye, yet it'd be effectively the same exact thing. Normal AWS account aliases come close to this, but aren't readily "resolvable" by some standard mechanism.

Hmm, let me add back the default for now, and we can circle back on this.
That's a good analogy, and I agree it will effectively be the same thing - using accountId or an account alias. FWIW one point here is, we would like to preferably keep the approach same whether its AWS, GCP or Azure in the future if and when we support scanning for other cloud environments. (maybe too much of future thinking here)


Consequencer updates and first CVecorder PR

Note that the doc in the firmware/contrib folder is needed as some old website articles link to this old location e.g. the gearnews article on consequencer.

It looks like the unit tests are now failing with changes to the menu import, PTAL: https://github.com/Allen-Synthesis/EuroPi/runs/6009089985?check_suite_focus=true

It looks like it's the "import micropython" line that is causing the
failure.
Kind Regards,
Nik
On Wed, Apr 13, 2022 at 4:26 PM Adam Wonak @.***> wrote:

It looks like the unit tests are now failing with changes to the menu
import, PTAL:
https://github.com/Allen-Synthesis/EuroPi/runs/6009089985?check_suite_focus=true
—
Reply to this email directly, view it on GitHub
https://github.com/Allen-Synthesis/EuroPi/pull/121#issuecomment-1098117537,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACKZSUITPH2JJBO2NAEJZATVE3KQBANCNFSM5S5BNBBQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

The only remaining change I'd like to see before merge is the removal of europi-front.png (which appears to be unused) and previous-pcb-design-build-instructions.png. I discussed my reasoning for the latter file in a previous comment:

Also, regarding docs/previous-pcb-design-build-instructions.png I'm not sure that an image file is the best way to commit build instructions. It will be very difficult for anyone to make changes to it. Also it references previous designs, which can get confusing. I'd like to suggest removing this file in favor of making any appropriate changes to https://github.com/Allen-Synthesis/EuroPi/blob/main/hardware/build_guide.md

previous-pcb-design-build-instructions.png and europi-front.png docs removed.
Fix for calibrate.py added.
output4isClock now accessible via the UI.
Added function timing code, but commented out - I will use this in the future.
Removed detail from CVecorder now reads "CVecorder: Added"

Thanks for sharing another amazing script!


Link to notebook app on git error?

When nbinteract displays an error, students might be left wondering how to proceed. I think we need to provide a link to the user's notebook server when this happens. Something like the image below. Thoughts?

This looks like a good idea. I can make the link configurable through an env var like ERROR_REDIRECT_URL or something like that, but I'll make the default the datahub link. Would this work?

I think the env var is a good idea since it would give other admins the opportunity to point at documentation or some such. Can the default be the hub's base_url rather than datahub specifically?
Here's an example when baseurl is in the javascript:
https://github.com/ryanlovett/nbrsessionproxy/blob/master/nbrsessionproxy/static/tree.js#L8

Sure, yeah. That's probably a better idea. So maybe, if the env variable is not specified, a javascript script can default to the hub's base url, like you mentioned.

Sounds good to me, thanks!
Ryan
On Thu, Jan 26, 2017 at 11:48 AM, Peter Veerman<EMAIL_ADDRESS>wrote:

Sure, yeah. That's probably a better idea. So maybe, if the env variable
is not specified, a javascript script can default to the hub's base url,
like you mentioned.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/data-8/nbinteract/issues/10#issuecomment-275493363,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJxfvQZufmZH_d597TANfVHaGfVu3trBks5rWPifgaJpZM4LuIOn
.

OK, I made the changes to Interact. If ERROR_REDIRECT_URL is set, it will use that link. ERROR_REDIRECT_URL must have either 'http://' or 'https://' included. If it is not set, it will just use a link of the hub's base url.

Sweet, thanks!
Ryan
On Thu, Jan 26, 2017 at 3:33 PM, Peter Veerman<EMAIL_ADDRESS>wrote:

OK, I made the changes to Interact. If ERROR_REDIRECT_URL is set, it will
use that link. ERROR_REDIRECT_URL must have either 'http://' or 'https://'
included. If it is not set, it will just use a link of the hub's base url.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/data-8/nbinteract/issues/10#issuecomment-275547694,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJxfvVY3e2P401VpiU4fngDr-GKZ3oCmks5rWS1cgaJpZM4LuIOn
.


Always start from the beginning of string

[Continuation of Twitter discussion]
Currently proposal uses stored lastIndex instead of starting with the beginning of string, which makes it confusing when used in combination with <=ES5 methods that do make use of lastIndex and thus iterator will start from an implicit internal position from unrelated call and won't really "match all" occurences as naming implies.
IMO, it would make more sense to always start from the beginning of the string, so that iterator wouldn't conflict with earlier exec calls and would behave in the same way independently from context.

One interesting collision between this and #6 is that the whole point of the sticky flag is to respect lastIndex - if matchAll respected sticky but ignored lastIndex, I'm not sure that would make sense or be consistent.
I wonder if it would be better, instead of ignoring lastIndex, to take an optional second parameter startingIndex, which when omitted, defaulted to the lastIndex property? Then you could str.matchAll(regex, 0) and always be guaranteed it would start at zero, without needing to cripple someone who wanted to rely on the lastIndex property to govern initial behavior?

One interesting collision between this and #6 is that the whole point of the sticky flag is to respect lastIndex - if matchAll respected sticky but ignored lastIndex, I'm not sure that would make sense or be consistent.

Not really - you still do use and respect sticky flag and respect lastIndex in between calls, so regex will still follow semantics. Take a string 1,2,3.

matchAll(/\d+/) will return only first match - 1.
matchAll(/\d+/g) will return all the numbers - 1, 2, 3.
matchAll(/^\d+/y) will return only first match - 1 because lastIndex in between points to , and sticky regexp tries to match ^\d+ starting from it, which obviously fails - so sticky would mean "^ has to match following regular expression right after the last match and not from the beginning of original string nor anywhere else".

In all those case, matchAll still does match all - like, entire string, and at the same times all the flags are respected in the context of each iterator.

(I believe this comment / discussion belongs to #6 more, so let's continue there)

OK, given the direction from #6, I think this question still applies.
I think the possible ways to handle lastIndex are the following:

ignore the provided regex's lastIndex, always start at zero
respect the provided regex's lastIndex, start there
Do either one of the above, and optionally receive a second startingIndex argument that when provided overrides the previous behavior.

In all cases, lastIndex would not be mutated on the provided regex.
One thing I think it's important to consider here is that the trivial case - a literal regex on a small string - is not the only thing this needs to account for. RegExp subclasses might exist that would match infinitely, for example - or, this might simply be a very very large portion of text, and you might know you already want to skip it - and simply slicing the large string might not be friendly to memory or performance.
I think there does need to be some way for the user to provide a starting index, and my initial thought was to just use the conventional method for this - the lastIndex property. My assumption is that in the common case, in a world where you don't need exec anymore, every regex's lastIndex will be at 0 anyways.

simply slicing the large string might not be friendly to memory or performance

Not really - as I pointed, none of engines actually copies substrings on slicing as they're immutable, instead they create minimalisting object that just points to the same memory and contains offset + length of the chunk. There were even a lot of complaints from V8 users that one-character slice of a huge string prevents GC from collection original string at all during the lifetime of this slice. Of course, this can be considered implementation-specific, but if we're taking performance into account, it's impl-specific anyway, and currently any engine deals well with it.

My assumption is that in the common case, in a world where you don't need exec anymore, most every regex's lastIndex will be at 0 anyways.

Probably you're right... It's just that taking lastIndex into account by default feels like a potential root of more "gotchas" than if defaulting to beginning of string and asking developer to explicitly slice original string or pass 2nd argument with r.lastIndex should you really want to use it - it's not too hard to do, and will be more transparent IMO for cases when developer really wants it.

Also, one more thought - we should probably still expose lastIndex from iterator object itself (as in opposite to old regexp-bound property). This can be useful for some cases e.g. regexp with sticky flag, where we want to know whether our "tokenization" matched entire string or stopped somewhere in the middle as following text didn't match so that we could handle error / try another regexp / whatever. Otherwise, regexpregexpregexp something something regexp and regexpregexpregexp return same list of matches and it becomes impossible to figure out whether and where the error occured.

@RReverser Can you file a new issue for that last one?

@ljharb Sure.

Deleted comment here, raised as #7.

What's the conclusion here--should we copy the lastIndex over, or always start from 0? (Note: I imagine a common use case will be to use a particular RegExp only with matchAll, and that would make this issue not come up.)

I think that the existence of the sticky flag makes lastIndex something we can't ignore; "sticky" is something for people to trip up on already, and we can't just gloss over it.
Per https://github.com/tc39/String.prototype.matchAll/issues/5#issuecomment-158779757, I think we have to respect lastIndex, and I also think that virtually nobody will accidentally pass in a regex with a nonzero lastIndex.

Closing, since we're going to stick with respecting lastIndex.


Link to GitHub Repo on documentation page?

Welcome!

[X] Yes, I've searched similar issues on GitHub and didn't find any.
[X] Yes, I've searched similar issues on the Traefik community forum and didn't find any.

What did you expect to see?
Would it be possible to put a link to the github repo on the documentation page: https://helm.traefik.io/traefik ?
Because if you have a local chart which references this URL and clicking on it and you want to know details like which traefik version is included in which chart version, then newbies are lost.

Hi @mfriess2,
Thanks for your interest in Traefik !
Wdyt about the linked PR ?

Great, thank you!


Onboard team repositories to developer portal

Include our team's repositories on the portal as a proof of concept.

I have not done every repo but have done one of every "backstage" component which can be used for development purposes and an example for other team.
If we bring this out of PoC then I will reopen this ticket and do the rest.


Update related.md

correcting link from ancient Hilgraeve HyperTerminal (https://en.wikipedia.org/wiki/HyperACCESS) to current Hyper.is (Electron terminal)

Thanks!


Missing parameters and wrong predictions

Hi,
I have downloaded model pretrained weights (file APViT_RAF-3eeecf7d.pth) following the link in README and tried to run the model architecture on some sample images.
I am loading the model with this code snippet
cfg = mmcv.Config.fromfile("configs/apvit/RAF.py")
cfg.model.pretrained = None

# build the model and load checkpoint
classifier = build_classifier(cfg.model)
load_checkpoint(classifier, "pretrained/APViT_RAF-3eeecf7d.pth", map_location='cpu')
classifier = classifier.to("cuda")
classifier.eval()

but I get some warnings
unexpected key in source state_dict:
output_layer.0.weight, output_layer.0.bias, output_layer.0.running_mean, output_layer.0.running_var, output_layer.0.num_batches_tracked, output_layer.3.weight, output_layer.3.bias, output_layer.4.weight, output_layer.4.bias, output_layer.4.running_mean, output_layer.4.running_var, output_layer.4.num_batches_tracked, body.21.shortcut_layer.0.weight, body.21.shortcut_layer.1.weight, body.21.shortcut_layer.1.bias, body.21.shortcut_layer.1.running_mean, body.21.shortcut_layer.1.running_var, body.21.shortcut_layer.1.num_batches_tracked, body.21.res_layer.0.weight, body.21.res_layer.0.bias, body.21.res_layer.0.running_mean, body.21.res_layer.0.running_var, body.21.res_layer.0.num_batches_tracked, body.21.res_layer.1.weight, body.21.res_layer.2.weight, body.21.res_layer.3.weight, body.21.res_layer.4.weight, body.21.res_layer.4.bias, body.21.res_layer.4.running_mean, body.21.res_layer.4.running_var, body.21.res_layer.4.num_batches_tracked, body.22.res_layer.0.weight, body.22.res_layer.0.bias, body.22.res_layer.0.running_mean, body.22.res_layer.0.running_var, body.22.res_layer.0.num_batches_tracked, body.22.res_layer.1.weight, body.22.res_layer.2.weight, body.22.res_layer.3.weight, body.22.res_layer.4.weight, body.22.res_layer.4.bias, body.22.res_layer.4.running_mean, body.22.res_layer.4.running_var, body.22.res_layer.4.num_batches_tracked, body.23.res_layer.0.weight, body.23.res_layer.0.bias, body.23.res_layer.0.running_mean, body.23.res_layer.0.running_var, body.23.res_layer.0.num_batches_tracked, body.23.res_layer.1.weight, body.23.res_layer.2.weight, body.23.res_layer.3.weight, body.23.res_layer.4.weight, body.23.res_layer.4.bias, body.23.res_layer.4.running_mean, body.23.res_layer.4.running_var, body.23.res_layer.4.num_batches_tracked

missing keys in source state_dict: projs.0.weight, projs.0.bias

Then I am loading some images in which I am first using MTCNN to crop around person face (to make them more similar to RAF DB) and processing with this torch transformations that should replicate the ones in the config files
test_preprocess = transforms.Compose([
                           transforms.Resize((112, 112)),
                           transforms.ToTensor(),
                           transforms.Normalize(
                                      mean=[x/255 for x in [123.675, 116.28, 103.53] ],
                                      std=[x for x in [58.395, 57.12, 57.375] ]
                           )
])

and running inference with
out = classifier(tensor_in.to("cuda"), return_loss=False)
out = [np.argmax(o) for o in out]

but what I get is always class 6 no matter the expression person has in input image.
Am I doing something wrong in either model loading or preprocessing ?
Thanks for your support
Current Environment:

Python 3.7.13
mmcls 0.25.0
mmcv-full 1.7.1
torch 1.8.2
torchvision 0.9.2

Thanks for your interest in our work and really detailed description. The first warning is raised when loading pre-trained weights of IR-50 and ViT-Small. It is useless for inference and will not affect the result. You can disable the pretraining with:
cfg.model.extractor.pretrained = None
cfg.model.vit.pretrained = None

The wrong prediction is caused by the wrong data processing (e.g., the std in Normalize is not divided by 255). But I find that it still has some differences between torchvision.transformes and mmcls. So it is highly recommended to directly use transforms in mmcls.
I have updated a demo notebook at demo.ipynb. Hope this could help you.

Hi @youqingxiaozhua  thanks for your prompt reply!
Nice to know weight loading is done correctly, thanks for the exaplanation.
Regarding data preprocessing, I have taken values of mean and stds reported in mmcls dataset config and divided by 255 because mmcls perform normalization when image pixels values are still in [0,255] while with torchvision this operation can be applied only after ToTensor which rescale image pixels value in [0,1].
Does this sound correct to you ?
Which other differences are you noticing between the two preprocessing pipelines ? I would like to use torch for preprocessing, is this feasibile in your opinion ?
By the way, thanks for updating a demo notebook.

Hi @youqingxiaozhua I am sorry for the silly error, now it is corrected and it performs way better !
Feel free to either close or directly delete this issue.
Thanks again


[Bug]: Does not reconnect when the TCP connection is broken

Checklist

[X]  I am not using Home Assistant. Or: a developer has told me to come here.
[X] I have checked the troubleshooting section and my problem is not described there.
[X] I have read the changelog and my problem is not mentioned there.

Deploy method
Docker
Zwavejs2Mqtt version
6.4.1
ZwaveJS version
8.11.1
Describe the bug
I'm using a Z-Wave adapter shared via TCP (ser2net on the server side). Today, I had to reboot the device with the dongle and, as expected, the connection broke. However, it is not restored automatically as I had expected. Instead, the following message is displayed:
Driver: Serial port errored: read ETIMEDOUT (ZW0100)
It would be nice if it tried to reconnect every few seconds until the server can be reached again. We already worked on a similar bug in #1246 and I saw similar reports in https://github.com/zwave-js/node-zwave-js/issues/3509.
To Reproduce

Connect the Z-Wave dongle via ser2net
Stop ser2net
Wait for the lost connection in zwavejs2mqtt
Start ser2net

This gives  Driver: Serial port errored: The socket closed unexpectedly! (ZW0100), but it doesn't reconnect either!
Expected behavior
After 4., the connection should be auto-restored.
Additional context
No response

@AlCalzone Does that throws a driver error?

https://github.com/zwave-js/node-zwave-js/pull/3520/files
It should emit a ZWaveError with code Driver_Failed.

@andyboeh Could you attach zwavejs logs please?

Here you go - nothing more happens, it just sits there displaying the error although the server is already restarted.
zwavejs_2022-02-01.log

2022-02-01T15:54:52.754Z DRIVER   Serial port errored: The socket closed unexpectedly! (ZW0100)
2022-02-01T15:54:52.757Z DRIVER   destroying driver instance...
2022-02-01T15:54:52.776Z DRIVER   driver instance destroyed
2022-02-01T15:54:52.786Z DRIVER   ███████╗ ██╗    ██╗  █████╗  ██╗   ██╗ ███████╗             ██╗ ███████╗
                                  ╚══███╔╝ ██║    ██║ ██╔══██╗ ██║   ██║ ██╔════╝             ██║ ██╔════╝
                                    ███╔╝  ██║ █╗ ██║ ███████║ ██║   ██║ █████╗   █████╗      ██║ ███████╗
                                   ███╔╝   ██║███╗██║ ██╔══██║ ╚██╗ ██╔╝ ██╔══╝   ╚════╝ ██   ██║ ╚════██║
                                  ███████╗ ╚███╔███╔╝ ██║  ██║  ╚████╔╝  ███████╗        ╚█████╔╝ ███████║
                                  ╚══════╝  ╚══╝╚══╝  ╚═╝  ╚═╝   ╚═══╝   ╚══════╝         ╚════╝  ╚══════╝
2022-02-01T15:54:52.786Z DRIVER   version 8.11.1
2022-02-01T15:54:52.786Z DRIVER
2022-02-01T15:54:52.786Z DRIVER   starting driver...
2022-02-01T15:54:52.788Z DRIVER   opening serial port tcp://SercommPrivate.lan:5000

The driver is also being restarted, but then it doesn't connect... I'll have to check why.


fix(subscription): fix warning message when a subscription query contains an unknown attribute #144

The  "node.get(it) must not be null" warning is returned when a matching subscription has an unknown attribute in its query.

The "node.get(it) must not be null" warning is returned when a matching subscription has an unknown attribute in its query.

I don't really understand it. Can you explain it with an example?
Also, that does not seem to be real warning? I don't get why we have hundreds of such messages in the logs...

I don't really understand it. Can you explain it with an example?

For example, we create a subscription to a beeHive having a query: unknownTemperatureAttribute>40.
When we update the temperature of a beeHive, the unknownTemperatureAttribute (retrieved from the query) does not match any attribute in the entity payload.
And we raise an exception Here

Also, that does not seem to be real warning? I don't get why we have hundreds of such messages in the logs...

Indeed, I think better to just return false (unmatching query).

Also, that does not seem to be real warning? I don't get why we have hundreds of such messages in the logs...

Indeed, I think better to just return false (unmatching query).

Yes, that's not a problem of us if an user created a subscription that does not match.

OK for this version. For later, think about an improved version without throwing exceptions.


fix: add use of gcp pypi package in example

This adds a dependencies that can only be taken from the remote to test if that works correctly.
Found issues:

This only works if the user sets up a keyring provider and then tells pixi to use that. The error could be more helpful by improve the error msgs.
Satifiablity works for both path versions and actual versions which should not satisfy in my opinion, it should redownload from the index if the user replaces package = {path = "."} to package = "*"

Good, works like a charm!


Run it without FluentAvalonia?

Hi, this program works wonderfully on Windows 10, but on Win 7 the program crashes upon opening it due to FluentAvalonia, is it possible to open it in an alternative way?
Thanks

Sure, it's open source so you can do whatever you want, but supporting Windows 7 is not something I'm willing to do myself.


Log 13753 event leader refactor

Surrounds k8 events with new leader election system, while removing the old “oldest pod” way of doing things.
Fixed a bug around failure case
Test plan:
Integration Test
Unit Test
Manual Testing via observing leader logs
Ref: LOG-13753

In regards to the manual testing has there been any regression tests to ensure that this process plays nicely with the startup lease process? There's a lot of logic changes in _main.rs that is in and around the existing startup lease logic.

Outside of the integration tests, and just testing my own stuff with all the changes. Not really, unless @jiangao1 has - I do know once this is buttoned up he has a few smoke tests planned on master/release branch.

In regards to the manual testing has there been any regression tests to ensure that this process plays nicely with the startup lease process? There's a lot of logic changes in _main.rs that is in and around the existing startup lease logic.

@stsantilena on top of that this is using the leader election logic that his been in master for a few weeks now. Nothing really new has been added


Installed Wordpress in my YoURLS directory... now what? Excluding /blog/ somehow?

Technical details

YOURLS version: 1.7.1
PHP version: 5.2.17

Reproducible Bug Summary

I have had YoURLS in the root directory of http://jle.vi for years - works great, I can't live without it.
Recently, I decided to migrate the website to Wordpress so I can create a blog. I don't care if the posts are short-linked through wordpress... the permalinks can be at http://jle.vi/blog/whatever-name-doesn't-matter or something
Currently, YoURLS is dominating the .htaccess, so I guess Wordpress can't make redirects. So, I can't get to posts.

This is a bug because I need to be able to link to blog posts, even if they aren't permalinks. It would be best if they were, and I could just exclude the /blog/ from rewrites, but I don't know how to do it.
I'm a pretty big novice, so I appreciate your patient and thorough explanation of what I need to do (for example, change a setting in Wordpress, add something to .htaccess, etc).
I don't want to move YoURLS, and obviously cannot move the entire site, unless, I guess, I redirect http://jle.vi/ to http://jle.vi/site or something like that and move the entire wordpress install.
Anyways, I attached the .htaccess file. Thanks for your help, everyone.
htaccess.txt

It should work just with installing WP as usual in a subdirectory, ie :

YOURLS in [root]
[root]/.htaccess with YOURLS directive
WP in [root]/blog
[root]/blog/.htaccess generated by WP

@ozh I want the website itself to remain in http://jle.vi, as it is now, just the blog posts to go to /blog/.
Do you know how I could possibly do this? Do I need to relocate the whole installation in order to do it and do some kind of redirect from root of jle.vi to jle.vi/blog or something? I wouldn't want the /blog/ in the URL for the main webpage, but if I had to, I'd live with it...
Thanks
JL

You just need to do just as I said above

Actually, this doesn't answer my question, because I still want the site to be hosted at jle.vi/, not jle.vi/site. I don't mind the BLOG posts to be at /site/, but the main site, I want to be at http://jle.vi/
If I do as you said, "[root]/.htaccess with YOURLS directive", then the whole site operates at jle.vi, and I don't know what happens when someone just goes to jle.vi without /site/ - know what I mean?
Should I maybe post in the wordpress help forums.

Your blog/... thing confused us at all, because what you are actually doing is: installing WordPress and YOURLS in the same directory. So you are trying to let them work at the same time.
I don't think you should ask here (maybe stackoverflow is better), NEITHER THIS IS A BUG. Just remember, WordPress doesn't have single post links only, it also have categories, tags, wp-json, feed and a lot more. But let's assume you just want blog/... work. You need some knowledge of regex.
# BEGIN YOURLS
<IfModule mod_rewrite.c>
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^index\.php$ - [L]
RewriteRule ^(?<!blog)(.*)$ /yourls-loader.php [L]
</IfModule>
# END YOURLS

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

It may not work, and I don't recommend this practice.

@phy25's solution won't work. You cannot have YOURLS and WP installed in the same directory.
@entreprenewer I don't understand what you mean with "site", "blog", "main site", "whole site". I just don't understand what you're trying to achieve.

Let me try to explain as clearly as I can.
I want my website to function at http://jle.vi - without any additional subdirectory in the URL (such as /blog/ or /site/)
However, in order to be useful, YoURLS needs to be installed in that root directory. I have thousands of links in there, and I'm not about to change them, plus, jle.vi/s/link is not a very useful short link, now is it?
Right now, Wordpress is in the same directory as YoURLS... and it's working. But only because http://jle.vi is a one-page theme.
As soon as I try to add the "blog" functionality of the theme, which links to other subdirectories (permalinks), then stuff breaks.
I don't mind if all permalinks at at http://jle.vi/blog/link-name-here or something.. but as far as I understand it, if I move the Wordpress installation in it's entirety to http://jle.vi/blog/ or any other URL, then the site won't load when people go to http://jle.vi
I guess part of what I'm asking is what happens if you JUST have YoURLS in a directory? What happens if people go to the root URL? What would happen if wordpress wasn't in there? I guess I would have to redirect to a subdirectory?

Well, you already have the 2 answers to your problem:

you cannot have YOURLS and WP installed in the same directory.
see my comment about having YOURLS in root and WP in /blog/

@ozh your above statement...

You cannot have YOURLS and WP installed in the same directory.

Makes me wonder? I have an apache server with 65 WordPress domains across 8 multisite WP installs, all centered on one document root (directory). In addition, there was some hand coded websites and a couple forums, often sharing the same domain name and directory (URI) structure.
Don't ask me why (started way back in 19-forgotten, before Google!). The point is that it worked by identifying the URI/directory structure differences. It seems to me it would be a simple thing to do the same with WordPress and YOURLS. In other words, I see no conflict with running the following together:
http://vekind.org/ (WP - domain default page)
http://vekind.org/vekind-basics/ (WP - page)
http://vekind.org/welcome-terrans/ (WP - post)
http://vekind.org/topic/vekind/earthling/ (WP - category page)
and something like...
http://vekind.org/v7hsLAN (YOURLS redirect URL)
This should be quite easy to do in Apache (and is what I am working on in Nginx).
If you would like, I could load a basic site with WordPress and YOURLS in Apache and write some simple directions on how to run them both in the same document root. Perhaps just a slight change.
If you think it would help others.
Sincerely,
Lan
PS: I would also suggest giving YOURLS its own directory, configurable, like WP does. This may allow more WP compatibility and make YOURLS multisite easier.

WP's .htaccess : "when a file requested isn't a real file on the server (eg a .CSS or a .GIF) then redirect to index.php"
YOURLS' .htaccess : "when a file requested isn't a real file on the server, then redirect to yourls-loader.php"
So, basically, you cannot have WP and YOURLS in the same directory because they work the same way and then your htaccess would need to redirect to something that would first have to guess if a requested URL is a WP thing or YOURLS stuff.

Yes, I agree with what you said about WP and YOURLS.  However, that works in our favor.  All one would need to do is to make a simple .htaccess file that would serve both programs.
.htaccess has both regex and conditional statements.  Just a quick overview of the way WP and YOURLS really works leads me to think there are many different regex that could be simply written to exploit the differences.  All that we would need to do is find one thing that one program always does that the other didn't do and bingo...
if (condition) {do index.php) else {do yourls-loader.php}.
Just write that logic into .htaccess.
Tell you what, I am traveling this week, but when I get back to the office next week, I will write the ,htaccess file for you.  Do you want it for a single WP site with a Single Domain YOURLS, or a multisite WP?
I will show you how easy it is to have YOURLS play nice with WP.
Regards,
Lan

I am fully aware of how this can be done. You'll find several explanations in issues here or even "tutorials" on the web of people who needed it and toyed with the idea. This is just something I don't want to support because it has to be tailor made depending on each setup (ie your "if (condition)" will vary, some folks will restrict YOURLS URLs to 5 chars to segregate them from WP, others will do something else, and so on) and doesn't rely on YOURLS only.
Anyway your solution to this problem is welcome as it may help searching for the same issue. Feel free to post your solution in a separate issue and answer it, Q&A style.

Yes, I see your point.
Basically, for a guy like me, who has been programming since back to the days of ARPANET at DARPA, "easy" is a relative term. I agree that ANY .htaccess setup needs to be extremely clear, similar to what WP or YOURLS now uses.
Sort of "copy, paste, and change this to that!" (Like "Change example.com to your domain name.")
"Restrict YOURLS URLs to 5 chars to segregate them from WP"
That's an interesting idea I hadn't thought about.  However, immediately I can see some serious flaws in this reasoning.
1. You'd run out of URL's before you reached a billion (a billion is really not that many if the site is open to the public).
2. I maintain a few hundred sites that have either "home" or "about" pages, or both.  My guess is that those pages, or any other with a URI <6, would be sent to YOURLS (and crash in WordPress).  A "five or less chars" limit might work for one guy publishing a single blog, but enforcing a greater than 5 chars WP rule on dozens (or thousands) of people will surely result in problems for some WP pages.
3. One additional problem I see is that a result of using WP in Multisite mode. So example.com, example.net, and example.org are going to be mapped to one single directory. Therefore, to a single .htaccess file. Assume YOURLS was only for the example.org domain, this five chars limit would send YOURLS some traffic (in error) from example.com and example.net also.
I agree with you that this needs to be something simple, very simple, "copy paste simple!"  I will work on a solution toward that end.
I have two questions I did not see on your FAQs or that I want to make clear.

Am I correct that YOURLS is always used on one domain only?  Meaning that one set of files is used to support YOURLS on one domain name?

Do you have a list of links to unsupported "tutorials" or unsupported third party advanced YOURLS configurations that people have posted?  It would save time seeing what other people have examined or tried.

Regards and Thanks,
Lan

Answers:

out of the box, yes, one set of files for one location. This said, I think there's a plugin or a hack somewhere to have multi domain support.
Nope. Everything noteworthy we've found is either mentioned in the readme or sometimes in specific issues here

Thanks ozh, your answers are very clear and specific - great support!
1) Give YOURLS Its Own Directory
I currently have a hack on my development server that gives YOURLS its own directory with just a configuration. In other words, out of the box, it works the same, but adding one configuration line and you can put the YOURLS files anywhere (any directory) you want and let it still work from the root directory.
2) YOURLS and WordPress Sharing the Root Directory
This is under test with 36 and 62 versions, with no restrictions to YOURLS. The setup is only simple configuration and giving YOURLS its own directory (above). The WP setup has one Pretty Permalinks setup restriction, but most people would not use that anyway.
3) YOURLS and WordPress Multisite Sharing the Root Directory
One of my advanced students is testing the number 2 settings above with a WordPress Multisite with the Multi-Networks plugin activated ( different domain names like VeKind.org and Plant-Only.org ). This would result in YOURLS (one domain) being on the same rood directory as WP Multisite (our test platform has 45 domains).  The setup requires the YOURLS domain be listed in the .htaccess file, but is still very easy to understand.
4) YOURLS Multisite
I have a roadmap to allow advanced users to define constants in the config.php file to enable multisite (multidomain) handling based on different domains, all via one root directory.  Also compatible with all the above configurations.
Each of these configurations is simple and easy to do at a novice or beginner's level.
I will move this to my Lan Net Work site so my students can have a go at it, and test it.  Will start a new thread with the finished hack or if we have any further questions.
Thanks again for your great support Ozh!
Best Regards,
Lan

You cannot, I tried different ways, maybe with new apache 2.4 using the if else statement you will, but I am not an expert on those commands, I want to share what I did to have the shortener option in the root page and the html site in a subdirectory, with this solution you can still give people normal url for the website (e.g. sho.rt):
set your website in a folder under root with a name e.g. "w", that means it will be at "sho.rt/w"
then use this .htaccess
# BEGIN YOURLS
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^.*$ /yourls-loader.php [L]
    RewriteRule ^$ /w [L]
</IfModule>
# END YOURLS

This will give you the option to still use sho.rt as your website address if the user doesn't pass any subfolder in the url, but if they do, it will check in yourls first and go to your folders if nothing found.
One more thing, do not forget to add "w" in the $yourls_reserved_URL array in /user/config.php (Yourls config file)


Outreach

➤ Basil Mohamed Gohar commented:
https://osc.edu/open-ondemand
Links to https://github.com/osc/open-ondemand


Bugfix | 1495 regexp escape string

Hello!

Type: bug fix
Link to issue: 1495

In raising this pull request, I confirm the following:

[X] I have checked that another pull request for this purpose does not exist

[X] I wrote some tests for this PR

[ ] I updated the CHANGELOG

Added slashes for regex string when generate C-code

Added tests

Thanks

Thank you

let e = "\e"

is escaped now
-ZVAL_STRING(&e, "\e");
+ZVAL_STRING(&e, "\\e");

so colors in ice console stopped working
https://github.com/ice/framework/blob/3667503adc7efb128ed8d56e46b0ef9b0e24577e/build/php7/ice/cli/console.zep.c#L289


Bottom sheets example for Gallery app

From https://www.google.com/design/spec/components/bottom-sheets.html#

This seems to be done too.


Laravel log context param not displayed on issue page

Hi! I'm using laravel-sentry via log channel. I offten use laravel log context param to log some additional data, for example:
Log::notice('Provider could not determine the country for ip', [
	'ip' => $ip,
	'provider' => $providerClass
]);

But after upgrading from 2.4.2 to version 2.5.3 these parameters are no longer displayed on sentry issue page neither in message text nor in breadcrumbs log metadata.
I found a way to display them using extra param:
Log::notice('Provider could not determine the country for ip', [
	'extra' => [
		'ip' => $ip,
		'provider' => $providerClass
	],
]);

But this approach affects other log channels (filelog, telescope) and does not seem very convenient. Is it possible to return previous behaviour somehow?

Hi, you mention upgrading to version 5. Version 5 of what exactly? The Sentry SDK for PHP is on version 3 and the Laravel SDK on version 2 😬

I'm sorry, I mean sentry-laravel version ^2.5
And also I need to mention that I use laravel 7 on php 7.2

No worries, I thought you were maybe using another package, but 2.5 makes better sense 😄
Interesting I have checked out the changes, compared to ^2.4, but I don't see anything that would make this stop working. In fact I did notice that what you described never worked in the first place.
This works, but without the extra key it should not work (in any version):
Log::notice('Provider could not determine the country for ip', [
	'extra' => [
		'ip' => $ip,
		'provider' => $providerClass
	],
]);

What version were you coming from and does reverting to that version work?

As I type this I read your comment a bit better, you said the information was in the message itself?
It never displayed nicely in a little table like the user data, all that extra data was just in the message?
We made some changes to make log messages show the message and not the fully rendered message with timestamps and all for example, I'm thinking that is what's happening here...
This is the PR with the changes: #482.

Yes, on 2.4.2 with this code there were two places where I could check my context params (not nicely but still): message text and breadcrumbs list:

So my question is, is there a way in 2.5.3 to send a context without wrapping array to extra (cause it will affect other log channels in stack)?
Or the only way without extra wrapping is to use a custom monolog formatter for message itself?

Ahh, yes with 2.5 the formatter is the only option.
However, I feel we should fix this... I think we can consider this a bug.
It was not intended to remove that data but when cleaning up the formatted message to just show the message part the extra data also got lost. We can do better here to have the data show up nicely.

If you can you can try out #489 which should fix the issue by changing your composer.json (temporarily):
-   "sentry/sentry-laravel": "^2.5"
+   "sentry/sentry-laravel": "dev-add-logger-context-as-extra-context#9ea5cb420aa7caba00d3b508ea95b4bb02ae86bc"

You can (and should) change this back to ^2.5 once this PR is merged and released 😄

Yes, it's works perfectly now! Thank you

Hey @stayallive, any general ETA on the fix being pushed? Want to determine if we should deploy the patched release or hold off. Thanks.

I'm planning on a release somewhere this week. So should be soon.

2.6.0 was just released which includes the fix.


Need to improve output format

Currently output provides full information or narrow information.
It is necessary to provide an output composed of meaningful information.

Ref #92

Resolved by #94


DatePickerElement doesn't behave as the MUI one.

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Current behavior 😯
The date picker goes to top left.

And I also get a warning when opening this picker for the first time.
Warning: Failed prop type: MUI: The `anchorEl` prop provided to the component is invalid.
It should be an HTML element instance or a virtualElement
(https://popper.js.org/docs/v2/virtual-elements/).

Expected behavior 🤔
The expected behavior should be the same as MUI.

Steps to reproduce 🕹
Can be seen here.
https://stackblitz.com/edit/vitejs-vite-cc4enk?file=package.json

@zkanda this seems to be off. I use the picker on NextJS and Storybook without an issue please check https://react-hook-form-material-ui.vercel.app/?path=/story/datepickerelement--basic
I don't know what Vite or Stackblitz are doing different than my setup.

Have the same issue

Same issue here as @zkanda

Same issue here. Actually I'm pretty sure it was working correctly in an earlier version but I can seem to find it.

Any PR is welcome, I can't see that issue in my environment and use this library in production without an issue so far.

Maybe it has to do with the version of React or MUI. Will check tonight.

Indeed, it was working properly on my side until I bumped react-hook-form-mui from version 5.7.2 to 5.12.3 (for reference, here is the commit that broke it in my project). Downgrading the library fixed it.
Bissecting on the versions of this package lead me to find that 5.12.0 is when the bug started appearing in my environment (between commits 7d2826b5b74b1ca7529dd5cd029c1bb42026e48f and a986ab368363fee8fb0e8e5252aad858c24fb8b4, included).

Alright, the problem was introduced in #109, namely the addition of:
inputRef={ref}

That said I have no idea why it is working on some environments but not others.

Somehow relates to mui/material-ui-pickers#1768 but the proposed fix of using ref={ref} instead of inputRef={ref} breaks the intended feature regarding the focus. I'm not too familiar with this to be honest.

@FlorianCassayre could you elaborate why on Storyblok and NextJS there is no issue? I merged that PR back in the days and could not see any regression in my setup thats why I merged it. I am open to revert it. I am also not familiar with the focus ref myself

@dohomi I don't understand, actually. I am also using NextJS, that's where I am encountering the problem. May have to do with a peer dependency but this is just a guess.
I guess if this focus feature brings more harm than good, probably worth reverting it for the time being. I don't mind either way for now as I pinned the library to the latest working version in my project.

I reverted the changes of inputRef in v5.12.4, please let me know if that fixes the issue

I was also encountering the same issue.
After updating to v5.12.4 the problem went away.
Thank you!

thanks @RubtsovAV I merged your PR. Will close this issue for now please open it again if 5.13.1 is causing any trouble


Solution to Median of array

Hi @BharatNischal, thanks for the PR. Could you please follow the guidelines to get this merged please?

@cruxrebels Is anything else missing?

@cruxrebels  in 26 line the expresssion will not evaluate (2-1) as precedence of division is higher so it will first divide the array size with 2 and will then subtract 1 from it. The logic behind this is that in case of even number of elements median is the avg of 2 middle elements.

@cruxrebels in 26 line the expresssion will not evaluate (2-1) as precedence of division is higher so it will first divide the array size with 2 and will then subtract 1 from it. The logic behind this is that in case of even number of elements median is the avg of 2 middle elements.

The code currently reads to naked eye as if you're doing division by a constant expression: 2 - 1. Better way to write it and make it clear would have been (Note the braces to signify precedence of division happening first):
Arr[(Arr.size() / 2) - 1]

The code could use more refactoring which can be taken up later when you feel like it. :)
Thank you for your first PR into https://github.com/cruxrebels/InterviewBit, keep contributing! 👍


Inconsistent ID generation for .d.ts files

Flamework's ID generation has differing behavior for .d.ts files depending on whether or not the file is a descendant of a rootDir.  .d.ts files that ARE a descendant of a rootDir (such as type declarations for .lua files or a types.d.ts file) won't have their extension removed, resulting in IDs like @package/types.d.ts@MyInterface. At the same time, .d.ts files that AREN'T a descendant of a rootDir will always have their extension removed, resulting in IDs like @package/types@MyInterface. This behavior discrepancy causes ID mismatches for packages that use declarations from .d.ts files.
Package A
// types.d.ts
export interface MyInterface {}

// .ts file
Flamework.id<MyInterface>() // @package/types.d.ts@MyInterface

Package B
// .ts file (with MyInterface imported)
Flamework.id<MyInterface>() // @package/types@MyInterface

Fixed in https://github.com/rbxts-flamework/transformer/commit/c455383c5ae5493cd921230b2e90bcfe2ed2f5e5