Is this still supported?

Hello @pelikhan  ,
I've been working on trying to get the demo template working with MakeCode but have been unable to do so without it crashing. The issue appears to be related to how the iframe is sandboxed in MakeCode. This template utilizes forms, but MakeCode's iframe does not appear to allow for form submissions. I've done some quick edits to remove the forms and use standard html buttons, and that works locally but does not work with the online MakeCode editor.
Before diving deeper into the template's code and doing further testing, I wanted to make sure if the features in this iframe extension are still supported by the MakeCode editor (transferring Serial communication, reading from and writing to the user's code).

I am afraid this kind of extension is not supported for 3rd party anymore so your extension will not load in the online editor.

From: Michael Schneider<EMAIL_ADDRESS>Sent: Thursday, March 11, 2021 5:14:25 AM
To: microsoft/pxt-react-extension-template<EMAIL_ADDRESS>Cc: Peli de Halleux<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: [microsoft/pxt-react-extension-template] Is this still supported? (#2)
Hello @pelikhanhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpelikhan&data=04|01|jhalleux%40microsoft.com|3f988a03ef9f4052417008d8e4442854|72f988bf86f141af91ab2d7cd011db47|1|0|637510328680076561|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=dHKI9A0wyujavG3rnhw5Zo6KOA8Bt%2FrIMIfp3jqlCbU%3D&reserved=0 ,
I've been working on trying to get the demo template working with MakeCode but have been unable to do so without it crashing. The issue appears to be related to how the iframe is sandboxed in MakeCode. This template utilizes forms, but MakeCode's iframe does not appear to allow for form submissions. I've done some quick edits to remove the forms and use standard html buttons, and that works locally but does not work with the online MakeCode editor.
Before diving deeper into the template's code and doing further testing, I wanted to make sure if the features in this iframe extension are still supported by the MakeCode editor (transferring Serial communication, reading from and writing to the user's code).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fpxt-react-extension-template%2Fissues%2F2&data=04|01|jhalleux%40microsoft.com|3f988a03ef9f4052417008d8e4442854|72f988bf86f141af91ab2d7cd011db47|1|0|637510328680076561|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=Vfrz4TrOxwluS7jIzJlNV4wgVXi9E5eTt%2F0HldVo74c%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAA73QKOJKTENA4O7I43A5U3TDAYRDANCNFSM4Y7O76VA&data=04|01|jhalleux%40microsoft.com|3f988a03ef9f4052417008d8e4442854|72f988bf86f141af91ab2d7cd011db47|1|0|637510328680086553|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=lRxr%2BzFN11iQ5eU9DGYNLeIzlm72Xtsp8ov5%2Flcw3kM%3D&reserved=0.

Thanks for the quick response. Are there other options for incorporating 3rd party UI's into MakeCode?  Or is this not a route MakeCode is looking at supporting at all?

I am afraid this is not planned for now. I would recommend posting on forum.MakeCode.com about it.

From: Michael Schneider<EMAIL_ADDRESS>Sent: Thursday, March 11, 2021 7:56:51 AM
To: microsoft/pxt-react-extension-template<EMAIL_ADDRESS>Cc: Peli de Halleux<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [microsoft/pxt-react-extension-template] Is this still supported? (#2)
Thanks for the quick response. Are there other options for incorporating 3rd party UI's into MakeCode? Or is this not a route MakeCode is looking at supporting at all?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fpxt-react-extension-template%2Fissues%2F2%23issuecomment-796509313&data=04|01|jhalleux%40microsoft.com|8cf6ba991bdf431742a408d8e45ad9cc|72f988bf86f141af91ab2d7cd011db47|1|0|637510426166284292|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=RK%2F2DGC8JFXKIeD2oNrklsqmerTc5Zh4To63Pq7ynuQ%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAA73QKN46SBRHT5ZQTZNWELTDBLSHANCNFSM4Y7O76VA&data=04|01|jhalleux%40microsoft.com|8cf6ba991bdf431742a408d8e45ad9cc|72f988bf86f141af91ab2d7cd011db47|1|0|637510426166294285|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=ZWJnTazdoQxIkQdiSYehaWEfwxzWaKkKvgnoFFkrvSw%3D&reserved=0.

Will do, thanks!


fix: better state managing capabilities

:tada: This PR is included in version 3.2.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Remove RxBlocking from Link Binary With Libraries of Build Phases

RxBlocking is for only testing purpose and it shouldn't be included in as Link Binary of a target may be used for production.

thanks for your contribution!


Update xvw.github.io

I've add my feed, but it is an Atom feed and not an RSS feed, no problem with that ?

Nha it's fine.


Fixed "Open summer of code" Grid View Height Issue

Problem / Issue No.

#398

Describe Problem / Solution

For some reason grid view (Year filter) for small screen was not calculating the height correctly
I was not able to fix it with grid view but i used layout instead

Screenshots
https://github.com/user-attachments/assets/b757a11c-eb16-48c3-a036-51028fbb9c20

@andoriyaprashant


train_gpt.c: Removing the hardcoded GPT2_EOT

Removing the hardcoded GPT2_EOT and using the one from the tokenizer instead

Ah yes I changed the cuda code but not the .c code ty


Documentation fixes

A few commits to fix some documentation issues.

I accidentally started this branch based off of a previous fix so the first commit is in a separate pull request which should be resolved before these.  I don't see a way to remove that bad commit.  Alternatively we can close that pull request and just use this one.  Sorry.


[forward] Fix Optional recipient

this pr fixes 2 thing linked to the fact that recipient is now optional in dpy2:

When a bot sends a message to a dmchannel, its recipient is None, so we fix that by fetching the channel via its id
Ephemeral message sent in response to an interaction don't have a guild since their channel is a DMChannel but its id is one of a GuildChannel, so if we fetch it, we'll get a channel that doesn't have a recipient, the way i fixed that is by discarding the message if its fetched channel isn't a DMChannel

This pr was tested without problems with an account that wasn't the bot owner

Indeed that could make quite a lot of request.
What do you want to assume ? because if we discard the message get_channel returns None, (which is the case for every dm the bot receives (for my small testing)) we won't forward anything or if we don't display the recipient, we'll also forward ephemeral messages that the bot sends via an interaction.
One solution could be to make it toggleable & by default at off, and instead of displaying the user, we display the channel id and add a command to easily fetch the recipient from the channel id (but then we would still have the problem of ephemeral messages)

Will take it as is, if it turns out to be problematic then I'll address it then. Thanks for the PR


issues discovered by the all-but-dask CI

After adding the py38-all-but-dask CI in #3919, it discovered a few backend issues:

zarr:

[x] open_zarr with chunks="auto" always tries to chunk, even if dask is not available (fixed in #3919)
[x] ZarrArrayWrapper.__getitem__ incorrectly passes the indexer's tuple attribute to _arrayize_vectorized_indexer (this only happens if dask is not available) (fixed in #3919)
[ ] slice indexers with negative steps get transformed incorrectly if dask is not available

rasterio:

[ ] calling pickle.dumps on a Dataset object returned by open_rasterio fails because a non-serializable lock was used (if dask is installed, a serializable lock is used instead)

Great finds @keewis !
Any idea why a lock is being serialized at all with a Dataset?

I think the lock is used to synchronize the I/O on the rasterio file, so we can't really remove it. The failing test states it is a regression test for #2121, but since then the backend code was rewritten. We'd probably need a serializable lock that does not depend on dask (I don't know much about the backend code, though)

I think the last remaining item has been fixed by https://github.com/pydata/xarray/pull/7586, but not completely sure.
Then we could close this issue :)

I think we'd need to be able to remove this xfail first: https://github.com/pydata/xarray/blob/f8127fc9ad24fe8b41cce9f891ab2c98eb2c679a/xarray/tests/test_backends.py#L712-L714 I didn't check, this could be xpassing right now.


chore(package): update kronos-interceptor to version 2.5.0

Codecov Report

Merging #144 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #144   +/-   ##
=======================================
  Coverage   83.16%   83.16%
=======================================
  Files          11       11
  Lines         594      594
  Branches      181      181
=======================================
  Hits          494      494
  Misses        100      100

Continue to review full report at Codecov.

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

Coverage remained the same at 78.419% when pulling ebfb088f99138e2a5ae8f692e05da1897523996f on greenkeeper/kronos-interceptor-2.5.0 into acc6d4f7ad56a4c9d5551ff3a86f87fa030e39b4 on master.


proposal: DItch shithub

https://sr.ht

Mailing list workflow
?

https://codeberg.org + External mailing list

Both PR / mailing list workflow
More familiar interface (issues, PRs, ...)
?

Mirrors should be maintained only for package repos

sourcehut would be nice if and when they add orgs.

Orgs are missing, although I think you can currently allow other user accounts write access to individual repos. But if we go with a mailing-list workflow, who pushes commits from the mailing list to the canonical repo?

nack on sourcehut. i don't want to get suddenly banned for dumb reason, which is why i will never have account there. plus, it does not support ipv6 at all. it's shame because even github has partial ipv6 support. and as has already been said, they don't have orgs.
IMHO having mailing lists there is OK, but no more.

So do we go ahead with it?
:+1: Codeberg
:100: Sourcehut
:hankey: Github
ML setup can be decided after this

Why not self-host :)

Why not self-host :)

uptime
discoverability
won't be alive in 5 years' time

Can codeberg run "actions"?  I think there is a shellcheck task in repo-community.

Should we consider instead offloading the checks to the local user instead? We can distribute the check as a hook which git will run whenever the correct action takes place. If the check fails it could even probably stop the action.
This way we don't have to worry about the infra supported by wherever we move.

Can codeberg run "actions"? I think there is a shellcheck task in repo-community.

It has woodpecker CI but it's not openly available - you just have to ask them to grant you access https://codeberg.org/Codeberg-CI/request-access

https://codeberg.org/kiss-community/


Clarify sentence

This PR improves the existing sentence for clarity.

That does read better.
/lgtm

Hi @network-charles , considering our  Trivial changes policy ,  please check this page for other improvements so that more changes can be added.

Ah, I see, @Ritikaa96. Thanks, I'll review other parts of the document.


Add example of creating and invoking a custom C++ toolchain

Inspired by https://github.com/bazelbuild/bazel/issues/12942.
Staging: https://github.com/gregestren/rules_cc/tree/master/examples/custom_toolchain

CC @katre

@oquenchil only code owners can merge. Could you merge?
Re: the failing presubmit, that's buildifiier's "print: "print()" is a debug function and shouldn't be submitted.". But since this is demo code this is intentional in this case.

This cannot be merged manually. A change is created in Gerrit and then I have to LGTM there. After that, there is a change created internally and that has to be approved again by somebody else. I lgtm'd on Gerrit but it says there is a merge conflict.


file client.ts in /src/interfaces/assistants_web/src/cohere-client/client.ts is broken

What is the issue?
import of CreateUser fails
linter says:
Module '"@/cohere-client"' has no exported member 'CreateUser'.ts(2305)
import CreateUser

These 2 methods are not declared in DefaultService
  public getAgentTasks(agentId: string) {
    return this.cohereService.default.getAgentTasksV1AgentsAgentIdTasksGet({ agentId });
  }

  public getDefaultAgent() {
    return this.cohereService.default.getDefaultAgentV1DefaultAgentGet();
  }

linter says:
Property 'getAgentTasksV1AgentsAgentIdTasksGet' does not exist on type 'DefaultService'. Did you mean 'getAgentByIdV1AgentsAgentIdGet'?ts(2551)
services.gen.ts(1308, 10): 'getAgentByIdV1AgentsAgentIdGet' is declared here.

Additional information
docker compose up doesn't compile

@marc4gov going to take a look this week

@marc4gov I've created #820 to fix this issue

This is now resolved.

Tnx man!


[QUESTION] Include HTTPExceptions in OpenAPI/Swagger that are raised in a dependency

First check

[x] I added a very descriptive title to this issue.
[x] I used the GitHub search to find a similar issue and didn't find it.
[x] I searched the FastAPI documentation, with the integrated search.
[x] I already searched in Google "How to X in FastAPI" and didn't find any information.
[x] I already read and followed all the tutorial in the docs and didn't find an answer.
[x] I already checked if it is not related to FastAPI but to Pydantic.
[x] I already checked if it is not related to FastAPI but to Swagger UI.
[x] I already checked if it is not related to FastAPI but to ReDoc.
[x] After submitting this, I commit to one of:

Read open issues with questions until I find 2 issues where I can help someone and add a comment to help there.
I already hit the "watch" button in this repository to receive notifications and I commit to help at least 2 people that ask questions in the future.
Implement a Pull Request for a confirmed bug.

Example
from fastapi import Depends, FastAPI, Query, HTTPException, status

app = FastAPI()

def dependency(name: str = Query(...)):
    if name == 'test':
        raise HTTPException(status_code=status.HTTP_406_NOT_ACCEPTABLE)
    return name

@app.get(path='/example', responses={"403": {"description": "Forbidden name was used"}})
def example(name: str = Depends(dependency)):

    if name == 'forbidden name':
        raise HTTPException(status_code=status.HTTP_403_FORBIDDEN)

    return name

Description
In our project we use dependencies that are reused in multiple endpoints.
The dependencies can raise exceptions and we would like to be able to see these exceptions documented in OpenAPI/Swagger.
If an exception is raised inside an endpoint (like in example() above) we add the raised exception to OpenAPI with the responses={} in the path operation decorator as described in the documentation.
Is there a way to add a similar responses={} to the dependency?
The only way we found is to manually go through the dependencies in each endpoint (and the dependencies used by the dependencies) and check for raised exceptions.
This seems very complicated and hard to maintain but maybe there is an less repetetive way?
Is it possible to add a responses={} to a whole app or router, so these codes are shown in all routes? (like app=FastAPI( responses={"403": {"description": "foo"}}))
This issue might be related to  #https://github.com/tiangolo/fastapi/issues/1999

Have you tried creating classes for it? Does this work in your case?
from pydantic import BaseModel
from fastapi import FastAPI

class Forbidden(BaseModel):
    description: str

    class Config:
        schema_extra = {
            "example": {"description": "Forbidden name was used."},
        }

app = FastAPI()

@app.get(path='/example', responses={"403": {"model": Forbidden}})
def example(name: str = Depends(dependency)):

    if name == 'forbidden name':
        raise HTTPException(status_code=status.HTTP_403_FORBIDDEN)

    return name


load_from_checkpoint uses default parameters instead of supplied argument (size mismatch)

Bug description
If any of the parameters of a model has a default value, those default values will be used for checking when doing load_from_checkpoint, instead of the arguments provided for the model, resulting in size mismatch.
What version are you seeing the problem on?
v2.0
How to reproduce the bug
import lightning as L
import torch.nn as nn

class a(L.LightningModule):
    def __init__(self, testing=True):
        super(a, self).__init__()
        if testing:
            self.model = nn.Linear(2, 4)
        else:
            self.model = nn.Linear(4, 8)

model = a(False)

trainer = L.Trainer()
trainer.strategy.connect(model)
trainer.save_checkpoint("bugtesting.ckpt")
model.load_from_checkpoint("bugtesting.ckpt") #comment this one and uncomment bottom two for more weird behavior

# model2 = a(False)
# model2.load_from_checkpoint("bugtesting.ckpt") #This should error out, but it doesn't.....

### Error messages and logs

Error messages and logs here please
size mismatch for model.weight: copying a param with shape torch.Size([8, 4]) from checkpoint, the shape in current model is torch.Size([4, 2]).
        size mismatch for model.bias: copying a param with shape torch.Size([8]) from checkpoint, the shape in current model is torch.Size([4]).

### Environment

<details>
  <summary>Current environment</summary>

#- Lightning Component (e.g. Trainer, LightningModule, LightningApp, LightningWork, LightningFlow): LightningModule
#- PyTorch Lightning Version (e.g., 1.5.0): 2.0.9
#- Lightning App Version (e.g., 0.5.2):
#- PyTorch Version (e.g., 2.0): 1.13.1
#- Python version (e.g., 3.9): 3.10.8
#- OS (e.g., Linux): Linux
#- CUDA/cuDNN version:
#- GPU models and configuration:
#- How you installed Lightning(conda, pip, source): pip
#- Running environment of LightningApp (e.g. local, cloud): local

</details>

### More info

Using load_state_dict fixes all of these issues

@B-lanc You are running into this issue here: https://github.com/Lightning-AI/lightning/issues/18169
You are calling load_from_checkpoint on an instance, but this is not the intended use. Change your code to this:
model = a.load_from_checkpoint("bugtesting.ckpt")

The a here is the class (consider following standard practice to name classes with upper case) and the load_from_checkpoint is considered a classmethod.
Docs:https://lightning.ai/docs/pytorch/stable/common/lightning_module.html#load-from-checkpoint

Sorry for the lowercase classname, I just used it for testing this "bug"
I see, thanks for the help! I couldn't find anything about supplying the model arguments into the load_from_checkpoint from the docs.


Add github action for shadow service add-on

Leverage github-action do test for shadow module.
Fix out of date for go.sum.
Move shadow to add-ons directory.

Codecov Report

Merging #102 (fcdf3b8) into main (feffa93) will decrease coverage by 0.03%.
The diff coverage is n/a.

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

@@            Coverage Diff             @@
##             main     #102      +/-   ##
==========================================
- Coverage   79.09%   79.05%   -0.04%
==========================================
  Files          63       63
  Lines        5199     5199
==========================================
- Hits         4112     4110       -2
- Misses        846      849       +3
+ Partials      241      240       -1

Impacted Files
Coverage Δ

.../client/command/meshinstall/controlpanel/deploy.go
50.00% <0.00%> (-1.43%)
:arrow_down:

Continue to review full report at Codecov.

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


Ability to update from within AWS cfct

Is your feature request related to a problem? Please describe.
We have stno (network orchestration) v2.0.0 deployed within Customizations for AWS Control Tower (CfCT) as a custom template, this was deployed by AWS Proserve a few years back, the hub is deployed to one transit account 2 regions (us-west-2,us-east-2).  The spoke is deployed to all accounts in the org to the same 2 regions.  When we tried to upgrade to v3.3.1 through cfct, it would error no matter what we did, we started with the default template and then tried to adjust the template per each error, got passed a few errors but it became an all day event and was not an easy lift.
Describe the feature you'd like
upgrade to v3.3.1+ through cfct without lots of edits to the template.  Documentation about using CfCT as a deployement/update tool as this seemed to be a common Proserve practice at the time.
Additional context
We ended up reverting back to v2.0.0 because we never got passed the point of having to fail forward.  This is a production environment and we don't want to blow it up.

Thanks for bringing this to our attention. CfCT use stack sets to deploy the stacks. It would be great if we can review the errors you observed in the CFN events when deployed via stack sets.
Assumption: These issues are decoupled from Control Tower setup and CfCT. We may be able to set the CFN parameters to avoid specific issues.
If you prefer, you can open a support case to make it easy to share details from the CfCT manifest file and other details.

so it would fail in the step function state machine for cfct in the deploying master account.  the first error we got was related to the ListofCustomCidrBlocks pattern.  it didn't matter if I had spaces or not after the comma it with error either way:
"RetryDeleteFlag": false,
"us-west-2": "Parameter 'ListOfCustomCidrBlocks' must match pattern (^$|^(([0-9]{1,3}\.){3}[0-9]{1,3}\/\d{1,2})(, (([0-9]{1,3}\.){3}[0-9]{1,3}\/\d{1,2}))$)",
"us-east-2": "Parameter 'ListOfCustomCidrBlocks' must match pattern (^$|^(([0-9]{1,3}\.){3}[0-9]{1,3}\/\d{1,2})(, (([0-9]{1,3}\.){3}[0-9]{1,3}\/\d{1,2}))$)",
"OperationStatus": "FAILED"
}
I was able to get past that by commenting out the pattern requirement in the template.  Then it would error at the service catalog app registry:
"us-west-2": "ResourceLogicalId:Application, ResourceType:AWS::ServiceCatalogAppRegistry::Application, ResourceStatusReason:Resource handler returned message: "'%VERSION%' is not a valid value for TagValue - it contains illegal characters (Service: ServiceCatalogAppRegistry, Status Code: 400, Request ID: ***)" (RequestToken: ***, HandlerErrorCode: InvalidRequest).",
"us-east-2": "ResourceLogicalId:Application, ResourceType:AWS::ServiceCatalogAppRegistry::Application, ResourceStatusReason:Resource handler returned message: "'%VERSION%' is not a valid value for TagValue - it contains illegal characters (Service: ServiceCatalogAppRegistry, Status Code: 400, Request ID: ***)" (RequestToken: ***, HandlerErrorCode: InvalidRequest)."
}
I commented that out and then it errored at the ResourceLogicalId:TgwPeeringLambdaFunction:
"OperationStatus": "FAILED",
"us-west-2": "ResourceLogicalId:TgwPeeringLambdaFunction, ResourceType:AWS::Lambda::Function, ResourceStatusReason:Properties validation failed for resource TgwPeeringLambdaFunction with message:\n#/Code/S3Bucket: failed validation constraint for keyword [pattern].",
"us-east-2": "ResourceLogicalId:TgwPeeringLambdaFunction, ResourceType:AWS::Lambda::Function, ResourceStatusReason:Properties validation failed for resource TgwPeeringLambdaFunction with message:\n#/Code/S3Bucket: failed validation constraint for keyword [pattern]."
}
I can open a support case if thats the best way.  The old 2.0.0 template was pretty similar besides the new resources added in the v3.3.1 template.

Hi @randyspainhower,
Thanks for providing details on your experience.
I am not aware of if any customization was made to the STNO stack but it seems that the stack in the GitHub repo is being used to upgrade the version. The reason is that the GitHub stack has %VERSION% and S3Key (use Mapping) and also refers to other variables.
If the stack was customized then you need to use the Build steps to replace the variables with the values you provide.
You will not find these variables in the hub stack template that we host in our managed bucket. Implementation Guide Template Page.
In reference to ListOfCustomCidrBlocks parameter. The implementation guide defines it as required parameter. The reason we don't add default value of <IP_ADDRESS>/1,<IP_ADDRESS>/1 to avoid internet to access APIs by default.

Resolving this issue. Please reopen if you have any questions. Thanks.


Compatibility question

Is there anything similar that also is compatible with arm based SOC macs?

There is Heron for Mac available in the package manager, but, not having access to an ARM based Mac, I've only tested on an Intel based Mac.  Have you tried using it?

I've been using it on an ARM mac. So far, no issues.
However, the version available in the packageManager when searching on an ARM Mac is v0.3.8, whereas on Windows I see the latest (v0.4.1). I'm not sure what your build process is like, but it is it possible that the distribution tag got set to win rather than any at some point?

Unfortunately, the libraries for GDAL are not universal and need to be compiled for each architecture, so it's not a quick change to the distribution tag.
For Heron v.0.3.8, I had grabbed osx-64 dylibs from someone's Unity repo (which I can't find anymore), but they aged quickly and I had focused development on the windows side.  However, I recently figured out how to build GDAL for osx-64 via Conda, so once again I have the most recent GDAL libraries to ship with Heron for Mac.  As a result, v0.4.2 is now available through Rhino's package manager with all the functionality of the latest windows version.  I'm hoping it works on ARM Macs, but if not, I can look into building the libraries for osx-Arm64.  Let me know what you find out.

Thanks for testing this.  It could be an error related to the target architecture for gdal.  A couple of things to check first:

Are you installing Heron from the package manager?
Can you post an example definition that throws this error so I can try to replicate it?

Heron was installed from the package manger. Below should be a minimal reproduction example definition. The choice of SHP doesn't seem to affect whether the component throws, but I've included it for completeness.
Heron Debug M1 Mac 2023-11-27.zip

Heron was installed from the package manger. Below should be a minimal reproduction example definition. The choice of SHP doesn't seem to affect whether the component throws, but I've included it for completeness.
Heron Debug M1 Mac 2023-11-27.zip

Thanks for the test/update! Using that new GHA (copied into the Package Manager folder for Heron) I no longer see the error I described above, but I did see two new errors thrown:

The vector datasource was unreadable by this component. It may not a valid file type for this component or otherwise null/empty.
Solution exception:Object reference not set to an instance of an object

The file path provided to the component is the same as I've used successfully in earlier versions of Heron on a Mac so I'm relatively confident it's not an issue with the path itself or its parsing.
The area of code you mentioned is similar to what I've been looking at while trying to get Heron to build on MacOS Visual Studio. In particular, in HeronConfiguration.cs a number of methods off of ConfigurationBuilder() were throwing because they seemed to depend on some missing packages. I've fixed up those packages and been able to perform a macOS build of Heron over in this branch. With that build, the Import Vector component still throws, but now with:

Solution exception:The type initializer for 'OSGeo.OGROgr' threw an exception.

Currently, attaching to Rhino isn't working on macOS builds, but I hope to address that and do some more useful debugging locally. In the meantime, would you like me to put through my macos-builds branch as a PR?

I think I've now found the reason GdalConfiguration() was exiting early.  I was telling it to look for a file path that does not exist at line 90, so the code would exit at line 108 before getting to set all the GDAL environment folder paths.

                nativePath = Path.Combine(gdalPath, osxPlatform);

This means my previous fix in HeronComponent.cs is unnecessary.  Can you try the attached update to confirm this is true?
Heron v0.4.2 update 2 for Mac.zip
The idea with the osxPlatform subfolder to gdalPath was to emulate the windows approach which comes with the default GdalConfiguration.cs shipped with the GDAL Nuget package.  In this approach, there are x86 and x64 subfolders containing platform specific GDAL-related dlls which are created upon build and which are pointed to when GdalConfiguration() determines the correct architecture.  I was thinking of creating an osx-64 (or osx-arm64 if necessary) subfolder containing all the dylibs which are currently dumped into the Heron root folder to both keep the folder structure clean in Heron releases, but also make it easier to build for multiple architectures from one solution in Visual Studio.
Once I get this cleaner approach working on the cross-platform branch, I can then look into pulling your macos-builds branch.
For reference, I'm building in Visual Studio (2019) for Mac and all GDAL dylibs are coming from a local conda folder on my machine.  I plan to commit these to the cross-platform branch if I can keep them structured as mentioned above.

Thanks for clarifying that and for the providing the updated GHA. I can confirm that using that GHA, everything now seems to work as expected.

I've updated Heron to v<IP_ADDRESS> with this fix on the package manager.


[Bug] Stream load fails when there's no data

Search before asking

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

Version
1.1.0
What's Wrong?
Stream load fails if there's no data to flush.

We could fix this by skip the flush if there's no pending data.
What You Expected?
No failure when there's no input data.
How to Reproduce?
Submit a job with an empty data source and Doris sink.
Anything Else?
No response
Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

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

hello, link3280:

all partitions have no load data is usually an error raised when the data format or partition does not exist.
I simulated the scene without data writing locally, and it can be run.

@JNSimba Thanks for your explanation.
I was writing to a non-partitioned table, of which DDL is like:
CREATE TABLE `tmp_test` (
  `a` text NULL COMMENT "",
  `update_time` datetime NULL COMMENT ""
) ENGINE=OLAP
DUPLICATE KEY(`a`)
COMMENT "OLAP"
DISTRIBUTED BY HASH(`a`) BUCKETS 32
PROPERTIES (
"replication_allocation" = "tag.location.default: 1",
"in_memory" = "false",
"storage_format" = "V2"
);

BTW, the doris cluster's version 0.15.0 (2pc disabled). Would that be related to the error?

I mock a few records in a Kafka topic and submit a Flink job to sink them into a Doris table.
The first checkpoint was good because there're existing data, but the second one fails with all partitions have no load data.
Please see the flink log for details.

Can you provide some sample data sent to the sink operator, let me simulate the test

hello, link3280, thanks for your reply.
Version 0.15 has this problem. In version 0.15, curl streamload an empty file will also report this error, even if all data is filtered out, this error will also occur. But the 1.X version is normal.
In addition, this change is not suitable: if there is no data entry for a long time, it is easy to cause a particularly long http request.
Version 0.15 can use doris-flink-connector-1.0.3 version first
Thanks~

@JNSimba Thanks for your input! Then I'll close the issue and the PR.


Links in README.md not working

one configuration file in JSON format [link not working]
one Extractor is allowed to extract data from a source [link not working]
one Loader is allowed to load data to a destination [link not working]
multiple Transformers that transform data in pipeline. [link not working]

Fixed, thanks.


webFormClientValidate function missing

I'm unable to find the webFormClientValidate() function on a web page that uses Liquid Template and I discovered that it's missing the funcition in AdxStudio.Xrm/Web/UI/WebControls/LiquidServerControl.cs
function webFormClientValidate() {
// Custom client side validation. Method is called by the submit button's onclick event.
// Must return true or false. Returning false will prevent the form from submitting.
return true;
}

What is the impact of the function not being present? Is there an error or is something you're trying to do not working?

The impact is that you cannot do a general client side validation on a WebForm if the page is using a Liquid Template.


Inverted density gradients ...

It turns out that our test case has some regions near the surface where the temperature gradient is inverted and it's causing problems. The image below shows the issue -- close to the surface we get reduced isopycnal slope which sends the adaptive coordinate back into isopycnal mode:

The simple fix for this is to place a condition on vertical density gradient to ensure it never gets below epsilon ...

Err, I think there might be a sign error here. Slope is now set to unity throughout the interior ...

Hmm, that's weird! Maybe try again now with the flipped signs?

Yeah, that's better.

On more thing here. The diagnostic of slope seems to be set to zero in the top layer. Is there a boundary condition set on the vertical gradient of density? It might be best to set that boundary condition to be zero gradient, which should force a finite slope at the surface (and hopefully it will be 1 there)

Just looked at the code re the slope calculation near the surface - it's not clear to me that the k=1 case is computed? Is this because we don't evolve the surface interface or is it an omission?

Just looked at the code re the slope calculation near the surface - it's not clear to me that the k=1 case is computed? Is this because we don't evolve the surface interface or is it an omission?

The former. Regridding is not allowed to change the total column thickness, so k=1 and k=nz+1 must remain as they are.

Aah, OK, so this is only an issue in the non-time stepping version of the pyale code?

I guess the slope is actually calculated along interfaces, so I don't quite know how you would extend that to a layerwise value.

Yeah, I guess my worry here is that there are some latitudes where no interfaces have large slope, which doesn't make sense to me ...


Inactive account

Hi guys, I just reset my password and when I try to log in I get a "This account is inactive". How can I get it set as active? :)
I saw this issue you solved in the past: https://github.com/rtfd/readthedocs.org/issues/1451 Just in case it helps :)
My username in readthedocs.org is gtorodelvalle
Thank you very much in advance for your help.

Should be good to go.

Indeed... :) Thank you very much!

Hi, I have exactly the same issue. My username is qiuwch. What should I do to active the account?

hey the same issue, my username is a.wadekar.

Thanks @ajinkyawadekar - can you open a new issue for this, please?


TUI regression

Problem
In main, output from the TUI stays on the terminal after completion. This is different from the behavior on the current stable release, 0.11.8.

On 0.11.8:

$ dagger call -m github.com/shykes/hello hello
hello, world!

On main (3767c8f0b3076a41c218c545c96641080b0e819b):

$ dagger call -m github.com/shykes/hello hello
✔ connect 0.1s
✔ initialize 3.1s
✔ prepare 0.0s
✔ hello: Hello! 0.0s
✔ Hello.hello: String! 0.2s

hello, world!

Solution
Revert the behavior to be the same as 0.11.8.

This was an intentional change. We would frequently get questions that came down to users not knowing about -v, so printing nothing at the end didn't really feel like a sane default to me. I found myself passing -v nearly all the time because running something, tabbing away, and coming back to having no visibility into what actually ran, and having nothing useful in my scrollback after repeated runs, felt pretty frustrating and not in line with the TUI experience from other tools.

OK, it's definitely a fair point to revisit. A heads up would be nice though, this is a known bike shedding hotspot, since nobody brought it up I assumed it was unintentional.

I found myself passing -v nearly all the time because running something, tabbing away, and coming back to having no visibility into what actually ran, and having nothing useful in my scrollback after repeated runs, felt pretty frustrating and not in line with the TUI experience from other tools.

But was that in the context of developing or debugging the engine or TUI itself? As an end user of Dagger, I can't remember ever being in that situation unless the pipeline fails, in which case I do get TUI output. When my pipeline doesn't fail, I find it distracting to have residue from its progress in my terminal. What use case am I missing that lead to people asking for more TUI residue when their pipeline succeeds?

My main concern is that the quiet behavior is a sane default for toy examples like the "hello world" above but is detrimental to the experience of using Dagger "in anger" because it eliminates the return on investment for a slow command (build/test/lint). I've got 10,000 lines of scrollback and only so many hours in a day; I'd rather spend the scrollback than spend time chasing ghosts because ambient information was taken from me to keep the output clean (concrete example for this later).

But was that in the context of developing or debugging the engine or TUI itself?

For me, it's usually in the context of running Dagger's integration tests or lints while developing Dagger. It's the same experience as you would have when testing any other product with Dagger, so I don't think it's disqualified at all by being too meta or too close to the problem - at the end of the day, I'm using Dagger for a project which just happens to be Dagger. This isn't influenced by the TUI itself; it's the other way around, dogfooding influenced the TUI.
Example: if I start a dagger call test --count=100 --run TestFooBar to suss out a flaky test and context-switch, I'd really prefer to come back to something in the output so I can start to rebuild that context. Coming back to an empty terminal makes it hard to even tell where I was, or if I even ran the command, because I have no point of comparison ("last run took 18.9s, oh this one's different"). Also, without even a basic timing breakdown it can be difficult to notice that I actually typoed TestFooBar and the command just took a while to initialize and didn't run any tests at all. This has happened before, and has made me angry.
So, to me, it seems like showing a brief summary by default causes less harm than being silent by default.
I'd still be interested in hearing the perspective of others outside of Dagger though.

Also, still willing to go back on this, don't want to sound like I've got 100% conviction on it, just wanted to outline the case for the change. :smile: Maybe there are other avenues to address the pains I and other users ran into. Either way, it felt like low enough risk to just try changing it based on the feedback so far and iterate. Would rather change it and have folks complain it's too noisy and change it back, than wonder whether the complaints so far represent a vocal minority.

I see. Yeah this boils down to test pipelines not returning anything useful. We're basically attacking that problem from two different angles - output verbosity, test reports - and interfering with each other somewhat. Specifically, the extra verbosity only bothers me when test pipelines print test reports- and the lack of verbosity bothers you when it doesn't 😁

What if we branched on pipeline output?

If pipeline returns something (non-void return value): wipe TUI output, print the return value
If pipeline returns nothing (void return value): don't wipe TUI

That way we keep your fix for test pipelines that return nothing; and we don't get in the way of a great experience for test pipelines that do. Best of both worlds?

That almost does the trick, but we'd also want the progress printed in situations where the CLI automatically calls sync, for example if your test function returns a Container, since that seems like a common pattern for test functions. We also have some expensive APIs that return simple scalar values like File.export and Container.publish which I would still want to see the progress for, but I'm curious if you feel differently about those since they're examples beyond running tests.
Ideally we could define the rules for this within a closed system that's easy to explain, without relying too much on pattern-matching the shape of API calls that tend to be made for the use case we're looking for. I would still have some anxiety that these heuristics apply to tests, but for another user with a different (or even the same) use case the removal of progress ends up feeling like a non sequitur. Maybe they just want to see the go test output at the end but still want to notice any slowness leading up to it.
I think my perspective boils down to "if my pipeline spent a significant enough amount of time on any particular step, I want to know about it, and if it didn't spend enough time when I expected it to, I want to notice that, too."
Right now "significant" is defined as >100ms, and we make an exception for top-level spans and always show them. Maybe there's a path where we adjust these? In the end these are still heuristics, but it feels like a slightly more closed system since it's derived from the value I care about in the first place (time spent) rather than incidental API patterns. If we bumped the threshold to 1 second for the final print for example, your "hello world" above would look a lot cleaner, with the caveat that you'd likely still see 'initialize' or module calls show up if there are occasional slowdowns.
Not really in love with it though. Mostly trying other dialogue trees. :) To be honest I find the output gives me a more solid grasp of what I'm building, so it doesn't bother me.

I don't think a "time elapsed" threshold is a good idea.

if my pipeline spent a significant enough amount of time on any particular step, I want to know about it, and if it didn't spend enough time when I expected it to, I want to notice that, too.

I think that's where Traces comes in. Or, if it takes long enough, the in-progress TUI. By definition the longer it takes, the more time you have to look at the output.
I think between:

Pipelines without a return value always keeping the TUI output (my proposed change)
Very slow pipelines being visible longer in the TUI
Traces being available for free to answer "where is my pipeline spending time and why?"
-v or a new better flag to explicitly always keep the TUI output
Easy to change signature of test function to return void if needed

We would be in a good place.

Test functions that return a container will print the container metadata. You don't want TUI mixed in there, it looks weird.
Test functions that return stdout of the test command, should also only print that. If that output is not useful, change the function signature to return void instead.

Adding rules about command duration overcomplicates things with no obvious benefit. We're talking about a default, it's not like users can't set a flag or change their function signature. Better if the rule for the default is super simple so that it's intuitive to understand when it applies, and how to override it.

Adding my 2 cents :moneybag:

I found myself passing -v nearly all the time because running something

Yup same, and to be honest, I often find myself turning it up even higher sometimes, or putting it into plain mode to try and understand a test run, since the test run itself gets collapsed in the output, so I can't see where the test actually ran.
Tangent: aside from just having the traces link in the output, it would be really interesting if we could replay previous runs from the CLI (or at the very least, just display the whole full explorable trace, since now we have the very cool navigable TUI).

I don't think a "time elapsed" threshold is a good idea.

I think we should keep the current behavior: don't show super short steps, but show all top-level steps. But we should always show the trace, regardless of whether it was fast/short/etc.
This is outside the scope for this issue though, since we've been doing this for a while - pretty much since this progress view was introduced. Potentially, we could do some better filtering and encapsulation/internalizing of various pieces and maybe make having a clean progress less dependent on the time-elapsed threshold.

Test functions that return stdout of the test command, should also only print that.

I don't think we should be altering the behavior of whether to keep the progress summary at the end based on the content of the function, etc - we have command-line verbosity flags to control verbosity, so we should use those. Having progress display sometimes, and not others, depending on return type would be really confusing.

@jedevc so are you arguing to a) keep the current always-verbose default, or b) revert to the 0.11.8 never-verbose default? Or something else?

I think I'd rather keep the current default, where after the run completes we collapse to just the top-level.
Separately, we need to do some cleanup of the top-level.

(trying to be brief, would rather hear more from others, I think after this comment all my thoughts are clarified)

I think that's where Traces comes in. Or, if it takes long enough, the in-progress TUI. By definition the longer it takes, the more time you have to look at the output.

The longer something takes the more likely I am to context-switch and not look at all; when I switch back I would like my scrollback to tell me what happened. I want to use Cloud because I want to, not because I have to; that frustration will spill over and negatively frame my Cloud experience. Juggling a bunch of de-contextualized browser tabs isn't fun when I'm already juggling so many terminals. :face_with_spiral_eyes:

Better if the rule for the default is super simple so that it's intuitive to understand when it applies, and how to override it.

To me, the simplest thing is to just always show the progress summary unless you pass something like -q or -s. I don't want to have to make my API worse (by removing a useful/chainable return value) just to to appease a TUI heuristic.

We're talking about a default, it's not like users can't set a flag or change their function signature. Better if the rule for the default is super simple so that it's intuitive to understand when it applies, and how to override it.

IMO the default should minimize wasted time. I don't see the progress as being "mixed in" with the desired output and I don't see it as "TUI residue" - it's a criticial part of the feedback loop for the tool to inform me how my code ran.

I disagree but don't have the energy to argue over this. Can you please give me a flag + env variable so I can at least revert to the previous behavior for my own use.

For sure:

#7822

Might as well put it to a vote in the meantime:

:rocket: = hide progress on completion, pass -v for verbose (v0.11.x behavior)
:eyes: = keep progress on completion, pass -q to hide it (#7822)

I won't vote (I'll vote both to bootstrap) since the original goal was to adjust to user feedback anyway.

That almost does the trick, but we'd also want the progress printed in situations where the CLI automatically calls sync, for example if your test function returns a Container, since that seems like a common pattern for test functions.

Now dagger call at minimum prints the name of the object if it has no eligible functions to print. Because of this the CLI no longer calls sync implicitly. The object's "fields" are printed instead.
The exception is that export is still implicitly called if you use --output, but that's for compatibility reasons.

We also have some expensive APIs that return simple scalar values like File.export and Container.publish which I would still want to see the progress for, but I'm curious if you feel differently about those since they're examples beyond running tests.

Export now returns the absolute path where it exported too. So both export and publish return something useful.
It's only when a function returns Void that nothing is returned.

Re: the vote, I don't have a strong opinion yet. I've felt annoyed by the lingering output, but I can see the value in leaving it in by default just to understand the times it took on each stage. It could also be a question of building the muscle memory to type -v. I don't know yet which one I'd use more: -v or -q, depending on the default.

Just remembered you can also press +/- at runtime to adjust the verbosity, a feature which was added along with this change(/regression).
So if we bring back the old behavior and you forget to pass -v, you can just press +.
And if we keep it as-is and you forget to pass -q, you can just press -.
Between the two I would argue the previous behavior benefits more from this feature. I always used -v for slower pipelines, so I'd have more time to press + if I forget. But if I forget -q for a faster pipeline, I don't have much time to press - before it pollutes my scrollback. If my math is right, the user benefits in more scenarios from a -q default.
Arguably skipping the flags and just using +/- is better anyway since it keeps dupes out of your shell history. :sweat_smile:
@helderco Yeah, I'm in the same boat really, though the output hasn't annoyed me as much. Maybe we're running different things. My guess is there just isn't a one-size-fits-all; I've found myself using + and - all the time (sometimes as a navigation technique).

May have been more annoyed by the surprise tbh. I wanted to make a screenshot of a command but didn’t want those progress lines. So I added -s to wait for a while without any output and in the end, the progress spitted out like a ghost on Halloween! 😂
Wasn’t even aware or remember -q. Or is that new? 🙂
That progress result didn’t feel useful because my shell already displays the elapsed time on any command, my terminal shows me when a command in history was executed just by Ctrl+R, and I can go to cloud to see how the whole thing progressed.
While it’s running I do use the navigation controls. Love c because I find it more usable to watch the progress in cloud instead of seeing things fly in the terminal.

So I added -s to wait for a while without any output and in the end, the progress spitted out like a ghost on Halloween! 😂
Wasn’t even aware or remember -q. Or is that new? 🙂

Yeah the final print unintentionally ignored -s, which is fixed now, in the same PR that introduced -q (#7822). -q is new, since there's no way to say -v=0. It actually works the same way -v does, only in the opposite direction (you can -qqq for -3).

That progress result didn’t feel useful because my shell already displays the elapsed time on any command, my terminal shows me when a command in history was executed just by Ctrl+R, and I can go to cloud to see how the whole thing progressed.

Totally fair - I think for most commands like dagger develop, init, --help, etc. I'd prefer it to be hidden. I only really had call in mind when making the change. Might be easy to make it per-command. Ultimately we're just summing the default with how many times the user passed -q (-1) or -v (+1), so it would be easy for a command to apply its own delta, too, and user flags would just become relative to that.

After live discussion, we have agreed to keep the new "lingering" behavior. We are leaving the door open to changing it back if users complain.
Also, this raises the bar on readability on the top-level TUI output. Specifically, we should be extra careful to not show top-level spans that are obscure or confusing to the user.


Text rendering issue: Letters with tails (g, j, q, y, etc) appear cut off

Notice how in this screenshot:

the letters that have "tails" (that go below the line) have them cut off, causing "y" to look like "v", "g" to look like "ɑ", etc. Even causes commas to look like periods.
Steps to reproduce: Open any Gemini page with the following configuration
Lagrange version: 1.15.7
OS: MS Windows version 10.0.19044.2728
Machine: Lenovo Thinkpad T490s
Font preferences: Iosevka (compact) with smoothing enabled
This bug appears to affect all pages with MIME type text/gmi regardless of path or domain. Unclear if other types of pages are affected. No idea what version was the first to have this bug but it has been present since I installed Lagrange about a month ago. If any further details are needed please let me know.

This is actually an old text rendering issue (same as #364) where the backgrounds of overlapping text lines erase some of the previously rendered text. The correct fix here would be to first do all the backgrounds of a paragraph and then draw the characters without a background.

I think the original issue has been fixed in 1.18. (The rendering issue I mentioned in the previous comment has not been fixed.) One additional possible cause for the clipped glyphs was that monospace page layout was not accounting for the larger lede paragraph font. Now monospace body text disables the lede paragraph resizing.


For portable packages, should add clean bat to remove all app data

For portable packages, should add clean bat to remove all app data

Add in 0e6bb3c2f5d8f5ccb2fbcc46e78cfbd1c202a6a4


needextract fails - latex builder with multiple latex output

Hi there -- thank you for publishing this amazing plugin.  I am running into trouble with the latex builder.  The following information is redacted from the actual source documents -- I can share more information privately if needed.
I am using sphinx=4.0.2 and sphinxcontrib-needs=0.7.1  In my conf.py, I have
latex_documents = [
   ('srd', 'SRD.tex', 'Software Requirements Document',
    'author', 'manual'),
   ('um', 'UM.tex', 'User\'s Manual',
    'author', 'manual'),
]

I define a need in srd.rst, and then have .. needextract  in both srd.rst and um.rst.
The html builder successfully builds the srd.html and um.html.  The latex builder successfully builds srd.tex but then fails on um.tex, and yields the following error message:
processing SRD.tex... srd
resolving references...
done
writing... done
processing UM.tex... um
resolving references...
failed

Extension error (sphinxcontrib.needs.directives.needextract):
Handler <function process_needextract at 0x7fb162671f80> for event 'doctree-resolved' threw an exception (exception: ('srd', None))

I suspect that the handling of external needs is contributing to this somehow.  I have tried to step through and debug it myself, but I am lost in the listeners.   I hope it is enough to explain the behavior and give a clue on how to fix it?

Thanks for reporting this bug.
I'm not 100% sure, how I can reproduce this error.
Would it be possible for you to setup a small example and upload it to a git repo?
This would help a lot and I can be sure I got your points.
But overall, I'm not an expert in latex and co.
And right now, Sphinx-Needs has no builder specific handling, as all Need-Nodes gets transformed to standard docutils-nodes, so that the later docutils-node-tree does contain standard rst-nodes only.
After that the specific builder starts to translate it to the specific output.
So up to now, everything which has worked for html has never thrown an exception during latex or other builds.
So this bug looks quite strange and I hope I can reproduce and fix it.

I will work to get you this example.  Thank you!

Please see example repo here:  https://github.com/gregegg/needextract_347
Thank you!


Horrible regression:  parametersFor[method name] not being picked up as a provider

I introduced this with PR #60 (sorry!).  Will fix

Thanks for the fix


Update: plex.plexmediaserver version <IP_ADDRESS>05

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?

[x] Does your manifest conform to the 1.0 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Oh, sorry. I have to update my fork.


Add backgroundView property for background image support

add backgroundView property for background image support
resolve an issue with the delegate call

thanks


adding instructions for developers

I'm interested in adding test cases, and running them locally, too.
I created a virtual environment using python3.7, activated it, ran pip install ., then attempted python setup.py test, and it complained about not having configured django.
So I checked how you run tests on travis-ci, and found you use tox.  no clue what it is, but if it works on travis, why not here?  so I installed it and started it.  that was some 15 minutes ago, and my laptop is still running tests, against far too many configurations.  initially it complained about a missing pypy ( ERROR: InterpreterNotFound: pypy ).
I hope that this PR can be a start for somewhat better developers instructions.

Pull Request Test Coverage Report for Build 54

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 51:
0.0%

Covered Lines:
76

Relevant Lines:
76

💛  - Coveralls

Pull Request Test Coverage Report for Build 54

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 51:
0.0%

Covered Lines:
76

Relevant Lines:
76

💛  - Coveralls

Pull Request Test Coverage Report for Build 54

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 51:
0.0%

Covered Lines:
76

Relevant Lines:
76

💛  - Coveralls

Pull Request Test Coverage Report for Build 54

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 51:
0.0%

Covered Lines:
76

Relevant Lines:
76

💛  - Coveralls


python310Packages.pymbolic: 2022.1 -> 2022.2

Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 201741 run on x86_64-linux 1

2 packages failed to build:

python39Packages.loopy
python39Packages.pymbolic

2 packages built:

python310Packages.loopy
python310Packages.pymbolic

https://github.com/inducer/pymbolic/issues/121


Add Hg to the command set for the Shell Mode

Could you elaborate? As it is, I have no idea what you mean.

@marijnh I mean, that it would be nice to have hg be a highlighted command in the shell.js mode

@marijnh Opened PR #4764 to address this

Solved via #4764


How to use the pretrained weight of CoOp for Multi-label Top-K Prediction?

Thanks for sharing the code.
I wish to apply the pretrained weights to the Multi-label prediction task. I would like to input the optimized prompt and 1 picture to the frozen CLIP encoders to get the TOP-K prediction results.
I followed the overview structure picture to code for the task. However, i met some problems in it.
In the pretrained weight, the prompt token [V1][V2]... has a shape of [n_ctx,512]. However, it does not match the normal prompt token with [CLS] (shape of [n_cls,77]), which means it cannot concat directly.
I saw the token_prefix and token_suffix embeddings in the weight file. After concat them with prompt_token, it gives a 3d tensor with the shape [n_cls,n_ctx,512], which does not match the image feature.
So, I would like to know that how to adjust the size of the optimized prompt and [CLASS] token so that it can be used as the input of CLIP's text encoder?
I am looking forward to the reply. Thanks a lot if you could give the help!

Hi, i am happy to tell you that I have solved my problem. The classifier performs well in my task.
Thanks for the job!

Hi, i am happy to tell you that I have solved my problem. The classifier performs well in my task.
Thanks for the job!

Hello, have you apply on NUSWIDE?I want to know how to apply it to NUS-WIDE,thanks!

Hello, have you apply on NUSWIDE?I want to know how to apply it to NUS-WIDE,thanks!

Hi, although i did not apply CoOp on NUSWIDE, but i did try on my own classification dataset.
The overall process is a little complicated. To sum up, Firstly, you need to preprocess the samples in the dataset to combine the image path, the corresponding category name and ID into a file with a format similar to split_zhou_xxxx.json (It can be seen in DATASETS.md ). Secondly, you need to code the DataLoader following the requirement in DASSL. (https://github.com/KaiyangZhou/Dassl.pytorch#add-a-dataset)

Hi~Do you have the original COOP model weights, not the ones for 4/16 shots?


FIXED: The APPROVAL LETTER is not wrapped with the  component

Proposed Changes

Fixes #9324

change 1

Change 2

update into shadcn button

@ohcnetwork/care-fe-code-reviewers
Merge Checklist

[ ] Add specs that demonstrate bug / test a new feature.
[ ] Update product documentation.
[ ] Ensure that UI text is kept in I18n files.
[ ] Prep screenshot or demo video for changelog entry, and attach it to issue.
[ ] Request for Peer Reviews
[ ] Completion of QA

Summary by CodeRabbit

New Features

Enhanced localization support with new key-value pairs for improved user feedback and resource management.
Added a PrintPreview component for better print functionality in the Resource Details view.

Bug Fixes

Improved error handling for unavailable resource data, directing users to a "not-found" page.

Refactor

Updated the ResourceDetails component to utilize translation keys instead of hardcoded strings, enhancing internationalization support.
Replaced outdated button components for a more consistent UI experience.

LGTM


improve execute many

execute many can handle different types now aswell and not only tuples.
This way it does not require the user to create a tuple to bind a single value:
execute_many(db, "INSERT INTO test VALUES (?, ?)",
            1,
            std::make_tuple(2),
            std::make_tuple(3, "three")
        );

currently this means it supports tuples and single values when only one value has to be bound, since these are the only types supported by VariadicBind right now

Coverage remained the same at 96.502% when pulling 83b5a102a637ca842632838264fcad1356b027e4 on maxbachmann:master into a637d247642404ebf9fef0c98d9472d33f4e8435 on SRombauts:master.

fixed #206

@SRombauts it's fixed now. However we should think about changing the name of the bind function to something like sql_bind so it is no name of a standard function anymore in the next major release

Yes please, if you can work on this, it would be nice to improve the naming before I release a new version.

You could open a 3.x branch

Thanks, I have integrated your fix!


Move all dependencies from vendor to node_modules since we're moved to NPM

And, remove gulp get-deps and gulp get-dev-deps

A pair with #427


Fix additional docs links

#584  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @mkandler and the rest of your teammates on  Graphite


superk

Modified Sources.SuperK methods. 1. Added some if statements for checking IP inputs. Deleted redundant code for setting up the GUI for setting laser parameters.

Hey @ponagehl2 , what's the status of the SuperK and this branch? Would be great to merge this in!

Hey @ponagehl2 , just checking in on this. Thanks!


discordgo.Interaction and Context

I think it would make sense that discordgo.Interaction type would carry a context with itself, because according to Discord API docs "Interaction tokens are valid for 15 minutes, meaning you can respond to an interaction within that amount of time."
You could use this context to cancel any long running operations automatically, after this 15 minutes elapsed.
Sure, you can do this yourself outside of the discordgo, but I think it would make sense to put it in the library code.

It's a good idea, but DiscordGo meant to be a low level Discord API wrapper. And this would cause issues with using DiscordGo in HTTP interactions.
The primary question here is where do we put the context initialisation?

Unmarshalling - no, we could unmarshal it multiple times or do it manually in some cases
In gateway - might work but won't with HTTP interactions
NewInteractionCreate - seems a good idea, but again, manual unmarshalling.

Marking the field as "gateway only" might solve the issue, but I'm unsure about this.

Hey folks 👋 I have a slightly different need here: I'm running a Discord app as a long running process, with some database operations. I'm instantiating a new context at the start of my main routine and listening on OS signals (through signal.NotifyContext) I would like to be able to propagate that context down to my database interactions, such that if the server receives the signal to shutdown, that notification can propagate all the way through the database interaction, and cancel the current discord Interaction.
Right now the way I'm doing that is by defining my interaction handlers in a map directly inside my main function such that the closure captures the parent context. My issue here is that, as you might expect, my main function is getting pretty long and unruly. I would like to declare my handlers outside, as standalone functions, but in that case I can't capture the parent context anymore. I could write it as a higher-order function that takes in a context and returns a handler function such that the context is captured in that closure, that would allow me to do the refactor I want, but I'm still not really keen on just capturing values in closures like that.
I would propose adding variants of the handler types that also accept ctx context.Context as their first parameters

Just chiming in - I rely on the golang context to do a bunch of stuff (like distributed tracing), so it would be awesome if the discordgo Interaction exposed the context for this message


sys/freebsd: add POLLINIGNEOF

Please add yourself to AUTHORS/CONTRIBUTORS files in this commit:
https://github.com/google/syzkaller/blob/master/docs/contributing.md#guidelines
and we are ready to go.
Thanks

Seems I didn't read the contributing guidelines careful enough, sorry. Now updated.


Abstract array check into separate function

This PR:

abstracts out the array comparison into a separate function for readability

Merged with e6bbfdcfaa60070ee6d7fd7b4747e22a3c008e81 and 50c660c6867d863c59274fb2379db6937bd14deb.


Update figure numbers in UG

Codecov Report

Merging #214 (4cebf52) into master (7a8971e) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #214   +/-   ##
=========================================
  Coverage     63.97%   63.97%
  Complexity      856      856
=========================================
  Files           126      126
  Lines          3042     3042
  Branches        394      394
=========================================
  Hits           1946     1946
  Misses          962      962
  Partials        134      134

Continue to review full report at Codecov.

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


Reordering of form fields?

How can I reorder the form fields?
Right now, I'm reordering via the DB, but that seems a really not great way to do it once I hit production.

This is a good idea. The simplest way I can think of is having an extra order number attribute added to the field, which you set in the metadata object before passing it to the zenstack-ui config.
itemFields.name.order = 0;
itemFields.description.order = 1;

For the implementation, I can think of 2 options:

Automatically assign an order number to every field based on the current zmodel order to the metadata object. However, if you want to just quickly move some items to the top of the form, you would have to manually re-order (by setting the order attribute value) all of the fields, or use negative values, which can get confusing
By default, the order field is undefined. When a user sets an order number in the metadata object, all fields with order values are prioritized and placed at the top in the order of their order numbers. The ones with undefined order numbers are placed below in the order of the zmodel file.

I think option 2 makes more sense as it is easier to make quick changes without needing to re-order all the fields but let me know what you think, or if you have any other ideas as well. It should be a fairly easy code fix because all I have to do is run a sort on the fields.

I see the advantage of (1) is that it's pretty easy to understand for newcomers as all fields are numbered and have a clear order. The order is already pre-defined, and you can manipulate it how you want. As you say though, reordering a portion means dealing with the whole list which is annoying.
So, since I would probably implement it that way anyway, I think (2) is the best approach. It's flexible and means you can just have a list of known fields and handle them. Then when an unknown (new) field appears it gets put at the end automatically by design.
You could extend it so that in (2) if an order is defined as a negative number for an item, it will always appears after the unknown fields and if it has 0 or a positive order it appears before the unknown fields. And if it has null or undefined it simply appears in the unknown items list (ordered by db).
This gives us maximum flexibility just to shift a couple of fields to the start or end. Or to deal with the whole list if we want.

This is now implemented in v0.0.21! Fields now have an order attribute. Also, a new options object has been implemented with a few settings, one of which is whether the ordered fields go first or last compared to the unordered fields.
// Ordering example
itemFields.name.order = 0;
itemFields.description.order = 1;

export const zsuiConfig: ZenStackUIConfigCreate = {
	// hooks, schemas, etc...
	options: {
		showOrderedFieldsFirst: false,
	},
};

You can also override these options for a specific form.
// Example to pass options override, uncomment to test
const optionsOverride: Partial<ZenStackUIOptions> = {
	showOrderedFieldsFirst: false,
	showUpdateButton: true,
};

return (
	<ZSUpdateForm {...props} optionsOverride={optionsOverride}/>
)


Updating Get-SecureScoreData

Adding a second condition to check if a subscription is enabled in order to resolve issue #202 .

Requesting @dicolanl as code owner to approve.


Deploy Stemcell builder pipeline to e/w

In order to have parity between the environments and pipelines we need to deploy the stemcell builder job (https://github.com/18F/cg-aws-light-stemcell-builder) to e/w.
Acceptance Criteria

[ ] Pipeline is created in ci.cloud.gov
[ ] At least one stemcell is uploaded to an S3 bucket in us-east

Pipeline is running at https://ci.cloud.gov/pipelines/aws-light-stemcell-builder, and stemcells are getting published to the cg-ew-stemcell-builder bucket.

Confirmed in use.


[DoodStream] Add extractor

update of outdated extractors:
Closes https://github.com/ytdl-org/youtube-dl/pull/28903.
Closes https://github.com/ytdl-org/youtube-dl/pull/28008.
Closes https://github.com/ytdl-org/youtube-dl/pull/31003

Thanks for the update and decoding the pass_md5/token stuff.
I've made some comments for information, but I'll apply the changes to the old PR with attribution. The question to be settled is whether the '/d/' page ever embeds a link other than the matching '/e/' page.

update of outdated extractors: Closes #28903. Closes #28008. Closes #31003

I tried it, but i get this error:
yt_dlp.utils.DownloadError: ERROR: [generic] Got HTTP Error 403 caused by Cloudflare anti-bot challenge; try again with  --extractor-args "generic:impersonate"
My code:
from yt_dlp import YoutubeDL

# Define the video URL
video_url = "https://dood.sh/e/fayk8qbo63zm"

# Options for yt-dlp
ydl_opts = {
    'format': 'best',  # Download the best quality
    'outtmpl': '%(title)s.%(ext)s',  # Save with video title as filename
    'extractor_args': {
        'generic': {
            'impersonate': 'chrome',  # Impersonate Chrome browser
        }
    },
}

# Create a downloader instance
with YoutubeDL(ydl_opts) as ydl:
    ydl.download([video_url])

Thanks


Include license file in published crate

Hi, thanks for this project!
This PR adds the license file to the published crate.

Thanks @ankane  -- this makes sense to me

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 86.151%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
14283

Relevant Lines:
16579

💛  - Coveralls

Thanks @alamb!


Chain responses in middleware.

[x] This PR follows the Contribution Guide
[ ] Changelog updated

Description / Motivation
By chaining the responses in rewrites, we can access headers set in earlier middleware.
Testing Details

[x] Unit Test Added
[x] Manual Test/Other - I have implemented similar changes in our Sitecore solution. I don't have a personal Sitecore instance to fully test them on at this time.

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

By making this change, middleware should favor headers for passing data. Cookies would be reserved for passing data to future requests.

Sorry for all the yarn.lock commits.

@mjarosch It took us a while to get to this, sorry.
This is great work and an amazing code cleanup. I might need to copy the changes into a separate branch for some cleanup and conflict resolution - or if you got time, let me know if you can adjust personalize-middleware and remove yarn.lock from changes in this PR (there are no new dependencies - so yarn.lock does not need to be updated)

@art-alexeyenko Yes, I will update to remove the yarn.lock file and resolve the conflicts in personalize.

Do you mean that cookies may be absent during middleware execution of other requests or that follow-up middleware plugins have no access to cookies?

I mean follow-up middleware plugins won't have access to the cookie. The cookie is still set on the client, and future requests will see it.

@mjarosch

I mean follow-up middleware plugins won't have access to the cookie. The cookie is still set on the client, and future requests will see it.

That's not what I'm seeing when testing locally - but perhaps I miss some scenarios. SITE_SYMBOL cookie is set in multisite plugin, and if you check the value in the follow up plugin like
    console.log(res?.cookies.get(this.SITE_SYMBOL)?.value);
The value will be available, on server. I also tested this in incgonito to ensure I'm not reading cookies from previous requests.

@art-alexeyenko I could have sworn, when I originally did this, that it wasn't there. But I validated on my original implementation and they are accessible. Should I remove the comment?

@mjarosch perhaps this PR can just be wound down to code cleanup? There's probably no reason to duplicate site in headers and cookies - but it's good to avoid code duplication.

@art-alexeyenko the chaining makes it so following middleware don’t need to re-set cookies. So I would consider that more than code cleanup.
I can remove adding the site name to the headers. I think it’s nice to pass things in a consistent place and not everything should be set in a cookie. So I think you could justify duplicating the site in this case.
I defer to your judgement on this.

@mjarosch I'm still not sure the site should be duplicated in two places. The cookie can be used for both Sitecore instance to be consumed by, and by middleware plugins. Header will just repeat what is already set.
Could you cleanup the part around setting the header please, and then we'll merge this into the product.

@art-alexeyenko I have updated it to remove storing the site in the header.


Add gruvbox light and dark themes

I created themes based on the popular terminal colour scheme gruvbox.
https://github.com/morhetz/gruvbox

Thanks, these are cool! Will merge now and get them added soon (I don’t have this automated yet, sorry).

Apologies for the delay — these are live now!


Visual Studio compatibility

Is it possible to install it in Visual Studio?

Unfortunately Comment Anchors is currently only available for Visual Studio Code, and at this time there are no plans to port it over to other editors


Node Webkit + Sequelize (SQLite) problem

I have commented also here https://github.com/sequelize/sequelize/issues/2642, but to have a better context I will explain and show my examples here. The packages versions I'm using are:
├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>│ └──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>└──<EMAIL_ADDRESS>
I compiler node-sqlite3 as specified here https://github.com/mapbox/node-sqlite3#building-for-node-webkit. So far, everything goes well inside Node Webkit. Here are the commands that works:
The next code works as expected:
models.sequelize.sync().then(function () {
  var server = app.listen(app.get('port'), function() {

    console.log("App listening: " + server.address().port);
  });
});

// In some part of the code
// If I do a console.log I see the object created in memory
var client = models.client.build(req.body);

And next the code which fails:
models.client.save().then(function(client){
    // this fails successfully
});

models.client.findAll().then(function(clients){
    // also this fails successfully
})

I both cases the throwed error is:
/Users/fjcero/project/node_modules/sequelize/node_modules/bluebird/js/main/captured_trace.js:478 Unhandled rejection Error: TypeError: Illegal invocation
  at Object.ensureErrorObject (/Users/fjcero/project/node_modules/sequelize/node_modules/bluebird/js/main/util.js:228:20)
  at Promise._rejectCallback (/Users/fjcero/project/node_modules/sequelize/node_modules/bluebird/js/main/promise.js:416:22)
  at Promise._settlePromiseFromHandler (/Users/fjcero/project/node_modules/sequelize/node_modules/bluebird/js/main/promise.js:460:17)
  at Promise._settlePromiseAt (/Users/fjcero/project/node_modules/sequelize/node_modules/bluebird/js/main/promise.js:530:18)
  at Promise._settlePromises (/Users/fjcero/project/node_modules/sequelize/node_modules/bluebird/js/main/promise.js:646:14)
  at Async._drainQueue (/Users/fjcero/project/node_modules/sequelize/node_modules/bluebird/js/main/async.js:177:16)
  at Async._drainQueues (/Users/fjcero/project/node_modules/sequelize/node_modules/bluebird/js/main/async.js:187:10)
  at Immediate.Async.drainQueues [as _onImmediate] (/Users/fjcero/project/node_modules/sequelize/node_modules/bluebird/js/main/async.js:15:14)
  at processImmediate [as _immediateCallback] (timers.js:321:17)

Seems that Sequelize is using Bluebird, but the thing is that for some reason Bluebird is exploiting inside the NW context. Any idea or explanation on how to debug this lib inside NW will be really appreciated :)

what is the bluebird version used?

@petkaantonov hey, I just updated the description. The bluebird version is<EMAIL_ADDRESS>

Can you enable long stack traces

ping @fjcero a long stack traces output or complete isolated code to reproduce would be a huge help here.

Excuse the delay, I will run some tests since I have it working in a older version of node webkit, so I want to run some test and then update the feedback.

Anything @fjcero ?

Anything @fjcero ?


HAWK is not started by the cluster role

HAWK is not started by default but should be.

It appears that hawk is not enabled by default. A new variable will be added named enable_hawk which will be default false.


Fix Reload service daemon task taking 30 min

you are deleting several tests?

you are deleting several tests?

tests_idempotency_2017.yml and tests_idempotency_2019.yml have tasks that take 30 minutes, I want to first check if the fix works on these tests, I'll return other tests after.


Fix crash when removing clipping planes attached to Model

Fixes #8728 and #10811.
The updateClippingPlanes code was wrapped in a check for model.isClippingEnabled. Removing all clipping planes from the collection causes clippingPlanes.length to equal 0, which means isClippingEnabled will evaluate to false. model.resetDrawCommands will never be triggered as a result.
This PR moves the currentClippingPlanesState check out of the if statement, so that it is always checked even if isClippingEnabled is false. This is what old Model did.
Localhost sandcastle for #8728 (click removeAll box twice, shouldn't crash)
Localhost sandcastle for #10811 (remove button shouldn't cause a crash)

Thanks for the pull request @j9liu!

:heavy_check_mark: Signed CLA found.
:grey_question: CHANGES.md was not updated.

If this change updates the public API in any way, please add a bullet point to CHANGES.md.

Reviewers, don't forget to make sure that:

[ ] Cesium Viewer works.
[ ] Works in 2D/CV.

Thanks @j9liu!

Thanks


How to sortBy by second level (subkey) of JSON object?

I have an example JSON array I would like to sort. However, I would like to sort by attributes.Country (a second level) rather than a first level like label.
[
   {
      "label":"Ha Dae-sung",
      "id":"268",
      "attributes":{
         "Country":"South Korea"
      }
   },
   {
      "label":"Maxi Pereira",
      "id":"486",
      "attributes":{
         "Country":"Uruguay"
      }
   },
   {
      "label":"Manabu Saito",
      "id":"441",
      "attributes":{
         "Country":"Japan"
      }
   }
]

I can sort just fine on the first level using _.sortBy. For instance, to sort by just the label.
searched = _.sortBy(searched, "label");

However, I want to get a sorted array by Country within attributes. How would I set up a second level sort?

Getting an array sorted by country can be achieved by using a function as the iteratee. This should work for you -
searched = _.sortBy(searched, function(obj) { return obj.attributes.Country; });

thank you so much! this worked!


AEROGEAR - 2223 certificate pinning

Motivation
JIRA: https://issues.jboss.org/browse/AEROGEAR-2223
Description
Creating this PR to changes made in 171 merged

@ciaranRoche : too fast merge... was still reviewing. Can you give a look to my comments?

Sorry about that @ziccardi this was opened for awhile now on @aidenkeating branch, I was just trying to get the changes merged, will look at your comments.


Feature/docs

Summary

Add docs

generated by sphinx

Tests
require Python 3.10

[x] docker run -it --rm -v $(pwd):/work -w /work python:3.10 bash
[x] pip install pipenv
[x] pipenv install -d
[x] pipenv shell
[x] export PYTHONPATH=$(pwd)
[x] cd docs
[ ] make html
[ ] cd build/html
[ ] exit (exit from container)
[ ] python -m http.server
[ ] Enjoy!!!! :cat:

@aokumasan

(work) root@6718ef985e1e:/work/docs# make html
Running Sphinx v5.3.0

Configuration error:
There is a programmable error in your configuration file:

Traceback (most recent call last):
  File "/root/.local/share/virtualenvs/work-WgJkZa2_/lib/python3.10/site-packages/sphinx/config.py", line 350, in eval_config_file
    exec(code, namespace)
  File "/work/docs/source/conf.py", line 9, in <module>
    import bootstrapdocs  # noqa: F401
ModuleNotFoundError: No module named 'bootstrapdocs'

make: *** [Makefile:20: html] Error 2


Styles encapsulation

Please enter a none for encapsulation.
to be able to override styles.
Thanks.
encapsulation: ViewEncapsulation.None

Added this to both select.component.ts and select-dropdown.component.ts.