huggingface connect error

hi thx for your excellent work!
when the code automatically downloads the 'open_clip_pytorch_model.bin' model, the hugging face can not connect like this.

And I also try to upload the .bin file to the code, but where I should upload to. Directly up down the '～./cache/models--laion--CLIP-ViT-H-14-laion2B-s32B-b79K' also can not work.
Looking forward to your reply！

Hi, @Kai-0515 , maybe you can try adding your personal huggingface token to the downloading code or changing your cluster network.

hi where can I add my personal token?

I think you need to find which line of code through out this error and add your personal token as: pipe = pipeline("xxx", model="xxx", token="your token"). More details can be found here.


Java Swing - Clickable items not recognized

In a SUT are some menu-items and buttons for closing and minimize a window  not recognized.

First image:
JInternalFrame component, not sure which kind of components are those min, max and close buttons.
Are they childrens of this JInternalFrame?
Not allowed properties by AccessBridge?

Is that a question for me? I don't know.

In the third image menu item Wise Client Clipboard and Over dit programma isn't recognized.

Third image menu item should already be solved into "java_swing_dev" branch
I'm not sure how to solve the recognition of the "elements" of the first image.

The  up and the down button are not recognized by Testar.
Up increase the number bij 1 and down decrease the number by 1.

Oke. Close button etc are recognized now. First image.


TTL for NS-records is "stuck"

Hi,
Trying to change the NS-records for my domains. They are defaulted to 3600 (1 hour). Trying to change these to 86400 (24 hours). I set the value (for all the NS-records), hit "Save", then "Apply". Update successful. Refresh domain/page, old values are displayed (and is also what resides in the DB).
PowerDNS 4.0.0rc2 + PostgreSQL DB backend.

"Apply"-button calls for /domain/$domain/apply, which hits record_apply().
Records sent to Record.apply() has new TTL value (86400).
Records in for r in new_records: have new TTL value.
final_records does not have new TTL value (it's now been replaced with the old value).

Culprit seems to be related to NEW_SCHEMA, and in turn changes done in #5.

if NEW_SCHEMA:
            records = sorted(records, key = lambda item: (item["name"], item["type"]))
            for key, group in itertools.groupby(records, lambda item: (item["name"], item["type"])):
                new_record = {
                        "name": key[0],
                        "type": key[1],
                        "ttl": records[0]['ttl'],
                        "changetype": "REPLACE",
                        "records": []
                    }

This sets the TTL of a record to whatever is stored first in records (after the sort). Probably not what we want...

I've patched it successfully, but there needs to be more logic in Record.apply(). The API in 4.0.0 seems to limit the TTL to be set per RRset-entry, which means that the logic should handle each TTL for each type of RRset.
https://doc.powerdns.com/md/httpapi/api_spec/#url-apiv1serversserver95idzoneszone95id
E.g. if we have one NS-record with TTL 3600 and another NS-record with TTL 86400, they should be put into two RRset's.

How is the API supposed to handle different TTL's?
According to https://doc.powerdns.com/md/httpapi/api_spec/#url-apiv1serversserver95idzoneszone95id ;

changetype Must be REPLACE or DELETE. With DELETE, all existing RRs matching name and type will be deleted, including all comments. With REPLACE: when records is present, all existing RRs matching name and type will be deleted, and then new records given in records will be created. If no records are left, any existing comments will be deleted as well. When comments is present, all existing comments for the RRs matching name and type will be deleted, and then new comments given in comments will be created.

So, since changetype is REPLACE, all records with same name/type are deleted, and then re-created. Since TTL now is set per RRset, this means records not matching the TTL, would be deleted. For good.

I guess the PR (#75) could be more a bit more "nice" and/or smart about it. That is, don't delete, but set both to the same TTL value (either from DB, or the new TTL). I'll take a look at it. Then the warning-suggestion (#76) would be "obsolete".

Okay, after a bit of testing, PR #95 should do the trick. It fixes so that it doesn't use the same TTL for the entire RRset (only the same name and type), which fixes the "stuck" issue I had. It also address the issue when you try setting different TTL-values for the same name+type.
If you have the following two entries;
@ 3600 NS ns1.foo.bar
@ 3600 NS ns2.foo.bar

...and you try changing one of them to TTL=1800, it would not delete any of them, and it would set the TTL to the same for both entries, using whatever entry is topmost in the record-table when you hit "Apply Changes".

#76 is no longer relevant imho, and I closed it.

@ngoduykhanh -- food for you (-:

If you have the following two entries;

@ 3600 NS ns1.foo.bar
@ 3600 NS ns2.foo.bar
...and you try changing one of them to TTL=1800, it would not delete any of them, and it would > set the TTL to the same for both entries, using whatever entry is topmost in the record-table when you hit "Apply Changes".

@jallakim : I tried but it didn't work. I have a comment at your PR :)

@ngoduykhanh - Ah, yes, my bad. Tested with the wrong branch. Should work now (-:

Fixed in PR #95.


fix: Indent the "Calculating monthly cost estimate" spinner

This makes the indenation on the "Calculating monthly cost estimate" spinner consistent with the other spinner lines.  It looks like they have been inconsistent for a while, but recent changes removed the blank line so it is now more apparent.
Old:
Detected Terraform directory at ./examples/terraform
  ✔ Checking for cached plan... found
✔ Calculating monthly cost estimate

With this fix:
Detected Terraform directory at ./examples/terraform
  ✔ Checking for cached plan... found
  ✔ Calculating monthly cost estimate

The reason for this originally is that the indented spinners are for a specific project, but the Calculating monthly cost estimate spinner is for all projects. Saying that, if this doesn't look confusing for multiple projects then I think it's good to go.

The recent parallelism changes effect how logging for multiple projects is displayed so maybe the original reasoning isn't relevent.  With two projects and parallelism 1 i get
Detected Terraform directory at examples/terraform
  ✔ Checking for cached plan... found
  ✔ Calculating monthly cost estimate

Detected Terraform directory at examples/terraform
  ✔ Checking for cached plan... found
  ✔ Calculating monthly cost estimate

👍  makes sense, thanks!


ComboBoxBackgroundUnfocused is not used reasonably

Describe the bug
In order to change the background of a ComboBox when it becomes focused, you have to modify the ComboBoxBackgroundUnfocused brush, since this controls HighlightBackground, which becomes opaque only on focus.
Steps to reproduce the bug
Try in vain to style the focus look of the background of a ComboBox using lightweight styling only to find out you have to modify ComboBoxBackgroundUnfocused
Expected behavior
The brush to modify would be named ComboBoxBackgroundFocused

Thanks for reporting this! definitely seems like a bug.

I would like to work on this.


Add option to index full string field

Background
At the moment, data type string uses a minimal tokenization logic that only splits at the word level, i.e. by using spaces (" "). This means that when matching for multi-word queries, anything that contains those (but also others) will be returned.
For example, given the following three documents:
- id: 1
   color: `grey`
- id: 2
   color: `light grey`
- id: 3
   color: `red`

And a query such as:
where: {
      operator: Equal
      path: ["color"]
      valueString: "grey"
    }

will return both object id:1 and id:2.
If the user is only interested in returning id: 1 there is no option
Goals

[ ] default behavior is not changed
[ ] the user can optionally set a flag to index the field as a whole. This flag must be immutable. TODO: @etiennedi to propose API
[ ] if the flag is set, tokenization is skipped entirely both at import and query time

Notes

This behavior only makes sense for fields of type string, not of type text, so it should only be possible there.
Some fields (anything that's not text or string) already matches the full field, keep this in mind depending on the default values.

Just to elaborate on the example, imagine the following documents:
- id: 1
   color: ['light grey', 'midnight blue']
- id: 2
   color: [light 'blue']

where: {
      operator: Equal
      path: ["color"]
      valueString: "light blue"
}

Is currently also returning both products. Not sure if arrays are in scope for this change already, but have a similar issue at the moment 😄

Great input, thanks. I did not think about arrays, yet. I guess in the above example the expectation would be that product 2 is returned but 1 isn't?

Yeah exactly!


btn-outline

Bootstrap uses this http://bootsnipp.com/snippets/featured/bootstrap-outline-buttons in the documentation, we could have this classes on core as alternatives to the standard buttons?

Coming in v4.

Thank you mdo, I really love bootstrap, I want to use bootstrap 4 as soon as possible, thanks for solving my doubts


cigien: Watch myfreelancerbook.com

cigien requests the watch of the watch_keyword myfreelancerbook\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

myfreelancerbook\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

myfreelancerbook\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Makyen in Charcoal HQ

Approved by Makyen in Charcoal HQ


Simplify dependencies

Description
Gets rid of

swift-builders (essentially only used for a typealias)
textbuilder (not used)
BigInt (not used)
overture (not used)
PresentationBackground (used in a few places, but it is non-standard and requires swizzling)
NavigationTransitions (used in a 2-3 places but barely noticeable)
IdentifiedCollections (imported anyway through TCA)

On the flip side, we now have to include this separately, since it is only used by the Account screen header now:

swiftui-introspect

PresentationBackground (used in a 2-3 places but barely noticeable)

It is actually used in 10 places and IMO the effect is quite noticeable, are we removing it just to reduce dependencies number or is there any conflict if we try to keep it?

Sorry, it's navigationTransition that is used in 2-3 places and is barely noticeable. Presentation background is noticeable, but I don't think it is worth keeping that at the cost of having to use introspection and swizzling. It is not the number of dependencies, it's specifically the introspection dependency that I really would like to get rid of.

Ok but we are still using Introspection for account header, no?

Yes, but we don't need to, and shouldn't

Alright, I am keeping the presentationBackground for now, but only so we can get this in quickly!


Translations

Smoothforms should allow translating all strings that are presented to the user.
The following items contain strings that need translation:
Validator error strings:

src/RequiredValidator.php

Email strings:

Form::sendForm()

Form title

I tried to implement translations via gettext... but that turned out to not be the approach with least work. Problems:

Difficult to get working
gettext's restriction that requires the locale to be installed on the OS may cause problems with less common languages in some web hosting services.

I will instead implement a simple solution that will read translated string form ini files. It's probably going to be a global object that can be called to get the strings. Really seems to be the path of least hassle.


New parser -- first draft, request for review

All regression tests are currently passing.
I still need to get all of the error messages cleaned up.  (Every regression test that expects a failure has an exception raised -- but sometimes the message is cryptic.)
I'd appreciate some guidance if you have time:

does this look consistent with existing style for the project?
are there corner cases not covered by current regression tests to watch out for?
is there any wish-lists for parser features that I could integrate while I'm in here?

Python 3 support is on the way.  That's my top priority right now to get all the regression tests passing.
The two biggest new features are:
1- Safe recovery from parse errors.   (There is no global state other than successfully loaded modules, which is easy to clear.)  This enables iterative development of thrift files at the REPL or in a jupyter notebook type environment. https://github.com/eleme/thriftpy/issues/268
2- Parses Apache Thrift's test file https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob_plain;f=test/ThriftTest.thrift;hb=HEAD

Does this pull in doc pieces into doc attributes for functions and classes?  That would be nice.

Hi, the parser library we originally used was pyparsing. And we switched to ply since v0.1.10, one important reason is that ply is much more faster than pyparsing.
I have tested this pull request. I called thriftpy.load with a 2200+ lines thrift file with 1000 times.  The ply version gives 0.00572609901428s and parsley version gives 9.22570109367s.
def bench():
    start = time.time()
    for i in range(1000):
        thriftpy.load('my.thrift')
    end = time.time()
    print(end - start)

The my.thrift file is the thrift of our private service, you can make one yourself.
thriftpy is heavily used in our company, it behaves well.  We may not make big changes on the current parser. Unless the ply version parser has some major flaws or the new parser has some very important new features or much better performance.

@hit9 with a difference that big, I'm fairly certain that you're seeing an artifact of the global cache. My experience is that Parsely is surprisingly comparable to Ply performance-wise.

Wow I forgot the cache，will try later
发自我的 iPhone

在 2016年12月23日，10:21，Mahmoud Hashemi<EMAIL_ADDRESS>写道：
@hit9 with a difference that big, I'm fairly certain that you're seeing an artifact of the global cache. My experience is that Parsely is surprisingly comparable to Ply performance-wise.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

I expect it will still be slower though, it's a stricter parser with more features (the ply parser can't parse Apache Thrift's test suite) :)

Bench results (2200+lines thrift, called 10 times, without cache)

ply version: 2.44250607491 (10 times)
parsely version: 78.2733860016s (10 times)

Hmm, the 7.8s per thrift file parsing is unacceptable for our service starting..

the ply parser can't parse Apache Thrift's test suite

Yes.. we try to stick with apache thrift parser. But some features are dropped or won't implemented in favor of historical reasons, and for some features we just don't use them.
The global variable issue may not be solved,  because ply requires that.

Hmm, 30x is closer to the real figure than 1800x, but we'll need to play around with it some more, I'm sure we can speed it up. Parsley has options to emit the generated Python parser, and that should take care of a good chunk. But long story short, we should parse that big file in under a second, ideally, right?

Yes, <1s should be okay. We have some services with 2000 lines thrift file.. By the way, what's the reason for new parser on parsely but not stick with ply ? the current version works well for us.

The load time smaller, the better.  One service may rely on multiple third-party thrift services. For example, one of our major thrift service requires to communicate with 15 thrift services.

Good call on performance.  I haven't taken a look at that since the first POC.  This hasn't been optimized at all, so I'm sure there is a lot of low-hanging fruit.
I just broke identifying reserved tokens out to a regular expression for a ~30% speedup (based on tests/parser-cases/tutorial.thrift).  9 more optimizations like that would be a 35x speedup.
In addition to optimization, we could cache the parsed files on disk, similar to how the python module loader transparently stores pyc's.

Added docstring parsing to services and functions.  Any number of comments right before the { of a service body, or immediately after a function definition will get joined together with newlines and set to the __doc__ of the generated class.
service Foo /* the docstring */ {
   void foo() /* arg doc */
}

Open for feedback / other ideas.

I've played around a bit, and I see the following options to improve performance.  (Disregarding py / pyc file caching -- since that is possible but orthogonal to the parser itself.)

Move "heavy lifting" out of parlsey.

Move parsing various sub-parts to "built-in" rules.  Along the lines of using regex to identify keywords, there are a couple mechanisms to break out "leaf" rules to other libraries / code.  This approach has the advantage of being very iterative.  The optimization can be done one rule at a time.

Move the first level tree-node extraction into parsimonious (https://github.com/erikrose/parsimonious) which is highly optimized.  Another possibility is to move the entire thing to parsimonious, although this results in a much more verbose two-phase parser.

Optimize parsley.  This has the advantage of optimization being orthogonal to grammar, so the grammar doesn't become longer or harder to modify.

Optimize ometa.runtime.OMetaBase.  (I've already investigated that a bit here: https://gist.github.com/kurtbrose/df78fe07d3e1283a7a1f3fb54ff27907)  Parsley generates code like this: https://github.com/python-parsley/parsley/blob/master/ometa/_generated/parsley.py which calls to the (parameterized) superclass.  Cython optimized superclass = faster parser.

Write / adapt parsley meta-grammar to generate .pyx instead of .py.  This builds on (2), now lift everything except the little bits of eval() python code into cython for maximum optimization.

I'm confident the parser will at least match the performance of the existing parser with a bit of work.

To give a bit more context to this PR, I'm currently trying to migrate a medium sized mid-tier from an old version of facebook thrift to thriftpy (~320 thrift files, ~a dozen services and data stores/logs with occasional thrift formatting, maintained by ~30 engineers).  The reason for the migration is that the Apache Thrift compiler is a huge pain-point.  The compiler takes ~30 minutes to build, and requires the latest C++ boost libraries which makes setting up the build environment painful.  In addition to solving this, thriftpy also has the nice bonus of not requiring a separate build step.  This opens the door to functionality similar to Avro (https://avro.apache.org/docs/1.2.0/#compare) where data schemas can be stored next to the data and passed around between processes.
The migration is necessarily going to be gradual, which means it is important for the process to be able to recover from parse errors.  (try/except around an exception importing a thrift module should allow the process to continue.)  In addition, if trying to parse invalid thrift IDL corrupts the whole system, treating thrift specs as data that can be stored in a DB is not viable.

Getting into the guts of the parser (131 of our legacy thrift files parsing so far), there are a lot of "quirks".
One is use of the reserved keywords 'END', 'end', and 'alias as struct fields / enum items.  The other is counting on enum values to be "lifted" out as constants.  (i.e. "foo.BAR" where "foo" is an included module with enum Baz { BAR = 1 })
It might make sense to maintain this as a separate parser module rather than merging to core given the quirks of our code.

Closing for now, we are going with Thrift 0.9.3; may come back around to this in the future.
Thank you very much everybody for your time and attention, this was a great learning experience on parsing for me.


Add RegularPolygon and Circle meshes

Objective
Bevy users often want to create circles and other simple shapes.
All the machinery is in place to accomplish this, and there are external crates that help. But when writing code for e.g. a new bevy example, it's not really possible to draw a circle without bringing in a new asset, writing a bunch of scary looking mesh code, or adding a dependency.
In particular, this PR was inspired by this interaction in another PR: https://github.com/bevyengine/bevy/pull/3721#issuecomment-1016774535
Solution
This PR adds shape::RegularPolygon and shape::Circle (which is just a RegularPolygon that defaults to a large number of sides)
Discussion
There's a lot of ongoing discussion about shapes in https://github.com/bevyengine/rfcs/pull/12 and at least one other lingering shape PR (although it seems incomplete).
That RFC currently includes RegularPolygon and Circle shapes, so I don't think that having working mesh generation code in the engine for those shapes would add much burden to an author of an implementation.
But if we'd prefer not to add additional shapes until after that's sorted out, I'm happy to close this for now.
Alternatives for users
For any users stumbling on this issue, here are some plugins that will help if you need more shapes.
https://github.com/Nilirad/bevy_prototype_lyon
https://github.com/johanhelsing/bevy_smud
https://github.com/Weasy666/bevy_svg
https://github.com/redpandamonium/bevy_more_shapes
https://github.com/ForesightMiningSoftwareCorporation/bevy_polyline

Another thing to note is that this is generating meshes like the pentagon on the right side:

Doing it like what is shown on the left would result in fewer triangles, but I'm not sure if there are any graphical implications with "tiny thin triangles" when using this to draw circles or how much we should be concerned about that otherwise.

Now generating the "optimized" mesh like the left side in the diagram above.

Personally I'd prefer if the choice of which triangulation method to wasn't hard coded, but could be selected at runtime

@bevyengine/rendering-team; do y'all have opinions on the triangulation strategy?

@bevyengine/rendering-team; do y'all have opinions on the triangulation strategy?

I personally prefer using something like SDF's for circles as they can scale much better and you don't have to be concerned with size, but otherwise this seems fine to me.

Personally I'd prefer if the choice of which triangulation method to wasn't hard coded, but could be selected at runtime

I think if someone wants a different triangulation method they can just build their own mesh?

I personally prefer using something like SDF's for circles as they can scale much better and you don't have to be concerned with sides, but otherwise this seems fine to me.

Agreed, but this is a solid stop-gap.

I use recursive triangulation, like this:

It can produce narrow triangles, but they'll be at the edges anyway. It's a pretty simple algorithm, recursively splitting the list of vertices into thirds. It's only valid for convex polygons, though. I can submit a PR if desired.

@HackerFoo
I only had a vague notion of "long triangle thin triangle bad" to go on, but couldn't really dig up any concrete information and the (limited) testing I did wasn't revealing. So I just went with fewest triangles / fastest mesh generation. I can see how
I'm assuming you had a pretty good reason to implement that recursive strategy in your own app? Seems worthwhile to me if it actually solves some sort of problem.

I'm assuming you had a pretty good reason to implement that recursive strategy in your own app? Seems worthwhile to me if it actually solves some sort of problem.

The recursive algorithm is much easier to extend to arbitrary polygons. That's probably a minor bit of useful future-proofing here, but not essential. I'm unsure if there are other benefits though.

I did this while I was working on UV mapping. I can't remember if I saw artifacts, but I was using the fan method (on the left of the diagram above) and circles were ugly when looking at them in Blender, so I fixed it. I like the recursive approach because I love recursion, but also because if you draw the triangles from largest to smallest with this method, you get an increasingly accurate approximation of the polygon. So the lowest quality triangles contribute the least to the shape.
It's probably best to stick with the simple fan until it's at least an annoyance, though.

Another thing to note is that this is generating meshes like the pentagon on the right side: (edit: fixed this)

Doing it like what is shown on the left would result in fewer triangles, but I'm not sure if there are any graphical implications with "tiny thin triangles" when using this to draw circles or with UVs or how much we should be concerned about that otherwise.

The regular polygon with the right-side triangulation will only ever have two more triangles for sides >= 5, right? That’s not a significant difference if quality is degraded with texture mapping. I’d prioritise quality in that case but maybe either is fine and then fewer triangles is I guess better.

The regular polygon with the right-side triangulation will only ever have two more triangles for sides >= 5, right? That’s not a significant difference if quality is degraded with texture mapping. I’d prioritise quality in that case but maybe either is fine and then fewer triangles is I guess better.

I couldn't see any difference when I tested this with a textured shape earlier, but I'm not really sure how to test that properly.
In the case of pentagons, two more triangles is significantly more, but it's hard for me to say whether that even matters.
Happy to do some testing with regard to those things if we want (maybe with some extreme scaling and/or bevymarking a bunch of pentagons), but I'm currently in agreement with HackerFoo that we probably won't need to worry overly much unless an issue pops up.

Definitely feels like something that can be shipped and changed later if something turns out to have problems. :)

Just a couple of minor changes then LGTM.

I would add a Circle::new(radius, subdivisions) and RegularPolygon::new(radius, sides). Other than that I like having this. I know there's the rfc for primitive shapes, but we can still change this in the future.

I agree that these are clumsy to use right now, but none of the other builtin shapes have that right now and I feel like this PR has a better shot if I keep the scope super narrow.

none of the other builtin shapes have that right now

Are you sure about that? Cube, Box and Quad all have one

Yeah, I guess having a Circle::new(radius) is better and letting people construct it manually otherwise is fine for me.

"Bevy users often want to create circles and other simple shapes." who would have thought?))) I mean the engine is like 1.5 years old and still doesn't have a beginner-approachable drawing API. I love Bevy but can't use it because of that...

@adsick You can use bevy_prototype_lyon until Bevy gets a proper drawing API.

@adsick You can use bevy_prototype_lyon until Bevy gets a proper drawing API.

I know that, looked at the examples, but it seems to me that immediate mode API is more intuitive.

bors r+


Multiple Workspaces

Is it possible to have multiple workspaces for each user? (So that each one has a private storage sorta thing)

No, that's not possible yet. I'd imagine it could be done by adding a home property to users that can be configured by privileged users in the options. After that, the APIs have to be adjusted to lock that user to the path.

Perhaps in the future then. Label this as a feature  maybe ?


New version: Tencent.WeChat version <IP_ADDRESS>

Created by 🥟 Dumplings in workflow run #6368.

Log
64位
https://dldir1v6.qq.com/weixin/Windows/WeChat<IP_ADDRESS>.exe doesn't exist, fallback to https://dldir1v6.qq.com/weixin/Windows/WeChatSetup.exe
Updated: <IP_ADDRESS> → <IP_ADDRESS>
Submitting WinGet manifests
Creating manifests
Uploading manifests and making commits
The manifests for the last version <IP_ADDRESS> will be removed. Reason: No installer URL is changed compared with the last state while the version is updated
Creating a pull request

Microsoft Reviewers: Open in CodeFlow

/azp run

/azp run

https://github.com/microsoft/winget-pkgs/issues/142854


grpc + TLS requires the hosts in global TLSContext to be the wildcard "*"

Ambassador version: v1.2.2
If we create a TLSContext for the top level domain (used by multiple services) since the certificates are wildcarded from LetsEncrypt, the filter_chain_match and the domains for the virtual hosts are setup with the same value. For example: "*.company.io"
When a gRPC application uses secure channel the SNI is done with serviceX.company.io but the authority header is "serviceX.company.io:443". So the the actual route is never found and the grpc app fails.
Following TLSContext
apiVersion: ambassador/v1
kind: TLSContext
name: xxx
ambassador_id: internal_proxy
hosts:
   - \"*.company.io\"

resulted in following config:
    "listeners": [
        {
            "address": {
                "socket_address": {
                    "address": "<IP_ADDRESS>",
                    "port_value": 443,
                    "protocol": "TCP"
                }
            },
            "filter_chains": [
                    "filter_chain_match": {
                        "server_names": [
                            "*.company.io"
                        ],
                        "transport_protocol": "tls"
                    },
             "filters": [
                        {
                            "name": "envoy.http_connection_manager",
                            "route_config": {
                                   "virtual_hosts": [
                                        {
                                            "domains": [
                                                "*.company.io"
                                            ],

So when the gRPC client makes gRPC call over https (443), the filter_chain_match is fine but the domains match fails and the route is not located since the authority in gRPC request is "serviceX.company.io:443"

There seems to be an association between the filter_chain_match.server_names and virtual_hosts.domains in the code.
https://github.com/datawire/ambassador/blob/8bef4449d2155112ffc057cef97165ef2c4aaa37/python/ambassador/envoy/v2/v2listener.py#L552
So for now our workaround is to set hosts in TLSContext to "" and this causes the server_names and domains to be "". This causes the actual route match to do the cluster steering and grpc + TLS works fine now.
But proper fix seems to be to disassociate the server_names and domains since in the case of gRPC over TLS, these would be different.

The mapping for grpc must have :443 in the hosts since the authority has hostname:443

@kthommandra, are you on our Slack? Might be worth talking over how we can tackle this...

Repeating my thoughts from slack here ..
Currently the Mapping for gRPC service has grpc: True. Ideally this would be the cue for Ambassador config generator to setup the header matches (include the appropriate listener port automatically) underneath appropriate listeners. IOW the service owner only adds grpc: True in the Mapping annotation.
The host: is regular match without the port number, just the way its done for non-grpc services.
The virtual_hosts.domains should also get generated automatically for any gRPC services in a listener. So rather than exporting the port number to a service user .. the system is actually taking care of it automatically
I don't claim to fully understand the different objects in Ambassador config and their relation to Envoy entities so take these comments with enough salt :slightly_smiling_face:

This issue is observed on ambassador 1.8.1.
In our case, it is impossible to set hosts to * because we have multiple tls contexts. Instead,  another host entry were added in hosts with port:
apiVersion: ambassador/v1
kind: TLSContext
name: xxx
ambassador_id: internal_proxy
hosts: ["*.company.io", "*.company.io:443"]

Ambassador 1.8.1 will generate two filterchain, one with server name ".company.io" and another with ".company.io:443". But both virtual hosts (with and without port number) are presenting in each filter chain's route_config. As a result, the first filter chain (*.company.io) met both matching criterias and request were successful.
            "filter_chains": [
                    "filter_chain_match": {
                        "server_names": [
                            "*.company.io"
                        ],
                        "transport_protocol": "tls"
                    },
             "filters": [
                        {
                            "name": "envoy.http_connection_manager",
                            "route_config": {
                                   "virtual_hosts": [
                                        {
                                            "domains": [
                                                "*.company.io"
                                                "*.company.io:443",
                                            ],

......

            "filter_chains": [
                    "filter_chain_match": {
                        "server_names": [
                            "*.company.io:443"
                        ],
                        "transport_protocol": "tls"
                    },
             "filters": [
                        {
                            "name": "envoy.http_connection_manager",
                            "route_config": {
                                   "virtual_hosts": [
                                        {
                                            "domains": [
                                                "*.company.io",
                                                "*.company.io:443",
                                            ],

Note: This workaround does NOT work with ambassador 1.6.2 because virtual host domains are not normalized together.  Each filter chain only have one virtual host domain exactly same as server name.
In ambassador 0.86.1, virtual host domain seems always be "*", so this issue do NOT exist in ambassador 0.86.1.
Thanks for all the above info.

We believe this has been addressed in more recent versions.  Feel free to reopen if the issue persists.


Focus next/previous pane commands don't work

Open a terminal, split it
Run the "Focus Next/Previous Pane" commands
They don't do anything

Maybe same root cause as https://github.com/microsoft/vscode/issues/123117?


Cairo ignores "Show desktop icons" selection on exit

Describe the bug
when Cairo is exited (either manually or by Windows during the logoff process), the Windows Explorer "Show desktop icons" setting is set to enabled regardless of its previous setting, even if it is disabled while Cairo is running.
Steps to reproduce

start Cairo.
in Windows Explorer, right click on any empty space in the desktop and under View, uncheck "Show desktop icons".
exit Cairo (or logoff/shutdown/reboot and log back in).

Expected behavior
if "Show desktop icons" is unchecked, desktop icons should not appear on the desktop once Cairo is exited.
System information:

Windows version: Windows 10, Insider Preview build 21376
Cairo version: <IP_ADDRESS>114
32-bit or 64-bit: 64-bit
In Cairo Settings > Advanced, is Cairo set as shell?: no.

Additional context
this seems to occur regardless of if the "Show desktop icons" option is disabled before Cairo is launched or while it is running.
FWIW, in Cairo Settings -> Desktop, "Enable desktop" is NOT enabled.
Screenshots
N/A.

This will be fixed in the next release.


Add submission entity to represent a data submission from a data submitter

Add a submission entity which is a grouping entity that represents a data submission from a data submitter.

Thanks @krausf !


not working properly

after i installed it it was working good. but then it started to become slower.

Do you know who overtorment is?
On Thursday, 14 January 2021, shravvan2812<EMAIL_ADDRESS>wrote:

after i installed it it was working good. but then it started to become
slower.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/45187, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALMZECQXAJLYH7MUOT7DUSLSZ35XDANCNFSM4WCQL7AA
.

--
nicole.gmail.org

Do you know who overtorment is?
On Thursday, 14 January 2021, shravvan2812<EMAIL_ADDRESS>wrote:

after i installed it it was working good. but then it started to become
slower.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/45187, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALMZECQXAJLYH7MUOT7DUSLSZ35XDANCNFSM4WCQL7AA
.

--
nicole.gmail.org

This is not a support forum but a bug tracker, we can only act on actual bug reports which provide sufficient information for us to debug/fix issues. There's nothing for us to work with in this issue, so I'll close it.

This is not a support forum but a bug tracker, we can only act on actual bug reports which provide sufficient information for us to debug/fix issues. There's nothing for us to work with in this issue, so I'll close it.


welp

how to translate %multiplayer.login.player% packet

Do you need to? What’s your use case? These strings can probably be found in the default resource pack.


FreeRTOS+TCP Set xDataLength before calculating checksum

Description
Since the big PR #2015, it can happen that the TCP checksum for an outgoing packet is not set correctly, because it sees a length error. I just found this out while testing with the WinSim projects.
The function usGenerateProtocolChecksum() has recently become stricter: it also checks the the total length is at least the sum of the Ethernet header, plus the length field found in the IPv4 header (see code below ).
I propose the following change, symbolically in FreeRTOS_TCP_IP.c:
+    pxNetworkBuffer->xDataLength = ulLen + ipSIZE_OF_ETH_HEADER;

     /* calculate the TCP checksum for an outgoing packet. */
     usGenerateProtocolChecksum( pxTCPPacket, pxNetworkBuffer->xDataLength, pdTRUE );

-    pxNetworkBuffer->xDataLength = ulLen + ipSIZE_OF_ETH_HEADER;

The length error was detected here in usGenerateProtocolChecksum():
    usLength = pxIPPacket->xIPHeader.usLength;
    usLength = FreeRTOS_ntohs( usLength );
    if( uxBufferLength < ( size_t ) ( ipSIZE_OF_ETH_HEADER + ( size_t ) usLength ) )
    {
        usChecksum = ipINVALID_LENGTH;
        location = 3;
        goto error_exit;
    }

The problem would only occur on platforms that do not have checksum offloading like WinSim.
Checklist:

[x] I have tested my changes. No regression in existing tests.
[x] My code is Linted.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/bot run checks


Parsing ranges apart from single values

Is there any functionality to parse ranges as flags. For example the namp tool takes a range of ports to scan nmap HOST -p 10-100
This would scan ports in the range 10 to 100. Similar functionalities being implemented would be helpful!

A very naive approach I have in mind for the same is as follows:
func ParseRange(Range string) (int, int) {
	if strings.Contains(Range, "-") {
		Vals := strings.Split(Range, "-")

		if len(Vals) != 2 {
			log.Fatal("Failed while parsing ranges. Invalid port range format!")
		}

		var min, max int

		if strings.Compare(Vals[0], "") == 0 {
			min = 1
		} else {
			val, err := strconv.Atoi(Vals[0])
			if err != nil {
				fmt.Println("Failed to parse ranges!")
				log.Fatal(err)
			}
			min = val
		}

		if strings.Compare(Vals[1], "") == 0 {
			max = 65535
		} else {
			val, err := strconv.Atoi(Vals[1])
			if err != nil {
				fmt.Println("Failed to parse ranges!")
				log.Fatal(err)
			}
			max = val
		}

		return min, max

	} else {
		val, err := strconv.Atoi(portRange)
		if err != nil {
			fmt.Println("Failed to parse values!")
			log.Fatal(err)
		}

		return val, nil

	}
}

Here, we could take in a string value as a flag and parse it separately based on whether or not a - is present. Default values can be provided if in case vales on either side of the - are omitted. In my above example default values are 1, 65535 (For ports).
We return the minimum value of the range and maximum through the above function and this can be used as ranges to iterate over. If in case a single value is given instead of range, we simply give just that value and nil.

This package tries to stick to what's available in the https://golang.org/pkg/flag/ package. You can use the VarP function to define a flag like this in your code that satisfies the Value interface. If you think this is a generally useful type of flag, the https://github.com/spf13/pflag fork has a bunch of extra flag types defined and takes a more "batteries-included" approach to adding new flags, so perhaps you could try contributing it there.


after import moment it  reports "[vee-validate]: No such validator 'date_format' exists." as before

Versions:

VueJs: 2.1.10
moment: 2.17.1
Vee-Validate: 2.0.0-beta.21

Description:
When I import moment in main.js, I meet the error " [vee-validate]: No such validator 'date_format' exists. " as before.
import moment from 'moment'
Vue.use(moment)

What went wrong?
Steps To Reproduce:
Any help?
Solution:
The replay by @logaretm is useful. I used the first scheme.

yep, moment is not a vue plugin so you can't call Vue.use(moment);
Since you are using es6, You need to install them manually:
import Vue from 'vue';
import VeeValidate, { Validator } from 'vee-validate';

Validator.installDateTimeValidators(moment);
Vue.use(VeeValidate);

and that should be it, you can alternatively import moment in the global scope and it should install them automatically:
import moment from 'moment';
import Vue from 'vue';
import VeeValidate from 'vee-validate';

window.moment = moment;
Vue.use(VeeValidate);

@logaretm Thank you very much!
I has misconstrued the document of org site. Just this statement "If your setup contains momentjs globally, it will be installed automatically for all validator instances".
It solved my problem. Thanks!

Solution:
The replay by @logaretm is useful. I used the first scheme.

@logaretm Unless I've missed it, the info in you last comment about installing with moment should most definitively be in the docs. I've spent half the day trying to use the date_format validation rules. So this is the info that I strongly suggest should be added to the docs:

All date validation requires momentjs. It is not mentioned in the docs, I found out in issue #125. And the error messages are not clear. I suggest there should be a check to see if there is any valid datetime validators registered

The installation steps your wrote earlier. There is no mention of that in the docs as far as know of.

Other than that, great plugin. Very useful!

Ok, I found the steps to install the momentjs with installDateTimeValidators as a side note of the available rules list. I recommend this should be in the installation process as an optional step.

@lunfel It is included if moment is available globally, that is on the window object in most cases. I can add an option to provide moment at start up.
Also take a look at #615 which might help resolve any future issues coming from it.

Ah nice! #615 seems to fix the issue completely. It is true that there is a lot of confusion, because I expected the validation rules to work out-of-the-box. But with that in place, I will be way more clear.


Expanded for comprehsions with folding

Pull request
Description
This PR expands for comprehension to allow for initial values and a fold operator. Both are optional and default, so the current behavior is maintained, and full backward compatibility is given.
The syntax changes from:
for <target> of
  <cases>
end;

to
for <target> of
  <cases>
[into <initial> [use <operator>]] end;

where initial defaults to [] and operator defaults to +.
Vaid operators are +, -, * and /.
The syntax leaves open the opportunity to expand operator to have more complex folding using lambdas or function pointers once those are implemented.
Checklist

[x] The RFC, if required, has been submitted and approved
[x] Any user-facing impact of the changes is reflected in docs.tremor.rs
[x] The code is tested
[x] Use of unsafe code is reasoned about in a comment
[x] Update CHANGELOG.md appropriately, recording any changes, bug fixes, or other observable changes in behavior
[x] The performance impact of the change is measured (see below)

Performance
Summary: We gain nearly 20% performance for the record case while maintaining near parity / stay within the noise level for arrays.
Simple "for" loop creating an array
    define script runtime
    script
      for event of
        case (k, v) => v
      end
    end;

Creating a record:
# old
    define script runtime
    script
      use std::record;
      record::from_array(for event of
        case (k, v) => [k, v]
      end)
    end;
# new
    define script runtime
    script
      for event of
        case (k, v) => {"{k}": v}
      into {} end
    end;

target
old
new

array
107.6 MB/s
108.6 MB/s

record
121.4 MB/s
102.2 MB/s

I got to admit, I'm disappointed by the changes in performance, but it does read nicer at least

I am no longer disappointed by the performance reasults

Would this also work as expected on strings with +?
I do think this table here: https://www.tremor.rs/docs/edge/language/expressions#operators needs some updating. And it should be referenced from the for-comprehension docs, in order to show what operations are allowed in the context of a for comprehension.

I do not like this syntax at all and believe we need an RFC as head/tail pattern matching in functions would resolve this far more elegantly.

https://github.com/tremor-rs/tremor-www/pull/302


Ability to optionally pass the initial state for Default Cubit/Bloc

At present, DefaultInfiniteListCubit and the DefaultInfiniteListBloc should pass the initialState even though there are no initial items provided.
Changing them into optional argument may reduce some boilerplates when creating the Default...s.

Closed by #21


Allow users to leave comments

Idea for manual moderation: https://blog.joeldare.com/how-i-implemented-comments-on-a-static-site/

Resolved by commit e1d7962


这是什么情况

/root/anaconda3/envs/echomimic/lib/python3.8/site-packages/diffusers/utils/outputs.py:63: UserWarning: torch.utils._pytree._register_pytree_node is deprecated. Please use torch.utils._pytree.register_pytree_node instead.
torch.utils._pytree._register_pytree_node(
Adding FFMPEG_PATH to PATH
Some weights of the model checkpoint were not used when initializing UNet2DConditionModel:
['down_blocks.0.attentions.0.transformer_blocks.0.attn2.to_q.weight, down_blocks.0.attentions.0.transformer_blocks.0.attn2.to_k.weight, down_blocks.0.attentions.0.transformer_blocks.0.attn2.to_v.weight, down_blocks.0.attentions.0.transformer_blocks.0.attn2.to_out.0.weight, down_blocks.0.attentions.0.transformer_blocks.0.attn2.to_out.0.bias, down_blocks.0.attentions.0.transformer_blocks.0.norm2.weight, down_blocks.0.attentions.0.transformer_blocks.0.norm2.bias, down_blocks.0.attentions.1.transformer_blocks.0.attn2.to_q.weight, down_blocks.0.attentions.1.transformer_blocks.0.attn2.to_k.weight, down_blocks.0.attentions.1.transformer_blocks.0.attn2.to_v.weight, down_blocks.0.attentions.1.transformer_blocks.0.attn2.to_out.0.weight, down_blocks.0.attentions.1.transformer_blocks.0.attn2.to_out.0.bias, down_blocks.0.attentions.1.transformer_blocks.0.norm2.weight, down_blocks.0.attentions.1.transformer_blocks.0.norm2.bias, down_blocks.1.attentions.0.transformer_blocks.0.attn2.to_q.weight, down_blocks.1.attentions.0.transformer_blocks.0.attn2.to_k.weight, down_blocks.1.attentions.0.transformer_blocks.0.attn2.to_v.weight, down_blocks.1.attentions.0.transformer_blocks.0.attn2.to_out.0.weight, down_blocks.1.attentions.0.transformer_blocks.0.attn2.to_out.0.bias, down_blocks.1.attentions.0.transformer_blocks.0.norm2.weight, down_blocks.1.attentions.0.transformer_blocks.0.norm2.bias, down_blocks.1.attentions.1.transformer_blocks.0.attn2.to_q.weight, down_blocks.1.attentions.1.transformer_blocks.0.attn2.to_k.weight, down_blocks.1.attentions.1.transformer_blocks.0.attn2.to_v.weight, down_blocks.1.attentions.1.transformer_blocks.0.attn2.to_out.0.weight, down_blocks.1.attentions.1.transformer_blocks.0.attn2.to_out.0.bias, down_blocks.1.attentions.1.transformer_blocks.0.norm2.weight, down_blocks.1.attentions.1.transformer_blocks.0.norm2.bias, down_blocks.2.attentions.0.transformer_blocks.0.attn2.to_q.weight, down_blocks.2.attentions.0.transformer_blocks.0.attn2.to_k.weight, down_blocks.2.attentions.0.transformer_blocks.0.attn2.to_v.weight, down_blocks.2.attentions.0.transformer_blocks.0.attn2.to_out.0.weight, down_blocks.2.attentions.0.transformer_blocks.0.attn2.to_out.0.bias, down_blocks.2.attentions.0.transformer_blocks.0.norm2.weight, down_blocks.2.attentions.0.transformer_blocks.0.norm2.bias, down_blocks.2.attentions.1.transformer_blocks.0.attn2.to_q.weight, down_blocks.2.attentions.1.transformer_blocks.0.attn2.to_k.weight, down_blocks.2.attentions.1.transformer_blocks.0.attn2.to_v.weight, down_blocks.2.attentions.1.transformer_blocks.0.attn2.to_out.0.weight, down_blocks.2.attentions.1.transformer_blocks.0.attn2.to_out.0.bias, down_blocks.2.attentions.1.transformer_blocks.0.norm2.weight, down_blocks.2.attentions.1.transformer_blocks.0.norm2.bias, up_blocks.1.attentions.0.transformer_blocks.0.attn2.to_q.weight, up_blocks.1.attentions.0.transformer_blocks.0.attn2.to_k.weight, up_blocks.1.attentions.0.transformer_blocks.0.attn2.to_v.weight, up_blocks.1.attentions.0.transformer_blocks.0.attn2.to_out.0.weight, up_blocks.1.attentions.0.transformer_blocks.0.attn2.to_out.0.bias, up_blocks.1.attentions.0.transformer_blocks.0.norm2.weight, up_blocks.1.attentions.0.transformer_blocks.0.norm2.bias, up_blocks.1.attentions.1.transformer_blocks.0.attn2.to_q.weight, up_blocks.1.attentions.1.transformer_blocks.0.attn2.to_k.weight, up_blocks.1.attentions.1.transformer_blocks.0.attn2.to_v.weight, up_blocks.1.attentions.1.transformer_blocks.0.attn2.to_out.0.weight, up_blocks.1.attentions.1.transformer_blocks.0.attn2.to_out.0.bias, up_blocks.1.attentions.1.transformer_blocks.0.norm2.weight, up_blocks.1.attentions.1.transformer_blocks.0.norm2.bias, up_blocks.1.attentions.2.transformer_blocks.0.attn2.to_q.weight, up_blocks.1.attentions.2.transformer_blocks.0.attn2.to_k.weight, up_blocks.1.attentions.2.transformer_blocks.0.attn2.to_v.weight, up_blocks.1.attentions.2.transformer_blocks.0.attn2.to_out.0.weight, up_blocks.1.attentions.2.transformer_blocks.0.attn2.to_out.0.bias, up_blocks.1.attentions.2.transformer_blocks.0.norm2.weight, up_blocks.1.attentions.2.transformer_blocks.0.norm2.bias, up_blocks.2.attentions.0.transformer_blocks.0.attn2.to_q.weight, up_blocks.2.attentions.0.transformer_blocks.0.attn2.to_k.weight, up_blocks.2.attentions.0.transformer_blocks.0.attn2.to_v.weight, up_blocks.2.attentions.0.transformer_blocks.0.attn2.to_out.0.weight, up_blocks.2.attentions.0.transformer_blocks.0.attn2.to_out.0.bias, up_blocks.2.attentions.0.transformer_blocks.0.norm2.weight, up_blocks.2.attentions.0.transformer_blocks.0.norm2.bias, up_blocks.2.attentions.1.transformer_blocks.0.attn2.to_q.weight, up_blocks.2.attentions.1.transformer_blocks.0.attn2.to_k.weight, up_blocks.2.attentions.1.transformer_blocks.0.attn2.to_v.weight, up_blocks.2.attentions.1.transformer_blocks.0.attn2.to_out.0.weight, up_blocks.2.attentions.1.transformer_blocks.0.attn2.to_out.0.bias, up_blocks.2.attentions.1.transformer_blocks.0.norm2.weight, up_blocks.2.attentions.1.transformer_blocks.0.norm2.bias, up_blocks.2.attentions.2.transformer_blocks.0.attn2.to_q.weight, up_blocks.2.attentions.2.transformer_blocks.0.attn2.to_k.weight, up_blocks.2.attentions.2.transformer_blocks.0.attn2.to_v.weight, up_blocks.2.attentions.2.transformer_blocks.0.attn2.to_out.0.weight, up_blocks.2.attentions.2.transformer_blocks.0.attn2.to_out.0.bias, up_blocks.2.attentions.2.transformer_blocks.0.norm2.weight, up_blocks.2.attentions.2.transformer_blocks.0.norm2.bias, up_blocks.3.attentions.0.transformer_blocks.0.attn2.to_q.weight, up_blocks.3.attentions.0.transformer_blocks.0.attn2.to_k.weight, up_blocks.3.attentions.0.transformer_blocks.0.attn2.to_v.weight, up_blocks.3.attentions.0.transformer_blocks.0.attn2.to_out.0.weight, up_blocks.3.attentions.0.transformer_blocks.0.attn2.to_out.0.bias, up_blocks.3.attentions.0.transformer_blocks.0.norm2.weight, up_blocks.3.attentions.0.transformer_blocks.0.norm2.bias, up_blocks.3.attentions.1.transformer_blocks.0.attn2.to_q.weight, up_blocks.3.attentions.1.transformer_blocks.0.attn2.to_k.weight, up_blocks.3.attentions.1.transformer_blocks.0.attn2.to_v.weight, up_blocks.3.attentions.1.transformer_blocks.0.attn2.to_out.0.weight, up_blocks.3.attentions.1.transformer_blocks.0.attn2.to_out.0.bias, up_blocks.3.attentions.1.transformer_blocks.0.norm2.weight, up_blocks.3.attentions.1.transformer_blocks.0.norm2.bias, up_blocks.3.attentions.2.transformer_blocks.0.attn2.to_q.weight, up_blocks.3.attentions.2.transformer_blocks.0.attn2.to_k.weight, up_blocks.3.attentions.2.transformer_blocks.0.attn2.to_v.weight, up_blocks.3.attentions.2.transformer_blocks.0.attn2.to_out.0.weight, up_blocks.3.attentions.2.transformer_blocks.0.attn2.to_out.0.bias, up_blocks.3.attentions.2.transformer_blocks.0.norm2.weight, up_blocks.3.attentions.2.transformer_blocks.0.norm2.bias, mid_block.attentions.0.transformer_blocks.0.attn2.to_q.weight, mid_block.attentions.0.transformer_blocks.0.attn2.to_k.weight, mid_block.attentions.0.transformer_blocks.0.attn2.to_v.weight, mid_block.attentions.0.transformer_blocks.0.attn2.to_out.0.weight, mid_block.attentions.0.transformer_blocks.0.attn2.to_out.0.bias, mid_block.attentions.0.transformer_blocks.0.norm2.weight, mid_block.attentions.0.transformer_blocks.0.norm2.bias, conv_norm_out.weight, conv_norm_out.bias, conv_out.weight, conv_out.bias']
已杀死

解决了么？我也碰到了


Basic Implementation for GetAPIKeyInfo

Greetings,
This request adds support for the GetAPIKeyInfo api call, which just simply returns the API key usage information.
Also included are unit tests to support it and example docs.

Thanks!


Akhilesh annotation list refresh

Changes to annotation list to avoid full refresh of the list
Create separate functions and signals for add/update/delete annotation and trigger signals accordingly
Create interface for common signals between AnnotationSource and MultiscaleAnnotationSource

update logic is incorrect, closing


Extend the Platform implementation

Note from a discussion on the state of Pi4J V2

The idea was "Platform" represented the target hardware or embedded device and environment a user would run Pi4J from.  Such as the "RaspberryPi" platform.  A platform could support multiple providers.  A platform may assign default providers for each IO type.
When creating a Pi4J Context only a single (default) Platform is held by the context.  This platform may be auto-detected based on the presence of a Pi4J platform JAR in the path.  If multiple platform JARs are detected there must be some order of precedence determined which is the Default platform.
Not sure how evolved or how complete the concept of Platform is in the current codebase.  So it may need some work.

Question by Pascal Mathis while testing on CrowPi
Here is a short code snippet that highlights the point I'm talking about:
package ch.fhnw.crowpi;

import java.util.concurrent.TimeUnit;

import com.pi4j.Pi4J;
import com.pi4j.io.gpio.digital.DigitalOutput;
import com.pi4j.io.gpio.digital.DigitalState;

public class App {
    public static void main(String[] args) {
        var pi4j = Pi4J.newAutoContext();
        pi4j.platforms().describe().print(System.out);

        var buzzerConfig = DigitalOutput.newConfigBuilder(pi4j).id("BCM18").name("Buzzer").address(18)
                .shutdown(DigitalState.LOW).initial(DigitalState.LOW).provider("pigpio-digital-output");

        var output1 = pi4j.dout().create(18);
        output1.config().shutdownState(DigitalState.LOW);
        output1.addListener(System.out::println);
        output1.pulse(100, TimeUnit.MILLISECONDS, DigitalState.HIGH);
        System.out.println(output1.provider());

        var output2 = pi4j.create(buzzerConfig);
        output2.addListener(System.out::println);
        output2.pulse(100, TimeUnit.MILLISECONDS, DigitalState.HIGH);
        System.out.println(output2.provider());

        pi4j.shutdown();
    }
}

The output1 GPIO pin created  by pi4j.dout().create(18) never seems to work (there is no output on the CrowPi at all), while output2 created using the DigitalOutputConfigBuilder works flawlessly. I noticed that output1 is an instance of com.pi4j.plugin.raspberrypi.provider.gpio.digital.RpiDigitalOutputProviderImpl where as output2 is an instance of com.pi4j.plugin.pigpio.provider.gpio.digital.PiGpioDigitalOutputProviderImpl . When not explicitly stating the provider for the config builder, the same provider as for output1 is used and it also does not work anymore.
Is it actually desired that the pipgio-digital-output provider has to be explicitly specified for each GPIO input/output or should the RpiDigitalOutputProviderImpl somehow figure this out by itself? It currently seems like the latter does not do anything except calling the usual event listeners, e.g. printing the digital change event to stdout as in my example.

I've managed to find a workaround for this issue to avoid having to implicitly specify the provider every single time, which greatly simplifies testing our component classes as we do not have to explicitly pass either pigpio-* or mock-*. Basically I've ditched the Pi4J.newAutoContext() and replaced it with this code:
this.pi4j = Pi4J.newContextBuilder()
    .noAutoDetectPlatforms()
    .addPlatform(new CrowPiPlatform())
    .autoDetectProviders()
    .build();

Additionally, the CrowPiPlatform class overrides the existing RaspberryPiPlatform by zeroing out the list of available providers for this platform:
package ch.fhnw.crowpi.helpers;

import com.pi4j.plugin.raspberrypi.platform.RaspberryPiPlatform;

public class CrowPiPlatform extends RaspberryPiPlatform {
    @Override
    protected String[] getProviders() {
        return new String[]{};
    }
}

This is not pretty, but avoids that Pi4J loads the Raspberry Pi providers, causing the PiGpio providers being registered as the default providers. This can also be seen by e.g. comparing pi4j.getPwmProvider().toString():

Without the workaround: com.pi4j.plugin.raspberrypi.provider.pwm.RpiPwmProviderImpl (does not work)
With the workaround: com.pi4j.plugin.pigpio.provider.pwm.PiGpioPwmProviderImpl (works)

I did not manage to find any other way to tell Pi4J to prefer the PiGpio providers over the RaspberryPi providers, so this seems like the easiest approach so far.

@ppmathis
Yes, the platform auto-detection and provider assignment is very much incomplete.
Here is the theory of what it was intended to do ...
A user could have one or more Platform JARs along with the various Provider JARs in the class-path of a given runtime environment.  In the case of an Auto-Context created, the Pi4J runtime context should iterate over all the Provider JARs it finds and interrogate them to see if they should be considered active for the runtime environment and potentially provide a weighting score for each provider.  Once the Pi4J runtime context has iterated over all the detected providers and obtains which are valid and their weighted scores it should attempt to initialize with the highest weighted platform and initialize all the providers defined by that platform implementation.
So in the case of CrowPi, CrowPi could certainly have a provider implementation that ranks higher than RaspberryPi if it can detect something in the runtime environment or via hardware that definitively asserts that it is running on CrowPi hardware.  However if it does not offer additional hardware I/O or prefer different I/O providers than the default RaspberryPi platform, then there would be no need for it.  But I get why you created it for the time being.
The immediate issue you are having is likely due to that no real I/O providers have been defined for the RaspberryPi platform.  It looks like there are some stub implementation classes, but no real implementation.  I think these were never originally assigned to PiGPIO because we intended to implement LinuxFS GPIO, SPI, I2C and use those as the default providers for the Raspberry Pi platform.

@savageautomate Thank you for your detailed explanation about the platform / provider implementation!

However if it does not offer additional hardware I/O or prefer different I/O providers than the default RaspberryPi platform, then there would be no need for it. But I get why you created it for the time being.

You are right, as far as I can tell there would be absolutely no need for a CrowPi specific platform but I was just using that name as it fit into our code base. Once there is no longer any need to use that workaround, the RaspberryPi platform should do just fine.

The immediate issue you are having is likely due to that no real I/O providers have been defined for the RaspberryPi platform. It looks like there are some stub implementation classes, but no real implementation. I think these were never originally assigned to PiGPIO because we intended to implement LinuxFS GPIO, SPI, I2C and use those as the default providers for the Raspberry Pi platform.

This sounds exactly like the issue I am facing, as I also noticed that the RaspberryPi platform does not seem to have any actual I/O providers included, but still registers them, causing them to end up as the non-working default providers despite PiGPIO being available. As the workaround does the job for now though, this is not a blocker in any way - it was mostly just a bit confusing at first why things did not work, but I understand that this is a work in progress.

This sounds exactly like the issue I am facing, as I also noticed that the RaspberryPi platform does not seem to have any actual I/O providers included, but still registers them, causing them to end up as the non-working default providers despite PiGPIO being available. As the workaround does the job for now though, this is not a blocker in any way - it was mostly just a bit confusing at first why things did not work, but I understand that this is a work in progress.

Yes, if I recall correctly, I think I was planning on defining RaspberryPi specific provider classes but simply inheriting each implementation from an actual I/O provider such as LinuxFS providers.
https://github.com/Pi4J/pi4j-v2/tree/main/plugins/pi4j-plugin-raspberrypi/src/main/java/com/pi4j/plugin/raspberrypi/provider
This way if there are special or unique cases for the Raspberry Pi versions of each provider we have a place to implement these modifications/overrides.
We could just inherit the PiGPIO providers for the time being, but I suspect these ultimately won't be the defaults for the RPi.

Has been discussed together with @eitch and @savageautomate and current implementation is considered as sufficient for now until specific use-cases would require more work.
Value weight has been refactored to priority in PR https://github.com/Pi4J/pi4j-v2/pull/95


TypeError: unsupported operand type(s) for *: 'int' and 'NoneType'

Thanks for your work.
I used the following command under ''/experiments/siammask_r50_l3/'':
CUDA_VISIBLE_DEVICES=0 # change your cuda visible devices here
python -m torch.distributed.launch --nproc_per_node=1 --master_port=2333 ../../tools/train.py --cfg config.yaml

But I encountered an error when I trained siammask:
Traceback (most recent call last):
  File "../../tools/train.py", line 316, in <module>
    main()
  File "../../tools/train.py", line 311, in main
    train(train_loader, dist_model, optimizer, lr_scheduler, tb_writer)
  File "../../tools/train.py", line 211, in train
    outputs = model(data)
  File "/data/anaconda3/envs/tang0.4.1/lib/python3.7/site-packages/torch/nn/modules/module.py", line 477, in __call__
    result = self.forward(*input, **kwargs)
  File "/data/anaconda3/envs/tang0.4.1/lib/python3.7/site-packages/pysot/utils/distributed.py", line 43, in forward
    return self.module(*args, **kwargs)
  File "/data/anaconda3/envs/tang0.4.1/lib/python3.7/site-packages/torch/nn/modules/module.py", line 477, in __call__
    result = self.forward(*input, **kwargs)
  File "/data/anaconda3/envs/tang0.4.1/lib/python3.7/site-packages/pysot/models/model_builder.py", line 113, in forward
    outputs['total_loss'] += cfg.TRAIN.MASK_WEIGHT * mask_loss
TypeError: unsupported operand type(s) for *: 'int' and 'NoneType'

Could you please tell me how to run train.py correctly?
Thank you very much!

You can use siamrpn_r50_l234_dwxcorr_8gpu or siamrpn_r50_l234_dwxcorr_16gpu  to train SiamRPN++. SiamMask only support inference yet. Training code for SiamMask will be ready recently.

Thanks for your reply.
I'll close this issue.


piknik not work in Ubuntu keyboard shortcuts

Hi,
Thank you for create this useful tool.
But I want to use this which one shortcuts in Ubuntu 18.04
I drop commands below in the shortcuts settings.
sh -c " sleep 0.5 && xdotool key Control_L+Insert && xclip -sel c -o > /tmp/t && xclip -sel c -o | piknik -copy"

By press super+C with select some text in chrome, I can find the xclip -sel c -o > /tmp/t put the selection to the file. But piknik seems not be trigger.
Any ideas?

Hi!
Maybe the piknik command is not in your PATH, or the path that is available for shortcut commands?
I don't use Linux, so unfortunately I can't really help with this.

Hi,
You are right, I use the Linuxbrew to install the piknik. It can work in my shell but not work for the Gnome keyboard shortcut.
So, my solution is create a softlink to /usr/bin/.
p.s. My shortcut configuration is:
# Super+C to copy current context to piknik
sh -c " sleep 0.5 && xdotool key Control_L+Insert && xclip -sel c -o > /tmp/t && xclip -sel c -o | piknik -copy"

# Super+V to paste from piknik
sh -c "sleep 0.5 && piknik -paste | xclip -i -selection c && xdotool key Shift_L+Insert"

It needs xclip and xdotool to installed.
And appreciate for the wandful tool.


Crash after logn with 'File does not exist at path '.../Enso/resources/lang/de.json' exception

Seems to missing de an nl locales.
php artisan vendor:publish --tag=localisation-lang-files fixes that.

Fixed in the last commit. Added also DE/NL to the online demo.
Thx.


Quick Accent - multi select for character sets

Description of the new feature / enhancement
Currently you can either select "All available" or select a single language.
It would be much better if it was possible to select 2 or more options from the list.
Scenario when this would be used?
Currently if you want accents for more than one language then you have to select the "All available" option for character sets.
Since this puts all possible accents in the menu this means that you have to skip a lot of characters in order to get to the characters that you actually need.
Also some languages have accents that are visually similar to accents in other languages, so you can end up selecting the wrong one.
Supporting information
No response

/dup https://github.com/microsoft/PowerToys/issues/21261


Box Plots treat NaNs as 0s

Example:

Steps to reproduce

aggregate by human development index,

Observed behavior

look at the ppl know they have HIV in the very high class, only a few countries have entries but those that have, have a pretty high percentage
but the median is still set as 0

Expected behavior

NaNs shouldn't influence the calculation of any statistics.


Server part

Added step 4 to the pull request, plan on addressing issues with comments with linter which which be configured at end.

All previous comments are addressed in interactive branch, please approve merge.


.get() in Headers does not return all headers

Request type

[ ] New documentation
[x] Correction or update

Page to change
If this request relates to an existing article, please give its URL:
https://developer.mozilla.org/en-US/docs/Web/API/Headers
Details
Please describe the change you are requesting. If you know of technical experts who can review the change, please mention them.
Try it out in a JS console:
const test = new Headers();
test.append("bla", 1);
test.get();

Results in:

TypeError: Not enough arguments to Headers.get.

in Firefox 64
or

TypeError: Headers.get requires at least 1 argument, but only 0 were passed

in Firefox 66
Whereas  test.get("bla") results in 1, as expected.
Related issues
If this request relates to other issues in Bugzilla or GitHub, please provide links:
I hope only the doc is wrong. I do not expect Firefox implements it in such a bluntly wrong way…

Coming from the issue on BCD.  I think that there may have been a misinterpretation of the note; the compatibility table doesn't mention anything about .get() with no arguments.  It mentions .getAll()'s functionality of obtaining all the headers of a given name being placed into .get(), meaning a name still needs to be specified.

But this is obsolete:

Headers.getAll()
Used to return an array of all the values of a header within a Headers object with a given name; this method has now been deleted from the spec, and Headers.get() now returns all values instead of just one.

Maybe that is really bad formulated, especially as it mentions the .get() without any given parameter.

Ah, okay.  That part isn't in the BCD, that's the documentation itself.  Yeah, I would agree, the wording seems a little odd to me.  Well, I just made a quick edit that should do the trick!  How's it look?

@vinyldarkscratch I think your rewording looks good; closing this one.

Hmm, still see no difference/explanation here.
So to clarify .get("") would get all headers or what? (Edit: tried, did not work.)
Also even https://developer.mozilla.org/en-US/docs/Web/API/Headers/get is not really explicit there. Actually, I see it nowhere even mentioned that retrieving all headers is possible.
Also consider adding an example in here. There is only the yellow box that tells the same: behaviors merged. So how do I do "get al"?? :confused:

Or is it not possibly anymore? If so, just tell it: "You cannot receive all headers without specifying them anymore." or so, but do not talk about some kind of "merging" when actually behaviour has been removed… :roll_eyes:

Ah or wait: Now I get it: .getAll could not actually return all headers? You had to specify them anyways… Ah, that makes it clear. Possibly this is also why it was renamed ("get all" implies you get well… all), so maybe this is the only misconception I had: If the old behaviour did not allow it, but was merged, no
So again, however, explicitly state it. Just something like "You cannot retrieve all headers at a time.", possibly with a workaround: "But you can…"

Since there are still  concerns here, I'll reopen this one, and I've tagged it and put it into the backlog. I've not got time right now, but I'll pick this one up in our next sprint.


Change intial name to friendly name when resolving usages

Fix this scenario:
Cadl in ADP:
@Azure.DPG.convenienceAPI
list is CustomResourceList<ClassificationSchema>;

@doc("List {name} resources", TResource)
op CustomResourceList<
  TResource extends object,
  TCustom extends Foundations.CustomizationFields = {}
> is Foundations.ResourceList<
  TResource,
  Foundations.CustomParameters<TCustom>,
  Page<TResource>
>;

Page<TResource> has a friendly name PagedTResource, so we will generate a model called PagedTResource, however, resolveUsages doesn't check friendly name, so its Usage in cadl.json would be None.

Could we add something in an existing test project or add a new test project about the changes in this PR to let us could what it does? I did not see anything about friendlyname in the test project changed in this PR
BTW if the changes in the test project in this PR is irrelevant to the changes here, it is a distraction, please try to do that in a different PR

friendlyName is defined at cadl-azure side on the template Page<TResource>. It is not defined at our test side.
The test added is to show the fix in this PR.

Can we add friendly name to a model in our cadl as well to show whether it works on that?

Can we add friendly name to a model in our cadl as well to show whether it works on that?

Added.


AI: auto test based on coverage

Pull Request Test Coverage Report for Build 3743
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.5%) to 83.637%

Totals

Change from base Build 3701:
0.5%

Covered Lines:
4309

Relevant Lines:
5152

💛  - Coveralls


HBASE-26938 Compaction failures after StoreFileTracker integration

Compactions might be concurrent against a given store and the Compactor is shared among them. Do not put mutable state into shared class fields. All Compactor class fields should be final. At the moment 'keepSeqIdPeriod' is an exception to this rule because some unit tests change it.
Compactor#getProgress and Compactor#getCompactionTargets now return union results of all compactions in progress against the store.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 48s
Docker mode activated.

FYI, we have some folks running this on a cluster against S3 now.

FWIW, we had a big ycsb load running from multiple nodes in parallel against a 5 node cluster with this change that ran happily for 6 hours (eventually failed due to an OOME which I think is just a misconfiguration by us).

Last set of changes broke tests so I will revert them.
@Apache9 I think we need to go back to the drawing board here. We need to put the call out to SFT logic somewhere else, or we need to make Compactor something that is created per compaction as was the assumption behind the changes that added the 'writer' field and requires the semantics offered by that. I will try the latter.

Last set of changes broke tests so I will revert them.
@Apache9 I think we need to go back to the drawing board here. We need to put the call out to SFT logic somewhere else, or we need to make Compactor something that is created per compaction as was the assumption behind the changes that added the 'writer' field and requires the semantics offered by that. I will try the latter.

Creating Compactor per compaction maybe too big? FWIW, we have a Compactor instance in StoreEngine, if we want to make it per compaction, it will cause a very big refactoring.
So I suggest that, we add something like a compactionId to the CompactionRequest interface, and use it as the key for our map, when calling StoreEngine.replaceStoreFile, we pass this id in, then we could use this to remove the writer in the Compactor.
WDYT?

@Apache9 I have been testing with my original workaround for what it's worth, https://github.com/apache/hbase/pull/4334 . This does allow concurrent compaction against a given store, respecting that Compactor is not thread safe for now. It works well. As an option to unblock us we could use it for now and come back to the implementation issues with SFT and compaction in a follow up issue.

@Apache9 I have been testing with my original workaround for what it's worth, #4334 . That change does not allow concurrent compaction against a given store, respecting that Compactor is not thread safe for now. It works well. The performance of the test scenario is unchanged from baseline without any SFT changes. As an option to unblock us we could use it for now and come back to the implementation issues with SFT and compaction in a follow up issue.

I do not think this is a good way to solve the problem, we do allow concurrent compactions happen at the same time in the past...

Maybe we do not call it resetCompactionWriter? We just call it cleanupCompaction or something else, which indicate that the compaction is finally finished, and the compactor should release all the related resources of this compaction.

I still think it is messy.
We have this PR in progress already, so I will make this change, so we can at least look at it.

Actually the keyed maps approach solves another problem I found. Posting an update soon. Making sure compaction unit tests all pass first.

Pushed an update that brings all of the above discussion together.

Compactions might be concurrent against a given store and the Compactor is shared among them. Add a comment to the class javadoc to not put mutable state into shared class fields. Make all Compactor class fields final, with the exception of keepSeqIdPeriod, which is set by unit tests.
Pass writer and progress instances through compaction as method parmeters of performCompaction to improve MT-safety of these code paths.
Scope compaction progress to each compaction to improve MT-safety overall and the accuracy of compaction progress reporting.

All compaction unit tests pass.
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running org.apache.hadoop.hbase.util.compaction.TestMajorCompactionTTLRequest
[INFO] Running org.apache.hadoop.hbase.util.compaction.TestMajorCompactionRequest
[INFO] Running org.apache.hadoop.hbase.quotas.policies.TestNoWritesCompactionsViolationPolicyEnforcement
[INFO] Running org.apache.hadoop.hbase.regionserver.TestMinorCompaction
[INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.427 s - in org.apache.hadoop.hbase.quotas.policies.TestNoWritesCompactionsViolationPolicyEnforcement
[INFO] Running org.apache.hadoop.hbase.regionserver.TestDateTieredCompactionPolicyOverflow
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.942 s - in org.apache.hadoop.hbase.regionserver.TestDateTieredCompactionPolicyOverflow
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.878 s - in org.apache.hadoop.hbase.util.compaction.TestMajorCompactionTTLRequest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.918 s - in org.apache.hadoop.hbase.util.compaction.TestMajorCompactionRequest
[INFO] Running org.apache.hadoop.hbase.regionserver.TestCompactionState
[INFO] Running org.apache.hadoop.hbase.regionserver.TestCompactionArchiveConcurrentClose
[INFO] Running org.apache.hadoop.hbase.regionserver.throttle.TestCompactionWithThroughputController
[INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 8.935 s - in org.apache.hadoop.hbase.regionserver.TestMinorCompaction
[INFO] Running org.apache.hadoop.hbase.regionserver.TestCompactionWithCoprocessor
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.828 s - in org.apache.hadoop.hbase.regionserver.TestCompactionArchiveConcurrentClose
[INFO] Running org.apache.hadoop.hbase.regionserver.TestCompactionWithByteBuff
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 34.662 s - in org.apache.hadoop.hbase.regionserver.TestCompactionWithByteBuff
[INFO] Running org.apache.hadoop.hbase.regionserver.TestCompactionFileNotFound
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 18.873 s - in org.apache.hadoop.hbase.regionserver.TestCompactionFileNotFound
[INFO] Running org.apache.hadoop.hbase.regionserver.TestCompactionArchiveIOException
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 11.024 s - in org.apache.hadoop.hbase.regionserver.TestCompactionArchiveIOException
[INFO] Running org.apache.hadoop.hbase.regionserver.TestCompactionLifeCycleTracker
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 84.897 s - in org.apache.hadoop.hbase.regionserver.throttle.TestCompactionWithThroughputController
[INFO] Running org.apache.hadoop.hbase.regionserver.TestMajorCompaction
[WARNING] Tests run: 3, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 16.319 s - in org.apache.hadoop.hbase.regionserver.TestCompactionLifeCycleTracker
[INFO] Running org.apache.hadoop.hbase.regionserver.TestDateTieredCompactionPolicy
[INFO] Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.984 s - in org.apache.hadoop.hbase.regionserver.TestDateTieredCompactionPolicy
[INFO] Running org.apache.hadoop.hbase.regionserver.TestCompactionInDeadRegionServer
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 26.748 s - in org.apache.hadoop.hbase.regionserver.TestCompactionInDeadRegionServer
[INFO] Running org.apache.hadoop.hbase.regionserver.querymatcher.TestCompactionScanQueryMatcher
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.896 s - in org.apache.hadoop.hbase.regionserver.querymatcher.TestCompactionScanQueryMatcher
[INFO] Running org.apache.hadoop.hbase.regionserver.TestCompaction
[INFO] Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 199.59 s - in org.apache.hadoop.hbase.regionserver.TestCompactionWithCoprocessor
[INFO] Running org.apache.hadoop.hbase.regionserver.TestDateTieredCompactionPolicyHeterogeneousStorage
[INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.228 s - in org.apache.hadoop.hbase.regionserver.TestDateTieredCompactionPolicyHeterogeneousStorage
[INFO] Running org.apache.hadoop.hbase.regionserver.compactions.TestFIFOCompactionPolicy
[INFO] Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 219.608 s - in org.apache.hadoop.hbase.regionserver.TestCompactionState
[INFO] Running org.apache.hadoop.hbase.regionserver.compactions.TestStripeCompactionPolicy
[INFO] Tests run: 36, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 11.35 s - in org.apache.hadoop.hbase.regionserver.compactions.TestStripeCompactionPolicy
[INFO] Running org.apache.hadoop.hbase.regionserver.TestCompactionAfterBulkLoad
[INFO] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 24.276 s - in org.apache.hadoop.hbase.regionserver.compactions.TestFIFOCompactionPolicy
[INFO] Running org.apache.hadoop.hbase.master.region.TestMasterRegionCompaction
[INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 8.307 s - in org.apache.hadoop.hbase.regionserver.TestCompactionAfterBulkLoad
[INFO] Running org.apache.hadoop.hbase.rsgroup.TestRSGroupMajorCompactionTTL
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 17.496 s - in org.apache.hadoop.hbase.master.region.TestMasterRegionCompaction
[INFO] Running org.apache.hadoop.hbase.mob.TestMobStoreCompaction
[INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.738 s - in org.apache.hadoop.hbase.mob.TestMobStoreCompaction
[INFO] Running org.apache.hadoop.hbase.mob.TestMobCompactionWithDefaults
[INFO] Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 208.078 s - in org.apache.hadoop.hbase.regionserver.TestCompaction
[INFO] Running org.apache.hadoop.hbase.mob.TestMobCompactionRegularRegionBatchMode
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 115.164 s - in org.apache.hadoop.hbase.rsgroup.TestRSGroupMajorCompactionTTL
[INFO] Running org.apache.hadoop.hbase.mob.TestMobCompactionOptRegionBatchMode
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 187.897 s - in org.apache.hadoop.hbase.mob.TestMobCompactionWithDefaults
[INFO] Running org.apache.hadoop.hbase.mob.TestMobCompactionOptMode
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 179.166 s - in org.apache.hadoop.hbase.mob.TestMobCompactionOptMode
[INFO] Running org.apache.hadoop.hbase.client.TestAsyncTableGetMultiThreadedWithBasicCompaction
[WARNING] Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0.022 s - in org.apache.hadoop.hbase.client.TestAsyncTableGetMultiThreadedWithBasicCompaction
[INFO] Running org.apache.hadoop.hbase.client.TestMobRestoreSnapshotFromClientGetCompactionState
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 290.012 s - in org.apache.hadoop.hbase.mob.TestMobCompactionOptRegionBatchMode
[INFO] Running org.apache.hadoop.hbase.client.TestAsyncTableGetMultiThreadedWithEagerCompaction
[WARNING] Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0.026 s - in org.apache.hadoop.hbase.client.TestAsyncTableGetMultiThreadedWithEagerCompaction
[INFO] Running org.apache.hadoop.hbase.client.TestRestoreSnapshotFromClientGetCompactionState
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 25.904 s - in org.apache.hadoop.hbase.client.TestMobRestoreSnapshotFromClientGetCompactionState
[INFO] Running org.apache.hadoop.hbase.TestAcidGuaranteesWithNoInMemCompaction
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 321.549 s - in org.apache.hadoop.hbase.mob.TestMobCompactionRegularRegionBatchMode
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 31.118 s - in org.apache.hadoop.hbase.client.TestRestoreSnapshotFromClientGetCompactionState
[INFO] Tests run: 27, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 688.559 s - in org.apache.hadoop.hbase.regionserver.TestMajorCompaction
[INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 201.193 s - in org.apache.hadoop.hbase.TestAcidGuaranteesWithNoInMemCompaction
[INFO] Results:
[WARNING] Tests run: 181, Failures: 0, Errors: 0, Skipped: 3

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 56s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+1 :green_heart:
mvninstall
2m 25s
master passed

+1 :green_heart:
compile
2m 15s
master passed

+1 :green_heart:
checkstyle
0m 35s
master passed

+1 :green_heart:
spotbugs
1m 13s
master passed

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m 59s
the patch passed

+1 :green_heart:
compile
2m  8s
the patch passed

+1 :green_heart:
javac
2m  8s
the patch passed

-0 :warning:
checkstyle
0m 33s
hbase-server: The patch generated 1 new + 39 unchanged - 0 fixed = 40 total (was 39)

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
11m 23s
Patch does not cause any errors with Hadoop 3.1.2 3.2.2 3.3.1.

+1 :green_heart:
spotbugs
1m 16s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m  8s
The patch does not generate ASF License warnings.

29m 46s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4338/3/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/4338

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux 609aeac8c873 5.4.0-1071-aws #76~18.04.1-Ubuntu SMP Mon Mar 28 17:49:57 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / f990f56e8e

Default Java
AdoptOpenJDK-1.8.0_282-b08

checkstyle
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4338/3/artifact/yetus-general-check/output/diff-checkstyle-hbase-server.txt

Max. process+thread count
64 (vs. ulimit of 30000)

modules
C: hbase-server U: hbase-server

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4338/3/console

versions
git=2.17.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

I think the key problem here is the compactionTargets is used during the whole compaction life time, but the state is only stored in compactor, which is only used for generating the new store files, so no matter what we do, it is still very awkward.
I got another idea in mind that, maybe we could just pass a StoreFileWriterTargetCollector to the compactor, the compactor implementation will add new target to the collector when creating new store file writer. And the collector is stored in StoreEngine or HStore, so we are free to clean it up at any time. The compactor does not need to do the cleanup work any more. I could implement a POC to see if it works. In general, I think we should also track the target of flushed store files as well, but this is a missing part in the original patch of HBASE-26271.

Please see if this POC could make things better...
I've introduced a a StoreFileWriterCreationTracker(actually in most places it is just a Consumer), for recording the creation of a StoreFileWriter, and this time we could also track the written files for flush. The trackers are maintained in HStore, so in compactor we do not need to store them any more.
https://github.com/Apache9/hbase/commit/79fa3a9d72aade0bfe490b301f909b3d5722de06

I don't see how we can collaborate here when pursuing two different solutions @Apache9 . I am happy to cut my losses and close this and review your solution instead.

Let @Apache9 propose a PR for his solution.
No hard feelings. Need to conserve my time.

One thing I will note is I also tried to clean up progress reporting, which will need to be separately addressed.

Let @Apache9 propose a PR for his solution that moves the scope of where this state is tracked, makes sense to me. No hard feelings. Need to conserve my time. We shouldn't be pursuing two different solutions. Let's just review the one that is cleaner, I think both Duo's proposal and Josh's comment expressed that preference.

Oh, sorry, I didn't mean to push my solution. Why I implement a POC is that seems we all think the current approach in this PR is a bit messy as we can not clean up the state with the 'try..finally' style, so I just give us an impression that what the code will look like if we can do the cleanup with the 'try...finally' style.
In fact I think the current solution in this PR is better enough to solve the problem for now and all related classes are IA.Private, so we are free to apply this PR first and then change to other approachs in the future.
So I'm neutrality on these two approach, especially if we want to fix the problem ASAP. Then we will have plenty of time to discuss what is a better solution, as it will not block the 2.5.0 release.
Just my thpughts, sorry if I didn't say this clearly before posting the POC. Anyway, if you guys think the approach in POC is generally good, let me convert it to a PR so you can better review it.
Thanks~


Recursive API

In the previous implementation the main problem was with the recursive API. In other terms, how to do nested components? I did not manage to find a proper solution. I need to solve this problem in order to make this system usable. I need a few examples where nested components are needed.

I am reading about scale-free networks: http://barabasilab.neu.edu/networksciencebook/download/network_science_december_ch4_2013.pdf
and I was reading about scale free network and fractal metrics of object oriented applications: http://homepages.mcs.vuw.ac.nz/~alex/files/PotaninNobleFreanBiddleCACM2005.pdf http://fulltext.study/preview/pdf/394262.pdf which does not appear to follow oo paradigms.
Wouldn't it be possible to do this in a scale free way. I mean having hubs and smaller nodes? For example there could be main nodes and helper nodes, or something like that. I am not sure about this yet, but I think this part worths some thought.

Hubs are highly connected nodes. That means that there should be a few classes which are used by many-many classes. Or there should be a few objects which are used by many-many objects. Actually this is the reverse of the abstraction level if you think about it. Many classes can be dependent on a few basic utility class. So the low abstraction level utility classes have the most connections. I don't feel this right. I mean this suggests that low abstraction level classes (hubs) are more important than high abstraction level classes, but from a human perspective the opposite is true.

So let's get back to the API. Currently I have a lot of nested calls, like:
pump1.on("pulled", function (flow1){
    pump2.pull(function (flow2){
        flow1.sustain(flow2.extract());
    });
});
pump2.on("pulled", ...);
...
setInterval(function (){
    pump1.pull(function (flow1){
        console.log(flow1.extract());
    });
}, 100);

pump1.on("pushed", function (flow1){
    pump2.push(function (flow2){
        flow2.sustain(flow1.extract());
    });
});
pump2.on("pushed", ...);
...
setInterval(function (){
    pump1.push(function (flow1){
        flow1.sustain(Math.floor(Math.random()*100));
    });
}, 100);

https://github.com/inf3rno/dataflower/issues/115

These we can call connections between nodes.
Is it possible to use the same pattern to do something like this?
pump1 <-> pump2 <-> pump3 <- ...

Where <- means pull+pulled+sustain+cb and -> means push+pushed+await+cb?
I am not sure whether the current model works this way. I mean a pump controls a single flow. In the previous API the flow term was absent. So this is something new. I need to play with it.

Actually the old structure looked like this:

a single pump can have multiple flows
the flows are the connections between these pumps
a pump can be publisher, subscriber or both

Now this does not really worked out by req-rep, that's why I changed the design, which still does not work by req-rep, but it is somewhat better. xD

I'll continue this later.

Let's talk about scale-free networks again. Hubs have navigation purpose by those. So if I want to flow data from a to e, then I have to use something like a -> B -> C -> D -> e, where the uppercase characters are hubs. Can we apply the same rules on our network nodes? Sure we can. So I think we need a structure something like this. We need hub components which are known globally and locally and we need simple nodes which are known only locally. The simple nodes can use only hubs to reach each other. Should they know of each other? I don't think so, at least implementation hiding should prevent that. We need to define some kind of interface they can use to communicate. E.g. they can publish that they can make some tasks, something similar to the service provider pattern. Another possible solution to communicate via message type. So the receiver can check whether it can accept a message or not. Probably we can combine both and publish which type of messages a node can handle.


Use POST for write web requests

To prevent CSRF
Closes https://github.com/moove-it/sidekiq-scheduler/issues/322

Coverage remained the same at 97.86% when pulling 84a1407dcee56d034d69bacf3a33d0f92f08e24a on sorare:bug/use-post-for-write-requests into 1dcb2669749f7d082c84dbaf0cf5ff912bb15119 on moove-it:master.

Thanks @such


Instructions for contributing to nixpkgs docs do not work

Describe the bug
To contribute to the nixpkgs documentation I followed the instructions in the nixpkgs manual "Chapter 21. Contributing to this documentation" and I followed the code snippet
$ cd /path/to/nixpkgs/doc
$ nix-shell
[nix-shell]$ make

Firstly I was greeted with some warnings:
trace: lib.crossLists is deprecated, use lib.cartesianProductOfSets instead
trace: `mkStrict' is obsolete; use `mkOverride 0' instead.
trace: `lib.nixpkgsVersion` is deprecated, use `lib.version` instead!
trace: warning: lib.readPathsFromFile is deprecated, use a list instead
trace: Warning: `showVal` is deprecated and will be removed in the next release, please use `traceSeqN`
trace: lib.zip is deprecated, use lib.zipAttrsWith instead

But moving on to make I saw a large number of /diagram-generator.lua: openBinaryFile: does not exist (No such file or directory) errors. It looks like makeFlags=PANDOC_LUA_FILTERS_DIR=/nix/store/xyn7np2z62dr711sgxyz2lkxk54pwivx-pandoc-lua-filters-2020-11-30/share/pandoc/filters is set up inside the nix-shell but it's not picked up by make?
Running the nix-build . command does work.
To Reproduce
$ cd /path/to/nixpkgs/doc
$ nix-shell
[nix-shell]$ make

Expected behavior
No warnings, no errors.
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
 - system: `"x86_64-linux"`
 - host os: `Linux 5.11.21, NixOS, 21.11.20210527.5658fad (Porcupine)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.4pre20210503_6d2553a`
 - channels(frijters): `""`
 - channels(root): `"nixos, nixos-unstable-20.09pre225264.683c68232e9"`
 - nixpkgs: `/etc/nixpkgs`

Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:

nix-shell has a specific setup to allow running stdenv phases such as
[nix-shell]$ buildPhase

https://nixos.org/manual/nix/unstable/command-ref/nix-shell.html

That also gives me a bunch of errors as well, but different ones:
stdenv/stdenv.chapter.xml:1: parser error : Document is empty

^
manual.xml:18: element include: XInclude error : could not load stdenv/stdenv.chapter.xml, and no fallback was found

For a bunch of files.
I managed to write some updates to the docs and validated them just using the nix-build command, but it's a bit unfortunate that just following the instructions literally doesn't work.

Sorry about that. https://github.com/NixOS/nixpkgs/pull/125625 should fix it.

Thanks, that fixes it for me (tested by setting the env variable manually).
Great to see these steps towards making it easier to contribute to the docs.


Update recommended version in README

Pursuant to discussion in https://stackoverflow.com/questions/68177877/need-help-resolving-typeerror-in-julia/68182821#68182821, it appears that these notebooks have actually been updated for Julia 1.6, but the readme still specifies Julia 1.4.
I can confirm that the manifest can in fact be instantiated in 1.6, consistent with the compat requirement in Project.toml and the description of various recent commits by @logankilpatrick.
If correct, the readme just needs to be updated, so these changes would fix #35

You are correct, thanks for this!


Auto-fuzz: Add some language specific properties to constants.py

This PR adds some language specific properties to constants.py to allow generalising the static analysis process of auto-fuzz.

Yes. Added.


Update compose_setup for UI config changes

Feature Request
With upcoming changes where UI will get its config information from web service (#2385 and #2386), update compose_setup to:

No longer have a dockstore.model.ts.template
Update web.yml.template with new uiconfig section, with appropriate parameterized values

┆Issue is synchronized with this Jira Story
┆Issue Type: Story
┆Fix Versions: Dockstore 1.7
┆Sprint: Seabright Sprint 10 Jet Ski
┆Issue Number: DOCK-701
┆Epic: Serve UI from s3/CloudFront

This is now the case for staging.dockstore.org