Undo when drawing Circles and using geometry functions

Describe the bug
The updated example from #11698 highlights a difference between ability to undo between Circle geometry (cannot undo center) and other geometries which can be undone back to the first point.  Drawing a circle is basically the same as using a 2 point LineString with a geometry function to produce a circle https://codesandbox.io/s/pensive-einstein-05es0?file=/main.js which can be undone as long as the geometry function handles it.  The same would apply to createRegularPolygon and createBox functions (attempting to undo even a Circle draw using these functions currently results in an error).  Custom geometry functions such as star and ellipse (based on a 3 point LineString) can also be undone as long as the function is set up to handle it (although in the codesandbox the fill re-renders immediately while the stroke does not update until there is a pointer event).
Expected behavior
If Circles drawn using a 2 point LineString can be undone the same should apply if they are drawn as a Circle.
There should be no errors if drawing is undone when using the predefined geometry functions.
Fill and Stroke should always show the same geometries.

Thanks for your observation @mike-000. If you see an easy way to fix circle drawing like you described, a pull request would be much appreciated.


virtualbox driver in timeout state after several minutes of VM use

Environment

docker
docker-machine
osx
virtualbox

1.11.2, build b9f10c9
0.7.0, build a650a40
El Capitan 10.11.5
5.0.20 r106931

Network Information

interface
subnet
netmask

en0
<IP_ADDRESS>/24
0xffffff00

vboxnet0
<IP_ADDRESS>/24
0xffffff00

I have various other network interfaces, but am not aware that any others are relevant. None overlap with the <IP_ADDRESS>/24 subnet.
Reproduction steps

docker-machine start my-machine
interact with the machine via the osx-based Docker client for 20-30 minutes

... then I can observe the machine in a Timeout state during docker-machine ls. active docker exec sessions print something like:
read tcp <IP_ADDRESS>:52922-><IP_ADDRESS>:2376: read: no route to host

Other possible causes
Sleeping the host seems to make this happen more often, and more quickly than 20-30min. Sometimes I use the VM after returning from a sleep before it enters a Timeout state, and sometimes it's already in a Timeout state.
Past reports
This PR has a unit test that asserts that docker-machine should raise an error in a variety of subnet-overlap cases, but I don't have any other subnets besides vboxnet0 that use <IP_ADDRESS>/24. https://github.com/docker/machine/pull/3165
Known temporary fixes
Restarting the osx host results in a fix that lasts 20min-1hr.

I am having the same issues except using docker 1.12 and machine 0.8.0 build b85aac1

After some testing it seems like it has something to do with the NAT network within virtualbox failing. It seems to be triggered at least in my case by "large" downloads and no amount of restarting my machine or the vm seems to be able to get around the issue.

in my case, restarting the vm's host fixes the issue. no observed correlation with downloads.

I downgraded to use the 1.11.2 boot2docker image and the issue is fixed. It seems like there is a network driver issue in the newer kernels. @zdexter can you confirm this on your end?


feature: Components Index Page

The components page needs to be implemented according to the design.
Since the functionality is not 100% set in stone yet it would be a good idea to not focus on the actual inner-workings of for example the filter part. Focus on the design! 👍

I’m gonna start working on that tomorrow :)

@cstrnt did you managed to get started on this?

@kevmodrome yes, I got quite some stuff done already. Right now im trying to make it look polished. Might be able to finish it tonight

This one also has mobile designs now: https://cln.sh/elJxc6

media queries width ?

Use grid-template-columns, no need for media queries

doing it

The buttons need to be adjusted so that they take either full or half the space. Probably a good idea to split this out into it's own component?

so basically kind of sticking em together ?

this is being worked on by #88


v0.3.6 and v0.3.7: lose peripherals following brew upgrade

When upgrading from v0.3.5 → v0.3.6 and v0.3.6 → v0.3.7 (both times via homebrew), I've lost the ability to type or register mouse clicks immediately following the reinstall. When I've lost the ability to type and click, I've tried plugging in / connecting via bluetooth additional mice and keyboards but with no resolution. At that point, the only action I can take is force shutdown the machine.
It's unclear to me why this is happening but one (obvious) observation is that the accessibility permission doesn't stick since the bin path changes. After I shutdown, I'm correctly prompted to open the accessibility permissions and everything works again.
Otherwise, (pure speculation) is it possible that brew is unceremoniously killing the skhd process, preventing it from releasing peripherals or something? Maybe the brew service handling terminated the service gracefully before?
(In any case, thanks for all the work you do! Much appreciated!)
edit: also happened for v0.3.8 though I found a workaround without having to force-restart this time. I was able to hit shift+cmd+Q to logout, then log back in and set the permissions for skhd and yabai. Unclear if this shortcut would have worked in the previous versions or if something was different this time.

The macOS permissions model works the way it does; stop the service before running upgrade.


Dynamic version

Implementing dynamic version control to push updates without hard terraform updates.
Currently the version is hard coded and pushing through new versions is not being maintained in the terraform repo. The commit will require a text file in an external source such as S3 to push updates dynamically to the terraform repo.
@todo: Link needs to be updated to reflect a Spotinst data source, for example spotinst-public S3 bucket.
A similar concept is currently used by the Spotinst team to manage the controller as follows
kubectl apply -f http://spotinst-public.s3.amazonaws.com/integrations/kubernetes/cluster-controller/spotinst-kubernetes-cluster-controller.yaml
A similar file will need to be created in this S3 bucket for this to be fully implemented and the example link changed in the pull request. The file format as per the pull request is as follows https://s3-eu-west-1.amazonaws.com/spotinst-vers/controller.json

Thank you for the PR.  For now we will pull in the latest tag and going forward we will make the version configurable.


Communicating snapshot update feature in Readme

Readme.md updates

Very basic info about how to update your snapshots using the cli.

Open to more ideas about communicating or clarity.

Love it.


Class based actions: Mypy not happy with defined parameters in the run method

For class-based actions, mypy is not happy with parameters to be defined in the method signature of the run method.
Current behavior
I have copied the class-based action example from doc:
from burr.core import Action, State, ApplicationContext

class Counter(Action):
    @property
    def reads(self) -> list[str]:
        return ["counter"]

    def run(self,
            state: State,
            increment_by: int,
            # add __context here
            __context: ApplicationContext) -> dict:
        # can access the app_id from the __context
        print(__context.app_id, __context.partition_key, __context.sequence_id)
        return {"counter": state["counter"] + increment_by}

    @property
    def writes(self) -> list[str]:
        return ["counter"]

    def update(self, result: dict, state: State) -> State:
        return state.update(**result)

    @property
    def inputs(self) -> list[str]:
        # add __context here
        return ["increment_by", "__context"]

Then mypy is not happy with it with errors:
mypy src/demo_application.py
src/demo_application.py:8: error: Signature of "run" incompatible with supertype "Function"  [override]
src/demo_application.py:8: note:      Superclass:
src/demo_application.py:8: note:          def run(self, state: State[Any], **run_kwargs: Any) -> dict[Any, Any]
src/demo_application.py:8: note:      Subclass:
src/demo_application.py:8: note:          def run(self, state: State[Any], increment_by: int, ApplicationContext, /) -> dict[Any, Any]
Found 1 error in 1 file (checked 1 source file)

Library & System Information
uv pip list | grep mypy
mypy               1.13.0
mypy-extensions    1.0.0

uv pip list | grep burr
burr               0.34.1

python --version
Python 3.12.5

Thanks for the report!  So this is an inherent mypy limitation/conscious decisiom. Mypy has no way of knowing that the fields are dynamically set by the inputs() property. To work aroudn it, you would want to use **kwargs as the signature and access the parameters dynamically. E.G.
 def run(self,
            state: State,
            **kwargs) -> dict:
        # can access the app_id from the __context
        __context = kwargs["context"]
       increment_by = kwargs["increment_by"]
        print(__context.app_id, __context.partition_key, __context.sequence_id)
        return {"counter": state["counter"] + increment_by}

We chose not to have that as it's harder to read, and I'm less a believer in strict type-checking in python, but it's there if you want it! You may be able to do something with a typed dict/type-hinting kwargs as well -- haven't tested it out -- see https://peps.python.org/pep-0692/

Thanks for the response. For now have considered the options, I probably will just put type: ignore[override] to each individual occassion of overriding the run method in a class based action. Being a strong believer of type checking in Python myselef this is quite a lot of frictions.

Thanks for the response. For now have considered the options, I probably will just put type: ignore[override] to each individual occassion of overriding the run method in a class based action. Being a strong believer of type checking in Python myself this is quite a lot of frictions.

Hey! Glad you found a workaround. Sorry for the delay in responding! TBH I think this is an area in which mypy could improve, and also an area in which python/strict type-checking falls a bit flat. That said, I wouldn't be surprised if there's a better way to define the superclass, and I'm happy to dig in a bit. It quite annoys me as well... Will report back!


FINERACT-1956: Added the skeleton structure necessary to publish doc …

Description
Added the necessary folders and files for Antora to build the documentation site from asciidoc i.e
Refer to https://docs.antora.org/antora/latest/
Checklist
Please make sure these boxes are checked before submitting your pull request - thanks!

[x] Write the commit message as per https://github.com/apache/fineract/#pull-requests

[ ] Acknowledge that we will not review PRs that are not passing the build ("green") - it is your responsibility to get a proposed PR to pass the build, not primarily the project's maintainers.

[ ] Create/update unit or integration tests for verifying the changes made.

[ ] Follow coding conventions at https://cwiki.apache.org/confluence/display/FINERACT/Coding+Conventions.

[ ] Add required Swagger annotation and update API documentation at fineract-provider/src/main/resources/static/legacy-docs/apiLive.htm with details of any API changes

[ ] Submission is not a "code dump".  (Large changes can be made "in repository" via a branch.  Ask on the developer mailing list for guidance, if required.)

FYI our guidelines for code reviews are at https://cwiki.apache.org/confluence/display/FINERACT/Code+Review+Guide.

Please reopen

The suggested bits have been removed. Review and advise.

LGTM

Please don't merge this one before we've created release 1.9.0. Let's target 1.10.0. Jira tickets updated.

No conflicts w base branch.

Please don't merge this one before we've created release 1.9.0. Let's target 1.10.0. Jira tickets updated.

@vidakovic now that 1.9 is out, can we resume this? This PR is purely documentation related and does not contain any fineract code and therefore should be safe to merge without breaking anything.

@jdailey @vidakovic @jogathogo Should we reopen and merge this one?


[PE-D][Tester A] Formatting Error in Error Message for Names

Just a small formatting mistake in the error message at "... forward slashand spaces...".
The slashand should have a space.
Proof:

Labels: severity.VeryLow type.DocumentationBug
original: HanB1n/ped#2

Duplicate of #185


[BUG] Getting SlotConfigResource results in exception

Library name and version
Azure.ResourceManager.AppService
Describe the bug
I am trying to get the list SlotConfigNames (the appsettings with the tick next to "slotsetting") to be able to update them later on.
When trying to get them, you get an exception that the resource id cannot be null.
await resource.GetSlotConfigNamesResource().GetAsync();
Where resource is a WebSiteResource.
When looking into this, I noticed that the REST API returns null for the id. Which makes sense, because it is not really a resource in itself.
Expected behavior
The method returns the SlotConfigResource as expected and doesn't throw exceptions.
Any idea about a workaround? Currently the only thing I see is to call the REST Api myself.
Actual behavior
An ArgumentNullException with stacktrace:

at Azure.Core.Argument.AssertNotNullOrEmpty(String value, String name)
at Azure.Core.ResourceIdentifier..ctor(String resourceId)
at Azure.ResourceManager.AppService.SlotConfigNamesResourceData.DeserializeSlotConfigNamesResourceData(JsonElement element)
at Azure.ResourceManager.AppService.WebAppsRestOperations.d__138.MoveNext()
at Azure.ResourceManager.AppService.SlotConfigNamesResource.d__14.MoveNext()

Reproduction Steps
Run following code on a WebSiteResource:
await resource.GetSlotConfigNamesResource().GetAsync();
Environment
No response

Thank you for your feedback.  Tagging and routing to the team member best able to assist.

Hi @dumonjorne, I'm trying to reproduce this issue, and unfortunately currently there is no good workaround for this issue.
And one more thing about this issue is that it is more like a service-side problem. In the REST API spec definition, this is marked as resource, which means a valid ID should be returned by the backend service.

Sorry for the delayed response, we don't have good ways to accelerate the fix of this bug. Could you please try this workaround?

Define the policy that will assign a valid value to the id property.

	public class InvalidPropertyFilterPolicy : HttpPipelineSynchronousPolicy
	{
	    public override void OnReceivedResponse(HttpMessage message)
	    {
	        if (message.Request.Method != RequestMethod.Put || message.Response.ContentStream == null) // Change here to get the expected response
	        {
	            return;
	        }

	        var reader = new StreamReader(message.Response.ContentStream);
	        var content = reader.ReadToEnd().Replace("", ""); // Assign a valid value to the property id
	        var jsonDocument = JsonDocument.Parse(content);
	        var stream = new MemoryStream();
	        var writer = new Utf8JsonWriter(stream);
	        jsonDocument.WriteTo(writer);
	        writer.Flush();
	        message.Response.ContentStream = stream;
	        message.Response.ContentStream.Position = 0;
	    }
	}

Register the policy in the ArmClientOptions

	options.AddPolicy(new InvalidPropertyFilterPolicy(), HttpPipelinePosition.PerRetry);

Hi,
Thanks for the response. I will try this approach.
I had worked around it using a custom REST client, but with this approach I would be able to use the SDK, so that would have my preference.

Hi,
Based on the above proposed workaround I was able to get slot config names and update them using the SDK.
class SlotConfigNamesEndpointFilter : HttpPipelineSynchronousPolicy
    {
        public override void OnReceivedResponse(HttpMessage message)
        {
            if (!message.Request.Uri.Path.EndsWith("slotconfignames", StringComparison.OrdinalIgnoreCase) || message.Response.ContentStream == null) // Change here to get the expected response
            {
                return;
            }
            var reader = new StreamReader(message.Response.ContentStream);
            var content = reader.ReadToEnd().Replace("\"id\":null", $"\"id\":\"{message.Request.Uri.Path}\""); // Assign a valid value to the property id
            var jsonDocument = JsonDocument.Parse(content);
            var stream = new MemoryStream();
            var writer = new Utf8JsonWriter(stream);
            jsonDocument.WriteTo(writer);
            writer.Flush();
            message.Response.ContentStream = stream;
            message.Response.ContentStream.Position = 0;
        }
    }

Close this issue as it is resolved.
If you have any other feedback to our Azure SDK, feel free to let us know in this survey.


[DOM-22549] amqp retry logic

The AMQP library in Forge does not do automatic reconnection, so we need to implement it.
This works to add retry logic to two two cases where RMQ disconnects:

on initial connection to the publisher
when publishing a message to RMQ

Unit tests need to be added once a good RMQ interface is found (wabbit appears to be good for this)

	* Connection logic with some cap on the maximum number of attempts and a fixed delay between retries
	* The ability to signal a reconnect when an existing connection is closed

	There are 4 different operations that can fail whenever RMQ goes away:

	1. Dialing a server (i.e. create connection)
	2. Creating a channel
	3. Declaring a queue
	4. Publishing a message

	Important Design Questions:

	- Should the publisher house all of the logic required to connect/reconnect a Connection and/or Channel?

	This is a bigger design and might not be worth the logic separation in terms of CBA.

	- Should "connection lost" errors be auto-resolved or should that signal be passed along to a user?

	We should be able to auto-resolve our own connection lost errors, but the real question is "when do we resolve them?"

	- Should we watch connections and channels separately, or focus primarily on the root cnxn object?

		How can channels close independently of connections w/o an explicit Close() operation? Seems low-risk.

		Connection failures result in channel failures: this is a reliable failure mode.```

@saahildhulla closing this now that #57 has been merged with the intended changes.


Support regex as dynamic parameters

This pr aims to add the support to simple parameters for the callable of commands and text events, like:
$bot->onText('My name is {name}, I live in {city}', function (Context $ctx, $name, $city) { ... });
// and
$bot->onCommand('start {token}', function (Context $ctx, $token) { ... });

As always, suggestions/changes are welcome

Hi, sorry for the late reply. That's a very cool feature! I added it also for cb queries. Can you add a comment explaining the regex? As you know they aren't much self-explanatory 😅

Hi, sorry for the late reply. That's a very cool feature! I added it also for cb queries. Can you add a comment explaining the regex? As you know they aren't much self-explanatory 😅

Thanks! Going to merge the PR and release a 0.6.2.

Thanks! Going to merge the PR and release a 0.6.2.

@cheeghi I've just noticed that a unit test is failing, about the callback queries, if you look at travis

@cheeghi I've just noticed that a unit test is failing, about the callback queries, if you look at travis

Ah yeah, there was an error in the unit test. Fixed in develop, thanks!

Ah yeah, there was an error in the unit test. Fixed in develop, thanks!


Log length of labels exceeding max length

This logs the actual length we encountered when validation of label
name or value fails due to it being too long.

I guess this is of mild interest, but once you get past 200 chars you’re doing it wrong.
In the case of label value we probably want the label name too - makes it easier to tie back to the source.

once you get past 200 chars you’re doing it wrong.

makes sense. closing this, if still wanted can be done on top of #890


Use CollectionCompat in WebjarService

This uses CollectionCompat.CollectionConverters.asScalaIterator instead of our own asScalaIterator. Motivated by https://github.com/http4s/http4s/pull/3326#pullrequestreview-395934628.

The test errors on the<EMAIL_ADDRESS>builds seem to be unrelated.

Btw, feel free to squash on merge because the build errors of the first two commits are legit.


public and restricted channels

Is it possible to have public community channels and allowlist restricted member channels ?

You can't have different access control between channel in a same Devzat instance, but you can self host your own Devzat instance and set up an allowlist on it. Does that answer your question?

Is this something you need for a devzat server you're hosting or considering to host @RocketRene


Using httprouter with go-json-rest

Instead of using the default router, is it possible to use the httprouter with go-json-rest?

Yes, on top of go-json-rest stack of middlewares must be an App. Which does not have to be the default router. Anything satisfying the App interface will do. It should be possible to take any third party router, and wrap it into an App.
The App interface is defined like this:
type App interface {
	AppFunc() HandlerFunc
}

I'm trying to do the opposite. In order to use manyminds/api2go with go-json-rest, I'm trying to write a api2go adapter. I need to get a http.Handler from go-json-rest and I am quite lost.


Make group boxes more visible

subtle grey background to make it more visible

On my monitor, rgb(250,250,250) is hard to distinguish from white (it is a VA panel with bad color accuracy though), so I settled for rgb(248,248,248) for now, hope that is subtle enough and still visible enough.

Oh and there is a massive diff in the SVG because I had to draw the group boxes at the beginning. Before they were drawn at the end so the background would cover the rest.


Update frequency

Hi Pallupz, really appreciate your efforts. Is there any way to reduce the frequency of updates? For some locations the slots get filled up in just a second or so, so it would be great if the slot availability could be checked   every second.

Hi @darrenpunnen : I will try to parameterize the timeout

@darrenpunnen Also take into account the fact that the API must be having some rate limiter configured on its end - based on IP address, to prevent DDoS attacks. More likely than not, 1 request a second might trigger that

Many thanks @pallupz, look forward to it. @mrms123 completely take your point, but honestly I don't think a request per second might trigger that. Certainly, there are codes that are already doing this. Availability would not have been so difficult otherwise :)

Hi @darrenpunnen : The latest version allows for timeout customization. I have set the minimum allowed value as 5 seconds. Maximum would be upto the user.

Thank you so so much @pallupz! It works perfectly and I was able to book 3 slots immediately.

Hi @darrenpunnen : I will try to parameterize the timeout

It would be nice if you could set it to 1-sec ping for a few minutes (say 20 minutes max) and then it reverts to whatever might make it look not suspicious.


sql "track_total_hits": true setting  Lose Efficacy

POST /_plugins/_sql?format=json
{
"query": "SELECT  * FROM logstash-java-* WHERE MATCH_PHRASE(message, 'ERROR') ",
"track_total_hits": true
}
{
"took" : 19,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 10000,
"relation" : "gte"
}

@binbinjianjian care to explain what you're trying to do and what the issue is?

Probably something similar to this https://github.com/opensearch-project/OpenSearch/issues/2093.
Where although they are passing track_total_hits the results show total hits being 10000 even though there should be more hits.

Closing this, since we are tracking this as feature enhancement on https://github.com/opensearch-project/OpenSearch/issues/2093. Feel free to reopen if you have more questions or concerns.

@binbinjianjian care to explain what you're trying to do and what the issue is?

i  know hit How much data


Badge background is not applied

Bcl badges do not allow customizing the background anymore.
@see https://github.com/openeuropa/bootstrap-component-library/blob/development/src/components/bcl-badge/badge.html.twig#L34
Proposed solution:
{% set _classes = _classes|merge(['text-bg-' ~ _background, 'bg-' ~ _background]) %}

This issue can be closed. After new investigation, text-bg has been introduced in Bootstrap 5.2: https://getbootstrap.com/docs/5.3/components/badge/#background-colors
I think there might have been a temporary mismatch between the provided version of bootstrap and this change, or it's our custom theme which override bg-VAR which resulted into having all badges in different colors.
Anyway. Issue is not from BCL-bootstrap anymore.


Update solid-rx's solid-js peer dependency to the latest version

When I install solid-rx 0.18 with solid-js 0.18, yarn gives me the following warning<EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS> This change updates the solid-js peer dependency to 0.18 to fix the warning.

Looks like the build failure is unrelated to my change and should be fixed by updating to the latest version of coveralls: https://github.com/nickmerwin/node-coveralls/issues/280

That is a weird warning since 0.18.0 would satisfy 0.15.5 I'd think.. I guess unless it treats 0. versions differently. But I will keep a closer watch on it. Lerna auto updates other dependencies but I guess not peer dependencies.


onViewableItemsChanged no triggered after the first section

Hello,
I use the Section List to display an alphabetical list of contacts. Each section correspond to a letter of the alphabet. Next to the list, there is a vertical component that display an alphabetical index (A to Z).
I would like to highlight the active section (letter) on this component. For that, the onViewableItemsChanged callback seems to be the answer.
However, it is not working as expected.
The event is only fired for the first section (in my contact app example, for the letter "A"). When the user scroll to the next section, the event is not triggered at all.
Thanks

Facing the same issue

@labtorie unfortunately no. And it's a big limitation.

@labtorie unfortunately no. And it's a big limitation.

Thanks for a quick response.
By any chance, do you know any other way to implement the list we both need, as perfomant as this one is, and without that kind of problems?

The only solution I see will be to debug this library and create a PR.

Hey. I guess I've found the problem. All you need to do is to patch BigList.js. The problem is in this line https://github.com/marcocesarato/react-native-big-list/blob/a50c24922e0f83226ba30a3626ab32bba74733d7/lib/BigList.jsx#L584
You need to replace section[sections] with section[s]

Hello,
I've installed the last release (version 1.5.3).
I can confirm that the bug is now fixed. The event onViewableItemsChanged is now triggered for each section of the list.
Again, thank you @labtorie @marcocesarato.
Have a nice day


Fixing the 'chunks' pointer so that it is not used before modifying a…

…gainst nullptr.
Adding a nullptr check before the pointer is used in the if-statement and before any memory is freed.

Superseded by https://github.com/godotengine/godot/pull/66787, I guess.


Flexible regions

Adding flexibility in the s3 storage region used and the choice of aws/gcp region to encode on.

Codecov Report

Merging #182 into master will decrease coverage by -0.12%.
The diff coverage is 50%.

@@            Coverage Diff             @@
##           master     #182      +/-   ##
==========================================
- Coverage   79.94%   79.82%   -0.12%
==========================================
  Files          29       29
  Lines        2493     2498       +5
==========================================
+ Hits         1993     1994       +1
- Misses        325      329       +4
  Partials      175      175

Impacted Files
Coverage Δ

config/config.go
100% <ø> (ø)
:white_check_mark:

provider/bitmovin/bitmovin.go
59.64% <50%> (-0.4%)
:x:

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 6f5cf95...41ae17b. Read the comment docs.


After modifying the dll, the software does not change

When I use the software to open a dll, if I modify the code and re-generate the dll, after refreshing in the software, it shows that the dll has not changed. You have to close the software and open it again.

Hi. Please see #54 .


#4 Added cloud implementation

Closes #4
Closes #11
We extracted the features of this branch from main since they were not yet production ready.
All contents of this branch are already reviewed.

test

/ci-test

/ci-build

/ci-build

/ci-build feature/4-cloud

/ci-build feature/4-cloud

/ci-build ref=feature/4-cloud


12 validate taxonomy

Taxonomy validation (Phase 1)
Description
The first set of validation activities includes visualisation tools as well as two approaches to labelling topics (entity labelling and weighted journal labelling). Plots include sunbursts and a first set of histograms. For details, see the README file in pipeline/taxonomy_validation.
Fixes #12
Checklist:

[X] I have refactored my code out from notebooks/
[X] I have checked the code runs
[X] I have tested the code
[X] I have run pre-commit and addressed any issues not automatically fixed
[X] I have merged any new changes from dev
[X] I have documented the code

[X] Major functions have docstrings
[X] Appropriate information has been added to READMEs

[X] I have explained this PR above
[] I have requested a code review

In regards to the validation utils, I completely agree that it eventually needs splitting. In fact, most functions there correspond to the labelling approaches (and using it to label our taxonomy with entities or journals). I'll rename it to "labelling.py", and create other py files as per your request for subsequent work, if necessary.

@emily-bicks I pushed some additional code (relating to the histograms, mostly). I was thinking of directly merging to dev since you already reviewed its legacy code, but maybe you want to have a quick peak again. Otherwise I can merge :)


Image Not found, when it's deleted and uploaded with same name.

I've added the CDN module & CDN media handler to my project.
When I updated the image with the same name, It's working as expected. If I just refresh the browser new image was showing.
However, If I delete the Image from Episerver and Upload it with the same name, the Image was not found.  And the path is showing in Recycle-Bin, as shown in the attached image.

Another Issue:
I've logged out. Still, cache-control was showing as Private.
Any pointers would be much appreciated.
Thanks.

Reopen if you still are having problems and think they are related to the CDN module, the module just adds the unique part of the URL and should not be changing the URL.


Modified clue hint for Yanille Agility dungeon cryptic clue scroll.

Modified clue hint for Yanille Agility dungeon cryptic clue scroll for accuracy.
Issue #10871

Accidentally included the wrong name for the altar.  Corrected opened a new pull request.


How do I use a custom GraphQL Lambda Authorizer with Congito users?

I need to create Accounts and each account has multiple users that can access it. I have been using Cognito groups with groups auth rule in the GraphQL schema, but that has a limit of 50 groups.
To do this I have to create some custom auth logic, but doesn't seem to be that straight forward. For starters I need to verify the JWT, and for that I need to get the UserPoolId.
const {
    authorizationToken,
    requestContext: { apiId, accountId },
  } = event;
  verifier = verifier || CognitoJwtVerifier.create({
    userPoolId: (await new CognitoIdentityServiceProvider().listUserPools({ MaxResults: 999 }).promise()).UserPools
      .find(pool => pool.Name === appName-${process.env.ENV}).Id,
    tokenUse: "access",
    clientId: apiId,
  });

The issue with this code is that the lambda function doesnt have permissons to list user pools.
Apart of that, I understand that I would then need to parse the GraphQL request to get what data source and item it is being queried.
Isn't there a more straight forward way I am missing?

Hi @demilp 👋 thanks for raising this issue. You can grant your lambda function access to your Auth resource by running amplify update function and selecting Resource access permissions. Here select auth and any other resources it should be able to access. Afterwards the CLI will make resource attributes available to the lambda as environment variables.
example:

Are you using the auth rule allow: custom in your GraphQL schema?

@chrisbonifacio yes, I am using allow: custom


Distributed lock component

When I was trying to use distributed lock component released in dapr's version 1.10.2. I have an issue that, how can I detect the lock is held by another user? rely on 2 functions provider by the dapr/go-sdk TryLockAlpha1 and UnlockAlpha1 for now I don't know how can I handle a request that lock by another
func (c *daprClient) TryLockAlpha1(ctx context.Context, in *TryLockRequest, opts ...grpc.CallOption) (*TryLockResponse, error) {
	out := new(TryLockResponse)
	err := c.cc.Invoke(ctx, "/dapr.proto.runtime.v1.Dapr/TryLockAlpha1", in, out, opts...)
	if err != nil {
		return nil, err
	}
	return out, nil
}

func (c *daprClient) UnlockAlpha1(ctx context.Context, in *UnlockRequest, opts ...grpc.CallOption) (*UnlockResponse, error) {
	out := new(UnlockResponse)
	err := c.cc.Invoke(ctx, "/dapr.proto.runtime.v1.Dapr/UnlockAlpha1", in, out, opts...)
	if err != nil {
		return nil, err
	}
	return out, nil
}

// TryLockAlpha1 attempts to grab a lock from a lock store.
func (c *GRPCClient) TryLockAlpha1(ctx context.Context, storeName string, request *LockRequest) (*LockResponse, error) {
	if storeName == "" {
		return nil, errors.New("storeName is empty")
	}

	if request == nil {
		return nil, errors.New("request is nil")
	}

	req := pb.TryLockRequest{
		ResourceId:      request.ResourceID,
		LockOwner:       request.LockOwner,
		ExpiryInSeconds: request.ExpiryInSeconds,
		StoreName:       storeName,
	}

	resp, err := c.protoClient.TryLockAlpha1(ctx, &req)
	if err != nil {
		return nil, errors.Wrap(err, "error getting lock")
	}

	return &LockResponse{
		Success: resp.Success,
	}, nil
}

What happening if we try to access to the nil value return by func (c *daprClient) TryLockAlpha1(ctx context.Context, in *TryLockRequest, opts ...grpc.CallOption) (*TryLockResponse, error)

how can we know the lock is held by another?

@onqlave-cesc The way do that is to invoke TryLockAlpha1. If another user owns the lock, you will get an error saying that

@onqlave-cesc I have given this more thought. I assume at this stage you probably moved on, but still answering here for posterity.
Essentially, the way to know if the lock is taken by someone else is to call Unlock() and passing a value for lock owner that you know is not correct.
For example, assume the resource myresource was locked and the call had owner Mario.
If you call "Unlock" on myresource and set as owner no-one, the unlock call will fail with an error indicating either:

That the lock is owned by someone else -> that means the lock is active
That the lock doesn't exist -> that means the lock is inactive

thanks for your answer. did the lock component support connect to the redis cluster?

@onqlave-cesc the current component does not support redis clusters, no.


pytest failed

I cloned the repo and followed the instruction as in README.md.
Also runned poetry install. But when I try to pytest test, it shows error like this.
root@e26b5af13215:/workspace/lightning-boilerplate# pytest test
ImportError while loading conftest '/workspace/lightning-boilerplate/tests/conftest.py'.
tests/conftest.py:6: in <module>
    import rootutils
E   ModuleNotFoundError: No module named 'rootutils'

I've tried
poetry pytest test
and it works.
Do you know why?

Thanks for your comment, you will just need to run the command poetry run pytest.

I see. Thank you for your reply :D


Expression-bodied members vs. expressions that return nothing

v6 introduces expression-bodied members, v7 will introduce expression-bodied finalisers. In the former case result of the expression of the body may be classified as nothing (§12.2.1) if the return type of the method is void; in the latter case it may be the case that the result type must be classified as nothing.
The introduction of at least the above two kinds of expression bodied members extends the places expressions whose result is classified as nothing may occur: §12.2.1 requires updating for v6 (and again for v7); it may impact how null conditionals are specified (PR #7, #251); and there could well be other places…
Let the hunt begin!

Moving this to C# 7.x, when some new places expression that may be classified as nothing get introduced. Then we need to look for places where nothing is currently not an option that needs to be considered and determine if now it needs to be… could be no such places of course but determining that may take non-trivial time.

These might be addressed in #213
Assigning to @jskeet to verify, or bump to C# 8

Will wait until #213 is merged before looking. I suspect it won't be fixed, but we can validate it's not worse.

Checked now, before #795 is merged, admittedly - all of the above is still true. Will change the milestone to C# 8.


Merge ostree-ext

xref https://github.com/ostreedev/ostree-rs-ext/issues/675
Basically I see bootc as the successor/inheritor of the original ostree-container work.
It will help us close the loop faster on things to merge it into this project.

Ah, messed this one up, will redo later

OK I redid this one, now with proper git history

Ugh, right I think I need to git merge --signoff

I have clicked "Set DCO to pass" to override the signoff on individual commits. Most of these commits are mine anyways, and with this statement I add my Signed-off-by onto all of these commits.

Yay for one less repo to watch :partying_face:


Limit transport to websockets

Is it possible to specify the transport before initializing a connection? We have a service which only supports websocket connections and no long polling.

That's currently not supported, but a feature that's rather easy to add. There is currently a lot of refactoring going on by @nshaaban-cPacket, but I'm sure we could add this to the list of features. Currently the first request is a http request to the server, receiving a handshaking packet in response. If this packet mentions an upgrade possibility, the client upgrades immediately.

How urgent is your need for this? We could maybe add this before working on a server implementation after the first refactoring PRs hit main.

@namxam released in 0.3.0-alpha-1 https://docs.rs/rust_socketio/0.3.0-alpha.1/rust_socketio/struct.SocketBuilder.html#method.transport_type

Closing this as it is now resolved.


Upgrade to 0.1.5 cause plugin lock up

Plugin locks in a cycle of "refresh states" following an upgrade.  Under investigation but for now a plugin restart clears the issue.

Problem identified, fixed and regression tested

Version 0.1.6 will upgrade from 0.1.3 without issues, also identified some other related issues 0.1.5  download bundle will be removed so avoid accidental usage

Introduced a further lockup now addressed in 0.1.7

New pre-release under test that should address all issues and odd behaviours.  Will test over a number of days before pushing to the store


New version: RoME v0.4.3

Registering package: RoME
Repository: https://github.com/JuliaRobotics/RoME.jl
Created by: @dehann
Version: v0.4.3
Commit: 9b32e22b7f12c039d758cdb67a24556fa6b1ff93
Reviewed by: @dehann
Reference: https://github.com/JuliaRobotics/RoME.jl/issues/202

Your new version pull request does not meet all of the guidelines for automatic merging.
Specifically, your pull request does not meet the following guidelines:

The following dependencies do not have a compat entry that has an upper bound: CoordinateTransformations

It is important to note that if your pull request does not meet the guidelines for automatic merging, this does not mean that your pull request will never be merged. It just means that your pull request will require manual review by a human.

These guidelines are intended not as requirements for packages but as very conservative guidelines, which, if your new package or new version of a package meets them, it may be automatically merged.

On a separate note, I see that you are registering a release with a version number of the form v0.X.Y.
Does your package have a stable public API? If so, then it's time for you to register version v1.0.0 of your package. (This is not a requirement. It's just a recommendation.)
If your package does not yet have a stable public API, then of course you are not yet ready to release version v1.0.0.

[noblock]

Your new version pull request met all of the guidelines for automatic merging.
I will automatically merge this pull request during the next cron job.
If you want to prevent this pull request from being auto-merged, simply leave a comment.
(If you want to post a comment without blocking auto-merging, you must include the text [noblock] in your comment.)

On a separate note, I see that you are registering a release with a version number of the form v0.X.Y.
Does your package have a stable public API? If so, then it's time for you to register version v1.0.0 of your package. (This is not a requirement. It's just a recommendation.)
If your package does not yet have a stable public API, then of course you are not yet ready to release version v1.0.0.

[noblock]

The mandatory waiting period has elapsed.
Your pull request is ready to merge.
I will now merge this pull request.

[noblock]


[docs] Implement the new API display design

Links
This PR is aimed at improving the API tables browsing experience as reported in the following issues:

https://github.com/mui/material-ui/issues/34085.
https://github.com/mui/material-ui/issues/36544

Design reference here.
Previews

Component
Before
After

Material UI's Tabs
Before
After

Material UI's Input Adorment
Before
After

Material UI's Zoom
Before
After

Material UI's Pagination
Before
After

Material UI's Modal
Before
After

Base UI's Tab
Before
After

To-do:

[x] Props title
[x] Props description
[x] Update props description to match list style instead of table
[x] Clean CSS
[x] Use props table on all pages
[x] Transform ClassesTable into a list

It's far from perfect in terms of dev and CSS but all the basics are here.

@alexfauquette maybe it's ok to make just the anchor icon container be clickable? The trade-off seems reasonable here. We also end up winning less hover state to manage, I guess!

For the Signature section, we might need to tweak the proptypes parsing to be able to extract the signature from the rest of the description. Seems feasible. I opened a dedicated PR for that #37446

@alexfauquette This last commit of mine, for some reason, broke the scroll anchoring 😅 Couldn't find where to fix it, so just giving you a shout out!

@danilo-leal it's the deletion of ...theme.typography.caption, which also deletes the typography.allVariants and its scrollMarginTop: 'calc(var(--MuiDocs-header-height) + 32px)', property 😉
https://github.com/mui/material-ui/blob/88197c9fb7dd57120674bb316198c523112f9273/docs/src/modules/brandingTheme.ts/#L308

I've open a PR to see the new design on mui-x docs: https://github.com/mui/mui-x/pull/9187

DataGrid
DateCalendar

@alexfauquette how are you enjoying it? It seems to me that it adapts well.
There are a few spots that I'd like to refine further such as 1) the "Signature" piece of text; 2) Base UI's "Slots" & "CSS classes" tables. For the latter, I'd love to remove the amount to repetitive content since we're putting each subcomponent API docs in one page/tab, but that might be out of scope. 😄

For the signature, I was waiting for a review of my PR in docs:api but I could do the modification here and whatever the technical solution I agreed on with core team, I will backport it in this PR.
For the Base specific docs, would you just delete them if they are not the first one? Or a note system like in books: a "more info" link that redirect to a footer note

I've done the update on the Classes list and the signature
Don't hesitate if you see blocking point in the design refinement

The only point that is sometime problematics is the slots type

@alexfauquette Do you think we can make the anchoring functionality also copy the link? It's a feature I just realized Stripe supports and it's a handy interaction! Example: https://stripe.com/docs/payments?payments=popular#multiparty-payments

I added the copy action.
For the visual feedback, it might take some time. I would prefer to put that in a follow-up PR since it requires some animation, plus placing the feedback text.

@danilo-leal Don't worries about the "PR: out of date" notification from github. Since I touched to the docs:api script, it will occur each time the API of a component is modified.

I added a proposal from @DanailH to manage types that are too long

@alexfauquette Sweet, this is looking super good ⎯ excited about it! A couple of thoughts:

Would it be possible to have this type display be a type of accordion whenever it is super long? For some reason, the hover approach with ellipsed text doesn't feel intuitive/natural to me. Maybe something like this?

Should we change the anchoring icon button past a certain breakpoint? Or do we have a way to solve this? I see that, for example, Tailwind ⎯ who positions it in the same place as we're doing it ⎯ just hides it.

Should we change the anchoring icon button past a certain breakpoint? Or do we have a way to solve this?

From tailwind behavior, I would say hiding it I enough. At least, I never used this kind of link on mobile device, so it would not be a problem to don't have it form a small screen

Would it be possible to have this type display be a type of accordion whenever it is super long? For some reason, the hover approach with ellipsed text doesn't feel intuitive/natural to me. Maybe something like this?

 I will see if it's feasible, but it's not obvious to know when the text overflows or not

Nice! Cool to see that working! Though I'm not yet loving the border, too 😬 Ideally, we would have something like this:

@danilo-leal Where are we on this topic?

@alexfauquette heya! I think we're good, aside from the accordion thing when the type is long ⎯ ideally, it should be like the above! What do you think?

@alexfauquette Alright, I think we're like 99% with this 😆 One tiny little thing I wanted to do is:

In the screenshot above, onChange is the one I clicked on, and then page is the one I'm hovering over. To clearly disambiguate the one that's currently selected, can we tilt/angle the link icon a bit inside the container? Or at least you could point me out how to target this "currently selected" state? 😬

For autocomplete I noticed that we say "Props of the native component are also available.", but there is no native autocomplete component – it's an input. Is there a better way to phrase this, or to explicitly the native component in question?

That topic would require a dedicated PR, because there is already a way to provide the element. So if it does not work it's more a dedicated improvement (I checked, it's not a regression)
let spreadHint = '';
if (spread) {
  // Any other props supplied will be provided to the root element ({{spreadHintElement}}).
  spreadHint = t('api-docs.spreadHint').replace(
    /{{spreadHintElement}}/,
    inheritance
      ? `<a href="${inheritance.pathname}">${inheritance.component}</a>`
      : t('api-docs.nativeElement'),
  );
}

We also appear to mention this twice, both before and after the prop descriptions:

Yes I think it's because this notion of props inheritance between components is not well known so there is the introduction sentence and a dedicated section to ensure devs see it.

@danilo-leal It let me see that we kind of miss some structure. Before props were into table so it's easy to see when it start an d stop. With list it's harder, so small comment/section can be mixed with the previous list of item.
Here for example we have the sentence about the ref that seems lost into the variant description.

Maybe we could move this ref sentence and props sub-section to the top
## Props

The ref is propagated

## Inheritance
...
## Theme default props
...

<PropsList />

## CSS

@alexfauquette agreed, felt the same about that! Additionally, can we see how adding a divider between level two headings (using your screenshot as an example, that would be between Import, Props, and CSS) feels like to better separate them?

I tried the dividers, but not entirely convinced
About the ref, it could be added into the other props with the description "propagated to the root element"

@gerdadesign heya, thank you for the feedback! 🙏 Few thoughts in response:
Re warning alerts:

looks like there should be some instances of a code block inside of each warning label, but those aren't rendering.

What do you mean? 🤔 They might be there in some component API docs.

the border color doesn't match the design (grey instead of yellow / 100). I think the yellow theme helps it read better over the grey.

Yeah, I had designed it originally with the light yellow border but I don't know, it looks too bright and sort of clashing, having just the background yellow kinda communicates the same way with a more sober design. What do you think?

yellow border
gray border

there's different stylings throughout the docs (see screenshots below). Can we make these consistent?

They're mostly with the same styles even though under the hood they're different things (some are customized Material UI Alerts and some are stray containers). However, the biggest impact is the rendering of the icon, which in the case of the Alerts, actually renders as an svg instead of a Unicode. Definitely would want to make this consistent, though ⎯ @alexfauquette thoughts?
Re code blocks:
Not sure if that was exactly what you were saying but it made me reflect that code blocks within paragraphs should probably be made gray instead of the blue we currently have. That way, we can save the blue color for both the prop name and the default value, which started to make much more sense to me visually!

This is looking awesome! 🎉
There's only two small things that stood out out to me:

The labels for default and Signature seem to kind of blend into the description section IMO, even though they are usually on a new line, and they're a bit bolder. I would increase the font-weight even more for this to create a bigger distinction.
Also, this is super tiny, but when we have both default and signature sections, it stands out to me that default is followed by a colon, but signature isn't. 🙈
The 'props' and 'css' section respect the same structure and that's awesome for consistency. However, in the props section we display the type above the divider, while the css section showcases the rule name on the same slot, with the same styling. I would suggest creating some sort of distinction between these, maybe changing the color of the type would do it.

Suggestion:

there's different stylings throughout the docs (see screenshots below). Can we make these consistent?

Nice point, It is 3 different JSdoc properties
Some context
To give some context on the pipeline: Each components have props type. From here we generate a JSON with all their properties (description, deprecated, notes, ...)
From this JSON the PropertiesTable.js render what you're seeing. The difference are provided by different parts
1st case

It's just some text from the description
/**
     * If `true`, the ripple effect is disabled.
     *
     * ⚠ Without a ripple there is no styling for :focus-visible by default. Be sure
     * to highlight the element by applying separate styles with the `.Mui-focusVisible` class.
     * @default false
     */
    disableRipple?: boolean;

2nd case

It's a @deprecated comment such as the following one
/**
   * @deprecated Use `slots.backdrop` instead. While this prop currently works, it will be removed in the next major version.
**/

3rd case
This is added for all components accepting ref
let notes = '';
if (isElementAcceptingRefProp(type) || isElementTypeAcceptingRefProp(type)) {
  notes +=
    '⚠ [Needs to be able to hold a ref](/material-ui/guides/composition/#caveat-with-refs).';
}

What can be done
I will simplify the 3rd case such that it renders the same way deprecated (2dn case)
For the 1st case, I would be in favor of waiting for a refinement PR since it implies modifying how the JSdocs description is interpreted.
About the code samples in the deprecated section
You can show them with this diff. But as you can see on the next screenshot it would require few CSS updates 🙈
diff --git a/docs/src/modules/components/PropertiesTable.js b/docs/src/modules/components/PropertiesTable.js
index c365410520..a1efbe8cba 100644
--- a/docs/src/modules/components/PropertiesTable.js
+++ b/docs/src/modules/components/PropertiesTable.js
@@ -102,8 +102,8 @@ export default function PropertiesTable(props) {
                     <span
                       dangerouslySetInnerHTML={{
                         __html: propData.deprecationInfo
-                          .replace(//g, '')
-                          .replace(/<\/code>/g, ''),
+                          // .replace(//g, '')
+                          // .replace(/<\/code>/g, ''),
                       }}
                     />
                   )}

@noraleonte appreciate the feedback! 🙏 Just to see if I'm getting your suggestion clearly: you're saying to use different colors for the Props type vs. the CSS rule? In that image, they'd be "array" and "root" respectively, right? Would you mind elaborating a bit more on how's that helpful?

@danilo-leal Sure! To me it seems that the two are conveying different information. I get how placing them on the same level within similar layouts makes sense, but I feel like there needs to be a distinction between them. That is why I suggested the different colors. Does that make sense?

Warning Alerts

Yeah, I had designed it originally with the light yellow border but I don't know, it looks too bright and sort of clashing, having just the background yellow kinda communicates the same way with a more sober design. What do you think?

I do think the yellow border looks better for a couple reasons: for one, the color is more connected to message, and secondly it's more consistent with the patterns already established of having the border colors be the same hue, but more saturated than the background colors. We see this throughout as light grey background/darker gray border and light blue background / bright blue border.

looks like there should be some instances of a code block inside of each warning label, but those aren't rendering.

What do you mean? 🤔 They might be there in some component API docs.

This is the before/after of the Modals page. It's how slotProps.backdrop is being handled. Seems like @alexfauquette proposed a way to address that moving forward!

Before
After

Code blocks

Not sure if that was exactly what you were saying but it made me reflect that code blocks within paragraphs should probably be made gray instead of the blue we currently have. That way, we can save the blue color for both the prop name and the default value, which started to make much more sense to me visually!

Yes! 100%! we are on the same page.

Circling back to this one! The warning alert border colors have been changed already in some of the previous commits 😬
@DavidCnoops about your suggestion, that was actually one the first iterations I've played with [1], but through discussing with some of the team, we figured it was too verbose with lots of repeating "Type" + "Default". Either way, I do think the point about scalability is important and given you were sort of seeing this with fresh eyes, it makes me wonder how many other people will struggle to figure it out at a glance what is what. One benefit of this approach would be the simplification of the prop header (removal of the accordion) + capacity to make the whole prop header clickable again. Don't think we need to add "Description", though ⎯ maybe just "Type" & "Default" is enough?!
@alexfauquette What do you think?
[1] Mentioned iteration:

@danilo-leal While reading material-minimal, I thaught about this PR, and it matches your comment

one downside of this approach is that you get an increased vertical height of each prop "block", which is an expensive thing here.

In the following example, they only keep what matters (pay button 😈) and put all the rest into a menu

I start to think we could do the same with the API page since we have two goals:

Should be easy to browse in order to see if the props you're looking for exist
Should be complete and extendable to put all the useful information

The simplest state could be only the props' name and description. It's enough to browse, and the extended stats could add all the other information
I tried a PoC to see how such an interface would feel. There is some stuff that are not working on purpose (it's a poc) such as types are still into the header, the expend button is present even if their is nothing to expend. But ven knowing all that, I'm not entirely convinced because the opening action creates some noise
https://github.com/mui/material-ui/pull/38006

@DavidCnoops About this comment, I'm wondering, how much time did it took to get that clear? I'm assuming after 4 or 5 items you see with string or number, you catch it and from here you can use the page. But I might be biased because I do not remember using the table header

In the new layout it wasn't immediately clear to me that the lists contains prop name - prop type combo's because of the lack of labels. In that regard, I prefer the old table design that shows the 'Name', 'Type', etc. legend in the table header.

About using aligning the description with other information, I agree it makes sense as long as we manage to get those left title small enough.

Overall I think we are reaching an equilibrium where we balance between those two directions:

Be explicit and pay the cost of size-consuming components
reduce the size with implicit information such as types into the header, and get a less clear specification

We could try one or two iteration on that topic, and at the end of July merge it to get user feedback.
We could add on top of API pages a clossable message

Hey! Api pages got a refreshing design 🎨🎉
Hope it will improve you experience. Here is the new structure

And at the bottom another one

Did you enjoy the new APi design? Come into the issue to share your opinion💬

Could also be a small survey to get feedbacks on different API design variation we have in mind

@alexfauquette woo, thanks for such a detailed response comment! I love the idea of having a sort of explanation block on top of each API page announcing & explaining the layout change while also giving the opportunity of dropping targeted feedback (would it be possible to just use the existing the docs-feedback infra for it, with some type of flag that says it is related to these changes?)
That said, I think the only change I'd experiment with before merging is having the "type" content be at the same level as the "default" value ⎯ similar to the mockup above! Would that be possible to do?

I moved type description from the body to the header of props API.
To simplify the alignment I also reorganized the default/typt/signature definitions with the following structure. It's style with display: table to ensure the alignment of all the descriptions (especially the signature)

// This is a table row

// This is a table cell

Default:

// This is a table cell
      {propDefault}

  {/* Repeat for types and signature */}

https://github.com/mui/material-ui/pull/37405/commits/3a735c52c9dc205fd8b5be672ae15ff9df6fe77a

@alexfauquette this is amazing, thanks for working on this! I ended up customing the alignment a bit more, simplifying it to use flex as the additional white space on "Type", especially once there's "Signature" present, was bothering me a bit 😬 Also did some tweaking to the feedback alert, which is super exciting to have!
Lastly, is there a scalable way ⎯ instead of going case by case ⎯ to remove the
 on "Type" entries like these?

Thanks for the feedback item, it's much better 👌
I removed the
, and ok for flex instead of table
For me we are good for merging 👍

Great work everyone! I really like this last iteration with the type on the same hierarchy. And nice touch by adding the alert with a way for users to provide feedback—I wonder if we shouldn't move it up on the page, at least in the first week after launch. With the new design, the pages are longer, and usually users would search for things by cmd + f on pages like this, making us lose some valuable feedback from people who don't scroll down to the end of the page.

Interesting take! @alexfauquette had originally put it on the top of the page but I ended up thinking that moving it to the bottom would be better because if you're not in the mood to give feedback, it's extra space + scroll that we're requiring from you. Although the idea of having it on the top just for the first week isn't bad, either. But maybe we could call attention out to this one on Twitter/blog and expose that there's such a place to drop feedback?

I had same concern as @zanivan when creating it. My thought process was the next one:

We need to catch the attention, so let's put the message on top
It's too noisy so let the user close the item
But it should still allow to send the feedback
Ho no, I'm in a trap, I need a Schrodinger alert: closed and open at the same time 🙈

Having it at the bottom seems to be a nice compromise because we have components with very small API pages for which it will be easier to see the warning.
For example mui.com/material-ui/api/card/ which gets more than 1.5k visits per day

@alexfauquette it looks great 👌

@alexfauquette I have noticed an important regression from these changes, the API pages are no longer index in Algolia. For example, "autoHighlight" does no longer return any results. To compare with https://v4.mui.com/.
To fix this, we need to go to https://crawler.algolia.com/admin/crawlers/739c29c8-99ea-4945-bd27-17a1df391902/configuration/edit and update the crawler configuration. Could you fix this? I could fix it but I feel it would be a great opportunity to learn more about the crawler if you haven't already.

@alexfauquette Thanks, you fixed it :)
            lvl3: [".algolia-lvl3", ".markdown-body h3, .MuiApi-item-title"],

@oliviertassinari Even better, now the autoHighligh search leads you to the props itself (not just to the props table 😍)


Variable names in describe_data('reanalysis-era5-land') different than what can be used in a request

When describing the dataset reanalysis-era5-land from cds data store, the output of variable names is like shown in the screenshot.
store.describe_data('reanalysis-era5-land')

When I select two of the variables according to the information above I get an error:
dataset = store.open_data('reanalysis-era5-land',
                          variable_names=['stl1', 'stl2'],
                          spatial_res=0.1,
                          bbox = [-180, 40, 180, 90],
                          time_range=['2001-01-01', '2001-06-30'])
dataset

Traceback
xcube-cds version 0.9.2
---------------------------------------------------------------------------
ValidationError                           Traceback (most recent call last)
Cell In[10], line 1
----> 1 dataset = store.open_data('reanalysis-era5-land',
      2                           variable_names=['stl1', 'stl2'],
      3                           spatial_res=0.1,
      4                           bbox = [-180, 40, 180, 90],
      5                           time_range=['2001-01-01', '2020-12-31'])
      6 dataset

File /home/conda/deepesdl/4f055d4cb9f5a7bb59c11d4f960211d16d612f0f49fe5f6f4a110ccac09352f7-20230630-130445-100057-279-xcube-1.1.2/lib/python3.11/site-packages/xcube_cds/store.py:835, in CDSDataStore.open_data(self, data_id, opener_id, **open_params)
    833 self._assert_valid_opener_id(opener_id)
    834 self._validate_data_id(data_id)
--> 835 return super().open_data(data_id, **open_params)

File /home/conda/deepesdl/4f055d4cb9f5a7bb59c11d4f960211d16d612f0f49fe5f6f4a110ccac09352f7-20230630-130445-100057-279-xcube-1.1.2/lib/python3.11/site-packages/xcube_cds/store.py:433, in CDSDataOpener.open_data(self, data_id, **open_params)
    430 save_request_to = open_params.pop('_save_request_to', None)
    432 schema = self.get_open_data_params_schema(data_id)
--> 433 schema.validate_instance(open_params)
    434 handler = self._handler_registry[data_id]
    436 # Fill in defaults from the schema

File /home/conda/deepesdl/4f055d4cb9f5a7bb59c11d4f960211d16d612f0f49fe5f6f4a110ccac09352f7-20230630-130445-100057-279-xcube-1.1.2/lib/python3.11/site-packages/xcube/util/jsonschema.py:131, in JsonSchema.validate_instance(self, instance)
    124 custom_validator = \
    125     jsonschema.validators.extend(base_validator,
    126                                  type_checker=new_type_checker)
    128 # jsconschema needs extra packages installed to validate some formats;
    129 # if they are missing, the format check will be skipped silently. For
    130 # date-time format, strict_rfc3339 or rfc3339-validator is required.
--> 131 jsonschema.validate(instance=instance, schema=self.to_dict(),
    132                     cls=custom_validator,
    133                     format_checker=jsonschema.draft7_format_checker)

File /home/conda/deepesdl/4f055d4cb9f5a7bb59c11d4f960211d16d612f0f49fe5f6f4a110ccac09352f7-20230630-130445-100057-279-xcube-1.1.2/lib/python3.11/site-packages/jsonschema/validators.py:1121, in validate(instance, schema, cls, *args, **kwargs)
   1119 error = exceptions.best_match(validator.iter_errors(instance))
   1120 if error is not None:
-> 1121     raise error

ValidationError: 'stl1' is not one of ['10m_u_component_of_wind', '10m_v_component_of_wind', '2m_dewpoint_temperature', '2m_temperature', 'evaporation_from_bare_soil', 'evaporation_from_open_water_surfaces_excluding_oceans', 'evaporation_from_the_top_of_canopy', 'evaporation_from_vegetation_transpiration', 'forecast_albedo', 'lake_bottom_temperature', 'lake_ice_depth', 'lake_ice_temperature', 'lake_mix_layer_depth', 'lake_mix_layer_temperature', 'lake_shape_factor', 'lake_total_layer_temperature', 'leaf_area_index_high_vegetation', 'leaf_area_index_low_vegetation', 'potential_evaporation', 'runoff', 'skin_reservoir_content', 'skin_temperature', 'snow_albedo', 'snow_cover', 'snow_density', 'snow_depth', 'snow_depth_water_equivalent', 'snow_evaporation', 'snowfall', 'snowmelt', 'soil_temperature_level_1', 'soil_temperature_level_2', 'soil_temperature_level_3', 'soil_temperature_level_4', 'sub_surface_runoff', 'surface_latent_heat_flux', 'surface_net_solar_radiation', 'surface_net_thermal_radiation', 'surface_pressure', 'surface_runoff', 'surface_sensible_heat_flux', 'surface_solar_radiation_downwards', 'surface_thermal_radiation_downwards', 'temperature_of_snow_layer', 'total_evaporation', 'total_precipitation', 'volumetric_soil_water_layer_1', 'volumetric_soil_water_layer_2', 'volumetric_soil_water_layer_3', 'volumetric_soil_water_layer_4']

Failed validating 'enum' in schema['properties']['variable_names']['items']:
    {'enum': ['10m_u_component_of_wind',
              '10m_v_component_of_wind',
              '2m_dewpoint_temperature',
              '2m_temperature',
              'evaporation_from_bare_soil',
              'evaporation_from_open_water_surfaces_excluding_oceans',
              'evaporation_from_the_top_of_canopy',
              'evaporation_from_vegetation_transpiration',
              'forecast_albedo',
              'lake_bottom_temperature',
              'lake_ice_depth',
              'lake_ice_temperature',
              'lake_mix_layer_depth',
              'lake_mix_layer_temperature',
              'lake_shape_factor',
              'lake_total_layer_temperature',
              'leaf_area_index_high_vegetation',
              'leaf_area_index_low_vegetation',
              'potential_evaporation',
              'runoff',
              'skin_reservoir_content',
              'skin_temperature',
              'snow_albedo',
              'snow_cover',
              'snow_density',
              'snow_depth',
              'snow_depth_water_equivalent',
              'snow_evaporation',
              'snowfall',
              'snowmelt',
              'soil_temperature_level_1',
              'soil_temperature_level_2',
              'soil_temperature_level_3',
              'soil_temperature_level_4',
              'sub_surface_runoff',
              'surface_latent_heat_flux',
              'surface_net_solar_radiation',
              'surface_net_thermal_radiation',
              'surface_pressure',
              'surface_runoff',
              'surface_sensible_heat_flux',
              'surface_solar_radiation_downwards',
              'surface_thermal_radiation_downwards',
              'temperature_of_snow_layer',
              'total_evaporation',
              'total_precipitation',
              'volumetric_soil_water_layer_1',
              'volumetric_soil_water_layer_2',
              'volumetric_soil_water_layer_3',
              'volumetric_soil_water_layer_4'],
     'minLength': 0,
     'type': 'string'}

On instance['variable_names'][0]:
    'stl1'

In the traceback I can see what the variable name should be and if I adjust accordingly, it is fine:
dataset = store.open_data('reanalysis-era5-land',
                          variable_names=['soil_temperature_level_1', 'soil_temperature_level_2'],
                          spatial_res=0.1,
                          bbox = [-180, 40, 180, 90],
                          time_range=['2001-01-01', '2001-06-30'])
dataset

I would expect describe data to return the variable names which are supposed to be used for the request.

And once I get the dataset from the cds store
The variables are again called differently than in the request! Quite confusing and incosistent.

Isn't this a duplicate of #15 ?

Isn't this a duplicate of https://github.com/dcs4cop/xcube-cds/issues/15 ?

Looks like it, but we do not use the UI at all anymore. So how about closing 15 and adress this issue here?

Looks like it, but we do not use the UI at all anymore. So how about closing 15 and adress this issue here?

OK, I can copy-paste the relevant content from #15 (there isn't much).

Some background, adapted from comments at #15 :
The CDS API doesn't have unified variable names between the request and the result -- in some cases, e.g. in the soil moisture data set, there isn't even a one-to-one mapping between the two sets of variables. the CDS store plugin generally tries to provide a thin interface to the CDS API (i.e. manipulates the requests and results as little as possible). Of course it would be possible to expand the scope of the plugin to rename variables and unify the two schemes, but that's quite a lot of implementation and maintenance effort. We should discuss whether this ought to be a design goal for the plugin (and for other data store plugins).
Comment from 2021-02-21: After discussion today: still no clear resolution on how we should proceed with this, so I'm leaving the bug open but not actively working on it.

To expand on the earlier comments above: data_vars in the return value of describe_data for a data store describes the values you can expect to see in the returned dataset. The parameters you can use in the request are not described under data_vars but under open_params_schema (which you can also get by calling get_open_data_params_schema), and there is no guarantee that the parameters schema will contain a list of variable names which corresponds exactly with those in the returned dataset. Indeed, there isn't even a guarantee that there will be a list of variable names in the parameter schema at all (e.g. it might be a one-variable dataset that therefore doesn't need to to explicitly specify the variables).
In the CDS store, the parameter schema is taken as directly as possible from the parameter schema of the CDS backend itself, so e.g. for reanalysis-era5-land, the user can browse around at https://cds.climate.copernicus.eu/cdsapp#!/dataset/reanalysis-era5-land-monthly-means?tab=form and use the same parameter names in their xcube request.

Plan, after internal discussion: expand the parameter schema and implementation to include, as an alternative to variable_names, an additional parameter era5_variable_names, where the caller can specify the requested variable names using the ERA5 identifiers (matching the names in the returned dataset) instead of the CDS identifiers. Implementation should be fairly straightforward, since the store already has a table to map between these identifiers.


Improve error message for "Entry not found in cache"

When users receive the entry not found in cache error, suggest a resolution step for them -- "Hint: try reloading VS Code to resolve the issue"

This was fixed in https://github.com/microsoft/vscode-azuretools/pull/825 and https://github.com/microsoft/vscode-azureappservice/pull/1882


Allow window title bars to be removed

Resolves #217
This adds the ability to hide window title bars, as a new plugin. This only applies to windows created after workspacer starts up.
Changes:

Added workspacer.TitleBar project.
Changed Win32.WS and Win32.WS_EX to be long instead of ulong.
I did this because Win32 functions like SetWindowLongPtr specify LONG_PTR instead of ULONG_PTR (though I'm not sure it matters much).
Added methods SetWindowStylePtr and SetWindowStyleExLongPtr to set window styles.
Add the ability to set/remove WS_CAPTION and WS_THICKFRAME (see docs.microsoft.com: Window Styles).
Added documentation to config.md

Available window styles:

(NOTE: screenshot taken on Windows 11, hence the rounded borders)

@sitiom thanks for fixing those build issues - they were driving me insane!

Thank you for this!

Seems like this PR currently has some conflicts with git master.
Fix it up and prep for another review? 🙂

This PR separates test-projects from normal code by putting it in a different, "less important" folder.
As someone who believes in rigid test-automation, I think this is a wrong move.
When I introduced xUnit tests to workspacer (that was me), I intentionally placed all the test-projects alongside normal production code, because the test-suite is required to ship.
IOW: The tests are production code too and should be treated as such.
And the best way to keep them like that is to keep them close to the code they're testing.
As such, moving them away from the code under test is a dramatically opposite move to what I consider good form, that I will reject this PR until that is reverted.
Also: A single PR really should focus on changing only one thing.
Right now this PR conflates several changes into one branch, causing merge-conflicts and preventing the good bits in there (there are!) from being merged.
Please try to be a bit more disciplined when making feature-branches in the future. Keeping them small is a good thing.

This PR separates test-projects from normal code by putting it in a different, "less important" folder.

It's not a less important folder, it keeps things organized and that's how most projects actually do it.

When I introduced xUnit tests to workspacer (that was me), I intentionally placed all the test-projects alongside normal production code, because the test-suite is required to ship.
IOW: The tests are production code too and should be treated as such.

Why would production code be dependent on a test suite? Why bloat assemblies with unit tests?
Even currently, the unit tests are not shipped with the production code and the change only separates the test projects with no actual change with the output anyway.

Also: A single PR really should focus on changing only one thing.

Although I agree it to be in a separate PR, sure.

Looking over the current code, it looks pretty good.
There's some left-overs from the previous test-code changes causing the diff to be "noisier" than it needs to be, and in some places not entirely cleaned up. There's also the core business-logic of this module which might benefit from some minor testing.
Apart from that, I think this looks good, and once those things are sorted out, I'll be happy to green-light and merge this PR :+1:

Approved and updated. Sorry about the slow response!


Setting Content-Encoding header for Cloud Storage Uploads with upload_from_file

I'm on Python 3.5.2 with google.cloud.storage.__version__ = '0.23.0'.
I'm attempting to upload objects to a bucket such that the object supports decompressive gzip transcoding.  I haven't been able to figure out how to accomplish this after searching through the documentation and the code as well as reviewing existing issues.  My most promising attempt was setting the blob.content_encoding property, which seems like it should work but doesn't.  See below for an example.
Does/can the API support this?
import google.cloud.storage
import gzip
import os
import requests
import datetime
import io

BUCKET_NAME = ...
GOOGLE_APPLICATION_CREDENTIALS_PATH = ...

os.environ['GOOGLE_APPLICATION_CREDENTIALS'] = GOOGLE_APPLICATION_CREDENTIALS_PATH
client = google.cloud.storage.Client()
bucket = client.get_bucket(BUCKET_NAME)

blob = bucket.blob('plaintext')
blob.content_type = 'text/plain'
with io.BytesIO() as f:
    f.write(b' '.join(100*(b'plaintext', )))
    blob.upload_from_file(f, size=f.tell(), rewind=True)
url = blob.generate_signed_url(datetime.datetime.max)
"""
This prints:

b'plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext plaintext' None
"""
response = requests.get(url)
print(response.content, response.headers.get('Content-Encoding', None))

blob = bucket.blob('compressed')
blob.content_type = 'text/plain'
blob.content_encoding = 'gzip'
with io.BytesIO() as f:
    with gzip.GzipFile(fileobj=f, mode='wb',  compresslevel=9) as fgz:
        fgz.write(b' '.join(100*(b'compressed', )))
    blob.upload_from_file(f, size=f.tell(), rewind=True)
url = blob.generate_signed_url(datetime.datetime.max)
"""
This prints:

b'\x1f\x8b\x08\x00\xac}\xbbX\x02\xffK\xce\xcf-(J-.NMQH\x1ee\x8e2G\x99\xa3L2\x99\x00/\x80\x15\xa7K\x04\x00\x00' None
"""
response = requests.get(url)
print(response.content, response.headers.get('Content-Encoding', None))

"""
If I manually set the content-encoding header through the metadata option on this object in the console, I get the appropriate response:

b'compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed compressed' gzip
"""
response = requests.get(url)
print(response.content, response.headers.get('Content-Encoding', None))

Hi @brianjpetersen,
Thanks for raising this, and sorry it took a couple days for us to say anything in response.
Let me summarize to make sure I understand the problem. Basically there seems to be no obvious valid way to set the Content-Encoding in the metadata to gzip and have it stick in storage. Is that correct?

That's right.  Setting the content_encoding attribute to 'gzip' on the object before uploading doesn't actually result in proper transcoding on subsequent GETs to Cloud Storage.  Furthermore, the metadata on the uploaded object (viewed in the Cloud Storage in the web console) doesn't reflect that the Content-Encoding was set to 'gzip' (see below).

Thanks. We will look into it.

This is a duplicate of several bugs, summed up in this comment, which also has a work-around.

Many thanks @pdknsk.
This workaround fixes the problem, although as noted in #754, the property update isn't atomic which has all sorts of nasty implications.  As another commenter noted in a linked thread, unfortunately this prevents me from using gcloud-python (and Google Cloud Platform) at this time.

I remembered a patch I had once used, which I've updated now. An alternative is to use the API directly, which is more complex.

This unfortunately didn't seem to do the trick for the content_encoding property.

Works for me.
>>> compressobj = zlib.compressobj(9, zlib.DEFLATED, 31) # 31 = gzip
>>> text_gzip = compressobj.compress('text') + compressobj.flush()
>>> len(text_gzip)
24
>>> text = bucket.blob('file.txt')
>>> text.cache_control = 'no-cache'
>>> text.content_encoding = 'gzip'
>>> text.upload_from_string(text_gzip)
>>> text.reload()
>>> text.size
24
>>> req = requests.get(text.public_url)
>>> req.content
'text'
>>> req.headers.get('Content-Encoding')
'gzip'

In the browser too.

Apologies @pdknsk, pip and I weren't getting along last night.  This does indeed address my need.  You've been super helpful - thanks.

Although this contrived example works, now I'm getting a gzip-decoding error from requests with larger payloads.  Using your example (slightly modified for Python 3):
>>> compressobj = zlib.compressobj(9, zlib.DEFLATED, 31) # 31 = gzip
>>> text_gzip = compressobj.compress(100*b'text') + compressobj.flush()
>>> len(text_gzip)
24
>>> text = bucket.blob('file.txt')
>>> text.cache_control = 'no-cache'
>>> text.content_encoding = 'gzip'
>>> text.upload_from_string(text_gzip)
>>> req = requests.get(text.public_url)

Traceback (most recent call last):
  File "/Users/brianjpetersen/Anaconda/python3/anaconda/lib/python3.5/site-packages/requests/packages/urllib3/response.py", line 192, in _decode
    data = self._decoder.decompress(data)
  File "/Users/brianjpetersen/Anaconda/python3/anaconda/lib/python3.5/site-packages/requests/packages/urllib3/response.py", line 58, in decompress
    return self._obj.decompress(data)
zlib.error: Error -3 while decompressing data: invalid distance too far back

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/brianjpetersen/Anaconda/python3/anaconda/lib/python3.5/site-packages/requests/models.py", line 664, in generate
    for chunk in self.raw.stream(chunk_size, decode_content=True):
  File "/Users/brianjpetersen/Anaconda/python3/anaconda/lib/python3.5/site-packages/requests/packages/urllib3/response.py", line 349, in stream
    for line in self.read_chunked(amt, decode_content=decode_content):
  File "/Users/brianjpetersen/Anaconda/python3/anaconda/lib/python3.5/site-packages/requests/packages/urllib3/response.py", line 503, in read_chunked
    flush_decoder=False)
  File "/Users/brianjpetersen/Anaconda/python3/anaconda/lib/python3.5/site-packages/requests/packages/urllib3/response.py", line 197, in _decode
    "failed to decode it." % content_encoding, e)
requests.packages.urllib3.exceptions.DecodeError: ('Received response with content-encoding: gzip, but failed to decode it.', error('Error -3 while decompressing data: invalid distance too far back',))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "test.py", line 47, in <module>
    response = requests.get(url)
  File "/Users/brianjpetersen/Anaconda/python3/anaconda/lib/python3.5/site-packages/requests/api.py", line 71, in get
    return request('get', url, params=params, **kwargs)
  File "/Users/brianjpetersen/Anaconda/python3/anaconda/lib/python3.5/site-packages/requests/api.py", line 57, in request
    return session.request(method=method, url=url, **kwargs)
  File "/Users/brianjpetersen/Anaconda/python3/anaconda/lib/python3.5/site-packages/requests/sessions.py", line 475, in request
    resp = self.send(prep, **send_kwargs)
  File "/Users/brianjpetersen/Anaconda/python3/anaconda/lib/python3.5/site-packages/requests/sessions.py", line 617, in send
    r.content
  File "/Users/brianjpetersen/Anaconda/python3/anaconda/lib/python3.5/site-packages/requests/models.py", line 741, in content
    self._content = bytes().join(self.iter_content(CONTENT_CHUNK_SIZE)) or bytes()
  File "/Users/brianjpetersen/Anaconda/python3/anaconda/lib/python3.5/site-packages/requests/models.py", line 669, in generate
    raise ContentDecodingError(e)
requests.exceptions.ContentDecodingError: ('Received response with content-encoding: gzip, but failed to decode it.', error('Error -3 while decompressing data: invalid distance too far back',))

Is this possibly related to #1724?

@brianjpetersen googling that error for requests got me to this SO question which lead me to the following issue.
See: https://bugs.python.org/issue27164
It sounds like there's an issue with Python 3.5.2.  If you upgrade do you still have the same issue?

That seems to be it.  It's working on my 2.7 binary.  Thanks.

OK great! I'm going to close this then.

Using Python 2.7 and the latest (as of this date) google-cloud module, this problem still occurs when using upload_from_string.

To make it even stranger, I get this intermittently on Python 3.7.1 and latest google-cloud-python.


ApiController + binding on WebHook actions = sadness

Consider:
[ApiController]
public class WebHookController : ControllerBase
{
    [StripeWebHook]
    public IActionResult Post(string id, string notificationId, string @event)
    {

    }
}

None of the 3-values get bound. This is because ApiController assumes these parameters come from query (they don't exist in route) and consequently assigns a FromQuery attribute on it. We should either
a) Make the behavior on ApiController less stringent (not set a binding source constraint on parameters)
b) Make WebHook set up the right metadata for this to work.

Let's be clear here: Were you sad or frustrated? I'd be frustrated!

BTW this issue relates to #240. WebHooks needs a few adjustments both to use some new 2.1 features e.g. ModelStateInvalidFilter and to avoid conflicts with other new 2.1 features e.g. [ApiController]. I like splitting the two sides of the coin: Handle the conflicts in this issue and think about using more new features in #240.

Inclinations:

throw an InvalidOperationException if mix of [ApiController] and a WebHook action is detected.
Is it possible to ensure the WebHook application model changes "win" for the WebHook action. May need a new "I do not compose" flag.
Enhance WebHook conventions to do the Right Thing:tm: when [ApiController] is applied. Do not require [ApiController] but allow it.

Chose (1).

I am unable to reproduce this issue. @pranavkm's test case may be different from mine.
Or, perhaps something changed since Preview1 in this area. I tested in the dev branch but will retest using Preview1 bits.
Expected behavior (what I see)
MVC's ApiBehaviorApplicationModelProvider disallows use of [ApiController] and other IApiBehaviorMetadata attributes with actions that are not attribute routed. That provider executes before WebHookRoutingProvider and WebHookRoutingProvider makes the action appear to be attribute routed (and throws if it already is attribute routed). That is, ApiBehaviorApplicationModelProvider should throw when it sees a controller with [ApiController] containing an action with any [WebHook] attribute.
Details
The InvalidOperationException thrown during IApplicationModelProvider execution at startup is:
System.InvalidOperationException: Action 'GitHubCoreReceiver.Controllers.GitHubController.HandlerForItsPushes (GitHubCoreReceiver)' does not have an attribute route. Action methods on controllers annotated with ApiControllerAttribute must be attribute routed.
    at Microsoft.AspNetCore.Mvc.Internal.ApiBehaviorApplicationModelProvider.EnsureActionIsAttributeRouted(Boolean controllerHasSelectorModel, ActionModel actionModel)
    at Microsoft.AspNetCore.Mvc.Internal.ApiBehaviorApplicationModelProvider.OnProvidersExecuting(ApplictionModelProviderContext context)
    at Microsoft.AspNetCore.Mvc.Internal.ControllerActionDescriptorProvider.BuildModel()
    at Microsoft.AspNetCore.Mvc.Internal.ControllerActionDescriptorProvider.GetDescriptors()
    at Microsoft.AspNetCore.Mvc.Internal.ControllerActionDescriptorProvider.OnProvidersExecuting(ActionDeciptorProviderContext context)
    at Microsoft.AspNetCore.Mvc.Internal.ActionDescriptorCollectionProvider.UpdateCollection()
    at Microsoft.AspNetCore.Mvc.Internal.ActionDescriptorCollectionProvider.get_ActionDescriptors()
    at Microsoft.AspNetCore.Mvc.Internal.AttributeRoute.GetTreeRouter()
    at Microsoft.AspNetCore.Mvc.Internal.AttributeRoute.RouteAsync(RouteContext context)

One action (after reviewing the code)
WebHookRoutingProvider doesn't actually throw in all attribute routed cases, only when an attribute route on an action provides a Template. Should check the ControllerModel for an attribute route and check both WebHook actions and containing controllers for an HttpMethodActionConstraint i.e. the result of an applied IActionHttpMethodProvider (see DefaultApplicationModelProvider).
Should probably also check for IConsumesActionConstraints since [Consumes] interferes with WebHookEventNamesConstraints and WebHookVerifyBodyTypeFilters.

will retest using Preview1 bits.

See the  same InvalidOperationException on startup of Preview1 application.

Slightly odd the application doesn't exit due to the startup Exception. It might as well crash since the same Exception occurs when a request arrives.

@pranavkm please respond if you're able to reproduce the starting-but-not-binding behaviour.

Temporarily assigning to @pranavkm.
I want it back regardless 😈 We need to at least triage the One action ideas.

:bump:
@pranavkm please let me know how to reproduce your sadness.

@pranavkm, some boilerplate just for you 😄: Thank you for your feedback. We're closing this issue as no updates have been provided in a timely manner and we have been unable to reproduce the issue. If you have more details and are encountering this issue please add a new reply and re-open the issue.

13da6ec8ac


🐛 add an optional chain to instructions filter

metaplex AuctionHouse program change breaks the inner instruction filter because the parsed object doesn't exist

Nice. Is there an example of a transaction tx? It would be good to add a test for this.

https://solscan.io/tx/4cK3AhyF3ZzHCQSdcxHzcZP4aTGwCQwqcecnHifVNKxiVF8AmX4K4Cde3c4j7AkpkK1WmGGZnoY7QLQRXr1h7wMx

You'll see it here
https://media.discordapp.net/attachments/906187062598852638/966108570284343296/CleanShot_2022-04-19_at_17.50.152x.png


Block model config UI to eliminate ambiguity

This PR is to block the model config UI, which contains a list of models to choose, to eliminate the ambiguous experience for users when using Azure OpenAI Services.
Changed file:

app/components/model-config.tsx

You can merge the owner's latest main branch to remove other file changes.

try to reopen it to trigger file diff

I have no idea why are there still have so many changes after diff updated...  Could you please try to create a new branch based by  this branch and cherry-pick your changes? Thanks!
Have checked for feature changes and agree that masking is the best option before azure openai opening the model selection api.

@LaChimere I have no idea why are there still have so many changes after diff updated... Could you please try to create a new branch based by this branch and cherry-pick your changes? Thanks!
Have checked for feature changes and agree that masking is the best option before azure openai opening the model selection api.

I will check it later today. Thanks.


bodyclose enabled

I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en

Pull request type

Please check the type of change your PR introduces:

[ ] Bugfix
[ ] Feature
[x] Code style update (formatting, renaming)
[x] Refactoring (no functional changes, no api changes)
[x] Build related changes
[ ] Documentation content changes
[ ] Other (please describe):

What is the current behavior?

Issue Number: N/A
What is the new behavior?

Other information

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

Comparison is base (c642118) 67.50% compared to head (0c5072a) 38.81%.

Additional details and impacted files
@@             Coverage Diff             @@
##           master     #986       +/-   ##
===========================================
- Coverage   67.50%   38.81%   -28.70%
===========================================
  Files         261      213       -48
  Lines       24686    21509     -3177
===========================================
- Hits        16664     8348     -8316
- Misses       7159    12806     +5647
+ Partials      863      355      -508

Flag
Coverage Δ

?

go-1.17.x
38.51% <ø> (-27.36%)
:arrow_down:

go-1.20.x
38.82% <ø> (-28.69%)
:arrow_down:

go-1.21.x
?

integration
?

macOS
?

ubuntu
38.81% <ø> (-0.02%)
:arrow_down:

unit
38.81% <ø> (-0.11%)
:arrow_down:

windows
?

ydb-22.5
?

ydb-23.1
?

ydb-23.2
?

ydb-23.3
?

Flags with carried forward coverage won't be shown. Click here to find out more.

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


Named Routes with Before and After Hooks

Is support for hooks and named routes possible?
router.on(
	'/':
		as: 'home'
		uses: (params, query) ->
			console.log 'Router: Home Route...'
			renderHome()
		hooks:
			before: ->
				console.log 'BEFORE'
			after: ->
				console.log 'AFTER'
)

It's done. Released in 3.4.1. You can do:
router.on({
  'products': { as: 'products', uses: handler },
  'products/:productId': {
    as: 'products.id',
    uses: handler,
    hooks: { before, after }
  }
});


SADeprecationWarning: Implicit coercion of SELECT and textual SELECT constructs into FROM clauses is deprecated;

In ext/async_sqlalchemy.py:23:
SADeprecationWarning: Implicit coercion of SELECT and textual SELECT constructs into FROM clauses is deprecated; please call .subquery() on any Core select or ORM Query object in order to produce a subquery object.
    total = await session.scalar(select([func.count()]).select_from(query))

Thanks, will take a look.


Add a readme and deprecation note for rescheduler

Since we are moving to priorty and preemption, we don't need rescheduler to move pods around to make room for new pods coming in.

closing this PR in order to avoid confusion. For more info, please see https://github.com/kubernetes/kubernetes/pull/64592#issue-191919104