Good First Issues in C++

提案类型 新增文章 主题简介 嵌入式那几篇文章我不太喜欢，觉得讲的很烂，需要进一步的改进，刚好出版社的一位大佬寄送我一本《嵌入式C++》的书，翻一翻帮忙参考咯！ 目标读者 No response 建议放置位置 No response 建议结构 No response 参考资料 No response 你是否计划提交 PR 是，我准备投稿 投稿说明 我理解维护者可能会调整文章标题、格式、放置位置和部分措辞。 如果文章引用外部资料，我会尽量提供来源链接。 如果文章包含图片或代码，我会说明来源或授权情况。

提案类型 新增文章 主题简介 添加一个最迷你的mini stl作为对数据结构的进阶理解~，刚好我最近也想重新修订一下这块的笔记了。以及顺手联动一下chrominum的base library! 目标读者 No response 建议放置位置 No response 建议结构 No response 参考资料 No response 你是否计划提交 PR 是，我准备投稿 投稿说明 我理解维护者可能会调整文章标题、格式、放置位置和部分措辞。 如果文章引用外部资料，我会尽量提供来源链接。 如果文章包含图片或代码，我会说明来源或授权情况。

Request preparation I used an AI assistant to help structure this request I checked for existing issues covering the same feature What would you like? Feature request: Allow hiding the decoded RTTY text panel Title: Allow the decoded-RTTY text panel to be hidden/disabled independently Type: Feature request Body: Problem: When RTTY mode is active, AetherSDR displays a decoded-text panel in the UI. For operators who use a third-party RTTY decoder instead (e.g. SDR Console's Digital Decoder), this panel takes up screen space and visually overlaps with the third-party decoder's own window, even when AetherSDR's own decoding isn't being used. Requested change: Add a setting (or a right-click/context-menu option on the panel itself) to hide or disable the decoded-RTTY text panel independently of RTTY mode itself — similar to how other applets/panels in AetherSDR can already be toggled or floated. This would let operators keep RTTY mode active for band/filter purposes while relying on a

Two gaps in Apple support, one small and one large. Both are open to contributors, and both need a measurement, not just code. 1. macOS never bypasses the page cache core/src/io/platform_io.cpp defines O_DIRECT to 0 when the platform lacks it, which on Apple means open_read(..., direct=true) silently returns an ordinary buffered descriptor. The equivalent there is fcntl(fd, F_NOCACHE, 1) after the open, and it is never called. So on a Mac the expert stream reads through the page cache, which is precisely what the design exists to avoid. Second half of the same problem: the o_direct metrics field is filled from the requested configuration, so a macOS run reports o_direct=1 while running buffered. The field should record what the open actually achieved, on every platform. That half is worth fixing on its own, even if nobody touches the macOS path. What a PR needs F_NOCACHE applied on Apple where O_DIRECT would be used elsewhere, without disturbing the Linux, Android or Windows paths. o_

Summary In-game logo is still using the old logo asset Should be using the new logo Requirements Replace old logo sprite with new logo sprite Examples / References Logo with text + outline

Request preparation I used an AI assistant to help structure this request I checked for existing issues covering the same feature What would you like? Title Change Band Plan text formatting to non-bold font weight What Change the font styling used for region/frequency segment labels in the Band Plan overlay (rendered within SpectrumWidget / PanadapterOverlay) from bold (QFont::Bold / QFont::Weight::Bold) to a normal or light weight font. Why The current bold font weight used for rendering segment annotations across the spectrum overlay can appear heavy, overly dense, and "fat"—especially on higher DPI screens or tight frequency spans where multiple band plan segment labels overlap or cluster together. Using a regular/non-bold font weight significantly improves readability and text legibility without visually cluttering the spectrum display. How Other Clients Do It SmartSDR (FlexRadio Native): Displays band plan region labels in a clean, non-bold, light-sans typography directly o

I suggest adapting DPsim GFL models to represent control and electrical filter structure of some well-known and well-accepted generic average value model (for example from https://doi.org/10.1109/TPEL.2012.2199334). The key issues right now: GFL control structure in DPsim misses cross-decoupling term. Filter circuit includes "coupling resistor" and some of the GFL models also include optional step-up transformer. This complicates automated steady-state initialization from power flow, because inverter controls the power at the filter capacitor node. If we set the same power for PQ bus in power flow and as reference power for inverter, it will not start in steady state due to losses on coupling resistor and optional transformer. The power differences between power flow settings and time-domain simulation settings now have to be handled manually. I suggest adding cross-decoupling term and removing coupling resistor and optional step-up transformer. This will break many existing example

All the numbers in the README come from one phone and one laptop. That's the honest limit of what we can claim, and it's why we're asking. The engine streams a MoE model's experts from flash so a model larger than RAM runs on the device. What we'd like to know is what that does on storage and CPUs we don't have: a mini PC with an NVMe drive, an ARM board with a PCIe slot, a Mac, a desktop with a lot of unified memory, a phone other than ours. Anything works, really. The open question is whether a real NVMe queue makes the flash stall we see on UFS go away, but every machine adds a data point. Any MoE the engine supports, in whatever quant you already have. Paste the result into a benchmark report and the row goes into docs/community-benchmarks.md with your name. On a PC or laptop (Linux, macOS) One command, about ten minutes after the model download: git clone --recursive https://github.com/Helldez/BigMoeOnEdge.git cd BigMoeOnEdge scripts/bench-report.sh /path/to/any-moe-model.gguf It

I hesitate to mark this as a bug but it is a usability issue. It's unclear whether the quit button quits the menu or the game. I was play testing and pressed it and found myself outside. It took me a minute to figure out this wasn't a crash. Possible fixes: Mark this as quit game and add a confirm dialog Remove the button

It is hard to type degrees/minutes/seconds characters from the phone's keyboard. Looks like other applications accept a space instead of the "special character" and are smart enough to recognize the coordinate pattern from that. For example: "37 00 27.73 N 08 56 41.59 W" (Roundabout in Sagres, Portugal) OpenStreetMap Google Maps OsmAnd Guru Maps

Description When deleting a workspace or account, the user is required to type the account name to confirm deletion. If the user cancels the dialog and reopens it later, the confirmation input field still contains the previously typed name instead of being empty. Environment Staging Application (+ app version, build, operating system) Mergin Maps Mobile App Android: 2026.3.2 / Samsung Galaxy A53 5G, Android 16 iOS: 2026.3.2 / iOS 26.0 Steps to reproduce Open account settings Tap Close account Type the account name in the confirmation input Tap Cancel (do not confirm deletion) Reopen the delete dialog Actual results The confirmation input field still contains the name entered in step 3. Expected results The confirmation input field should be empty each time the delete dialog is opened. Conclusion Created by Claude and supervised by a human test analyst.

This issue covers resolving the cppcoreguidelines-pro-type-const-cast warnings. clang-tidy warnings (click to expand) File Line Message opentelemetry-cpp/examples/http/server.cc 55 do not use const_cast to remove const qualifier opentelemetry-cpp/ext/include/opentelemetry/ext/http/client/curl/http_operation_curl.h 297 do not use const_cast to remove const qualifier opentelemetry-cpp/ext/src/http/client/curl/http_operation_curl.cc 915 do not use const_cast to remove const qualifier opentelemetry-cpp/ext/src/http/client/curl/http_operation_curl.cc 957 do not use const_cast to remove const qualifier opentelemetry-cpp/ext/src/http/client/curl/http_operation_curl.cc 1005 do not use const_cast to remove const qualifier opentelemetry-cpp/ext/test/w3c_tracecontext_http_test_server/main.cc 206 do not use const_cast to remove const qualifier opentelemetry-cpp/sdk/include/opentelemetry/sdk/common/circular_buffer.h 43 do not use const_cast to remove const qualifier opentelemet

This issue covers resolving the 20 modernize-use-emplace warnings: clang-tidy warnings (click to expand) File Line Message opentelemetry-cpp/api/test/baggage/propagation/baggage_propagator_test.cc 90 use emplace_back instead of push_back opentelemetry-cpp/api/test/context/propagation/composite_propagator_test.cc 145 use emplace_back instead of push_back opentelemetry-cpp/api/test/context/runtime_context_test.cc 127 use emplace_back instead of push_back opentelemetry-cpp/api/test/nostd/shared_ptr_test.cc 224 use emplace_back instead of push_back opentelemetry-cpp/api/test/trace/propagation/http_text_format_test.cc 265 use emplace_back instead of push_back opentelemetry-cpp/api/test/trace/propagation/jaeger_propagation_test.cc 194 use emplace_back instead of push_back opentelemetry-cpp/examples/multithreaded/main.cc 63 use emplace_back instead of push_back opentelemetry-cpp/exporters/otlp/src/otlp_file_client.cc 568 use emplace_back instead of push_back opentelemet

Describe the bug I noticed in this home improvement store that there was a window with no curtains from which someone could look into the bathroom. Also the window is between the bathroom, the office, and outside, which is sort of confusing. Screenshot is included in this issue. Attach save file Cass Lake-trimmed.tar.gz Steps to reproduce Go to one of the home improvement stores (not the superstore) and go to the bathroom to view the window. It is possible to find and teleport to a home improvement store in the debug menu, by selecting map and overmap editor, revealing enough of the map to find a home improvement store, and teleporting to it. Expected behavior I'd expect there to not be a window between the office, bathroom, and outdoors? Maybe the window was supposed to be an office window right next to the other. If the bathroom was supposed to have a window, it seems odd to me that there are no curtains or anything so anyone could just see in. I suppose it's conceivable that the til

Problem description Misusing lofts can result in the "Segments of a loft do not have sufficient separation" message which is better than a generic error (or crash as in the past) but could directly mention the incriminated profiles. Workbench affected? Part Design Steps to reproduce Create two sketches A and B with geometry that can be lofted between (e.g. a circle on each) Create an additive loft with A as a profile and both A and B as sections; A being used twice is intentional Expected behavior An error message that obviously points to the coincident/referred-twice sketches, e.g. "AdditiveLoft001: Segment A cannot be used both as profile and first segment" and "AdditiveLoft001: Segments B and C do not have sufficient separation" Actual behavior Fixed "Segments of a loft do not have sufficient separation" message with no details Development version About Info (in Safe Mode) OS: Void Linux (KDE/wayland) Architecture: x86_64 Version: 26.3.0dev.20260819 (Git shallow) AppImage Build d

Found this with an LLM. I don't think any current scripts exercise this, so it's just a correctness bug in an extremely specific scenario. The following crashes with a OOB heap write: event zeek_init() { local v: vector of count; v[4294967295] = 1; print |v|; } That's from VectorVal::Assign resizing te index + 1. Seems like that overflows. Then, Claude also says that the AddHoles(index - n) performs a narrowing conversion on it (to int, so -1). Basically just a weird set of coincidences. A minimal fix would just add a check to VectorVal::Assign (GPT-5.5 suggested patch): bool VectorVal::Assign(unsigned int index, ValPtr element) { if ( ! CheckElementType(element) ) return false; unsigned int n = vector_val.size(); + if ( index == std::numeric_limits<unsigned int>::max() ) + reporter->RuntimeError(GetLocationInfo(), "vector index too large"); if ( index >= n ) { if ( index > n ) AddHoles(index - n); vector_val.

This is an unordered list of things that didn't go as expected when (start to) work(ing) with Parthenon and downstream codes as part of the 2026 user meeting. It's meant as a loose collection that will eventually be used to inform future changes/developments/updated doc. Nothing is too small/simple to report!

Reported by @sims1253 for bernoulli_logit_lpmf here and bernoulli_logit_glm_lpmf here. Here are some tests that would fail if inserted into math/test/unit/math/mix/prob/bernoulli_logit_glm_lpmf_test.cpp Line 4 in 344d716 TEST_F(AgradRev, mathMixScalFun_bernoulli_logit_glm_lpmf) { // internal cutoff for extreme values const double cutoff = 20; Eigen::MatrixXd x_one(1, 1); x_one << 1.0; Eigen::Matrix<double, Eigen::Dynamic, 1> beta_one(1, 1); beta_one << (cutoff + 5); stan::test::ad_tolerances tols; tols.gradient_grad_ = 1e-6; stan::test::expect_ad(tols, f(0), x_one, 0.0, beta_one); stan::test::expect_ad(tols, f(1), x_one, 0.0, beta_one); stan::test::expect_ad(tols, f(2), x_one, 0.0, beta_one); Eigen::Matrix<double, Eigen::Dynamic, 1> beta_flipped = beta * -1; stan::test::expect_ad(tols, f(0), x_one, 0.0, beta_flipped); stan::test::expect_ad(to

As stated in the title. This is another extremely annoying autopilot behavior that we need to fix. It makes no sense why the autopilot would need to do this.

As of 0.10.x, the autopilot is buggier than ever. Now when you start anywhere near a planet, station, or jump; target another planet, station, or jump; and turn on the autopilot to start traveling there, the autopilot consistently steers away from the target, for no reason that I can determine. It continues to head in a different direction for several minutes -- far longer than it should. Finally, it will eventually start heading towards the target. This behavior is extremely annoying, and it never used to happen in older versions. We need to get this fixed as a matter of priority.

Description of the bug: Testcase let {b}; builds a malformed parse tree, resulting in a crash. It also doesn't produce any diagnostic message, despite being syntactically invalid. What did you do, or what's a simple way to reproduce the bug? let {b}; What did you expect to happen? A diagnostic should be produced for the invalid pattern. A well-formed parse tree (including nodes marked as invalid or InvalidParse nodes as appropriate) should be produced. What actually happened? An IdentifierNameExpr parse node was produced for the b token, which doesn't match the expected shape for a StructPattern node. This leads to a CHECK-failure since the parse tree is malformed: 3. Filename: - 4. Parser stack: cursor position_ @ 1:12: token token8 : FileEnd #0 0x0000556bab27561b llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) external/+llvm_project+llvm-project/llvm/lib/Support/Unix/Signals.inc:935:8 #1 0x0000556bab275ba8 PrintStackTraceSignalHandler(void*) external/+llvm_pr

A phrase is a list of words plus a rule at each junction saying where the next word may sit. This issue is about adding rules we cannot write yet. Everything below uses the same query, the words quick brown fox, against these four documents: A quick brown fox B quick brown little fox C quick and very brown fox D brown quick fox plain phrase yes no no no "quick brown 1-3 fox" yes yes no no maxwidth 4 yes yes no, it is 5 wide no, wrong order maxgaps 1 yes yes no, two extra words no, wrong order What we can write today Next to it. "quick brown fox". Matches A only. Exactly N apart. "quick brown 2-2 fox". One word between brown and fox, whatever it is. Somewhere in a range. "quick brown 1-3 fox". Fox lands one to three words after brown. Matches A and B. Slop. A budget for the whole phrase. All three words still have to be there, but they may be spread out or come in the wrong order, and each move costs. With slop 3 the query also matches D, where brown and quick are swapp

For example, in prim/fun/square.hpp. Note that some care must be taken to avoid changing the rounding behavior by casting the input before multiplying With default toolchain settings (gcc/clang default to -fmath-errno), std::pow must set errno on domain/range/overflow errors, so the optimizer cannot rewrite it to a multiply in general. glibc's pow is a branchy multi-path implementation where x * x is one instruction. Originally posted by @sims1253 in #3368

DESCRIPTION On my fresh installed hybrid system with HM200.2 and wlw-7 mb ar I don't get valued für compressor output power and compressor speed. They always show zero REQUESTED INFORMATION Provide the System information in the area below, taken from http://<IP>/api/system {"system":{"version":"3.9.0-dev.4","uptime":"000+00:34:51.618","uptimeSec":2091,"resetReason":"Software reset CPU / Software reset CPU","platform":"ESP32","cpuType":"ESP32-D0WD-V3","arduino":"Tasmota Arduino v3.3.8","sdk":"5.5.4.260407","freeMem":173,"maxAlloc":108,"minFree":155,"freeCaps":4146,"usedApp":1973,"freeApp":2699,"partition":"app1","flash_chip_size":16384,"psram":true,"psramSize":4096,"freePsram":4025,"model":"BBQKees Electronics E32V2.2 rev.2.2/2026012","txpause":false,"gpios_allowed":"2, 4, 5, 14, 32, 34, 36, 39","gpios_in_use":"2, 4, 5, 14, 32, 34, 36, 39","gpios_available":""},"network":{"network":"WiFi","hostname":"ems-esp","RSSI":-49,"WIFIReconnects":0,"BSSID":"set","TxPowerSetting":0,"staticIP

Request preparation I used an AI assistant to help structure this request I checked for existing issues covering the same feature What would you like? Filing this as a tester report since the release notes asked for radio and firmware details from people running the experimental Icom backend. There don't appear to be many IC-9700 reports yet. Setup Radio: Icom IC-9700, firmware 1.42 AetherSDR v26.8.4, Windows 11, laptop Connection: radio's rear LAN port to a router, DHCP, radio at 10.0.0.17, laptop on the same subnet Configured in ASDR CI-V address field left blank so the auto-detect from #4991 does the work What works Connected first try after the radio-side setup was right. Confirmed on 146.520 FM: Frequency and mode read correctly and follow the radio Panadapter and waterfall both live, including the 3D view S-meter tracking RX Controls shows repeater tone (103.5), offset (0.600 MHz), and Simplex/XFC — the tone/duplex work from #5140 is reaching the radio correctly Status b

Problem description Bit annoying that no shortcut key mapped popup alert that restrictly require only MOUSE CLICK to avoid the alert situation. Workbench affected? None Steps to reproduce Open or Create any file any contents bit. Try to close the FreeCAD app by clicking 'X' buttom right upper corner. The popup shows to recomment to save/discard/cancel without no shortcut infomation "Save(S) / Discard(D) / Cancel(C)" It is the popup that need to improve. Expected behavior By pressing key 'Y' or 'N' or 'C' (which means OS standard shortcut) are usual shortcut mapping for Yes / No / Cancel. But Freecad takes 'Save/Discard/Cancel' so change label and set/map the standard shortcut or map shortcut display standard that S / D / C as "Save(S) / Discard(D) / Cancel(C)" that intuitivly gives/control next action. In anyway will helps. Actual behavior To close the popup, the only way is mouse click that lead, big, hand and arm movement. Development version About Info (in Safe Mode) OS: Windows

Terms I have searched all open bug reports I agree to follow Scribe-Android's Code of Conduct Behavior As discussed here and on Matrix, the current version of the keyboard on main has a vertical stretch that's making the UI not as usable. See the screenshot below: This issue would investigate what's causing it and devise a fix. Device type Phones and tablets Versions Current main

Configuration of General Attribute Limits Background: The configuration schema includes a general attribute_limits element at the same level as the signal providers. This element defines limits for attribute count and length that should be used by the tracer and logger provider if their limits elements are not configured. attribute_limits: $ref: "#/$defs/AttributeLimits" description: | Configure general attribute limits. See also tracer_provider.limits, logger_provider.limits. The YAML parser supports attribute_limits, but the SdkBuilder currently does not pass them into the builders for the Tracer and Logger providers. As a result these values are ignored. See: opentelemetry-cpp/sdk/src/configuration/sdk_builder.cc Line 2641 in b603742 OTEL_INTERNAL_LOG_WARN("attribute_limits not supported, ignoring"); The spec requires the following limit behavior: If bot

well...tried to play test but something is up with my system at the moment as while the mouse works while on base (Atlantis) as soon as I launch I have zero controls. Tried another branch too so I know it's not simply this work. Based on the code though I do think you're okay so once some others confirm we can merge. Originally posted by @BenjamenMeyer in #1683 (comment)