remote add should set usable pushurl

The problem I'm trying to solve:

$ cd my-github-repository
$ hub remote add <someusername>
$ git push <someusername>
fatal: remote error:
  You can't push to git://github.com/<someusername>/repo.git
  Use https://github.com/<someusername>/repo.git
$ tail -n3 .git/config
[remote "someusername"]
        url = git://github.com/<someusername>/repo.git
        fetch = +refs/heads/*:refs/remotes/someusername/*

How I imagine hub could expose this functionality:

hub could simply add the ssh pushurl entry as well. This is what I do by hand for quite a while every now and then:
$ tail -n4 .git/config
[remote "someusername"]
        url = git://github.com/<someusername>/repo.git
        url = git@github.com:<someusername>/repo.git
        fetch = +refs/heads/*:refs/remotes/someusername/*

Sent from my RMX2020 using FastHub


Construct Box from world for ReflectComponent

Objective

For dynamic scene editing purposes need to create Component from defaults and insert it to entity.

Solution

Provide method from_world for ReflectComponent to create Box using FromWorld trait.

Changelog
Added:

Proxy method of FromWorld trait to ReflectComponent

This is breaking, as it adds a new field. I'd like to have a more tests and docs here, but that can be done later.


[Bug]: plugin does not respect .gitignore

Describe the bug
Hi! 👋
I've noticed that the plugin does not respect .gitignore.
My mac and android both have different files open etc in Obsidian, affecting the .obsidian/workspace file.
Hence, I added .obsidian/workspace to .gitignore, to avoid committing the workspace file as it is transient and device-dependent.
However this is not respected.
Currently, both parties are constantly committing their opinion on the file, also leading to conflicts (but they push through).
Relevant errors (if available)
No response
Steps to reproduce

write a .gitignore containing the line .obsidian/workspace
commit the .gitignore
run git rm --cached .obsidian/workspace, and commit that deletion (file should still exist locally but is now ignored)
obsidian will now check in .obsidian/workspace again, commits, pushes.
this renders .gitignore useless, because files that are already checked in will be tracked regardless of what .gitignore says.

Expected Behavior
.gitignore is respected, and neither party tries to push .obsidian/workspace since the file was never staged.
Addition context
No response
Operating system
macOS
Plugin version
2.5.1

I'm using the system installed git on desktop. So I'm very sure it's respected. I guess it's in the wrong directory or since you can't run git rm --cached .obsidian/workspace on mobile you got the file via mobile on desktop.

Ok let me check!

I'm running into the same problem.
Currently looking for a way to make it work

i wansnt completely clear in step 4: its obsidian on mobile that doesnt like the new commits from desktop: because workspace file is changed locally (mobile) and removed on remote. it does popups with a pull, conflict, push.
the resulting pushed commit will contain the workspace file as it was on mobile.

@ddelange So your issue is that gitignore is working on desktop.  But when pulling that commit on mobile, you get a merge conflict because the workspace file has changed. May you try to discard the workspace changes on mobile and then pull?

Thanks @Vinzent03, I can confirm that the plugin does respect .gitignore! Fix was to:

on mobile, disable auto pulling/pushing temporarily, close app
on desktop, git rm --cached .obsidian/workspace, commit again and push
on mobile, open command palette -> Obsidian Git: Open source control view
click the minus next to the workspace file  (under changed files) to discard the changes
pull the removal commit, this time without conflicts
enable auto pull/push again, all good! :tada:

Great! Things are always a bit more complicated if you can only use the gui.

on a similar note, it seems mobile and desktop are fighting over this one
--- a/.obsidian/plugins/obsidian-git/data.json
+++ b/.obsidian/plugins/obsidian-git/data.json
@@ -21,6 +21,6 @@
   "differentIntervalCommitAndPush": false,
   "changedFilesInStatusBar": false,
   "username": "__token__",
-  "showedMobileNotice": false,
+  "showedMobileNotice": true,
   "refreshSourceControlTimer": 7000
 }

Did you correctly pull the true value on mobile?  Close Obsidian on mobile and reopen. I think the issue is that the false is still cached in the running obsidian-git plugin instance. And writes its cached settings to the disk, ignoring the previously pulled value.

closed obsidian on android, manually edited data.json to true, started app, app pulled commit with true from desktop, no pushes with false coming from mobile as of yet 🎉


Memory access violation

Dear Mr Zaiser,
First of all thank you so much for making publicly available this very nice implementation of the XCP protocol.
I'm a developer mostly using the Mathworks / dSpace toolchain combining Simulink for modelling and code-generation with ControlDesk for debugging and visualisation.
The code compiled without any issues on my Windows 64bit machine.
Using a demo version of CANape I was also able to visualize the different measurements and instances of the XCP objects.
However, when connecting with the ControlDesk client from dSpace, XCP Slave application crashes with a memory access violation on line 754 of src/xcpLite.c
            memcpy((uint8_t*)d, &base[OdtEntryAddr(e)], n);

I'm no expert at all in writing or understanding this type of C++ software but after a few days of trial-and-error debugging I was able to find a workaround for the issue:
            uint8_t addr = OdtEntryAddr(e);
            uint8_t *src = &base[addr];
            memcpy((uint8_t*)d, src, n);

I cannot explain why this piece of code, which as far as I can see is identical to the original, does work, and the original does not, but it seems to solve the issue.
Would you be able to shed some light on this issue?
Thank you very much for your time and effort
Kind regards
Christophe

Hi Christophe,
the code you pointed out is the inner loop of measurement data aquisition. An access violation there is most probably caused by incorrect addresses in the A2L file. Are you sure, you are using an up to date (the generated) A2L file in control desk?
Regards
Rainer

Hi Rainer,
Thank you for your quick answer.
The problem is 100% reproducible in the sense that the original code always results in an access violation, and the adjusted code never does, with exactly the same A2L file in both cases.
My feeling is that the compiler somehow generates different (optimized?) machine code in both cases explaining the different behavior, but I cannot prove this assumption.
Would you or one of your colleagues be able to reproduce this behavior with an installation of ControlDesk?
Regards
Christophe

Hi Christophe,
sorry, I have overseen one detail in your code, which indeed changes the behaviour compared to the original code:
uint8_t addr = OdtEntryAddr(e);
XCP addresses are 32 bit values. You casted to 8 bit. Normally, you should have got a compiler warning from this.
As a result, the access violation disapears, but it will measure garbage read from a wrong address. Note that XCPlite constructs pointers from A2L addresses by adding the module load address to the A2L address.
So I still guess, there is a problem with wrong addresses in your A2L.
Please make sure that controldesk really uses the address from the A2L file. Try to reduce your measurement setup to a single signal that fails. Increase the debug output level to see what happens. In higher levels, the DAQ lists are dumped.
Regards

Hi Rainer,
Thank you for your clear explanation. Unfortunately I was not able to figure out more about this issue.
The good thing is I have code now that works so the issue is no longer blocking but it would be interesting to know from other ControlDesk users if they're facing the same problem.
If you would know any other users that are open to discuss about this issue please let me know.
Regards
Christophe


IIR filter implementation incomplete?

I tried to implement a controller, which is more complex than a PID, using the IIR-module. The controller is "just" a discrete-time linear transfer function. That didn't work and during debugging I stumbled across multiple issues with the IIR module I couldn't explain.
The fpga code only uses four coefficents, whereas the difference equation y0 = b0 * x0 + b1 * x1 + b2 * x2 + a1 * y1 + a2 * y2 of a general second order section / biquad has five. There is also a warning in the python code if b2 is non-zero. This would suggest the IIR module is currently unable to implement filters with complex zeros?
I also had weird outputs suggesting an unstable filter or some sort of transient oscillation or even saturation even given very small inputs.
I'm currently prototyping a re-implementation of the fpga-side implementation - I there didn't dig too much deeper into the second issue.
Edit: Also just... to avoid trouble later: What branch should I sensibly base any PRs on? I also did some dead-code removal in the verilog code for example.

Hi, please use the branch develop-0.9.3, the IIR implementation is a bit more advanced there than in the master branch. As far as I rememer, one can implement complex zeros, just needs to make sure the number of poles is bigger or equal to the number of zeros (for the high-frequency response not to diverge). Actually if there are as many poles as zeros, I think the code automatically adds a first-order pole near the nyquist frequency to make the filter more stable and to simplify the computation of the coeffiicients.

I just merged above branch into master. This should fix the issue. In case it persists, please re-open this issue @Delphinator

Sorry this took so long.
As far as I can see the issue still exists. The warning about b_2 != 0 is still there and the FPGA code only has four coefficents instead of the required five.
As far as I can tell the FPGA code implements y0 = b0 * x0 + b1 * x1 + a1 * y1 + a2 * y2, which corresponds to the (z-domain) transfer function
              b0 + b1 * z^(-1)
G(z) = ------------------------------
       1 + a1 * z^(z-1) + a2 * z^(-2)

which can only have a single real zero (given real-valued coefficents). It can however have one or two real poles or a single complex conjugate pair of poles.


Modal toast sent to background screen

When toast created in currently open modal screen, it is not displayed in the modal but on background screen. How to send the toast to open modal screen ?

I had the same problem. I've added the following code to my main css:
.toast, #toast-container {
z-index: 11001;
}
I think there was an another solution in a commit, but I didn't find it.

Fixed in bdf0aafef9ae8e7362f575b4e37e8b0f4a363569

A z-index of 10000 is not enough. We need at least 10001 in my case. Do you observe the same?


[1.3] Gaps in TV clusters - cont

Reproduction steps
Here is a list of updates needed for the tv example apps in order to use them for showcasing 1.3 functionality:

tv-app: ensure all the new TV 1.3 features are enabled
wrap up message cluster PR (see https://github.com/project-chip/connectedhomeip/pull/30254)
tv-app: add message as a server cluster on ep2.
tv-casting-app: add message as a client cluster on ep2.
Bump revision number of updated TV clusters from 1 to 2: AccountLogin, Channel, MediaPlayback, TargetNavigator - see 30261 , 30410 and 30411
Add missing OTT type to ChannelTypeEnum in Channel cluster.
Enable 3 new feature flags for ContentControl cluster (bits 5, 6, 7).

NOTE: This commit by @cecille seems to have accidentally removed the Message cluster events:
https://github.com/project-chip/connectedhomeip/commit/9c0cd9eb3656d3c7e40ca811257270db50384d61#diff-cc2349c86fdf91ea42e6eaf7253544065f6adefd863ab6f6a16e0b63f8ca8743
Bug prevalence
always
GitHub hash of the SDK that was being used
master
Platform
core
Platform Version(s)
No response
Type
Common Cluster Logic
Anything else?
No response

https://github.com/project-chip/connectedhomeip/pull/30254 under point number 2 continued here: https://github.com/project-chip/connectedhomeip/pull/31656


visualize audio in realtime (for audio recorder app)

is it posible to visualize streaming audio ?

The library doesn't do “visualization”. It is only a decoder of frequency into data for JS.
That is, you need to save some file and analyze it using the “analyze” method.
And what is the stream being streamed with?


Update oracle-manage-monitor-oracle-database-azure.md

Updated URL with available Microsoft Monitor Metrics
Before selecting the "Create pull request" button:

Enter a meaningful title above^, using a prefix if necessary and keywords "New" or "Update" indicating the nature of changes.

Describe the summary, scope, and intent of this PR:
Old URL was pointing back to Oracle URL. I have replaced this with Microsoft Monitor Metric URL which capture all metrics availability for Oracle Database@Azure VM Cluster.

Absence of this was causing bit confusion on available metric as part Monitor.

Insert links(s) to any related work item(s) or supporting detail:
This is official Microsoft URL for available metric for Oracle Database @ Azure VM Cluster https://learn.microsoft.com/en-us/azure/azure-monitor/reference/supported-metrics/oracle-database-cloudvmclusters-metrics

AFTER YOUR PR HAS BEEN CREATED, expand this section for tips and additional instructions.
These are common guidelines for contributions across the repos managed by the Cloud Architecture Content Team (CACT). Some repositories may have additional specific requirements that are not listed here.
Guidance for all contributors

Topic
Guidance

Draft PR
If your PR will be a work-in-progress for more than a day or two, select the Convert to draft link in the upper right of the page (under Reviewers) to change it to a draft. For future reference, you can also do this using the Create pull request button drop-down during PR creation.

ms.date metadata
Don't update an article's "ms.date" metadata property unless you've done a full freshness review of the content. A full freshness review includes changes required to correct or improve the full technical accuracy of the article.Don't update "ms.date" if you're doing targeted changes to improve non-technical aspects of the article, such as editorial quality, art improvements, article template alignment, etc.If you've changed any "ms.date" properties for work that wasn't part of full review for freshness, please reset them to their previous value.

Placement and linking
If you're creating a new article or articles, include updates to the related TOC.yml file to propose where the article(s) should be placed. Also consider other places within the document set where it would be beneficial to cross-reference and link to your new article(s).

PR build
After you open your PR, and for each successive commit that you push to your branch, the publishing platform will run validation on the files in your pull request. A summary of the build results for each file will be inserted inline into your pull request, which includes any build suggestions/warnings/errors. PRs cannot be merged until all build errors and most warnings are resolved.

Publishing
Following a successful merge, most repos publish to the live site at least once per (business) day, usually around 10am Pacific.

Additional resources
Learn.Microsoft.Com contributor guide

Additional guidance for private repos and internal contributors

Topic
Guidance

PR size
If your PR is more than ~5 lines of changes, or you'd like for the changes to go through editorial or larger review, open a contribution request at https://aka.ms/Contribution and include a link to the PR in response #8. Once it's processed, you'll be notified of the next steps.

PR title prefix
Select the Edit button to the right of the PR title if you need to revise it. The following prefixes are reserved for specific contribution types:[Quality Check] - maintenance work related to content quality (edit passes, art improvements, template alignment)[LinkFix] - recurring/adhoc PRs to correct link URLs[Pipeline] - new/updated contributor success pipeline content[WIP] - a work-in-progress draft requiring several days/weeks

PR preview
Following successful build of your PR, publishable files will also include Preview URL links to staged previews of your new/updated articles. Be sure to review these for verification of your intended contributions, or to send to other internal contributors for review.

PR sign-off (public repo)
If an article you own is updated in a public repo PR, you are responsible for sign-off. You will be automatically notified via email. The PR will not be merged until you've had a chance to review and sign-off.

PR sign-off (private repo)
After you've completed your proposed changes, addressed build warnings, and completed all review work, you can begin the sign-off process for review and merge:If your PR is in draft mode, remove "[WIP]" from the title and select Ready for review button at the bottom of the PR.Enter "#sign-off" in a new comment. This comment indicates that you're confident the work meets or exceeds Microsoft's standards for publication, and will trigger the review process.Your PR may be selected for initial review by the CACT. Following CACT review, you may receive questions or requests for additional changes. You should have initial feedback from CACT review within a few business days. If you have an urgent request or need to contact the team, please mention @MicrosoftDocs/cloud-architecture-content-team-pr-reviewers in your PR and someone will get back to you. After CACT review is complete, a CACT #sign-off will be added.Final review/merge is done by the PR review team. The PR team may also respond with feedback, categorized as "Blocking" (requires action from you), or "Non-blocking" (to be addressed in a future PR).

Additional resources
Learn.Microsoft.Com internal contributor guideAuthoring templates: architecture-center-pr, well-architected-prTo contact the CACT use e-mail, or @mention our GitHub team in your PR comments using: @MicrosoftDocs/cloud-architecture-content-team-pr-reviewers

PnP #sign-off
#remove-label:"pnp-review-in-progress"
#remove-label:"do-not-merge"
#label:"ready-to-merge"

#sign-off


Skip run query tests when when malformed connection was found

I had reproduced the same error in the Java SDK, but since working through the changes leading up to this state am able to run this test successfully now there — so I believe we should be able to run it successfully now here, too.
Going to close this PR as a result.


HCAP-1023 | Participant table dialogues component

https://freshworks.atlassian.net/browse/HCAP-1023

Please address duplicate code. Possibly share service could solve the issue.

https://github.com/bcgov/hcap/pull/618 Fixed here!


Recognition of Adetogramma (Polypodiaceae) [PASSED]

Name of taxon
Adetogramma T.E.Almeida
Rank of taxon
Genus
Approximate number of species affected
1
Description of change
Adetogramma, a monotypic genus in Polypodiaceae, was described by Almeida et al. (2017) to accommodate Polypodium chrysolepis Hook. The species had been previously combined in Microgramna (Microgramma chrysolepis(Hook.) Crabbe).
Reason for change
Phylogenetic inferences by Schneider et al. (2004) indicated that Polypodium chrysolepis was not related to Microgramma. Later phylogenetic and morphological evidence showed that Polypodium chrysolepis constitutes an isolated lineage among the neotropical polygrammoid ferns, close to Serpocaulon and the grammitids (Almeida et al. 2017). The results were later supported by the phylogenomic inference of Wei and Zhang (2022).
Adetogramma can be distinguished by its entire leaves with free veins and peltate, pedicellate, and lanceolate paraphyses. It can be distinguished from Microgramma, by the anastomosing veins on the sterile fronds of the latter (vs. free veins in Adetogramma). Moreover, A. chrysolepis has lanceolate, peltate, long-stalked paraphyses while in Microgramma, paraphyses (if present) are hairlike or lanceolate and sessile, never stalked.
Adetogramma can be readily distinguished from Serpocaulon by having free veins, non-clathrate scales, peltate scales covering the laminar surfaces, and peltate scales as paraphyses. These characers contrast with features of Serpocaulon species: regular anastomosing veins (goniophlebioid venation), clathrate scales, and the absence of scales in veins or laminar surface between veins or paraphyses, or if paraphyses are present, they are 2-3 celled glands.
Adetogramma also resembles some Pleopeltis species in having entire laminae, long-creeping rhizomes, and peltate paraphyses. The main difference between Pleopeltis and Adetogramma chrysolepis lies in the shape of the paraphyses – ovate-lanceolate in Adetogramma vs. roundish in Pleopeltis. Furthermore, species of Pleopeltis with entire blades always have anastomosing veins.
Polypodium s.s. can be distinguished from A. chrysolepis by its deeply-pinnatifid to pinnate leaves with free (in the Polypodium dulce complex species) to anastomosing veins, with a single included veinlet in each areole. Indument is also a useful character for separating A. chrysolepis, as Polypodium s.s. shows glabrous to pilose laminar surfaces and the paraphyses, when present, are filamentous or branched, while Adetogramma has scaly laminae and the paraphyses are pedicellate scales.
Reference(s) for publication of the name
Almeida TE, Salino A, Dubuisson J, Hennequin S. 2017. Adetogramma (Polypodiaceae), a new monotypic fern genus segregated from Polypodium. PhytoKeys 78: 109–131. DOI: 10.3897/phytokeys.78.12189
Crabbe JA. 1967. Bolivian pteridophytes collected by Winifred Brooke. Fern Gazette 9: 309–320.
Schneider H, Smith AR, Cranfill R, Hildebrand TJ, Haufler CH, Ranker TA. 2004. Unraveling the phylogeny of polygrammoid ferns (Polypodiaceae and Grammitidaceae): exploring aspects of the diversification of epiphytic plants. Molecular Phylogenetics and Evolution
31(3): 1041–1063. DOI: 10.1016/j.ympev.2003.09.018
Wei R, Zhang X-C. 2022. A revised subfamilial classification of Polypodiaceae based on plastome, nuclear ribosomal, and morphological evidence. Taxon 71(2): 288-306. DOI: 10.1002/tax.12658
Almeida_et_al_2017_Adetogramma.pdf
List the numbers of any related issues
No response
Code of Conduct

[X] I agree to follow the PPG Code of Conduct

This proposal was voted on during PPG Ballot 2 (voting period August 2023). A total of 69 votes were cast. There were 67 'Yes' votes (97.1%) and 2 'No' votes (2.9%). The proposal passes.

Already implemented in data, closing.


Update reducer to use new implementation of merge environments

Didn't move mergeEnvironments() as it's not specific to the reducer, can be used in resolver as well.

Codecov Report

Merging #14152 into main will decrease coverage by 59.94%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##             main   #14152       +/-   ##
===========================================
- Coverage   59.94%    0.00%   -59.95%
===========================================
  Files         705       14      -691
  Lines       39101       38    -39063
  Branches     5667        3     -5664
===========================================
- Hits        23440        0    -23440
+ Misses      14429       38    -14391
+ Partials     1232        0     -1232

Impacted Files
Coverage Δ

src/client/debugger/constants.ts
0.00% <0.00%> (-100.00%)
:arrow_down:

src/client/common/process/constants.ts
0.00% <0.00%> (-100.00%)
:arrow_down:

src/client/common/platform/constants.ts
0.00% <0.00%> (-100.00%)
:arrow_down:

src/client/datascience/notebook/constants.ts
0.00% <0.00%> (-100.00%)
:arrow_down:

src/client/interpreter/autoSelection/constants.ts
0.00% <0.00%> (-100.00%)
:arrow_down:

...t/datascience/jupyter/jupyterDataRateLimitError.ts
0.00% <0.00%> (-50.00%)
:arrow_down:

src/client/language/braceCounter.ts

src/client/activation/jedi/activator.ts

src/client/terminals/types.ts

src/client/datascience/messages.ts

... and 685 more

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 218dd8d...d99acd7. Read the comment docs.

Codecov Report

Merging #14152 into main will increase coverage by 0.06%.
The diff coverage is 95.23%.

@@            Coverage Diff             @@
##             main   #14152      +/-   ##
==========================================
+ Coverage   59.28%   59.34%   +0.06%
==========================================
  Files         715      715
  Lines       39956    39950       -6
  Branches     5791     5788       -3
==========================================
+ Hits        23686    23708      +22
+ Misses      15021    14980      -41
- Partials     1249     1262      +13

Impacted Files
Coverage Δ

src/client/pythonEnvironments/base/info/env.ts
78.00% <80.00%> (+40.26%)
:arrow_up:

...nts/base/locators/composite/environmentsReducer.ts
95.58% <100.00%> (+0.65%)
:arrow_up:

...very/locators/services/virtualenvwrapperLocator.ts
76.92% <0.00%> (-15.39%)
:arrow_down:

src/client/common/utils/platform.ts
60.00% <0.00%> (-12.00%)
:arrow_down:

.../pythonEnvironments/common/externalDependencies.ts
64.10% <0.00%> (-2.57%)
:arrow_down:

src/client/linters/pydocstyle.ts
86.66% <0.00%> (-2.23%)
:arrow_down:

src/client/datascience/debugLocationTracker.ts
76.56% <0.00%> (-1.57%)
:arrow_down:

src/client/datascience/jupyter/jupyterSession.ts
71.42% <0.00%> (-1.21%)
:arrow_down:

src/client/common/process/proc.ts
14.49% <0.00%> (-0.73%)
:arrow_down:

...ient/datascience/interactive-ipynb/nativeEditor.ts
7.76% <0.00%> (-0.03%)
:arrow_down:

... and 4 more

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 0a1bbbd...4046609. Read the comment docs.


Question: How to compile without system library dependencies

Is there a way to compile a standalone version without any system library dependencies? I don’t absolutely need a static binary. It could be many files with dynamic libraries but I would like to have no dependencies to libs in /lib/.
The reason I need it is for portability mostly on system that have recent glibc version. Right now, I compile on a debian (stretch) host using Python 3.6.8 and nuitka 0.6.5.

If you need absolutely no dependency on /lib, you can not use glibc, unless you can remove any dependency on pthreads.
See https://www.google.com/search?q="libgcc_s.so.1"+"pthread_cancel"
The alternative is to build static Python against a different libc.
If you can accept a dependency on libgcc_s , then it is possible, but you will need to carefully build your static Python otherwise you run into problems with duplicate/missing symbols.  See https://github.com/Nuitka/Nuitka/issues/95
And then you need to hack a bit to get Nuitka to find your static Python .a
# Force static support
sed -i 's/return "Anaconda" .*$/return True/' nuitka/Options.py
# Help Nuitka find the static lib to link against
sed -i 's:python_lib_path, "libpython" + python_abi_version + ".a":"/usr/lib/python3.7/config-3.7m-i386-linux-gnu/libpython3.7m.a":' nuitka/build/SingleExe.scons

I am just going through this process myself ;-)
I just removed the Py_GetArgcArgv collision by excluding main.o from the .a, but now I have a bunch of undefined references to PyCore*/PyConfig*/others.

Current factory branch no longer has these issues, @jayvdb by just making the symbol weak.
The standalone cannot make glibc for newer kernels work with older ones. You absolutely have to build on the oldest system you intend to support, going forward then often works. The other way around, not so much.


Native support for .env in Serverless Framework

@colynb great thanks for this plugin!
We're currently investigating a possibility of supporting .env file natively in a Framework.
Main reason is that ideally env vars from .env should be loaded at very begin of a process, and resolution via plugin is delayed simply by its nature. So taking into account dotenv popularity I believe it's a good call to make it a first class citizen in the Framework (it's also already supported in Serverless Components)
Also we simply plan to support it it as convenient env vars transport into process.env and nothing more (no automatic leak into lambdas etc.)
We will value your feedback at https://github.com/serverless/serverless/issues/7907

Thanks @medikoo - I included my comments in that thread. I'm more than happy to be part of the conversation and will do my best to support your efforts.


chore(Data/Set/Lattice): use named arguments more.

It's nicer to read than writing @foo _ _ _.

Thanks!
bors merge


Add shashwathi as approver

Add shashwathi to list of Approvers in Build
From ROLES.md
Reviewer of the codebase for at least 3 months or 50% of project lifetime, whichever is shorter
Earliest Pull request submitted: 2018-07-03(yyyy-mm-dd). Finished 3 months on the projects.
Total PRs submitted:
https://github.com/knative/build/pulls?q=is%3Apr+author%3Ashashwathi
Reviewer for following PRs to the codebase
https://github.com/knative/build/pulls?q=is%3Apr+reviewed-by%3Ashashwathi
/assign @ImJasonH
cc @dprotaso @pivotal-nader-ziada @bsnchan

Welcome aboard! 🚀
/lgtm
/approve


Remove .validation for manifests\j\JiacaiLiu\1History - Empty directory

Microsoft Reviewers: codeflow:open?pullrequest=https://github.com/microsoft/winget-pkgs/pull/115573&drop=dogfoodAlpha

[Policy] Needs Manual Merge


import 'postprocessing'  cause 404 error on next js

Import cause 404 error in server side render(next js)
When i run in local it's run very well but since I deploy with vercel and next js.
Just when I use
composer = new EffectComposer(renderer, {});
cause this  symptom..

please help...
env:
"postprocessing": "^6.29.1",
"react": "18.2.0",
"next": "12.2.0",
"three": "^0.147.0",

I solved with this way but please check if it is okay..
First I downloaded the postprocessing.js from node module postprocess build.
I put that file on my local path  and imported with import * as POSTPROCESS from ./postprocessing ,
I checked the error message with all lines that require('three') so I have to change the require('three')
to THREE with import * as THREE from 'three';
I checked that it solved the 404 error.
But In this way, cocMaterial in DepthOfFieldEffect is not work. I mean the changing world distance is not working..

Hi,
this should just work out of the box if you're using ESM modules correctly, e.g. via import xxx from "xxx". The 404 errors are probably coming from those require('xyz') lines and it's unlikely that the postprocessing package is causing this.

First I downloaded the postprocessing.js from node module postprocess build.

That's not a good idea. Why don't you use import { EffectComposer } from "postprocessing";? I'm not familiar with next.js, but this looks like a bundler misconfiguration issue.

I tried that import { EffectComposer } from "postprocessing";
But it didn’t work neihter

This has nothing to do with the postprocessing library and entirely your usage of the file-based-routing of Nextjs. Please see its docs and basic routing.
For how to include three.js in a React app see:

imperatively via hooks: https://codesandbox.io/s/react-three-1l5oj
declaratively via a renderer: https://codesandbox.io/s/react-three-fiber-f78cg

If you need further help, ask in https://discord.gg/poimandres, but please don't resort to issues unless you're describing a feature request or bug of a library.


Add fallback configuration for fostgres.sql view

This will allow the user to configure a fallback view for use when none of the path matches are selected.

This will close issue #15


Add sounds to the effects

This could add a nice touch and a new dimension to the effects.
Could be a config option because it wouldn't always make sense. Still a lot of things to figure out here:

how to best incorporate it in the developer experience
where to get sounds that are free to use for our use-case
how to handle e.g. long-running audio (loops?)

@DaemonLoki I love this one. We can check epidemic sounds for some sound effects


Camera is not working.

Thanks for this wonderful library.
I have an issue. Camera screen is not working.
Although, I have download demo repository and running the same.
Here is a screenshot.

@Rashesh-Bosamiya check if your compass calibration is enabled, on Settings->Privacy->Location Services->System Services->Compass Calibration

Try deleting the app and re-installing, ensuring you accept camera permissions. Also - this won't work in simulator.

It is not asking for camera permission.

working fine now.
iPhone 6 Doesn't support AR based Apps.
Thanks.


Add support for ESP-IDF v5.0

Missing support for newer version of the IDF 5.0.

In the guide for the migration from IDF 4.x to 5.x.
Suggest the use of <inttypes.h> to facilitate the changes regarding the size of integers of this new version.


unsubscribe all observer

What does the pull request do?
Use the simplest way to unsubscribe all observers.
What is the current behavior?

What is the updated/expected behavior with this PR?

How was the solution implemented (if it's not obvious)?

Checklist

[x] Added unit tests (if possible)?
[ ] Added XML documentation to any related classes?
[ ] Consider submitting a PR to https://github.com/AvaloniaUI/avalonia-docs with user documentation

Breaking changes

ValueStore (Add a method)
AvaloniaObject (Add a method)
StyledElement (Add a method)
ILogical (Add a method)

Obsoletions / Deprecations

Fixed issues
Fixes #13703

I'm not sure this is the correct solution because it only works for TopLevel controls. What if your custom observable is applied to a non-TopLevel control? We can't apply this logic to a non-TopLevel control because we can't unsubscribe all bindings there as the control may be re-attached to a tree. So I am having difficulty accepting that we should special-case TopLevel.
Having said that, I'm having difficulty understanding your repro, so lets continue discussion on #13703.


StackNavigator: How to send data back from child screen to calling screen?

I have defined a MainScreen, from where the user can navigate to a "subscreen" called EditScreen, using Stacknavigator and this.props.navigation.navigate().  There, the
user can change some data.
I now want to send the data back to MainScreen. What is the correct way of doing this?
My self-made "trick" until now was:
First, navigate to EditScreen with
this.props.navigation.navigate(
  'Edit',
  {
    parent: this
  }
);

Then, once the data shall be sent back from EditScreen:
this.parent.foo = "new value";
this.parent.setState({ bar }); // To trigger render.
this.props.navigation.goBack();

However, this leads to some odd behaviour afterwards in MainScreen, such as
reloading it twice and loosing some of its state.
So I wonder: What is the correct way to send some data back to the calling
screen.
(BTW: I've simplified the example, if you want to see the original code:
check here )

I'd suggest using Redux here to pass state around your app.

Hi! In an effort to reduce the number of open issues I'm closing question-type issues that would be a better for the react-navigation tag on StackOverflow. This is nothing personal, merely trying to get the # of issues to a more manageable level. If you think this issue should be re-opened please let me know. Thanks!


Enhancing ZZCrossTalk Parameter Input

Hello,
I'm currently working with the ZZCrossTalk class to specify ZZ crosstalk parameters between qubits in a noise model. The current implementation requires these parameters to be provided as a numpy.array, where the element at index [i, j] represents the crosstalk between qubit i and qubit j, as shown below:
ZZCrossTalk(cross_talk_matrix=np.array([[0, 1e-4],[0, 0]]))
While this approach is straightforward for smaller circuits, it can become cumbersome and inefficient for larger circuits due to the potential sparsity of the crosstalk matrix. In many cases, the matrix might contain a significant number of zeros, leading to unnecessary memory usage and possibly making the input process less intuitive.
To address this, I propose an alternative method of specifying the crosstalk parameters using a dictionary in coordinate format. This method would allow users to input only the non-zero crosstalk values, specifying the qubit pairs as keys and their corresponding crosstalk strengths as values. For example:
ZZCrossTalk(cross_talk_matrix={(0,1): 1e-4})
In this format, the tuple (0, 1) represents the crosstalk between qubits 0 and 1, and 1e-4 is the strength of the crosstalk.
My question is:

Do you find the coordinate format more user-friendly, compared to the current array-based input?

New release now has this implemented.


implement a tool for verifying language grammars

The passtool currently only performs some basic checks (i.e., whether
all references name existing rules and that no duplicate productions
are introduced).
In the future, it'll also provide code-generation facilities for
automating the creation of validation layers for languages. The idea is
to reduced the overhead of removing, changing, or adding new
intermediate languages as much as possible.
The tool is ran as part of CI to make sure all language grammars are
valid.

I didn't merge it in case there was more to it than waiting for the merge of the other PR, apologies if that was the only blocker.

I didn't merge it in case there was more to it than waiting for the merge of the other PR, apologies if that was the only blocker.

No no, it's all good. The reason I wanted to wait with merging was so that I can update CI to test lang1 instead of lang0.


fix: lambda this closure value and config

1. Does this PR affect any open issues?(Y/N) and add issue references (e.g. "fix #123", "re #123".):

[ ] N
[x] Y

fix #1668
fix: lambda this closure value and config

Pull Request Test Coverage Report for Build<PHONE_NUMBER>3
Details

6 of 54 (11.11%)  changed or added relevant lines in 6 files are covered.
5 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.05%) to 70.606%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

kclvm/evaluator/src/context.rs
0
1
0.0%

kclvm/evaluator/src/node.rs
6
9
66.67%

kclvm/evaluator/src/func.rs
0
10
0.0%

kclvm/evaluator/src/lib.rs
0
10
0.0%

kclvm/evaluator/src/rule.rs
0
10
0.0%

kclvm/evaluator/src/schema.rs
0
14
0.0%

Files with Coverage Reduction
New Missed Lines
%

kclvm/sema/src/resolver/mod.rs
1
99.06%

kclvm/driver/src/toolchain.rs
4
88.89%

Totals

Change from base Build<PHONE_NUMBER>8:
-0.05%

Covered Lines:
51444

Relevant Lines:
72861

💛  - Coveralls


Add README

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

Project coverage is 93.93%. Comparing base (fc896e2) to head (f4f41b9).

Additional details and impacted files
@@           Coverage Diff           @@
##             main       #8   +/-   ##
=======================================
  Coverage   93.93%   93.93%
=======================================
  Files           7        7
  Lines         264      264
=======================================
  Hits          248      248
  Misses         16       16

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


Adding travis tests

Tests fail due to integration tests, this is fixed by pull integration tests out of npm test

This will land in #18


Logger defaults to Rails.logger if run in Rails environment -- can't turn off API response payloads

My Rails log file is overflowing with the payload of every API response from the GMail v1 API
The docs here suggest setting your level to INFO to silence the output:
https://developers.google.com/api-client-library/ruby/guide/logging
But when you do that, all of your Rails standard debug logging goes away. Digging in, I see that Google::Apis assigns its logger to the Rails.logger if it's defined.
This seems like a strange choice and almost never the right answer.
I realize that the workaround is to construct a new Logger and assign it to Google::Apis.logger -- but that should be documented as the proper way to adjust logging
Or perhaps the default should be to use the $stdout logger and Rails users can choose to pollute their Rails log file by reassigning the logger accordingly
Oh, how I miss Log4j :-)

Unfortunately I don't think I can change this behavior until the next major bump since there could be people expecting/relying on the current behavior. That said, I'll update the docs to make this clearer.
If it helps, I'd be willing to add a simpler mechanism to turn this on/off (albeit default to on) like an environment variable or something along those lines.

I think an option (supporting both ENV or explicit Google::Apis method) for specifying what level to dump payloads would be best .. and yeah, it could default to DEBUG but you could specify NONE if you want to shut it off (not my preference since most client libraries don't enable this level of tracing by default .. but if it's really necessary for backwards compat, I understand)

Added a bypass mechanism + updated the readme with more details on how to configure logging.


Provide pluggable exception handling strategy

When a listener fails with an exception CursorManager.onError called, exception escapes - as an outcome processing stops:
    private void processBatch(Batch<T> batch) throws IOException {
        final Cursor cursor = batch.getCursor();
        try {
            listener.accept(batch.getEvents());
            cursorManager.onSuccess(eventName, cursor);
        } catch (EventAlreadyProcessedException e) {
            LOG.info("Events for [{}] partition [{}] at offset [{}] were already processed", eventName, cursor.getPartition(), cursor.getOffset());
        } catch (Throwable throwable) {
            cursorManager.onError(eventName, cursor, throwable);
            throw throwable;
        }
    }

In some cases it is useful to continue reading events and commit the cursor or read failed batch again. This can be up to user. What about providing pluggable strategy to handle batch processing exceptions, like this:
    private void processBatch(Batch<T> batch) throws IOException {
        final Cursor cursor = batch.getCursor();
        try {
            listener.accept(batch.getEvents());
            cursorManager.onSuccess(eventName, cursor);
        } catch (EventAlreadyProcessedException e) {
            LOG.info("Events for [{}] partition [{}] at offset [{}] were already processed", eventName, cursor.getPartition(), cursor.getOffset());
        } catch (Throwable throwable) {
            exceptionHandlingStrategy.onException(throwable, cursor, cursorManager);
        }
    }

This can be done without breaking current API.

The exception handling strategy currently is

EventAlreadyProcessedException ignore without committing
IOExceptions close connection and reconnect
RuntimeException abort streaming, has to be handled outside

What other strategies could be useful, and could they be implemented in the Listener itself?

I overlooked EventAlreadyProcessedException this behaviour is exactly what I need.


AttributeError: module 'tensorflow' has no attribute 'confusion_matrix'

I am using GPU version of tensorflow 0.12.1 and python3.5 for building a CNN network.
When I am trying to compute confusion matrix it gives me the error.
confusion = tf.confusion_matrix(labels = y_, prediction = y, num_classes = model.No_Classes)
y_ is the input labels that I am giving to the network and y is the output of my CNN network. model.No_Classes = 4 an integer value.
is there package missing in this version ?

I have upgraded to tensorflow 1.0.1 and this works !


Restricts spel-release so it will only install on matching EL version

Broke open the repos stored as build artifacts, to confirm the expected Requires statements:
Requires:       redhat-release >=  8, redhat-release < 9

Requires:       redhat-release >=  7, redhat-release < 8

Ok, it's a stream thing, not a CentOS thing:
$ rpm -qa \*release\*
epel-next-release-8-19.el8.noarch
epel-release-8-19.el8.noarch
spel-release-8-3.noarch
centos-stream-release-8.6-1.el8.noarch

Which is to say, it shouldn't install when generating CentOS Stream AMIs or already-running CentOS Stream EC2s (whether running version 8 or version 9)

We already install this on the steam Amis that we build, so, we already know it must be ok? In fact, the build itself installs the package successfully into a stream8 docker container. It definitely is working.


[Bug] "Internal Error" (version 0.8.0b1) when adding buttons to radio box [sf#232]

Reported by rsonnenfeld on 2017-12-30 20:35 UTC
Greetings Maintainers!  To get more comfortable with wxglade, I have slavishly followed the directions here: http://wxglade.sourceforge.net/docs/tutorial.html to create a calculator app.
Everything was perfect up till the step where I was asked to add radio buttons for +-*/.
As you can see from screenshot, the buttons DID get added (and the designer window shows
them correctly) but every press of the "Add" (or "Remove") key resulted in the following error.
The summary said "type.exceptions "Type Error" and "This is a bug, report it" even though
the detailed description says ERROR: None.  The code appears to be working, apart from this
obnoxious message.  I will update the report when I finish the calculator project and let you know
if the radio buttons actually created functional code.

ERROR   : None
An unexpected error occurred!

Exception type:      <type 'exceptions.TypeError'>
Exception details:   Required argument 'col' (pos 3) not found
Application stack traceback:
File "/home/richard/aainfors/Tech/python/wxglade0.8/new_properties.py", line 2461, in add_row
self.grid.GoToCell( (len(values)-1,self.cur_col) )
File "/usr/lib/python2.7/dist-packages/wx-3.0-gtk2/wx/grid.py", line 1428, in GoToCell
return _grid.Grid_GoToCell(*args, **kwargs)
Thanks for the excellent tutorial BTW, and version 0.8 seems to be quite a bit easier to work with than 0.6 was.

Commented by rsonnenfeld on 2017-12-30 20:36 UTC
I am working on an update to the tutorial BTW just to make it a little clearer.
Can I e-mail that to someone?

Updated by dschwertberger on 2017-12-30 20:46 UTC

status: open --> accepted
assigned_to: Dietmar Schwertberger

Updated by dschwertberger on 2017-12-30 22:37 UTC

status: accepted --> pending

Commented by dschwertberger on 2017-12-30 22:37 UTC
Thanks for reporting.
I did some changes recently on grid/list properties to make editing smoother.
I'm mainly testing on wxPython Phoenix, so I did not notice that Grid.GoToCell is different with Classic and not available on 2.8.
The fix is now in the repository and will be in revision 0.8.0b2.
Nowadays I recommend to switch to Phoenix. It has been quite usable for more than one year now.
See separate PM for the tutorial.


Disable test stdlib/PrintFloat.swift.gyb on arm64_32 watchos

It fails on a bot.
rdar://77087867

@tbkka Out of curiosity, does this reflect any recent changes in SwiftDtoa?

No.  It seems to be fallout from some recent work on arm64_32 support.


Style fix

https://cockroachlabs.atlassian.net/browse/DOC-6425
"CockroachDB Dedicated-managed service account" is technically incorrect because service accounts are created for your CockroachDB Cloud organization, not Serverless or Dedicated clusters specifically. Removed hyphen and changed to "CockroachDB Cloud service account."

I think the GCP project is actually unique to each Dedicated cluster, so that one makes more sense. Are you ok with leaving that hyphen in? It's a little awkward but does make sense.

Sure then! You absolutely know this better than I, approved!


Update client validation error messages to align with Heuristic evaluation criteria

Description
Please add an informative description that covers that changes made by the pull request and link all relevant issues.
If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
criteria: https://hits.microsoft.com/collection/7002637/Section/72548#5YP3J-design"

Make all text white except error message which should be red
Precede error messages with "(x)"
Make all links cyan

This PR also updates SDK validation error messages to raise MlExceptions and record error type when telemetry is recorded.
All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-ai-ml


Fix tags (#guide and #resource)

In the same vein as https://github.com/princomp/princomp.github.io/issues/32, the #guide and #resource tags probably need to go away or get populated

Drafted a solution with 97806b4, but may be tweaked depending on opinions.

Yes that seems fine.


RedisHubLifetimeManager Self Referencing Loop

I am trying to use redis scaleout with SignalR and having some issues.  I have a few models that I return to the clients that have self referencing loops in them.
With just SignalR I simply did this in my startup and it resolved the issue....
services.AddSignalR(options => { options.JsonSerializerSettings.ReferenceLoopHandling = Newtonsoft.Json.ReferenceLoopHandling.Ignore; });
I have now added Redis into the mix and my serialization settings are no longer being obeyed.  I took a look at the RedisHubLifetimeManager and it appears that when I call Clients.All.InvokeAsync..... from my hub it is being proxied through to RedisHubLifetimeManager.PublishAsync where the private readonly serializer is taking over from there which sort of explains the issue, however, I was under the impression that the RedisHubLifetimeManager shouldn't actually be calling the clients, rather it should be gathering all of the connections and dispatching them back....not totally sure on this though.
Any suggestions or pointers are appreciated as I'm currently at a standstill with no real idea how to properly resolve this issue.

What kind of payload are you sending through SignalR? You should generally avoid sending anything other than plain data-transfer objects (with no reference loops) via SignalR.

In my case they are EF models.  I know it’s best to use view models but my payload does not contain any sensitive data so no reason to add the overhead to convert it

This is going to be solved by https://github.com/aspnet/SignalR/issues/1800


Regex convertPlaceholder is broken

I think there was a mistake.
https://github.com/tinglesoftware/dependabot-azure-devops/blob/75df48ab6b5999ad614107a447858f225a113f96/extension/task/utils/convertPlaceholder.ts#L4
This does not work:
https://regex101.com/r/bmIth9/1
This works:
https://regex101.com/r/q0hfGm/1

version: 2
registries:
nuget-azure-devops:
type: nuget-feed
url:
password: PAT:${{PAT}}
updates:

package-ecosystem: nuget
directory: "/source"
target-branch: "feature/dependabot"
target-branch: "acceptance"
registries:

nuget-azure-devops
open-pull-requests-limit: 1

You can close this item. Found the problem, was missing a permission

Thanks for getting back. Could you kindly contribute the unit tests?

Yes I could. I will make a pr monday for you


Default shortcut keys Conflict (Mac OS)

I am on the latest Cerebro.app version

I have searched the issues of this repo and believe that this is not a duplicate

OS version and name: macOS Big Sur 11.4

Cerebro version: 0.3.0

Relevant information from devtools N/A

Issue
The default shortcut keys conflict with the macOS keyboard language switcher ( ^␣ ).

If there are any good suggestions I guess we're open to that.
We could go for option + space.


⚠ Bofrost.at has degraded performance

In bd0a913, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1495 ms

Resolved: Bofrost.at performance has improved in 9ac6161.


VehicleDoors.Trunk2 Doesnt exist

Can I remove the Trunk2 from the Vehicle doors enum. Its defined on Native DB but Im 99.99% sure it doesnt exist and vehicles only have 6 doors max(driver, passenger, drive side rear, passenger side rear, hood and trunk)

Scratch that, Im 100% sure it doesnt exist
http://puu.sh/oSMp1/9038ae3b04.png

Sure. (By the way, is that IDA database available somewhere?)

I literally just disassembled the latest gta5.exe and documented that function to see if anything changed (i.e still 6 doors)

you may be able to find documented databases from the first game versions that give quite a lot of useful stuff. however since R* started encrypting the native table, reversing natives on later patches is harder

Fixed in #460


Node does not work with galactic?

First of all, thanks for the ROS2 port!
I've pulled today the current version and noticed, that apriltag_ros cannot be build any more. I'm using ROS2 Galactic on Ubuntu 20.04.5 LTS on virtual machine and I got the following error:
--- stderr: apriltag_ros
CMake Error at CMakeLists.txt:25 (find_package):
  Could not find a configuration file for package "apriltag" that is
  compatible with requested version "3.3".

  The following configuration files were considered but not accepted:

    /opt/ros/galactic/share/apriltag/cmake/apriltagConfig.cmake, version: 3.2.0

In the Galactic central index there isn't still apriltag 3.3:
https://github.com/ros/rosdistro/blob/master/galactic/distribution.yaml
so I wonder where can I get it?
Until then, I found out, that I can remove the version from CMakeLists.txt line 25 like that:
find_package(apriltag REQUIRED)
Only then I got other errors on launch. The initialization of the ROS2 parameters "detector.refine" and "detector.debug" fails even when I do not set the parameters and wrong parameter type error appears. Here the one for "detector.refine", they are both identical:
[INFO] [launch]: All log files can be found below /home/mihail/.ros/log/2022-09-27-22-53-49-985567-myVB-20693
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [component_container-1]: process started with pid [20705]
[component_container-1] [INFO] [1664312030.711422719] [apriltag.tag_container]: Load Library: /home/mihail/thermalcamerafaultdetection/ROS2_Workspace/install/apriltag_ros/lib/libAprilTagNode.so
[component_container-1] [INFO] [1664312030.884578613] [apriltag.tag_container]: Found class: rclcpp_components::NodeFactoryTemplate<AprilTagNode>
[component_container-1] [INFO] [1664312030.884656263] [apriltag.tag_container]: Instantiate class: rclcpp_components::NodeFactoryTemplate<AprilTagNode>
[component_container-1] [ERROR] [1664312030.917002066] [apriltag.tag_container]: Component constructor threw an exception: parameter 'detector.refine' has invalid type: Wrong parameter type, parameter {detector.refine} is of type {bool}, setting it to {integer} is not allowed.
[ERROR] [launch_ros.actions.load_composable_nodes]: Failed to load node 'apriltag' of type 'AprilTagNode' in container '/apriltag/tag_container': Component constructor threw an exception: parameter 'detector.refine' has invalid type: Wrong parameter type, parameter {detector.refine} is of type {bool}, setting it to {integer} is not allowed.
^C[WARNING] [launch]: user interrupted with ctrl-c (SIGINT)
[component_container-1] [INFO] [1664312600.778612133] [rclcpp]: signal_handler(signal_value=2)
[INFO] [component_container-1]: process has finished cleanly [pid 20705]

I managed to fix the error by reverting the data type back to int, as it was before commits on Aug 28, 2022. Does this has something to do with the fact, that I'm not using the newest version 3.3? The parameters are being initialized from the "apriltag_detector_t* const td".
Then as a side question, I was wondering why the more precise pose estimation from the apriltag library is not implemented. The pose estimation from the homography has very low precision that is almost unusable, isn't? I've took the time to implement it as an optional setting that is turned off by default and I think it could be useful to others as well. I can gladly contribute it if you want:
https://github.com/MihailV1989/apriltag_ros
Only I cannot guarantee there aren't any hidden bugs and that the code is optimized well as I have no experience with C++. The more precise pose estimation can be turned on by the "refine-pose" parameter that I saw in a very old launch.py file few months ago.

The API in the apriltag library changed and we incremented the version for that. That version has not been released to the official ROS repos yet. You will have to build it from source. The node requires this new version. If you just rove the version check,

Thanks for the fast reply! In fact I'm not getting any compilation errors after I removed the version check. Only the wrong parameter type errors on launch. With the fixes I mentioned above the node is working correctly, so I'll then just wait for the official ROS repos release.
As for the pose estimation method, I didn't found a new solution, I just implemented the the official method that is described in the AprilTag Wiki:
https://github.com/AprilRobotics/apriltag/wiki/AprilTag-User-Guide#pose-estimation
The accuracy gain of the pose estimation is quite obvious and the exact method is documented in a paper. This is from apriltag_pose.h that is used for the pose estimation:

Estimate pose of the tag. This returns one or two possible poses for the
tag, along with the object-space error of each.

This uses the homography method described in [1] for the initial estimate.
Then Orthogonal Iteration [2] is used to refine this estimate. Then [3] is
used to find a potential second local minima and Orthogonal Iteration is
used to refine this second estimate.

[1]: E. Olson, “Apriltag: A robust and flexible visual fiducial system,” in

 2011 IEEE International Conference on Robotics and Automation,

 May 2011, pp. 3400–3407.

[2]: Lu, G. D. Hager and E. Mjolsness, "Fast and globally convergent pose

 estimation from video images," in IEEE Transactions on Pattern Analysis

 and Machine Intelligence, vol. 22, no. 6, pp. 610-622, June 2000.

 doi: 10.1109/34.862199

[3]: Schweighofer and A. Pinz, "Robust Pose Estimation from a Planar Target,"

 in IEEE Transactions on Pattern Analysis and Machine Intelligence,

 vol. 28, no. 12, pp. 2024-2030, Dec. 2006.  doi: 10.1109/TPAMI.2006.252

@outparam err1, pose1, err2, pose2

With the fixes I mentioned above the node is working correctly, so I'll then just wait for the official ROS repos release.

Alternatively, you can just check out the library in your workspace and compile it together with the node.

As for the pose estimation method, I didn't found a new solution, I just implemented the the official method that is described in the AprilTag Wiki:

I just meant that if you find that this works better and is more accurate, you can send a PR with that proposed implementation in the node. I can review it, but it would be good to have some comparison in this PR that shows that the alternative implementation works better in speed and/or accuracy.

Will do. In the mean time I think I found an issue with the pose estimation. The node is using the camera intrinsic parameters, specifically the matrix P, without adjusting them to the actual image resolution. The CameraInfo message provides the original calibration resolution and corresponding intrinsic parameters:
http://docs.ros.org/en/melodic/api/sensor_msgs/html/msg/CameraInfo.html
They have to be then scaled proportionally to the scale of the actual image used for pose estimation relative to calibration resolution:
https://docs.opencv.org/4.x/d9/d0c/group__calib3d.html#MathJax-Element-78-Frame
I've implemented this as well in my fork:
https://github.com/MihailV1989/apriltag_ros/commit/a7c4d8b77c0e7152346be93b01b9a39fabee5a88
So far it's working correct and now I've tested it on a Raspberry Pi 4 with 1GB RAM and headless Ubuntu. I'll provide performance test results in the next days.

They have to be then scaled proportionally to the scale of the actual image used for pose estimation relative to calibration resolution:

Is this related to quad_decimate in the library and detector.decimate in the node? The image dimensions in the image you get from the camera should match the values in the CameraInfo message. Is there a case where the processed image dimension differs from the received image?

I would say that it would be inconvenient if you are stuck with the original calibration resolution. If you're using a third party camera image publisher and you calibrate the camera at say full resolution, then you have to manually scale the intrinsic parameters every time you change the resolution. In my case I'm starting a third party publisher node and I have to give the path to a .yaml file where the intrinsic camera parameters are saved and I could edit the file according to the set resolution. But this is only possible at start and with time a calculation error will accumulate. So I don't find it a good solution as you won't be able to experiment easily with different resolutions.
Then of course is the question why not to use always full resolution. Normally you would like to find the optimal resolution for your application so that you don't overload your system. In my case the main limiting factor is the 1GB RAM and the camera bandwidth. But probably there are other use cases where you don't want to use up your resources for publishing big images at high FPS and later decimate the images.
Then about the decimate function. In the case that you're interested in the pose estimation capabilities, it does not make sense to reduce the resolution only for the quad detection that is then used for the pose estimation and still use the full resolution for decoding the binary payload. I don't know how much computational intensive the decoding is, but when I run it on a hardware with limited resources I don't want it to perform better than needed. When a tag is moving away from the camera, the pose estimation becomes unusable much sooner than the decoding.
Maybe all this is not a big deal, but scaling the intrinsic camera parameters when the actual image resolution differs from the calibration resolution is even less problematic and makes the node more foolproof, isn't?

I would say that it would be inconvenient if you are stuck with the original calibration resolution. If you're using a third party camera image publisher and you calibrate the camera at say full resolution, then you have to manually scale the intrinsic parameters every time you change the resolution. In my case I'm starting a third party publisher node and I have to give the path to a .yaml file where the intrinsic camera parameters are saved and I could edit the file according to the set resolution. But this is only possible at start and with time a calculation error will accumulate. So I don't find it a good solution as you won't be able to experiment easily with different resolutions.

I am still not sure what the exact problem is. What do you mean with being "stuck with the original calibration resolution"? Every camera setting, such as image dimension, zoom, lense, etc. will have a dedicated set of intrinsic parameters.
When a ROS node publishes images, it also has to publish the corresponding intrinsics. When this node publishes a scaled version of the image, it also has to scale the intrinsics accordingly. You will see this with cameras supporting different image resolutions. Most of them will have dedicated intrinsics for every setting. Otherwise, you will have to calibrate them manually for every setting you use. It's the responsibility of the "sender" (e.g. a camera or generic image publisher) to make sure that image data and intrinsics are correct and match. The "receiver" (e.g. this apriltag node) cannot know how the images are scaled. It just relies on the image data and intrinsics.

Then about the decimate function. In the case that you're interested in the pose estimation capabilities, it does not make sense to reduce the resolution only for the quad detection that is then used for the pose estimation and still use the full resolution for decoding the binary payload.

It depends on your application of course. If there is only a single image consumer/subscriber then publishing at a lower resolution makes sense. But if there are multiple consumers, you force them all to use the lower resolution, even though a higher resolution would be possible. So this is entirely up to your setting and you cannot easily generalise this. Some people will only want to reduce the resolution for the AprilTag detection, some will want to have a lower resolution for their entire setup. In any case, you have to provide the corresponding intrinsics.

Maybe all this is not a big deal, but scaling the intrinsic camera parameters when the actual image resolution differs from the calibration resolution is even less problematic and makes the node more foolproof, isn't?

If the image source is publishing scaled images it also has to scale the intrinsics accordingly. It's not the responsibility of the receiver to figure out scaling and adapt the intrinsics. It is much more foolproof when the image data and correct intrinsics are published by the sender.

So, I reverted back the last changes with the automatic adjustment of the camera intrinsic parameters.
And also manged to do few simple tests. I ran a preview on the detected tags on live camera image.
As mentioned in the beginning, I'm using ROS2 Galactic on Ubuntu 20.04.5 LTS on virtual machine and for video capture I'm using a OAK-D camera from luxonis and the performance is rather bad. I'm using a HP ZBook 15 G2 with Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz with 4 of 8 threads and 6GB RAM assigned to the virtual machine.
Tags have 20 mm width, no decimation and no blur set for the AprilTag detector. I've tried with and without the more precise pose estimation, with 1 or 4 threads and at both 1280x720 and 960x540 image resolution. Results:

Settings
AprilTag
Image
Result

refine-pose
detector.threads
width
height

1
TRUE
1
1280

2
FALSE
1
1280

3
TRUE
4
1280

4
FALSE
4
1280

5
TRUE
1
960

6
FALSE
1
960

7
TRUE
4
960

8
FALSE
4
960

Unfortunately at that small frame rate it is not possible to say which algorithm is faster/slower. Also, it is rather strange, that there isn't really an improvement with 4 threads. Maybe running detection on image series will be much faster, but I cannot find a image publisher for ROS2 that also publishes camera info so I would have to write them by myself.
The better accuracy is clearly visible on the images by the naked eye, so I would say that there is no need for exact precision comparison. Here are the images in the same order as the table above:

Let me know if this is enough as a comparison.

I lost track of the actual problem since my last comment was from more than a month ago :-)
Can you clearly state what the problem with the node is? Could you show the actual results from the node and the standalone apriltag library and then state what the expected outcome would be?
What are you comparing here? Are those results on the same image with different estimation settings, different intrinsics or different implementations for the pose estimation? Where does the higher accuracy come from?

Can you clearly state what the problem with the node is?

The problem is that the more accurate pose estimation from the apriltag library is not implemented:
https://github.com/AprilRobotics/apriltag/wiki/AprilTag-User-Guide#pose-estimation
and that the current one performs poorly.

Could you show the actual results from the node [...]
The apriltag_ros node publish as a result of the detection a tf2_msgs/TFMessage that provides the translation and rotation of all the detected tags. This information is not very useful unless you know the actual translation and rotation of the tags. I could conduct such a test, but it would cost me much more time and much more documentation. Instead I'm using the information from the TFMessage to visualize each detected pose as rgb axes and a black cube frame for every tag on the images above. The apriltag_ros node publish as well the corners of the tags in a AprilTagDetection.msg. I'm using this information to visualize the tags' actual edges in yellow on the images above. Thus on every image you can see how well the detected pose of every tag fits on the tag itself.

[...] and the standalone apriltag library and then state what the expected outcome would be?
The standalone apriltag library initially doesn't give you the tag pose, it gives you just the homography which currently is being used in the apriltag_ros node to estimate the tag's pose:
https://github.com/christianrauch/apriltag_ros/blob/master/src/AprilTagNode.cpp#L64
But this estimation doesn't provide good results, but rather visibly bad pose estimations, check the 2nd, 4th, 6th and 8th images. For better results the standalone apriltag library provides the estimate_tag_pose function:
https://github.com/AprilRobotics/apriltag/wiki/AprilTag-User-Guide#pose-estimation
This is what I've added in the apriltag_ros node. It can be optionally used by setting the 'refine-pose' node parameter to true.

What are you comparing here? Are those results on the same image with different estimation settings, different intrinsics or different implementations for the pose estimation? Where does the higher accuracy come from?

I'm comparing the current pose estimation (refine-pose = FALSE, even images 2, 4, 6, 8) with the more accurate pose estimation from the standalone apriltag library (refine-pose = TRUE, odd images 1, 3, 5, 7). Those are not exactly the same images, as I was using live camera footage, but the differences are negligible. I've tested with different image resolution (respectively scaling the intrinsic parameters) and detector threads, but pairwise: eg. 1st & 2nd image have same settings, only different pose estimation is used. The same goes for 3rd & 4th, 5th & 6th, 7th & 8th. The higher accuracy comes from the different pose estimation.

Now I've tested it on a Raspberry 4 with 1 GB RAM and headless Ubuntu Server. The camera driver works much better so I got higher FPS and now it's clearly visible that the more precise pose estimation is a bit slower. At worse it is about 68 % slower.
I've also used a plain sheet of paper with different tags so that the advantage of the more precise pose estimation is much more obvious. Here again the results from the different test configurations:

| refine-pose | detector.threads | width | height | detections topic avg. hz
-- | -- | -- | -- | -- | --
1 | TRUE | 1 | 1280 | 720 | 3,1
2 | FALSE | 1 | 1280 | 720 | 3,7
3 | TRUE | 4 | 1280 | 720 | 3,4
4 | FALSE | 4 | 1280 | 720 | 3,8
5 | TRUE | 1 | 960 | 540 | 4,0
6 | FALSE | 1 | 960 | 540 | 6,7
7 | TRUE | 4 | 960 | 540 | 4,3
8 | FALSE | 4 | 960 | 540 | 6,6

And the corresponding tag preview images in the exact same order:

I still do not see which results correspond to the current baseline implementation on the master branch in this repo and what you implemented. If you want your improvements to be part of this repo, I suggest that you submit a PR with your changes and the "before" (baseline) and "after" results for comparison, probably with some parameter to switch to either estimation approach. I will be happy to review any improvements to this node :-)
It is hard for me to judge the improvements when I do not have a clear connection between the qualitative results that you show with the actual implementation that was used for the estimation (given the same homography) and also some runtime information.

It is true that I didn't compared against the actual master branch, but instead I just used the "old" estimation method that is implemented in the master branch and compared it against the "new" method recommended by the standalone apriltag library. So yes, there could be a slight chance that I messed up something. If this is what is bothering you, I will repeat the test.
Aside from that I have no idea at all why you don't understand/accept my comparison =)
My improvement does not change the homography result of the detection and I'm not using the homography information to do the comparison. The actual difference can be only seen in the tf2_msgs/TFMessage provided by both "old" and "new" method and more precisely in the pose rotation saved as geometry_msgs/Quaternion message. As a quaternion is not "human readable" (at least not for me), I'm expressing it as a reference system drawn on top of the corresponding tag and thus I'm visualizing the estimated orientation of the tag so you can use common sense to determine if the estimation is reasonable. This same visualization of the estimated orientation is repeated for both the "old" (even images 2, 4, 6, 8) and the "new" (odd images 1, 3, 5, 7) method.
If you want a more direct comparison, I can convert the quaternions to normals and calculate the misalignment (in degrees) of the tag's normal relative to the camera normal vector. Thus you can then compare the misalignment of the tags relative to camera normal using the "old" and the "new" methods and see that the old method has much bigger standard deviation, as there every tag is pointing in different direction. Only thing is, this is already clearly visible from the images above, so I'm really not sure, what kind of comparison you are expecting.
I have never performed a PR, so please don't be harsh on me =)
I also don't know what kind of runtime information do you need.

Aside from that I have no idea at all why you don't understand/accept my comparison =)

I simply do not see on which implementation you do your comparisons. You show results, but I don't see from which implementation they come from. Which of those images are results from apriltag_ros master branch (given which parameters) and which images are from your implementation (incl. parameters)? How would someone reproduce these results?

I'm not using the homography information to do the comparison

Don't you have to use the homography from the apriltag detection to estimate the 3D pose?

provided by both "old" and "new" method

Is the "old" method the one on my master branch? And the "new" method is the one you show the results for?

I'm expressing it as a reference system drawn on top of the corresponding tag and thus I'm visualizing the estimated orientation of the tag so you can use common sense to determine if the estimation is reasonable.
[...]
If you want a more direct comparison, I can convert the quaternions to normals and calculate the misalignment (in degrees) of the tag's normal relative to the camera normal vector.

This is not required. If you do not have ground truth for the tag poses to do a qualitative comparison, then the qualitative results with the rendered coordinate frames are totally fine. The only problem I have is that it is not clear which implementation generates which result.

Only thing is, this is already clearly visible from the images above, so I'm really not sure, what kind of comparison you are expecting.

So far, I only saw 8 images but without the information from which implementation they come from.

I have never performed a PR, so please don't be harsh on me =)

That's not a problem. Since you talked about your alternative implementation, I assumed that you wanted to contribute it back via a PR. That would mean that you commit your changes to a new branch in your repo and use the GitHub webinterface to send a pull request (PR) to this repo. I can then see the exact changes you propose and comment on. But if you opened this issue only to tell me that my baseline implementation provides poor results in some cases -- then yes, this is certainly possible but I don't have the time currently to look into alternative approaches.

I also don't know what kind of runtime information do you need.

It would be useful to know if an alternative approach works faster or slower than the current baseline (and by how much). If it is faster, we can replace the old method. If it is slower we probably want to give users a choice between the "accurate but slow" and the "fast but inaccurate" method.

Thank you for the clarification.

Aside from that I have no idea at all why you don't understand/accept my comparison =)

I simply do not see on which implementation you do your comparisons. You show results, but I don't see from which implementation they come from. Which of those images are results from apriltag_ros master branch (given which parameters) and which images are from your implementation (incl. parameters)? How would someone reproduce these results?

Unfortunately the new apriltag version 3.3 is still not released in the Galactic central ROS2 index, so the apriltag_ros master branch will still not work on my system. That is why I'm testing with a modified version of the master branch. Of course I'll provide the exact parameters, but I would say that they're not very interesting:
    "image_transport": "raw",
    "family": "16h5",
    "size": 0.02088,
    "max_hamming": 0,
    "z_up": False,
    "detector.decimate": 1.0,
    "detector.blur": 0.0,
    "detector.refine-edges": 0,
    "detector.threads": 1 or 4,
    "detector.debug": 0

provided by both "old" and "new" method

Is the "old" method the one on my master branch? And the "new" method is the one you show the results for?

Yes. Both methods are available for use at my branch by switching a parameter on/off:
https://github.com/MihailV1989/apriltag_ros
This is the branch I've used for testing. Unfortunately, as I mentioned in the beginning of this issue, I currently cannot use your branch without modifications as I get errors. I'll try to compile the newest AprilTag version 3.3 from source and see if I can get it up and running. Anyway I can and I have to implement the "new" method on a clean copy of the master branch without the bug fixing for getting round the version incompatibility. Then you could easily re-produce my results if you would have the time.

I also don't know what kind of runtime information do you need.

It would be useful to know if an alternative approach works faster or slower than the current baseline (and by how much). If it is faster, we can replace the old method. If it is slower we probably want to give users a choice between the "accurate but slow" and the "fast but inaccurate" method.

I've used the "ros2 topic hz" command to measure the publishing frequency of the "/apriltag/detections" topic and showed the results in my post above:
https://github.com/christianrauch/apriltag_ros/issues/11#issuecomment-1312856559
Isn't this what you need?

Unfortunately the new apriltag version 3.3 is still not released in the central ROS2 Galactic index, so the apriltag_ros master branch will still not work on my system.

Have you tried building the library and the node from source?

Yes. Both methods are available for use at my branch by switching a parameter on/off

Looking for the first time at the code now, I see that you essentially switch between the old and den new method via refine_pose / refine-pose. I guess this is an important piece of information when looking at your tables. Without making this explicit, it is not possible to see which method generates which result. It is much easier for me now to understand the results in the table.

Then you could easily re-produce my results if you would have the time.

If you manage to implement your changes on top of the master branch without modifications and send a PR for this, then I am happy to review and potentially merge your changes.

Isn't this what you need?

I think for benchmarking, it would be better to temporarily measure the time specifically for the "if (refine_pose) ... else" block since the frequency results on the topic also include the tag detection itself, which did not change between the old and the new method, and all the IPC overhead.
Btw, 3 Hz seems quite low. Did you build in Debug or release mode? On a modern PC, you should get much higher framereates.

The AprilTag ROS 2 node has been released to humble and rolling and you should be able to install the node from the official ROS 2 repos after the next sync.
@MihailV1989 Do you plan to submit a PR for your implementation of the estimation method provided with the apriltag library? I intend to close this issue soon as there is nothing wrong with the current implementation.

Yes, I think this feature will be useful not only to me. I just have to manage to run the image_publisher so I can use the same images for testing both pose estimations. I see you're now using the older apriltag 3.2, so it shouldn't be a problem to run your current ROS2 node version.

I have made the same experience. The computed pose is more accurate using the ROS1 node or the library function.
@MihailV1989 how far are you with the PR? I would be very happy if you provide your improvements. May I can help you!?

Duplicate of #14.


Turn off dry, verbose run of "send to many owners" tests?

I claim: if the "send to many owners" tests work for 20 owners, then they also work for 200 or 2000.
Given my extensive testing with owner numbers of 25000, and that the dry runs were intended for debug purposes, I suggest:

Turn them off. Currently each "send to many owners" test is run twice: once for printing output without stopping on error, and another time to actually test results.

Lower the number of owners to test.

What's your opinion on this, what are good numbers to test?
Context: foundation/omni/test/rpc/sto/MSCSendToManyOwnersSpec.groovy#L220-L236

Addressed by #56.


Use Lifecycle Scripts

This PR uses lifecycle scripts for shell-history and azure-cli-persistence, and fixes #12
Note: my (temporary) forked devcontainer feature contains these changes: https://github.com/joshuanianji/devcontainer-features/tree/main/src/azure-cli-persistence-forked

@stuartleeks Any chance to review this?


chore(main): release near.js 2.2.1

:robot: I have created a release beep boop
2.2.1 (2023-03-07)
Bug Fixes

gitignore (0af6a80)
remove cyclic import (a35807b)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/switchboard-xyz/sbv2-near/releases/tag/near.js-v2.2.1 :sunflower:


Spike to determine the scope of the issue of eager evaluation

Where and why do we perform eager evaluation?

As part of determining exports
To build code result cache (after a build message from the ts worker)

What problems does it actually cause?

Performance
Mutation via side effects:

a.js
export let A = 100

b.js
import { A } from './a'
A = 7777

app.js
/** @jsx jsx */
import * as React from 'react'
import { Scene, Storyboard, View, jsx } from 'utopia-api'
import { A } from './a'
export var App = (props) => {
  return (
    <View
      style={{ width: '100%', height: '100%', backgroundColor: '#FFFFFF' }}
      layout={{ layoutSystem: 'pinSystem' }}
    >
      {A}
    </View>
  )
}
export var storyboard = (
  <Storyboard layout={{ layoutSystem: 'pinSystem' }}>
    <Scene
      component={App}
      props={{}}
      style={{ position: 'absolute', left: 0, top: 0, width: 375, height: 812 }}
    />
  </Storyboard>
)

In app.js, the value of A should be 100, but is 7777

ReactDOM.render in an index.js - seems to only be an issue if trying to render to the 'editor' node
Exceptions thrown - we're wrapping in a try catch so shouldn't be an issue

Closing due to spike above.


Bug in Achived Hashmap

Ran into the following issue when attempting to serialize a Hashmap using to_bytes.
created a new `Panic` from: out of range integral type conversion attempted
stack backtrace:
   0: rust_begin_unwind
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/panicking.rs:665:5
   1: core::panicking::panic_fmt
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/panicking.rs:74:14
   2: <rancor::Panic as rancor::Source>::new
             at rancor-0.1.0/src/lib.rs:648:9
   3: <core::result::Result<T,E> as rancor::ResultExt<T,E>>::into_error
             at rancor-0.1.0/src/lib.rs:408:27
   4: <rend::i32_le as rkyv::rel_ptr::Offset>::from_isize
             at rkyv-0.8.8/src/rel_ptr.rs:76:44
   5: rkyv::rel_ptr::RawRelPtr<O>::try_emplace
             at rkyv-0.8.8/src/rel_ptr.rs:177:22
   6: rkyv::rel_ptr::RawRelPtr<O>::emplace
             at rkyv-0.8.8/src/rel_ptr.rs:191:9
   7: rkyv::collections::swiss_table::table::ArchivedHashTable<T>::resolve_from_len
             at rkyv-0.8.8/src/collections/swiss_table/table.rs:500:13
   8: rkyv::collections::swiss_table::map::ArchivedHashMap<K,V,H>::resolve_from_len
             at rkyv-0.8.8/src/collections/swiss_table/map.rs:238:9
   9: rkyv::impls::std::collections::hash_map::<impl rkyv::traits::Archive for std::collections::hash::map::HashMap<K,V,S>>::resolve
             at rkyv-0.8.8/src/impls/std/collections/hash_map.rs:24:9
  10: <rkyv::collections::util::EntryAdapter<BK,BV,K,V> as rkyv::traits::Archive>::resolve
             at rkyv-0.8.8/src/collections/util.rs:52:9
  11: rkyv::ser::writer::WriterExt::resolve_aligned
             at rkyv-0.8.8/src/ser/writer/mod.rs:134:9
  12: rkyv::collections::swiss_table::table::ArchivedHashTable<T>::serialize_from_iter::{{closure}}::{{closure}}::{{closure}}
             at rkyv-0.8.8/src/collections/swiss_table/table.rs:464:45
  13: rkyv::util::ser_vec::SerVec<T>::with_capacity
             at rkyv-0.8.8/src/util/ser_vec.rs:56:22
  14: rkyv::collections::swiss_table::table::ArchivedHashTable<T>::serialize_from_iter::{{closure}}::{{closure}}
             at rkyv-0.8.8/src/collections/swiss_table/table.rs:445:25
  15: rkyv::util::ser_vec::SerVec<T>::with_capacity
             at rkyv-0.8.8/src/util/ser_vec.rs:56:22
  16: rkyv::collections::swiss_table::table::ArchivedHashTable<T>::serialize_from_iter::{{closure}}
             at rkyv-0.8.8/src/collections/swiss_table/table.rs:379:17
  17: rkyv::util::ser_vec::SerVec<T>::with_capacity
             at rkyv-0.8.8/src/util/ser_vec.rs:56:22
  18: rkyv::collections::swiss_table::table::ArchivedHashTable<T>::serialize_from_iter
             at rkyv-0.8.8/src/collections/swiss_table/table.rs:369:9
  19: rkyv::collections::swiss_table::map::ArchivedHashMap<K,V,H>::serialize_from_iter
             at rkyv-0.8.8/src/collections/swiss_table/map.rs:220:9
  20: rkyv::impls::std::collections::hash_map::<impl rkyv::traits::Serialize<S> for std::collections::hash::map::HashMap<K,V,RandomState>>::serialize
             at rkyv-0.8.8/src/impls/std/collections/hash_map.rs:40:9

Using rkyv 0.8.8

By default, rkyv is configured to only support up to 2 gigabyte files. To support larger files, enable the pointer_width_64 feature. This will come at the cost of slightly larger encoded pointers.

Closing this issue since it seems like your issue was resolved. Re-open if that wasn't the case.


[FLINK-16730][docs] Python SDK Getting Started

Note: This should not be merged until after #67 because I used the updated locations for my links.

I guess we'll postpone the merge / review of this until #73 is merged.

Yes, I'll rebase and port this after #73


No such module error popping up on XCode 7 using Swift

I have done as outlined in the readme to get GPUImage available as a module for my project using Swift. At first the app did not throw an error about the module not existing but after quitting and restarting XCode it started to complain that the module did not exist. I then started a brand new project and did as outlined again by doing the following:

but I still get this:

Any other ideas on what I can do to keep this error from popping up in the future?

I also can recreate the issue by loading any of the swift examples and doing a project Clean. Any way to keep the module going after cleaning?

What I ended up doing is just selecting the Framework and telling it to Build like so

And then switched back to my main app target and things are able to run again. Good enough for now


fix(consensus): validate pledges are correct payload

Currently replicas vote Accept even if a shard is pledged to a different payload:

In this case, the first and third shards are pledged to 4de...

With this PR, the nodes reject the payload for the right reason, but they still seem to go all the way to Decide. (WIP: Not sure why yet)

Ah ok found the issue, pledge_object returns an existing pledge but was not predicated on the payload - will PR a fix quick


MetadataHelper should force string and do some basic string replacement (html decode)

When I play Artist Adele, Album 19 from Music library the following code (end also the full AVTransport service code):
coordinator.Events.on(SonosEvents.CurrentTrackMetadata, (data) => {
      console.log('Current track metadata %s', JSON.stringify(data, null, 2))
})

produces an "Album" property of type number - see console.log:
Current track metadata
{
  "Album":19,
  "Artist":"Adele",
  "AlbumArtUri":"http://<IP_ADDRESS>:1400/getaa?u=x-file-cifs:%2f%2fnas2019%2fMultimedia%2fMusic%2fMyMusic%2fAdele%2f19%2fAdele%20-%20Right%20as%20Rain.mp3&v=35",
  "Title":"Right as Rain",
  "UpnpClass":"object.item.audioItem.musicTrack",
  "Duration":"0:03:17",
  "ItemId":"-1",
  "ParentId":"-1",
  "TrackUri":"x-file-cifs://nas2019/Multimedia/Music/MyMusic/Adele/19/Adele - Right as Rain.mp3",
  "ProtocolInfo":"x-file-cifs:*:audio/mpeg:*"
}

In addition it would be good if you could decode Album, Title, etc. Currently I do it with:
decodeHtml: (htmlData) => {
    debug('method >>%s', 'decodeHtml')
    const decoded = String(htmlData).replace(/<|>|&|'|"/g, (substring) => {
      switch (substring) {
      case '<': return '<'
      case '>': return '>'
      case '&': return '&'
      case ''': return '`'
      case '"': return '"'
      }
    })

    return decoded
  },

You see the work around - using String to convert the number to string. Without that it throws error "replace is not a function" as 19 is number.
Wish you a Merry Christmas, Happy New Year.
Keep healthy!

This bug is related to the MetaDataHelper for anyone who want to give it a go. Probably an easy fix.

@hklages I did something wrong with the git branch, so the above version is actually 2.3.0-beta.1 I changed the metadata helper it should now always return a string and do some html decoding.
can you check if this version solves the Adele 19 issue and the &pos; in titles?

I could only install 2.2.0-beta.7.
Album  with numbers return now string so Adele album 19 is ok.
Decoding remains a problem.
{"Album":"Bob Dylan's Greatest Hits","Artist":"Bob Dylan","AlbumArtUri":"http://<IP_ADDRESS>:1400/getaa?s=1&u=x-sonosapi-hls-static:catalog%2Ftracks%2FB00GQW0DA8%2F%3Fsid%3D201%26flags%3D0%26sn%3D19","Title":"Blowin' in the Wind","UpnpClass":"object.item.audioItem.musicTrack","Duration":"0:02:47","ItemId":"-1","ParentId":"-1","TrackUri":"x-sonosapi-hls-static:catalog/tracks/B00GQW0DA8/?sid=201&flags=0&sn=19","ProtocolInfo":"sonos.com-http::application/x-mpegURL:"}


fix(ctrl): use builtin command kill

The builder Pods may not have a /bin/kill command, but do have a builtin shell kill command available.


conda-forge is broken

https://github.com/conda-forge/pyfolio-feedstock/pull/1
Related: https://github.com/quantopian/pyfolio/issues/560
/home/conda/feedstock_root/build_artifacts/pyfolio_1533248344668/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_/lib/python3.6/importlib/_bootstrap.py:219: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
  return f(*args, **kwds)
Traceback (most recent call last):
  File "/home/conda/feedstock_root/build_artifacts/pyfolio_1533248344668/test_tmp/run_test.py", line 2, in <module>
    import pyfolio
  File "/home/conda/feedstock_root/build_artifacts/pyfolio_1533248344668/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_/lib/python3.6/site-packages/pyfolio/__init__.py", line 3, in <module>
    from . import utils
  File "/home/conda/feedstock_root/build_artifacts/pyfolio_1533248344668/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_/lib/python3.6/site-packages/pyfolio/utils.py", line 26, in <module>
    import empyrical.utils
  File "/home/conda/feedstock_root/build_artifacts/pyfolio_1533248344668/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_/lib/python3.6/site-packages/empyrical/__init__.py", line 21, in <module>
    from .stats import (
  File "/home/conda/feedstock_root/build_artifacts/pyfolio_1533248344668/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_/lib/python3.6/site-packages/empyrical/stats.py", line 23, in <module>
    from .utils import nanmean, nanstd, nanmin, up, down, roll
  File "/home/conda/feedstock_root/build_artifacts/pyfolio_1533248344668/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_/lib/python3.6/site-packages/empyrical/utils.py", line 25, in <module>
    from pandas_datareader import data as web
  File "/home/conda/feedstock_root/build_artifacts/pyfolio_1533248344668/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_/lib/python3.6/site-packages/pandas_datareader/__init__.py", line 2, in <module>
    from .data import (DataReader, Options, get_components_yahoo,
  File "/home/conda/feedstock_root/build_artifacts/pyfolio_1533248344668/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_/lib/python3.6/site-packages/pandas_datareader/data.py", line 14, in <module>
    from pandas_datareader.fred import FredReader
  File "/home/conda/feedstock_root/build_artifacts/pyfolio_1533248344668/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_/lib/python3.6/site-packages/pandas_datareader/fred.py", line 1, in <module>
    from pandas.core.common import is_list_like
ImportError: cannot import name 'is_list_like'
Tests failed for pyfolio-0.9.0-py_0.tar.bz2 - moving package to /home/conda/feedstock_root/build_artifacts/broken
WARNING:conda_build.build:Tests failed for pyfolio-0.9.0-py_0.tar.bz2 - moving package to /home/conda/feedstock_root/build_artifacts/broken
removing: pyfolio-0.9.0-py_0.tar.bz2
TESTS FAILED: pyfolio-0.9.0-py_0.tar.bz2
Exited with code 1

Looks like another pandas incompatibility.


krun issue

While running krun on Mac OSX it fails when you are trying to run a test from a location where it's path contains a ' ' because Maude can't locate the file (probably because the ' 'character is not escaped).

Fixed in K 3.5.2.