support POST /data_compliance/deletion/invitees

refs #28

Codecov Report

Merging #47 (5134af5) into master (42678a0) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master       #47   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           42        42
  Lines         2357      2361    +4
=========================================
+ Hits          2357      2361    +4

Impacted Files
Coverage Δ

lib/calendly/client.rb
100.00% <100.00%> (ø)

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


Data Section of appsettings.json

Steps to reproduce
Open appsettings.json
The issue
Would expect to see
ConnectionStrings section instead of
"Data": {
        "default": {
            "ConnectionString": "Server=someserver=somedatabase;Trusted_Connection=True;MultipleActiveResultSets=true"
        },
        "aes": {
            "ConnectionString": "Server=anotherserver=anotherdatabase;Trusted_Connection=True;MultipleActiveResultSets=true"
        }
      },

Further technical details
win 7 x64
rc2
vs 2015 update 2
Comments
I am starting to use strongly typed config.
The current structure of Data section of Appsettings has a hierarcy that doesn't lend itself to easy config object.
I want to do
"ConectionStrings": {
    "somedatabase" : Server=someserver=somedatabase;Trusted_Connection=True;MultipleActiveResultSets=true"
    "anotherdatabase": ConnectionString": "Server=anotherserver=anotherdatabase;Trusted_Connection=True;MultipleActiveResultSets=true"
}

This seems simpler to me but I am concerned about going against convention.
Is this a valid direction or will it work against me later as efcore develops.

@mikes-gh There is a bug in the item template for appsettings.config file in Preview1 tooling: https://github.com/aspnet/Templates/issues/589. The result is that doing Add New Item -> ASP.NET Configuration File creates a file with the outdated convention, i.e. "Data":"DefaultConnection":"ConnectionString". If that is what you are seeing please just hand edit the file to reflect the new convention?

Closing as duplicate of https://github.com/aspnet/Templates/issues/589. Please create a new issue in the Templates repo or the Configuration repo if I have failed to address your concerns. Note that this is not an EF issue.

@divega Sorry I missed that - thanks for the pointer


Add flag to queries to allow it to bypass query caching

538407bf7ec2ad40d93e1613385d022d9dd88778

&dontCache=true in the rest

query.setDontCache(true) in java


Add filter for map to reduce traffic, browser load

I tried this with mysql, but it doesn't seem to be impacting the map/load.
I have
MAP_FILTER_IDS = [161, 165, 16, 19, 167, 10, 13, 21, 23, 29, 32, 41, 46, 48, 50, 52, 56, 133, 77, 96, 163, 167, 177, 183, 191, 194, 198, 121, 98, 61, 54, 14, 118]
But several of the pokemon still show up.  (I even copied this to 'Trash IDs') ...

I've updated it so that it works with the current version.
@kbtbc the impact on the web.py won't be that big, but it reduces traffic for you
And with the load if you run the map on your phone with a big area you will notice the difference fast
I know a few people who had Pokemon Go / Chrome restart every time they switch between them as the sytem runs out of memory


Help if you can,thinks.

I would like to run your code. Could you tell me which Python packages and their respective versions are required to execute it?

Did you, by any chance, figured it out? Right now I am struggling with the same problem...

Hello bro i've sovled this problem! please follow my method.
this is the requirements.txt
certifi==2024.2.2
cycler==0.11.0
fonttools==4.38.0
idna==3.6
joblib==1.3.2
jsonpatch==1.33
jsonpointer==2.4
kiwisolver==1.4.5
matplotlib==3.5.3
networkx==2.6.3
opencv-python==<IP_ADDRESS>
packaging==24.0
pandas==1.3.5
pyparsing==3.1.2
python-dateutil==2.9.0.post0
pytz==2024.1
PyYAML==4.2b1
pyzmq==25.1.2
scikit-learn==1.0.2
scipy==1.7.3
setuptools
six==1.16.0
threadpoolctl==3.1.0
tornado==6.2
tqdm==4.66.2
typing_extensions==4.7.1
visdom==<IP_ADDRESS>
websocket-client==1.6.1
wheel==0.42.0

and the python version is 3.7
i install my pytorch use this command
pip install torch==1.12.1+cu116 torchvision==0.13.1+cu116 torchaudio==0.12.1 --extra-index-url https://download.pytorch.org/whl/cu116

when you finish install this you still have some bug in this code follow this image to fix.


webpack config setup

Right now there is a requirement on the consumer project to setup an alias in the webpack config to blabbr-config.js. What can we do to improve this? Could move the config as json and then expect to find that in the host somewhere but what about the version number being imported from package.json?

Discussing this more with @james-nash this is more of a bug. The config should come from a file in the server vs begin part of the build. If we need to, say, change the slack end point then we need to redo the builds for every single version. So the config needs to be separate.


Interactive Chart

hello,
first to say...really nice lib, real time line chart works really nice.
i have the question if there are some interactive functions like click one a point, zoom or something like that?
i have a real time line chart and i would need the possibility to click on the chart and get the y and time values of the point i clicked on.
thanks

The question of interactivity with real-time charts is still and open one. Since the chart is moving it seems like a bad idea from a UX perspective (as most interface do not require the user to hit a moving target when clicking or hovering). This being said I wonder if it is even the job of the library to provide this behavior in the first place.
That being said, if you have a sample implementation that does a good job with this, we would always welcome a pull request. For now I am closing this issue.


Year button dose not work and year always has comma.

<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/flatpickr/4.6.9/flatpickr.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/flatpickr/4.6.9/themes/material_blue.min.css"/>

              <input type='text' class="flatpicker form-control" value="<?= \Session::get('insight.from')?>" placeholder="クリックして入力" id="start_at" style="background-color: #fff;" readonly/>

~

              <input type='text' class="flatpicker form-control" value="<?= \Session::get('insight.to')?>" placeholder="クリックして入力" id="end_at" style="background-color: #fff;" readonly/>

I have these code on ubuntu 18.04LTS and chrome 89.0.4389.114.
The year input field always contains comma and year button dose not work at all.

Is there anything wrong with my source code?
Best regards,

I do not know how to solve it myself.
But, for now, I do need year so I added following CSS.
.flatpickr-current-month .numInputWrapper
{
  display:none;
}

Is there any other solution for this?


Typo in check_package_licence_list function name

Should we fix it? It should be check_package_license_list (with an s, not a c).
If people are using this function and we change it, their code might break.

Closing, feel free to reopen.


Unable to generate report

Hello,
I executed setup.ps1 and all modules was installed.
When starting Invoke-Scuba, after signing and execution code, the console show many errors (i think it's when to generate the HTML report)
"ExceptIfSubjectOrBodyContainsWords":  [
],
"DocumentMatchesPatterns":  [
],
"ExceptIfDocumentMatchesPatterns":  [
],
"DocumentContainsWords":  [
],
"ExceptIfDocumentContainsWords":  [
],
"SenderADAttributeMatchesPatterns":  null,
"ExceptIfSenderADAttributeMatchesPatterns":  null,
"SenderADAttributeContainsWords":  null,
"ExceptIfSenderADAttributeContainsWords":  null,
"RecipientADAttributeMatchesPatterns":  null,
"ExceptIfRecipientADAttributeMatchesPatterns":  null,
"RecipientADAttributeContainsWords":  null,
"ExceptIfRecipientADAttributeContainsWords":  null,
"ContentCharacterSetContainsWords":  [
],
"ExceptIfContentCharacterSetContainsWords":  [
],
"DocumentNameMatchesPatterns":  [
],
"ExceptIfDocumentNameMatchesPatterns":  [
],
"MessageSizeOver":  "",
"ExceptIfMessageSizeOver":  "",
"MessageTypeMatches":  null,
"ExceptIfMessageTypeMatches":  null,
"UnscannableDocumentExtensionIs":  [
],
"ExceptIfUnscannableDocumentExtensionIs":  [
],
},
{
"Description":  null,
"AllowBroadcastScheduling":  true,
"AllowBroadcastTranscription":  false,
"BroadcastAttendeeVisibilityMode":  "EveryoneInCompany",
"BroadcastRecordingMode":  "AlwaysEnabled",
"DataSource":  "Memory",
"Key":  {
"ScopeClass":  "Tag",
"SchemaId":  "XName=",
"AuthorityId":  "Class=Host;InstanceId=00000000-0000-0000-0000-000000000000;XmlRoot=",
"DefaultXml":  "SchemaId=;Data=;ConfigObject=;Signature=00000000-0000-0000-0000-000000000000;I
sModified=True",
"XmlRoot":  "name={urn:schema:Microsoft.Rtc.Management.ScopeFramework.2008}AnchoredXmlKey"
},
"Identity":  "Tag:Default",
"ConfigMetadata":  {
"Authority":  "Host"
}
}
],
"teams_successful_commands": [
"Get-CsTenant",
"Get-CsTeamsMeetingPolicy",
"Get-CsTenantFederationConfiguration",
"Get-CsTeamsClientConfiguration",
"Get-CsTeamsAppPermissionPolicy",
"Get-CsTeamsMeetingBroadcastPolicy"
],
"teams_unsuccessful_commands": [
]
}

Hello to complete the investigations :

I ran Invoke-SCuba -OutPath .\reports
of course .\reports is in my main directory folder
In this folder (at the end of Invoke-ScuBa execution with many errors), i can found files and folder :
ProviderSettingsExport.json
TestResults.csv
TestResults.json
IndividualReports -> (Folder)

but no HTML file locate on reports folder.
Thanks

I had the same problem

Same.  Here is the error that happens.  PS C:\Users[$USER]\Downloads\ScubaGear-main\ScubaGear-main> Invoke-SCuBA -productnames aad
Fatal Error involving the Report Creation.
Ending ScubaGear execution. See the exception message for more details: Invalid object passed in, ':' or '}' expected. (572882):         {
"baseline_version": "1",
"module_version": "1.1.0",
"date": "02/12/2024 14:48:38 Central Standard Time",
"tenant_details": [
{

Thanks Schrolla  for your answer.
However, i follow your instructions but different error, when i replace RequiredVersions.ps1, and after uninstall and reinstall scuba, i have the following error when running powershell command to load the scuba module :  import-module -Name .\PowerShell\Scubagear
Import-Module : No acceptable installed version found for module: Microsoft.Graph.Beta.Users
Required Min Version: 2.0.0 | Max Version: 2.12.0
Run Get-InstalledModule to see a list of currently installed modules
Run SetUp.ps1 or Install-Module Microsoft.Graph.Beta.Users -Force -MaximumVersion 2.12.0 to install the latest
acceptable version of Microsoft.Graph.Beta.Users
Au caractère Ligne:1 : 1

Import-Module .\PowerShell\ScubaGear

  + CategoryInfo          : OperationStopped: (:) [Import-Module], FileNotFoundException
  + FullyQualifiedErrorId : No acceptable installed version found for module: Microsoft.Graph.Beta.Users
      Required Min Version: 2.0.0 | Max Version: 2.12.0
      Run Get-InstalledModule to see a list of currently installed modules                                                        Run SetUp.ps1 or Install-Module Microsoft.Graph.Beta.Users -Force -MaximumVersion 2.12.0 to install the la     test acceptable version of Microsoft.Graph.Beta.Users,Microsoft.PowerShell.Commands.ImportModuleCommand


Does this work for React Native?

Since it is just a npm package, can this work in React Native?

We publish as an npm package for convenience, but it is a browser-based library.
This library relies heavily upon browser security and messaging features that often do not work or exist in web-to-native environments.
You can give it a try, but we do not officially support React Native. You may have some success calling out to our native Android and iOS SDKs from React Native, though.


Circle functionality?

Loving this framework, makes parsing GeoJSON so much simpler!
Looking to extend the functionality in here by adding support for circles. GeoJSON doesn't strictly have a "Circle" feature however convention states that you create a Point and then in the properties for the feature you have the radius.
Happy to submit a PR but just wondering where the best place to start would be.
Cheers

MapKit supports Circles with its MKCircle class too

Hi Chris,
thank you for your love for the project! :beer:
I see two issues with integrating support for circles into GEOSwift.
The first, easy one: the GEOJSON parser at the moment just ignores the features' properties. I have in plan to add support for them but actually it is not possible.
The second one is that the project is based on a C library named GEOS, that doesn't support circles. Nothing prevents us to extend features over the original project, but I would advise against introducing different primitives.
As a workaround you can try to do this (I didn't actually test it):
        if let point = Waypoint(WKT: "POINT(9 45)") {
            let radius = 1.13
            if let circlePolygon = point.buffer(width: radius),
                let overlay = circlePolygon.mapShape() as? MKOverlay {
                self.mapView().addOverlay( overlay )
            }
        }

Does this work for you?
Cheers

Yeah, that works fine for me! I suppose I'll just need to check whether or not the properties object has a radius specified and if so apply the necessary modifications
Thanks so much.

Ok happy to hear


[Core] Support for donation URLs

Contribution to #2099
This adds a new const "DONATION_URL" to the bridges. If set, a new (green for better distinguishing) button will be shown on the HTML overview, linking to that URL.

Not sure about design.

@ORelio and @JackNUMBER hi! Any suggestions about that link?
Also ping @somini @VerifiedJoseph @sysadminstory @corenting @AntoineTurmel @teromene @mitsukarenai @LogMANOriginal. If you haven't read discussion about donation, you can read it here https://github.com/RSS-Bridge/rss-bridge/discussions/2063

Forgot to ping @Roliga

I'm pretty sure that is your browser.
Firefox:

Chrome:

Edge:

It doesn't matter how large or small I make the window, the button doesn't morph like in your screenshot

About the colors: I'm not the best person for color choices, so feel free to change those :) My idea was to use a darker green for the link and a lighter green for the hover. If you have better values, go for it. I just wanted to use a positive color so the user notices it.

Thank you @Bockiii for initiating the design update.
About the
I suggest this color, as a tribute to the old logo ;)

Or something less "eye catchy". This way the buttons are limited to the output format.

Fix 1
About the 2-lines-button issue, it can be fixed with min-height: 40px, reduce Y's paddings and remove line-height.
  <- desktop
 <- mobile
Fix 2
In an other hand, if we want to keep the same design everywhere we can apply white-space: nowrap, min-width: 200px  and remove line-height but it can bring side effects on mobile.
 <- desktop
 <- mobile

Thank you @Bockiii for initiating the design update.

No problem :)

I suggest this color, as a tribute to the old logo ;)

That color is also fine with me. If you have an idea for the lighter "hover" color, post the values and I can change them

Or something less "eye catchy". This way the buttons are limited to the output format.

I actually want it to be catchy. If the maintainer doesnt provide the URL, it isn't shown at all, so it will only be shown on bridges with donation info. That way, people will actually notice the option and can then still choose to ignore it.
The eye-catchiness was the main reason I added it as an additional button in the location that everyone looks at anyways.

@JackNUMBER I like Fix 1 better than Fix 2.
Also, "Fix 3" could be just to write "Donate" on the button and not have the issue at all :D
I just wanted to make clear that you donate to the bridge maintainer and not to rss-bridge in general (we could/should put a button for that somewhere as well btw)

I actually want it to be catchy. If the maintainer doesnt provide the URL, it isn't shown at all, so it will only be shown on bridges with donation info. That way, people will actually notice the option and can then still choose to ignore it.
The eye-catchiness was the main reason I added it as an additional button in the location that everyone looks at anyways.

Agreed!
Default: #ff6600
Hover: #ff8a3b

donezo

Woops. didnt mean to start the review :D You can close that.
I added a new commit, doing all the style changes from @JackNUMBER

@em92 Do you want to add a donate button to rss-reader as well?
I would suggest doing it next to the hide-inactive-button. This way it's out of sight usually but still visible enough to not completely overlook. I would do it in the same visual style as the maintainer donate buttons, just smaller to fit the hide-inactive button.
Thoughts?
Also, do we want to make this configurable? So add a setting to not show donation buttons at all? I'm 80% "no" on this, but maybe someone else has a good point to make.

The design looks fine to me, and I think that the idea of allowing donations for bridge maintainers is a great idea as well.

Can I suggest something like that?

I am more on the side of "Make it visible on every specific bridge and less visible on the front page". So my vote is against the small donate link.
You can inline-review and add changes btw @JackNUMBER . If you change the .css to the 2-line-fix1, I can accept them here in this PR.

I like this, and would propose combining this with a project-wide banner on top asking for donations. Sort of like Wikipedia?

Isn't that one of the most universally hated banners in the web?
I'm still pro-button, but if you want to go with the text link, I would definitely not do a banner.
I'll just say that this will be overlooked completely.

Should we run a public poll for the different solutions or wo wants to decide this? I can code the solution, I just need to know the "what" :D

@Bockiii, I think we need to have both "clearly visible button in html preview" and "small text link in bridge card" and option, where instance admin chooses one (or even none, if admin does not want to show them). The default one should be "clearly visible button", 'cos of strategy to promote donation.

would propose combining this with a project-wide banner on top asking for donations. Sort of like Wikipedia?

@somini , that is discussable, but not here.

Do you want to add a donate button to rss-reader as well?

If you mean add donation link to feed items, then no. That is definitely going to be frustrating for users.

I meant a "donate to rss-bridge" link somewhere. One option would be next to the "show inactive" button. At the end of the site and usually half-greyed out if you dont hover over it. As I user, i would be find with it being there.
So I will do this:

One button like it is now on the html overview
One link on the bridgecard like in sominis screenshot
Global opt-out to not display donation links at all. Placed in the config.ini

I would not do it opt-in since we want to promote the usage. In the future, we could switch the default in the config ini to opt-in.

Current state:

Config option to disable donations. Default is "true" for donation display
Bridge Maintainer Donations as button in HTML and as link in bridgelist view
RSS-Bridge general donation link (I need an actual link to point to @em92 as I couldn't find anything) in the footer of the page.

html view:

bridgelist view:

general rss-bridge dono:

Thoughts?

Thoughts?

Hi, just read all the discussion and I totally agree with this end result. With donate link not too agressive in bridge list, more visible button in bridge details, and setting to optionally disable the feature 👍

However I'm not super confident in the financial part of the feature: what happens if several people work on a bridge? How to split/manage donations for the project-wide donation link? I'm not planning to accept donations for my own bridges in the near future but I'm still curious 🤔

for the general: no idea.
For the maintainer: I think the majority of bridges have 1 maintainer. If its more than one, I assume the team has to decide if the "old" maintainer is still worthy enough.
We could also do a mandatory site in the repo were we list a kind-of-history. "Originally by Peter, maintained by Paul since 2018. Link for Peter <> Link for Paul <>" or something... idk. I just picked up the todo, I have no game in this fight

Any blocker once PHPCS problems are fixed ? @em92

@em92 @teromene all fixes fixed.

Okay. If you ever want to add a general dono URL, you have an example.
Other than that, we would also need to adapt documentation. How far along is the rework?

Other than that, we would also need to adapt documentation. How far along is the rework?

Mark Ruffallo and Leonardo Di Caprio meme

gj @Bockiii !


Add support for alternative RSA implementations

Goal
The main purpose of this PR is to pave the way for alternative RSA implementations by having the library interact with the RSA module through the RSA interface functions only, as opposed to direct manipulation of structure fields.
@mpg @gilles-peskine-arm @yanesca Please review.
Main parts

Extend RSA interface to allow function-based setup and export of an RSA context.
Adapt library, tests and example programs to use the new functions.
Use the gained flexibility to remove CRT fields DP,DQ,QP,RP,RQ from the RSA context if RSA_NO_CRT is defined (see below for why P,Q are retained nonetheless). After the preparation, this requires changes in the RSA module implementation only.

Changes in more detail
Interface changes

The RSA interface is extended by import functions that can be used to setup RSA contexts from RSA core parameters (N, P, Q, D, E). The parameters can be provided as mbed TLS MPI's (mbedtls_rsa_import) or as big endian byte arrays (mbedtls_rsa_import_raw), and import can happen at once or successively.
The interface is extended by export functions that can be used to extract RSA core parameters, again either as MPI's (mbedtls_rsa_export) or as big endian byte arrays (mbedtls_rsa_export_raw).
The interface is extended by a completion function mbedtls_rsa_complete that can be used to finalize the initialization of an RSA context after its core parameters have been imported (e.g., computing any internal helper variables from the core parameters).
The interface is extended by generic (meaning: not depending on the RSA context structure) helper functions for deducing missing but redundant RSA core parameters; specifically, this includes the derivation of the prime moduli from a pair of private and public exponent (mbedtls_rsa_deduce_moduli), and the derivation of the private exponent from the prime moduli and the public exponent (mbedtls_rsa_deduce_private) and the computation of CRT parameters (mbedtls_rsa_deduce_crt). The new completion function uses these helper functions to setup RSA contexts if they have only been partially specified.

These changes are meant to encourage the transition from constructing RSA contexts by hand to building them through interface functions, which is hopefully more stable against future changes and/or drop-in alternative RSA implementations.
The PR does not remove or change the signature or semantics of any existing RSA interface function and is therefore meant to be fully backwards compatible.
Library changes
The library code directly interacting with the RSA module needed adaption in the PK interface layer:  pkwrite.c, pkparse.c and pk_wrap.c.
Test changes

The RSA selftest needed adaption to the new interface
The RSA test suites needed adaption to the new interface
The PKCS v15 / v21 test suites needed adaption to the new interface
The RSA test suite has been significantly expanded to test the new interface functions.
all.sh has been extended by a run with MBEDTLS_RSA_NO_CRT set.

Example program changes
Exemplifying the intended use of the new interface, numerous example programs have been modified accordingly: key_app, key_app_writer, gen_key, dh_server, rsa_sign, rsa_genkey, rsa_encrypt, rsa_decrypt.
Comments
Necessity of helper functions
The helper functions, in particular the one computing P,Q from N,D,E, were written with the intend to support implementations using N,D,E only - including our own if MBEDTLS_RSA_NO_CRT is set. After all, however, it seems that removing P,Q introduces problems that outweigh the space benefit it brings - see below. Keeping P,Q (or at least one of both) in the RSA context frees us from the need for the derivation function mbedtls_rsa_deduce_moduli, and we might therefore decide to drop it or to make it optional (disabled by default). This is up to discussion - for now I kept mbedtls_rsa_deduce_moduli.
Reducing the RSA context to N,D,E alone
If neither CRT nor verification are used, mbedtls_rsa_public and mbedtls_rsa_private can be implemented using N,D,E only, and so it is tempting to reduce the RSA context to N,D,E alone. However, the following cumbersome questions arise:

What does mbedtls_rsa_check_privkey check for if only N,D,E are present?
With only N,D,E given there are no simple sanity checks. Instead, to get confidence that they belong to some complete RSA keypair, one of the following computation heavy checks would need to be done:

Temporarily deduce P,Q from N,D,E and check that N,P,Q,D,E all fit together.
Do a pair of example encryption and decryption (using N,D,E only) and check that they are indeed inverse to each other.

When setting up an RSA context from a DER encoded RSA key, where to do the checking of the unused fields P,Q,DP,DQ,QP?
To make the problem clear, assume that we're setting up a bare-bones RSA context which uses N,D,E only, and which during setup completely ignores P,Q,DP,DQ,QP. When we're calling mbedtls_rsa_check_privkey afterwards, this will somehow (as discussed above) check if N,D,E can be extended to a valid N,P',Q',D,E, but it will not take the P,Q parameters from the original DER encoded key into consideration. The question is if and where the verification of these original parameters should happen. There are three options:

The parameters have to be checked by the user before the RSA context is set up. The RSA implementation may completely ignore unused parameters, in particular not validating them against those that are used.
Even if the RSA context does not use P,Q,DP,DQ,QP, it must accept and verify them at setup.
No checking at all.

Comments on that:

The first option is highly redundant if a full-fledged RSA key is used, because we're introducing both an unnecessary copy of the key and an unnecessary check (because for a full RSA context, mbedtls_rsa_check_privkey will contain all the checks).

For the second, the interface must either enforce all parameters to be passed to the context at once at setup time, or the RSA context has to somehow save them internally until enough parameters are present for verification. In the former case, we're again unnecessarily introducing a full copy of the RSA key during setup when a full-fledged RSA context with all fields is used. In the latter, additional fields have to be added to the RSA context for the temporary storage, counteracting the initial intend of keeping the context small.

The third option sounds bad at first, but on the other we're probably trusting our own private key in the first place anyway?

The approach followed in this PR uses a mixture of the first and second approach: The RSA context must accept and validate the core parameters N,P,Q,D,E, and the compatibility-check of the parameters DP,DQ,QP with the core parameters is done in the interface function mbedtls_rsa_check_crt after the setup is completed.
I think that the little space gained from removing P,Q from the RSA context is not worth the complexity it introduces, so I sticked with it even when MBEDTLS_RSA_NON_CRT is set.

Regarding checking of unused fields, I'd be inclined to say that not checking them at all is a fine option. IMO the main purpose of checking keys is to make sure we won't produce wrong results (and, crucially, that we won't leak information by doing so). I understand that some people might want to validate a particular keyfile for the sake of it, but as you say private keys are supposed to be trusted anyway, so I don't think this use case is important enough to justify increasing the complexity of the code or API.
Similar ideas apply to "what does checking a key mean when we only have N, E and D?".
Regarding P and Q in the context, IMO the main reason they're needed currently is for exponent blinding, which unless I'm mistaken is just as useful in the non-CRT case as in the CRT case. However, I'm wondering it we could not get rid of that need by blinding with a multiple of D*E instead of a multiple of phi(N). In practice, 99.9% of the time E is 17 bits, so we don't loose that much. However, that might not be acceptable for the remaining 0.1%.

Hi @mpg, thanks for your comments! Not promising to always validate all fields when parsing a DER encoded RSA private key would ease matters, and your idea of using multiples of D*E for blinding when P,Q are not present sounds promising, too. Still, we also need P,Q when writing DER-encoded RSA private keys in mbedtls_pk_write_key_der, so if we want to get rid of P,Q in the context structure we'd need to dynamically deduce them using something like mbedtls_rsa_deduce_moduli.

Good point about writing keys, I didn't think about it.
On the other hand, now I'm wondering if some alternative implementations might want to refuse writing or more generally exporting (some) private keys. (I'm thinking HSM or that kind of thing, not just about the P and Q thing any more.) How would we handle that? Maybe in that case the export function could return a special code like MBEDTLS_ERR_RSA_OPERATION_NOT_PERMITTED?

@mpg Good point, HSM's should be allowed to refuse such export requests. When it comes to our non-CRT default software implementation, I think we should be able to export the full PKCS1 RSA private key, so looking at our previous discussion, I think there are two options:

Keep at least P or Q in the context.
Reduce the context to N,D,E only, and generate P,Q on the fly when export[_raw] is called.

As we discussed, 2. is only feasible in conjunction with the lax verification of imported parameters (ignoring unused ones - this would need clarification in the documentation) and an either non-meaningful or computation-heavy modification rsa_check_privkey.

I think both options are acceptable and can lead to a similar API (that is, if we consider that performance characteristics are not part of the API). From what I know, I feel like keeping P and Q in the context might be easier to implement cleanly, but at that point you're probably in a better position than me to judge that.
I think the only requirement, of which I'm sure you're already aware, is that users be able to provide only N, D, E and we take care of the rest, one way or the other.
PS: just curious, what's the expected complexity of the probabilistic code that recovers P and Q from N, D, E? How does it behave if D doesn't match N, E?

@mpg Once you know an odd multiple K of LCM(P-1,Q-1), you have a 50-50 chance of finding a non-trivial 4-th root of unity (1,-1) or (-1,1) in Z/NZ ~= Z/PZ x Z/QZ when applying (-)^(K/2) to some random element in Z/NZ (and then the GCD of that number +1 with N is P or Q). If you know only DE - 1, i.e. just some multiple of LCM(P-1,Q-1), you additionally have to search for an odd multiple of LCM(P-1,Q-1)/2 by going through the (DE - 1)/2^j. The implementation starts with the maximal such j, so it depends on the order of 2 in P-1 and Q-1 how many iterations are needed - e.g., for safe primes, already the first iteration would succeed. This is not very detailed, though, and perhaps it would be good to estimate and document the expected number of squarings needed until the algorithm succeeds.
I haven't thought in detail about the complexity when D,E do not fit. In this case, the algorithm would perform 30 (hardcoded, perhaps too large?) iterations, and for each of traversing ord(2,DE-1) candidates for (P-1)(Q-1)/2.

Ok, so the dominant operation seems to be (-)^(K/2), but we don't have a repeat it too many times unless we're really unlucky, right? So if the goal was just to check N, E, D it looks like it would be less expensive to just to a simple public-private operation on random data and see if we get back to that data. But of course there are situations where we actually want to findP, Q, not just check N, E, D.

@mpg Given a random number 0 < X < N, we first compute X^L for L = ( DE - 1 ) / 2^max and afterwards only square. So each iteration (which succeeds 50% of the time of N,D,E fit) should be at most as expensive as an exponentiation to the exponent DE - 1.

Ok, thanks!

@mpg So in summary, it seems like it doesn't make a big difference in (computation and memory) costs whether we try to find P,Q or just do a random encryption-decryption if N,D,E match.

If I understand correctly, the only difference is that in one case we're doing something just once, and in the other we're doing some roughly equivalent thing once with proba 1/2, twice with proba 1/4, etc, so on average 2 times.

Re-pushed last commit to trigger CI which didn't seem to be working.

I like the new interface and the helper functions.
On requiring p and q in the non-CRT case:

What does mbedtls_rsa_check_privkey check for if only N,D,E are present?

Not an issue. This function isn't supposed to guarantee that the key is valid, merely that using it won't cause a bug such as a buffer overflow or division by zero.

When setting up an RSA context from a DER encoded RSA key, where to do the checking of the unused fields P,Q,DP,DQ,QP?

If the fields need checking, check them at the point where you have them. Storing p and q (but not dp, dq and qp) won't help you anyway.
The real problem I see with eliminating p and q is that they're used for exponent blinding. If we could solve that then I'd argue for eliminating them. If you aren't using CRT, it's presumably because you care either about data size or about glitch attacks. Then it isn't good to carry extra data around.

I like the new interface and the helper functions.

I'm relieved to hear that.

What does mbedtls_rsa_check_privkey check for if only N,D,E are present?

Not an issue. This function isn't supposed to guarantee that the key is valid, merely that using it won't cause a bug such as a buffer overflow or division by zero.

Ok, if we want that semantics, we're fine, but isn't that too weak? If a user checks for validity of the key, shouldn't he rightfully expect that, e.g., a pair of encrypt-decrypt or sign-verify will give the expected results?

When setting up an RSA context from a DER encoded RSA key, where to do the checking of the unused fields P,Q,DP,DQ,QP?

If the fields need checking, check them at the point where you have them. Storing p and q (but not dp, dq and qp) won't help you anyway.

The point is memory efficiency again. These fields cannot be checked on the fly as you need to have several of them in order to perform any validation (e.g. for PQ you need P and Q). If you don't care about them in the first place, e.g. because you're not using CRT, what should you do? Temporarily hold them back to verify them once they have all been provided (which is not required to happen at once in the current form of rsa_import, again for memory reasons), or simply ignore them? Again, the simplest solution for us is to make no guarantees on validation of the imported parameters at all, allowing us to ignore what we don't need.

@gilles-peskine-arm @mpg @yanesca
Just a general note: The current non-CRT implementation still keeps P,Q around, but that's not at all carved in stone - with the other changes, it would be rather quick to throw them out, provided we agree on sufficiently weak semantics for import, complete (no guarantees for imported parameters?) and  check_privkey. It's just something we need to make a decision on.

This function isn't supposed to guarantee that the key is valid, merely that using it won't cause a bug such as a buffer overflow or division by zero.

Ok, if we want that semantics, we're fine, but isn't that too weak? If a user checks for validity of the key, shouldn't he rightfully expect that, e.g., a pair of encrypt-decrypt or sign-verify will give the expected results?

@hanno-arm The API documentation doesn't say what it means by “valid”, so as a programmer using the library I don't really know what it does.
Taking a step back for a moment, I see two use cases.

The caller trusts that the key is valid. Any check the library does is useful only to detect basic programmer errors such as passing parameters in the wrong order. We don't need any fancy mathematical checks, and testing will quickly reveal bugs that result in bad functional input.
The caller doesn't trust that the key is valid. Any check the library does is insufficient — we aren't going to verify that the key is really a good one, which would entail making sure that nobody unauthorized knows the private key (e.g. it's been generated by a backdoored RNG). Since we can't guarantee security, is there any benefit to providing functional guarantees beyond “this won't crash when you run it”?

In summary: I'm fine with garbage in, garbage out.
Whatever we decide, it would be good to document the expectations in the public interface.

I'm happy about the commits down to https://github.com/ARMmbed/mbedtls/pull/1060/commits/56bae95e1d3528d4c562293c915c74ea8762505c but several issues in my initial review have not been addressed, especially the modification of input parameters in mbedtls_rsa_deduce_xxx which I continue to disagree with.

Let me try to summarize the situation:

@gilles-peskine-arm and @andresag01 argued that allowing the modification of input parameters in mbedtls_rsa_deduce_moduli, mbedtls_rsa_deduce_private, mbedtls_rsa_import_raw and mbedtls_rsa_check_crt is counter-intuitive and not worth the space-efficiency it brings. My original incentive was to try to not put an API commitment burden on us that will impede potential future work in the direction of less memory-usage. Still, @gilles-peskine-arm has a point saying that such considerations might be premature at this point. So the signatures of these functions will probably be changed.

@gilles-peskine-arm and @mpg seem to be in favor of a lax semantics for import, complete and check_privkey not guaranteeing anything about the validity of the parameters that have been imported - if the user has reason to mistrust the private key, he has to use other means to verify it. If that's the way we want to go, the documentation needs to be changed, and a few test cases might need to be dropped. A benefit of this semantics is that it will allow easy switching to an N,D,E only non-CRT version of the RSA context on the next ABI breaking release.

I don't think there were any other bigger discussion points so far.

@hanno-arm

I would be against modifying input parameters even if I believed it could lead to significant memory usage reduction.

I'm in favor of a lax semantics, provided that our users don't currently expect more. From the current public documentation, I don't see any reason to expect more.

@gilles-peskine-arm @yanesca @mpg Please note the newest commits which follow the requests to make the input arguments constant. Further, they relax the semantics of the complete, import and check_privkey routines to not include any strong guarantees about the sanity of the internal parameters, which would e.g. allow us to drop any non-trivial checks when passing to an N,D,E-only non-CRT context at the next ABI-breaking release. Note also that despite that semantic relaxation, the current implementation check_privkey has remained untouched and continues to perform detailed checks, as all relevant fields are present.
I'm still wondering whether the semantics isn't too weak this way, and whether we should at least mandate that some empirical consistency-check is done, e.g. performing a pair of encrypt-decrypt as in the public-private check for alternative RSA implementations which would most likely catch any accidental misconfiguration.

Two general remarks (sorry if this is not the best place, I find the github interface suboptimal for large review discussions).

Regarding keeping P and Q in the CRT context: while it's undesirable, I don't see a better solution right now, and this PR is already a significant improvement for non-CRT users, so I'm happy to accept that part.

For the record, I agree with the arguments given against modifiable input parameters (even if I understand the arguments for it) and I'm glad it was changed.

I think I've commented on all pending API/design issues, please let me know if I forgot one. I'll do an actual code review of the implementation once a agreement has been reached and implement on the design/API issues.

@mpg @yanesca @gilles-peskine-arm
Thanks a lot to all of you for your reviewing so far! In the latest commit, I addressed the following points of our discussions:

Weaken semantics of rsa_complete, while keeping a strong semantics of rsa_check_privkey.
Split off the RSA helper functions from rsa.c and introduce a separate compilation unit for them.
Remove the PRNG argument from rsa_deduce_primes.

The model for the usage of RSA_ALT hasn't yet been adapted - I still need to catch up on the discussion there.

I made some oversights in case of MBEDTLS_RSA_NO_CRT causing the tests to fail. I'll look into it.

@mpg @gilles-peskine-arm @yanesca Pushed two commits that keep DP,DQ,QP,RP,RQ in the RSA context even if RSA_NO_CRT is set, to preserve the ABI. Also, in response to #1139 I changed the code to not check for P,Q in rsa_private if NO_CRT is set and f_rng == NULL. rsa_complete will always check for P,Q as it cannot know if rsa_private will be called with or without PRNG, and not using a PRNG is deprecated.

@yanesca Switched to old model for alternative implementations.

I'm not sure we have a requirement to keep the ABI stable for non-default configs; I would assume most people who use us as a shared library do so in the context of Linux distros, which probably build us with the default config. However, it's probably safer to err on the side of not changing the ABI anyway.
Can you please add that to the list of changes waiting for the next ABI change? (See email.)

@gilles-peskine-arm @mpg Thanks for your feedback - I pushed some commits addressing your comments and requests.

@yanesca Thanks for your comments, I've answered (strangely it's only shown if you open the respective file - here) and added a commit.

@gilles-peskine-arm @mpg @yanesca Janos and I have had a longer discussion and considered making the following changes:

Modify the signature of mbedtls_rsa_import to int mbedtls_rsa_import( mbedtls_rsa_param_t param, mbedtls_mpi *val ) allowing to set one parameter at a time, selected by an identifier enum mbedtls_rsa_param_t holding values like MBDTLS_RSA_PARAM_N. In comparison to the previous code, this forbids all-at-once importing of parameters, but that doesn't seem a noteworthy loss. Also, importing DP,DQ,QP can be easily added, as @gilles-peskine-arm requested above. The same changes would of course apply to mbedtls_rsa_import_raw, mbedtls_rsa_export and mbedtls_rsa_export_raw.
Currently, mbedtls_rsa_complete guesses the kind of key the user probably intended to set up from the parameters that were imported, but that's not foolproof. E.g. if the user intends to setup an decrypt-only private key from N,D but mistakenly imports N,E, then rsa_complete would view it as a public key. The suggestion is to add a bitflag parameter to mbedtls_rsa_complete identifying the intended use for the RSA key, which is any subset of sign, verify, decrypt, encrypt (shortcuts can be defined for all-operations, verify-encrypt and sign-decrypt). The guarantees that rsa_complete makes is that on success the respective functions can be safely called without risk of failure or crash.

As an aside, this will shorten the PR considerably by rendering all tests around all-at-once vs. successive import/export superfluous.
@mpg @gilles-peskine-arm Please let me know if you think that's a reasonable change.

@hanno-arm  @mpg @yanesca Regarding the proposed changes to import and complete:
I'm happy with the current interface. I'm not adverse to changing, but see no compelling reason.

selected by an identifier enum mbedtls_rsa_param_t holding values like MBDTLS_RSA_PARAM_N.

I'm not necessarily against this, but I don't see it as a clear win. Both methods have potential for user error:

Many parameters at once → wrong order of arguments
One parameter designated by an enum → use the wrong enum constant

I think the second one is more likely because it's a natural copy-paste mistake. The first is more likely to be a single copy-paste of example code.

The suggestion is to add a bitflag parameter to mbedtls_rsa_complete identifying the intended use for the RSA key, which is any subset of sign, verify, decrypt, encrypt (shortcuts can be defined for all-operations, verify-encrypt and sign-decrypt).

That could be a good idea, especially given that we're planning to add support for external keys which may have permission restrictions (e.g. a key for which the external token allows signature but not decryption). But for the use case of external keys, what matters is analyzing an existing key, not the creation of the key which doesn't go through our library.
If someone calls this function with SIGN as the flag, and they try to decrypt with the key, there is an expectation that the decryption attempt will be rejected. Do we want to promise that (assuming that people call the API correctly, this is a C API, not an crypto token which defines its own security perimeter)? Do we want to allow it in the future?

Update: Merged with development and added a commit applying the fix from PR #1025 to the new RSA tests.
@gilles-peskine-arm @mpg I suggest whoever reviews the merge commit does the merging himself and compares the results. The merge was not very complicated, it was about the ChangeLog, error codes, deprecation comments, and #1025.

@gilles-peskine-arm Thanks for the quick feedback. I've pushed a commit to address your comments.


Erreur d'installation

J'ai suivi scrupuleusement l'installation :
composer create-project umbrella2/skeleton .
mais j'ai cette erreur, sans avoir rien modifié au code
PS C:\wamp64\www\mes_comptes> composer up Loading composer repositories with package information Restricting packages listed in "symfony/symfony" to "5.3.*" Updating dependencies Nothing to modify in lock file Installing dependencies from lock file (including require-dev) Nothing to install, update or remove Generating optimized autoload files composer/package-versions-deprecated: Generating version class... composer/package-versions-deprecated: ...done generating version class 85 packages you are using are looking for funding. Use the composer fund` command to find out more!
Run composer recipes at any time to see the status of your Symfony recipes.

Executing script cache:clear [KO]
 [KO]
Script cache:clear returned with error code 1
!!
!!  In ArrayNode.php line 252:
!!
!!    Invalid type for path "umbrella_admin.menu". Expected "array", but got "string"
!!
!!
!!
Script @aut
```o-scripts was called via post-update-cmd`

up en 3.3 et ça passe maintenant


Roll engine 9aa7c9a48e93..fcd717e28df8 (4 commits)

https://github.com/flutter/engine/compare/9aa7c9a48e93...fcd717e28df8
git log 9aa7c9a48e9342a450c3078e15c8d7923a338ede..fcd717e28df83038055084d2ed0d737cd8863b72 --no-merges --oneline
fcd717e28 Update README.md to point to flutter.dev (flutter/engine#8557)
501892a92 Roll src/third_party/skia 35f1c154c5e5..25071cc52b4b (7 commits) (flutter/engine#8560)
db99c86ab Roll src/third_party/skia 41476708db86..35f1c154c5e5 (1 commits) (flutter/engine#8559)
a88cd8032 Roll src/third_party/skia f74fff660084..41476708db86 (1 commits) (flutter/engine#8558)
The AutoRoll server is located here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, please contact the current sheriff (garyq@google.com), and stop
the roller if necessary.

Trybots failed. These were the failed builds: https://cirrus-ci.com/task/5174931091357696 , https://cirrus-ci.com/task/5710626121842688

Commit queue failed; closing this roll.


Fix notifications escaped msgs

cc @javierarce @zenitraM

:+1:

Frontend tests were OK :+1: (details)


WIP: Upgrade kubernetes dependencies to v1.27

What this PR does / why we need it:
I upgraded kubernetes dependencies to v1.27. Also, I will upgrade the controller-runtime version in a separate PR since the latest controller-runtime has huge breaking changes with non-backward compatibility.
ref: https://github.com/kubernetes-sigs/controller-runtime/releases/tag/v0.15.0
Which issue(s) this PR fixes (optional, in Fixes #<issue number>, #<issue number>, ... format, will close the issue(s) when PR gets merged):
part-of #1803
Checklist:

[ ] Docs included if any changes are user facing

It seems that we should upgrade k8s dependencies with controller-runtime.
/close


user data clean up

once we remove the temp fastly headers we will need to update the language and country for users with these countries

[ ] xx
[ ] xr

users located in the us, with global english, should have language updated to english
select u.uid, u.mail, a.field_address_country, u.language
from users u
inner join field_data_field_address a on a.entity_id = u.uid
where u.language = 'en-global'
and a.field_address_country = 'US';

users from mexico, update from global english to mexican spanish and country to mx
select u.uid, u.mail, a.field_address_country, u.language
from users u
inner join field_data_field_address a on a.entity_id = u.uid
where u.language = 'en-global'
and a.field_address_country = 'XX';

users from brazil, update from global english to brazillian portuguese and country to br
select u.uid, u.mail, a.field_address_country, u.language
from users u
inner join field_data_field_address a on a.entity_id = u.uid
where u.language = 'en-global'
where a.field_address_country = 'XR';

this should be a db_update hook in the global module


Concurrent enter/leave transitions

I'm submitting a feature request
Current behavior:
I read a closed issue on the animator-css branche regarding concurrent enter/leave transitions between the outgoing and incoming views:
issue
Rob mentioned also the following within this issue.

This is supported now in the router-view and we'll add it to the compose element as well. See the latest release blog post for more information.

Expected/desired behavior:
Am wondering if it would be possible to implement this feature also for the compose method.
Within the aurelia-router plugin this feature is already implemented:

The router-view has a new property swap-order which lets you control the swaping order of views. By default, it is set to "before" which adds the new view before removing the old view. It can also be set to "with" and "after".

<router-view swap-order="with"></router-view>

What is the motivation / use case for changing the behavior?
See above, in expected behavior.

This might make a nice contribution as well, if you are interested.

Sure, i will take a look and see if i can make a PR that implements this feature.

@EisenbergEffect  Hi Rob, I think i've implemented this feature. Yesterday i tried to create a gist, but (still) have some trouble to use the custom version of both plugins.
Only the implementation covers both the following branches:

aurelia-templating composition-engine.js
aurelia-templating-resources compose

Furthermore there are no unit tests created yet. Because I didn't see any unit tests within the templating-router branche relating to the swap-order attribute.
Would you like to take a look at the code? If the implementation is done the correct way.

Absolutely. Go ahead and submit a pull request and we can do a code review. Thanks!


Cant upgrade v15 to v16 - Could not find package.json

Which @angular/* package(s) are the source of the bug?
compiler-cli
Is this a regression?
Yes
Description
I have read through the checklist prior to the upgrade and I run the upgrade command:
ng update @angular/cli @angular/core
At first I needed to update my CLI and node version, which I have done.
The command still fails with:

An unhandled exception occurred: Could not find package.json
See "C:\Users\psarn\AppData\Local\Temp\ng-xqBl5P\angular-errors.log" for further details.

I am running the ng update in the same folder as package.json.

Node is in my PATH and latest LTS version (18.16.0.).   npm is 9.6.7.
I'm out of ideas, outside of doing the whole thing manually.
Error log shows:

[error] Error: Could not find package.json
at getProjectDependencies (C:\Users\psarn\AppData\Roaming\npm\node_modules@angular\cli\src\utilities\package-tree.js:68:15)
at async UpdateCommandModule.run (C:\Users\psarn\AppData\Roaming\npm\node_modules@angular\cli\src\commands\update\cli.js:191:34)
at async UpdateCommandModule.handler (C:\Users\psarn\AppData\Roaming\npm\node_modules@angular\cli\src\command-builder\command-module.js:118:24)

Please provide a link to a minimal reproduction of the bug
ng update @angular/cli @angular/core
Please provide the exception or error you saw
> An unhandled exception occurred: Could not find package.json
> See "C:\Users\psarn\AppData\Local\Temp\ng-xqBl5P\angular-errors.log" for further details.

Package                      Version
------------------------------------------------------
@angular-devkit/architect    0.1600.2 (cli-only)
@angular-devkit/core         16.0.2 (cli-only)
@angular-devkit/schematics   16.0.2 (cli-only)
@schematics/angular          16.0.2 (cli-only)

Package.json still showing 15.2.5.

"dependencies": {
"@angular/animations": "^15.2.5",
"@angular/cdk": "^15.2.5",
"@angular/common": "^15.2.5",
"@angular/compiler": "^15.2.5",
"@angular/core": "^15.2.5",
"@angular/forms": "^15.2.5",
"@angular/platform-browser": "^15.2.5",
"@angular/platform-browser-dynamic": "^15.2.5",
"@angular/router": "^15.2.5",

Anything else?
No response

This seems like a bug but we'll need to look at a reproduction to find and fix the problem. Can you setup a minimal repro please?
You can read here why this is needed. A good way to make a minimal repro is to create a new app via ng new repro-app and adding the minimum possible code to show the problem. Then you can push this repository to github and link it here.
This might be related to your directory structure so its really important to get an accurate repro to diagnose this.

Closing due to the lack of a reproduction.


refactor common code out of zedUpload, add explanational comment

This is something I wanted to do after #2643

It adds a lot more detail to the explanation as to why we use sync.Pool
It refactors out a lot of repetitive code into a few utility types and functions
It separates between actual update stats - sizes, errors, parts that are done - and responses, which are implementation-specific.

I assume yetus will fail, let's let it and then fix.

I forgot to make porto-vendor, as @giggsoff pointed out. Just done and pushed. Let's let regular CI done, and then please kick off the extended one @eriknordmark .

CI unit tests failure looks like a transient issue. Maintainer, please rerun.

CI unit tests failure looks like a transient issue. Maintainer, please rerun.

Can you please rebase on top of the current upstream main branch?

Rebased


iframe/video resize issue when loading data with .innerHTML =

Thank you for this seamless and quick media resize module on quill.
I would like to report an issue with not being able to resize iframe/video when using .innerHTML to propagate Quill.
This is what the code looks like after using embed video, and then saving and loading the content:
<iframe class="ql-video" frameborder="0" allowfullscreen="true" src="https://www.youtube.com/embed/xyz?showinfo=0" width="677" height="392" style="float: right;"></iframe>
But the element is not resizable.
I hope this issue report is helpful to find a fix, or do you know of any quick fix to this?
A thousand thank yous in advance,
Jason

Hi @JasonHoku.
Thank you for contacting me, could you provide me more details about the error?
Can't it be resized again using the tools provided by the library or if you are trying to resize it by code?
I would appreciate if you could give me more details of the implementation so I can do my best to give you an answer.

Thank you for your prompt response, @BOTOOM.
Allow me to clarify:
Description of issue:
After embedding a YouTube video iframe, saving and then loading data (I use .html = data to preserve styles which are lost with value = {data}) into Quill, the video iframe element no longer has the resize options provided by this Quill module.
Steps to reproduce:
Add video to Quill
Save Quill data to database
Load data into quill with .html = data
Notice the ability to resize is now gone and video must be re-added if desiring resize.
Hypothesis:
Adding styles to iframe makes quill-resize-module not detect iframe element?
Possibly setting .html = data skips a procedural check for iframe videos by quill-resize-module?
Not exactly sure though.
I hope this helps. Thank you again.

Hello @JasonHoku
I did a test with a nextjs project to recreate the error you are talking about, you can access here the code of the project:
https://github.com/BOTOOM/next_and_quill/blob/9b74059f7d5beb00ef9eb9848d72bdadae92d80d/components/RichTextArea.tsx#L37
this is the rendered result

And even the tools of the library are shown.

Could you provide me how are you implementing the editor, and how are you implementing the innerHTML?

Issue closed for 10 days with no response.


Fix types of declared ExtensionDtypes

[x] Closes #315
[x] Tests added:

test_api_types.py:check_extension_dtypes()

Had to add NumericDtype, Float32Dtype, Float64Dtype, and just make them classes with appropriate super-types, but didn't define methods for them.  Not sure that is really needed from a user type checking perspective.

Thanks @Dr-Irv


Update config file to new format

This retains backwards compatibility, but I honestly hope that you're not still using nginx ≤ 1.9 at this point.

Going to just close this because I created clarfon/nginx-uaparser-module to replace this with a more modern version.


Nerdfont Bug

This doesn't look right.....
using the Firacode Mono Nerd Font i found on the nerd font page you linked in the install.md

I have the same (or a similar) problem with Nerd Fonts' Hack.  On my machine, it looks even weirder.  I get Asian characters instead of the weather symbols and tofu for the greeting emojis.

Hey @SevenChords,
Can you give further inside about the os you are using? From the crab emoji, my first guess would be you are using mac but just to be sure.
Trying to give some first aid: The line characters in the graph are not provided by nerd fonts. Your terminal draws them from a unicode symbol font that needs to be installed as well. It's also listed in the in the install.md.
To give an alternative without installing anything: the necessary characters for another graph style setting might already be available on your system.

On all platforms tested this came down to missing fonts. I think the best solution is that I provide better installation and dependency instructions.
INSTALL.md was extended.
Please reach out again if there are further problems.


[BUG] WillPopScope result is always ignored.

https://github.com/jonataslaw/getx/blob/6c2ff16818a3f8442a25925480df5d24b1b70163/lib/get_navigation/src/routes/get_router_delegate.dart#L808
Hi, can you fix it please?
If this line returns false, the application will be closed.
But when we change this to super.popRoute(), the application will start working with willpopscope.
 @override
  Future<bool> popRoute({
    Object? result,
    PopMode? popMode,
  }) async {
    //Returning false will cause the entire app to be popped.
    final wasPopup = await handlePopupRoutes(result: result);
    if (wasPopup) return true;

    if (_canPop(popMode ?? backButtonPopMode)) {
      await _pop(popMode ?? backButtonPopMode, result);
      notifyListeners();
      return true;
    }

    return super.popRoute();
  }

related
https://github.com/jonataslaw/getx/issues/2381


support for reading csvs from a stream

The cli supports reading csv data from stdin, I'm wondering if there's similar support for reading from a node js stream to avoid having to write a csv file to disk first?

I'm assuming you'd have to do something similar to the httpfs extension and override the OpenFile method?

Another approach to avoid having to write more C++ would be to use the httpfs extension and actually start a server during the import process and pipe your csv stream to the response stream. This works, but feels a bit hacky. See this example using the fast-csv library.
const duckdb = require("duckdb");
const {format} = require("@fast-csv/format");
const db = new duckdb.Database(":memory:");
const {createServer} = require("http");
const con = db.connect();

con.run(`CREATE TABLE product (name VARCHAR);`);

const server = createServer((req, res) => {
  const csvStream = format({
    delimiter: ",",
    headers: ["name"],
  });
  if (req.method === "HEAD") {
    res.writeHead(200, {});
    res.end();
    return;
  }
  if (req.url === "/csv") {
    res.writeHead(200, {"Content-Type": "text/csv"});
    req.pipe(res);
    csvStream.pipe(res);
    csvStream.write(["test"]);
    csvStream.end();
  }
});
server.listen(4444);

con.run(
  `
INSERT INTO product (name)
SELECT  name
FROM read_csv('http://localhost:4444/csv', header = true, delim = ',', columns = {
  'name': 'VARCHAR'
})
`,
  (err) => {
    if (err) {
      throw err;
    }
    server.close();
  }
);


many bars in goods section

tool.exe repack --no-redirect
It was repacked normally, but an error occurs in the goods menu.
Many bars are displayed in the "Products" menu.

If I click on any item and then enter it, It doesn't show anything.

I've compressed all the files I've modified.
modi.zip
**add: If I don't modify the image, this bug won't occur!
Thanks!

nvm, The problem was caused by trying to repack all unpacked images.
After erasing the images that don't need to be modified, solved the problem.
I confirmed that it was repacked normally.


fixed appirio-tech/topcoder-app/issues/1175 changed winner lists in l…

fixed appirio-tech/topcoder-app/issues/1175 changed winner lists in links

@shubhendusaurabh this is a hard link to prod, this should use props to get the current environment


Documentation, version 2

I start this thread of discussion before implementing a new version of the documentation. I pushed in a new branch topic/doc-v2 (commit #29bcf0d) an outline that I suggest for the documentation. Please feedback on this proposition.

I suggest that we add the section Labs, just after Tutorials, as we already have them, and keeping them up to date should be easy as you use those to teach classes.

I created a pull request with updates to the outline, as discussed with Nicolas.
I repeat the comment to the pull request here:
I think the doc should be modeled on Eigen's "long tutorial": a series of pages, each covering a topic from the user point of view, with worked examples in the form of short snippets intertwined with the code.
Then the proper tutorials will contain larger in-depth examples.
The technical part, containing implementation details, should be separate.
So, the main user doc in a part I called  "Features". As "List of features" should closely reflect the content of "Features", I removed all content from the former part and put in into the latter.
Also, I moved the math to later in the doc, as discussed

Please now refer to https://github.com/stack-of-tasks/pinocchio/projects/1 for discussing and adding items topic on the re-factorization of the documentation.


create controller tests

verify pages rendered on index and show methods for users and posts controllers

Added the suggested test. Kindly explain why is it needed since documentation on this page
https://rspec.info/features/6-0/rspec-rails/controller-specs/render-views/
indicates that checking the response.body is a way to evaluate the correctness of the template used.
Thanks


webui: simplify expert-mode tools

I'd like to propose the following tweaks to the existing UI, in order to simplify and focus on the rule match content. This should also enable the removal of some code/maintenance.
Remove "Toggle All" button, since only a single row should be expanded at any point in time:

Remove (or hide display behind global preferences dialog) the column filter inputs with preference for global search:

Always show the columns (rule, namespace, ATT&CK, MBC) and remove configurability:

remove columns "Address" and "Source"

Good point that we'll need a few more links. I wonder if a dropdown of links is appropriate here, or maybe the links can be displayed as a list once an entry is expanded?
I don't like the idea of having lots of extra columns. I could probably be persuaded on icons, though I don't super like how they're be repeated on every line.

Ah neat, I'd like to see the drop-down as a first pass maybe using ... to hide the links.

during our sync today, @s-ff showed how to display a right click menu that may work well for this. he'll explore this, with the backup plan of a dropdown list or entry details element.

during our sync today, @s-ff showed how to display a right click menu that may work well for this. he'll explore this, with the backup plan of a dropdown list or entry details element.

I was able to get this to work, I will implement it now. It should look like:

(correct if I am wrong on the links here)

That looks promising! Can you add icons in there as well (easily)?

And does this prevent copying highlighted text or other functionality via the regular browser right-click menu?

Adding icons should be easy to do, though I received feedback that we should avoid icons as much as possible.

And does this prevent copying highlighted text or other functionality via the regular browser right-click menu?

The default browser right-click won't be available, but selecting, copying and pasting text via CTRL+C works fine.

[X] Context menu right click implemented (only) for rule title and - match: statement.
[X] remove toggle all button
[X] make row click event expand the the rule match
[X] remove table column configurability


v2.6.0

Add Stream::map_while() combinator. (#116)
Add list of excluded features to crate documentation. (#112)

why does this justify a new minor release instead of a patch release? nothing should break if people update to this from the previous version, right?

Adding a new API may break user code.
For example, adding a freestanding function/type may break code that does glob imports, and adding a method may conflict with another trait that has a method of the same name.
See also RFC 1105 for more info about which changes are considered major/minor/patch.

cc @smol-rs/admins


Rayleigh-Benard regression test with forcing and passive tracer

This PR introduces a new regression test (and renames "golden master tests" to "regression tests") based on Rayleigh-Benard convection that adds regression tests for Value boundary conditions, the forcing implementation and the salinity equation, by using salinity as a passive tracer in the test.
The test avoids setting random initial conditions by loading both the initial model state and the comparison state from file.
Note that loading the model state from file required writing a new OutputWriter that outputs and loads the "source terms", G. This implementation is included in test_regression.jl, but it may be worthwhile to integrate it into output_writers.jl at some point.
The test runs on the CPU and GPU. However, similar to the thermal bubble tests, this test fails on the GPU.
This PR also adds a file to sandbox to aid running and exploring solutions to Rayleigh-Benard and also demonstrates the user-specification of a forcing term.

Note: I discovered a bug in the specification of the 'model configuration' (the viscosity and diffusivity coefficients were swapped). This bug does not affect the other regression tests or dynamics tests (which assume equal viscosities and diffusivities), but it does affect this regression test.

#241 should be merged first. Then we will merge those changes here, and update the regression tests.

I've merged in the fixed Model constructor and updated the regression test. This PR is now ready to merge, after #241 is merged.
The bug that is fixed by #241 reveals that the different viscous and diffusive coefficients is an additional feature of this test.
It also suggests that in the future we should make sure to test as many features (as possible) in individual regression tests.

Awesome! Good to have another test and a JLD output writer.
In light of #242 and #238, might be good to first figure out why the GPU golden master test fails for the thermal bubble test and fixing that before we merge this PR.
Out of curiousity, why the "golden master" -> "regression" name change?

I changed the name because I believe that "golden master" is misleading: as far as I know, a "golden master" test is one in which the output of the model matches some externally verified result (eg, an MITgcm solution, or a numerical solution reported in the literature).
In other words, a "golden master" in our case is another numerical model that we (arbitrarily) deem to be a master.
These tests are not "golden master" tests in that sense. Instead, they test whether the output of the model has "regressed" (changed relative to prior output).
Basically, we should not be committing "updates" to a golden master test, because the golden master is... the golden master. However, we do have to update the regression test data when we find bugs in Oceananigans.
Make sense?
It would be nice to have golden master tests, too. Our best hope for this are tests that use a turbulence closure, since there are many published results for "low-resolution" solutions using common turbulence closures like Constant Smagorinsky. Unfortunately, we do not support the boundary conditions that the majority of published results use at low-resolution (either triply-periodic, or vertically-bounded with a 'wall model').

I don't see the reason for waiting to merge this PR before fixing the GPU issue. This is a perfectly valid regression test; CPU tests pass using the output generated by the CPU, and the regression test itself is independent of the GPU issues. When the GPU solver is fixed, the GPU tests should pass for both thermal bubble and Rayleigh-Benard. It is nice that this test demonstrates consistent behavior with thermal bubble, as well.
I think #242 is a good reason to merge this test. This test further closes the gap between CPU and GPU tests.
It should actually be useful to have these tests in place for fixing the GPU issue, because this regression tests stresses more features than the thermal bubble test.

Note: this PR does not touch the algorithm. It only adds a test.
Also note that the major component that is different between the CPU and GPU is the poisson solver, and the poisson solver functionality is untouched by both #241 and this PR.

That makes sense. I didn't realize the difference between a "golden master" and a "regression" test. I wouldn't call the output we produce right now to be "golden master" level.
As for merging this PR, I'm working on figuring out why the thermal bubble regression test fails on the GPU on the fix-gpu-gm branch. Hopefully it'll be something trivial. I'm thinking it's good to tackle one small problem at a time, and I'm more familiar with the thermal bubble test. The two regression tests may be failing for different reasons.

That makes sense. I didn't realize the difference between a "golden master" and a "regression" test. I wouldn't call the output we produce right now to be "golden master" level.

That's just how I'm defining it.

The two regression tests may be failing for different reasons.

I don't understand your argument. This PR introduces a test --- it does not change the functionality of the code. If you merge these changes, you may find that once you resolve whatever issue the GPU solver has that both tests pass (and you can move on with your life). This will save you some work and time with zero risk of negative consequences.

The thermal bubble regression test works on the GPU again (i.e. CPU and GPU output match).
Pretty sure the Rayleigh-Benard GPU regression test will pass now, so probably good to merge after #243.

On another note, the deep convection regression test is disabled right now as it's waiting for a truly portable random number generator #219 but maybe a better approach is to just save the initial condition to disk like you did here.

You should merge this before #243.

Ah right, that makes more sense.


CreateSwapchain failure with Oculus OpenXR Runtime (Quest/Link)

Symptoms are from a compile-run of the default app from a fresh NuGet install of StereoKit 0.2 in Visual Studio 2019.
Command window log is:
[SK info] xrCreateSwapchain failed [XR_ERROR_VALIDATION_FAILURE]
[SK error] Couldn't create OpenXR view swapchains!
[SK warning] Couldn't create StereoKit in MixedReality mode!
[SK info] Runtime falling back to Flatscreen
I presume the failure occurs at line 282 of "openxr_view.cpp"
In the headset, some things are initialized before the failure. Even after the failure, the controllers are tracked, hand avatars appear and respond to finger movements, a shaded floor and ceiling appear, and a curved panel appears with the text "Dotnet loading...".
A window does appear on the desktop monitor with the expected cube, and interactions using the desktop mouse work as expected.
Graphics card: Nvidia GTX1070, with current driver release and a fresh install of Oculus runtime.

Thanks for reaching out! Could you tell me which version of Oculus you're using? This looks a lot like what you'd see in Oculus versions 16 and earlier. You may need to be on the beta channel to get access to 17, which introduced the necessary features for StereoKit to run!
If that's not it, could you set Log.Filter = LogLevel.Diagnostic, and see what else comes up?

Your guess was correct. After install of Oculus PC Runtime v17 Beta, all is A-OK. Thanks!
The update process on the Oculus end was not exactly seamless and eventually required resets of both the WinPC and the Quest before things started working.
Should we close this issue or leave it up for a while to as a signpost for others?  Alternately, is there a FAQ or some other forum where such info should live?
BTW, Guy Godin has tweeted an aspiration to support OpenXR in (the sideloaded version of) Virtual Desktop.  Given his impressive productivity, perhaps there will be a useful tetherless option for StereoKit-PC/Quest fairly soon.
Are you interested in possible mission creep to include native StereoKit support for Oculus Mobile?

Just added a note about v17 to the started guide, so we can close this here :) Shouldn't need it up for long, Oculus looks like they do updates on a monthly schedule!
I'm absolutely interested in supporting Quest as a standalone platform! And that's actually my primary focus for v0.3 :) I've been doing a bunch of code related to OpenGL/Vulkan to feel out exactly how I want to do it. Since that would be opening up platform support for Android, it's entriely possible for me to broaden the scope of that a bit to hit Linux, and longer term, possibly WASM/WebXR as well!
So v0.3 will definitely have Quest support! But it's definitely a pile of work!

Also, if you have a suggestion for where content and tips should live, outside of the docs, I'd be super curious! Right now, StereoKit has a small channel on the HoloDeveloper's slack, but that's not exactly long-term persistent, or easily searchable. A forum sounds tempting, but is perhaps overkill? Github issues is actually decently searchable/discoverable, but is very specifically a assistance format. Not sure what other people are doing these days :)

Impressive roadmap.
Have you considered bringing in a wgpu dependency as a render backend? Perhaps that could cover a bunch of issues at once - DX12, Vulkan, and Metal support, along with a partly-to-mostly paved path to future WGPU/WebXR support.

I had actually been looking pretty hard at GLES lately. I thought WebGPU was a little too early to get onboard with, but you made me pretty curious! Aaaand it looks like it's a fair bit further along than I thought, including emscripten support!
I'll definitely be reconsidering that then :) Thanks for bringing that up!

In my limited testing, wgpu seems almost ready for prime time. Also, Mozilla and Google are working toward common native C API's for wgpu and Google's Dawn:
https://dawn.googlesource.com/dawn

Ok, Dawn looks pretty sweet at a casual glance! I will -definitely- be taking that for a spin!


Added action.yml and pack.sh

This Github Action adds several tools needed to work with Pack and Buildpacks, including:

pack
jq
yj
crane

Github only allows one action.yml per repo, so we might want to move this to a setup-pack repo. That way we could add other actions later on.
Minimal usage of this would look like:
name: Buildpackage
on:
    release:
        types:
            - published
jobs:
    create-package:
        name: Create Package
        runs-on:
            - ubuntu-latest
        steps:
            - id: checkout
              name: Checkout code
              uses: actions/checkout@v2
            - if: ${{ github.event_name != 'pull_request' || ! github.event.pull_request.head.repo.fork }}
              name: Login to GitHub Package Registry
              uses: docker/login-action@v1
              with:
                registry: ghcr.io
                username: ${{ github.repository_owner }}
                password: ${{ secrets.GHCR_TOKEN }}
            - id: pack
              name: Setup Pack CLI
              uses: buildpacks/github-actions@pack-beta
              with:
                version: "0.14.1"
            - id: package
              name: Package Buildpack
              run: |
                #!/usr/bin/env bash
                set -euo pipefail

                VERSION="$(cat buildpack.toml | yj -t | jq -r .buildpack.version)"
                pack package-buildpack --config package.toml --publish ${PACKAGE}:${VERSION}
              shell: bash
              env:
                PACKAGE: ghcr.io/${{ github.repository_owner }}/buildpacks/jkutner_minecraft

If a user wants to chain this together with the registry action, they would do something like:
jobs:
// ...
            - id: package
              name: Package Buildpack
              run: |
                #!/usr/bin/env bash
                set -euo pipefail

                VERSION="$(cat buildpack.toml | yj -t | jq -r .buildpack.version)"
                pack package-buildpack --config package.toml --publish ${PACKAGE}:${VERSION}
                DIGEST="$(crane digest ${PACKAGE}:${VERSION})"

                echo "::set-output name=version::$VERSION"
                echo "::set-output name=digest::$DIGEST"
              shell: bash
              env:
                PACKAGE: ghcr.io/${{ github.repository_owner }}/buildpacks/jkutner_minecraft
            - id: register
              name: Register Buildpack
              uses: docker://ghcr.io/buildpacks/actions/registry:main
              with:
                token:   ${{ secrets.PUBLIC_REPO_TOKEN }}
                id:      jkutner/minecraft
                version: ${{ steps.package.outputs.version }}
                address: ghcr.io/jkutner/buildpacks/minecraft@${{ steps.package.outputs.digest }}

Also, while I understand the need for a "Setup Pack CLI" kind of action (and would approve an action with that name moved down a level) wouldn't users be well served, by a more complete solution?
steps:
- id: checkout
  name: Checkout code
  uses: actions/checkout@v2
- if: ${{ github.event_name != 'pull_request' || ! github.event.pull_request.head.repo.fork }}
  name: Login to GitHub Package Registry
  uses: docker/login-action@v1
  with:
    registry: ghcr.io
    username: ${{ github.repository_owner }}
    password: ${{ secrets.GHCR_TOKEN }}
- id:   info
  uses: ghcr.io/buildpacks/actions/buildpack-info
- id:   package
  uses: ghcr.io/buildpacks/actions/package-buildpack
  with:
    pack_version:  "0.14.1"      # Optional override of baked in version
    configuration: package.toml  # Optional defaulting to local pack.toml if it exists, or synthesized one-liner if it doesn't
    package:       ghcr.io/${{ github.repository_owner }}/buildpacks/jkutner_minecraft:${{ steps.info.outputs.version }}
    publish:       true
- uses: docker://ghcr.io/buildpacks/actions/registry:main
  with:
    token:   ${{ secrets.PUBLIC_REPO_TOKEN }}
    id:      jkutner/minecraft
    version: ${{ steps.info.outputs.version }}
    address: ghcr.io/${{ github.repository_owner }}/buildpacks/minecraft@${{ steps.package.outputs.digest }}

@nebhale that's the route I went originally: https://github.com/buildpacks/github-actions/pull/2
However, I don't think it won't work unless you do both:

pass your GHCR token into ghcr.io/buildpacks/actions/package-buildpack
have ghcr.io/buildpacks/actions/package-buildpack do all the docker login steps

When I was testing it out, I could get the docker/login-action@v1 setup to carry over.
If we can get that to work, I would definitely prefer it.

Interesting.  I agree that we shouldn't ask for the credentials and this is suitable if we can't get login to work across multiple steps.  Let me experiment.

  I've had three different goes at this, and there's just no way around it.  I believe that the restriction is, regardless of what style of action you create, none of them have access to the job's work directory except to write new things to it.  I kind of understand the security of it, but its certainly makes composition of actions difficult.  I'll review this in the context of  a setup-pack action.

@nebhale bummer. but it's nice that it's in setup-pack/ (i didn't realize you could do that). All things considered, I think this is good. Thanks for refactoring and adding docs.


SuccessMessageMixin is missing

Hi,
As a request, I was hoping that django.contrib.messages.views.SuccessMessageMixin could be included as well. I think it's a valuable addition to mention, since it's designed to be used in combination with form views.

Super on board with this but the navbar is already straining under the weight of Generic + Auth, so adding Messages will definitely break the current navbar design. So yes we should do it, but it'll probably necessitate that little redesign rather than just being the one line of code it should be.
Maybe keeping everything from Generic in the top level but then grouping all contrib modules together under a Contrib (or "Other" or "More") dropdown is the way to go.

Fully agreed :-) making a "contrib" dropdown menu would definitely help here.

Shouldn't this just go under the mixin menu?

That mixin dropdown (and the views one next to it) is for auth, not generally.
As it is, the menus are organised by source (most of them are from Generic, those two are from Auth). Note that, for example, the form mixins are under Edit as that's where they're from: they're not under Mixins as that's just the auth.mixins module.

So no, without a redesign of the menus, it's not just a case of putting this under that

I've opened #208 to track the need for improved navigation.


How do I get 3.1.0 back?

This new release completely changes the colour of everything, and at first glance I thought I left a quote off the end of a string or something. Even automatic variables have no colour consistency between them:

Do you have an offline download as all I can see is one single release for 4.0.0...

You can download any commit from GitHub with github.com/{user}/{repo}/archive/{refspec}.zip. Rename the zip to PowerShell.sublime-package and put it in Sublime Text's "Installed Packages" folder.

Naah. Need to unpack it as they contain an additional level of folders, which might cause issues.

Thanks for this, I actually managed to recover a cached copy from another machine I had. Placed it in and changed the NTFS permissions to prevent deletion or writing to the file 🥳. Merry Christmas!


PartitionKeyDelete: Add API to delete all items in a partition key

V3 SDK changes for PKDeletePurger
Description

Added DeleteItemsInPartitionKeyAsync API
Added PartitionKeyDeleteThroughputFraction to ContainerProperties
Changes in GetStoreProxy in DocumentClient.cs, GetHttpMethod in RequestInvokerHandler.cs, PrepareRequestMessageAsync in GatewayStoreClient.cs for GatewayMode of PkDeletePurger to work.

class Container
{
        /// <summary>
        /// Deletes all items in the Container with the specified <see cref="PartitionKey"/> value.
        /// </summary>
        /// <param name="partitionKey">The <see cref="PartitionKey"/> of the items to be deleted.</param>
        /// <param name="requestOptions">(Optional) The options for the Partition Key Delete request.</param>
        /// <param name="cancellationToken">(Optional) <see cref="CancellationToken"/> representing request cancellation.</param>
        /// <returns>
        /// A <see cref="Task"/> containing a <see cref="ResponseMessage"/> which wraps a <see cref="Stream"/>.
        /// </returns>
        public abstract Task<ResponseMessage> DeleteAllItemsByPartitionKeyAsync(
               Cosmos.PartitionKey partitionKey,
               ItemRequestOptions requestOptions = null,
               CancellationToken cancellationToken = default(CancellationToken));
}

class ContainerProperties
{
        /// <summary>
        /// Gets or sets the PartitionKeyDeleteThroughputFraction for the container.
        /// </summary>
        /// <para>
        /// This specifies the maximum fraction of container( or database) throughput that can be used for document deletes initiated in the background in response to DeleteAllItemsByPartitionKey operation.
        /// The request units consumed for deletion of documents will always be within the RU limits determined using PartitionkeyDeleteThroughputFraction.
        /// In the absence of background document deletes, the whole container (or database) throughput is available for use by other operations.
        /// If not set, the default value is considered to be 1.0, meaning the whole user throughput can be used for background document deletes.
        /// </para>
        [JsonProperty(PropertyName = Constants.Properties.PartitionKeyDeleteThroughputFraction, NullValueHandling = NullValueHandling.Ignore)]
        public double? PartitionKeyDeleteThroughputFraction{ get; set; }
}

Implement contract for encryption-container also.

Review meeting notes:

[X] DeleteAllItemsByPartitionKeyAsync : LongName vs clear name

Stream vs generic semantics: Generic API, throw exceptions for 503 etc...
Future proof: Bulk delete API (for latency sensitive) [NOT BLOCKER]

[X] ItemReqesutOptions applicability: SessionToken? (Not a goal)
Closure

Explicit in docs etc...
Remove from contract

[ ] Sync vs async semantics and user interpretations
[X] Fraction vs percentage vs exact RU's: ??? (AutoScale impact ??)

AutoScale expectations: Use the MAX RU for fractions (Implementation)
Exact RU's (not in scope)
Code doc reference to metrics for monitoring (MUST)
Code doc explicit on RUs returned is not the full RU's for async deletion.

Is ZERO better alternative? (i.e. don't return RU charges) +1

Optional: If not then full RU's are used (throttling TSG guide??)

100% default impacts availability, explicit in the code docs

[ ] ChangeFeed expectations call out explicitly [Closure from PM/Mark]

CF expectations: immediately vs future/deferred?
For deferred: Do context cover when delete was accepted
IMP: notification ASAP when delete accepted -> won't it lead to ambiguity??
Only have single event with deleted PK entry

Is CF now forced to be stateful ??

[ ] PITR compatibility
[ ] Analytical store consistency (document explicitly)
[ ] Materialized views impact

From Deborah (offline)
For server-less, where there is no concept of provisioned throughput, will setting the container percentage/fraction be ignored? Or rejected
If user has long running request to delete items, and new ones are writen during that time, do they also get deleted immediately? Or is the partition key deletion of a snapshot at the time the request was issued?


How do I install/use this?

The IntelliJ Ultimate 14 plugin manager does not recognize this as a plugin, and there are no instructions in the readme.

Sorry for a little promo, but got working prototype: https://github.com/hurricup/Perl5-IDEA
So if anyone still want to participate.


[WFCORE-623] add missing methods to ModelControllerClient.Factory

Core - Full Integration Build 719 is now running using a merge of 4425d844a06671013133ace620dd97a9604575a7

Windows Build 1116 is now running using a merge of 4425d844a06671013133ace620dd97a9604575a7

Linux Build 1457 is now running using a merge of 4425d844a06671013133ace620dd97a9604575a7

Windows Build 1116 outcome was SUCCESS using a merge of 4425d844a06671013133ace620dd97a9604575a7
Summary: Tests passed: 3076, ignored: 65 Build time: 0:19:00

Linux Build 1457 outcome was SUCCESS using a merge of 4425d844a06671013133ace620dd97a9604575a7
Summary: Tests passed: 3076, ignored: 65 Build time: 0:19:10

Core - Full Integration Build 719 outcome was SUCCESS using a merge of 4425d844a06671013133ace620dd97a9604575a7
Summary: Tests passed: 2838, ignored: 416 Build time: 0:54:53

Instead of adding more overloaded methods, I'd rather deprecate a bunch of the existing variants and refer people to public static ModelControllerClient create(final ModelControllerClientConfiguration configuration) and ModelControllerClientConfiguration.Builder.

Having a builder is certainly preferable, but I believe that these should be added too. The reason is EAP compatibility, as explained in the JIRA.

I see, so the first method you added is actually restoring one that got dropped, which we need for sure. I don't see the need for or like adding the second one, but I don't care enough to argue about it. :)
I've superceded this with #600 though, as I want all these convoluted factory methods deprecated. And then I did some other clean up while adding the @Deprecated stuff.

Thank you, Brian :-) I added the second one purely for symetry, no other reason.


Can't import task with ID via the API

Hello!
I would expect the API to accept IDs in the input data for tasks:
curl -X POST -H Content-Type:application/json http://localhost:8808/api/project/import --data "[{\"id\":42, \"data\":{\"name\": \"test 1\", \"description\": \"y\"}}]"

However, IDs are discarded. Return of that command looks like:
{"columns_to_draw":[],"duration":0.02617335319519043,"files_as_tasks_list":{"selected":true,"type":null},"found_formats":{},"id":1,"new_task_ids":[1],"project":"./media_category","selected_formats":null,"selected_objects":null,"show_files_as_tasks_list":null,"task_preview":[{"description":"y","name":"test 1"}],"total_completions":0,"total_predictions":0,"total_tasks":1}

It would be useful to keep IDs stable when posting the same tasks multiple times.
thanks!

@sylvinus Hello! It's better to use PATCH api/tasks/id for this purpose.

Ah right, I hadn't seen that one. Feel free to close this if you don't want to implement (I guess the benefit would be to allow bulk-posting)

@sylvinus we are working on new backend, so we definitely won't implement this.


[blog] Adding Introducing Slack Integration for Hue blog post

What changes were proposed in this pull request?

Blog post for v1 Slack App

To-Do

Update image links after all the image are uploaded to CDN
Update security section with example (after discussion)

ok so put 6 please!
On Fri, Apr 16, 2021 at 6:04 AM Harsh Gupta @.***>
wrote:

@Harshg999 commented on this pull request.
In
docs/gethue/content/en/posts/2021-04-09-collaborate-on-your-sql-queries-and-results-directly-within-slack.md
https://github.com/cloudera/hue/pull/1992#discussion_r614820513:

+In the follow-ups, promoting the Share to Slack from the Hue side where users can select the channel to send the link.
+
+Also stay tuned for more such functionalities such as replying to users asking questions on how to find certain data tables or to query them and also send results for scheduled queries in certain Slack channels!
+
+### Try it out!
+
+Get your hands on this beta feature by:
+
+Running some queries on the demo live instance.
+
+Joining the demo Slack workspace to see the app in action or by using the following demo Slack account credentials to share some query links in the demo workspace.
+
+```
+Slack account email: @.***
+Slack account password: demohuedemo
why no just demo?
Min. 6 character password required for Slack account
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cloudera/hue/pull/1992#discussion_r614820513, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAEMGMTVVDEFR3VZ5K3QQ3TJAYUHANCNFSM42UX5TVA
.


Support Copy Command

Are you going to be adding support for vertica's copy command like you did in your ruby implantation?

No, I will not work on this myself, because I don't work in either Javascript software, not Vertica infrastructure anymore.
I'll gladly accept PRs though.

Ok I will look into seeing if I can find some time into making a pull request, as i might need this for a project I am working on.


Map

#98 This probably isn't in the correct part of the website, but here is a map.  Let me know where a better place for it would be (if you still want a map).

Closing this one.  Going to put it in a separate file.


fix a bug for the Broyden's method

Based on @ayamada224 san's report about out of array access, I fix a bug for the Broyden's method. @ayamada224 san and @uemoto1 san, could one of you two check this PR?

Thank you @mn2007 san, I will check your PR.

@mn2007 san, I confirm that the problem in the Broyden of GS calculation seems to be resolved.