Convergence rates of the global ZZ error estimate appear to depend on the parity of the polynomial order

I am using total_error computed with a  ZZErrorEstimator object as stopping criteria in an adaptive mesh refinement project. Although the refinement patterns the estimator produces appear reasonable, I noticed the following suspicious behaviour: When the polynomial order is even, the convergence rate is one degree higher than the true H^1_0 error. When the polynomial order is odd the convergence rate of the error estimate agrees with the convergence rate of the true H^1_0 error.
I have verified this behaviour with two independent implementations of the same L-shaped domain benchmark problem, which has its solution in H^{3/2}. Attached are a number of convergence plots demonstrating the behaviour.
ConvergencePlotOrder1.pdf
ConvergencePlotOrder2.pdf
ConvergencePlotOrder3.pdf
ConvergencePlotOrder4.pdf

The issue appears with uniform refinements as well. Here are the convergence rates when the exact solution is u(x,y) = sin(πx) sin(πy).
ConvergencePlotOrder1.pdf
ConvergencePlotOrder2.pdf
ConvergencePlotOrder3.pdf
ConvergencePlotOrder4.pdf

For completeness, was this with a quad mesh or triangles? If using triangles, was this conforming or nonconforming refinement? Also, what was the flux FE space? Was it vector H1? It will be interesting to see what the behavior looks like with an RT flux space.
From theoretical point of view, I'm not sure what theory exists for this setup and what it says. In any case, this is an interesting study.

Hi @v-dobrev, it was with quads. The flux FE space is vectorial H^1 of space order of the potential field (this is as in the original papers).  I tried with RT but I believe that is only supported in the parallel implementation. Part 2 of the original pair of papers considers order p=2 conforming quads and shows asymptotic exactness.
I am willing to try to add RT support to the ZZ routine, but I don't understand the code well enough yet. I'm also not sure if that is the issue here, as the results in the original paper already seem to conflict with what I am seeing.

If anyone would like to experiment, I wrote a script to reproduce the issue here: https://github.com/mfem/mfem/tree/zz_test/ZZ_test

It is possible that the implementation in MFEM does not exactly match the algorithm from the paper(s). Can you post links to the papers you mentioned?

https://doi.org/10.1002/nme.1620330702
https://doi.org/10.1002/nme.1620330703

This is now being discussed internally.


Update Readme.md for running doctor on Ubuntu

you need to add one more line
/usr/lib/postgresql/9.5/bin/initdb -D

This should go away when we swap with sqlite

Also psql -c 'alter user harsha with createdb' postgres

PR sent.


Update YQ

Tool name
yq
Tool license
Apache-2.0 License
Add or update?

[ ] Add
[X] Update

Desired version
latest
Approximate size
No response
Brief description of tool
About Command-line YAML, XML, TOML processor - jq wrapper for YAML/XML/TOML documents
https://github.com/mikefarah/yq (Currently default, experience jq incompatibility)
https://github.com/kislyuk/yq (jq wrapper)
I think whether it is possible to provide a yq that is consistent with the experience of jq
URL for tool's homepage
https://github.com/kislyuk/yq
Provide a basic test case to validate the tool's functionality.
No response
Virtual environments affected

[ ] Ubuntu 16.04
[ ] Ubuntu 18.04
[ ] Ubuntu 20.04
[ ] macOS 10.15
[ ] macOS 11
[ ] Windows Server 2016
[ ] Windows Server 2019
[ ] Windows Server 2022

Can this tool be installed during the build?
No response
Tool installation time in runtime
No response
Are you willing to submit a PR?
YES

/cc @Yann-J
/cc @AlenaSviridenko
/cc @maxim-lobanov

Hmm, I didn't realize there were 2 tools with the same name, thanks for spotting that...
My 2 cts would be that consistency with jq isn't really a huge benefit IMHO. And judging from the github repos and docs, the original yq (https://github.com/mikefarah/yq) seems more popular (more stars, forks, has a popular Github action, a popular docker image with 6M pulls), better maintained, and from what I can see, seems more capable (the other one isn't native YAML but works by first converting documents to JSON and piping to jq, which will inevitably lose YAML-specific features like comments and references).
If jq syntax is desired, piping yq --output-format=json to jq, and then back to yq --prettyPrint seems like it should work.
I'd personally vote to stick to https://github.com/mikefarah/yq

Hello @wzshiming,
@Yann-J answer looks pretty convincing, I think it does not make sense to change anything in the existing yq tool installation. Anyway, if you have any others questions or concerns, feel free to contact us here.
I'm going to close the issue.


fix/#979 fix springboot running plain jar instead of executable jar

This PR solves the following issue: https://github.com/railwayapp/nixpacks/issues/979
Disclaimer:  This drops support of any spring version that does not have a bootJar task, mainly spring v1

Adjust the JavaProvider so that it uses bootJar to build an executable JAR instead of build which generates a *plain.jar also when spring and gradle is detected
Add e2e test cases for spring v2 and v3, also remove spring v1
Update the docs of the JavaProvider so that it has information regarding the spring version support, and the build commands

As per the comments below PR implements a different solution now:

Adjust the JavaProvider so that if gradle and spring is detected then the start cmd includes a one line to find the executable jar and blacklists the plain.jar
Add e2e test cases for spring v1, v2 and v3
Update the docs of the JavaProvider so that it includes description for the new start cmd if gradle and spring is detected

[x] Unit tests are added
[x] E2E tests are added
[x] Docs are updated

Thank you 🎉


Broken links in documentation

Many of the links, perhaps all of them in the docs point to 404s when viewing in github. I can't do an exhaustive list but might be worth reviewing the docs and where they point. some links are mentioned a few times with different text but still ultimately point to pages that result in 404s. I think in most cases, simply adding .md actually fixes them.
Examples:
In index.md there are several, possibly all of them

query language
dataview api
guide
reference material
documentation
documentation

In data-queries.md every link is broke
Describe the problem
Not so much as unclear as when reading through the docs I'd expect these links to point to content when viewing from github, but they instead go to pages that do not exist.
Describe the solution you'd like
This links should be updated to point to the current doc intended or removed if they no longer exist. They probably just need to add .md to the end of them in most cases.

You aren't supposed to view the docs via github. Please use the official documentation site: https://blacksmithgu.github.io/obsidian-dataview/

You aren't supposed to view the docs via github. Please use the official documentation site: https://blacksmithgu.github.io/obsidian-dataview/

I was aware of the  website (which is why i was pointing out the 'w/ github) but wasn't aware i wasn't 'supposed' to use the /docs folder when viewing the project.
Other projects I use/follow I generally have no issue using the /docs folder and often pull down the project locally, especially if I want to get a closer look and may consider contributing.
Apologies.

There are instructions to build docs locally but I couldn't get it to work TBH. If I had files locally, I'd probably grep around to find things but I suspect someone already inclined to do that would likely just use the Electron console anyway.


[xSqlServerScript]Fixing PSSA errors - Fixes #728

As raised in #728 there are various ScriptAnalyzer errors from the parameters being marked as Mandatory = $false, this resolves those errors.

This change is

@ChrisLGardner,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by Microsoft. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

Codecov Report

Merging #764 into dev will not change coverage.
The diff coverage is n/a.

@@         Coverage Diff         @@
##            dev   #764   +/-   ##
===================================
  Coverage    97%    97%
===================================
  Files        30     30
  Lines      3250   3250
===================================
  Hits       3165   3165
  Misses       85     85

@ChrisLGardner Thanks for fixing this and the others! Please add this change to the CHANGELOG.md.

Done.

Reviewed 1 of 1 files at r1, 1 of 1 files at r3.
Review status: all files reviewed at latest revision, 1 unresolved discussion.

CHANGELOG.md, line 55 at r3 (raw file):

[Issue #728]

Please use lower-case 'i' in issue to be consequent with the other entries.

Comments from Reviewable

Review status: all files reviewed at latest revision, 2 unresolved discussions.

CHANGELOG.md, line 55 at r3 (raw file):

Please remove on of the dashes here as well.

Comments from Reviewable

Review status: 1 of 2 files reviewed at latest revision, 2 unresolved discussions.

CHANGELOG.md, line 55 at r3 (raw file):
Previously, johlju (Johan Ljunggren) wrote…

[Issue #728]

Please use lower-case 'i' in issue to be consequent with the other entries.

Done.

CHANGELOG.md, line 55 at r3 (raw file):
Previously, johlju (Johan Ljunggren) wrote…

Please remove on of the dashes here as well.

Done.

Comments from Reviewable

Reviewed 1 of 1 files at r4.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


App not running

Prerequisites

[ ] Verify that this is not a Windows issue;
[ ] Refer to the Before running.
[ ] Refer to the How to use.
[ ] If you issue concerns the Wrapper, please mention @BenchTweakGaming in issue

Steps to reproduce
After running script from PowerShel version 7.2 ended error:
PropertyNotFoundException: The property 'productState' cannot be found on this object. Verify that the property exists.

MethodInvocationException: Exception calling "Substring" with "2" argument(s): "startIndex cannot be larger than length of string. (Parameter
'startIndex')"

PropertyNotFoundException: The property 'ProductStatus' cannot be found on this object. Verify that the property exists.

Please run this and the output:
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName Antivirusproduct

And you didn't check all necessary checkboxes in your issue.

Please run this and the output:
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName Antivirusproduct

And you didn't check all necessary checkboxes in your issue.

displayName              : McAfee VirusScan Enterprise
instanceGuid             : {A37DD4B2-BDFF-70DA-DE19-9F9927D6940F}
pathToSignedProductExe   : C:\Program Files (x86)\McAfee\VirusScan Enterprise\SHSTAT.EXE
pathToSignedReportingExe : C:\Program Files (x86)\McAfee\VirusScan Enterprise\VsTskMgr.exe
productState             : 397312
timestamp                : Fri, 12 Aug 2022 08:43:24 GMT
PSComputerName           :

Could you format the output to amek it releasable?
Code

And you still didn't check checkboxes that indicates that this is not Windows issue and so on

I have Windows Enterprise G edition where is Windows Defender fully deactivated from factory.

Ah, I forgot about it. He-he! Well, this version isn't supported officially, but I will add formal support. Will release a new build today or tomorrow.

Fixed in 5.13.4 now.

All these errors are minor and can be ignored. I do not not want to re-write all the script only for this special Chinese Windows. :)

Sorry but issue is not fixed...
after run ended with error:
The property 'productState' cannot be found on this object. Verify that the property exists.
At U:\Downloads\T\Module\Sophia.psm1:285 char:2
+     $productState = (Get-CimInstance -Namespace root/SecurityCenter2  ...
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], PropertyNotFoundException
    + FullyQualifiedErrorId : PropertyNotFoundStrict

Exception calling "Substring" with "2" argument(s): "startIndex cannot be larger than length of string.
Parameter name: startIndex"
At U:\Downloads\T\Module\Sophia.psm1:286 char:2
+     $DefenderState = ('0x{0:x}' -f $productState).Substring(3, 2)
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : ArgumentOutOfRangeException

The property 'ProductStatus' cannot be found on this object. Verify that the property exists.
At U:\Downloads\T\Module\Sophia.psm1:327 char:6
+     if ((Get-CimInstance -ClassName MSFT_MpComputerStatus -Namespace  ...
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], PropertyNotFoundException
    + FullyQualifiedErrorId : PropertyNotFoundStrict

I tested it on a VM. Could you redownload archive again? I uploaded a new version with the same tag. And upload screenshot with the error.

And please t3at without the Wrapper.

If you have Discord: upload screenshots there.
https://discord.gg/sSryhaEv79

on left is PS 5.1, left PS 7.2

If you have Discord: upload screenshots there. https://discord.gg/sSryhaEv79

i will accepted... i am send screenshot to channel sophia-script-en

 on right is PS 5.1, left PS 7.2

The left screenshot makes no sense: you tried to run the PS 5.1 module in PS 7 instance.))

And run this
Get-ItemPropertyValue -Path "HKLM:\SOFTWARE\Microsoft\Windows nt\CurrentVersion" -Name EditionID

And run this
Get-ItemPropertyValue -Path "HKLM:\SOFTWARE\Microsoft\Windows nt\CurrentVersion" -Name EditionID

EnterpriseG

 on right is PS 5.1, left PS 7.2

The left screenshot makes no sense: you tried to run the PS 5.1 module in PS 7 instance.))

yes, but in Sophia script is...
#Requires -RunAsAdministrator
#Requires -Version 5.1

Waiting for your response on Discord.

Any response?


Implement maze generator

Very basic maze generator is in the master.
Remaining tasks and issues (for future):

Parse LvlMaze.txt in order to get room count
Improve rooms merge strategy (all merged at the moment)
Find out a way to detect maze LvlPrest.txt palette in order to avoid huge amount of hardcode
Implement custom layouts for some levels (arcane sanctuary, for example)


Implement the W3C TDM Reservation Protocol and enable a more standard opt-out mechanism

The solution which was chosen by the author after a heated discussion in #293 was to support an opt-out expressed in http headers, via well know values "noindex" and "noimageindex" plus the ad-hoc values "noai" and "noimageai".
This is already a good move: in Europe, any crawler associated with TDM and AI technologies MUST support opt-out, as stipulated by the European DSM Directive. You'll get more information here about that legal requirement. Because this soft is gathering images available for AI training, it should not integrate in its dataset images for which authors have decided an opt-out.
But "noai" and "noimageia" are not well known tokens (even if you're not alone trying them), there is nothing standard in them so far. And robots.txt is not only about http headers. Directives can be in a file stored at the root of the web site (and as html meta, but this is not interesting here). Therefore your move does not really help the community establishing trusted relationships between AI solutions and content providers (which is a requirement if you want content providers to see AI actors as partners, not enemies).
For this reason, a  W3C Community Group constituted of content providers and TDM actors decided to create an open specification two years ago, and released this specification called TDMRep (for TDM Reservation Protocol). The home page of the group is there; 42 participants.
For those wondering, this specification also covers AI solutions. And this group didn't use robots.txt for clear reasons.
Adding the support of a new property in the http header, called "tdm-reservation", and filtering images if its value is 1 (number)  is a no-brainer. Adding the support of a JSON file named tdmrep.json, hosted in the /.well-known repository of the Web server on which the image is stored, is a bit more complex, but still easy in Python (it is identical to the processing of the robots.txt file); and its is mandatory even if less performant.

Hi @maathieu,
To what extent is X-Robots-Tag: noai more standard than tdm-reservation: 1?  A Web server must in both cases be tuned to generate the property.
The evolution of is_disallowed() is far from complex. Would it help if contributors propose a PR?
The main complexity will in any case be to handle a robots.txt or tdmrep.json file.
Note: the W3C Community Group is waiting for more feedback from implementers before going through the W3C Recommendation route.

Adding a new header in the set of disallowed ones seems indeed fine.
Note img2dataset did not introduce the noai and noimageai tags, there were suggested by DeviantArt, see #218
It would be great to see this standardized instead of each website creating their own.
As for tdmrep.json, i am wondering if you considered specifying in the response headers that this file exists? If that were the case, it would be possible to check this file only for the (initially small minority) of websites providing it.

It would be great to see a set of opt out headers standardized instead of each website creating their own.

YES, this is why we would all like to have a worldwide standard for TDM and AI opt-out (and because a raw opt-out is not great for the future of AI, we're trying to allow deals to be made).

As for tdmrep.json, i am wondering if you considered specifying in the response headers that this file exists?

No, we didn't consider that. A simple HEAD on tdmrep.json that responds with a 404 is not a huge lack of performance. PS: You will have to parse robots.txt if you want to check its rules, which takes much more time.

To what extent is X-Robots-Tag: noai more standard than tdm-reservation: 1?

Neither of them is "more standard." TDMRep is a draft specification, it (by necessity) explicitly states that it's not a W3C standard, and it only has one author and editor: you. I counted participants in the mailing by hand and saw 20 unique names, which isn't even enough for the "There are dozens of us! Dozens!" meme.
Using your not-a-standard wouldn't make the owner of this repo any less inconsiderate or any less of a disingenuous clown.

@DavidJCobb , good point, that was a nice strawman argument from @llemeurfr . Robots.txt does not require any server tuning. Just place the file in the root directory. The scraper will download the file once, then compare all the URLs it wishes to scrape to the data placed in robots.txt . If there is no match, then it can download. If there is a match, then no download. There is no need to invent something new and convoluted to replace this established practice. A scraper is not different from a search engine spider. Google has also been doing "AI" for decades, and it has respected robots.txt on webmaster's websites. Please be good netizens. It's not because AI is the shiny new thing that all established practices must be abandoned.


DocsArchive-1.0.21020.4Auto archive content

Auto archive content from https://github.com/opstestprod1/E2E_DocsArchive_Prod.git

Docs Build status updates of commit 717474e:
:clock10: Pending: waiting for processors (9 builds ahead of you)
:warning: Docs Build is busy, currently there are 9 builds ahead of this one, for more information you can view the Build queue graph on the Docs Portal.

Docs Build status updates of commit 717474e:
:clock10: Pending: waiting for processors (9 builds ahead of you)
:warning: Docs Build is busy, currently there are 9 builds ahead of this one, for more information you can view the Build queue graph on the Docs Portal.

Docs Build status updates of commit 717474e:
:warning: Validation status: warnings

File
Status
Preview URL
Details

e2e_archiveDocs_Prod_20210125220112/fallback.md
:warning:Warning
View
Details

.openpublishing.publish.config.json
:white_check_mark:Succeeded

.openpublishing.redirection.json
:white_check_mark:Succeeded

e2e_archiveDocs_Prod_20210125220112/TOC.yml
:white_check_mark:Succeeded
View

e2e_archiveDocs_Prod_20210125220112/breadcrumb/e2e_archiveDocs_Prod_20210125220112/toc.yml
:white_check_mark:Succeeded

e2e_archiveDocs_Prod_20210125220112/docfx.json
:white_check_mark:Succeeded

e2e_archiveDocs_Prod_20210125220112/fallback.md

Line 2, Column 1: [Warning-ms-author-missing] Missing required attribute: 'ms.author'. Add the current author's Microsoft alias.
Line 2, Column 1: [Warning-ms-prod-or-service-missing] One of the following attributes is required: 'ms.prod', 'ms.service'. Use ms.prod for on-premise products, or ms.service for cloud services.
Line 2, Column 1: [Suggestion-description-missing] Missing required attribute: 'description'.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 717474e:
:warning: Validation status: warnings

File
Status
Preview URL
Details

e2e_archiveDocs_Prod_20210125220112/fallback.md
:warning:Warning
View
Details

.openpublishing.publish.config.json
:white_check_mark:Succeeded

.openpublishing.redirection.json
:white_check_mark:Succeeded

e2e_archiveDocs_Prod_20210125220112/TOC.yml
:white_check_mark:Succeeded
View

e2e_archiveDocs_Prod_20210125220112/breadcrumb/e2e_archiveDocs_Prod_20210125220112/toc.yml
:white_check_mark:Succeeded

e2e_archiveDocs_Prod_20210125220112/docfx.json
:white_check_mark:Succeeded

e2e_archiveDocs_Prod_20210125220112/fallback.md

Line 2, Column 1: [Warning-ms-author-missing] Missing required attribute: 'ms.author'. Add the current author's Microsoft alias.
Line 2, Column 1: [Warning-ms-prod-or-service-missing] One of the following attributes is required: 'ms.prod', 'ms.service'. Use ms.prod for on-premise products, or ms.service for cloud services.
Line 2, Column 1: [Suggestion-description-missing] Missing required attribute: 'description'.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


Cannot install Windows version

When I try to run the Install.ps1 file, I get a message that "The frameworks with name "Microsoft.NET.CoreRuntime.2.2" currently installed are: {}". I've tried manually installing multiple versions of Core runtime and SDK, with no luck. I also ran CompanionApp.UWP_<IP_ADDRESS>_x86_x64_arm_Debug.appxbundle by itself and receive a message "App Installer failed to install package dependencies. Ask the developer for Microsoft.VCLibs.140.00.Debug package."

I have the same issue with version 2020-08-12, any news about this issue?

I have the same issue with version 2020-08-12, any news about this issue?


last commit 2011 - still active now in 2017?

Just curious if this resource is still active and functional in 2017 with OS Sierra?
Thanks very much...

Perhaps it needs to be updated for Retina support?  The Retina Mac came out in 2012, which is after this release.   thanks!!

@ronpackard unfortunately, the lack of updates is indicative of our support for it.

Well, I'm sure we can fix it - if it basically still works?!


Validate uniqueness of values in Arrays of IDs

Fixes https://github.com/MobilityData/gbfs-json-schema/issues/99
Example of vehicle_types.json file with with duplicate ids in the field vehicle_types.pricing_plan_ids:
"pricing_plan_ids": ["1-standard", "1-standard"]

Before
After

Reverting the validation of unique values in Arrays of IDs since this is a best practice, not explicitly written in the specs.


update xml document (batch 3 "D" to "I")

Contributing to the Azure SDK
Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.
For specific information about pull request etiquette and best practices, see this section.

API change check
API changes are not detected in this pull request.

API change check
API changes are not detected in this pull request.


[VS Code] Live Share extension failed to initialize, try to reload the VSCode window and try again.

Error:
Live Share extension failed to initialize, try to reload the VSCode window and try again.
Steps to Reproduce:

Version Data

extensionName
VSLS

extensionVersion
0.3.423

protocolVersion
2.2

applicationName
VSCode

applicationVersion
1.25.1

platformName
Linux

platformVersion
4.15.0-29-generic

Thanks for reporting this! Could you try uninstalling and reinstalling the extension? That may help unblock this issue. We’re tracking this issue via #660, so I’m going to close this as a duplicate in order to consolidate the conversation. But let us know if the mentioned workaround helps. Thanks!


Linting, PR checks, etc

I know how to do this in python land, but this is a whole new beast for me.

Status report:

We now have linting and PR checks involving that linting.
We are using an .editorconfig file to tweak some of those rules and check for more than just whitespace.

We are not using any other Analyzers yet.


pillar_features IndexError: too many indices for tensor of dimension 1

(openpcdet) ves@ves:~/OpenPCDet/tools$ python demo.py --cfg_file cfgs/kitti_models/pointpillar.yaml --ckpt pointpillar_7728.pth --data_path /media/ves/Z/bag_ansan/pcd_out/npy_list/1718073773.002808809.npy
2024-07-09 13:41:48,997   INFO  -----------------Quick Demo of OpenPCDet-------------------------
2024-07-09 13:41:48,997   INFO  Total number of samples: 	1
/home/ves/anaconda3/envs/openpcdet/lib/python3.9/site-packages/torch/functional.py:504: UserWarning: torch.meshgrid: in an upcoming release, it will be required to pass the indexing argument. (Triggered internally at /opt/conda/conda-bld/pytorch_1702400441250/work/aten/src/ATen/native/TensorShape.cpp:3526.)
  return _VF.meshgrid(tensors, **kwargs)  # type: ignore[attr-defined]
2024-07-09 13:41:49,148   INFO  ==> Loading parameters from checkpoint pointpillar_7728.pth to CPU
2024-07-09 13:41:49,165   INFO  ==> Done (loaded 127/127)
2024-07-09 13:41:49,181   INFO  Visualized sample index: 	1
Traceback (most recent call last):
  File "/home/ves/OpenPCDet/tools/demo.py", line 138, in <module>
    main()
  File "/home/ves/OpenPCDet/tools/demo.py", line 124, in main
    pred_dicts, _ = model.forward(data_dict)
  File "/home/ves/OpenPCDet/pcdet/models/detectors/pointpillar.py", line 12, in forward
    batch_dict = cur_module(batch_dict)
  File "/home/ves/anaconda3/envs/openpcdet/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1518, in _wrapped_call_impl
    return self._call_impl(*args, **kwargs)
  File "/home/ves/anaconda3/envs/openpcdet/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1527, in _call_impl
    return forward_call(*args, **kwargs)
  File "/home/ves/OpenPCDet/pcdet/models/backbones_2d/map_to_bev/pointpillar_scatter.py", line 41, in forward
    pillars = pillar_features[batch_mask, :]
IndexError: too many indices for tensor of dimension 1

my_npy_file.zip
The pillar_features of the npy file that works for 3D object detection is a 2D array, but the pillar_features of my npy file is output as a 1D array.
# pointpillar_scatter.py
class PointPillarScatter(nn.Module):
    def __init__(self, model_cfg, grid_size, **kwargs):
        super().__init__()
        self.model_cfg = model_cfg
        self.num_bev_features = self.model_cfg.NUM_BEV_FEATURES
        self.nx, self.ny, self.nz = grid_size
        assert self.nz == 1

    def forward(self, batch_dict, **kwargs):
        # print(batch_dict)
        pillar_features, coords = batch_dict['pillar_features'], batch_dict['voxel_coords']
        batch_spatial_features = []
        batch_size = coords[:, 0].max().int().item() +

        # By using this code, the point cloud is displayed, but the 3D boxes are not.
        # if len(pillar_features.shape) == 1:
        #     pillar_features = pillar_features.unsqueeze(0)

        for batch_idx in range(batch_size):
            spatial_feature = torch.zeros(
                self.num_bev_features,
                self.nz * self.nx * self.ny,
                dtype=pillar_features.dtype,
                device=pillar_features.device)

            batch_mask = coords[:, 0] == batch_idx
            this_coords = coords[batch_mask, :]
            indices = this_coords[:, 1] + this_coords[:, 2] * self.nx + this_coords[:, 3]
            indices = indices.type(torch.long)

            print('*****')
            print(f'pillar_features: \n{pillar_features}\npillar_features.shape: {pillar_features.shape}')
            print('-----------------------------')
            print(f'batch_mask: \n{batch_mask}\nbatch_mask.shape: {batch_mask.shape}')
            print('*****')

->
python demo.py --cfg_file cfgs/kitti_models/pointpillar.yaml --ckpt pointpillar_7728.pth --data_path pointcloud_test.npy

pillar_features:
tensor([0.0000e+00, 1.2826e+32, 4.2726e+31, 1.5496e+31, 2.6135e+30, 8.7043e-01,
        2.6156e-01, 1.0135e+29, 5.3591e-01, 2.0796e+29, 1.7418e+31, 0.0000e+00,
        6.4862e+28, 0.0000e+00, 4.0649e-01, 2.6790e+31, 2.8577e+32, 5.4466e+29,
        6.6605e+31, 3.5346e+31, 0.0000e+00, 0.0000e+00, 1.8015e-01, 4.4836e+30,
        1.3956e+32, 1.2039e+29, 3.6126e-03, 0.0000e+00, 0.0000e+00, 2.6504e+30,
        0.0000e+00, 3.7262e-01, 1.6756e-01, 4.0609e+29, 1.6201e+31, 2.0788e+31,
        2.7670e+00, 7.9919e+30, 6.3981e+31, 0.0000e+00, 2.0904e+00, 4.9841e+30,
        1.7689e+31, 0.0000e+00, 7.4313e+30, 0.0000e+00, 0.0000e+00, 3.7969e+31,
        8.6608e-02, 1.2728e+30, 4.5646e-01, 1.9545e-01, 0.0000e+00, 2.8419e+32,
        1.6905e+29, 1.3752e+32, 3.9255e+31, 7.6501e+29, 2.7532e+32, 6.4052e+31,
        0.0000e+00, 3.3674e+30, 2.3766e-02, 4.8696e+31], device='cuda:0')
pillar_features.shape: torch.Size([64])
-----------------------------
batch_mask:
tensor([True], device='cuda:0')
batch_mask.shape: torch.Size([1])

What could be the reason for this, and is there any solution?

@Oh-JongJin Same issue here, any further advancements or solutions on this issue?


detekt error RedundantVisibilityModifierRule in generated code

compose-destinations version: 1.7.30-beta
detekt version: 1.22.0
compose-destinations ksp generates this code:
public class MyLabelsNavType

Which triggers this detekt warning:
RedundantVisibilityModifierRule: Line 16: MyLabelsNavType is explicitly marked as public. Public is the default visibility for classes. The public modifier is redundant.

See detekt docs: https://detekt.dev/docs/rules/style/#redundantvisibilitymodifierrule
No need to explicit specify public on classes or objects
Workaround:
Consumer of this lib can exclude generated sources in detekt config: https://detekt.dev/docs/introduction/configurations/#path-filters--excludes--includes

Hi @yogurtearl!
This was done for #221.
I don't think generated code should be subject to linters like detekt because:

The generated code was not written by your team
Your team shouldn't care about the generated code, it's not going to be maintained or read. So a lot of warnings don't actually matter
Has code generated tool, there will always be conceptions done in the name of simplifying the code that generates the code. For example, instead of adding another config, another if to whether or not to use explicit api, I just do it always since there really is no harm in it.

Does this make sense to you?

I'm closing this for lack of feedback. Let me know if I can still help any further :)


Using pyodata with userID and password

I want to use pyodata package for non-SAP API like https://odata.restaurant365.net/api/v2/views/SalesPayment, which requires me to pass my userID and password to access the data. I have figure out how to send ID/pswd . Appreciate a quick help.

Thank you for taking the time to create the issue. PyOData does not implement any part of HTTP protocol, PyOData relies on an external HTTP library. If you copied sample codes from the documentation, you are most probably using Python Requests. So Just initialize your Python requests session with your credentials.
The minimal example as from the documentation https://pyodata.readthedocs.io/en/latest/#basic-usage would look like this:
import pyodata
import requests

SERVICE_URL = 'http://services.odata.org/V2/Northwind/Northwind.svc/'
HTTP_LIB = requests.Session()
HTTP_LIB.auth = ('SOME_USER', 'SECRET_PASSWORD')

northwind = pyodata.Client(SERVICE_URL, HTTP_LIB)

for customer in northwind.entity_sets.Customers.get_entities().execute():
    print(customer.CustomerID, customer.CompanyName)

Thanks for the explanation. Hels.


Lint is failing on master

After https://github.com/open-telemetry/opentelemetry-js/pull/892 is merged, lint starts failing on master branch and PRs that merged master branch.
/cc @OlivierAlbertini since they are the original author of the root commit.
Edit: seems like it's not failing on CI, I'll check it further.

Sorry, seems like there is no color outputs with lerna run lint and the warnings were treated as errors. Closing since this is not a problem.


Adding SWMM calculation options - along with some minor unit tweaks

I made a pass on diameters and changed the koq to LENGTH_SHORT where appropriate - structure diameter is usually presented in the larger units for example
There were a couple of spots using the wrongs units , or using the AECU units instead of the rru
Add a enum to the rainfalleventset to store the type of rainfall data associated with it
refactor the CalcOptions so they are more like Design constraints...

There is now a CalculationOptions element with an enum for engine type, and based on the engine type will select the appropriate calc options aspect

Thanks for addressing KoQs on various properties of this schema. Since the presentationUnits on the LENGTH_SHORT KoQ (RoadRailUnits schema) are currently wrong (i.e. Meters for SI, Feet-Index for US), do you want to address that in this PR? Or in a separate one?


Color of Japanese text conversion box is invisible

Steps to reproduce

Prepare a flutter project (flutter version 3.7.7)
Run iPad simulator (iOS 17.2)
Enable I/O > Keyboard > Connect Hardware Keyboard
Type some Japanese-kana text and try to convert it to Kanji

Expected results
I would like to know how to customize the text color and background color of the suggestion box.
Actual results
It is hard for users to see which suggestion is selected because the text color and background color of suggestion box are almost the same.
Code sample
Code sample
import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return const MaterialApp(
      title: 'Flutter Demo',
      home: MyHomePage(title: 'Demo Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({super.key, required this.title});

  final String title;

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            TextFormField(),
          ],
        ),
      ),
    );
  }
}

Screenshots or Video

Screenshots / Video demonstration
https://github.com/flutter/flutter/assets/109844522/3414c0da-2e29-49eb-ba12-d540d6d64147

Logs
No response
Flutter Doctor output
Doctor output
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.7.7, on macOS 14.3 23D56 darwin-arm64, locale ja-JP)
[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
[✓] Xcode - develop for iOS and macOS (Xcode 15.1)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2022.1)
[✓] VS Code (version 1.87.2)
[✓] Connected device (3 available)
[✓] HTTP Host Availability

• No issues found!

[✓] Flutter (Channel stable, 3.7.7, on macOS 14.3 23D56 darwin-arm64, locale ja-JP)

I believe this is fixed in a newer version of Flutter. Could you check if this works on the latest stable?

I would like to know how to customize the text color and background color of the suggestion box.

Is this a feature request, or you would like to use the default text color (instead of the white color that made the candidate text invisible) for the currently selected IME candidate?

@LongCatIsLooong

I believe this is fixed in a newer version of Flutter. Could you check if this works on the latest stable?

I confirmed that it works fine on new version of flutter. Thank you 🙇

Is this a feature request, or you would like to use the default text color (instead of the white color that made the candidate text invisible) for the currently selected IME candidate?

It is not a request.
But if there is a way other than upgrading Flutter version, I would like to know it.

Ah I thought you wanted to change the candidate text to use a custom color.  Closing as a duplicate of https://github.com/flutter/flutter/issues/132548


Faust: fix build

Motivation for this change
@doronbehar Changed opencv to opencv2 and that got marked broken.
These commits remove opencv2 where it seems unneeded and changes it back to opencv where it is needed.
@doronbehar You implied you got errors in faust2jack  when using opencv instead of opencv2.
I am not getting any, any idea why?
Are you ok with this change?
Things done

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

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

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

IIRC there were build errors with either opencv 2 or 4. I only wanted the default opencv attribute to be renamed. Feel free to do whatever is needed to get this package working for you.

@doronbehar  OK, thanks!


Missing wave_errno

Various comments in wave.h refer to wave_errno, but no such name appears to be defined.

@gson1703 Please use wave_err instead. Sorry for obsolete docs. I will update the comments when I have time.


Add Tableau Changes

This merge request updates the connector plugin files in the repo with the changes we made when integrating the connector into Tableau. Most of these came up when doing our internal tests, or are best practices that were not properly documented on the SDK.
connectionbuilder.js:
Updated to use connection helper funcitons instead of hardcoded strings.
connectionResolver.tdr:
Added setImpersoanteAttributes and one-time-sql (which allows for initial sql) to the tdr file.
manifest.xml:
Added plugin-version number. (It was originally 1.0, but with the username/password update we're bumping it to 1.1). The version tag is for all Tableau xml file and is always 18.1.
Added en_US resource file:
This is for localization. We wrote new documentation to cover the resource files here: https://tableau.github.io/connector-plugin-sdk/docs/localize.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


No way of checking if ofxArtnetSender/Receiver is actually connected

As of now there is no way of checking if Sender/Receiver is actually connected to the udp endpoint. This makes it impossible to check if one is actually connected before sending data.

Yes this is exactly the interest of Polling the receiver, but it seems that it is not implemented in this git

I think you guys are talking about artpoll message.
It’s not implemented in this version. I don’t think it’s not that complicated though.

+1, I'm also interested in a method to check if the connection has been opened successfully

I found this from a friend of mine,
https://github.com/mattbeghin/Art-Ext-Poll
and
https://github.com/OpenLightingProject/artnet-examples/blob/master/src/artnet-test-master.c
but i don't have sufficient knowledge in C to make a good (coded well) implementation alone.
Somebody would be interested to implement it ?

if you can wait some time, I will try it later. maybe in next month.
in case you can not wait, i think you can write your own code using ofxNetwork.
The basic infomation is here.

Ok , i'll try. I can do it, it will just be quite dirty. If somebody can later clean the code... :)
I'll try to implement it in october.
thks


Edge case fix for prerender errors

This adds error and node_modules lookup handling to prerender exception hook.  As it turns out, #310 was actually a legit error: @vimeo/player and headroom.js both try to access window.xx on import, so they can't be imported in an SSR context at all.  That was all going as planned, but the nice error handler we have for SSR was bailing because it generated an incorrect sourcemap filename.  I've added some (possibly non-windows-friendly?) edge case handling to the filename generation, basically implementing rudimentary support for webpack's ~/foo lookup style to point those at node_modules/foo.

Sorry, I looked thru this but forgot to mark Approve  /facepalm


Unable to load custom backends because "enterprise modules are disabled"

Searchguard 6.1.2-20.1
Elasticsearch 6.1.2
JVM 1.8.0_162
1 node cluster
We are getting this error when we load our back-end classes in Searchguard.
[2018-03-16T06:39:23,605][ERROR][c.f.s.a.BackendRegistry  ] Unable to initialize auth domain authentication_aaf due to ElasticsearchException[Can not load 'com.att.searchguard.auth.aaf.AafAuthenticationBackend' because enterprise modules are disabled]
org.elasticsearch.ElasticsearchException: Can not load 'com.att.searchguard.auth.aaf.AafAuthenticationBackend' because enterprise modules are disabled
	at com.floragunn.searchguard.support.ReflectionHelper.instantiateAAA(ReflectionHelper.java:171) ~[search-guard-aaf-6.1.2-20.1.3.jar:?]
	at com.floragunn.searchguard.auth.BackendRegistry.newInstance(BackendRegistry.java:667) ~[search-guard-aaf-6.1.2-20.1.3.jar:?]
	at com.floragunn.searchguard.auth.BackendRegistry.onChange(BackendRegistry.java:229) [search-guard-aaf-6.1.2-20.1.3.jar:?]
	at com.floragunn.searchguard.configuration.IndexBaseConfigurationRepository.notifyAboutChanges(IndexBaseConfigurationRepository.java:361) [search-guard-aaf-6.1.2-20.1.3.jar:?]
	at com.floragunn.searchguard.configuration.IndexBaseConfigurationRepository.reloadConfiguration(IndexBaseConfigurationRepository.java:311) [search-guard-aaf-6.1.2-20.1.3.jar:?]
	at com.floragunn.searchguard.action.configupdate.TransportConfigUpdateAction.nodeOperation(TransportConfigUpdateAction.java:113) [search-guard-aaf-6.1.2-20.1.3.jar:?]
	at com.floragunn.searchguard.action.configupdate.TransportConfigUpdateAction.nodeOperation(TransportConfigUpdateAction.java:47) [search-guard-aaf-6.1.2-20.1.3.jar:?]
	at org.elasticsearch.action.support.nodes.TransportNodesAction.nodeOperation(TransportNodesAction.java:140) [elasticsearch-6.1.2.jar:6.1.2]
	at org.elasticsearch.action.support.nodes.TransportNodesAction$NodeTransportHandler.messageReceived(TransportNodesAction.java:262) [elasticsearch-6.1.2.jar:6.1.2]
	at org.elasticsearch.action.support.nodes.TransportNodesAction$NodeTransportHandler.messageReceived(TransportNodesAction.java:258) [elasticsearch-6.1.2.jar:6.1.2]
	at com.floragunn.searchguard.ssl.transport.SearchGuardSSLRequestHandler.messageReceivedDecorate(SearchGuardSSLRequestHandler.java:170) [search-guard-ssl-6.1.2-25.0.jar:6.1.2-25.0]
	at com.floragunn.searchguard.transport.SearchGuardRequestHandler.messageReceivedDecorate(SearchGuardRequestHandler.java:121) [search-guard-aaf-6.1.2-20.1.3.jar:?]
	at com.floragunn.searchguard.ssl.transport.SearchGuardSSLRequestHandler.messageReceived(SearchGuardSSLRequestHandler.java:92) [search-guard-ssl-6.1.2-25.0.jar:6.1.2-25.0]
	at com.floragunn.searchguard.SearchGuardPlugin$6$1.messageReceived(SearchGuardPlugin.java:525) [search-guard-aaf-6.1.2-20.1.3.jar:?]
	at org.elasticsearch.transport.RequestHandlerRegistry.processMessageReceived(RequestHandlerRegistry.java:66) [elasticsearch-6.1.2.jar:6.1.2]
	at org.elasticsearch.transport.TransportService$7.doRun(TransportService.java:652) [elasticsearch-6.1.2.jar:6.1.2]
	at org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingAbstractRunnable.doRun(ThreadContext.java:637) [elasticsearch-6.1.2.jar:6.1.2]
	at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37) [elasticsearch-6.1.2.jar:6.1.2]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_162]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_162]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_162]

Enterprise modules are disabled because we do not use them - we only use the opensource modules and the modules we have developed ourselves.
This has been working with previous searchguard releases (5.6.0 is our last working version)
This is preventing us from using Searchguard in our deployments

The custom modules in SG 5.x were never a officially documented and supported interface/functionality.
For SG 6 we decided to make this officially supported (and stable) but its now a enterprise feature which requires a license.
For details pls. refer to

https://docs.search-guard.com/latest/custom-authentication-modules#custom-authentication-modules
https://github.com/floragunncom/search-guard/blob/master/src/main/java/com/floragunn/searchguard/auth/HTTPAuthenticator.java#L42
https://github.com/floragunncom/search-guard/blob/master/src/main/java/com/floragunn/searchguard/auth/AuthenticationBackend.java#L40


Add types for TypeScript

Feature Proposal
Add types declaration for this library :
@types/csv-parser
or add
index.d.ts
Feature Use Case
As a csv-parser integrator, I can have types linked to help me and allow typescript to check if I integrate it well.
thanks

Would be happy to accept a PR that adds types.

Resolved in #104


Add a reminder script

hubot remind me in 1 minute to open a pull request

Cool idea. You should use Robot.Brain to persist reminders across hubot restarts.

I thought about that but couldn't think of a way to persist msg.send, any suggestions?

Reminders now persist :)

+10, I was going to write something like this today


Consider returning deployment details from deploy mutations

There are currently 4 separate mutations to trigger an actual deployment with the lagoon api:

deployEnvironmentPullrequest: String
deployEnvironmentBranch: String
deployEnvironmentLatest: String
deployEnvironmentPromote: String

There's also addDeployment: Deployment but it doesn't work the same way as these others, it just adds the deployment record without triggering the action (maybe this is an issue with my environment?) so we will ignore it for now.
On success these 4 mutations all return the string "success", so there's no real way to determine which deployment has been added by your mutation, only that a deployment has been added. It's possible to hook into the broker to see status changes and assume which one is which but there's no real guarantee the deploy you see in the queue is the same one you triggered through a mutation.
There are three ways I can see to make it possible to track this:

Change the output to be a Deployment type instead of "success".
Change the output to be generic but include a deployment ID or name.
Allow the passthrough of some sort of state. EG let me pass something like deploymentReferenceId when creating the deployment and query it later (or see it as part of the broker update queue)

It's likely the third one would be the only one that'd maintain backward compatibility for what that's worth.

You're correct that addDeployment doesn't trigger a deployment, it's just a database insert.
With Lagoon 2 we have control over the entire deployment, so it could be possible to add some passthrough data, we just need to be able to store it in the Lagoon api and the kubernetes deployment(?) resource.
Some background on why we can't currently return deployment info for anyone who works on this issue:
It used to be the only way you could trigger a deployment was to commit and push which would trigger a webhook from github OR to use a separate REST api. In #838 we copied all the REST endpoints into graphql so that we could deploy from the new Lagoon UI. In order to not break too badly external code that was using the REST api we did a straight copy of the interface and used the same underlying system of deployments. The methods works by creating a task (internal task, not a lagoon environment task) in a rabbitmq which eventually would get picked up by the deployment system at which point it would add all the relevant info to the api (via addDeployment). The other major blocker is that openshift used to control the deployment system, so we had no info on what the deployment data would be until openshift actually started the deployment.
With Lagoon 2 we use an entirely different deployment workflow and I think it would be possible for us to invert the process and add a deployment to the api first, then have it get picked up by the deployment system. Like you said, this would be a big BC break though.

FYI - we're currently working on an additional :scream: kind of deployment (bulk triggered) - that will define the ID on the trigger and pass it to the deployment, which can then follow the deployment through the process - we should be able to roll this out to more deployment types to allow for easier retrieval.


BUG: Series.align resets name when fill_value is specified

import pandas.util.testing as tm

ts = tm.makeTimeSeries()
ts.name = 'ts'
a, b = ts[2:], ts[:5]

# OK (names are preserved)
aa, ba = a.align(b)
aa.name
# ts
ba.name
# ts

# NG, specifying fill_value resets names
aa, ba = a.align(b, fill_value=-1)
aa.name
# None
ba.name
# None

@jreback Could you review this?

lgtm

Thanks!


Add More Questions

There should be one thousand questions

ok there aren't 1000 but there's more


IE fix for xml parsing

Hey @vrajroham
I've taken a look into the IE11 parsing issue in #325 although I don't have a good way to test it, are you able to test for me or flick me an email with some details as to how to?
Cheers

Hey @rowanwins,
Sorry ☹  I'm getting back very late. I'll need an internet explorer to test this 🤣. I'll review this soon.


[KYUUBI #544] Combine deregister exception messages and stacktraces

Why are the changes needed?

To simplify the usage and be more user friendly, combine kyuubi.engine.deregister.exception.messages and kyuubi.engine.deregister.exception.stacktraces to kyuubi.engine.deregister.exception.messages.
How was this patch tested?
Existing UT.

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[x] Run test locally before make a pull request

thanks, merged to master for v1.2.0


Allow returning bytes in MSB order

Currently (at least on my platform, ARMv7), bytes are returned in LSB order but my driver requires them to be MSB. How tricky would it be to add a configuration option for this?
Example:
#[bitfield]
pub struct MyBitfield {
  foo: B16,
}

let test = MyBitfield::new().with_foo(0x1234u16);

test.as_bytes() returns [0x34, 0x12] but I need it to be [0x12, 0x34]. While I could reverse the order of the result from as_bytes, it is error-prone and would IMO be better captured by the bitfield itself.

I agree that functionality like this would be nice in #[bitfield]. Until then you should be able to wrap your bitfield with a new type that does exactly this conversion that you have already described.

I might be able to contribute this, what would be your suggested API for it?

Tough question. I haven't made up too many thoughts about it, yet but I always try to keep the API simple and contained and if it is not possible to keep it as such with the addition of a new feature I mostly think that it is some way to measure that a feature does not naturally belong in there.
That's to say that there are some options forward of which I am not sure if I like them:

Introduce endian specifier, e.g.: #[bitfield(endian = "big")] that would entirely change how your internal bitfield works and it layed out.
Generate into_bytes_{le,be} and from_bytes_{le,be} methods very similar to the currently already generated from_bytes and into_bytes methods. This approach is more lightweight, yet introduces some complexity that should imo not be inherent to this crate and therefore bitfield types. Bitfield types according to the current spec are always internally layed out as little-endian, so having APIs for both does not feel natural for me.
??

Thanks, 1 would work for my use cases and I can't come up with one where the same register needs to be sent both MSB and LSB (but it is certainly possible that someone else can). I don't think we can easily store e.g. integers as MSB if the platform is little endian, because each setter call would come with a non-trivial conversion cost.
Actually, what is the current memory layout on big endian platforms? I assume integers are stored MSB then? What about the result of into_bytes?
Are there any performance implications (memory) to this choice, as in: are there situations where the current implementation can optimize away the copy into a byte buffer?

Hm, if I may put my two cents. My intuition leans towards option 2, both because e.g. u32 has to_be_bytes and to_le_bytes, and also because it doesn't force the person making the #[bitfield] to decide between one or the other until they actually need it.
In particular, I'm working on a program which generates Rust-friendly wrappers around register maps, so my code is generating #[bitfield]s, but I don't know how the user ultimately interacts with their devices (whether they want it in LE or BE). (in practice, because of the way I'm doing things, I end up forcing u32 numbers on the user, but they could use the bitfield structs directly and I don't know whether they would want LE or BE or both if they did)
I can't think of a third option though, sadly.

Actually, what is the current memory layout on big endian platforms? I assume integers are stored MSB then? What about the result of into_bytes?

It is always stored as little-endian at the moment. Even with #[repr(uN)] we still store it as byte array which is kind of lying to the user in some way. However, if you provide #[repr(C)] (which you should do anyways in those cases) then it is basically the same as long as you do not unsafely transmute but use the generated From impls.

Are there any performance implications (memory) to this choice, as in: are there situations where the current implementation can optimize away the copy into a byte buffer?

I think this is where we should put the focus. Do we actually need this additional complexity or will the compiler take care of it anyways? I actually believe the compiler will optimize all these conversion down to the bare minimum needed as compilers nowadays are brilliant when it comes to bit twiddling tricks.

Hm, if I may put my two cents. My intuition leans towards option 2, both because e.g. u32 has to_be_bytes and to_le_bytes, and also because it doesn't force the person making the #[bitfield] to decide between one or the other until they actually need it.

Thank you very much for putting in your use case! This basically disqualifies option 1 in my opinion.

I can't think of a third option though, sadly.

I think the third option is to create some proper benchmarks using criterion and check whether there are some performance implications by not introducing this feature to big-endian systems and if there are none we can simply close this issue. If the benchmarks show that the non-existence of such a feature has performance implications to those systems we should find a solution.

Actually, what is the current memory layout on big endian platforms?

It is always stored as little-endian at the moment. Even with #[repr(uN)] we still store it as a byte array which is kind of lying to the user in some way.

My 2¢: in my opinion this is also deserving of attention, because I think and being able to transmute() to and from bitfield structs is valuable (even if those structs have to be tagged with specific #[repr()] attributes), and I think the memory layout matching the bitfield declaration is one of the strengths of this crate.

My 2¢: in my opinion this is also deserving of attention, because I think and being able to transmute() to and from bitfield structs is valuable (even if those structs have to be tagged with specific #[repr()] attributes), and I think the memory layout matching the bitfield declaration is one of the strengths of this crate.

Can you please elaborate why transmuting between bitfield structs and their underlying representation is important? In little-endian systems the From impl is already a no-op and I can imagine that even for big-endian systems the compiler optimizer can do an amazing job as well. So no unsafe transmute is needed from this perspective but please tell me if I am missing something!
So in conclusion I think we really should have some benchmarks to measure this impact before we further complicate the API of bitfields in this crate. I am willing to implement this (or be implemented by you) if it turns out to be useful.

Hm. I didn't realize the From impl was a no-op for little-endian systems. Still, I am imagining a situation where you have a section in memory that you do not directly control (like hardware), but you can have a pointer to it, and thus you can transmute the pointer to a pointer to a bitfield struct.

Hm. I didn't realize the From impl was a no-op for little-endian systems. Still, I am imagining a situation where you have a section in memory that you do not directly control (like hardware), but you can have a pointer to it, and thus you can transmute the pointer to a pointer to a bitfield struct.

But why would you do that if you could as well just read out the bitfield behind the pointer and use the (mostly) no-op From impl? This way you can stay in safe Rust and do not risk undefined behavior induced by using unsafe Rust transmute.

Hm, I think I see the use case (correct me if I'm wrong)... imagine it's some HW register somewhere, you could:
#[bitfield]
struct WwdtTimeReg {
   count: B24;
   reserved: B8;
};

let reg = 0x4000_000c as *WwdtTimeReg;
let reg: &WwdtTimeReg = reg.as_ref().unwrap();
...
let current_count = reg.count();

vs. having to do a two-step process:
let reg = 0x4000_000c as *u32;
...
let register_value = WwdtTimeReg::from_le_bytes(*reg); // Sorry I forget the exact syntax right now
let current_count = register_value.count();

It'd prevent you from being able to atomically set/get all fields simultaneously, but that may be fine. In this case there's only one interesting field anyway.

Just to summarize here, if we do these changes:

Rename into_bytes and from_bytes to into_le_bytes and from_le_bytes
Introduce new functions into_be_bytes and from_be_bytes

This should not have any performance implications, as it is essentially just a rename for existing use cases.
I think allowing the user to additionally specify the memory layout of bitfield could probably be a FR on its own, as it would just determine whether into_le_bytes or into_be_bytes is the faster operation.

Yeah, in the meanwhile, I have even worked with protocols which use mixed LSB/MSB encoding (yes, i am talking to you, IEEE 802.15.4).
Probably the proper way is to introduce LE16 and BE16 types in place of B16 so that the endianness can be specified on a field by field basis. This gets very close to the zerocopy crate, but that one doesn't have bitfield support (which is kind of the selling point of this library), so I don't see a conflict here. We would need to define what the odd types (e.g. B15) means for the two variants. For example:
#[bitfield]
pub struct MyBitfield {
  foo: B15,
  bar: B1,
}

How does the memory layout when foo is stored as LE differ from the layout when foo is stored BE? What does it even mean to define endianness for a 15 bits? Maybe we should just not support this for non-even fields (i.e. LE16 but no LE15)?

I'm interested in this feature as well.  Getting bitfields and endianness to work correctly is very tricky and needs a library solution.
From my experience, the only way to handle this situation is to carefully define a bitfield layout in a way that's independent of endianness.  You do this by defining it in terms of the underlying representation.  So taking the example from the previous comment and using #[repr(u16)], it has the following layout:
 1  1
 5  4                    0
--------------------------
|B1|        B2           |
--------------------------

Notice that this layout works regardless of the machine endianness: within the 16 bits of a u16, the MSB is B1 and everything else is B2.  No bytes are mentioned in this definition.
(Note, however, that the order of the fields within this representation is completely ambiguous.  B1 could be the LSB, for example.  In fact, GCC actually reverses the field layout based on endianness.  This is a mistake IMO, and should not be repeated by this library.  Pick one order, document it, and stick to that.  Backwards compatibility will likely determine your choice.)
As a separate step, you define the byte order when this representation needs to be viewed as bytes.  There are three options: host endian, little endian, and big endian.  The representation in memory should always be in the host endianness (so the underlying u16 is just that), with options to read and write it explicitly in either big or little endian.  In the end, that means providing from_le_bytes and from_be_bytes.  Also, don't forget from_ne_bytes for native endianness (like Rust does with primitive types, which is guaranteed to be fast).  I'd also suggest renaming to to_{le,be,ne}_bytes for consistency with std.
The above solution works with every interface I've worked with and layout I've seen from a C or C++ compiler.  It's also compatible with how people do bitfields manually (bit shifts on integer values).  (With the possible exception of mixed endianness mentioned above, though to be honest I don't even know what that really means in this context.  Regardless, I think it's rare enough to ignore from a library perspective.)
This interpretation apparently departs from the current implementation, which uses byte arrays under the hood.  To be frank, I think that's a dubious implementation to begin with.  However, it does allow for space optimization when the number of bits is something like 24 bits instead of 32, and it allows for very large bitfields.  I'm not sure the advantages are significant (you can break up a bitfield if needed and the space overhead is likely minimal).  As a compromise if that's still desired, I suggest using a byte array when a representation isn't provided, but consider not providing a way to access the bytes.

In summary, I recommend doing the following:

Under the hood, store the data using the provided representation rather than a byte array.  If none is provided, choose the next larger unsigned integer.  Limit bitfields to 128 bits.

Alternatively, use a byte array by default, but with no access to the array or access but with no guarantees about layout.

Remove into_bytes and from_bytes
Provide in_le_bytes, in_be_bytes, in_ne_bytes, from_le_bytes, from_be_bytes, and from_ne_bytes.  These should basically just be calls to the equivalent function provided by the underlying type.

With the possible exception of mixed endianness mentioned above, though to be honest I don't even know what that really means in this context. Regardless, I think it's rare enough to ignore from a library perspective.

Mixed endianness means the following:
#[bitfield]
pub struct MyBitfield {
  foo: LE<U16>, // Little endian u16
  bar: BE<U16>, // Big endian u16
}

let s = MyBitfield {
  foo: 0x1234.into(),
  bar: 0x5678.into(),
};

s.into_bytes()

should produce [0x34, 0x12, 0x56, 0x78]. How the struct is stored in memory is an implementation detail which I care less about (most likely using the host native representation makes most sense there).

How common is mixed endianess in structs that could profit from modular_bitfield supporting field-wise endianess?
I have the impression it is a niche feature and very much like the idea for a struct-wise endianess, e.g. stating at the top if all fields should be serialized and deserialized as big- or little- endian. Then later if that one works we could refine this feature to also work field-wise if there is greater need for this.
Until then users are totally free to define custom bitfield structs to be used in #[bitfields] structs as with the proposed LE and BE types. It should be easy to add some conversion methods to those.

Yeah, if you can specify endianness on the struct level and it is supported to mix struct fields of different endianness in a bitfield struct, then I am happy (I would just wrap foo and bar into structs in my example above and call it a day).
For me to understand correctly, the current standing proposal is to add an endianess parameter to the #[bitfield] macro, which controls the endianess of all (non-struct) fields?

For me to understand correctly, the current standing proposal is to add an endianess parameter to the #[bitfield] macro, which controls the endianess of all (non-struct) fields?

There have already been many proposals in this thread but this one I consider to be implementable without the need of having way too many design discussions about potential pitfalls.

@henrikssn
That makes sense when it comes to fields that are byte-aligned ... but what if you have something like this?
struct BitAlignedMixedEndian(LE<U4>, LE<U16>, BE<U16>, LE<28>);
Which bits of which bytes does each field come from?
@Robbepop
128 bits is only a limitation if the intention is to put everything inside a single bitfield, even things that don't have bitwise alignment requirements.  Which, I will admit, is very tempting to do and simulates what other languages (C, C++, Ada) that have native bitfields provide.
  Even aligned fields could require unaligned reads (unless you're aligning the byte array?) which can have significant performance impacts, you're forcing everything to go through getters and setters (also unfortunate for other reasons, a topic for a different day), etc.  (On the plus side, the interface doesn't allow forming a pointer to a field so you can't fall into that particular undefined behavior trap).
It takes a bit more work and has indirection to get at the fields you want, but I think it's overall better to see this as a member of a larger structure.  Something like this, for example:
#[bitfield]
#[repr(u16)]
pub struct MyBits {
    a: B3,
    b: B13,
}

pub struct MyData {
    c: u16,
    d: MyBits,
    e: u32,
}

(It's slightly unfortunate that Rust doesn't have nested anonymous structures like C, which makes this a bit less messy.)
From here, we can use something like the BinRead crate to handle the I/O.  If we assume from_be_bytes() is provided to read from a byte array as big endian:
#[derive(BinRead)]
#[br(big)]
pub struct MyData {
    c: u16,
    #[br(map = MyBits::from_be_bytes)] // BinRead uses from_be_bytes to populate the data in d
    d: MyBits,
    e: u32,
}

(Incidentally, you can also solve byte-aligned mixed endianness this way since BinRead can apply different endianness to individual fields).
We're actually tantalizingly close to this already, come to think of it.  Just change it to:
#[br(map = |x|MyBits::from(u16::from_be_bytes(x)))]
This workaround seems to do the right thing from my testing, but I haven't tried doing the reverse on a big-endian machine (and I wonder if this library is broken on big endian anyway...).
Anyway, this is why I'm suggesting from_be_bytes() instead of a parameter to #[bitfield].  It should be dead simple to implement since the infrastructure is already there.  The same bitfield can be serialized in either endianness, too, which is a nice bonus.

I originally used the suggestion of creating a LE<U16> and BE<U16> types, but I had the need to define multiple enums that were backed by big endian ints, and defining into_bytes/from_bytes on a number of enums seemed a lot of toil.
I considered the from_be_bytes approach, but it's unclear if folks actually needed to sometimes read their struct as LE and other times as BE, and it seems to be making decisions at runtime instead of generating the code once.
As a proof of concept, that allows setting #[endian = "big"] on BitfieldSpecifier structs, e.g:
#[derive(BitfieldSpecifier)]
#[bits = 16]
#[endian = "big"]
pub enum QClass {
    Reserved = 0,   // [RFC6895]
    Internet = 1,   // [RFC1035]
    // ...
}

The changes to the procedure macros seem simple enough, and this seems flexible to mix and match endian in a struct, but to otherwise be opinionated about the endian of the struct, without changing the API.
I plan to support
 `endian = "host"`   // the default and today's behaviour
 `endian = "big"`    // Big endian
 `endian = "little"` // Little endian

I'm happy to extend the bitfield to support endian at the struct level, and the per field level. That seems a simple enough API, is backwards compatible, and will no doubt solve 90% of cases. If you need something more custom, it is easy enough to implement modular_bitfield::Specifier to do that.

Hi all. I also needed a way to represent big endian byte orders for a network protocol.
While @CirrusNeptune s fork (https://github.com/CirrusNeptune/modular-bitfield-msb) work well for me, I decided to continue on the POC from @bramp. You can check it out here: https://github.com/vhdirk/modular-bitfield/tree/endian
I've modified the original POC by creating an enum for specifying the byte order, and also supporting structs. The only thing I have left to do is to add support for little-endian orders for B2 - B128. Any suggestions how you may want that to work?

@vhdirk I would vary the order of the bytes which are being written out for types which are crossing the byte boundary. This means that aligned even bytes like B16 get the same representation as u16. The drawback is that it takes a bit of time to wrap your head around it. Take the following example:
#[bitfield]
#[endian(Little)]
struct example {
  // First two bytes
  foo: U15,
  bit_one: bool,
  // Third byte is always unaffected by endianness
  bit_two: bool,
  bar: U7,
}

// In serialized format:
// [foo(lsb)] [foo(msb) bit_one] [bit_two bar]
// with big endian:
// [foo(msb)] [foo(lsb) bit_one] [bit_two bar]

I've been trying something like that, but I'm afraid it is still buggy. I'll make a PR soon so that you can comment on it.
Basically, you can also set the endian flag on each individual field. If it's not specified, it derives the byte order from the struct it's in.
#[bitfield(endian = "big"]
struct Example {
  // First two bytes
  foo: B15,
  bit_one: bool,
  // Third byte is always unaffected by endianness
  bit_two: bool,

  #[endian = "little"]
  bar: B15,
}

This would yield
// [foo(msb)] [foo(lsb) bit_one] [bit_two bar (lsb)] [bar(msb)]

I'm quite sure my implementation is not quite correct stil, and the're some conflicts in specifications as well:
#[bitfield(endian = "little", bits = 2]
struct Inner {
  bit_one: bool,
  bit_two: bool,
}

#[bitfield(endian = "big"]
struct Example {

  foo: B6

  #[endian = "little"]
  inner: Inner
}

What would be the byte order of inner here?

I don't think a boolean should be affected by endianness. Additionally, the serialization of your example should be unaffected by endianness, since it is just one byte long.
Even if foo was spanning multiple bytes, I expect Inner to come after foo and the order of the fields in Inner should be respected.
I would advise to wait with supporting specifying endianness on nested structs, since it makes the proposal a lot more complex with more edge cases to consider.

The order of the boolean in Inner definitely does matter. It's exactly why I need this.
You're right that alternating endianness is a mess, but I don't think it should necessarily be that hard. The range of the bits to write into is specified by the container; how it is filled exactly is the responsibility of the field.
At least that's how I understand this crate.

In my case (assembler instructions), handling endianness of structs and fields is essential.
What is endianness?
Basically, it is the order of whatever unit of data you are refering to... which is not part of the definition.
The unit of data can be a bit, u8, u16, u32, u64, u128, or even exotic stuff like 5 bits (spr field of PowerPC, to retain compatibility with the POWER architecture).
Endianess can be different for each unit of data.
Rust only handles endianness at the byte level (le and be), which is fine because the minimum alignment of struct fields is 1 byte.
Endianness of a #[bitfield] struct
In this crate the alignment of struct fields is 1 bit, so it should view structs from a bit perspective. The internal representation can be anything, but the transition of into_bytes, from_bytes, and From has to respect the intended endianess.
As reference... maybe check how C bitfields are layed out in little endian and big endian systems? Maybe the modular-bitfield-msb crate already matches big endian systems?
Struct VS Field
The endianness of a field only means something after defining the endianness of the #[bitfield] struct.
A le field in a be struct and a be field in a le struct needs to have the order of the units of data reversed.
A le field in a le struct and a be field in a be struct is already fine.
Instead of defining the endianess of a field, it is more appropriate to define what units of data are reversed and in what order.
Proposal
Example:
use modular_bitfield::prelude::*;

#[bitfield(order = Msb)]
pub struct MsbStruct {
    msb_field: B24,
    lsb_field: ReverseBytes<B24>, // TODO should bits be reversed?
    signed_field: Signed<B6>,
    weird_field: Reverse5Bits<B10>,
    wtf_field: CustomSpecifier<ReverseBytes<ReverseBits<32>>>,
}

If you can have a Specifier that calls another Specifier in chain then you can implement any kind of weird or composite "endianness" in fields.
If it's possible, also allow custom orders #[bitfield(order = ::path::to::CustomOrder<Msb>)].
Not sure how it would interact with #[derive(BitfieldSpecifier)].
I already tried to implement something like Signed but failed at generics, so instead I implemented I1 to I128 with a macro and 128 macro invocations... :/


Support Azure DevOps

This change has been borne of customer requirements, they have an existing investment in ADO and do not wish to migrate to GH Enterprise.
@liamfoneill and I have jointly worked on this capability.
This PR should be considered in conjunction with the corresponding change to the AzOps repo: https://github.com/Azure/AzOps/pull/19
Change summary:

Docs Add documentation for Azure DevOps

Pipeline Add pipeline for Azure DevOps

ADO Implementation
The ADO pipeline works by pulling the AzOps Docker image from a registry. Additional environment variables are used to pass in required information and to make the container function in ADO.
We know ADO is not the priority at the moment, but we are in the situation where we have to support our customer. Keeping this ADO solution in sync with the upstream repo will be very time consuming and this PR means we don't have to be refreshing our code to keep up to date.
Conversely, we believe that this does not introduce significant ongoing maintenance work for the maintainers of this repo.

As much as I see the alignment with the DevOps strategy going forward, ADO is still what customers have mostly running so far.
Keen to see both supported for this great initiative.
Cheers
Manu


[TOAZ-129] A few more fixes prior to B2C enablement in dev

https://broadworkbench.atlassian.net/browse/TOAZ-129

Fix billing scope elevation for the B2C case. No change in behavior for the Google case.

For now Azure logins through B2C don't have a profile picture, so don't render a broken link. There's a ticket to address this better.

Make Terra UI source the oidcClientId from the backend (Orch), and move it out of UI config. We were already using the backend to redirect to the appropriate authority endpoint (see context here). This put us in an awkward situation where it would have required a coupled UI+backend release to update the client+authority. Now, B2C vs Google is fully controlled in backend conf.

Still reviewing, but the first thing that I noticed is a behavior that looks like it predates this PR that might have been introduced with the B2C support. In the window that opens to sign in to Google, after signing in (or selecting a signed-in account), I see Terra UI start to load in that window before it closes! I'm not 100% sure that this didn't happen before, but I don't remember it. The consequence is unnecessary network traffic and, depending on timing, even recording usage events in Mixpanel.
I think we should find a way to avoid this, especially if we can confirm that it didn't happen pre-B2C.

@breilly2 yeah Christina and I noticed that earlier. The signin pop-up redirects to ${window.origin}/#redirect-from-oauth, which renders a spinner and calls the callback to close the popup (see it in action here). However Loading Terra.. flickers before the spinner is rendered, I think from here.
I'm not certain how to avoid this -- the popup redirect needs to render to complete the auth flow. Is it possible to have a Terra UI route which doesn't display Loading Terra..?

FWIW, in TDR I made a route just for that redirect that just shows a spinner (and doesn't trigger fetches)

Yeah, now thinking I could have some logic in index.js to avoid fetches for that route. Will try it out..

@breilly2 I tried a thing. Now the /redirect-from-oauth route doesn't render the full app or make any backend calls -- it just renders the single component it needs to complete the oauth callback. I still see Loading Terra… flicker (while some assets are loaded) but it's much less than before. Let me know what you think :)

I'm actually going to close this because the thing it depends on was reverted. Will re-open when ready.


for extract attention --word_level attention doesnt work

I have used preprocess_unlabelled to create my json file. Can you provide a preprocess file which would help word level attention.
When I use this file and when I pass the argument --word_level to extract_attention I get the following error:
Converting to word-level attention...
Traceback (most recent call last):
File "extract_attention.py", line 144, in
main()
File "extract_attention.py", line 134, in main
feature_dicts_with_attn, tokenizer, args.cased)
File "/home/manasi/Documents/BERT/attention-analysis-master/bpe_utils.py", line 74, in make_attn_word_level
words_to_tokens = tokenize_and_align(tokenizer, features["words"], cased)
KeyError: 'words'
Please help me fix it.

As the README says, you need to supply "words" as opposed to "text" or "tokens" in the data json to get word-level attention.

@clarkkev
Should I supply "words" by additional code? I did not see code doing this in preprocess_unlabelled.py.
Thanks!


Add check if the user exists for the various user admin commands

I believe I caught all the cases here


Cylinder and capsule sinking through plane

Environment

OS Version: macOS Sonoma 14.5
Source build: gz-physics7 (a068d3f7)

Description

Expected behavior: the cylinder and capsule should not pass through the ground plane.
Actual behavior: the cylinder and capsule slowly sink.

Steps to reproduce

run gz sim -v4 -s -r shapes.sdf and gz sim -v4 -g (two commands on macOS).
use the rotation tool to tip the cylinder and capsule to the side.
raise both objects to ensure there is no initial intersection.

Output

I'm able to reproduce this on the Capule but not the cylinder on Ubuntu. For the capsule shape, I filed an issue on DART a while ago (https://github.com/dartsim/dart/issues/1654), but there hasn't been any update.


Home button added

🛠 Fixes Issue

Closes #109
👨💻 Changes proposed

Added Home button inside NavBar.
✔ Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[x] This PR does not contain plagiarized content.
[x] The title of my pull request is a short description of the requested changes.

📄 Note to reviewers

📷 Screenshots

@Siddhesh777 hi siddesh
This pr has some merge conflicts

hey @KaizenGirl1111
Conflicts resolved.


Added check for the correct content type in addition to the response status code.

I recently experienced an issue where the CA functionality was broken because Mozilla has a maintenance page up for the CA link in the code (https://mxr.mozilla.org/nss/source/lib/ckfw/builtins/certdata.txt?raw=1) and unfortunately that maintenance page returns a 200 status. That means the HTML page was being downloaded as the CA, which didn't exactly work super well.
My change adds an additional check for the content type to be text/plain in addition to the status code check.

I added you to the repo. Merge and test and let me know when to pull and republish.
I can add you to npm so you can publish yourself if you give me your npm username.

Thanks for the merge. Sorry I didn't get to it when you first added me, but I've been away a bit and just now circling back.


Fix issues with newer versions of bson and chrono

I have Cargo.toml
[dependencies]
serde="1.0.2"
serde_derive="*"
bincode="*"
redis = "*"
cdrs = "1.0.0-rc.1"
bson = "0.7.0"
mongodb = "0.2.7"

Compiling mongodb v0.2.8
error[E0308]: mismatched types
   --> /home/trionprog/.cargo/registry/src/github.com-1ecc6299db9ec823/mongodb-0.2.8/src/gridfs/file.rs:592:37
    |
592 |             file.upload_date = Some(*datetime);
    |                                     ^^^^^^^^^ expected struct `chrono::DateTime`, found struct `chrono::datetime::DateTime`
    |
    = note: expected type `chrono::DateTime<chrono::UTC>`
               found type `chrono::datetime::DateTime<chrono::offset::utc::UTC>`
    = help: here are some functions which might fulfill your needs:
            - .timezone()

error[E0277]: the trait bound `bson::Bson: std::convert::From<chrono::DateTime<chrono::UTC>>` is not satisfied
   --> /home/trionprog/.cargo/registry/src/github.com-1ecc6299db9ec823/mongodb-0.2.8/src/gridfs/file.rs:616:23
    |
616 |           let mut doc = doc! {
    |  _______________________^ starting here...
617 | |             "_id" => (self.id.clone()),
618 | |             "chunkSize" => (self.chunk_size),
619 | |             "length" => (self.len),
620 | |             "md5" => (self.md5.to_owned()),
621 | |             "uploadDate" => (self.upload_date.as_ref().unwrap().clone())
622 | |         };
    | |_________^ ...ending here: the trait `std::convert::From<chrono::DateTime<chrono::UTC>>` is not implemented for `bson::Bson`
    |
    = help: the following implementations were found:
              <bson::Bson as std::convert::From<f32>>
              <bson::Bson as std::convert::From<f64>>
              <bson::Bson as std::convert::From<&'a str>>
              <bson::Bson as std::convert::From<std::string::String>>
            and 16 others
    = note: required by `std::convert::From::from`
    = note: this error originates in a macro outside of the current crate

error[E0308]: mismatched types
   --> /home/trionprog/.cargo/registry/src/github.com-1ecc6299db9ec823/mongodb-0.2.8/src/topology/monitor.rs:125:38
    |
125 |             result.local_time = Some(*datetime);
    |                                      ^^^^^^^^^ expected struct `chrono::DateTime`, found struct `chrono::datetime::DateTime`
    |
    = note: expected type `chrono::DateTime<chrono::UTC>`
               found type `chrono::datetime::DateTime<chrono::offset::utc::UTC>`
    = help: here are some functions which might fulfill your needs:
            - .timezone()

I've edited my Cargo.toml
[dependencies]
serde="1.0.2"
serde_derive="*"
bincode="*"
redis = "*"
cdrs = "1.0.0-rc.1"
bson = ">=0.7.0,<0.7.1" #to use 0.7.0
mongodb = ">=0.2.7,<0.2.8" #to use 0.2.7

But then =(
error: failed to select a version for `bson` (required by `mongodb`):
all possible versions conflict with previously selected versions of `bson`
  version 0.7.0 in use by bson v0.7.0
  possible versions to select: 0.7.1

Confirm

Thanks for the report! I just updated the dependencies and pushed to master. Assuming it passes the CI, I'll push a new version to crates.io.

Just published 0.2.9. Thanks again for reporting the issue!


HSEARCH-2654 Upgrade Elasticsearch RestClient + Sniffer to 5.3.0

https://hibernate.atlassian.net/browse/HSEARCH-2654

merged!


Skype: bug with group chats

Hello,
when you use the Bot in group chats for Skype, the bot can only respond to you if you add a mention:
@SomeBot test_command
But there is a bug with hears method. The regular expression expects a command from the start of the string thanks to ^:
// BotMan.php
$text = '/^'.preg_replace('/\{(\w+?)\}/', '(.*)', $pattern).'$/i';

but when I send a command to bot using mention, the command looks like this:
<at id="28:3176e6ca-8dad-4c6d-97f1-e2a86548acc8">@SomeBot</at> test_command
So regexp does not match and hears does not work, the fallback is used then.
An exception is needed for such case.

Yes, the ms bot framework driver should remove the <at... tag in this case.
Maks Rafalko<EMAIL_ADDRESS>schrieb am Fr. 6. Jan. 2017 um
11:13:

Hello,
when you use the Bot in group chats for Skype, the bot can only respond to
you if you add a mention:
@SomeBot test_command
But there is a bug with hears method. The regular expression expects a
command from the start of the string thanks
https://github.com/mpociot/botman/blob/1.3.0/src/Mpociot/BotMan/BotMan.php#L245
to ^:
// BotMan.php$text = '/^'.preg_replace('/{(\w+?)}/', '(.*)', $pattern).'$/i';
but when I send a command to bot using mention, the command looks like
this:
@SkotBot test_command
So regext does not match and hears does not work, the fallback is used
then.
So we need an exception for such case
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/mpociot/botman/issues/104, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAxHTGuwpCN-isCZJZUPXLdLFiTLRIyhks5rPhN-gaJpZM4Lck-H
.

--
Marcel Pociot
http://www.marcelpociot.com
https://github.com/mpociot
http://twitter.com/marcelpociot

I can send a PR for that, just need time to finish with tests.
Tried with
public function getMessages()
    {
        $message = preg_replace('/<at id=(.*?)at> /', '', $this->event->get('text'));

        return [new Message($message, $this->event->get('from')['id'], $this->event->get('conversation')['id'], $this->payload)];
    }

and it works correctly

A PR with a test case would be great :)
Maks Rafalko<EMAIL_ADDRESS>schrieb am Fr. 6. Jan. 2017 um
11:30:

I can send a PR for that, just need time to finish with tests.
Tried with
public function getMessages()    {        $message = preg_replace('/ /', '', $this->event->get('text'));        return [new Message($message, $this->event->get('from')['id'], $this->event->get('conversation')['id'], $this->payload)];    }
and it works correctly
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mpociot/botman/issues/104#issuecomment-270876029, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAxHTGLq4-vVvYV7O8oX3zPd1MZaH8gWks5rPhfbgaJpZM4Lck-H
.

--
Marcel Pociot
http://www.marcelpociot.com
https://github.com/mpociot
http://twitter.com/marcelpociot


Package description updates

Codecov Report

Merging #268 (b060d8e) into master (5c23a06) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##            master      #268   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           39        39
  Lines          362       362
  Branches        54        54
=========================================
  Hits           362       362

Continue to review full report at Codecov.

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


Project: Discord Community Management Agent (CoMA)

Project Name
Discord Community Agent
Description
Discord Community Management Agent (CoMA)
Discord is home to vibrant technical communities, including Microsoft's AI community, but managing large-scale discussions can be challenging.
The Problems:
Team Matchmaking:
Hackathon and project channels are often flooded with messages, making it hard to find the right people to collaborate with, test your product, or provide mentorship. There’s too much noise and not enough targeted matchmaking.
Getting Help:
While many interesting solutions are shared in help channels for new technology where there are breaking changes everyday, searching through them is keyword-specific and lacks context. It's difficult to identify the niched solution to your niched problems.
The Solution:
Introducing CoMA, a Discord bot designed to streamline community management by processing messages in specific channels.
Enhanced Team Matchmaking:
When users introduce themselves in the matchmaking channel, CoMA reaches out to interviews users through direct messages to gather detailed information, builds rich profiles, and uses these to power advanced search capabilities. This allows users to find teammates, network with others, or connect with potential testers and mentors more effectively.
Enhanced Search for Help:
Important technical context is extracted from a community's ask for help channel, and users can now just search for them with a command, and start a thread to chat about the issue.
Details
Architecture

What data sources did you use?
None, they are built in real time from the users
Did you make additional modifications to the data ingestion or prompting flows?
Yes, there are prompts to extract user data from user chat and technical details from documentation
Who can benefit from your app?
Users of technical communities: No more lost context or frustrating searches through channels. Just ask CoMA, and you’ll be recommended the people you need and the guidance to your problems Especially for builder communities, you can find your collaborators, customers, testers, mentors and network! Networking is powerful!
All technical communities: CoMA can be easily deployed to any existing technical discord community server, just follow the steps in my project's ReadME. Communities become more efficient, engaged, and thriving.
Microsoft AI Discord Server: Would you be down to use this? 🥺
Technology & Languages

[X] JavaScript
[ ] Java
[ ] .NET
[ ] Python
[X] AI Studio
[X] AI Search
[ ] PostgreSQL
[X] Cosmos DB
[ ] Azure SQL

Project Repository URL
https://github.com/KenjiPcx/CoMA-Discord-Community-Management-Agent
Deployed Endpoint URL
https://discord.gg/DGtMcBuq
Project Video
https://www.loom.com/share/1bc330d993434cab8ae9fe9b73f61211?sid=0e4f47bf-f2d4-437e-b9e9-baa37869146b
Team Members
kenjipcx

Deployed Endpoint URL is expired

Oops looks like it's a discord issue, does this link work? https://discord.gg/xvtKzFPJ


Page scroll while moving the mouse

In Ubuntu 14.04，I update my VIM 7.4 to VIM 8.1 and use this ale plugin,
but i found that when i moving the mouse the the screen will auto scrolling up,
i have no idea to solve this problem.

Could you record a video of this happening? This took works very well on Linux: http://www.maartenbaert.be/simplescreenrecorder/ You can upload a video to YouTube.

Thanks.This is my screen video link while happening this problem.video

I can't repeat this bug myself. I don't know what's causing this.

https://github.com/vim/vim/issues/2419 This might be related. Try playing with your ttymouse setting. If the issue goes away after disabling balloons, I'll disable them by default for terminals, because mouse behavior in terminal Vim cannot be relied upon to work properly without some configuration.

mouse is a, ttymouse is xterm2.
The problem goes away if I either:

Set ttymouse to xterm
disable balloons

Okay, I'll disable balloons in ALE by default then, and someone can report a bug in Vim. I don't see why using balloonexpr should ever cause the mouse to scroll up or register different clicks.

Now balloon support is disabled for terminals by default, due to this Vim bug. People who want balloons in terminals can turn them on after they have set up their mouse settings appropriately.

Thanks!It work well when i use let g:ale_set_balloons = 0.


ci: install dev deps when building in pipeline

Yeah, this build in the pipeline is just to verify that it does build. The artifact is not stored and re-used by the production/stage envs.


Support for Homeworks QS Connect Bridge

Since the connect bridge used for homeworks qs uses the same leap protocol. would it possible to add them to the list of supported devices ? it would also open the door for the previous generation of Ketra devices that Homeworks QS supports.

Have you tried the "Lutron" or "homeworks" integrations with the telnet LIP protocol? Not sure if the connect bridge's LEAP is compatible with this library. I have QSX, so not able to test it.

I've tried the lutron connect bridge for homeworks qs and ra2 with pylutron-caseta but they both failed during the pairing process. and seems like that only through the official Lutron app the telnet  service can be enabled on the bridge and only QSX and Caseta system can use this app. Which this in fact corroborates your previous comment... pylutron-caseta won't work!


sorry,I found a small mistake in NavigationManager.cs

var navigation = GestureSettings.NavigationX | GestureSettings.NavigationY | GestureSettings.NavigationRailsZ;
Maybe the last one  should be GestureSettings.NavigationZ.

@zwxbest Thanks!


Windows jobs intermittently freeze at git clean stage

and have to be manually aborted
see e.g. https://scala-ci.typesafe.com/job/scala-2.11.x-release-package-windows/286/console
or https://scala-ci.typesafe.com/job/scala-2.12.x-release-package-windows/146/console

In principle, this was fixed by #132, but somehow the git config command did not result in a core.longpaths=true in gitconfig. For now, I manually ssh'ed and set the config option for both --global and --local (as user jenkins)

TODO: why does the chef solution not work?
bash 'git config' do
  interpreter cygbash
  # without longpaths enabled we have:
  # - known problems with `git clean -fdx` failing
  # - suspected problems with intermittent build failures due to
  #   very long paths to some classfiles
  code "git config --global core.longpaths true"
end

I haven't seen this in months, optimistically closing


optimize webpack development compile time

Check also this https://github.com/webpack/webpack-dev-server/issues/1503
NOTE: Code splitting and hot realoading in issue #34.

Everything ok already? Material-UI with typescript is still slow?


Unable to parse VideoChannel due to mismatched schema with holodex

Problem
The issue originated from these deserializers defined in ChannelStats where the fields video_count, subscriber_count, and view_count are set to deserialize with DisplayFromStr which tells serde to expect a string that represents a number instead of actual number type.
(green is the format ChannelStats expects, and red is the format Holodex API returned)
   {
         ...
+        "video_count": "141",
-        "video_count": 141,
+        "subscriber_count": "693000",
-        "subscriber_count": 693000,
+        "view_count": "61862973",
-        "view_count": 61862973,
         "clip_count": 1009,
         ...
   }

https://github.com/anden3/holodex-rs/blob/e16ce3ac79e172fdcae75b6501147495218c1cc7/src/model.rs#L986-L997
Reproduction
Querying any video from holodex should return this error.
let client = holodex::Client::new("API_KEY").unwrap();
let video_id = "ZMLJMxKgjLU".parse().unwrap();
dbg!(client.video(&video_id));

Thank you for notifying me of this!
I'll check with the Holodex team if this was intentional, and if so, release a new version that removes the DisplayFromStr attributes on those fields 👍

0.3.3 is out now, fixing this issue!