[feature request] allow for sorting the spells by spell level

I'm playing a resource caster which doesn't use ordinary spell slots but a resource (item). The spells take up that resource in the same amount as the level of the spell. In order to not have to fiddle with spell slots, I configured all these spells with their respective spell level and "Innate spellcasting". But within that category there's no level sorting. This requests to allow for sorting by level within the respective categories. As a third option on the same level as "sort alphabetically" and "sort manually".
Furthermore it would be nice if there was a column or place which shows the individual spell's level.

Spellcasting is generally still a big work in progress, and something like this (Sounds similar to a Spell Point system) is 100% possible but the work around of a spell needing to be innate is wonky I'll give you that. From what I remember there was no real need to sort Innate spells because Innate normally assumes no upcasting iirc. You cast your Innate spells innately at their base level and what not.
Something like Spell Points could solve something like this, making a custom version of a spell-point spellcasting progression for a specific class,. Though it is far off and we've still yet to have a PR published for a Spellcasting Advancement to spruce up the whole spellbook system.

@Zanderaf I also came to the conclusion that "something like spell points" could help solving this, which lead me to create yet another feature request which points to all the advantages I guess: https://github.com/foundryvtt/dnd5e/issues/3053


Accept Feature arg

Fix so that get_log_density() works even after passing Feature.  @vigsterkr , comments?

can you trigger the CI again to see if everything is working please?


Can't find .dll file.

 I have downloaded the latest release and extracted but I can't seem to find the .dll file. I have tried every way of putting the files in the plugins\ folder but nothing. Not even an error code.
I'm using the latest version of PKHex being 19.12.09.
I'm not sure if i'm missing certain files or plugins to read the main raid files.

There is a release tab on github where you can find the dll: https://github.com/Leanny/PKHeX_Raid_Plugin/releases


testutil helpers are hard to use and make too many assumptions on command outcomes

Description
Specifically, some helpers testing stdout do first assert that exit code == 0.
However, there are legitimate cases where exit code is not 0 and you still want to test the output.
Recently, we also faced issues with commands being executed multiple times as each helper invocation used to call Run again.
In light of these issues, maybe it will soon be time to have a look at type Cmd and possibly revamp it to make testing easier.
Steps to reproduce the issue
na
Describe the results you received and expected
na
What version of nerdctl are you using?
main
Are you using a variant of nerdctl? (e.g., Rancher Desktop)
None
Host information
No response

Besides bugs in our testing tools - hopefully got fixed by now - laying out issues here with the current design, that should inform a proposal to enhance:

use of defer instead of t.Cleanup - cleaning up should be taken care of automatically
not calling cleanup routines before running tests - making failing tests successive reruns to fail (locally) - cleaning up should be taken care of automatically
Cwd for binary calls is by default the current working directory of the test process - this is causing a variety of issues, as it could very well be read-only (lima), and should by default be a temp directory
manipulating the environment directly has side-effects for other tests - there should be an obvious mechanism for people to set additional env without polluting the parent scope
tests are usually a blurb of mixed together setup, cleanup, and actual test routines - making them hard to read and figuring out what is actually being tested - abstraction should encourage a clean separation of Setup, Cleanup, Command
tests are inherently repeating the same boilerplate over and over (tID := testutil.Identifier()) - since all tests are doing it, that should be hidden away
structuring tests and subtests is left as an exercise to the developer - leading to a wide variety of approaches and complex boilerplate - we should have a cleaner, simpler, ready to go abstraction for that
debugging is hard: some assert methods will provide no feedback whatsoever on what was the command that actually failed, what was the output of it - all failing commands should provide complete output automatically
icmd.Expected is too limiting, and is making assumptions that:

there is only one error you can test
you can only test the output if exitCode == 0

running commands with other binaries than the current target (eg: not calling base.Cmd) is left as an exercise to the developer, leading to all of the issues above (Chdir, Env manipulation, no debugging output, etc)
no-parallel is the default - unless specified otherwise - it should be the opposite


borgbackup: 1.1.11 -> 1.1.13

Motivation for this change
New upstream releases:

https://github.com/borgbackup/borg/releases/tag/1.1.12
https://github.com/borgbackup/borg/releases/tag/1.1.13

Marked broken on Python 3.8 due to an upstream issue that is currently
under investigation.
Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

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

@flokli @dotlambda @globin

Why don't we fetch the source instead of the release tarball and cythonize ourselves?

I'm not sure what this will solve? We usually fetch from PyPI if there's a usable sdist.


PHP Toolbox extension

Description
This is a collection of commands to help PHP developers. The initial version includes two commands:

A unix timestamp helper for converting timestamps to formatted dates and quickly copying common timestamps
A php date format helper to search, build, and save date format strings

Screencast
Unix Timestamp Helper
https://user-images.githubusercontent.com/21592/162595259-e876ed92-b44d-4db8-86f6-a2339a011c56.mp4
PHP Date Format Helper
https://user-images.githubusercontent.com/21592/162595195-192ac0eb-5f32-44e6-99dd-45502d28d288.mp4
Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

I'm closing this due to inactivity; feel free to open it again or comment in the thread when you're ready to continue working on it 🙂
You can also catch me in Slack if you want to discuss 😄

I'm closing this due to inactivity; feel free to open it again or comment in the thread when you're ready to continue working on it 🙂
You can also catch me in Slack if you want to discuss 😄


Requests should allow access to users with admin role

Currently we check to see if the user is the "admin" user - we need to
check to see if the user has administrator priveleges regardless of
who they are.
Incidentally removes a couple of uses of any_instance_of :tada:
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1421878
Side note: I'm not sure why they other request types do not allow admin access to all requests, it seems that we should fix that as a follow up to this once merged.
@miq-bot add-label api, bug
@miq-bot assign @abellotti
Thanks @jvlcek for your help debugging this!

👍 Thanks @imtayadeway for fixing this. 🎵


LPC11U35 Compiler/linker issue

Some of my previously working LPC11U35 programs are hard faulting before they even get to main(), even known-good versions with older libraries. In an isolated test, I was able to produce an even weirder problem in which the presence of a destructor in a class breaks USBDevice, while removing it "fixes" it. I think this may be a compiler/linker issue, and that it may affect other targets as well. More details here: https://developer.mbed.org/forum/bugs-suggestions/topic/17204/

Additional experiments have shown that the LPC11U68 and LPC1549 are also affected by this issue.

I take it from your forum post that this is just happening with the online compiler?  If I take your weird bug sample and build it for my LPC11U24 board, it should reproduce the hard fault?

Note:  I built your LPC11U35_WeirdBug sample for the LPC11U24 with the online compiler and it didn't fault.  When I break in with GDB, it is always just running through the main loop.

I built online for the lpc1768 and was not able to reproduce either. Will keep trying different boards. I did notice that with both the connect false and the constructor false the hid device did enumerate which I found odd.

The example I posted doesn't hard fault, but USBDevice will break when the DummyClass's destructor is present. Windows will report the USB device has "malfunctioned", but the loop will still run IIRC. Removing the destructor, or overriding __aeabi_atexit() fixes the problem. Compiling it offline using uVision 4 works too.

It's behaving like a memory corruption issue, different programs are being affected in different ways. While playing around with library versions in one of my projects, I was able to get a binary that didn't hard fault, but USBDevice wouldn't enumerate. Now that same combination is hard faulting...

I see.  Too hard for me to debug without symbols then.  I will bow out and let you and Sam take care of it.

I think it might be a heap-related issue with the ARM micro toolchain, since overriding __aeabi_atexit() fixes it. http://www.keil.com/forum/21859/using-destructor-without-heap-results-in-stop-on-bkpt/

I just tested the LPC1768, and can confirm that it is NOT affected by this issue.

Here's something interesting, startup_LPC11xx.S doesn't appear to be defining __heap_base and __heap_limit properly. The assumption seems to be that __user_setup_stackheap() in sys.cpp will initialize the heap. However, according to Keil's documentation, that method isn't applicable to microlib... I would try changing the values, but unfortunately the online compiler isn't letting me edit startup_LPC11xx.S.

ARM Internal Ref: IOTMORF-229


Code documentation

This PR contains:

Documentation strings about the contents of the file where I think is helpful.
Disables warning missing docstring about contents of the file in pylint config.
Renames Class BuilderOvalGraph to BuilderOvalTree.

/packit copr-build

/packit copr-build

Hello @Honny1! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file oval_graph/converter.py:

Line 2:100: E501 line too long (100 > 99 characters)

There is nothing clearly wrong with documentation, but as Rober C Martin would say, one should document public interfaces and quirks in the code that are caused by limitations of the programming language or of the chosen framework.
Almost all other code documentation can be avoided correctly naming functions and variables, and by keeping those functions/methods small. I think that majority of the documentation that you propose doesn't fix any real problem - good for you! As you use descriptive names, it just states the obvious.

I like the evolution of the PR, it led to massive simplification of test suite output, and the code is readable even without extensive comments due to good naming practices.


Specify order of reviews

Affects article pages and index.

Reviews on the article should be displayed in reverse chronological order. See here:
https://projects.invisionapp.com/share/B9WVPQAS4PE#/screens/415053755
On the home page, the counter of total reviews is shown for each listing, alongside the latest review only:
https://projects.invisionapp.com/share/B9WVPQAS4PE#/screens/415097280


[AIRFLOW-1618] Add feature to create GCS bucket

Make sure you have checked all steps below.
JIRA

[x] My PR addresses the following Airflow JIRA issues and references them in the PR title. For example, "[AIRFLOW-XXX] My Airflow PR"

https://issues.apache.org/jira/browse/AIRFLOW-1618

Description

[x] Here are some details about my PR, including screenshots of any UI changes:
Added create_bucket method to gcs_hook and created corresponding operator GoogleCloudStorageCreateBucket
Added tests
Added documentation

Tests

[x] My PR adds the following unit tests OR does not need testing for this extremely good reason:
GoogleCloudStorageCreateBucketTest

Commits

[x] My commits all reference JIRA issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

[x] Passes git diff upstream/master -u -- "*.py" | flake8 --diff

Could you rebase on master? CI has been fixed.

Codecov Report

Merging #3044 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #3044      +/-   ##
==========================================
- Coverage   73.23%   73.22%   -0.01%
==========================================
  Files         178      178
  Lines       12472    12472
==========================================
- Hits         9134     9133       -1
- Misses       3338     3339       +1

Impacted Files
Coverage Δ

airflow/models.py
87.15% <0%> (-0.05%)
:arrow_down:

Continue to review full report at Codecov.

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

Let me know when LGTM @kaxil @fenglu-g

@Fokko LGTM now.

I still need to change the test which is causing the CI to fail. Will do that late today.

@Fokko Fixed the tests and LGTM. This can now be merged.


CSS imported to JS using ?inline contain JS code for URL handling instead of actual URLs when built for production

Describe the bug
One of our project which works fine with Vite 2.x has code like
import previewHacks from './preview-hacks.css?inline';

injectGlobalCss(previewHacks.toString());

where preview-hacks.css contains
@import url('line-awesome/dist/line-awesome/css/line-awesome.min.css');

The line-awesome.min.css file contains
@font-face{
  font-family:'Line Awesome Brands';
  font-style:normal;
  font-weight:400;
  font-display:auto;
  src:url(../fonts/la-brands-400.eot);
  src:url(../fonts/la-brands-400.eot?#iefix) format("embedded-opentype"),url(../fonts/la-brands-400.woff2) format("woff2"),url(../fo
 }

With Vite 3.0.0-3.0.7 the CSS string previewHacks.toString() contains in dev mode
@font-face {
  font-family: 'Line Awesome Brands';
  font-style: normal;
  font-weight: normal;
  font-display: auto;
  src: url("/VAADIN/@fs/path-to-project/node_modules/line-awesome/dist/line-awesome/fonts/la-brands-400.eot");

but when built for production it contains
@font-face{font-family:Line Awesome Brands;font-style:normal;font-weight:400;font-display:auto;src:url("+new URL('la-brands-400.c0e32387.eot', import.meta.url).href+");

Reproduction
Reproduces in a private Vaadin project. So far I have been unable to trigger it in a simple project. @patak-dev has access to the project though
System Info
System:
    OS: macOS 12.4
    CPU: (10) arm64 Apple M1 Max
    Memory: 8.07 GB / 64.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 17.9.0 - ~/.nvm/versions/node/v17.9.0/bin/node
    npm: 8.5.5 - ~/.nvm/versions/node/v17.9.0/bin/npm
  Browsers:
    Chrome: 104.0.5112.79
    Chrome Canary: 106.0.5241.0
    Firefox: 102.0
    Safari: 15.5
  npmPackages:
    vite: ^3.0.7 => 3.0.7

Used Package Manager
npm
Logs
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

Oh we actually see this in many many of our tests now also when trying to upgrade from 3.0.4 to 3.0.7: https://github.com/vaadin/flow/pull/14356. Which is a bit weird because in the other project, it shows up also with 3.0.4

Perhaps related to #9381 or some other import meta PR @sapphi-red ?

What is the problem here? Because
"@font-face{font-family:Line Awesome Brands;font-style:normal;font-weight:400;font-display:auto;src:url("+new URL('la-brands-400.c0e32387.eot', import.meta.url).href+");"

is in JS, it will be evaluated as something like
"@font-face{font-family:Line Awesome Brands;font-style:normal;font-weight:400;font-display:auto;src:url(https://example.com/assets/la-brands-400.c0e32387.eot);"

which is a valid CSS.
This import.meta.url is used for relative base, so using base: './' will be a important for creating reproduction.

The problem is that it is not evaluated but the JS code remains in the final string

Just a detail, but previewHacks should already be a string here, no? There is no need for toString
injectGlobalCss(previewHacks.toString());

It would help a lot to be able to get a reproduction, I wonder if one of your plugins is getting in the way. If it isn't evaluated, it means that the CSS code didn't end up like:
" ... "+new URL().hred+" ... "

when you are importing previewHacks, that is quite strange

The code in the output JS is like
const Rl = O`@font-face{font-family:Line Awesome Brands;font-style:normal;font-weight:400;font-display:auto;src:url("+new URL("la-brands-400.c0e32387.eot",import.meta.url).href+");src:url("+new URL("la-brands-400.c0e32387.eot?#iefix",import.meta.url).href+") format("embedded-opentype"),url("+new URL("la-brands-400.ff70c9bc.woff2",import.meta.url).href+") format("woff2"),url("+new URL("la-brands-400.14c63377.woff",import.meta.url).href+") format("woff"),url("+new URL("la-brands-400.fbc98702.ttf",import.meta.url).href+") format("truetype"),url("+new URL("la-brands-400.4da18191.svg#lineawesome",import.meta.url).href+") format("svg")}

So as the CSS is wrapped inside
O`css`

breaking out using "+new URL will obviously not work
I suspect the wrapping is done by rollup-plugin-postcss-lit

Interesting, this looks like something that could be fixed in rollup-plugin-postcss-lit. It isn't safe to wrap code in this way. At one point, we had used
` ... ${new URL().href} ... `

For our wrapping, but that also may have issues depending on their (I assume) regex based replacing 🤔
If it is this plugin, you should be able to create a reproduction and maybe check if they are willing to patch their plugin.

Thinking about this some more, since we are replacing the URL in renderChunk, it is not really safe for Vite to assume that no other plugin has transformed it from "..." to a template string. So I think this issue falls on our side.
I see two options:

We could migrate to using` ... ${new URL().href} ... `

This should be safer in general, maybe we could do this change and release it in 3.1 to avoid disruption (prob. out in two weeks, but you could start using a beta sooner)
We could add code to detect in what kind of string is the __VITE_ASSET__ being replaced directly in renderChunk.

Leaning towards 2. if we can find a good implementation.

Here is a reproduction case https://github.com/Artur-/vite-vaadin-problem7

If it's using tagged template literal (css`a` ) and not a normal template literal (css(`a`) ), are we able to preserve the meaning? (I'm not sure if this is the case though.)
function t(...args){console.log(args)}

t`aa` // [['aa']]
t`a${'url'}a` // [['a', 'a'], 'url']
t(`a${'url'}a`) // ['aurla']

For example, if rollup-plugin-postcss-lit is transforming (a) to (b), transforming (b) to (c) might break it.
// (a)
export default ".foo { background: url('./foo') }"
// (b)
export default css`.foo { background: url('./foo') }`
// (c)
export default css`.foo { background: url('${new URL('./foo', import.meta.url).href}') }`

Tried rollup-plugin-lit-css and it has the same problem when using the following config in the project linked above:
import litcss from 'rollup-plugin-lit-css';

export default {
  base: './',
  plugins: [
    {
      ...litcss({include: '**/*.css*'}),
      enforce: 'post'
    }
  ],
}

That plugin use string-to-template-literal instead of RegEx based replacing.

Compared the code produced by two plugins I tested, and both have src:url(__VITE_ASSET__b7ef2cd1__) in the output.
The only real difference in the output is format("woff") vs format(\\"woff\\"); which seems irrelevant.
rollup-plugin-postcss-lit
@font-face{font-family:Roboto;font-style:normal;font-display:swap;font-weight:400;src:url(__VITE_ASSET__b7ef2cd1__) format("woff2"),url(__VITE_ASSET__e41533d5__) format("woff")}

Full output
import {css as cssTag} from 'lit';
export default cssTag`@font-face{font-family:Roboto;font-style:normal;font-display:swap;font-weight:400;src:url(__VITE_ASSET__b7ef2cd1__) format("woff2"),url(__VITE_ASSET__e41533d5__) format("woff");unicode-range:U+0460-052F,U+1C80-1C88,U+20B4,U+2DE0-2DFF,U+A640-A69F,U+FE2E-FE2F}@font-face{font-family:Roboto;font-style:normal;font-display:swap;font-weight:400;src:url(__VITE_ASSET__495d38d4__) format("woff2"),url(__VITE_ASSET__e41533d5__) format("woff");unicode-range:U+0301,U+0400-045F,U+0490-0491,U+04B0-04B1,U+2116}@font-face{font-family:Roboto;font-style:normal;font-display:swap;font-weight:400;src:url(data:font/woff2;base64,d09GMgABAAAAAAXMABIAAAAACeAAAAVwAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGiYbIBw2BmAANAhUCYM8EQwKg2iDSgsQABIUATYCJAMcBCAFgnQHIAyCSRt8CAieB2WbnmbLuYAwwpK8+iIe4P3r89wHDZaakNWCmB8R66SEWr+ILhpijnTqf6QAyyF8GVAOAPOWtmNg6llFXANTaQXCgXMubThOj6JRPCJsEWW3o1/4wX411uruvta/9FF8Zz50qenu3hVxmf4QIi1dRSzhkcR0SqA1QoiwzI2uAUbffgtBpA0YCssEQRChiaaAgMpAFvDsmKQshIEEer1l/u1J0Sbi8P6OJsQc3VHd6N0nlHe1MAhFbvPNcXJVWKNNekPqCYVx/lj8nqMi5BY4Pd6hectSY5E2Lll8SMf/HJXfEKEOfCtEMjEFBEHtpSkbjBK4aB1MIEjT/t9z/+W3j8FgVyeNWdDn7wh7b19l7pQoyFW8FXcx+P9D4NE2ErMMk4kskmVMCiwyG5ZhhyC7qZ19JoMatwj00/I0GG/uexT/v7K+Ysx9JXVwiRoC1yHR9VGAy9QQcXVQbqOGmOvEACWZm5EnyicLnfULjlggc0ldeRXQEqImnlS9kL8XAZndegKyuixM77OP24/Mzw9QQ7Kfha4v9OEOadjJ0qBYxN896pRbZI6ly/PS82Bs9iiYPpuaWJZEw83lXbg5G5JRslr2VFWPDtfbPBryeqZk5eKg/CqRD2Oz8tcvgJMiFi4RC6PWb9fnkzx74cWAeELYJFCSObI1tnxBfqwo2lPppazn26eGKDWU3KLMvOioppPNX6y4euc5FBq4y6Emd99OYa6zfpnpUhjE4Y/qoWtWQ4tIHr845ZA6bDc+AOSaR/sb6c9Otrh6uj3cUdDVKESNWgCK/GzxKQiLFKJeTz+QgzZKTIUcA2Nz9h2ppBhtbSQxfsjAtk4xoD1oes5gXYPe8UWmx+HjwQeNPfi2Wv/952vDpV/80Njw3WfWXv5IL3662ucz8dd9se78QkPd6ihDH61ZfS/s/KK0fjE+sgih+YDL5pz1vnH249tjfOAcLqZOTdvY/3jL1Hy3vqvcu358ODj2/etmVHfcdW+1t2X6R08H6p3BTzz87uDo6/H/vD/2scffaEf/ThphsXX6jLtDvp7cx6bvFUbnpWbFBWgOekJEip6LgFz63wtE+H/fXrpM++P7m8wAgZk/NJnacWXJLOW1rWO16C5ouY7SRE5T8x0iJ7MpntZyQJtPS2tuKXZpKqNf728OLK1FiJj72rq99z4Ho7G9hTQm0sqlhiEBKlWXfTDq1zbQcaP1HosN1zo/TqWGAGGywdQJhaSfHo9wDdfhs78cJKBZ5glRluQQEG030P7t9IdL+03+rRhRIHjxxwF7IsRHYeWXv0f991G5d9GJAKUIBPIT/jUpF/wa9f/Ccm9YiMnjjap8MPxDeomeuKM1ffn/fWHktrCSBT3iY20i0fZ0BBSOAgtJiYMAUDBoOigYaTtuMB4PJjiY2lFfMDPaqZe2rfYTKVcYVUK+QIPiwY175iFi5Yq4Em50vIyNq4cbYFLL2Fyqwbe4aq5Kx+XgZMhZco180ZCv3b5iqtyXD9VCUsquRpcNT74CH3LW95hzWKkvV3KxoHLNhF5fxylXMNkCLk6rio/XJGRzZWquGi/JysTM3sUM+4wfckMBveM4zKV1U1VT4QMTqQI/IFSPuDBgopvEnkF6u7kQ4gJdWIvWjkeivDg/OWNxRqSXxIolJclBKluW+uwutDVlWXtxjIc9y9fPPiBAxIqR2jR/O1ZmRftILVjVU5bo4zjbmDxi6XLWfHj/+sMns5ZFfyP9jLWD9pU5CFi/MC+Fo8Vo/+XhjzuFH9jQ3a32p2/nQ0fiTr60oFFwFV18KrXSKp2m/+AsuvlQKqXRIVOncITG9B6cRRdfSqt0RP8hVHTzrZOuHdwJDHdwJwA=) format("woff2"),url(__VITE_ASSET__e41533d5__) format("woff");unicode-range:U+1F00-1FFF}@font-face{font-family:Roboto;font-style:normal;font-display:swap;font-weight:400;src:url(__VITE_ASSET__daf51ab5__) format("woff2"),url(__VITE_ASSET__e41533d5__) format("woff");unicode-range:U+0370-03FF}@font-face{font-family:Roboto;font-style:normal;font-display:swap;font-weight:400;src:url(__VITE_ASSET__77b24796__) format("woff2"),url(__VITE_ASSET__e41533d5__) format("woff");unicode-range:U+0102-0103,U+0110-0111,U+0128-0129,U+0168-0169,U+01A0-01A1,U+01AF-01B0,U+1EA0-1EF9,U+20AB}@font-face{font-family:Roboto;font-style:normal;font-display:swap;font-weight:400;src:url(__VITE_ASSET__3c23eb02__) format("woff2"),url(__VITE_ASSET__e41533d5__) format("woff");unicode-range:U+0100-024F,U+0259,U+1E00-1EFF,U+2020,U+20A0-20AB,U+20AD-20CF,U+2113,U+2C60-2C7F,U+A720-A7FF}@font-face{font-family:Roboto;font-style:normal;font-display:swap;font-weight:400;src:url(__VITE_ASSET__f6734f81__) format("woff2"),url(__VITE_ASSET__e41533d5__) format("woff");unicode-range:U+0000-00FF,U+0131,U+0152-0153,U+02BB-02BC,U+02C6,U+02DA,U+02DC,U+2000-206F,U+2074,U+20AC,U+2122,U+2191,U+2193,U+2212,U+2215,U+FEFF,U+FFFD}

rollup-plugin-lit-css
@font-face{font-family:Roboto;font-style:normal;font-display:swap;font-weight:400;src:url(__VITE_ASSET__b7ef2cd1__) format(\\"woff2\\"),url(__VITE_ASSET__e41533d5__) format(\\"woff\\");}

Full output
import {css} from 'lit';
export const styles = css`export default "@font-face{font-family:Roboto;font-style:normal;font-display:swap;font-weight:400;src:url(__VITE_ASSET__b7ef2cd1__) format(\\"woff2\\"),url(__VITE_ASSET__e41533d5__) format(\\"woff\\");unicode-range:U+0460-052F,U+1C80-1C88,U+20B4,U+2DE0-2DFF,U+A640-A69F,U+FE2E-FE2F}@font-face{font-family:Roboto;font-style:normal;font-display:swap;font-weight:400;src:url(__VITE_ASSET__495d38d4__) format(\\"woff2\\"),url(__VITE_ASSET__e41533d5__) format(\\"woff\\");unicode-range:U+0301,U+0400-045F,U+0490-0491,U+04B0-04B1,U+2116}@font-face{font-family:Roboto;font-style:normal;font-display:swap;font-weight:400;src:url(data:font/woff2;base64,d09GMgABAAAAAAXMABIAAAAACeAAAAVwAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGiYbIBw2BmAANAhUCYM8EQwKg2iDSgsQABIUATYCJAMcBCAFgnQHIAyCSRt8CAieB2WbnmbLuYAwwpK8+iIe4P3r89wHDZaakNWCmB8R66SEWr+ILhpijnTqf6QAyyF8GVAOAPOWtmNg6llFXANTaQXCgXMubThOj6JRPCJsEWW3o1/4wX411uruvta/9FF8Zz50qenu3hVxmf4QIi1dRSzhkcR0SqA1QoiwzI2uAUbffgtBpA0YCssEQRChiaaAgMpAFvDsmKQshIEEer1l/u1J0Sbi8P6OJsQc3VHd6N0nlHe1MAhFbvPNcXJVWKNNekPqCYVx/lj8nqMi5BY4Pd6hectSY5E2Lll8SMf/HJXfEKEOfCtEMjEFBEHtpSkbjBK4aB1MIEjT/t9z/+W3j8FgVyeNWdDn7wh7b19l7pQoyFW8FXcx+P9D4NE2ErMMk4kskmVMCiwyG5ZhhyC7qZ19JoMatwj00/I0GG/uexT/v7K+Ysx9JXVwiRoC1yHR9VGAy9QQcXVQbqOGmOvEACWZm5EnyicLnfULjlggc0ldeRXQEqImnlS9kL8XAZndegKyuixM77OP24/Mzw9QQ7Kfha4v9OEOadjJ0qBYxN896pRbZI6ly/PS82Bs9iiYPpuaWJZEw83lXbg5G5JRslr2VFWPDtfbPBryeqZk5eKg/CqRD2Oz8tcvgJMiFi4RC6PWb9fnkzx74cWAeELYJFCSObI1tnxBfqwo2lPppazn26eGKDWU3KLMvOioppPNX6y4euc5FBq4y6Emd99OYa6zfpnpUhjE4Y/qoWtWQ4tIHr845ZA6bDc+AOSaR/sb6c9Otrh6uj3cUdDVKESNWgCK/GzxKQiLFKJeTz+QgzZKTIUcA2Nz9h2ppBhtbSQxfsjAtk4xoD1oes5gXYPe8UWmx+HjwQeNPfi2Wv/952vDpV/80Njw3WfWXv5IL3662ucz8dd9se78QkPd6ihDH61ZfS/s/KK0fjE+sgih+YDL5pz1vnH249tjfOAcLqZOTdvY/3jL1Hy3vqvcu358ODj2/etmVHfcdW+1t2X6R08H6p3BTzz87uDo6/H/vD/2scffaEf/ThphsXX6jLtDvp7cx6bvFUbnpWbFBWgOekJEip6LgFz63wtE+H/fXrpM++P7m8wAgZk/NJnacWXJLOW1rWO16C5ouY7SRE5T8x0iJ7MpntZyQJtPS2tuKXZpKqNf728OLK1FiJj72rq99z4Ho7G9hTQm0sqlhiEBKlWXfTDq1zbQcaP1HosN1zo/TqWGAGGywdQJhaSfHo9wDdfhs78cJKBZ5glRluQQEG030P7t9IdL+03+rRhRIHjxxwF7IsRHYeWXv0f991G5d9GJAKUIBPIT/jUpF/wa9f/Ccm9YiMnjjap8MPxDeomeuKM1ffn/fWHktrCSBT3iY20i0fZ0BBSOAgtJiYMAUDBoOigYaTtuMB4PJjiY2lFfMDPaqZe2rfYTKVcYVUK+QIPiwY175iFi5Yq4Em50vIyNq4cbYFLL2Fyqwbe4aq5Kx+XgZMhZco180ZCv3b5iqtyXD9VCUsquRpcNT74CH3LW95hzWKkvV3KxoHLNhF5fxylXMNkCLk6rio/XJGRzZWquGi/JysTM3sUM+4wfckMBveM4zKV1U1VT4QMTqQI/IFSPuDBgopvEnkF6u7kQ4gJdWIvWjkeivDg/OWNxRqSXxIolJclBKluW+uwutDVlWXtxjIc9y9fPPiBAxIqR2jR/O1ZmRftILVjVU5bo4zjbmDxi6XLWfHj/+sMns5ZFfyP9jLWD9pU5CFi/MC+Fo8Vo/+XhjzuFH9jQ3a32p2/nQ0fiTr60oFFwFV18KrXSKp2m/+AsuvlQKqXRIVOncITG9B6cRRdfSqt0RP8hVHTzrZOuHdwJDHdwJwA=) format(\\"woff2\\"),url(__VITE_ASSET__e41533d5__) format(\\"woff\\");unicode-range:U+1F00-1FFF}@font-face{font-family:Roboto;font-style:normal;font-display:swap;font-weight:400;src:url(__VITE_ASSET__daf51ab5__) format(\\"woff2\\"),url(__VITE_ASSET__e41533d5__) format(\\"woff\\");unicode-range:U+0370-03FF}@font-face{font-family:Roboto;font-style:normal;font-display:swap;font-weight:400;src:url(__VITE_ASSET__77b24796__) format(\\"woff2\\"),url(__VITE_ASSET__e41533d5__) format(\\"woff\\");unicode-range:U+0102-0103,U+0110-0111,U+0128-0129,U+0168-0169,U+01A0-01A1,U+01AF-01B0,U+1EA0-1EF9,U+20AB}@font-face{font-family:Roboto;font-style:normal;font-display:swap;font-weight:400;src:url(__VITE_ASSET__3c23eb02__) format(\\"woff2\\"),url(__VITE_ASSET__e41533d5__) format(\\"woff\\");unicode-range:U+0100-024F,U+0259,U+1E00-1EFF,U+2020,U+20A0-20AB,U+20AD-20CF,U+2113,U+2C60-2C7F,U+A720-A7FF}@font-face{font-family:Roboto;font-style:normal;font-display:swap;font-weight:400;src:url(__VITE_ASSET__f6734f81__) format(\\"woff2\\"),url(__VITE_ASSET__e41533d5__) format(\\"woff\\");unicode-range:U+0000-00FF,U+0131,U+0152-0153,U+02BB-02BC,U+02C6,U+02DA,U+02DC,U+2000-206F,U+2074,U+20AC,U+2122,U+2191,U+2193,U+2212,U+2215,U+FEFF,U+FFFD}\\n"`;
export default styles;

It should be possible to workaround this by making the URL wrapped as Vite expects it so instead of rewriting in the plugin from
@font-face{src:url(__VITE_ASSET__c0e32387__)}

to
cssTag`@font-face{src:url(__VITE_ASSET__c0e32387__)}`

it would rewrite to
cssTag`@font-face{src:url(${unsafeCSSTag("__VITE_ASSET__c0e32387__")})

Then __VITE_ASSET__ is quoted with " like Vite expects..

Do you have a reference for src:url @Artur-?
@sapphi-red do you have an example where it will break? I know that the named template string could potentially do anything, but I assume that if they see a URL interpolated they must respect it. Maybe they will be adding custom logic to be able to update it later? But I think the resulting CSS should be well-formed.

For the record, this resolves the issue for us https://github.com/umbopepato/rollup-plugin-postcss-lit/pull/54/files

For the record, this resolves the issue for us umbopepato/rollup-plugin-postcss-lit#54 (files)

Oh, interesting. Great that they were so responsive. They will also need to guard against __VITE_PUBLIC_ASSET__. I still think that we should be guarding against this in Vite core, so let's keep discussing in this issue.

Well... I created that PR :)

I think this one will break if we inject new URL(foo) without wrapping with unsafeCSS. (stackblitz)

If you must use an expression in a css literal that is not itself a css literal, and you are confident that the expression is from a fully trusted source such as a constant defined in your own code, then you can wrap the expression with the unsafeCSS function:
lit docs

unsafeCSS is not at all a great solution, far from it but it allows us to move forward before this is fixed properly

Is this fixed, or still an issue ?

This issue reappears when trying to upgrade from Vite 5 beta 9 to beta 10. Not sure what has changed

In the test logs (https://github.com/vaadin/flow/actions/runs/6627641560/job/18003126076) there are requests for files like
Error message in browser log: [2023-10-24T13:47:41.126Z] [SEVERE] http://localhost:8888/+new%20URL('fa-solid-900-9yKDp_qD.woff2',%20import.meta.url).href+ - Failed to load resource: the server responded with a status of 404 (Not Found)

@Artur- beta10 upgrades rollup to v4. rollup v4 uses some additional characters for the reference id. I guess you need to change this line like I did here.
https://github.com/vaadin/flow/blob/66cec6601f458f514e42cbe4f9ea279f58469db7/flow-server/src/main/resources/plugins/rollup-plugin-postcss-lit-custom/rollup-plugin-postcss-lit.js#L31
https://github.com/vitejs/vite/pull/14508/files#diff-91776e7c6039d23a070162f02a69cd46046a2095bd5ecb384ae9e27f2ea5288fL30-R31

Thanks! That did it and we are 🍏 📗 🟢 💚 with Vite 5 beta 10

Is there any fix for that problem? Local all work as I need. When I deploy and build i got a 404 error.
downloadable font: download failed (font-family: "Font Awesome 6 Free" style:normal weight:900 stretch:100 src index:0): status=2147746065 source: https://DOMAIN.COM/dist/webfonts/fa-solid-900.woff2
package.json
{
  "name": "kirby-vite",
  "main": "src/index.js",
  "type": "module",
  "scripts": {
    "vite": "vite",
    "dev": "concurrently \"npm:server\" \"npm:vite\"",
    "server": "php -S localhost:8888 -t public server.php",
    "build": "vite build",
    "preview": "npm run build && npm run server"
  },
  "author": "arnoson",
  "license": "MIT",
  "devDependencies": {
    "concurrently": "^8.2.2",
    "glob": "^10.3.10",
    "vite": "^5.1.5",
    "vite-plugin-kirby": "^5.3.0"
  },
  "dependencies": {
    "@fortawesome/fontawesome-free": "^6.5.1",
    "mburger-webcomponent": "^3.1.4",
    "mmenu-js": "^9.3.0",
    "sass": "^1.71.1",
    "uikit": "^3.19.1"
  }
}

index.scss
// Theme
@import "theme/variables-theme.scss";

@import "uikit/src/scss/variables-theme.scss";
@import "uikit/src/scss/mixins-theme.scss";

@import<EMAIL_ADDRESS>@import<EMAIL_ADDRESS>@import<EMAIL_ADDRESS>@import<EMAIL_ADDRESS>
@import "theme/_import.scss";
@import "mmenu-js/src/mmenu.scss";

vite.config.php
<?php
// This is an auto-generated file. Please avoid making changes here.
// Configure your settings in the "vite.config.js" file instead.
return [
  'rootDir' => 'src',
  'outDir' => 'public/dist',
  'assetsDir' => 'assets',
  'legacy' => false
];


[2024.12] Unable to provision VDIs as a Cognito users when environment is not setup with AD

Bug description
With the 2024.12 release, AD parameters are optional during deploy time. Customers can deploy RES with no AD attached. Customers can also login and launch VDI as Cognito users.
After deploying an environment without providing the optional AD parameters, Cognito users are not able to create a new VDI in the RES web portal. They are presented with a 'None' has no attribute 'upper' error. This error is not seen for deployments where Cognito and AD are both configured for RES.
Affected versions
2024.12
Mitigation
We're currently working on a fix. To workaround this issue, you can either provide AD parameters when installing RES, or provide the AD configuration in the RES web portal after installation. This will allow you to launch VDI as Cognito users.

Issue has been resolved with 2024.12.01 release.
https://github.com/aws/res/releases/tag/2024.12.01


Mk card toolbar & card settings extensible

Describe what your pull request addresses

[ ] Make the toolbar of the Card component and the SettingsCard component extensible.

Now both components have an onRender... prop which is a callback function that would allow the RCL consumer to hook into the rendering of the wrapped elements
Test Instructions

[ ] Create a Component that renders a Card component
[ ] Add the onRenderToolbar prop to the Card
[ ] Create an onRenderToolbar function with {items} as the argument
[ ] Make the onRenderToolbar return modified items i.e ({items}) => [...items, "example"]
[ ] Add onRenderToolbar function to the onRenderToolbar prop of Card
[ ] Do the same with onRenderSettings.

Resulting code:
const Component = () => {
  const onRenderToolbar = ({items}) => [...items,"example"]
  const onRenderSettings = ({items}) => [...items,"example"]

  return (
    <Card
      onRenderToolbar={onRenderToolbar}
      onRenderSettings={onRenderSettings}
    >
    </Card>
  )
}

Returning jsx instead of array:
const Component = () => {
  const onRenderToolbar = ({items}) => <>{items}{"example"}</>
  const onRenderSettings = ({items}) => <>{items}{"example"}</>

  return (
    <Card
      onRenderToolbar={onRenderToolbar}
      onRenderSettings={onRenderSettings}
    >
    </Card>
  )
}

LGTM


Server running with Black border even with same aspect ration of the monitor

[x] I have read the FAQ.
[x] I have searched in existing issues.

Environment

OS: Windows 10
scrcpy version: 1.18
installation method: just use the .exe in the zip file (sorry, I don't know how to name this)
device model: Xiaomi Redmi Note 5
Android version: 9

Describe the bug
My device has a 18:9 screen while my monitor is 16:10. So, when I get to really use my cellphone, I run adb
adb shell wm size 1350x2160 with some resolutions, but always 16:10
adb shell wm density 220 when I need it to work better with my monitor size
The problem is that at most resolutions, the server always cuts about 2-3 pixels from the top and the bottom. When I try to add these 4p in the height, then the black border appears on the sides...
It is really a problem for me because my phone has some gestures:

pull op from the very bottom: go to home
pull from the very side: go back
pull from the very side and mantain: switch apps

With the borders, I can't use them. Even though my android is running at true 16:10 (ex. 2160x1350), the server does the following:
INFO: scrcpy 1.18 https://github.com/Genymobile/scrcpy
C:\Users\vfran\OneDrive\Documentos\Android Tools\scrcpy-wi... file pushed, 0 skipped. 28.2 MB/s (37330 bytes in 0.001s)
[server] INFO: Device: Xiaomi Redmi Note 5 (Android 9)
INFO: Renderer: direct3d
INFO: Initial texture: 1344x2160
I tried to crop (or downscale, don't really know how it is called) the client, like scrcpy  --max-size 1800 or any other, like 1440 (my monitor height), but didn't work. I also tried to run with OpenGl, but same thing.
What could I do? thanks for the attention

I don't really know why it didn't show the mouse above the border, but the border is there
(It is not showing just half of the screen, just my phone launcher that doesn't really support this forced landscape mode)

The problem is that at most resolutions, the server always cuts about 2-3 pixels from the top and the bottom

Scrcpy always rounds the size to a multiple of 8, because it's required by most video encoders.
But it slightly stretches or shrinks the content, it should not add padding or crop.
This is obvious by rounding to a multiple of 512 instead:
diff --git a/server/src/main/java/com/genymobile/scrcpy/ScreenInfo.java b/server/src/main/java/com/genymobile/scrcpy/ScreenInfo.java
index c27322ef..0d2e9cc8 100644
--- a/server/src/main/java/com/genymobile/scrcpy/ScreenInfo.java
+++ b/server/src/main/java/com/genymobile/scrcpy/ScreenInfo.java
@@ -116,8 +116,8 @@ public final class ScreenInfo {
         // - scale down the great side of the screen to maxSize (if necessary);
         // - scale down the other side so that the aspect ratio is preserved;
         // - round this value to the nearest multiple of 8 (H.264 only accepts multiples of 8)
-        w &= ~7; // in case it's not a multiple of 8
-        h &= ~7;
+        w &= ~511; // in case it's not a multiple of 512
+        h &= ~511;
         if (maxSize > 0) {
             if (BuildConfig.DEBUG && maxSize % 8 != 0) {
                 throw new AssertionError("Max size must be a multiple of 8");

adb shell wm size 1350x2160 with some resolutions, but always 16:10

Try 1200x1920 (both dimensions are multiple of 8).

Thank you! That makes sense, now it is working great on 8x based numbers.

Hello, I was reading and from what I understood, the screen of your smartphone is 18:9 but you could adapt it to your 16:9 monitor using a command, could you explain to me how this works? I have a 21:9 smartphone and I also want to adapt it to my 16:9 screen

@Leuhan76 You can change the size of your device:
adb shell wm size …
adb shell wm density …

https://stackoverflow.com/questions/18500611/android-how-to-use-adb-shell-wm-to-simulate-other-devices
If you don't want to change your device size but want to make an image fit into a rectangle having a different aspect ratio, theoretically, you have only 2 solutions: stretch the image and/or crop.
Scrcpy does not support stretching the image (it always preserves aspect ratio), so you can only crop.

Ok, I can change the size of my device, the screen of my smartphone is 720x1600 and the one of my monitor is 1366x768, what resolution should I put? Sorry but I hardly understand this and thanks for answering so quickly

Ok, I can change the size of my device, the screen of my smartphone is 720x1600 and the one of my monitor is 1366x768, what resolution should I put?

Try 1366x768, so they'll have exactly the same resolution.

ok i will try this adb shell wm size 1366x768

I already tried it, if the resolution changes, but the window on the monitor continues to be seen with the same black borders and does not fit the entire screen


Support for Bucket.location setter

I was trying to change location of the bucket in Storage, but everything gets updated apart from location. It looks like the data is being sent through API, but are not persisted?
Code example
storage_client = StorageClient()
bucket = storage_client.create_bucket(name)
bucket.storage_class = 'MULTI_REGIONAL'
bucket.location = 'EU' # tried 'eu' as well
bucket.labels = {
     'project': 'etl-transformer',
     'group': 'etl',
}
bucket.patch()

# update_properties printed in _PropertyMixin:patch
{
    'labels': {
        'project': 'etl-transformer',
        'group': 'etl'
    },
    'storageClass': 'MULTI_REGIONAL',
    'location': 'EU'
}

# I checked here even dump in requests package to be sure it's being passed to the http object

# api_reponse
{
    u 'labels': {
      u 'project': u 'etl-transformer',
      u 'group': u 'etl'
    },
    u 'location': u 'US',
    u 'storageClass': u 'MULTI_REGIONAL'
}

I know that documentation doesn't say that location attribute is a setter, but under the hood it's a _scalar_property which is appended to changed properties and according to json API, location is writable:
https://cloud.google.com/storage/docs/json_api/v1/buckets

Hi @gastlich,
Could you try the following instead:
# Imports the Google Cloud client library
from google.cloud import storage

# Instantiates a client
storage_client = storage.Client()

# The name for the new bucket
bucket_name = 'bucket-name'

# Create a new bucket object
bucket_object = storage.bucket.Bucket(storage_client, bucket_name)

# Set location
bucket_object.location = "EU"

# Set storage class
bucket_object.storage_class = "MULTI_REGIONAL"

# Create bucket
bucket_object.create()

Hi @frankyn ,
it worked, I thought there is only create_bucket way to create buckets, didn't realise, that there might be just .bucket() constructor...
but still, do you know the reason, why it hasn't been updated in my first example?
Cheers

@gastlich,
The issue is each call does something a bit different. storage_client.bucket creates a bucket object on the client. storage_client.create_bucket creates the bucket on the platform. When you changed your code to use bucket() you changed it to not actually create anything until you had set the location to EU.
In the original you had created a bucket in US and then tried to change its location to EU. Once created, you cannot change the location of a bucket.

Two code changes are required to address this issue:

Plumb the location argument through to Client.create_bucket.
Make the Bucket.location property read-only.

Hmmm, making Bucket.location read-only in all cases would be backward-incompatible:  applications which set the location between instantiating the bucket and calling its create method would break.

That could be done, but the comment for create_bucket already states that for more complex creation you should use the other flow. My guess would be this is because if we add location, really we need to start adding all of the possible configuration options to create_bucket to support all uses. But we already have an alternative for that.
The doc comment I am referring to btw:
    To set additional properties when creating a bucket such as
    :attr:`~.Bucket.location`, use :meth:`~.Bucket.create`.

@crwilcox OK.  Maybe the setter for the location property should still raise an error if there is already a value set?

That seems like a reasonable idea. Really that entire class is almost entirely read-only once written fields from what I could tell. That fix would help to prevent this in the future.

Really that entire class is almost entirely read-only once written fields from what I could tell.

That may have been a strong statement. The more accurate statement I should have made is that in fixing this we should be sure we do the same protection of all write-once settings.

Bucket.location is the only property set using the _scalar_property helper, which gives it a non-validating setter.
The following properties are already read-only (no setter defined):

path
client
user_project
acl (but the ACL itself is mutable).
default_object_acl (likewise)
etag
id
metageneration
owner
project_number
self_link
time_created

The following bucket properties have explicit setters:

cors
labels
lifecycle_rules
storage_class
versioning_enabled
requester_pays

The logging and website resource keys are supported through non-property mutators.

Closed via #5808.


Added gitee OAuth Provider

Happy New Year!
This PR implements OAuth provider for Gitee, a Chinese code hosting platform similar to Github. It is fairly popular among Chinese developers and companies. This would allow me to use Pocketbase in my applications targeting a more regional audience.
Their authentication flow is fairly similar to Github's. However, their documentation seems to be only in Chinese. So if you need any help testing this I would be happy to help.

Thank you for working on this.
I've tested it locally and it works fine with one minor detail - when the user checks the "Keep my email address private" checkbox from the Gitee Emails management the email field is not an empty string but the text "未公开邮箱" (google translate: "undisclosed email") and this prevents making the additional emails request (and eventually fail the validation for new OAuth2 users).
I suggest:

Remove the Email field from the extracted struct.
Always make a request for https://gitee.com/api/v5/emails, bit in case of a failure, don't return an error and silently ignore it (if possible check for scope error) and just return the user as it is. This is because Gitee allows the user to uncheck the "all emails" checkbox when faced with the Auth screen. This is OK with PocketBase because we no longer require the email and the OAuth2 email is used primarily for existing accounts linking (and when the auth collection has the "Always require email" toggle, but that will trigger the validations anyway). I'll apply a similar change to the GitHub provider sometime later.

Alternatively (and probably easier) would be to just remove the extra email call (if the user prefer their email to be private then let it be).
Or in other words, keep the Email field in the extracted struct but also add a validation for it in case it is not an empty string:
user := &AuthUser{
	Id:          strconv.Itoa(extracted.Id),
	Name:        extracted.Name,
	Username:    extracted.Login,
	AvatarUrl:   extracted.AvatarUrl,
	RawUser:     rawUser,
	AccessToken: token.AccessToken,
}

if extracted.Email != "" && is.EmailFormat.Validate(extracted.Email) == nil {
	user.Email = extracted.Email
}

3rd option would be to combine the above 2 suggestions, aka. make the extra api call request if the extracted email is invalid (the request must be optional, aka. ignore the response error and directly return the user without an email).

Hi, I have pushed a fix. I have chosen the 3rd option you proposed with validation and an optional request step from the emails api. All errors in the optional request step are ignored.

All errors in the optional request step are ignored.

Only the optional request error should be ignored. I'm working on it locally since I'm updating also the GitHub provider.

Ok, I can sync your update to the Github provider to the Gitee provider once you have finished. But I think it is reasonable to ignore the subsequent io and JSON parsing error following the optional request. An other option is to validate the status code?

Ok, I see that you already added the status code validation.

I have pushed a new change to conform with the way the Github provider handles this.

@yuxiang-gao Please be patient, I'm currently working on it. Gitee is not the same as GitHub. It seems to return 401 in case the "Access your email data" was not checked.
Additionally, when "Keep my email address private" is set, the optional call seems that will always fail the json parsing because the returned email and response code is something like:
<EMAIL_ADDRESS>200

Which is not what we want. I'm trying to figure out all edge cases and will push and update once I test it properly.

I've merged it locally in master - https://github.com/pocketbase/pocketbase/commit/c673d9d314e1b5556e7c24392aef5c400e382694
It seems that Gitee users have 3 options (some of which can be combined):
A. "Access your emails data" (Auth screen's checkbox)
B. "Public email address" (select in the account "Emails management" page)
C. "Keep my email address private" (checkbox in the account "Emails management" page; overwrites 2)
The email is returned in the main response only if 2) is set.
The second optional request works only if  "Keep my email address private" is not set.


Add support for typescript in multiplatform project

Right now there is support only for Lumin. This enhancement will allow developer to create multiplatform project that has typescript support

Resolved with https://github.com/magic-script/magic-script-cli/pull/132


Full debugger support

I think we need a way to get access to main debugger features for a given program. I know the ghci debbuger but it would be nice if it could be run by a public API
An API wich provides:

[ ] set a breakpoint (classic and conditional)
[ ] step by step
[ ] step into function
[ ] step outside function
[ ] watch a binding
[ ] force evaluation
[ ] current call stack visualization and exploration

You can have a good overview of IDE needs by looking at the VSCode debuging protocol:
https://github.com/Microsoft/vscode-debugadapter-node/blob/master/protocol/src/debugProtocol.ts
With more general explanation here:
https://code.visualstudio.com/docs/extensionAPI/api-debugging

ide-backend's debugger support never got very sophisticated, but it may be helpful to reference https://github.com/fpco/ide-backend/blob/master/ide-backend-server/Run.hs#L413

I've actually been looking at the vscode/omnisharp protocol again, with a view to building a HIE transport for it. Which brings in all the omnisharp-capable IDEs at one fell swoop.

Phoityne meets most of above requirements  ?
https://hackage.haskell.org/package/phoityne-vscode
https://marketplace.visualstudio.com/items?itemName=phoityne.phoityne-vscode

Some information from LSP4E (Eclipse LSP Client project): https://github.com/eclipse/lsp4j/issues/130

The Phoityne debugger uses this at the back https://hackage.haskell.org/package/haskell-dap which implements the vscode debug protocal, as I understand it.
Using a standard protocol makes sense to me, but it is not as widely implemented as LSP.  See https://code.visualstudio.com/docs/extensionAPI/api-debugging
And there is a ticket asking for LSP4J support, it is a complex ecosystem.

Any update on this?

more useful links:

Prior job, debug support for atom editor using ghci executable: https://github.com/atom-haskell/haskell-debug
Original paper: https://simonmar.github.io/bib/papers/ghci-debug.pdf
ghc reference about debugger: https://downloads.haskell.org/ghc/latest/docs/html/users_guide/ghci.html#the-ghci-debugger

The standard is now DAP, I would say, supported in both emacs and vscode.
And as I said earlier, phoityne already supports it, maybe we should consider an integration with it.
Fundamentally this is about having a GHCI session at the same time, which has been considered quite a bit.  See e.g https://gitlab.haskell.org/ghc/ghc/issues/15461


Merging master (SOCI 3.2.3) into develop

This is a 'walking' PR following #303 as attempt merge of the master with current SOCI 3.2.3 changes into develop.
All the conflicts have been resolved.
Further changes, if any, should be only related to fixing broken builds.

Would be nice to avoid reintroducing the trailing whitespace that I removed in develop.
Otherwise I looked over the changes and noticed just a raw & in an HTML file which should be <, all the rest looks good, thanks!

@vadz Thank you for the review. I've restored the trailing whitespace removal and corrected the &.
Assuming we're happy with this PR, I'll do git co develop && git merge develop-3.2.3. OK?

FYI, I used the old fashion command line way.


Support display clusterId from master ui

What changes are proposed in this pull request?
Display cluster Id in the master UI overview page, so that we can make sure the the cluster identify.

Why are the changes needed?
Display the cluster id.
Does this PR introduce any user facing changes?
Display the cluster id.

Codecov Report

Merging #13765 (07d98f6) into master (3f73cf9) will decrease coverage by 17.09%.
The diff coverage is 0.00%.

@@              Coverage Diff              @@
##             master   #13765       +/-   ##
=============================================
- Coverage     34.60%   17.50%   -17.10%
+ Complexity     6956     2660     -4296
=============================================
  Files          1384     1384
  Lines         80346    80351        +5
  Branches       9777     9777
=============================================
- Hits          27804    14069    -13735
- Misses        50145    65034    +14889
+ Partials       2397     1248     -1149

Impacted Files
Coverage Δ

...rc/main/java/alluxio/wire/MasterWebUIOverview.java
0.00% <0.00%> (ø)

...o/master/meta/AlluxioMasterRestServiceHandler.java
0.00% <0.00%> (ø)

...mon/src/main/java/alluxio/shell/CommandReturn.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...mon/src/main/java/alluxio/util/ExceptionUtils.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...n/src/main/java/alluxio/wire/AlluxioProxyInfo.java
0.00% <0.00%> (-100.00%)
:arrow_down:

.../src/main/java/alluxio/wire/AlluxioMasterInfo.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...src/main/java/alluxio/job/meta/JobIdGenerator.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...n/src/main/java/alluxio/stress/BaseParameters.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...src/main/java/alluxio/client/UnderStorageType.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...main/java/alluxio/underfs/options/ListOptions.java
0.00% <0.00%> (-100.00%)
:arrow_down:

... and 486 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 3f73cf9...07d98f6. Read the comment docs.

Hey @maobaolong Those JVM metrics are really useful, can you add some docs for the added JVM metrics or even giving more information for the existing jvm metrics so that other users can know how to use them! Appreciate your help
https://docs.alluxio.io/os/user/stable/en/reference/Metrics-List.html#jvm-attributes

@tieujason330  Can you take a look ? thanks

alluxio-bot, merge this please


Resolved all FutureWarnings of Pandas in Deepar Introduction Notebook

Issue #, if available:
#1218
Description of changes:
The Deepar Introduction Notebook emitted three Pandas Future Warnings:
FutureWarning: Creating a DatetimeIndex by passing range endpoints is deprecated. Use pandas.date_range instead.

twice, and:
FutureWarning: Addition/subtraction of integers and integer-arrays to Timestamp is deprecated, will be removed in a future version.  Instead of adding/subtracting `n`, use `n * self.freq`

Since we insist on the highest standards, I took the liberty to resolve them, by replacing pd.DatetimeIndex() with pd.date_range()
and also
use pd.Timedelta(1, unit=self.freq) to increment the Timestamp, instead of just adding 1. Note that I used the frequency to dynamically select the unit (instead of statically passing the hours=1 parameter), since in the top cells, the user defines freq as 'H', but if somebody changed that locally, then that change would not be reflected in the prediction code (which applies that increment).
I checked all the Notebook's cells after my changes, and everything worked as before (except from the warnings obviously), results were the same.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Hi,
I still got the error "TypeError: new() got an unexpected keyword argument 'start' " even after changed pd.DatetimeIndex() to pd.date_range():


Wood, leaves and fence don't burn

When put near a flame, none of the wood, leaf or fence blocks burn.

Versions?

Versions?

Version 2.0.3 on Minecraft 1.14.4 with Forge 28.1.0

Fixed in 2.0.4


can't match the color in jsx

export function Comp() {
  console.log('rgba(0, 0, 0, 0.3)');
  return (
    <div
      style={{
        background: 'rgba(0, 0, 0, 0.3)',
      }}
    >
      hello
    </div>
  );
}

settings:
"color-picker-universal.languages": [
    "javascript",
    "typescript",
    "javascriptreact",
    "typescriptreact"
]

version:
Color Picker Universal: 2.2.3
Version: 1.89.1 (Universal)
Commit: dc96b837cf6bb4af9cd736aa3af08cf8279f7685
Date: 2024-05-07T05:14:24.611Z
Electron: 28.2.8
ElectronBuildId: 27744544
Chromium: 120.0.6099.291
Node.js: 18.18.2
V8: 12.0.267.19-electron.0
OS: Darwin arm64 23.5.0

I can't reproduce on version 1.91.0, Node 20.9.0, Windows x64. Can you update and see if it still happens?

Seems fixed

What happens sometimes is that VSCode or the extension bugs, in those cases you can try restarting VSCode, or the extensions


Create Login Page

WHAT DOES THIS PR DO?

Run this project locally (cd to web directory and then run npm run dev)
Navigate to the login page by clicking Login on the homepage navbar
Upon loading, the following page should appear:

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (e5106fa) 97.96% compared to head (69f7af6) 100.00%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff             @@
##             main      #115      +/-   ##
===========================================
+ Coverage   97.96%   100.00%   +2.03%
===========================================
  Files          28         1      -27
  Lines         492         3     -489
  Branches        0         1       +1
===========================================
- Hits          482         3     -479
+ Misses         10         0      -10

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


adding react-bootstrap CDN

I was wondering where would I add local or CDN reference to React-Boostrap

Hey, thanks for the interest.
We want to direct all questions like this to StackOverflow
Hopefully, you will learn more about React and CSP there.


add example of accessing location from Widget

For example, it's not necessary to give pathParameters to a widget when defining BeamLocations, as in most examples currently.
Every widget can take what it needs for build via Beamer.of(context).currentLocation

put this in main example


Breaking changes moving from to 5.73.0 -> 5.77.0

Hi-
I upgraded to 5.77.0 from 5.73.0, and it seems to be breaking other libraries or at least modifying something that doesn't work with other libraries.  Not sure what changed in that release that would affect other libs.
This update breaks Apple Sign In using OAuth 2 using the AspNet.Security.OAuth.Apple nuget package.  For whatever reason it seems to be hijacking the http client when making a token request and Apple is returning "invalid_client".  It's easy to reproduce by using 5.77.0 and integrating apple authorization.

Strange, we don't have that as a dependency in the project.
We did upgrade Microsoft.AspNetCore.Mvc.Core because the dependant Microsoft.AspNetCore.Http package had a security vulnerability. This is only for the .NET Standard 2.0 build.
If you are using .NET 5 or 6, it now doesn't have the Microsoft.AspNetCore.Mvc.Core dependency anymore, and relies on a framework dependency instead.
This change was made for #70.
This dependency change may be what triggered your issue, but there is probably a better way to fix it and still use the patched Microsoft.AspNetCore.Http package.

Definitely not something I expected when the error started showing up on my applications.  I spent several hours in a process of elimination and didn’t even think it would break something so disconnected.  I’m using net6.0 and not really clear on what is going on.  Based on the error my guess is it’s changing http request header to be “application/json” for the content type and Apple is expecting form encoding.  I could be wrong…
From: Niels Swimberghe @.>
Date: Wednesday, August 3, 2022 at 11:55 AM
To: twilio-labs/twilio-aspnet @.>
Cc: Brett Winklesky @.>, Author @.>
Subject: Re: [twilio-labs/twilio-aspnet] Breaking changes moving from to 5.73.0 -> 5.77.0 (Issue #82)
Strange, we don't have that as a dependency in the project.
We did upgrade Microsoft.AspNetCore.Mvc.Core because the dependant Microsoft.AspNetCore.Http package had a security vulnerability. This is only for the .NET Standard 2.0 build.
If you are using .NET 5 or 6, it now doesn't have the Microsoft.AspNetCore.Mvc.Core dependency anymore, and relies on a framework dependency instead.
This change was made for #70https://github.com/twilio-labs/twilio-aspnet/issues/70.
This dependency change may be what triggered your issue, but there is probably a better way to fix it and still use the patched Microsoft.AspNetCore.Http package.
—
Reply to this email directly, view it on GitHubhttps://github.com/twilio-labs/twilio-aspnet/issues/82#issuecomment-1204292550, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALE7XFWH4EJ5FHTB75KZNETVXKW7XANCNFSM55PVFCEA.
You are receiving this because you authored the thread.Message ID: @.***>

@bwinklesky have you found a solution?
I do think the Twilio SDK which Twilio.AspNet depends on has also received some updates. The Twilio SDK has a dependency on System.IdentityModel.Tokens.Jwt which may influence your Apple Auth? I personally wouldn't know.

Closing this for now. We can reopen this if necessary.

I tested 6.0 and the issue is still present.  I'm going to need to stay on 5.73 until the issue is resolved in the Twilio SDK.

@bwinklesky are you able to reproduce the issue when not using Twilio.AspNet but still using Twilio?

I added Twilio 5.79.0 along with Twilio.AspNet.Core 5.73.0 and that creates the invalid_client error from Apple.  I will try other versions to see if there's a version that works.

The breaking change is in version 5.76.0.  I went back to Twilio 5.73 and worked my way up.

I'm wondering it's reproducible when you remove Twilio.AspNet.Core and add Twilio.

I removed Twilio.AspNet.Core and added Twilio 5.76.0.  The issue still exists.

So it must be caused by the Twilio transitive dependencies. I happen to find the following issue which was fixed a couple months ago: https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/1861
I hope there's some information in there that can help you get this fixed!

You should make the minimum version be 6.20.0 for System.IdentityModel.Tokens.Jwt.  I added that version and the issue is resoled.

Fantastic! I'm glad it fixed your issue.
Let me create an issue for the Twilio library so they can update that version.


Fix: Relax S1 regex to avoid false positive

Fixes #62

Is there a reason why there is no release?

Is there a reason why there is no release?

@kornoa, Thank you for your patience. The maintainer team has been busy with the AVD 4.0 release. @gmuloc and I will work on a new release promptly!

Excellent! I've already noticed the release of v1.1.0. Many thanks!


Do not default health endpoints

This is opposite of https://github.com/knative/func/issues/1281.
The defaulting means user cannot unset health endpoints in any way.
The endpoints should be set explicitly in templates.
If the endpoints are not explicitly set in func.yaml then knative service should not have health endpoint set.

/cc @lkingland

cc @mvinkler

If the endpoints are not explicitly set in func.yaml then knative service should not have health endpoint set.

@lance  What if user doesn't have endpoints, for instance when trying to migrate existing project to use func?
IMO user should have ability to not have endpoints.

Are you also saying that the frameworks, e.g. faas-js-runtime disable these endpoints if the value is not found in func.yaml?

Nope. The application still may have health endpoints, but knative serving would not be checking them if not set in func.yaml.

This has been discovered by @mvinkler . He tried to port some existing Quarkus code to use func but it did not work because of missing endpoints.

Defaulting:
+ Three fewer lines in func.yaml.
- There is absolutely no way to disable health probes should user want it.
No Defaulting:
+ User can disable health probes should they need it.
- There are there more lines in func.yaml.

Thanks Matej for filing this issue.
Reasoning is the following:
If user decides to use his existing Quarkus app and includes func.yaml in the project (with default values), health checks will be the point of failure for the app deployment. When the ksvc is created on the cluster, functions project "magically" adds the health checks for readiness and liveness and it doesn't care, if there is smallrye extension with proper paths in application.properties added in the project.
Compare with the default behavior of kn service create: it adds the following "minimal" health check:
readinessProbe:
  successThreshold: 1
  tcpSocket:
    port: 0

User has no way of knowing that there is some default value applied on Functions side and he actually cannot in any way use the mentioned minimal health check.
Addition to Matej's summary:
Defaulting:

Not consistent with kn service create
User has no way of knowing what happens, where the health checks come from, how to change them.
No health checks description in Functions documentation.

No Defaulting:

The explicitly set health checks are self-documentary.
No magic creating health checks on application deploy.

I hit this using Quarkus, I have no idea if other runtimes also have some extensions similar to Smallrye and the same behavior applies to them.

@mvinkler @matejvasek thanks for the explanation - that all makes sense

Thank you for considering the situation, opening the topic, and providing a thread of pros/cons!
tl;dr: this is actually a feature request for the Quarkus Functions Runtime, but let's keep the issue open because the discussion is good.   Let me explain:

[we] tried to port some existing Quarkus code to use func but it did not work because of missing endpoints.

Implementing these endpoints is the responsibility of the Functions middleware (runtime) and an area of active development (see the Scaffolding Architectural Discussion and Go MVC Epic).   If the Function author has implemented health endpoints in their Function, those should be used (and how to do so clearly documented in multiple places; see below).  If they did not implement the endpoints, the middlware will answer those health and readiness checks, and these endpoints should be easily configurable.   This is clearly superior to a hard-coded TCP probe in the func.yaml on project creation for several reasons, and a point in favor of Functions as a "value add" over standard services.
However, this thread does indeed bring up two things worth covering in this week's call:  1) we need better func.yaml documentation and 2) we need to more strictly interpret func.yaml to help avoid confusion confusion.
I will be sure to bring this up in this week's meeting.
Here, I'll address the points made in this thread so far; just to be sure we have a productive conversation.

@lance What if user doesn't have endpoints, for instance when trying to migrate existing project to use func?

Then the middleware will implement it, to the best of its ability, entirely transparently to the Function developer.

Defaulting:

Three fewer lines in func.yaml.

This is a purposeful mischaracterization of the motivation, intended to cast it as of trivial benefit, and thus insinuating it's equally trivial to change the other way to achieve the subsequent benefits and avoid the cons.  Perhaps it's worth reiterating the actual purpose of the in-code defaults:
By hard-coding the values into the func.yaml when a Function is created, we are inhibiting the user's ability to migrate in the future, and our ability to respond quickly to everything from platform improvements to CVEs.  Updating func (library or binary) updates defaults, allowing the infrastructure supporting a user's Function to grow, evolve, and patch itself intelligently (see: our burgeoning conversation around how to implement a Function's operator).  Updating func binary can not touch the user's func.yaml without possibly destroying user changes, because there is no way to know if a value written to func.yaml simply the default written at Function craetion time, or a value intentionally added by the author.
Let's consider the next point as an example:

Defaulting:

There is absolutely no way to disable health probes should user want it.

This is a simple misunderstanding about the purpose of func.yaml.  It should be strictly interpreted as overrides to default middleware behavior.  With that expectation, setting the values to empty should disable the endpoints entirely, though this makes no sense to do, presuming the middleware works correctly.

− Not consistent with kn service create
See above, an intelligently implemented default endpoint is better than a TCP probe, and a value-add of Functions.

− User has no way of knowing what happens, where the health checks come from, how to change them.
This is a documentation issue, easily solved with a comment block in func.yaml showing the syntax and current default values.   This is idiomatic of many system config files.

− No health checks description in Functions documentation.
Duplicate of issue above:  need docs.

The explicitly set health checks are self-explanatory.

Again, a documentation issue, not a point either for or against setting defaults in code vs in the config file.

No magic creating health checks on application deploy.

Again, a documentation issue.  Countless things happen outside the purview of a service author.  What causes angst (and levying the prejoritive term "magic") is when complexity that the author needs to know is hidden.  I empathize, and empthatically agree that systems should not include (thusly defined) magic.    The root of the problem here, I believe, is taht the Quarkus Function in question needed to know.  These endpoints should be entirely optional (ignoring them should not cause the Quarkus function to fail), and it should be well documented, in multiple places, how an author can implement their own.
So summarize the conclusion:  it is absolutely essential that we 1) have better documentation of func.yaml  2) implement it trictly to enable complete control by the Function author and 3) write only user-provided overrides to func.yaml.  This latter point is essential to our future flexibility.
Thank you very much for the feedback

/assign

Thanks @mvinkler.  In our most recent meeting we discussed using a template for the func.yaml rather than a "blind" marshalling, which will have all possible settings enumerated (but commented out) with their static defaults shown in the comment.  If the user has overridden any of the values, the comment will be omitted in favor of the user-supplied setting.
This method is not without its annoyances (for example, any manual edits to the comments will not be retained), but this should allow one to easily scan through a func.yaml to see what options are available, and uncomment the lines to provide customized overrides.
This will be a good deal of manual work, but its documentation we need to have!
I also agree we should have an easy way to display the effective values on deploy.  Either via an echo during kn func deploy, a much -expanded kn func status, or both.
Let's leave this issue open until it is superceded by that task/issue directly 👍🏻

My thoughts on this issue are that having an opinionated implementation is perfectly fine as long as its documented.  Pushing people towards best practices is much better than letting people have absolute freedom.  (Rust borrow checker vs C entirely unrestrained)
I am not sure if there is an open standard between the different function providers.  OpenFaaS, AWS Lambda, etc.


[Bug]: Fonts return "Failed to decode downloaded font" when uploaded following the docs

Operating system
Windows 10
Node.js version
15.5.0
Shopify CLI version
2.1.0
Browsers
Chrome
Version
4 (Current)
Modifications
No response
Details
When adding fonts to my assets folder, and then referencing per the docs I get some errors.
It looks like the fonts might be being uploaded to shopify as the wrong type of file?

Notice

[X] I read the notice

This is a Shopify CLI bug. Currently, all binary file uploads are broken (images, fonts etc). Here's a comment from me on a similar issue in the Shopify CLI Repo

This issue should now be fixed with the latest Shopify CLI 2.3.0 release.


Correctness/Tests

You briefly mentioned this on the Reddit announcement:

Correctness is... tricky. I would like to run it against the Harfbuzz test suite, but I will have to account for differences in output both with respect to cluster numbering and how Harfbuzz distributes some positioning information differently between offsets and advances. Still, this is an area that needs attention.

I'm admittedly unqualified to understand why it's difficult to integrate the HarfBuzz test suite like rustybuzz did, but how immediate is it on your TODO list?
Tracking

[x] Text Rendering Tests
[x] AOT Tests
[x] In-house Tests

Note: rustybuzz is a direct port of harfbuzz. So its not surprising that they could just lift the test suite directly

I am actually going to begin investigating this in the next few hours because I believe it is vitally important now that this crate is released. I will leave this issue open and report back here on progress.

Small update on this. I've spent some time with the HarfBuzz test suite and developed a plan for moving forward. I won't try to predict a timeframe, but this issue is fairly high priority for everyone that has expressed interest in using this crate for shaping so it will be receiving a high proportion of my attention.

Small update on this. I've spent some time with the HarfBuzz test suite and developed a plan for moving forward. I won't try to predict a timeframe, but this issue is fairly high priority for everyone that has expressed interest in using this crate for shaping so it will be receiving a high proportion of my attention.

If you're interested, I could try implementing it if you don't mind giving a rundown on how you planned on doing it.

This is still important, but text layout has unfortunately taken precedence due to other interested parties that are making use of the crate. If you want to have a go at it, that sounds great! My plan is to essentially use the HarfBuzz test suite as is, so the first step is to write a parser for the test data to extract the fonts, input text and expected output glyph sequences. I don't recall if the test data contains the associated script. If not, you'd need to detect the dominant script in the input text. Then it's just a matter of loading the font, running the shaper and comparing the results.
I don't have a lot of time to devote to this at the moment, but am happy to provide assistance when I am able.

Gotcha, I'll work on it as soon as I'm able.

After some poking around with HarfBuzz, RustyBuzz, and Swash, I think I have a good idea on how to proceed from here. Since I know absolutely nothing about shaping, I'll estimate it'll take me 1-2 weeks to get a draft PR submitted (though with anything, prepare to add 1 or 2 weeks to that estimate :-) ). I was keen on learning shaping anyway, so I'm excited to start working on this.

Brilliant!
Tackling this was about 8-10 weeks out for me, so no rush at all. As for shaping, enjoy your journey down the rabbit hole. I took the tumble almost two years ago now and haven't hit the bottom yet :)

It's only a draft PR, so it may end up being that original 8-10 week estimate to get it merged :P

No worries. If you're not done by time it rolls around on my schedule, we'll finish it up together. Then comes the challenge of fixing all the bugs that the tests are sure to reveal. I know HarfBuzz has some per-script special casing for ZWJ/ZWNJ that I haven't accounted for so I'm hoping that pops up in some of the tests. There were also comments about tricky bits with some Arabic ligatures, but my ligature handling code is quite different from what HarfBuzz does so I'm curious to see if it catches the edge cases. We'll see how it fares.

@dfrg I've begun researching what I need to create the tests, and I've hit an obstacle with figuring out how to get the glyph name from a GlyphId in swash. Is there a method or function somewhere I missed?

Good catch. I didn't want to provide glyph names as public API because they're not useful in the context of font rendering, but I'll throw together some quick code to parse them from the post table and expose it under some doc(hidden) function to be used for the tests.

Realized I had written this code in an earlier rev, so just copied it over and pushed to master. FontRef now has a hidden glyph_name function that takes a GlyphId and returns Option<&'a str>. I believe HarfBuzz uses gid for missing names.

Awesome!

Progress update: I've begun working out the beginnings of the generate_tests tool. I hope (fingers crossed) that I will be able to get text-rendering-tests complete tomorrow.
@dfrg I don't quite understand the output format used in this test: https://github.com/harfbuzz/harfbuzz/blob/main/test/shaping/data/text-rendering-tests/tests/MORX-11.tests
[B|A@650,0|B@1288,0|B@1938,0|A@2588,0|X@3226,0|A@3812,0|B@4450,0]

Just a note that HarfBuzz seems to be accumulating advances into offsets here. I'm not sure if that is done for all of the tests.
I hacked together a small harness for this and an initial run through the shaper yields:
[B@0,0+650|A@0,0+638|B@0,0+650|B@0,0+650|A@0,0+638|X@0,0+586|A@0,0+638|B@0,0+650]
And if I accumulate advances:
[B|A@650,0|B@1288,0|B@1938,0|A@2588,0|X@3226,0|A@3812,0|B@4450,0]
Which matches the expected output.
The source text here is "BABBAABX" and the resulting glyphs are "BABBAXAB". This is a fairly odd use of the rearrangement mechanism in the AAT extended metamorphosis table that revealed two bugs. Both are "fixed" but might need some more work if there are real fonts that do this sort of thing. Notably, this font probably breaks text selection on macOS. Looks like we're in for a bumpy ride :)

Hi Kirawi,
I am interested in testing swash, what's about your testing tool? If I can help you anything, please let me know.
Thanks,

It was already merged #19, but @dfrg is continuing to work on it I believe.


log the errors always

constexpr int kMaxNumAccumulatedErrors = 1000;

only the errors count is large than 1000, the errors can be printed.
I think error log is very important to developers. It should be printed when it happened.

@googlebot I signed it!

Thanks jiqimaogou.  I believe you can see these errors immediately using the command line option either "--v=2" or "--vmodule=calculator_graph=2".  Let us know if these options are not sufficient for your use case.


Vulnerability roundup 97: tcpdump-4.9.3: 1 advisory [7.5]

search, files

[ ] CVE-2020-8037 CVSSv3=7.5 (nixos-20.09, nixos-unstable)

Scanned versions: nixos-20.09: 50c8d1e0deb; nixos-unstable: 83cbad92d73.
Cc @globin

patched on master in 08d77caac01d567acf1816c36cd16f38fecf41b2, on release-20.09 as b16158b39a785bc6e637c42a4054031b6a499cb5.

patched on master in 08d77caac01d567acf1816c36cd16f38fecf41b2, on release-20.09 as b16158b39a785bc6e637c42a4054031b6a499cb5.


⬇ feat: desktop entry & manpage installation through linutil-installer.sh

Type of Change

[x] New feature
[x] UI/UX improvement

Checklist

[x] My code adheres to the coding and style guidelines of the project.
[x] I have performed a self-review of my own code.
[x] My changes generate no errors/warnings/merge conflicts.

The include_dir crate appears to resolve symlinks. Instead of downloading these files from the internet, we can include them in the binary, by symlinking them into some directory the script can access.

The include_dir crate appears to resolve symlinks. Instead of downloading these files from the internet, we can include them in the binary, by symlinking them into some directory the script can access.

I know. Do we want to though? linutil-installer.sh already needs internet connection for its functionality.


Wrong measurements on ad delivery (SSP Yieldlab)

It seems that the Header Bid Expert shows way to high measurements when a delivery through yieldlab is done.
The measurement is correct as long, as only the header bidding call is done, but when the delivery call is added and the counting pixels are fired it seems, that they are all included in the measurements, ending in a way to high time span.
To reproduce it:

open the developer tool bar of your browser and go to the network tab
filter on "yieldlab"
navigate to https://kachelmannwetter.com/de

If you only see a /yp call than the given time span will most likely be ok. But once an actual ad is delivered with a /d call, than the timespan will be far to wide.
If you got problems getting a delivery, I recommend visiting https://www.otto.de/ or https://www.zalando.de/herren-home/. Just look at some items of these stores and you will hopefully get their ads.

Thanks for accepting the PR. With this merged and released, this can be closed.


Wrong collection name in code snippet of BlockingCollection

The code snipper mentions a numbers collection while in fact the name of  the collection is dataItems

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

ID: b5ab9298-8ed6-2a79-47c0-55021199ced6
Version Independent ID: 32d003fc-b7de-37b7-02c5-0719a8878e2a
Content: BlockingCollection Overview
Content Source: docs/standard/collections/thread-safe/blockingcollection-overview.md
Product: dotnet
Technology: dotnet-standard
GitHub Login: @mairaw
Microsoft Alias: mairaw

Thanks for pointing out the incorrect variable name in the comment, @mikaelmello. We've corrected it in dotnet/samples#909.


Add typst ftplugin runtime files

Adapted with some minor modifications from https://github.com/kaarmu/typst.vim.
The typst/emoji.vim and typst/symbols.vim are quite large and are used to provide conceal characters for emoji and math symbols. The g:typst_conceal variable is disabled by default so these files won't be used unless the user opts in to them. I can remove them if they're too bulky.

@ribru17 are you aware that you will be taken away maintainershipt for the ftplugin?

The g:typst_conceal variable is disabled by default so these files won't be used unless the user opts in to them. I can remove them if they're too bulky.

Yeah, let's remove it please. People who want the full expierence can still install the upstream repo.

@ribru17 are you aware that you will be taken away maintainershipt for the ftplugin?

Fine with me :+1:

Added docs for g:typst_cmd, g:typst_conceal, and g:typst_embedded_languages. Removed the typst/emoji.vim and typst/symbols.vim variables.
Removed the CompilerSet definition.
Updated file headers
Removed 'iskeyword' modification
I also removed most of the functionality in the autoload/typst.vim file (which were used for the custom user commands) and kept only the indentexpr function. If users want the TypstWatch or Toc commands they can use the full plugin.

thanks!


Remove Gaming section and OpenEmu

Types of Changes

[ ] New addition to list
[ ] Fixing bug in existing item in list
[x] Removing item from list
[ ] Changing structure (organization) of list

Proposed Changes
OpenEmu and gaming in general are completely unrelated to what this repo was created for, gathering apps helpful for developers and designers.
PR Checklist
Put an x in the boxes once you've completed each step. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[x] I have read the CONTRIBUTING guide
[x] I have explained why this PR is important
[x] I have added necessary documentation (if appropriate)

I saw your comment on issue #357, sounds good.


New Component: Site Alert

Site Alert
USWDS Version
2.10.0
Description
When your agency has urgent information to share with the public, it’s essential that it stands out from other content on the site.  Using the same site alert treatment across agencies helps create a consistent and predictable way for users to find urgent information across all government websites.
Requirements (proposed)
Prop Interface
Props = {
  heading?: string // Default undefined (to allow Site alert with no header)
  variant: "info" | "emergency"
  showIcon?: boolean // Default true
  slim?: boolean // Default false
  className?: string
  children: React.ReactNode
} & JSX.IntrinsicElements['section']

Example Implementation (proposed)
return (
  <SiteAlert heading="Short alert message">
    Additional context and followup information including <Link" href="#">a link</Link>.
  </SiteAlert>
)

More Details

<section>root element
The Alert component that we already have makes up most of the content of a SiteAlert. It's worth exploring if SiteAlert can just wrap an Alert and modify as necessary depending on the variant.

I decided after talking through it with @brandonlenz and @haworku that it's as much work to modify the existing Alert component, so I'm writing it independently


Keep the same format with captializing

Keep the same format with captializing
Signed-off-by: yuexiao-wang<EMAIL_ADDRESS>

i don't know - capitalization implies each point is a sentence - which also means it'd need a full stop.
I used to lean more to bullet points being a way to represent parts of a sentence, and would use comma's
I guess this is a style question - @sfsmithcha ?

Thank you for your contribution @yuexiao-wang . I'm closing this for a couple of reasons:
Commands and machine names should reflect the command line and also the machine names.
Capitalization is not required in the case of these bullets - they are continuations of a sentence, not the beginning of a new sentence.


Cobey vsmac refactoring

I have added a page on Visual Studio for Mac IntelliSense, which highlight basic behavior as well as improvements made in 2019. This includes new images as well as new copy.

Hi @cobey, can you re-target your changes/commits to the private repo? (visualstudio-docs-pr)  New articles and large changes to existing articles need to be submitted through the private repos so we can take advantage of the proofing, validation, and staging tools there.
Thanks, we'll close this PR and look for a new one from you in the private repo.
Here's some additional information about it:

Microsoft authors and contributors need to make content contributions through the private repository so the content can be staged and validated by the current validation rules.
After you review staging and fix all validation issues, you can tag an author for review or add the sign-off comment to let PR reviewers know that the updates are ready to be merged.
Read about authors working in the public repo for more information.
If you need help getting set up to work in the private repo, see How to get to the private repo. You can also take a look at the GitHub account setup page for additional details on making sure you're set up.

tagging @gewarren and @jillre for visibility to look for this content coming through the private repo.


Omejdn is not working in tesbed

Dear Team,
I am trying to use IDS testbed to validate dataspace. However, I am countering the issues specific to the omejdn as given below.
omejdn                 | 2024/04/22 13:03:31 [emerg] 1#1: unexpected "(" in /etc/nginx/conf.d/default.conf:14
omejdn                 | nginx: [emerg] unexpected "(" in /etc/nginx/conf.d/default.conf:14
I tried different versions, but they are still not working. This is an issue of parsing Ngnix.conf into the omejdn while creating the container. Due to this the connectorA could not get register with the broker as DAPS remains unreachable. Please help and let me know if you need any further rinformation
===================More logs are given below=======================================
azureuser@IDSConnector:~/IDS-testbed$ docker-compose up
Starting broker-core         ... done
Starting omejdn-ui           ... done
Starting omejdn-server       ... done
Starting postgresb-container ... done
Starting postgresa-container ... done
Recreating omejdn            ... done
Starting broker-fuseki       ... done
Starting broker-reverseproxy ... done
Starting connectora          ... done
Starting connectorb          ... done
Attaching to broker-core, omejdn-server, omejdn-ui, postgresa-container, broker-fuseki, postgresb-container, broker-reverseproxy, omejdn, connectora, connectorb
broker-core            | Starting Spring boot app
broker-core            | ARGS=-Djava.security.egd=file:/dev/./urandom -Dsparql.url=http://broker-fuseki:3030/connectorData -Delasticsearch.hostname=broker-elasticsearch  -Ddaps.validateIncoming=true -Dinfomodel.validateWithShacl=true -Dcomponent.uri=https://localhost/ -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
broker-core            | Listening for transport dt_socket at address: 5005
broker-reverseproxy    | /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
broker-reverseproxy    | /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
broker-reverseproxy    | /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
broker-reverseproxy    | 10-listen-on-ipv6-by-default.sh: info: IPv6 listen already enabled
broker-reverseproxy    | /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
broker-reverseproxy    | /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
broker-reverseproxy    | /docker-entrypoint.sh: Configuration complete; ready for start up
omejdn-server          | Starting Omejdn version 1.7.0
omejdn-server          | =========================================
omejdn                 | /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
omejdn                 | /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
omejdn                 | /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
omejdn                 | 10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
omejdn                 | 10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
omejdn                 | /docker-entrypoint.sh: Sourcing /docker-entrypoint.d/15-local-resolvers.envsh
omejdn                 | /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
omejdn                 | 20-envsubst-on-templates.sh: Running envsubst on /etc/nginx/templates/default.conf.template to /etc/nginx/conf.d/default.conf
omejdn                 | /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
omejdn                 | /docker-entrypoint.sh: Configuration complete; ready for start up
omejdn                 | 2024/04/22 13:03:31 [emerg] 1#1: unexpected "(" in /etc/nginx/conf.d/default.conf:14
omejdn                 | nginx: [emerg] unexpected "(" in /etc/nginx/conf.d/default.conf:14
omejdn-ui              | /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
omejdn-ui              | /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
postgresa-container    |
postgresa-container    | PostgreSQL Database directory appears to contain a database; Skipping initialization
postgresa-container    |

Dear @parwinderau,
Configuring Nginx in Azure involves modifying specific configuration files and creating symbolic links for proper operation.
Please take a look at the Nginx configuration in Azure.
However, looking at issue #141 it looks like you have already fixed the Nginx/DAPS issue.
Could you please check that the DAPS is launched by making a request to https://localhost:443?
In addition, if you share the complete deployment logs it can help to detect if there is any error in the deployment of any of the IDS-testbed components.
Finally, please share in this issue the changes you have made to the docker-compose IDS-testbed file to launch it in Azure and get DAPS working in conjunction with nginx redirection, so that it can help the community behind these components.