Editor: AnimationTree node font color is black

Godot version
v4.2.dev5.official [e3e2528ba]
System information
Linux Ubuntu 22.04, GeForce 1060
Issue description
Node labels in AnimationTree editor are black and thus unreadable, for default (dark theme).

Same for a Light theme

Didn't happen before (in v4.2.dev4)
Steps to reproduce
AnimationTree editor, with  root nodes, dark theme.
Minimal reproduction project
N/A, just editor

IIRC nuking the shader cache helped with an extremely similar issue someone else had.

IIRC nuking the shader cache helped with an extremely similar issue someone else had.

Alas, removal of  /home/me/.local/share/godot/shader_cache/ doesn't fix.
And 4.2.dev4 side-by-side still works


Unexpected union results

The following union works as expected:
define Foo3: { 1 } union { 1.0 }

returning { 1, 1.0 }
However, this oddly results in a null?
define Foo2: { 1, 'hi', true } union { 1.0, true }

I expected { 1, 'hi', true, 1.0 } but I get { 1, 'hi', true, null }?

Appears that this may be a bug in the CQL Language Server rather than the CQL Runtime. IOW, they underlying value appears to be correctly computed, but it's serialized incorrectly.


Two places for Footer Text Color

What is the difference, or does one override the other?

(see top and bottom entry in screenshot)

Good catch. I couldn't get the header text color to work consistently so I dropped that and added a footer option instead. Will remove the header text reference.

Good catch! Actually a copy and paste error -- the top one is the wide subscribe box text color. Will fix in the next update.

This will be fixed in the next release.


RFP-1:  Bitcoin Integration

Overview
The pre-release of the Bitcoin integration recently went live on the Internet Computer. This allows canisters to hold native BTC and sign Bitcoin transactions via threshold ECDSA. Furthermore, the Internet Computer keeps track of the Bitcoin state, i.e. the current set of unspent transaction outputs (UTXOs), and makes it available to canisters with a new API.
Areas for Proposals
Novel applications and infrastructure
Wallets
The Bitcoin integration opens a wide design space for on-chain and hybrid wallets. Here are a few examples:

Simple on-chain Bitcoin wallet with Internet Identity authentication
Programmable wallets that may act autonomously
Integration into existing Bitcoin wallets, e.g. as a secure second signature provider or recovery option

Tapping into Bitcoin Liquidity for DeFi
The Bitcoin integration allows DeFi protocols and applications on the Internet Computer to directly tap into Bitcoin liquidity.
Protocols  and applications of interest are in particular:

Decentralized exchanges based on automated markets makers and order books
Lending protocols and stablecoins

Your unique idea
Of course, we are also excited to support you in the implementation of novel use cases that we haven't thought of.
Libraries and Tooling
The Bitcoin integration provides a rather low-level API to interact with UTXOs and sign transactions. We are looking for libraries and abstractions to be used in Motoko and Rust canisters to simplify development and increase developer experience.
Tutorials and well-documented Sample Applications
Tutorials in written and/or video form as well as well-documented example applications help new developers get started.
How to apply?
Please submit your application at https://dfinity.org/grants
References

Bitcoin Integration Overview
Internet Computer Wiki article
Developer docs
Sample app
Bitcoin API

Replaced by #58


Better store modules management and structure

Description
The modules in vuex store is very important for this library because - 1) The actions are the public APIs for developers, and 2) We want to make the code easy to understand for developers customizing the components on their own. To achieve these goals, following improvements can be made:
Tasks

[ ] Slice the cosmos.js module into individual modules responsible for different category of tasks
[x] (?) Flatten the namespaces of the modules to make the API cleaner

Hey @fadeev , do you have any suggestions for organizing bank and module modules in ui/develop branch?
For bank module, we can either extract the part related to account matters into a account module, or keeping them together with a better name.
About module module, my intention was to keep everything related to customized types here; does this make sense? If it does, I'm sure a better naming for this module is required too.
Or if there's any better ways to organize the modules, let me know!

Ideally, Vuex store API and structure should resemble the blockchain's API.

Ideally, Vuex store API and structure should resemble the blockchain's API.

You mean like Cosmos and Tendermint RPC REST endpoints? If so, would modules with namespaces make more sense? For example, cosmos/txs/{hash}.

I was thinking more gRPC. Not a fan of v1beta1, and we need first to build gRPC for JS to actually see the API.

I see. Hmmm I guess it's true that v1beta1 is not very friendly for devs like me to use, but following the pattern of which should be fine for our purpose here?

@vince19972 to figure this out I suggest we try using gRPC from JS even before CosmJS, for example by decoding the data from WebSockets.

Mapping vuex store modules's data structure with proto files is a bigger scale task to work on. We can create another issue to discuss the topic.


Semantic router does not work with latest versions of Cohere

When I upgraded to the latest Semantic Router version in my project, I got the following error:
  File "/src/app/src/main.py", line 10, in <module>
    from semantic_router.encoders import HuggingFaceEncoder
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/src/app/.venv/lib/python3.11/site-packages/semantic_router/__init__.py", line 1, in <module>
    from semantic_router.hybrid_layer import HybridRouteLayer
  File "/src/app/.venv/lib/python3.11/site-packages/semantic_router/hybrid_layer.py", line 6, in <module>
    from semantic_router.encoders import (
  File "/src/app/.venv/lib/python3.11/site-packages/semantic_router/encoders/__init__.py", line 7, in <module>
    from semantic_router.encoders.cohere import CohereEncoder
  File "/src/app/.venv/lib/python3.11/site-packages/semantic_router/encoders/cohere.py", line 5, in <module>
    from cohere.types.embed_response import EmbedResponse_EmbeddingsByType
ImportError: cannot import name 'EmbedResponse_EmbeddingsByType' from 'cohere.types.embed_response' (/src/app/.venv/lib/python3.11/site-packages/cohere/types/embed_response.py)

When I looked at cohere.types.embed_response in cohere 5.11.0, there is no EmbedResponse_EmbeddingsByType- it seems to have been one-to-one replaced by EmbeddingsByTypeEmbedResponse.

@marygriffus this should be resolved with SR 0.0.68, we saw this issue initially with #422 and made the changes. Could you confirm you have 0.0.68?

Apologies, was on 0.0.66, can close this!


Adding more explanation about the dependencies for ESM version with webpack

I see number of issues related to this and I felt this is matter of documentation.
So I am making a pull request for the vue-monaco community.

Closing it because it seems like noone interested in.


Add unittests for json schemas

CLOUDBLD-7880
Signed-off-by: mkosiarc<EMAIL_ADDRESS>Maintainers will complete the following section

[ ] Commit messages are descriptive enough
[ ] Code coverage from testing does not decrease and new code is covered
[ ] JSON/YAML configuration changes are updated in the relevant schema
[ ] Changes to metadata also update the documentation for the metadata
[ ] Pull request has a link to an osbs-docs PR for user documentation updates
[ ] New feature can be disabled from a configuration file

Other schemas are covered in other places, sometimes as parts of testing the whole plugins - uniting those all in one file would take more effort. And I am also interested in your opinion on those cases I commented with "TODO should this fail?"


Prepare PauliEvolutionGate for Rustiq & port it to Rust

Summary
Port the PauliEvolutionGate synthesis to Rust, plus, expose the Pauli network and allow other plugins to synthesize the gate. Also adds the plugin structure for the gate for #12789.
Details and comments
The larger the Pauli network to synthesis, the better the speedup from the port to Rust. Here I measured a Heisenberg Hamiltonian (XX+YY+ZZ on interacting qubits, plus 1-qubit Z on each qubit) on a square lattice for different settings:

1 timestep for first order Trotter: speedup @ 100 qubits is 2.8
N=25: 7.0
main: 0.007 +- 0.006
this: 0.001 +- 0.000

N=100: 2.8
main: 0.042 +- 0.000
this: 0.015 +- 0.000

N=255: 2.8
main: 0.198 +- 0.040
this: 0.071 +- 0.003

N=400: 2.3
main: 0.607 +- 0.001
this: 0.260 +- 0.000

10 timestep for 4th order Trotter: speedup @ 100 qubits is 9.4
N=25: 6.7
main: 0.040 +- 0.003
this: 0.006 +- 0.000

N=100: 9.4
main: 0.330 +- 0.037
this: 0.035 +- 0.001

N=255: 10.8
main: 1.291 +- 0.066
this: 0.119 +- 0.007

N=400: 11.5
main: 4.052 +- 0.051
this: 0.353 +- 0.009

1 timestep for first order Trotter but with wrap=True: speedup @ 100 qubits is 3.6
N=25: 3.4
main: 0.034 +- 0.012
this: 0.010 +- 0.004

N=100: 3.6
main: 0.187 +- 0.017
this: 0.052 +- 0.010

N=255: 3.1
main: 0.551 +- 0.048
this: 0.178 +- 0.019

N=400: 3.0
main: 1.367 +- 0.068
this: 0.458 +- 0.027

Side effects of this PR:

add SparsePauliOp.to_sparse_list to construct the sparse list format (i.e. op == SparsePauliOp.from_sparse_list(op.to_sparse_list()))
refactor LieTrotter to just be an alias of SuzukiTrotter and reduce code duplication
fix the docstrings to use actually non-commuting Paulis (XX and ZZ commute and would have no expansion error)

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

54 of 60 (90.0%)  changed or added relevant lines in 6 files are covered.
26 unchanged lines in 4 files lost coverage.
Overall coverage decreased (-0.01%) to 88.862%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit/synthesis/evolution/product_formula.py
13
15
86.67%

qiskit/synthesis/evolution/qdrift.py
12
14
85.71%

qiskit/transpiler/passes/synthesis/hls_plugins.py
4
6
66.67%

Files with Coverage Reduction
New Missed Lines
%

crates/accelerate/src/two_qubit_decompose.rs
1
91.45%

crates/qasm2/src/lex.rs
3
92.48%

qiskit/synthesis/evolution/product_formula.py
4
95.63%

crates/qasm2/src/parse.rs
18
96.69%

Totals

Change from base Build<PHONE_NUMBER>1:
-0.01%

Covered Lines:
74597

Relevant Lines:
83947

💛  - Coveralls

Hmm, after switching SX and SXdg in 2b6f4eb, some of the tests in pauli_feature_map now fail. I believe the tests were incorrect before 2b6f4eb, so it's good that they would be fixed, yet it's scary how difficult it is to distinguish between the correct and incorrect behaviors (I was actually looking at these before and they looked perfectly fine to me). Can we add more Operator-based asserts? I.e. in addition to checking that the ref circuit looks as it's supposed to, also that Operator(encoding) == Operator(ref)?
Other than that, I am very happy with this PR, thanks for the great work!

For the record, I am no longer sure what was our conclusion with @raynelfss. I know that @Cryoris used boxing to be able to return both the usual and the double-ended iterators (and maybe something else too), yet if I remember correctly the double-ended iterators are a bit heavier than the usual ones. Does it make sense for us to return the double-ended iterators everywhere? Another possibility is maybe we should return the CircuitData objects (instead of Vec<Instruction> or iterator over that).

In hindsight @Cryoris, we might not be able to use a simple impl Trait I believe I can now see why you used so many Box pointers.

This is because this function returns different types of Iterator depending on the input (e.g. Chain<Map<...>> vs Empty). The dynamic type was the only way I got to work, but I'm happy to change it if there's a better way 🙂

Even though both Once iterators and an example iterator such as Chain<Map<Iterator>> should technically both count as Iterator the types are different enough to require a dynamic block, and so you'd need to use the Box there. I can't think of another way to do this right now, so you can keep the Box here.


Request: Optional strict typing on bracket access to properties

Tested with TypeScript 1.8.7
I have a situation where I need to access a property on an object with bracket notation because the property name contains dots. Unfortunately, TypeScript is less strict with the bracket notation:
interface IFoo {
  n: number;
  s: string;
}

function testNumber(x : number) {
  return x;
}

function (foo : IFoo) {
  testNumber(foo.n);  // pass
  testNumber(foo.s);  // fail
  testNumber(foo.asd);  // fail

  testNumber(foo['n']);  // pass
  testNumber(foo['s']);  // fail
  testNumber(foo['asd']);  // pass
}

foo.asd in this case fails because asd is not a valid property of IFoo. But foo['asd'] is assumed to be of type any.
I read somewhere that this behavior is intentional to offer some kind of backdoor. I am pretty sure I do not need that backdoor in my project, but I need foo['asd'] to fail. So it would be great if this behavior could be optionally turned on.
I guess the --noImplicitAny option would have some effect, but unfortunately turning it on would require major changes in the rest of my codebase, so that is not an option.

JavaScript allows to index into any object. TypeScript compiler can not statically know type checked all these, e.g. var name = getName(); x[name];. so it gives it the type any.
Obviously this is not type-safe, for this you have index signatures on types, e.g.
interface IFoo {
  n: number;
  s: string;
  [x:string] : number | string;
}

testNumber(foo['asd']);  // now fails

--noImplicitAny enforces that you can not access into anything without either 1. using known property names (e.g. foo["n"] above), or 2. having an index signature on the type as outlined above.

My report was not a question but a feature request. I will take your answer as a no to that request.

However when the index type is a number you loose some more typing.
The compiler seems to be lost when doing:
interface IFoo {
        [x: number]: number | string;
}
var t = testNumber(foo['a']); // t = any

The equivalent, but using string as index key, works as expected even with "wrong" accessor type:
interface IFoo {
        [x: string]: number | string;
}
var t = testNumber(foo[0]); // t = number | string;

This is perhaps a silly example but becomes odd when using enums as keys.
And in 2.1.5 you can't use enums as accessors yet so you have to use key:number.
@mhegazy any recommendations of usage here? (e.g. not getting back eny when using key:number)
Using 2.1.5 in examples


Desktop app prevents Windows Taskbar from auto-hiding

Sometimes Toggl Desktop appears to keep Windows Taskbar from auto-hiding.
The Windows taskbar can be set to'auto-hide' so it only appears when you move your mouse to the edge of the screen where the task bar is located. This maximizes screen real estate and cleans up the appearance of the desktop. The Taskbar will
pop whenever there is a warning msg or pop-up from a running application (a task reminder from Outlook, for example). Toggl Desktop is triggering something to cause Windows to drop the taskbar. Stopping Toggl Desktop and restarting resolves the issue for a while.
Windows 10, windows_native_app/7.3.157
Desk case with logs #217208.

Was able to reproduce this once, but not since then.
In that one case, the taskbar popped up with the autotracker notification, and did not return to normal afterwards. May be unrelated. Currently not occurring again under what seem to be the same conditions.


feat: add duplication keys check

Add duplication key check to avoid key overwriting on phrase

Weird behavior from GitHub. We'll create a new PR for this contribution. 🤔


MINOR: Add text and link to blog in announcement template email

The blog is "new" compared to the existence of the announcement email template. I added a section for the blog in the template so nobody forgets about it.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Hi @soarez if you have some time this is a quick one

Thanks for the change

No need to wait for CI as it only changes a template file in python


Proxy Support

Hello
The app does not work if using system wide proxy.

This is a weird limitation in the Flutter framework: https://github.com/flutter/flutter/issues/26359. Preferably system proxies would work by default, but external packages do exist to address this.


[#494] Wrong credentials cause thread to wait forever

Fixes #494

Sorry, it seems there is something wrong


possibility to show ingame when an award is unlocked

hmm could be sent via ping if its an award which is not run related... if its run related it could be sent by the run response?!

API part done in b787359b94190596042dd67e190fbe82ae19fe2b

Gameserver part done here: d65a66d


Wallet goes Blank during loading of confirm button

Hi,
I've been trying to send/transfer Funky Donut's from STXNFT to those that have entered our Giveway and have been experiencing an issue where the Hiro Wallet goes blank as it's trying to load the confirm button. The confirm button is pale blue while it's loading (to be able to clicked) and then within 3-4 secs the wallet/screen goes blank.
This has happened to me several times now as it's now happening repeatedly so I'm unable to send the NFT's to the recipients. It was fine for maybe the first 8 transfers and then it started going blank and has ground me to a halt.
I'm using Brave Browser. Hiro wallet v2.20.2
James.

@funkyjames Chrome seems to have no issue with the steps above.Testing with Brave now

We believe this was caused by lack of error handling of the /mempool endpoint. @funkyjames, can you try and replicate the issue with v2.20.3?

I'm taking this off our board until we can get confirmation from @funkyjames that it's still a problem.

I'm taking this off our board until we can get confirmation from @funkyjames that it's still a problem.

Apologies Mark, I've been away for a few days. This is no longer an issue 🙂 Thank you!


Six minute walk distance test

Problem
The six minute walk distance test sample result is not implemented for FHIR in Spezi. How do we go about implementing it?
Solution
We could be provided a way to implement samples that are not yet implemented or the HealthKit module could have it ready to be collected as is the case for heart rate as an example.
Additional context
The six minute walk distance test is gathered passively and is a great meausre of cardiac health. It is a needed information for monitoring cardiac health.
Code of Conduct

[X] I agree to follow this project's Code of Conduct and Contributing Guidelines

@scdi I have moved this issue to Spezi Questionnaire as we have started to implement a six minute walk test in here which is currently in process and found at https://github.com/StanfordSpezi/SpeziQuestionnaire/pull/16.
If you are just looking for the HealthKit HKSample to FHIR mapping please check out https://github.com/StanfordBDHG/HealthKitOnFHIR and maybe create an issue over there.

Thank you!

This issue was addresed by #16, which has been merged into the main branch - will close.


pull request for e2e test at 11/19/2016 01:26:19

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

optest/docs/updated_at.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


[BACKLOG-11619] Updating code to point to a none XUL specific version…

… of the icon property.
@hudak / @mkambol / @kcruzada

Build Completed
:fire: This pull request has some issues. It would be preferable to fix them in order for it to be just perfect. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
ant -Dtestreports.dir=bin/reports/unit-test -f engine/build.xml clean-all resolve jacoco && ant -Dtestreports.dir=bin/reports/integration-test -f engine/build.xml jacoco-integration checkstyle publish-local

Cleanup Commands
rm -r ~/.ivy2/local || echo no publish local to remove

Changed files
  engine/src/org/pentaho/di/core/gui/SwingDirectGC.java
  engine/src/org/pentaho/di/core/gui/SwingGC.java

Unit test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.core.auth.core.impl.DefaultAuthenticationConsumerFactory

Branch Change: -7.14%:small_red_triangle_down:
Complexity Change: -7.69%:small_red_triangle_down:

org.pentaho.di.job.entries.evalfilesmetrics.JobEntryEvalFilesMetrics

Branch Change: -.39%:small_red_triangle_down:
Complexity Change: -.51%:small_red_triangle_down:
Instruction Change: -.08%:small_red_triangle_down:

org.pentaho.di.job.entries.evaluatetablecontent.JobEntryEvalTableContent

Branch Change:  + 1.01%
Complexity Change:  + 1.06%
Instruction Change:  + .17%

org.pentaho.di.job.entries.sql.JobEntrySQL

Instruction Change: -3.28%:small_red_triangle_down:
Line Change: -3.87%:small_red_triangle_down:

org.pentaho.di.job.entries.waitforsql.JobEntryWaitForSQL

Branch Change:  + .66%
Complexity Change:  + .93%
Instruction Change:  + .13%

org.pentaho.di.trans.step.StepMeta

Instruction Change: -.19%:small_red_triangle_down:
Line Change: -.27%:small_red_triangle_down:

org.pentaho.di.trans.steps.checksum.CheckSumMeta

Branch Change:  + 1.35%
Complexity Change:  + 1.45%
Instruction Change:  + .11%

org.pentaho.di.trans.steps.constant.ConstantMeta

Instruction Change:  + .10%

org.pentaho.di.trans.steps.dbproc.DBProcMeta

Instruction Change:  + .11%

org.pentaho.di.trans.steps.dimensionlookup.DimensionLookupMeta

Branch Change:  + .66%
Complexity Change:  + .41%
Instruction Change:  + .50%
Line Change:  + .24%

org.pentaho.di.trans.steps.groupby.GroupByMeta

Branch Change:  + 1.04%
Complexity Change:  + 1.05%

org.pentaho.di.trans.steps.insertupdate.InsertUpdateMeta

Instruction Change:  + .05%

org.pentaho.di.trans.steps.pgbulkloader.PGBulkLoaderMeta

Branch Change:  + .88%
Complexity Change:  + .93%

org.pentaho.di.trans.steps.replacestring.ReplaceStringMeta

Instruction Change: -.07%:small_red_triangle_down:

org.pentaho.di.trans.steps.setvalueconstant.SetValueConstantMeta

Instruction Change:  + .14%

org.pentaho.di.trans.steps.sort.SortRowsMeta

Instruction Change: -.08%:small_red_triangle_down:

org.pentaho.di.trans.steps.sortedmerge.SortedMergeMeta

Instruction Change:  + .18%

org.pentaho.di.trans.Trans

Branch Change: -.10%:small_red_triangle_down:
Complexity Change: -.14%:small_red_triangle_down:
Instruction Change: -.09%:small_red_triangle_down:
Line Change: -.11%:small_red_triangle_down:


Memory leak from enclave

Describe the bug
Context https://github.com/ros2/rcl/issues/1198 and https://github.com/Yaskawa-Global/motoros2/issues/35
I believe that there is a possible memory leak in rmw_microxrcedds. In the micro-ROS rcl repo, the following lines duplicate a string and dynamically allocate the memory if RCL_MICROROS_COMPLETE_IMPL is set.
https://github.com/micro-ROS/rcl/blob/041a67a2e102e9c48ae2580f19b2677016fcf86a/rcl/src/rcl/init.c#L265-L273
This memory which is dynamically allocated for enclave via strdup is deallocated in other (full) rmw implementations. For example:
https://github.com/ros2/rmw_fastrtps/blob/1128b57d336dfa8bf462a5f9147291f73faa8ed3/rmw_fastrtps_shared_cpp/src/rmw_init.cpp#L116
However it is never deallocated in rmw_microxrcedds. I believe that this is only a problem if RCL_MICROROS_COMPLETE_IMPL is set, because that is the only case where strdup runs and sets aside dynamic memory.
I do not believe that the solution is as simple as freeing the memory in rmw_init_options_fini, because the code below copies the enclave data to static memory, and thus cannot be freed. I might be wrong about that.
https://github.com/micro-ROS/rcl/blob/041a67a2e102e9c48ae2580f19b2677016fcf86a/rcl/src/rcl/init.c#L105-L110
To Reproduce
I do not have a MWE, but it is apparent in MotoROS2 using the debug listener script.
Expected behaviour
I expect the memory set aside by strdup to be freed by the rmw, as it is with other rmws.
System information (please complete the following information):

YRC1000
ROS 2: I am currently using Jazzy. I believe that the problem exists on Humble as well, though.
Version: I am currently using a fork off of 2.4.3

Please let me know if I need to provide any more information, or if I am doing something improperly. Thank you.

Here is a MWE. It's a silly program that doesn't accomplish anything other than to demonstrate this problem, but when I use valgrind I get the following results:
....
==18276== 222 bytes in 111 blocks are definitely lost in loss record 17 of 18
==18276==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==18276==    by 0x492E85C: rcutils_strndup (in /opt/ros/humble/lib/librcutils.so)
==18276==    by 0x495382D: rcl_init (in /opt/ros/humble/lib/librcl.so)
==18276==    by 0x48613D5: rclc_support_init_with_options (in /opt/ros/humble/lib/librclc.so)
==18276==    by 0x10942D: Ros_StateServer_TimerCallback (in /home/jimmy/everything_motoros2/Other/reproduce/install/lib/reproduce/reproduce)
==18276==    by 0x4961679: rcl_timer_call (in /opt/ros/humble/lib/librcl.so)
==18276==    by 0x4866078: ??? (in /opt/ros/humble/lib/librclc.so)
==18276==    by 0x486B0BF: rclc_executor_spin_some (in /opt/ros/humble/lib/librclc.so)
==18276==    by 0x486C0AE: rclc_executor_spin (in /opt/ros/humble/lib/librclc.so)
==18276==    by 0x109771: main (in /home/jimmy/everything_motoros2/Other/reproduce/install/lib/reproduce/reproduce)
.....

This suggests that it is the strdup in rcl_init

@jimmy-mcelwain thanks for recreating the issue here, this does seem like a problem.

I would need to check this deeper but the for of rcl that we maintain for micro-ROS is intended to be built with RCL_MICROROS_COMPLETE_IMPL to not defined. In a sense, this flag excludes the code that micro-ROS does not need from mainstream rcl.
In any case, I wonder why rmw is supposed to deallocate memory being allocated by rcl?

I would need to check this deeper but the for of rcl that we maintain for micro-ROS is intended to be built with RCL_MICROROS_COMPLETE_IMPL to not defined. In a sense, this flag excludes the code that micro-ROS does not need from mainstream rcl.

we understand.
But seeing as rcl maintainers suggest this is an issue with the RMW, we thought we'd report it anyway.

In any case, I wonder why rmw is supposed to deallocate memory being allocated by rcl?

That is also something I'm not sure about.
Perhaps @clalancette and/or @fujitatomoya can say something about that.

Honestly, this seems like a bug in rcl (or, at least, in the expectations between rcl and rmw).  I agree that it doesn't make sense for the rcl layer to allocate it, and the rmw layer to free it.
To fix it, we have to either:

Leave the strndup in rcl_init, move the free into __cleanup_context, and remove the free from all of the RMW implementations, or
Move the strndup out of rcl_init and into rmw_init, and leave the free in the RMW.

I would actually probably go for the latter; while it is annoying to have to duplicate that code among the various RMWs, I think it also makes more sense since this code is manipulating the rmw_init_options structure.  But I don't have a strong opinion either way.

In any case, I wonder why rmw is supposed to deallocate memory being allocated by rcl?

yeah, thanks for pointing this out, i focused on memory leak issue. this is not good.
the thing is that some data of rmw_init_options_t needs to be updated via rcl_init before rmw_init, and a part of those is enclave which needs to be copied to rmw_init_options_t.

Move the strndup out of rcl_init and into rmw_init, and leave the free in the RMW.

i am also inclined to this option, it is important to keep the clear responsibility for memory management for maintenance.
@clalancette rmw_init requires rmw_init_options_t, so probably we need to have rmw_init(free)_options_enclave to allocate(deallocate) the memory in rmw implementation. what do you think?
i can patch this if we are good to go. i can also give it a shot to rmw_microxrcedds, as far as i see static memory management is done only on rmw_init_options_t structure, i think we need to call deallocator before returning that memory slot to the static buffer. @pablogs9 @gavanderhoorn am I understanding correctly? actually this is 1st time to see this code... 😅 )

@fujitatomoya that's it. I guess that checking if init_options->enclave != nullptr and deallocating it using the default allocator.
When this responsibility is moved to rmw implementations, the correct option is not to allocate nor deallocate this as rmw_microxrcedds does not handle SROS2 security features.