pyproject.toml configuration support

Many other python formatting/style tools have added support for the pyproject.toml file's [tool.*] sections for their configuration. Is this something that pydocstyle would be open to supporting?

As far as I know, there's 1 formatting/style tool that supports it. What other tools have added support for it? For what it's worth flake8 and pycodestyle have both refused to support this at this time.

That's interesting, I hadn't interpreted https://github.com/PyCQA/pycodestyle/issues/813 as a refusal, rather than just a deferral until wider config refactoring happened.
At least black (https://black.readthedocs.io/en/stable/pyproject_toml.html) and isort (https://timothycrosley.github.io/isort/CHANGELOG/#435-february-24-2019-last-python-27-maintenance-release) both do, and my (limited) impression was that the community seemed to be converging on it as a good option going forward?

A very vocal minority are trying to create that impression in my experience but they have no regard for backwards compatibility or the maintenance burden of each of these tools adding yet another new config file location to have to observe and determine precedence of.
@wlcx that is de facto refusal because no one is actually working on pycodestyle

@sigmavirus24 It seems that in 2020 pyproject.toml becomes mainstream. Please, take a look at the corresponding awesome list: https://github.com/carlosperate/awesome-pyproject . More and more tools supports it. May be it is the time to reconsider.

@prokher given the accuracy of the title of the section "Projects discussing the use of pyproject.toml" which conveniently implies that those projects are still open to the idea, I'm not swayed by that list. It's not overwhelming in size. The benefits of adopting pyproject.toml (as I've explained in numerous places) are not overwhelming in anyway and finally as I've said above, the biggest barrier is lack of maintainers who can work on it without breaking things for existing users.

+1 for this
It would be nice to at least be able to do --config pyproject.toml even if it is not parsed by default and has no precedence

I am happy to reopen the issue at the very least since it seems like there are some discussions going on.

+1 for this
I have a project where I am using black, isort, pylint, coverage and pytest and have configured all of them within the pyproject.toml file, like so:
[tool.isort]
multi_line_output = 3
include_trailing_comma = true
force_grid_wrap = 0
use_parentheses = true
ensure_newline_before_comments = true
line_length = 88

[tool.pylint.format]
max-line-length = 88

[tool.pylint.messages_control]
disable = ["C0301",   "C0330", "C0326", "C0415"]

[tool.pytest.ini_options]
DJANGO_SETTINGS_MODULE = "config.settings.test"

[tool.coverage.paths]
source = ["src", "*/site-packages"]

[tool.coverage.run]
branch = true

[tool.coverage.report]
show_missing = true
fail_under = 100

It would find it really useful to be able to also define a tool.pydocstyle section there, so that I don't need to have an extra .pydocstyle config file at the root of my project.

It is possible to use --config=pyproject.toml as of this year, unsure about prior versions. The only restriction being that the configuration key must be named pycodestyle.

Also, @sigmavirus24, it isn't a vocal minority - PEP518 standardized the usage of pyproject.toml. It is an officially accepted standard in the Python community.
I am normally of the "standards are a poor excuse for mediocrity" stance, however, pyproject.toml and unifying toolchain configuration would be a big improvement for the already suffering Python ecosystem.

It's a standard for build tools with an allowance for extraneous tools. The tools that can support it without serious maintainer burden have chosen to do so. The rest that have limited or no maintainer time shouldn't. The people talking this up are over-selling the standard (like you are) for ad hominem purposes.
This conversation and issue has been pointlessly circular as users demand things maintainers can't afford to support.

The people talking this up are over-selling the standard (like you are) for
ad hominem purposes.

Nobody's overselling anything, nor is any ad hominem involved. Do you
know what that means? I haven't personally attacked any of the
maintainers anywhere, because that's not part of computer science.
If you do a little bit of thinking you'd realize that the
standardisation makes life easier, as it means you don't need to
maintain the processing for your own configuration file.

This conversation and issue has been pointlessly circular as users
demand things maintainers can't afford to support.

Nobody has demanded anything, either. This is a discussion - if you
don't know what those are, they're also quite common in science.
Perhaps something you should invest a little portion of your free
maintainer time into is respectful tone and ability to work with
rational conversations. Just a suggestion.

that's all, I think

Absolutely correct. Just trying to help and be constructive.
Either way, in reasonable terms, supporting it shouldn't be too much of
a hassle. If anything, as aforementioned, it allows the developers to
shave off the overhead involved in supporting individual configuration
formats.
I am open to making a PR and contributing if necessary. If not, that's
my piece said.

Actually, another interesting thing I noticed - isort, also under PyCQA, does support pyproject.toml. If these two packages are maintained by the same organization, it makes even more sense to do this for consistency - not to mention it disproves the claim that the maintainers cannot support it, because it has been done elsewhere under the organization.

Nobody's overselling anything, nor is any ad hominem involved. Do you know what that means?

There is an ad hominem throughout this issue "This is a standard and must be implemented everywhere" (not an exact quote). It's not an ad hominem character attack on the maintainers, it's a claim repeated over and over and over to get your way. It's not you in particular doing this but you in particular piling on to this. That's the definition of an ad hominem.
Quoting Wikipedia:

Ad hominem (Latin for 'to the person'), short for argumentum ad hominem, refers to several types of arguments, some but not all of which are fallacious. [...] This avoids genuine debate by creating a diversion to some irrelevant but often highly charged issue.

In other words, claiming that the PEP that defines the file and allows for tools to leverage pyproject.toml in some way implies that this and other tools must implement support for it, is trying to use "it's a standard" as a diversion against the very real costs of maintaining that support.

haven't personally attacked any of the maintainers anywhere,

I didn't say you personally attacked anyone. You misread my words.

that's not part of computer science. [...]
This is a discussion - if you don't know what those are, they're also quite common in science.

You ask me to be "more respectful" but have now taken a quite emotional approach to trying to attack me for being:

emotional (apparently real scientists are robots) despite being quite detached and simply making observations in my comment,
not understanding language,
talking down to me as if you're superior

None of which is very respectful in and of itself. Please point out exactly how I was disrespectful.

Either way, in reasonable terms, supporting it shouldn't be too much of a hassle. If anything, as aforementioned, it allows the developers to shave off the overhead involved in supporting individual configuration formats.

I suspect in "computer science" (of which you speak as if you're an expert) you just drop support for things haphazardly. That's not how real software maintenance works. "It shouldn't be too much hassle" exposes your inexperience in supporting a widely used tool or set of tools and doesn't take in to consideration the complexities of existing software.

Please don't go burning yourselves out for this! If it's too much load and maintainer time is so scarce, I think people will understand. Heck, perhaps someone who cares enough will help and ease that load.

I believe it's been said numerous times above that the maintainers don't have the time/energy for this, and still we have folks adding comments that add no new content and continue to repeat false statements. If there ever was an appetite for doing this work, simply explaining to people the current state of affairs takes a quite significant amount of time away from even doing that work. This issue has been open for over a year, no one has said "I'll help do this work" and then kept with it as soon as they realized the complexity of implementing it.

Sorry to hear that man, I really meant to say something nice. It's painful to see this conversation devolve this way, and to hear such a pessimistic viewpoint - as justifiable as it may be. But I recognise my comment wasn't really adding to the technical conversation. I hope you and the other maintainers get some rest 🌴

Although, it's possible that I'm wrong. English is not my first
language, so I might be mistaken in this case.

You are not. That was precisely my point - not that it makes my argument
any more valid, but English is my first language, and linguistics is
one of my subjects of interest.
Ad hominem, under the Oxford Languages dictionary, refers to an argument
directed against a person rather than the position they are maintaining.
Nobody in this thread personally attacked anyone, which is what I was
saying - especially not me, which is, as far as the context was
concerned, who he was responding to.

something being a part of a PEP is not a good argument for it being
good, it is a good argument for it not being an unpopular or
fringe use case.

Absolutely. "Standards are a poor excuse for mediocrity", as I always
say, however, they are useful for unification.

his second comment is not very polite to say the least
[...]
From his point of view, he came into this issue to have a civil
discussion, but was immediately accused of making a personal attack

Pretty much. While I agree that, looking back on it, my response was
somewhat irrational, I cannot express the degree of annoyance it causes
me for someone to bring a victim mentality and the notion of ad hominem
into a civil discussion regarding engineering where they have no place.
Those things do not belong in science. Ever. And I will not stand to
have such accusations made against me or any other innocent people.

People are offering their help with implementing this feature. People
are giving arguments for and against this feature being implemented
(developer and maintainer effort being part of this discussion). This is
how Open Source is supposed to work, no?

Thank you for your response. I didn't respond because arguing wouldn't
take it any further, and I already said I'd be willing to make a pull
request. But yes, people are most certainly willing to help.
Although, that does bring one thing to my attention. The tool can
already read TOML configuration (mostly) due to its similarity to .cfg,
as I highlighted earlier in the thread. It just doesn't fully or officially
support it, and it doesn't use the correct configuration header format for
pyproject.toml files.
Therefore, it would not be overly complex. I cannot weigh in on the
usage and need to support tox.ini and setup.cfg as I am not aware of
any formal studies or statistics on their usage, but I know adding
pyproject.toml would not be overly difficult (once again, TOML is a
close superset of CFG).

Although, that does bring one thing to my attention. The tool can already read TOML configuration (mostly) due to its similarity to .cfg, as I highlighted earlier in the thread. It just doesn't fully or officially support it, and it doesn't use the correct configuration header format for pyproject.toml files. Therefore, it would not be overly complex.

I've tried it and for my project configuration files it failed, when trying to parse an unrelated part of the configuration. Unfortunately .ini/.cfg is not 100% .toml and it's different enough to the point where I don't think you can just kludge it together to support arbitrary .toml files. And we need arbitrary .toml, since pyproject.toml will also contain the configuration for other tools.
With that said, I do agree that it shouldn't be too complicated. It's not "just enable it, lol" simple, but more like "write a thin wrapper around toml that emulates configparser.RawConfigParser" simple.
I don't know, how close of a superset toml is compared to ini. If it is close enough, then this parser can just replace configparser.RawConfigParser, if it's not, then we can just use it when path.endswith('.toml').
After that, adding the tool.pydocstyle section is indeed "just enable it, lol" simple.

repeated over and over and over to get your way

We aren't repeating claims, we're making points that relate to the discussion. It feels repetitive because it has been going on for quite some time.

I didn't say you personally attacked anyone.

Your words were "The people talking this up are over-selling the standard (like you are) for ad hominem purposes". Notice the "(like you are)". You are implying that I, too, am engaging in ad hominem, and simply overselling a standard. Do I misread or do you miswrite?

That's the definition of an ad hominem.
[...]
This avoids genuine debate by creating a diversion to some irrelevant but often highly charged issue.

"avoids genuine debate by"
That is a statement of purpose. Ad hominem, or personal attacks, draw discussion away from genuine debate to other abstract factors of the people involved. That is the purpose and result of an ad hominem, not what it is. However, this is GitHub, not a linguistics forum, so I will not partake in any further discussion regarding what people have or have not said. The points I have made so far are sufficient.

other tools must implement support for it
[...]
is trying to use "it's a standard" as a diversion against the very real costs of maintaining that support.

Nobody has to - but your organization already has implemented support for it in its other projects. That alone proves that it can be done and it is not too complex or unmaintainable. If you genuinely believed it was, you would not have already done it.

that's not part of computer science. [...]
This is a discussion - if you don't know what those are, they're also quite common in science.

I do still stand by those statements. Ad hominem and related fallacies belong nowhere near informatics, science, or related fields. It is also important to note that this is a discussion, not a demand.

* emotional (apparently real scientists are robots) despite being quite detached and simply making observations in my comment,

"This conversation and issue has been pointlessly circular"
"demanding things maintainers can't afford to support"
"(like you are)"
Not once did I say real scientists are robots - I didn't even mention them. However, those definitely have undertones. They are not simply observations. They are passive aggressive at best. That is the reasoning for the response I gave you.

* talking down to me as if you're superior

You gave me a passive-aggressive comment with no constructive value, I gave you a reality check. The law of equivalent exchange.

None of which is very respectful in and of itself. Please point out exactly how I was disrespectful.

See the above. Once again, I am done discussing the semantics of language and respect, though. I will not be partaking in further discussion of these things.

you just drop support for things haphazardly. That's not how real software maintenance works.

It isn't haphazardly at all; versioning exists solely so you can make changes while informing existing users of the changes you make in upcoming releases, deprecations included, and so current users are not affected by your changes in future releases until they choose to update.

doesn't take into consideration the complexities of existing software.

It does, because it would reduce the complexity of the existing software, were you to deprecate other formats. Once again, though, I am not sure of their usage rates, so I am uncertain of how appropriate that solution would be.

I believe it's been said numerous times above that the maintainers don't have the time/energy for this

Once again, that is provably wrong. If you can do it in other projects, you evidently can do it.

still we have folks adding comments that add no new content and continue to repeat false statements

No false statements have been made, nor are there comments adding no new content. We are simply making points, and backing them up. That's as good as content gets.

no one has said "I'll help do this work"

I said it earlier, as have other people. A resolution needs to be achieved before effort is put into creating an implementation, though - nobody will work on something to later be told it is not happening.

Apologies, I thought it was due time for a formal response. If you want someone to work on this, let me know. Until then, I will not be participating in anything on this thread other than critical discussion points and the overall verdict.

Unfortunately .ini/.cfg is not 100% .toml and it's different enough to the point where I don't think you can just kludge it together to support arbitrary .toml files.

I know - TOML is a superset for the most part (of CFG), not a subset. It supports basics, but special types are off the table thus far.

With that said, I do agree that it shouldn't be too complicated. It's not "just enable it, lol" simple, but more like "write a thin wrapper around toml that emulates configparser.RawConfigParser" simple.

That sounds like a good idea. I haven't delved too much into the configuration system used by pydocstyle just yet, but it sounds viable enough to consider.

I don't know, how close of a superset toml is compared to ini. If it is close enough, then this parser can just replace configparser.RawConfigParser, if it's not, then we can just use it when path.endswith('.toml').

It would be better to use an actual TOML parser honestly. We'll see if this gets approved.

After that, adding the tool.pydocstyle section is indeed "just enable it, lol" simple.

Thank you for your contributions.

Consider me nerd-sniped, I've implemented pyproject.toml support.

Just to make it clear, on version 2.10.0:
:point_right:  pyproject.toml (mind it is NOT tool.pycodestyle):
[pycodestyle]
max-line-length = 100

:point_right:  command:
pycodestyle /path/to/file.py --config=pyproject.toml


City Index: Social Infrastructure Capacity

Create city index on Social Infrastructure Capacity, such as shools, gps, etc.

Solved in #507.


Bump dependencies

📲 What
Bump dependencies to the latest verison

add .idea to .gitignore
Bump dependencies

A description of the change.
🤔 Why
Vulnerabilities
🕵 How to test
CI Build/Automation Test
✅ Acceptance criteria Checklist

[ ] Code peer reviewed?
[ ] Documentation has been updated to reflect the changes?
[ ] Passing all automated tests, including a successful deployment?
[ ] Passing any exploratory testing?
[ ] Rebased/merged with latest changes from development and re-tested?
[ ] Meeting the Coding Standards?

/azp run

/azp run


About the openvidu server

How to build my openvidu server(which openvidu sample?) to  replace the address "https://demos.openvidu.io/basic-videoconference/"?  Thanks.

Yes.

What I did was clone the openvidu repository and run the openvidu server
Then change the URL in this Android app to the server URL.
Add my wechat if u want to discuss more. Wechat ID:zzzykf

ok, I add you.


Possible to disable automatic insertion of periods when using Codespaces on macOS?

When using Codespaces on macOS, hitting the space bar twice (after another non-whitespace char) has the effect of inserting an automatic period, per the below:

That OS feature can be disabled globally via System Preferences > Keyboard, but some users (e.g., students) wouldn't necessarily know to do that:

Curiously, though, in the client-side version of VS Code on macOS, periods aren't inserted automatically, even with the global setting still enabled. Might there be a similar way to suppress that behavior in Codespaces as well? Thank you!
CC @lostintangent @rongxin-liu

Hi @alexdima, thanks so much for such a detailed follow-up. Really interesting to hear the underlying implementation details.
It looks like Add period with double-space is on by default in macOS Big Sur; the screenshot below is from a colleague's fresh install:

No strong feelings on the feature request. It certainly seems reasonable to respect the OS-wide setting. Then again, I imagine it's intended for human languages, so perhaps not unreasonable to suppress for programming languages. (I assumed the latter was intended, given the desktop behavior.) One potential (if minor) argument for intentionally suppressing on desktop and web would be in the context of inline PEP comments, which prescribe 2+ spaces before the #, resulting in the below, fwiw!
print("hello, world"). # Inline comment with unintended period

Thanks a ton for filing this issue. This behavior has been bugging me a ton. I don't have the same problem in other editors like Sublime Text or Intellij even with the OS setting on. The only editor affected was vscode, which made me think this was a VSCode bug. I've even pointed it out to several co-workers in pairing sessions and they kinda shrugged and guessed it was intentional vscode behavior but didn't know how to turn it off.

Do you know if the Add period with double-space option is on by default on macOS? It was unchecked on my computer, and I don't remember explicitly unchecking it. I'm thinking that if the default is unchecked, then students that would run into this have previously opted into this explicitly.

I got a new machine recently and certainly didn't enable that feature. I'm on Mac Big Sur 11.6.2 (20G314) and it was enabled by default for me.
I personally can't imagine a scenario where someone would want this behavior in a code editor, (however I'm open to alternate perspectives). If all other editors are suppressing (or not respecting) it, I think it's okay for vscode to do the same.
Also thanks for the work on vscode, it's been a joy to use with the Rust analyzer extension.

Oh, interesting, I thought this was a VS Code bug, but nope, it's a fun new macOS default, gotta remember to turn that off after fresh installs! Interesting that "add period with double space" works in VS Code search inputs (global and editor), but not in the editor, the Explorer search input, the Source Control input, the Extensions search... I don't have a strong need for it to work anywhere personally, but maybe it should be consistent?


add npm check updates and a script target for it

okay to assign to https://issues.redhat.com/secure/RapidBoard.jspa?rapidView=5662&view=detail&selectedIssue=COST-2936 ?

Codecov Report

Merging #2456 (a89ea5b) into main (e630ec9) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head a89ea5b differs from pull request most recent head 446038c. Consider uploading reports for the commit 446038c to get more accurate results

@@           Coverage Diff            @@
##             main    #2456    +/-   ##
========================================
  Coverage   71.21%   71.21%
========================================
  Files         427      427
  Lines        7925     7925
  Branches     1838     1837     -1
========================================
  Hits         5644     5644
+ Misses       2278     2174   -104
- Partials        3      107   +104

Impacted Files
Coverage Δ

src/utils/cookie.ts
58.33% <0.00%> (ø)

src/utils/format.ts
67.00% <0.00%> (ø)

src/api/orgs/orgUtils.ts
37.50% <0.00%> (ø)

src/api/queries/query.ts
43.85% <0.00%> (ø)

src/utils/localStorage.ts
78.66% <0.00%> (ø)

src/store/metrics/selectors.ts
75.86% <0.00%> (ø)

src/api/resources/resourceUtils.ts
17.18% <0.00%> (ø)

src/components/exports/exportsLink.tsx
43.75% <0.00%> (ø)

src/routes/components/currency/currency.tsx
31.25% <0.00%> (ø)

src/routes/costModels/components/errorState.tsx
37.83% <0.00%> (ø)

... and 24 more

Continue to review full report at Codecov.

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


It's not possible to flash and use REPL in the same time

Hi
I have been using Sublime with the UPIOT plugin a lot lately to work with micropython. It still seems to me to be the most reliable tool for working with micropython prototypes. I have a little note about installation and use in my repository.
One of the most important features of UPIOT is the seamless use of the COM port. I don't need to disable the REPL console to use sampy / upload files. It works in the same console. Using this plugin, when flashing with the console open, an error pops up - COM port, of course, busy. This feature just wasn't provided? Is this feature available because of modified ampy — sampy? Is it possible to implement this seamless behavior in intellij plugin?
This UX doesn't feel right — the terminal window is just in one window, the error in another, close the console, then flash, then open...

I think, pull request #139 related

My current work-around is to have Thonny open and connected to the board for upload and REPL.  I edit the code on PyCharm and never connect to the board from it.  I would very much like to not have to do this and work entirely from PyCharm.

I've just spent some time attempting to replicate this kind of workflow within pycharm. Unfortunately I could not get it down to a button press, but I got it down to a terminal line run, although you need to quit out of the terminal REPL between runs.
Here's my approach in case if helps anyone else:

Within my local pycham venv I installed the rshell package.
I created a flash_dev.sh file with the below contents. Make it executable (chmod +x flash_dev.sh)

#!/bin/bash
rshell --buffer-size=512 --quiet "cp $1 /pyboard/dev.py; repl ~ import dev"

You can then use a pycharm terminal window to run the script, passing the file you want to flash like: ./flash_dev.sh script.py.
You can exit out the repl with Ctrl+X. A re-run from being in the repl would just need a Ctrl+X followed by :arrow_up: then Enter in the terminal.

I have other flash_*.sh scripts in my working repo here to flash files across (without running) and to flash a file as the main.py file on the device.
I tried to wrap this in a run configuration but failed since you can't pass the active filename to the shell run configurations. You could hard-code it to a specific script, but then running without remembering to close the existing repl session makes things messy.


Ensure TLS related fields are initialized

Jira: OSPRH-8078

/hold

/cherry-pick 18.0.0-proposed

/remove-hold


Vercel has a cleanUrls option

Hey!
FYI, Vercel has a cleanUrls option for vercel.json.

When set to true, all HTML files and Serverless Functions will have their extension removed. When visiting a path that ends with the extension, a 308 response will redirect the client to the extensionless path.
For example, a static file named about.html will be served when visiting the /about path. Visiting /about.html will redirect to /about.
Similarly, a Serverless Function named api/user.go will be served when visiting /api/user. Visiting /api/user.go will redirect to /api/user.
{
  "cleanUrls": true
}

https://vercel.com/docs/configuration#project/clean-urls

Thanks, will add a line for this option (and also trailingSlash) soon.
I understand that /file.html will redirect to /file with cleanUrls, however I was surprised that without this option, /file is 404 while /file.html works.
Particularly, next export will create files such as file.html by default (without trailingSlash: true) so wouldn't it make sense that a no-config next export works on a no-config Vercel by default?

Thank you! We will soon be changing the default on Vercel to have cleanUrls enabled by default. Stay tuned for that changelog.
Re: next export – the vast majority of Next.js applications are using next start, actually. I agree that it should work out of the box, though. We will fix this!

Yes that's what I thought 😆 using next export on Vercel is probably not the most used setup

@leerob is there a way to configure cleanUrl + trailingSlash using the Vercel interface?
What's the simplest way for me to deploy the static folder with 4 distinct optionscombinations? Is there any way to avoid having 4 distinct folders?

Currently, those options are only available through vercel.json. We will be adding them to the UI, though!
You can simply create multiple projects with different vercel.json files for testing 😄

@leerob but doesn't this mean that I have to create/maintain multiple copies of my static folder in this repo then?
I'd like to avoid that 😅 let me know if there is a way, or if it will be configurable on the UI soon, otherwise I'll have to do that and handle multiple copies.

No, you can import the same repository multiple times. One to many relationship with projects. So you can have the same code but different settings per project!

Yes I understand that, but how can I have different Vercel settings for the same github repo? I'd have to use 4 vercel.json config in any case, and it's only possible to put one in /static/vercel.json
I'm thinking of using different branches for each vercel deployment, any better idea?

Ahh, my bad. Sorry, I wasn't putting the full picture together here.
Yes, since you need to have multiple vercel.json files, you could do different branches! Or separate folders entirely.

Oh noooow :'(
I just created the 6 branch to account for all the combinations of cleanUrls + trailingSlash configs, and now get this error:

Is there anything you can do to unlock this? I'd prefer not having to maintain multiple forks 🤪

P.S. vercel.json is in the root of the folder, not underneath static.

From what I see, it's fine to nest the config file in /static/vercel.json as long as I set /static as the root in the UI
Also, noticed that the trailingSlash option is available on both Next.js and Vercel, any idea how they relate? I know the trailingSlash of Next.js will also affect filenames on next export

Happy to sponsor a Pro team (which has 10) for this 😄

Create a new Pro trial and let me know the team slug
Transfer the project from your Personal Account to the team
Ensure it's working!

thanks :)
Here's the slug: https://vercel.com/teams/trailing-slash-team/

Done!

Thanks
Will try to finish all this tomorrow 😜
Le mar. 6 juil. 2021 à 20:31, Lee Robinson @.***> a
écrit :

Done!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/slorber/trailing-slash-guide/issues/1#issuecomment-874989297,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAFW6PVL67SPXYYAOBG6FYLTWNDZXANCNFSM46UGJ2MQ
.

Thanks, it seems to be working.
Now covering all the options (I think)
Seems like Vercel has some unexpected serving behaviors. Using cleanUrls is not enough to get file.html served and you have to use the trailingSlash option too?
https://github.com/slorber/trailing-slash-guide

FYI I wasn't able to transfer the projects (asking for CB) so I recreated them:

@slorber Guessing you hit the issue since I added a sponsorship to your account, and never put in card information 😄 Edge case!

Seems like Vercel has some unexpected serving behaviors. Using cleanUrls is not enough to get file.html served and you have to use the trailingSlash option too?

That sounds unexpected, I will report back to the team!

We will soon be changing the default on Vercel to have cleanUrls enabled by default. Stay tuned for that changelog.

@leerob was wondering if cleanUrls: true is now the default, and if other changes were made?
It seems a Docusaurus user may be affected by the serving behavior: https://github.com/facebook/docusaurus/discussions/6706
Should SSG deploying to Vercel document that cleanUrls: true is a recommended setting?

Hey!
FYI, Vercel has a cleanUrls option for vercel.json.
When set to true, all HTML files and Serverless Functions will have their extension removed. When visiting a path that ends with the extension, a 308 response will redirect the client to the extensionless path.
For example, a static file named about.html will be served when visiting the /about path. Visiting /about.html will redirect to /about.
Similarly, a Serverless Function named api/user.go will be served when visiting /api/user. Visiting /api/user.go will redirect to /api/user.
{
  "cleanUrls": true
}

https://vercel.com/docs/configuration#project/clean-urls

please show me how and were to find the vercel.json files to edit this in.


packaging+docker: Outdated go.mod used in images and tarball

What version of Go are you using (go version)?

go version go1.20.4 linux/amd64
(docker image golang:1.20.4)

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.20.4"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-O2 -g"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-O2 -g"
CGO_FFLAGS="-O2 -g"
CGO_LDFLAGS="-O2 -g"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2411391097=/tmp/go-build -gno-record-gcc-switches"

What did you do?
Started a Go docker container - docker run -it --rm -v $PWD:/src golang:1.20.4 bash and built a project in order to confirm the fix in https://github.com/golang/net/commit/82780d606d189ee6d3e9dd4683e493d832f3caaf took effect
What did you expect to see?
The fix should exist in the h2 bundle (/usr/local/go/src/net/http/h2_bundle.go)
What did you see instead?
It does not (and the issue still repros) because h2_bundle.go is still based on x/net v.4.1
Extra
To try and dig into it a bit further, I figured I'd manually update the bundle and see whether that pulled the changes down
root@dfd0ea978345:/# git clone https://github.com/golang/tools.git
root@dfd0ea978345:~/tools/cmd/bundle# cd tools/cmd/bundle
root@dfd0ea978345:~/tools/cmd/bundle# go build main.go
root@dfd0ea978345:~/tools/cmd/bundle# cp main /bundle

# Taken from the header of the existing bundle
root@dfd0ea978345:/usr/local/go/src/net/http# /bundle -o=h2_bundle.go -prefix=http2 -tags='!nethttpomithttp2' golang.org/x/net/http2`

The file regenerated on disk, but the fix still wasn't in there.
The reason for this was in /usr/local/go/src/go.mod:
root@d8a072516a9a:/go# grep "x/net" /usr/local/go/src/go.mod
	golang.org/x/net v0.4.1-0.20230214201333-88ed8ca3307d

The docker container is referencing a really old version.
I updated to use v0.10.0 (as here) and updated vendor/modules.txt) accordingly.
The bundle then updated correctly and I was able to build my project with the expected fix in place

Although it's the docker image that I noticed this in, it looks like it's the upstream tarball that's the issue.
The Dockerfile does
wget "https://dl.google.com/go/go1.20.4.linux-amd64.tar.gz"

If we check that
ben@ratchett:~/tmp/go_bundle$ tar xzf go1.20.4.linux-amd64.tar.gz
ben@ratchett:~/tmp/go_bundle$ grep x/net go/src/go.mod
	golang.org/x/net v0.4.1-0.20230214201333-88ed8ca3307d

For completeness, this affects the Mac and Windows packages too
ben@ratchett:~/tmp/go_bundle$ tar xzf go1.20.4.darwin-amd64.tar.gz
ben@ratchett:~/tmp/go_bundle$ grep x/net go/src/go.mod
	golang.org/x/net v0.4.1-0.20230214201333-88ed8ca3307d

ben@ratchett:~/tmp/go_bundle$ unzip go1.20.4.windows-386.zip
ben@ratchett:~/tmp/go_bundle$ grep x/net go/src/go.mod
	golang.org/x/net v0.4.1-0.20230214201333-88ed8ca3307d

Oh, doh.... they're psuedo-versions.
88ed8ca3307d is the final commit on this branch: https://github.com/golang/net/commits/internal-branch.go1.20-vendor

Hey @seankhliao - quick follow up: it doesn't look like it's in the list for 1.20.5 either: https://github.com/golang/go/issues?q=milestone%3AGo1.20.5+
Just wanted to make sure the fix itself hadn't been overlooked - there isn't a PR on the github side, because it was created directly in Gerrit: https://go-review.googlesource.com/c/net/+/486156

typically we will not backport, our policy is at https://github.com/golang/go/wiki/MinorReleases

Thanks! I think this probably meets the criteria, so I'll raise a cherrypick request so that it can be assessed there


md-dialog height is wrong on Chrome on Android (address bar issue)

md-dialog height is wrong on Chrome on Android where the footer is not visible and if there is scrollable content the user is stuck without getting to for example an exit button in the footer.

Good catch! See discord thread.
I noted a few problems when investigating.

sizes in the dialog are using vh instead of dvh: this should just be changed.
in fullscreen mode, the settable container tokens are not honored: probably should just remove this.
dialog appears to apply a default inset-block-start: probably will need to change the default when in fullscreen mode.

Workaround until fixed which I believe should work:
md-dialog[showing-fullscreen] {
  /* hack: private! */
  --_container-max-block-size: 100dvh;
  --md-dialog-container-inset-block-start: 0px;
}

Workaround works perfectly, thanks! :) Will remove hack after this gets fixed.


Keeping same source in all translation

Some PR update only some lang translation.
I think all source source code must be same.
How do you think about building readme with some script and seperated translation files?
For example..
// en.js
{
util: {
title: "Utilities",
description: "",
contents: {
  isArray: { title: "isArray", description: "" }
}
...
}

and
// isArray.js
// jQuery
$.isArray(range);

// Native
Array.isArray(range);

Nice idea to find a way to keep them sync automatically.
But this can be tough, firstly we should try to keep the docs easy maintain. Right now markdown is easy.
The JS are not easy enough, but still a good start, we should investigate on this further.

We can check diff by travis-ci.
First, grep source code part and get count of each source part. If they have some difference, it was broken.
How about this?

How about keep code source in js files and using some directives to insert them? For example:
In markdown:

#### code example:

```javascript
{{include 'src/a.js'}}
```

In build tools:
source.replace(/\{{2}include (['"])([^\1]+)\1\}{2}/g, (match, quote, src) => fs.readFileSync(src).toString());

In my view this will also be helpful for further testing :)

Some source code have comments that need to be translated. If you want to include them, it will not be possible to get internationalized comments (well... in reality, source code is a lot of time in English).


move pull to options

What is the benefit of having this PR merged in? I see what the code does, but why does pull need to be an option?


Improve wording of delete actions (EXPOSUREAPP-10407)

Re-addresses EXPOSUREAPP-10407 and fixes #4323

The issue here is already fixed in 2.14 using right terms also

https://github.com/corona-warn-app/cwa-app-android/blob/e3250b766dc6b12dabd9d4d817da2a875a407ab7/Corona-Warn-App/src/main/res/values-de/recycler_bin_strings.xml#L14
https://github.com/corona-warn-app/cwa-app-android/blob/release/2.14.x/Corona-Warn-App/src/main/res/values-de/recycler_bin_strings.xml#L37


GC Adjustments for Stable Regions

Some GC- and memory-specific adjustments for stable memory regions:

Using the forwarding pointer of the incremental GC in the compiler and runtime system.
Checking whether region0 is defined before access (since dereferencing address 0 would not trap in release mode).
Initializing the 16-bit padding field in the region as it is read by the compiler-generated code.
Applying write barriers when assigning Region.vec_pages.

CI passed. Ready to merge?


Passing Parameters to Pipeline

Is there a way with this extension to pass variables to the downstream pipeline if the pipeline is in a separate project?

Hi @Silburfuchs,
Did you find a solution for this use case?
@maikvandergaag

this is not yet supported and needs to be implemented

@Silburfuchs @khalidibnelbachyr This might be late. but did you guys try this api before?
{orgULR}/{pipelineName}/_apis/pipelines/{buildDefinition.ID}/runs
https://gist.github.com/chenghuang-mdsol/c99f5411a7636cc02d7183fe31837217

is in production


#1 add support for horses in database initialization

/paulo - can you please review this pull request?

/paulo - can you please review this pull request?

/paulo - can you check now?


feat(ui): improved the UI for announcement page

Fixes #3524
Describe the changes you have made in this PR -
I have improved the UI of the Announcement Page
Screenshots of the changes (If any) -

cc @tanmoysrt this is the new one


feat(lint): create module spark-lint and import MaterialComposableUsageDetector

@soulcramer, it's ready to be reviewed. I'll add the packaging/export on another PR.


Refactor and optimize

Thanks for the resource! Really cool.
I checked it out yesterday and found it very interesting, just thought I'd improve it a bit.
Removed the IDE settings from git - shouldnt be versioned.
Refactored some code out to functions and fixed the weird handling it coords/playername indices.
Added debug option to generate 1024 random blips and send it to clients - helps with debuging (discovered and fixed a memory leak (or just weird GC timing, not sure, but with 1024 blips it was leaking memory fast).
If you find these changes useful I'll continue on improving it. Currently the biggest issue IMO is that its sending large events, which could be fixed by splitting the blips to chunks and sending chunks to clients over time. As per Ferrum's message on discord Latent events have some weird issues so its not reliable enough to use.
Another thing this script is doing, which im not sure you know about, its sending blips in parallel. I.e. if you have 512 players online, you only wait for 5 seconds between each update but the update itself takes 51 seconds. So you have 10 threads sending blips in parallel.

Noticed that you iterate over players with a static number:
for i = 1, 1024 do
Why not use: https://docs.fivem.net/docs/scripting-reference/runtimes/lua/functions/GetPlayers/

If you mean in the function GetDebugBlipsOfPlayers(), its actually a debug function meant for testing this script solo without other players :)
This way you can test how it would perform with 1024 players without having that many people. Its also the way I found out and fixed the memory leak.
This MR can be closed since there is no interest in improving this script.

I was going insane with that memory leak. Thank you so much!!


Previous optical element

Find a way to display Reference O. E. you're referring to when positioning a new O. E.
This depends on:

selected Mode

Orientation

First, issue #10 has to be solved!

Q1: you mean that #10 must be solved because the function that gets the reference optical element may fail, and in this case the field "Reference O.E." should be "Not found", correct?
Q2: Once this exception will be solved, it seems to me that the solution is crystal clear. Right os am I missing something?

You're correct...

Both for Q1 and Q2?

Yes, for both...

I was working on this today. This will be quite tricky to do in the GUI, as the Wiser beamline only gets built when clicking on Compute, so the Reference O. E. technically doesn't exist. We can discuss at some point in the future, I am skipping this at the moment.

There is a placeholder now...

Definitely True.
This makes us remember that
We decided to separate field computation and beambline construction+positioning (BeamlineElements.Append +BeamlineElements.ApplyPositioningDirectives), it's time to do the first step. Of course this does not solve the present issue but can help.
Once this is done, I have a question.
Is it possible do "progressively build" the beamline structure (i.e. BeamlineElements), without calling yet the positioning directives stuff? I envision something like:
1)drag&drop the new optical element
2)The optical element is initialized(to default values) and appended to the beamline (BeamlineElements.Append)
3)The user modifies properties of the OE
-Here the OE can acces the beamline of which he is the last item, or can anyway call the reference.
- When the form is closed... we update the OE with a one having the right values. This is difficult for how we did the cod in WofryWise, but I guess that just calling .__init__(user_values) should work. Or we use a dummy OE, etc
What do yout think?

Action:

it is related to the new structure of do_wiser_computation
it is "automatically" solved when solved issue #10

NO ACTION REQUIRED

We put the do_wiser_beamline somewhere into the GUI, for example where you select the PD type (distance from source, distance from previous, etc.). This way the beamline will be initialized and the previous element will be picked up by get_previousOE...

Probably since we are late this is simpler for now.
But in the future we should consider the following alternative
Operation A
do_wiser_beamline is called every time that a OASYS widget is appended/linked to another. It contains:

init OpticalElement with CoreOpticsElement=None => do_wiser_optical_element
BeamlineElements.Append(...) => this can be incremental or traverse OASYS chain of responsibility from the beginning every time, if it is simpler.

Problems what happens if the widghet is disconnected? or if distinct "partial chains" are present? (e.g. A-B-C and F-G-H) and I am still drawing the missing dots?)
Operation B

every time that you change/close a widget, you init the CoreOpticsElement and you replace it =>do_wiser_core_optics_element

Operation C

refresh_wiser_beamline => RefreshPositioningDirectives. Called via a) menu command, AND  b) before running the computation

Comments?/ramifications?
tnx

It works in the following way, you click "Beamline" and then the reference element is updated:

The thing which has to be updated still is that when you set:

Set fixed distance from source it always shows the Source

Done:

Acknowledged.


🐛 [export][llama2] AssertionError: Currently we don't support unsqueeze with more than one dynamic dims

Bug Description
Configuration: llm_examples_main branch, current torch version: 2.4, transformers==4.41.2
AssertionError: Currently we don't support unsqueeze with more than one dynamic dims
Error :
    return impl.unsqueeze.unsqueeze(
  File "/work/TensorRT/py/torch_tensorrt/dynamo/conversion/impl/unsqueeze.py", line 36, in unsqueeze
    len(get_dynamic_dims(input_val.shape)) <= 1
AssertionError: Currently we don't support unsqueeze with more than one dynamic dims.

While executing %unsqueeze_8 : [num_users=1] = call_function[target=torch.ops.aten.unsqueeze.default](args = (%mul, 0), kwargs = {_itensor_to_tensor_meta: {<tensorrt_bindings.tensorrt.ITensor object at 0x7f0bdd34b070>: ((s0, s0 + 1), torch.bool, False, (s0 + 1, 1), torch.contiguous_format, False, {}), <tensorrt_bindings.tensorrt.ITensor object at 0x7f0bdd34b1b0>: ((s0, s0 + 1), torch.float32, False, (s0 + 1, 1), torch.contiguous_format, False, {}), <tensorrt_bindings.tensorrt.ITensor object at 0x7f0bd714a570>: ((s0, s0 + 1), torch.float32, False, (s0 + 1, 1), torch.contiguous_format, False, {}), <tensorrt_bindings.tensorrt.ITensor object at 0x7f0bdd1f7270>: ((s0, s0 + 1), torch.bool, False, (s0 + 1, 1), torch.contiguous_format, False, {}), <tensorrt_bindings.tensorrt.ITensor object at 0x7f0bdd1f5330>: ((s0, s0 + 1), torch.float32, False, (s0 + 1, 1), torch.contiguous_format, False, {}), <tensorrt_bindings.tensorrt.ITensor object at 0x7f0bdd1f7070>: ((1, s0), torch.int64, False, (s0, 1), torch.contiguous_format, False, {}), <tensorrt_bindings.tensorrt.ITensor object at 0x7f0bdd1f4bb0>: ((1, 1, s0), torch.int64, False, (s0, s0, 1), torch.contiguous_format, False, {}), <tensorrt_bindings.tensorrt.ITensor object at 0x7f0bdd1f52f0>: ((1, 32, s0, 64), torch.float32, False, (2048*s0, 64, 2048, 1), None, False, {}), <tensorrt_bindings.tensorrt.ITensor object at 0x7f0bdd1f5bb0>: ((1, 32, s0, 64), torch.float32, False, (4096*s0, 128, 4096, 1), None, False, {}), <tensorrt_bindings.tensorrt.ITensor object at 0x7f0bdd6eb830>: ((1, 32, s0, 128), torch.float32, False, (4096*s0, 128*s0, 128, 1), torch.contiguous_format, False, {}), <tensorrt_bindings.tensorrt.ITensor object at 0x7f0bdd2faab0>: ((1, 32, s0, 64), torch.float32, False, (2048*s0, 64, 2048, 1), None, False, {}), <tensorrt_bindings.tensorrt.ITensor object at 0x7f0bdd2d7ab0>: ((1, 32, s0, 64), torch.float32, False, (4096*s0, 128, 4096, 1), None, False, {}), <tensorrt_bindings.tensorrt.ITensor object at 0x7f0bdd367ab0>: ((1, 32, s0, 128), torch.float32, False, (4096*s0, 128*s0, 128, 1), torch.contiguous_format, False, {})}})

To Reproduce

Expected behavior

Environment

Build information about Torch-TensorRT can be found by turning on debug messages

Torch-TensorRT Version (e.g. 1.0.0):
PyTorch Version (e.g. 1.0):
CPU Architecture:
OS (e.g., Linux):
How you installed PyTorch (conda, pip, libtorch, source):
Build command you used (if compiling from source):
Are you using local sources or building from archives:
Python version:
CUDA version:
GPU models and configuration:
Any other relevant information:

Additional context

Closing this as this is fixed by https://github.com/pytorch/TensorRT/pull/2933


[Wildcard Variables] UNUSED_LOCAL_VARIABLE support

As per the discussion in https://github.com/dart-lang/linter/issues/4968, we want to start reporting UNUSED_LOCAL_VARIABLE for non wildcard underscore cases (e.g., __, ___, etc).
UPDATE: non-wildcard underscores will produce diagnostics but whether we want to start reporting on other identifiers (e.g., e or exception) is still an open question. (See proposal below.)

Follow-up from https://github.com/dart-lang/linter/issues/4974,
Proposal: report UNUSED_LOCAL_VARIABLE  on all unused bound catch clause parameters
Specifically, this means we start flagging the following (which we don't today) with an UNUSED_LOCAL_VARIABLE diagnostic:
try {
} catch(e) { }

providing a quick-fix conversion to:
try {
} catch(_) { }

Since the idiom of catching (and ignoring) an exception named e or similar is well established, this will produce a bunch of diagnostics in some projects but with dart fix code can effortlessly be migrated.
/cc @dart-lang/language-team @dart-lang/analyzer-team

This resurfaced while testing const evaluation in the analyzer, in a comment here.
We should probably remove the UNUSED_LOCAL_VARIABLE diagnostic that's being reported here and other places.
test() {
  const _ = true; // Should not have `UNUSED_LOCAL_VARIABLE`, but currently does.
  const c = _;
}

Revisiting this case, I think it's actually working as intended and we're getting tripped up by the test framework.
Here's the test:
  test_visitSimpleIdentifier_wildcard_local() async {
    await assertErrorsInCode(r'''
test() {
  const _ = true;
  const c = _;
}
''', [
      error(WarningCode.UNUSED_LOCAL_VARIABLE, 35, 1),
      error(CompileTimeErrorCode.UNDEFINED_IDENTIFIER, 39, 1),
      error(CompileTimeErrorCode.CONST_INITIALIZED_WITH_NON_CONSTANT_VALUE, 39,
          1),
    ]);
  }

The unused variable being reported is actually c (the _ is at offset 17).
Offset-based tests test expectations are easy to get tripped up by!
@kallentu: do you recall the intention of the test?
If it's valuable as-is, we could make it a little more explicit by updating the expectation like so:
error(WarningCode.UNUSED_LOCAL_VARIABLE, 35, 1, messageContains: ["'c'"]),

Ah, that makes a lot more sense. Woops, sorry for the noise.
The test was mainly trying to make sure we would produce an error if we tried to access/use the const _. I think it's useful to have still.


rootston: add keybinding to toggle decoration mode

This is useful for xdg-decoration client devs to test decoration mode changes triggered server-side.
Test plan:

Add Ctrl+Shift+d = toggle_decoration_mode to rootston.ini
Open rootston and then spawn build/examples/toplevel-decoration
Press the keybinding

I'm not familiar with wlroots code, but looks sensible to me.
Seems to work well with the toplevel-decoration test, as well as my patch for xdg-decoration in Qt clients: https://codereview.qt-project.org/#/c/235936/3

Thanks!


[WIP]bugfix iranmap

[x] modify label
[x] add rows
[x] clean data tsv
[x] background color of svg for download

I can't find the issue about black background color on my mac


Wallet not handling LNURLp redirects

I have configure the LNURL https://btc.us/.well-known/lnurlp/bilall to redirect to https://getalby.com/lnurlp/bilall with the status code 301.
This means that is<EMAIL_ADDRESS>is added as recipient in the wallet, the wallet should send the payment to<EMAIL_ADDRESS>However, adding<EMAIL_ADDRESS>throws a 503 error. Adding<EMAIL_ADDRESS>works perfectly though.
Note: I was using the Legend demo server for this: https://legend.lnbits.com/
These screenshots show the btc.us redirect not working.

These show the getalby.com address working.

I think it makes sense to follow redirects for lightning addresses as domains should be able to redirect to other valid lightning addresses. I can volunteer to write a fix for this.

@talvasconcelos is it fixed? I haven't tested recently or is the spec updated to disallow following redirects?

Was asking because you mentioned a fix!

no I haven't fixed it. why should it be closed? it should either be fixed or it can be closed as spec compliant.


Save issue - saves fine, but won't allow a second "save"

Hi - thanks for the great library!
When I listen to the "saved" event, it triggers successfully, but it seems the tools stop listening.  (I can no longer hilight and edit).  If I trigger save a second time, I get
Uncaught TypeError: Cannot read property 'removeAttribute' of null
    at c.unmount (contentTools.js:110)
    at c.save (contentTools.js:113)
    at HTMLElement.sb.onclick (contentTools.js:946)
c.unmount @ contentTools.js:110
c.save @ contentTools.js:113
sb.onclick @ contentTools.js:946

Even if I just return without doing anything this happens.  For example:
editor.addEventListener('saved', async function (ev) {
        var name, payload, regions, xhr, template;
        return true;
    });

Is the API expecting a return code or some sort of trigger to indicate success and return to an editable state?

Hi @chronofish can you post enough of your JS and HTML somewhere I can have a look, clearly something is going wrong the first time save is called (you don't need to return anything) but I can't see what from the information you've provided. The error the second time around is likely due to the editor not being put into the right state after the first save and some element being missing.

Relevant HTML
Save button

Editable section

Place cursor and start editing!

                            You can use the floating toolbar to edit this document - just be sure to hit the save button before you're done!

                            More fund stuff

javascript (file called contentTools.js)
// ContentTools
import ContentTools from'ContentTools/build/content-tools.min.js';

window.addEventListener('load', function() {
    var editor;

    ContentTools.StylePalette.add([
        new ContentTools.Style('Author', 'author', ['p'])
    ]);

    editor = ContentTools.EditorApp.get();
    editor.init('*[data-editable]', 'data-name', '', false);

    editor.addEventListener('saved', async function (ev) {
        var name, payload, regions, xhr, template;
        return true;
    });

var sb = document.getElementById('saveButton');
    sb.onclick = function() {
        editor.save();
    }

    editor.start();
});

Also - thanks for the impressively fast response!

Ah OK so you have a custom save button - no worries but this explains why the editors state is getting out of wack.

However, if you want the save button to save the changes and exit edit mode then you need to stop the editor, something like:
editor.ignition().state('ready')
editor.stop(true)

Let me know if that helps out.

YES!  Thank you! that was a super easy fix!


Enum with maxlength/minlength

Hi
Should maxlength/minlength be valid attributes with enum?
"status": {
"type": "string",
"description": "pet status in the store",
"maxLength": 12,
"enum": [
"available",
"pending",
"sold"
]
}
Thanks
Shweta

It kind of goes against the enum being there so I don't think so.

Yes you are correct , but is it specified in the specification . When i run the open api document against any validator it doesn't show any error

It's valid, it just doesn't really help much. If one of the enum values would be longer than 12 characters, that enum value will not be valid through validation..

Yup so should this be fixed in specification then so that  all other dependent tools like validators and code generators can also update as per specification?

What is there to fix?

I cannot imagine what a fix would be @shwetashukla, but regardless, OpenAPI v3.1 Schema Object (where the enum property is described) is JSON Schema. Seeing as this is valid JSON Schema, there is nothing to fix in OpenAPI. The conversation could be had on the JSON Schema spec repo, but the same question exists: I don't know if there's anything in the spec to fix there either.

@philsturgeon @shwetashukla I'll state definitively that there is nothing to fix here.
JSON Schema does not forbid apparently-nonsensical combinations of attributes.  If you want to do that, a linter or a custom meta-schema is the appropriate place to decide what you want to forbid.
There are several reasons why this is allowed, but the most fundamental is that it keeps implementations simple.  You just evaluate all of the keywords you have, with no need to keep track of which keywords conflict with which other keywords.

Right. Put another way, each JSON Schema assertion has independent veto power. A value has to pass all of the assertions in order to be valid.
It's possible for a schema to include constraints that are redundant, overlapping, or even contradictory, making the schema unsatisfiable. But it's up to the schema designer, posssibly with the help of linters or other tools, to avoid these issues.
OpenAPI 3.1, currently in progress, aims to close the gap so that OpenAPI documents can use the full set of JSON Schema keywords. That's the direction, and we don't want to adopt any changes that would put OpenAPI out of step with JSON Schema. But there is an Alternative Schema proposal that would allow other schema languages to be used in OpenAPI. We could take up that proposal in a future version of the OpenAPI spec.
@shwetashukla , hopefully we've addressed your concern, so I'll close this issue for now. If you feel the issue isn't really resolved, please feel free to reopen the issue and provide further comments.

Thanks @tedepstein  @philsturgeon @handrews for the clarification


Running Error

Hi, I want to try LLM-Guard using Colab, and when I run the code, it shows an error:
WARNING:presidio-analyzer:model_to_presidio_entity_mapping is missing from configuration, using default
WARNING:presidio-analyzer:low_score_entity_names is missing from configuration, using default
WARNING:presidio-analyzer:Model en_spacy_pii_distilbert is not installed. Downloading...
✘ No compatible package found for 'en_spacy_pii_distilbert' (spaCy
v3.6.1)
An exception has occurred, use %tb to see the full traceback.
SystemExit: 1
can I know how to fix it?

Hey @NEWbie0709 , thanks for reaching out. In our new version, we are removing this dependency but it still exists in v0.3.0.
https://github.com/laiyer-ai/llm-guard/blob/v0.3.0/README.md#installation
Run
pip install https://huggingface.co/beki/en_spacy_pii_distilbert/resolve/main/en_spacy_pii_distilbert-any-py3-none-any.whl

Alright thankyou


Code cleanup

I went and cleaned up some of the FormatHelper class to make the code more uniform and follow the same style.

This also satisfies a CodeFactor code format issue

Is it ready to merge?

Let me do some quick review to see if I got everything

I can say that everything is working, but I'd test it from your end too.

Everything works as expected at my end too. Good job.


Package distribution improvements

Wanted to give this a try on a project using laravel mix and was unable to run it:

Bunding for package distribution can be a pain. Here are a few things that might help:

An export map in packages.json:

{
  ...
  "exports": {
    ".": {
      "import": "./dist/index.mjs",
      "require": "./dist/index.cjs",
      "types": "./dist/index.d.ts"
    }
  }
}

A module key in your package.json, like:

  "module": "dist/index.mjs",

Rollup into a single .mjs and a .cjs file. You can use rollup for this (admittedly a pain).

Thanks for the info, yeah had a quick look into this in the beginning and wanted to postpone this. But apparently it can't wait any longer. Will try to fix this by tomorrow.