Integration wont load after update to HA 2024.2.2

Describe the bug
After updating to HA 2024.2.2 integration won´t load
To Reproduce
Steps to reproduce the behavior:

Go to System/Logs
See error message

Expected behavior
The integration to start
Screenshots
Version

2024.2.2
0.24.6
?

** Debug SCAN **
** IMPORTANT **
No able to run debug scan as integration is not loaded, see error message from systems logs
Additional context
Logger: homeassistant.config_entries
Source: config_entries.py:444
First occurred: 06:35:37 (3 occurrences)
Last logged: 06:44:44
Error setting up entry RC300/RC310/Nefit Moduline 3000 for bosch
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 444, in async_setup
result = await component.async_setup_entry(hass, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/bosch/init.py", line 148, in async_setup_entry
_init_status: bool = await gateway_entry.async_init()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/bosch/init.py", line 245, in async_init
if await self.async_init_bosch():
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/bosch/init.py", line 299, in async_init_bosch
await self.gateway.check_connection()
File "/usr/local/lib/python3.12/site-packages/bosch_thermostat_client/gateway/base.py", line 331, in check_connection
await self.initialize()
File "/usr/local/lib/python3.12/site-packages/bosch_thermostat_client/gateway/base.py", line 73, in initialize
await self._update_info(initial_db.get(GATEWAY))
File "/usr/local/lib/python3.12/site-packages/bosch_thermostat_client/gateway/ivt.py", line 75, in _update_info
response = await self._connector.get(uri)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/bosch_thermostat_client/connectors/xmpp.py", line 94, in get
data = await self._request(method=GET, path=path)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/bosch_thermostat_client/connectors/xmpp.py", line 124, in _request
await self.start()
File "/usr/local/lib/python3.12/site-packages/bosch_thermostat_client/connectors/xmpp.py", line 113, in start
self._xmppstream = await self._st.enter_async_context(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/contextlib.py", line 659, in enter_async_context
result = await _enter(cm)
^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/aioxmpp/node.py", line 1660, in aenter
await conn_future
File "/usr/local/lib/python3.12/site-packages/aioxmpp/node.py", line 837, in _on_main_done
task.result()
File "/usr/local/lib/python3.12/site-packages/aioxmpp/node.py", line 1005, in _main
await self._main_impl()
File "/usr/local/lib/python3.12/site-packages/aioxmpp/node.py", line 951, in _main_impl
tls_transport, xmlstream, features = await connect_xmlstream(
^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/aioxmpp/node.py", line 390, in connect_xmlstream
result = await _try_options(
^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/aioxmpp/node.py", line 241, in _try_options
transport, xmlstream, features = await conn.connect(
^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/aioxmpp/connector.py", line 263, in connect
await stream.starttls(
File "/usr/local/lib/python3.12/site-packages/aioxmpp/protocol.py", line 762, in starttls
await self._transport.starttls(ssl_context, post_handshake_callback)
File "/usr/local/lib/python3.12/site-packages/aioopenssl/init.py", line 732, in starttls
await self._waiter
File "/usr/local/lib/python3.12/site-packages/aioopenssl/init.py", line 355, in _tls_do_handshake
self._tls_conn.do_handshake()
File "/usr/local/lib/python3.12/site-packages/OpenSSL/SSL.py", line 2202, in do_handshake
self._raise_ssl_error(self._ssl, result)
File "/usr/local/lib/python3.12/site-packages/OpenSSL/SSL.py", line 1802, in _raise_ssl_error
self._context._verify_helper.raise_if_problem()
File "/usr/local/lib/python3.12/site-packages/OpenSSL/SSL.py", line 456, in raise_if_problem
raise self._problems.pop(0)
File "/usr/local/lib/python3.12/site-packages/OpenSSL/SSL.py", line 481, in wrapper
result = callback(
^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/aioxmpp/security_layer.py", line 300, in verify_callback
if not check_x509_hostname(
^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/aioxmpp/security_layer.py", line 230, in check_x509_hostname
ssl.match_hostname(cert_structure, hostname)
^^^^^^^^^^^^^^^^^^
AttributeError: module 'ssl' has no attribute 'match_hostname'

Duplicate of https://github.com/bosch-thermostat/home-assistant-bosch-custom-component/issues/387


Achtung! Cthulhu (CoC 7th) Release v1.01 – Bugfix

Achtung! Cthulhu (CoC 7th) Release v1.01
This is a Bugfix.

Submission Checklist
Required

[x] The pull request title clearly contains the name of the sheet I am editing.
[x] The pull request title clearly states the type of change I am submitting (New Sheet/New Feature/Bugfix/etc.).
[x] The pull request makes changes to files in only one sub-folder.
[x] The pull request does not contain changes to any json files in the translations folder (translation.json is permitted)

Changes / Description

Fix initial weapon damage bug

Character Sheet Info Roll20 Internal Use only.


Bump prometheus/client_golang and dependencies v1.3.0

Updates prometheus to v1.3.0; given that this dependency wasn't updated for a while, doing so in some steps;
vendor: bump beorn7/perks v1.0.1
full diff: https://github.com/beorn7/perks/compare/4c0e84591b9aa9e6dcfdf3e020114cd81f89d5f9...v1.0.1

beorn7/perks#3 Avoid iterating on maps

Speed up InsertTargeted* functions by at least 2x by avoiding iterating on maps.

beorn7/perks#4 Fixed format error
Use 1000000 instead of 1e6 for int constant
Add go module support

vendor: bump prometheus/client_model v0.1.0
full diff: https://github.com/prometheus/client_model/compare/99fa1f4be8e564e8a6b613da7fa6f46c9edafc6c...v0.1.0

prometheus/client_model#22 add go_package, regenerate Go binding file
prometheus/client_model#31 Support Go Modules
prometheus/client_model#38 Remove all languages but Go and add a deprecation note

vendor: bump prometheus/common v0.7.0
full diff: https://github.com/prometheus/common/compare/89604d197083d4781071d3c65855d24ecfb0a563...v0.7.0
vendor: bump prometheus/procfs v0.0.8
full diff: https://github.com/prometheus/procfs/compare/cb4147076ac75738c9a7d279075a253c0cc5acbd...v0.0.8
vendor: bump docker/go-metrics v0.0.1:
full diff: https://github.com/docker/go-metrics/compare/4ea375f7759c82740c893fc030bc37088d2ec098...v0.0.1

docker/go-metrics#15 Add functions that instruments http handler using promhttp
docker/go-metrics#20 Rename LICENSE.code → LICENSE
docker/go-metrics#22 Support Go Modules

vendor: bump prometheus/client_golang v0.9.4
full diff: https://github.com/prometheus/client_golang/compare/f4fb1b73fb099f396a7f0036bf86aa8def4ed823...v0.9.4
version v0.9.0 is the minimum tagged version to work with go-metrics v0.0.1,
as it depends on prometheus.Observer:
vendor/github.com/docker/go-metrics/timer.go:39:4: undefined: prometheus.Observer
vendor: bump prometheus/client_golang v1.1.0
full diff: https://github.com/prometheus/client_golang/compare/v0.9.4...v1.1.0
Using v1.1.0, because version v1.2.0 and up use versioned import paths for the
github.com/cespare/xxhash/v2 dependency (prometheus/client_golang#657), which
causes vendoring with vndr to break due to the v2 in the import-path.
vendor: bump prometheus/client_golang v1.3.0
full diff: https://github.com/prometheus/client_golang/compare/v1.1.0...v1.3.0
This requires LK4D/vndr v0.1.0 or newer for vendoring; also adds a new
dependency: github.com/cespare/xxhash

Codecov Report

Merging #3959 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #3959   +/-   ##
=======================================
  Coverage   42.63%   42.63%
=======================================
  Files         130      130
  Lines       14759    14759
=======================================
  Hits         6292     6292
  Misses       7548     7548
  Partials      919      919

Flag
Coverage Δ

#linux
46% <ø> (ø)
:arrow_up:

#windows
38.22% <ø> (ø)
:arrow_up:

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 a767b62...2f0db8e. Read the comment docs.


Flight module sticking "on"

Hi,
I have a custom server pack and I've set up an environmental controller, fed by an IE HV capacitor. There's a single Flight module in it.  Similar to #538 my flight is persisting even after the buff has expired. It persists when out of range of the controller, including across dimensions.
I have tried to replicate this in SSP, with a local test server with configs copied from the production server, and with a stripped-down pack, but I can't! It only happens with our production server. Only difference in testing was that I used an RFT creative powercell rather than an IE HV cap.
If I disable the EnvCtlr with its redstone button, the buff expires as expected.
I have enabled debug in rftools.cfg on both server and client but I'm not seeing anything extra in the regular logs.  Is the additional info supposed to go into the regular logs?
If you have any ideas on how I can troubleshoot, please let me know!
Cheers

Version please?

oops!
rftools-1.1x-5.75
mcjtylib-1.1x-2.3.1
compatlayer-1.10-0.1.6
forge 2185
mc 1.10.2
Update: Having the controller disabled isn't a sure-fire way of ensuring the buff expires.
/tp anotherplayer DID clear it!

Thank you for taking the time to create this issue, as we're no longer supporting versions below 1.12, I'm going to go ahead and close it but if this bug seems to continue over to newer versions, please do report it again so we can investigate the issue further.


5.2.1 Release for Browserify Update

Hey all,
I was curious what the timeline looked like to release the next version that includes the browserify version bump to 16.x? There are a handful of ES2018 features covered in v16.x of Browserify that are currently breaking in my build due to the v14.x requirement.

A small update: sorry, the week turned out to be too busy, I'll publish the update this weekend.

Done. I have released the update as 5.3.0.

@DirtyHairy Thank you!


Void Manager window will not close when I press F5.

As title says, the Void Manager Window will not close when I press F5, and I cannot find any button in Void Manager to close Void Manager.

Thanks for reporting this issue. Is there anything noticeable in the console or Player.log file? To find it, paste the following into windows file explorer. %localappdata%low\Hutlihut Games ApS\Void Crew
Additionally, it may be faster to contact us on our discord server.

Seems the issue was resolved and not reproduced via discord contact. Closing the issue.


Dead Sources

Checklist:

[ ] Updated extVersionCode value in build.gradle for individual extensions
[ ] Updated overrideVersionCode or baseVersionCode as needed for all multisrc extensions
[X] Referenced all related issues in the PR body (e.g. "Closes #xyz")
[ ] Added the isNsfw = true flag in build.gradle when appropriate
[X] Have not changed source names
[ ] Have explicitly kept the id if a source's name or language were changed
[ ] Have tested the modifications by compiling and running the extension through Android Studio
[ ] Have removed web_hi_res_512.png when adding a new extension
[X] Remove Dead Sources

Changelog:
Colored Manga (English): deleted (Closes #266)
CatOnHeadTranslations (English): deleted (Closes #443)
Epik manga (Turkish): deleted (Closes #449)
Drop Scan (Pt-br): deleted (Closes #459)
Ama Scans (Pt-br): deleted (Closes #461)
Baixarhentai (Pt-br): deleted (Closes #464)
Hentaisphere (English): deleted (Closes #465)
projetoscanlator (Pt-br): deleted (Closes #467)
Girls Love Manga (English): deleted (Closes #468)

Thanks for putting in the effort, though after giving it some thought I will have to deny this PR because:

Don't make pull requests on the main branch. From the contributing guide:

When you feel confident about your changes, submit a new Pull Request so your code can be reviewed
and merged if it's approved. We encourage following a GitHub Standard Fork & Pull Request Workflow
and following the good practices of the workflow, such as not commiting directly to main: always
create a new branch for your changes.

I have already suggested to make one PR for each site, because lumping a lot of changes into the same PR is hard to review and hard to verify.
You don't seem to have checked yourself if the website is down (e.g I had to point out Reaper Scans FR was not dead, but then you also assumed Reaper Scans TR was still up).


Added basic page object pattern implementation for Windows apps

PR summary

This PR is the starting point for creating automated UI tests with Appium for Windows applications following the page object pattern.
Additionally, there are some starting point WindowsElement wrappers contained within this PR which were initially created to test functions of core controls in the Windows 10 SDKs. Note, these are not a complete set of wrappers and will be included in a separate piece of work.
Sample test projects have been added for the Windows Alarms & Clock application from my original Windows UWP Appium page object pattern example, and another sample project added for the XAML Controls Gallery application.
PR checklist

[x] Sample tests have been added/updated and pass
[x] Code styling has been run on all new source file changes
[x] Contains NO breaking changes

References

Windows (UWP) Appium Page Object Pattern Example

Let's start fleshing out features for the rest of the work before carrying on. Help to track where we're going with this.


Should we use jest?

Problem description
ATM, the test is using mocha frameworks, I would like to open consideration to moving to Jest + TS-Jest . At the moment, the test in guardian-service is not very good written (my opinion) it is still using pure js and import file from 'dist' to run the test
Requirements

setup jest and ts-jest
migrate js to. ts for test file inside guardian-service test
setup jest module alias so the test can run on the source ts file instead of dist
add more test for other share components such as interface

Please note: if you don't want to using jest, mocha still able to do all above requirements but it not easy as Jest.
Definition of done
How do we know we've fully dealt with it?
Acceptance criteria
What are the criteria by which we determine if the issue has been resolved?

@samuraitruong Thanks for your suggestion. We are currently implementing the https://www.cypress.io/ framework for our e2e tests. We are planning to use this framework for API and UI tests. Implementation of JEST is not in our roadmap. But you are right current API tests are not written well and need to be cleaned.


Syncing vscode extension version number with PRQL compiler releases

When the VS Code extension came out with the 0.5.2 PRQL compiler, the extension's version number was "0.6.0". Now that PRQL is at 0.6.0, there'll be a new VS Code extension.
But what should its version number be? And should we try to keep it in sync with the PRQL compiler?

It's convenient (low "cognitive load") to have them numbered the same
But it locks changes to the Extension to updates in the compiler

Does it matter? Or should we simply agree they should be separate? (For example, declare VSCode Extension to be 1.0 soon, then note that 1.0.1 has PRQL compiler 0.6.0, and extension 1.0.2 has new feature foo and PRQL compiler 0.6.0, and extension 1.0.3 has PRQL compiler 0.6.1, etc.) Thanks.
PS If this sets off a whole lot of work, just close this issue.

I agree! We had a short discussion on Discord about this.
I was a +0.1 on syncing the minor versions, I think @RandomFractals was keener for prql-vscode to not be inhibited, and he has been doing the work, so he gets to decide. Depending on how we go, it's not impossible to get them in sync again.
We should sync the major versions though, or at least I don't yet see a good reason to un-sync them.
@RandomFractals lmk if you have any thoughts, otherwise we can close...

yes, I brought this up when packaging v0.6 with the multi-Sql preview updates.
https://discord.com/channels/936728116712316989/1028380004226171032/1077224905730437160

@max-sixty follow-up on that in dicsord:
https://discord.com/channels/936728116712316989/1028380004226171032/1077349146127769641

I would like to create ext. version 1.x.x. I think it's mature enough, but we can keep it at 0.x for now.
Realistically, as stated in that discord discussion, keeping ext. version in sync with prql compiler might be logically tempting, but harder to maintain as ext. will be getting less updates now after that 0.6.0 release and prql compiler can iterate more to flash out prql language design, or vice versa if we need to add more UX features.

@RandomFractals Updated the review. I also approve of the plan to let the VS Code extension and PRQL version numbers drift as needed. Thanks!


Fix TableCell child nodes on paste

This PR fixes pasting tables that have the copied html in such format:
...

 ...

...

Pasting this results in the following node structure:

which causes the editor to freeze and eventually crash on enter key press, as the text node is not wrapped in a paragraph node.
This issue is similar to the one described here and was fixed for the case when pasting empty cells.
This PR addresses the case when on paste the children of the TableCell node are not within a block element node.
Another case to reproduce this issue is when we copy something with such html:
...

 ...

...

This results in a link node inside a tablecell node which again crashes on enter key press.
Also, this PR fixes the issue with alignment of text inside the cell as well, as this formatting can now be applied on the wrapping block element node.
So, copying from google sheets will now have the correct alignment.
Before

After

Thank you, we can merge this, but I'd be inclined to roll it back as soon as https://github.com/facebook/lexical/pull/5857 is ready as it fixes the same issue in a more generic manner cc @potatowagon

Thanks Gerard! Happy to revert once the larger one lands. Do we have an ETA on the generic solution? If it's a week, we can wait it out.

#5857 is ready, tests and comments addressed @ivailop7 @zurfyx


Rendering novel pose with train_stage 2

I'm trying to run render_novel_pose.py with train_stage 2. I trained both stages with the m4c_processed dataset, but after rendering 110 images completely blank, just like the one below:

I get the following message error:
Traceback (most recent call last):
  File "E:\trabalhos\GaussianAvatar\render_novel_pose.py", line 48, in <module>
    render_sets(model.extract(args), network.extract(args), op.extract(args), args.epoch,)
  File "E:\trabalhos\GaussianAvatar\render_novel_pose.py", line 26, in render_sets
    for idx, batch_data in enumerate(tqdm(novel_pose_loader, desc="Rendering progress")):
  File "C:\Users\pusa\miniconda3\envs\gs-avatar\lib\site-packages\tqdm\std.py", line 1181, in __iter__
    for obj in iterable:
  File "C:\Users\pusa\miniconda3\envs\gs-avatar\lib\site-packages\torch\utils\data\dataloader.py", line 633, in __next__
    data = self._next_data()
  File "C:\Users\pusa\miniconda3\envs\gs-avatar\lib\site-packages\torch\utils\data\dataloader.py", line 1345, in _next_data
    return self._process_data(data)
  File "C:\Users\pusa\miniconda3\envs\gs-avatar\lib\site-packages\torch\utils\data\dataloader.py", line 1371, in _process_data
    data.reraise()
  File "C:\Users\pusa\miniconda3\envs\gs-avatar\lib\site-packages\torch\_utils.py", line 644, in reraise
    raise exception
FileNotFoundError: Caught FileNotFoundError in DataLoader worker process 2.
Original Traceback (most recent call last):
  File "C:\Users\pusa\miniconda3\envs\gs-avatar\lib\site-packages\torch\utils\data\_utils\worker.py", line 308, in _worker_loop
    data = fetcher.fetch(index)
  File "C:\Users\pusa\miniconda3\envs\gs-avatar\lib\site-packages\torch\utils\data\_utils\fetch.py", line 51, in fetch
    data = [self.dataset[idx] for idx in possibly_batched_index]
  File "C:\Users\pusa\miniconda3\envs\gs-avatar\lib\site-packages\torch\utils\data\_utils\fetch.py", line 51, in <listcomp>
    data = [self.dataset[idx] for idx in possibly_batched_index]
  File "E:\trabalhos\GaussianAvatar\scene\dataset_mono.py", line 471, in __getitem__
    return self.getitem(index, ignore_list)
  File "C:\Users\pusa\miniconda3\envs\gs-avatar\lib\site-packages\torch\utils\_contextlib.py", line 115, in decorate_context
    return func(*args, **kwargs)
  File "E:\trabalhos\GaussianAvatar\scene\dataset_mono.py", line 479, in getitem
    inp_posmap = np.load(inp_posmap_path)['posmap' + str(self.dataset_parms.inp_posmap_size)]
  File "C:\Users\pusa\miniconda3\envs\gs-avatar\lib\site-packages\numpay\lib\npyio.py", line 390, in load
    fid = stack.enter_context(open(os_fspath(file), "rb"))
FileNotFoundError: [Errno 2] No such file or directory: 'E:\\trabalhos\\GaussianAvatar/assets/test_pose/inp_map/inp_posemap_128_00000110.npz'

Maybe I'm missing something obvious here, but what could be causing this, and how could I rectify that? Besides the 110 posemaps in m4c_processed's training folder, I cannot find any other posemaps anywhere, nor I can find a way to generate more posemaps (which, speaking - or typing - out loud, doesn't make that much sense).

me too
I wish the author will provide the test code for the second stage.


Implement list permissions

Reference: List sharing permissions on a drive item

Closing this given that the apis are all sourced from the msgraph-metadata repository and not written manually. If this is part of the apis in the open api data provided it will be added at some point. If you find that this is not the case and would like this api please feel free to open this ticket again.


Add Mystery of Solarus XD, Mercuris Chess, Zeldo's Challenge, and Zeldo's Challenge 2

New Port for Mystery of Solarus XD, Mercuris Chess, Zeldo's Challenge, and Zeldo's Challenge 2
URL: https://solarus-games.org/games/
Install: Similar enough to the others
Tested on multiple devices in PortMaster Discord

All files in order and devices have been tested in PM Discord.
Good to go.


[iOS] composition items memory issue

in FramesExtrator, Exporter
initialize 'VideoCompositionItemDecoder' at once
So, If a lot of items make OOM crash.
This problem can be solved by using decoder pool only for required items
Then I can preview a lot of composition items.
However, the frame generation loop in the exporter still has memory issues.
If you are using 'Instructions' for monitoring memory allocation.
It continues to increase until it is finished.
so short composition items will be fine but long & heavy video have same problem.
CVPixelBufferCreate return kCVReturnAllocationFailed
create MTLTexture return null
But It already been called
CVPixelBufferRelease(pixelBuffer);
[cpuAccessibleTexture setPurgeableState:MTLPurgeableStateEmpty];

Can anyone help me with this?

@fdecampredon 🥹

For preview, the problem with using VideoCompositionItemDecoder on demand is for live composition playing. for example let's say you need to play a video at frame 60, if we don't pre-create the decoder it might not be ready in time.
For export, we'll try to investigate memory issue, but in general most of the memory allocated is done by AVAssetReader, which we don't have the control over.
However, we could using lazy  VideoCompositionItemDecoder on demand.
Just for info are you using the resolution field in your composition item ? Downscaling the resolution has a great impact on memory issues.

Oh, I'm missing 'resolution' in composition item. It pretty good for better preview.
But it still have many composition items will load at once.
How about initialize items will renderer by compositionStartTime, startTime, duration.
Here is PR
and exporting memory allocation fixed PR


Fixed #434 jni lib load failure

Added the check if CPU is ARM v7a
If ARM v7a, load specific name of library (-v7a.so) .

this PR will not be merge-able anymore. If this solution works, we need to reimplement in https://github.com/couchbase/couchbase-lite-java-native


chore: bump project and Hilla to 2.5

I suggest to update the README versions together with this PR.

Build is failing because of an API change in Hibernate 6.3. Fix should be released in Quarkus 3.6.0
https://github.com/quarkusio/quarkus/commit/5985241799f10eb9236519d19710d7549cc872b1
Hibernate 6.3 is brought in by Hilla through spring-boot-starter-data-jpa
We should probably wait for Quarkus 3.6.0 final, and highlight the dependency requirement it in the readme

Temporarily pinned hibernate version in parent pom


Include params

Other than putting them into the URL, is there a way to add include params?
  findWookies: resourceAction('find-em?include=wookie,tart', {
    type: 'POST',
    pushToStore: true
  }),

Currently, the only possible way to do that is to use the example you passed or a payload (but only in case of GET)
It looks like a very interesting feature to add a support for queryParams. I will add it to my schedule.

Cool. I was expecting some kind of syntax like:
  findWookies: resourceAction('find-em', {
    type: 'POST',
    pushToStore: true,
    include: 'wookie,tart',
    filter: {name: 'chewie'},
    queryParams: {single: false}
  }),

//or
  findWookies: resourceAction('find-em', {
    type: 'POST',
    pushToStore: true,
    pathOptions: {
      include: 'wookie,tart',
      filter: {name: 'chewie'},
      queryParams: {single: false}
    }
  }),

OK, today it is on my way :)
Potential interface:
 findWookies: resourceAction('find-em', {
    type: 'POST',
    pushToStore: true,
    queryParams: {
        single: false,
        include: 'wookie,tart',
        filter: {  name: 'chewie'  },
    }
  }),

Branch: feature-query-params
PR: is coming

Implemented :)


[CSBindings] Mark generic parameter type vars as complete if they don…

…'t have any adjacent vars
Always marking generic parameter type variables as incomplete is too aggressive.
That was the way to make sure that they are never attempted to eagerly, but really
there are only a couple of situations where that can cause issues:
1. Int <: $T_param
   $T1 <: $T_param

2. $T2 conv Generic<$T_param>
   $T2 conv Generic<Int?>
   Int <: $T_param

Attempting $T_param before $T1 in 1. could result in a missed optional type binding for example.
Attempting $T_param too early in this case (before $T2) could miss some transitive bindings inferred through conversion of Generic type.
If a type variable that represents a generic parameter is no longer associated with any type variables (directly or indirectly) it's safe to assume that its binding set is complete.

@swift-ci please test source compatibility

@swift-ci please test source compatibility

@swift-ci please test

@swift-ci please test

@swift-ci please test source compatibility


Ignore ERROR_ACCESS_DENIED in one more case.

Ignoring ERROR_ACCESS_DENIED also in this place is essential to make multiple tests for winloop (Windows port of uvloop) pass. Specifically tests involving processes for the record:
test_process.Test_UV_Process
test_process.TestAsyncio_UV_Process
test_process.Test_UV_Process_Delayed
test_pipes.Test_UV_Pipes

There are about 15 errors/failures in total, typical error message:
RuntimeError: unable to perform operation on <WriteUnixTransport closed=True reading=False 0x29fb9100210>; the handler is closed

This seems to be one more case for ignoring ERROR_ACCESS_DENIED, which is also done in a few other cases in src/win/pipe.c and in src/win/process.c.
With this change, Winloop passes all of 500+ uvloops unit tests (except for some tests that are not relevant on Windows).

Is it possible to reproduce the problem with a libuv-only test case?

I'm not sure how to do that right now. Would have to "investigate" the call chain etc. Maybe you have a suggestion when you inspect one of the test cases, like this one (same test for uvloop and winloop):
https://github.com/Vizonex/Winloop/blob/main/tests/test_process.py#L633-L648
The test result is:
======================================================================
ERROR: test_communicate (test_process.TestAsyncio_UV_Process.test_communicate)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\Berry\Documents\GitHub\Winloop\tests\test_process.py", line 646, in test_communicate
    exitcode, stdout = self.loop.run_until_complete(task)
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "winloop\loop.pyx", line 1520, in winloop.loop.Loop.run_until_complete
  File "C:\Users\Berry\AppData\Local\Programs\Python\Python312\Lib\asyncio\tasks.py", line 520, in wait_for
    return await fut
           ^^^^^^^^^
  File "C:\Users\Berry\Documents\GitHub\Winloop\tests\test_process.py", line 641, in run
    stdout, stderr = await proc.communicate(data)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Berry\AppData\Local\Programs\Python\Python312\Lib\asyncio\subprocess.py", line 201, in communicate
    stdin, stdout, stderr = await tasks.gather(stdin, stdout, stderr)
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Berry\AppData\Local\Programs\Python\Python312\Lib\asyncio\subprocess.py", line 152, in _feed_stdin
    self.stdin.write(input)
  File "C:\Users\Berry\AppData\Local\Programs\Python\Python312\Lib\asyncio\streams.py", line 346, in write
    self._transport.write(data)
  File "winloop\handles/stream.pyx", line 689, in winloop.loop.UVStream.write
  File "winloop\handles/handle.pyx", line 159, in winloop.loop.UVHandle._ensure_alive
RuntimeError: unable to perform operation on <WriteUnixTransport closed=True reading=False 0x196ad2dbc10>; the handler is closed

Or, can you point to some test cases for the other cases where ERROR_ACCESS_DENIED is ignored, like this one maybe:
https://github.com/libuv/libuv/blob/5d1ccc12c48099d720bb39f7430c480a52953039/src/win/pipe.c#L229

Hi @vtjnash, I have tried to find out what we could do differently in winloop but I couldn't find any other solution then ignoring ERROR_ACCESS_DENIED as done in this PR.
So, here's a minimal program that shows the problem:
import sys, subprocess, asyncio, winloop
winloop.install()

asyncio.run(asyncio.create_subprocess_exec(sys.executable, stdin=subprocess.PIPE))
print(f'{proc.stdin=}')

In winloop, the pipe for stdin is created using a "socket pair" from a call to uv_pipe() as we don't have Unix sockets on Windows. The use of uv_pipe() seems to be the intended libuv substitute for Unix sockets, and thus gives a nice alternative on Windows.
The problem is that we get a closed transport, which shouldn't be the case:
proc.stdin=<StreamWriter transport=<WriteUnixTransport closed=True reading=False 0x230ca2ea2b0>>

The transport is closed indeed because of an ERROR_ACCESS_DENIED from this call to ReadFile():
https://github.com/libuv/libuv/blob/5d1ccc12c48099d720bb39f7430c480a52953039/src/win/pipe.c#L1406-L1411
Here, the handle->handle resulted from this call to uv__get_osfhandle():
https://github.com/libuv/libuv/blob/5d1ccc12c48099d720bb39f7430c480a52953039/src/win/pipe.c#L2373-L2374
Now, it turns out that if we check access.AccessFlags & FILE_READ_DATA for os_handle and file, we get different results. We use a call like this for os_handle (and another one for file):
https://github.com/libuv/libuv/blob/5d1ccc12c48099d720bb39f7430c480a52953039/src/win/pipe.c#L2413-L2417
For file we get 1, but for os_handle we get 0.
Hence, read access is not granted for os_handle, while it was for file. We have created file with the right kind of access in winloop, so I don't see what we could do differently.
Does this give you an idea for a solution?

Have you tried using uv_socketpair?

I think I've tried that before, even before uv_pipe. I've now tried it again, using this call:
err = uv.uv_socketpair(uv.SOCK_STREAM, 0, fds, uv.UV_NONBLOCK_PIPE, uv.UV_NONBLOCK_PIPE)

The call succeeds, but the returned file descriptors lead to problems, like this kind of errors:
OSError: [Errno 9] bad file descriptor

Even a call like os_set_inheritable(fds[0], False) fails. Do you know how compatible the (WSA)socket file descriptors returned by uv_socketpair() are for use with calls like os_set_inheritable?

I think you might have to upgrade to libuv v2 (master) to use that reliably. The current v1.x is mostly for bug-compatibility with nodejs and may not work well with process spawn (something that nodejs is known to be somewhat bad at doing). It is only tested with Julia, and thus only on v2. I am away from a computer today, but can try to provide more specifics tomorrow. One possible note is that you should not necessarily automatically close a pipe when you read an error or EOF (that is a nodejs mistake), but only in certain conditions which includes checking !writable.

Oh, I use it for subprocesses in my small JS runtime and haven't run into issues yet!
Can you elaborate on that case about EOF?

As for the possible note mentioned above by @vtjnash about not automatically closing a pipe, that looks similar to what I've tried before in winloop. See https://github.com/Vizonex/Winloop/commit/e292e029c91ca839e3093ae8b9749cbbfc1256e4, keeping the connection open for writing (but stop reading). But this kind of solution looks somewhat undesirable to me.
Isn't there a way to avoid the ERROR_ACCESS_DENIED by giving read access (to make the 0-read succeed)?
Trying
err = uv.uv_pipe(fds, uv.UV_NONBLOCK_PIPE, uv.UV_NONBLOCK_PIPE | uv.UV_READABLE_PIPE)

leads to ERROR_ACCESS_DENIED already early on, at this point
https://github.com/libuv/libuv/blob/5d1ccc12c48099d720bb39f7430c480a52953039/src/win/pipe.c#L299-L309
Could there be a way to fix things at this stage?

Oh, I use it for subprocesses in my small JS runtime and haven't run into issues yet!

Way off topic here, but these bugs only manifest if you do something non-trivial: 1. libuv hijacks stdin/stderr/stdio (aka 0, 1, 2) and makes them non-blocking. When starting another application, this often leads to problems since they application that gets started doesn't expect this. (Sometimes it also changes it back to blocking, and libuv doesn't expect that and it leads to deadlock in libuv instead which is unfortunately but unfortunately posix doesn't supply anything that works better). This can be avoided by passing a dup handle instead. In libuv it also leaks the tty fd handle in some cases, which I have been meaning to fix recently; 2. nodejs does not support passing the same pipe to two different fd (e.g. using the same pipe for stdout/stderr) and attempting it just results in bad behaviors. It is easily avoided just by not doing that, but it means it cannot quite implement a shell (this is why we introduced uv_pipe); 3. nodejs defaults to autoclose when hitting EOF, which causes issues similar to this one 4. nodejs defaults to immediately starting a read, even if the user doesn't want the data from the pipe (this one might have been fixed?), which also causes issues similar to this one; 5 nodejs only supports v1.x currently, while libuv master has support for directly using Windows HANDLE objects which adds some overhead issues and limits scalability

we still can't receive more

FWIW, this comment is false. A TTY will often still receive more after an EOF.
I still don't think this PR is correct. We never handle any other error in any other place like this, as it is up to the application to handle read results correctly, and not to incorrectly autoclose a handle.
If I had the ability to do IO all over again, I would make 2 separate application handles for the separate read and write directions. Being unable to do that though, I recommend checking uv_is_writable in your keep_open decision as well as checking on the handle type. This will still give you some issues on FreeBSD (where pipes are bi-directional), but generally keeps things like this more sane. (Aside: for FreeBSD support, we would need to implement a way of watching for write errors, which is a feature that has been requested in libuv quite often, but nobody has yet tried to figure out how to do it correctly for every platform and file type)

Thx for your elaborations @vtjnash! As for the keep_open option, that will only be used on Windows, so no need to worry about FreeBSD or anything else. Checking uv_iss_writable is a helpful refinement indeed.
However, about changing the PR as suggested above, that is, ignoring a 0-read if there is no access, looks to me as in the same category as how ERROR_ACCESS_DENIED is treated in various other places in libuv/src/win. If we look at all
repo:libuv/libuv ERROR_ACCESS_DENIED occurrences, there are also instances where we do a CreateFileW() call and then "back up" if it turns out that we don't have read or write access. See in particular how ERROR_ACCESS_DENIED is handled throughout win/pipe.c.
Dropping a 0-read attempt upon ERROR_ACCESS_DENIED seems a natural thing to do, especially because we have these situations where we don't want to read anything at all (only write things) as you are pointing out above--as we don't have separate read and write directions.
NB: this way of handling ERROR_ACCESS_DENIED applies to both 0-reads in win/pipe.c, for the overlapped case and non-overlapped case.

Completely ignoring an error (resulting in losing the read error) is very different from having multiple code path to do roughly the same thing that selects between them. Having keep_open exist anywhere (especially if not existing everywhere) sounds like a portability issue foot-gun, but that is up to you, since libuv tries to be only about mechanisms and not policies.

Your case (this PR) is more akin to https://github.com/libuv/libuv/blob/4e310d0f90af29e699e2dedad5fa0dcee181a7cc/src/win/fs.c#L870-L872 where this flag gets explicitly remapped to EBADF (handle not open for reading). We might consider applying that same error remapping here too, since EBADF is more accurate than EPERM. However, we map this one incorrectly on v1.x for legacy support of nodejs. It is fixed on master (a877ca243).

Yes, thx a lot @vtjnash. Fiddling with keep_open was indeed not desirable. I've now found the place where the uv.UV_EPERM you are mentioning above "surfaces" in winloop, and there I'll skip closing the stream.
Specifically, for the record, replacing this line calling sc._on_eof(), see https://github.com/Vizonex/Winloop/blob/00fd2897f64d7a00ba5675a08419d0b8d4b94e3b/winloop/handles/stream.pyx#L821
by
 if system.PLATFORM_IS_WINDOWS and nread == uv.UV_EPERM:
      sc._stop_reading()
  else:
      sc._on_eof()

makes all tests pass;)
We're sticking with v1.x for winloop because uvloop is also still on v1.x.
So, no need for this PR anymore.


[ZT] Access for SaaS SCIM provisioning

👋Hi there, we’re going to close this PR. All PRs prior to August 12 need to be reworked due to the platform migration to Astro.


P2P support

After struggling with UPNP from Godot 3.1 release without success, I've decided to add support for P2P via Steam libraries, and it actually works :)
Look here about the Steam interface I used to achieve this:
https://partner.steamgames.com/doc/api/ISteamNetworking
The workflow for establishing P2P connection is the following:

Use sendP2PPacket() method to send the data to Steam user with some ID (you can obtain Steam user's ID, for example, from game lobby)
On the target user's machine, p2p_session_request signal is emitted. Target user should respond to this signal with acceptP2PSessionWithUser() and sendP2PPacket() with some data back.
On the initial user's machine, p2p_session_request signal is emitted. Initial user should respond to this signal with acceptP2PSessionWithUser().
Now users can send data to each other using sendP2PPacket() and readP2PPacket() methods. It is advised to call getAvailableP2PPacketSize() before using readP2PPacket() and call readP2PPacket() only if getAvailableP2PPacketSize() returned packet size with nonzero length.

Appreciate the work being done on this.  X)
Was glancing at the commit, is it incorrect to think this is directly portable to the module?

@Antokolos Damn, son!  You're speeding ahead!  Is this using the newer Steamworks 1.44 API?  I know Valve added some newer networking stuff in there.  Or is this still 1.42?
@Avencherus Yes, the module and GDNative stuff should be interchangeable with some minor differences.

If I understood correctly, these functions already were here in 1.42 API, but yes, I've used 1.44 API while developing and testing this.
Yes, Valve said that they improved networking speed in 1.44, but I think this in done under the hood. Nevertheless, it is cool, of course :)
Hope you can integrate it into the main branch easily! One point about this, please take a look at the following method:
bool sendP2PPacket(uint64_t steamIDRemote, PoolByteArray vData, int eP2PSendType, int nChannel = 0);
Maybe PoolByteArray vData parameter should be changed to const PoolByteArray& vData when integrating into main branch, I've done this because it is like this issue I've submitted earlier, with const String& s parameters. I've initially tried const PoolByteArray& vData and it crashed again in GDScript, and PoolByteArray vData is working OK in GDScript.

OK, sounds good.  The Steamworks API updates are always backwards compatible.  I planned on updating the pre-compiles to 1.44 this week.  Have yet to see what Valve actually changed in the API.
I should be able to add it pretty easy.  Going to try to port it this evening.  I must say, sir, excellent work!
Noted about the PoolByteArray.  Not sure what the difference of GDNative and the module are for that kind of stuff but I'll try with const first and see if I get a crash.

Very good work!
Do you have any example how to send for example player position? And how would you send something like a rpc like remotesync or remote to someone?

Cheers, sir!  I might have an example but am away from home until the weekend.  I'll report back when I return.
Working on a side-project that's co-op/multiplayer action so this is relavent to me too.


lovr.headset.getStatus; lovr.headset.glob;

rm the Device variant of lovr.headset.getDriver.  Now it only takes zero arguments and always returns the display driver.
Rename lovr.headset.isTracked to lovr.headset.getStatus.
lovr.headset.getStatus takes a Device and an optional TrackingType (pose, velocity, button, touch, axis, skeleton, defaults to pose).
It returns a TrackingStatus (unavailable, estimated, tracked), and a driver.
Add lovr.headset.glob as a more general version of lovr.headset.getHands.  It is equivalent to the following Lua code:

function lovr.headset.glob(filter, ...)
  local devices = { 'head', 'hand/left', 'hand/right' } -- (i.e. all the devices)
  local result = {}
  for i, device in ipairs(devices) do
    local matched = not filter or device:match(filter)
    local available = ... == nil or lovr.headset.getStatus(device, ...) ~= 'unavailable'
    if matched and available then
      result[#result + 1] = device
    end
  end
  return result
end
-- lovr.headset.glob() --> all devices
-- lovr.headset.glob('hand') --> all hands
-- lovr.headset.glob('hand/', 'pose') --> all hands with a pose
-- lovr.headset.glob(nil, 'button', trigger') --> all devices with a trigger

lovr.headset.getHands is sorta unofficially deprecated now, since if lovr.headset.glob turns out to be good you can just do lovr.headset.glob('hand', 'pose') to get the same behavior.

EDIT: It might still be nice to have getHands because you can't do lovr.headset.glob('hand') once there are more hand sub-devices like pointer, palm, fingers, etc., it would need to be lovr.headset.glob('hand/%w+$')

This enables a lot of cool device querying but it still sucks right now:

We don't separate pose and velocity into linear and angular components, so we can't detect 3DOF vs. 6DOF.  This sort of thing is important for eye tracking.  I figure we can add the separated components later (it complicates the internal getPose interface) and keep the fused "pose" / "velocity" enums to be a boolean and/or of the other two.
We still can't detect connectedness, which creates awkward situations and is kinda a bummer.  Connectedness is complicated, and I'm not sure it's even possible in OpenVR and OpenXR anymore.  It needs more thought, we don't want those drivers to always report connected/disconnected, maybe pose could be used as a proxy but that breaks gamepads too so, idk.
There is a weird conflation between "unknown/disconnected" and "not tracked".  Ideally these are separate concepts, but separating them right now would require a lot of work.  I think it would be a good change to make so we can do better status queries.
Related: It would be good to have a concept of "device capabilities" instead of always making decisions based on instantaneous tracking status.

It increasingly seems like these higher level functions like getHands/glob/getDevices belong in Lua.  Putting them in C has minimal benefit because it's just logic that does not query the hardware, isn't performance sensitive, and is trying to satisfy all the ways people could iterate/query devices.  The main factor is the convenience of having this logic readily available.

Thoughts

I really don't like the name glob(), personally, it communicates nothing about what the function does. I am not sure someone who is not a linux-head would even understand the etymology of "glob". I would suggest "getDevices" or if that sounds too long to you just "get"?

Why is "devices" in glob hardcoded? Why not just iterate over the HeadsetDriver enum as in https://github.com/bjornbytes/lovr/pull/221 ? That would mean you could get the eyes, if you wanted them.

"Estimated" tracking status corresponds to what? Oculus Mobile hand tracking with low confidence?

I think we should add one more TrackingType which is just something like "exists". I was describing a test app of mine in Slack that iterates over all devices and prints the information those devices expose. If we accept both this and the gamepad, there is no way to iterate over all devices (since hand-tracking hands don't respond to buttons and gamepads don't respond to pose). Adding "exists" would also provide one way of distinguishing between "the handset is connected, but pose tracking is lost" and "the handset is not connected at all" (especially useful with oculus mobile hand tracking hands, because they lose pose tracking frequently). (I understand OpenXR makes this information difficult to get but I think OpenXR made a bad decision there and I don't think we have to replicate their mistakes! I complained about this on their forum too 😛)

With TrackingType buttons or axis, could getStatus take one more argument to indicate which button/axis is being asked about? As I mentioned in Slack last night, currently there is no way to distinguish if a particular handset uses thumbstick or touchpad (because if the axis doesn't exist it still returns 0,0)

Instead of removing isTracked, I recommend having both getStatus and isTracked present, but with different semantics. isTracked could indicate that "at least" that status is supported. So if you say lovr.headset.isTracked("hand/left", "pose", "estimated"), this would return true if pose is estimated or tracked.

Moving some of these functions into Lua sounds reasonable, where would we define them? boot.lua?

The name can be anything
Devices isn't hardcoded, it iterates over every member of the Device enum.
Estimated corresponds to a few different situations.  Low-confidence hand tracking, "estimated" hand tracking like knuckles/vive controllers have, eye tracking where the pose of an eye is estimated from the head position instead of being derived from an actual sensor value, etc.
I really want to support the "exists" one which is what I mentioned as "connectedness" above but I don't think it's easy right now.  You can iterate over all the devices by doing lovr.headset.glob(nil), which returns everything.
getStatus accepts the button/axis in question already.
I considered this, but I didn't like having multiple ways of doing things.
I think they live best in people's Lua projects given how versatile the necessary behavior is.

Ah, sorry, got confused by the lua sample code above

"You can iterate over all the devices by doing lovr.headset.glob(nil), which returns everything" Surely that will return both connected and non-connected devices though?
"but I don't think it's easy right now" I'd say it's pretty easy: Just add the callback to the driver interface? Some drivers can definitively and easily answer the question of whether a device is connected (and ones that can't say maybe could return "exists":"estimated" for everything)? I don't think it's a good idea to limit our feature set to only those features that all drivers support. If you need a feature some drivers don't support, you can choose to ship your app without support for those drivers. But if we drop features because OpenXR does them poorly we've dropped them even on drivers where they work…

Awesome. Sorry misread the code *_*

6/7: I think keeping the lovr API small is good, but moving isTracked/getHands specifically into a third party library sounds a bit alarming. First off it is starting to get a bit troublesome that this is looking like the third release in a row where getControllers, the one function I call in every one of my lovr scripts, gets renamed *_* But also we still don't have a fantastic story for distributing scripts/libraries. I'm distributing a sizable third-party lovr lib myself that is just picking up more and more stuff, and I don't have a good way to tell people to use it other than telling them to fork my repo.
Not to say we can't rely on third party libraries, but for the basic stuff I think it's friendlier if Lovr can keep the simple stuff simple. If nothing else, think about how it would look in sample code. Every current use of getHands() would have to become getAll("hand"). Every current use of isTracked would have to become lovr.headset.getStatus("hand/left") == "estimated" or lovr.headset.getStatus("hand/left") == "tracked". The getHands change isn't actually so different here but the change to isTracked() instances seems like a real quality-of-life issue, and is harder to describe to new users…

Currently, as designed, the new getStatus function proposed in this PR does not return information but returns the level of validity of a piece of information.  So lovr.headset.getStatus('device', 'axis', 'myaxis') indicates whether you can call lovr.headset.getAxis('device', 'myaxis') in the current frame and expect to receive valid information.  The second glob function was added to return collections of devices which contain valid information for a certain property.  Note that this is a separate concept from both "the information itself" and from "the capabilities of the device".  Currently there is no way for input drivers to expose the capabilities of devices, you have to glean it implicitly by the stuff they return.
It is possible to expose connectivity information in the headset module in the same way.  The way to do this would be to call isConnected(device) to figure whether a device is connected, and getStatus(device, 'connection') to figure out if that information is valid, estimated, etc.
It doesn't seem like this would be a satisfactory solution to the problem of retrieving every connected device because getDevices(nil, 'connection') would only return the devices that are known to be connected or not.  There would need to be a second pass over the devices that calls isConnected to read the actual data, just like how isDown or getAxis is used.
Given that exposing connectivity as a tracked property would still be inconvenient for one of the use cases expressed here, it's possible that there would need to be another helper function like getConnectedDevices (iterate over all devices and filter by the actual data rather than the validity of the data), or the consideration that connectivity should not be treated as a sensor value but given some kind of special treatment.  If it was treated as special then it probably does not belong in getStatus anyway, and would need to have some other system for querying the data and filtering devices.  It's also possible that the inconsistency here is an indicator that the general system proposed in this PR is not universally useful and should be redesigned.

Currently there is no way for input drivers to expose the capabilities of devices, you have to glean it implicitly by the stuff they return.

I'm proposing adding such a function to the input drivers. At minimum the Oculus Mobile, Oculus Quest, Gamepad and Leap Motion drivers know exactly which capabilities every connected device they expose have.

It doesn't seem like this would be a satisfactory solution to the problem of retrieving every connected device because getDevices(nil, 'connection') would only return the devices that are known to be connected or not. There would need to be a second pass over the devices that calls isConnected to read the actual data

(In this case you're hypothesizing adding a 'connected' tracking type that isn't present currently, correct?)
Anyway, that (two passes, first get the list of connected devices and then query getStatus for each one's TrackingTypes) would be the approach I'd take, yes. The thing is, I can only do that second pass if I have the "all connected devices" list to iterate over in the first place.
Consider what an app that wants to discover attached devices and their capabilities would look like without the "all connected devices" iterator. I'd have to one-by-one query glob for each of "pose",  "buttons" and "axis", and build a table using the device name as a key. That is more complicated and more awkward (and might even miss things; if there is a hand-tracking hand "connected" but not currently tracking, that hand will respond "unavailable" to all of getStatus "axis", "button" and "pose"). So in that case I'd definitely prefer a "connected" TrackingType.

I'm not 100% sure now but I think there is a misunderstanding of what a 'connected' TrackingType would mean if it was added.
getStatus could also be named "getConfidence" because it returns how "valid" a piece of information is when it's queried.  getDevices, the way it exists in this PR, filters based on this confidence value.  So lovr.headset.getDevices('connected') would not return a list of connected devices.  It would return a list of devices that have a high confidence about their connectivity.  You would then need to iterate over these and call isConnected on each one:
local connectedDevices = {}
for _, device in ipairs(lovr.headset.getDevices(nil, 'connection')) do
  if lovr.headset.isConnected(device) then
    table.insert(connectedDevices, device)
  end
end
return connectedDevices

It's analogous to how getStatus('hand/left', 'button', 'trigger') gives you the confidence level of the trigger button but you still need to call isDown to get the current state of the button.  This is why I don't think a TrackingType of 'connected' has very much utility without a separate helper function, and what you are really looking for is a special-cased getConnectedDevices function that actually reads the isConnected state.  And this raises questions for me about the usefulness of querying devices by confidence levels.
I've been thinking about these queries as belonging to 3 different categories:

Capabilities -- "will valid information ever be returned?" -- These are usually static properties of the SDK/hardware.  Things like "do the hand devices have analog grip axes" or "does the headset have eye tracking".  Currently LÖVR doesn't expose this, but I think it's a really useful way to ask questions about devices that we are missing right now.
Confidence -- "is valid information currently being returned?" -- You can use this to figure out if tracking is lost, or if information is being indirectly inferred from some other source.  This is what was originally being communicated by returning nil from the various accessors, and is now being brought back by the getStatus function.
Actual Data -- "what is the information?" -- This is the stuff actually returned from getPose, isDown, getSkeleton, isConnected, etc.

I probably won't be merging this in its current form


Please add "data_type" tag to make parsing easier

Please add "data_type" tag to make parsing easier, for example the CVE JSON format has:
"data_type": "CVE" which means you don't have to guess and test to see what kind of data you're parsing. If the OSV ould add a " "data_type": "OSV" to everything that would make life much simpler. Especially if more people start using things like OSV's database_specific field to embed OSV data into other formats (cats and dogs living together, it's turtles all the way down).

Thanks for raising this! In hindsight we should have named our schema_version osv_version or something similar instead, but we are no longer able to change this for compatibility reasons.
A data_type field is a possibility, but I wonder if there are other ways we can infer this without adding another field to the schema, (e.g. with how GSD is using it today).


Caller can not be passed recursively to a call block inside a macro

Issue
It is not possible to pass a caller to a call block inside a macro.
See attached file for an example.
What I did
I defined a macro which uses a caller and calls itself(recursive) using a call block and passes its own caller to the call block.
It seem to be impossible because the following exception occures:
Traceback (most recent call last):
  File ".../jinja2cli.py", line 291, in <module>
    main(scriptfile)
  File ".../py/jinja2cli.py", line 283, in main
    output = render_template(_fc, infilename, outfilename, 'node', config)
  File ".../py/jinja2cli.py", line 249, in render_template
    _output = _loader.load(_env)
  File ".../py/jinja2cli.py", line 83, in load
    _result = _template.render(**content)
  File ".../venv/lib/python3.10/site-packages/jinja2/environment.py", line 1301, in render
    self.environment.handle_exception()
  File ".../venv/lib/python3.10/site-packages/jinja2/environment.py", line 936, in handle_exception
    raise rewrite_traceback_stack(source=source)
  File ".../jinja/test/test.jinja", line 33, in top-level template code
    {%      call(_k, _v) macro1(data.keys()) %}
  File ".../venv/lib/python3.10/site-packages/jinja2/runtime.py", line 777, in _invoke
    rv = self._func(*arguments)
  File ".../jinja/test/test.jinja", line 18, in template
    {%      call(_k, _v) macro1(_k) %}
  File ".../venv/lib/python3.10/site-packages/jinja2/runtime.py", line 777, in _invoke
    rv = self._func(*arguments)
  File ".../jinja/test/test.jinja", line 14, in template
    {{  caller(voc, None) }}
  File ".../venv/lib/python3.10/site-packages/jinja2/runtime.py", line 777, in _invoke
    rv = self._func(*arguments)
  File ".../jinja/test/test.jinja", line 19, in template
    {{          caller(_k, _v) }}
  File ".../venv/lib/python3.10/site-packages/jinja2/utils.py", line 83, in from_obj
    if hasattr(obj, "jinja_pass_arg"):
jinja2.exceptions.UndefinedError: No caller defined

How to reproduce
Run the attached example file with jinja_cli or simmilar.
What I expected
I expected the caller is executed recursive inside the macro.
Conclusion
May be this is not a Bug Report but a Feature Request
Environment:

Python version: 3.10
Jinja version: 3.1.2
test.jinja.txt

Please include reproducing code in the description rather than as an attachment.

The attachment gives more convenience for testing.
The code does not give more information that is not included in the description.
I see no reason for the required redundancy.

Why this issue is closed without a result ?

Probably because you decided to go for a (slightly) snarky response instead of including the code in the issue as expected?
Being able to check the code directly in the issue makes it much easier for us to have a look. Nothing wrong with having it attached as well. But for a first check having it immediately visible is much better than having to download an attachment...

@ThiefMaster
First thanx for the work around.
Probably davidism has a slightly wrong perception.
What I wrote was never meant snarky or can you tell me that is technically wrong what I wrote ?
Your explanation (code in issue text) sounds plausible I will remember it for the next time.
Perhaps you can teach him to be less emotionally fragile(psychologically/mentally sensitive)
and present an explanation instead as you did.
The code to render a jinja template is the "template.render()" call as it is visible in the stacktrace.
Can you explain to me what python code could cause this kind of error ?
My example file should be self contained and should work with every jinjacli tool
thus making it independent form the calling python code.
Please tell me if I am wrong and what I can improve next time.
Thank you for being so patient.

 Tip: basically calling maintainers insane is NOT a good way to get them to help you.
FYI my point was that maintainer time is valuable. If the issue has no immediately visible code, then it's less convenient for us. And thus less likely to get your question answered.
And the Python code? Again it's faster if there's code we can paste to reproduce your issue. Yes, again, we are lazy. Because humans are lazy. Make it easy for us to reproduce your issue. That implies something we can run "out of the box", and that's minimal (quite sure your example template isn't minimal).


Not merging i18n descriptions

The tool does not update "description" info in target language .xlf files when "description" part in i18n attribute is updated.
I am referring to DESCRIPTION part in the code example from below.
<div i18n="DESCRIPTION@@translation_item_id">       Some source language text...     </div>
I do have the following options in angular.json file:
"includeContext": true

Hi @co-dax, I think this is covered by a unit test - can you give details on your full config and how to reproduce?

Hi @daniel-sc, you are right that it is covered by the unite test you mentioned above and I confirm the notes are update in the case in template translations but they are not updated when they change in .ts files as descirbed at the following link https://angular.io/guide/i18n-common-prepare#i18n-metadata-for-translation.
I am using the pattern: let title = $localize":Some notes/descriptions go here@@translation_id:The actual source text to be translated";
...and if in the pattern from above I change the part Some notes/descriptions go here then that change is not reflected in the merged file.
Please let me know if I am not clear.

@co-dax I am slow again and still do not get your point.
The actual extraction of the i18n elements are done by the angular extract-i18n builder and should make no difference between ts and html.
Is it possible you re-used the "translation_id" at other places and did change the meaning only in one place? In this case, it is pure "luck" which meaning is picked by the extract-i18n builder..


mjtest crate: procedural macros for re-using mjtest cases as cargo tests

There are also some clippy warnings that need fixing

cargo fmt has no effect on my machine, though

bors retry

We also have a collition for the mj-test CI jobs
fatal: destination path 'mjtest' already exists and is not an empty directory.

I am not sure, but maybe we have to add a line to build that clones the submodules? The CI does it correctly, but I am not sure about the test infrastructure of the IPD.
git submodule update --init --recursive

* I am not sure, but maybe we have to add a line to `build` that clones the submodules? The CI does it correctly, but I am not sure about the test infrastructure of the IPD.
  ```
  git submodule update --init --recursive
  ```

./build does not invoke cargo test, so nothing fails in speedcenter

Ah, right :) but then we cannot use the build script locally for setup during devevlopment. In this case I just have to remember.

The CI fails because you cannot pass --release to cargo fmt

Ah, right :) but then we cannot use the build script locally for setup during devevlopment. In this case I just have to remember.

I have a re-write of the README.md in https://github.com/comprakt/comprakt/pull/28/commits/fcf46bdda5aa798d492aa6af15f11f07fb6ae37e which will cover git submdoule update --init --recursive.

looks good to me now. Great work!

bors r+


Adding note about MFA and CA policies to rooms-configure-accounts.md

Closes https://github.com/MicrosoftDocs/OfficeDocs-SkypeForBusiness/issues/8213.
@dstrome, could you kindly confirm? Thanks.

@JohanFreelancer9 Copy editing is needed for this PR. Thanks.

Removed CA sentence:
https://www.microsoft.com/microsoft-365/roadmap?featureid=89068

@dstrome PR has been copyedited and is ready for final review, could you please check and merge? Thanks!


mGBA cask broken: invalid file downloaded

I followed the instructions in the bug reporting guide, to no avail.
Here is what I get:
$ cask install mgba
==> Downloading https://github.com/mgba-emu/mgba/releases/download/0.5.2/mGBA-0.
######################################################################## 100.0%
==> Verifying checksum for Cask mgba
Error: It seems the App source is not there: '/usr/local/Caskroom/mgba/0.5.2/mGBA-0.5.2--osx/mGBA.app'
Error: nothing to install

Looking in /usr/local/Caskroom/mgba/0.5.2/ is a 12.5 mb invalid .xz file which "extracts" into a cpgz

I can confirm this issue - downloading the tar.xz manually and decompressing gives a tar.xz.cpgz file, leading to an endless loop of tar.xz to tar.xz.cpgz - this is usually an indication of a corrupt file, and may need to be reported upstream.


Web UI

Should render every page in sub 10kb (per https://a-k-apart.com/) and work well on phones for long form reading.

[x] investigate libraries / frameworks / build tools of this week
[x] bundle isomorphic renderer into go app
[x] learn more

basically, this is being tackled by using straight up templated HTML, no CSS/JS libararies, and a build system for it all on top of go generate and lessc


Use sensible whitespace in fbtest generator.

Removes trailing whitespace
Adds newline at end of file.

This makes it so editors that modify whitespace on save will leave the
file in the correct state.
Because https://github.com/facebook/esprima/pull/85#discussion-diff-23480413. cc @spicyj

lgtm

Lint is failing with node 0.11.15 but not node 0.11.14. It's not our code but jslint code failing to run, which is weird and actually looks like it might be a bug in jslint... Lint is passing in other node environments. We should maybe let 0.11.x fail.

Can you try rolling back the jslint dep version and see if you can find a version that doesn't fail for now?

I don't think so but I didn't try too hard. The version of jslint is from 2013. Updating actually results in the lint code running but then it fails for linting reasons.

Oh I didn't read your previous comment correctly -- it's the node version that's failing, not the jslint version.
In that case, can you just take 0.11 out of the travis config file? 0.11 is unstable anyway...

:thumbsup: Actually, it might be even better to bring in upstream again since they just fixed this (stopped using jslint entirely)

Rebased and all passing.


Refactor NetworkManager

I am looking at refactoring the NetworkManager class to make it more abstract. Currently, it is heavily linked to specific layers and methods in the TI interface (eg the ZDO). I think in many (hopefully most!) cases this is not necessary and this should be left to the implementation, not the abstract class.
So, I plan to look at removing all links to things like ZDO if I can - for example -:
networkManager.sendZDOBind() takes a ZDO_BIND_REQ class as parameter - I'd remove this and simply pass in the required parameters and move the instantiation of the ZDO_BIND_REQ to the implication class.
I think his should make it easier to implement other sticks that support higher level interfaces (eg Telegesis / Ember / XBee.....)
Any thoughts appreciated :)

I totally agree. In the long term it would be great if the current API project and jar could be split in:

an API project with no implementation
an implementation which is dongle independent
a common dongle interface API
different dongle implementations of the dongle API

We want to integrate zigbee4osgi in the Eclipse Kura project http://www.eclipse.org/kura/.
Kura runs in an OSGi framework and the above separation is very common in OSGi.

Interesting. I'm working on eclipse SmartHome which is also osgi.
Generally I'm aligned with your thinking - maybe some room for small change but not when I'm typing on a phone! :)

For your information we are branched from zb4osgi project which might already provide what you need:
http://zb4osgi.aaloa.org/

@tlaukkan, I know but that project in not very active and it's unlikely that the bugs and improvements of zigbee4java will be merged in zb4osgi. They use SVN so collaboration is more difficult.
For the same reason zb4osgi could be used by Eclipse SmartHome but it's not.
There is no problem repackaging (monolithically) zigbee4java in an OSGi bundle or plugin.
Indeed you could also slightly change your pom.xml to generate a jar file whose MANIFEST contains the necessary OSGi headers, this would be simple, so that it can be immediately consumed by an OSGi framework

@cdjackson I don't think ZDO_BIND_REQ is strictly tied to the TI ZNP protocol:
ZDO_BIND_REQ(ZToolAddress16 nwkDst,
ZToolAddress64 ieeeSrc, int epSrc,
DoubleByte cluster, int addressingMode,
ZToolAddress64 ieeeDst, int epDst) {

We could just remove references to ZTool and it would become the container for the parameters of the Bind_req Command (<IP_ADDRESS>.2 of the spec). On top of that if you have a class for the request's parameters you can keep these are around (queued), for example when directed to sleeping end devices.
However I agree that the TI ZNP API should be kept internal and should not "leak" around.
In my opinion we should create new classes, for example ZdoBindRequest, and refactor the NetworkManager API to only expose these. A first step would be to create the Zdo interface accordingly to the ZigBee spec.
Another important thing is the configuration of the NetworkManager. For example:
setZigBeeNodeMode() should be changed to setLogicalDeviceType().
setZigBeeNetwork(byte ch, short panId) should be split in setPanId() and setChannelMask(). Internally these values should be initialized accordingly to the spec (random PAN ID) and channel mask as described by the profile.
The security interface is totally missing. We will end up with a lot of getters and setters.
Sticking to the names as spelled in the spec (where it does not collides with the Java name conventions, for example the '_') would be a plus (but less friendly).
For porting to a different module/dongle we need to design a Driver interface and pass an instance to the NetworkManager (instead of passing a ZigBeePort). Finding the interface requires studying the existing protocols, like the TI ZNP, Freescale ZTC (used by the Jemma project), Telegesis, Silabs/Ember and getting their intersection. I expect that the Driver interface implements many of the interfaces of the NetworkManager so that many calls to the NetworkManager (like the ZdoBindRequest above) are simply delegated to the Driver.
While writing this I wonder what the role of the NetworkManager is. If it does not do anything useful over the Driver we could just drop it.
This is a lot of work. Is there any roadmap available for ZB4J?

You can now implement support for other hardware by implementing ZigBeeNetwork interface. This is only supported with experimental SimpleZigBeeApi which is not tightly coupled with the old message serialization implementation.


https://www.google.com/finance/markets/indexes/authorize?copy_id=3cc6375c-cbb0-44be-b697-747d4a034f88

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version:
OS Version:

Steps to Reproduce:

I suppose this is not an issue.


What is the correct method to set up a repo mirror for PMC?

Describe the issue
Need to allow systems without internet access to access package repository. Would like to use a local mirror. What is the correct method to set up a pkg repo mirror for PMC?
When did the issue occur?
Now
If applicable, what package did you attempt to install, and from which repo?
trying to install azure-cli for ubuntu
Steps to Reproduce
n/a
Actual Result
Cannot directly access PMC
Expected Result
Either have a local mirror or proxy access to PMC (local mirror preferred)
Screenshots
n/a
Additional context
n/a

I am guessing you can use a wide range of tools for this, the most obvious would be https://pulpproject.org/ because that is backing packages.microsoft.com but there are other tools stuff like https://jfrog.com/artifactory/ or https://www.sonatype.com/products/sonatype-nexus-repository -- or you can even mirror it on cli https://help.ubuntu.com/community/AptGet/Offline/Repository/

There's no official way to mirror a PMC repo locally but @Klaas- gave some good options.


PAPILIO-96 Update Activity, Added Image Upload

General info
Added an endpoint for Activity update. Modified Activity creation for Business to MULTIPART and allowed image upload
Task description

Activity update endpoint
Swap from JSON to MULTIPART for image upload (identical to User's)
Same endpoint, small change in implementation

Manual testing
For Activity update

For Activity creation for Business

Note
Ping me if something is wrong

Image can be uploaded with different size


Using scribble with blend modes causes weird rendering issues.

I'm using blend modes to mask text inside of my textboxes, and It's causing some weird rendering issue with scribble. Like, its drawing the empty space of the characters and.

Here's the relevant code that draws the text relative to the mask.
gpu_set_blendmode_ext(bm_dest_alpha, bm_inv_dest_alpha);
gpu_set_alphatestenable(true);

text.draw(text_x, text_y);

gpu_set_alphatestenable(false);
gpu_set_blendmode(bm_normal);

I don't know if this is a problem that's already been asked, or if there is a solution in the manual I haven't read yet?

Scribble uses its own shader. Alpha testing is a feature of the default native GameMaker shader. As such, alpha testing is not supported by Scribble. Alpha testing in general is expensive on the GPU and I am not inclined to provide support for it.
Instead, if you're using more recent versions of GameMaker you should looking into the new native GPU scissor functions. These will help you further with content masking. If you want to clip your text using more complex shapes then you should use the stencil buffer.


Handling Municipality with DWC Import in TaxonWorks

Describe Issue
In DWC field, municipality is an accepted field, but TaxonWorks does not have this component.
~ How should we handle municipalities? Should they:

Be included in the locality field?
Have a separate field built into TaxonWorks that matches DWC terms?

This will help in creating a completed Collection Event (see screenshot below in Expected behavior)

To Reproduce
Steps to reproduce the behavior:

When I fill out the datasheet, I separate the municipality (Bishop Hills) from locality (Bluff on W Amarillo Creek)

Then I upload using DWC-A Importer on Sandworm (INHS DWC Testing)

And I make sure it uploaded properly, and go to one of the records, click the stacked icon in the top right corner to get to the Comprehensive specimen digitization page, and check both the locality and verbatim Label fields...

See error

Expected behavior

The verbatim Label should have the information from the DWC verbatimLabel field, but that does not get populated.

In the Collecting Event field, it does not include the municipality, even though it is part of the verbatimLabel DWC field.

It would be great to see municipality as a separate field that is different from a specific locality. This may be important for biogeography analysis or understanding the distribution of sampling effort within a state/province.

Environment (please identify where you experience this bug:

Sandworm -  https://sandworm.taxonworks.org - INHS
FireFox on Mac

Thanks *very * much for the testing @brennaldecker.
Question. Is municipality a DwC Field? (Ping @debpaul )

@mjy Yes, municipalities is a DWC field = municipality (http://rs.tdwg.org/dwc/terms/municipality)

@LocoDelAssembly We'll need to map it to custom data attribute with the municipality IRI as discussed in the meeting this morning.  Likely create or match on demand?

@brennaldecker steps to capture (will export with new export coming)

Add a Predicate in the "Manage controlled vocabulary terms"
Give it a name and defintion, but most importantly use http://rs.tdwg.org/dwc/terms/municipality (double checking not the IRI version) in the URL field.
GOTO project->preferences (or have your project admin do it)
Click "Collecting Event"
Select your Predicate (is autosave)

At this point you will see a Municipality field in Custom attributes sections

@debpaul I believe we can close this thanks to your work with Jared and Hernán?

Currently it works as data attribute, no special handling, just the default behavior of the importer checking if there is a DwC term enabled in the project as data attribute for CO and/or CE matching the one in the dataset. No native import is performed, and I think municipality is not exported either (although the field itself does exist in dwc_occurrences table).


[6.x] The refresh() fix to support AsPivot trait.

This PR fixes #31811, please see issue for more details.

@LastDragon-ru it's best to describe in the PR why this is needed (see the PR template).

@driesvints, done

@LastDragon-ru thanks!


Should nixnet.db.Database use in-memory database as default?

The FrameInStreamSession and FrameOutStreamSession sessions both default to the ':memory:' name for databases.
Should we also allow a default of ':memory:' for the parameter database_name in the nixnet.db.Database constructor?
This would further abstract python users from having to explicitly name ':memory:' in their code to access the in-memory database. I believe there would be no further need for users to use that particular string for the in-memory database.

I learned a number of interesting things from talking with Jason Smith:

Jason pointed out that the stream sessions in the LV API default to to the :memory: database, so the python API matches there.
Jason told me that there is nothing special about :memory:. You can get an in-memory database by specifying :anything: (any name between colons). In-memory databases are process wide. They start out as an empty database, and retain any modifications until the last reference is closed. So, if two threads open the same in-memory database, they will share it and see any changes made by the other thread.

Also, I took a closer look at our API. Even if we allowed the Database class constructor to default to :memory:, you still have to pass a database name instead of a ref to session constructors. Do we also allow an optional parameter on those for the database name to be :memory:? If we did, it would then be less clear to the user that the session is using the same database created when they called database.Database(). It would only be clear if the user could pass a database object to the session, This is starting to get messy.
At this point, I don't think we should take any action on this issue.


Initial upload of code, update README file

Load code to project and update readme file with placeholder text.

Done.  Code and readme updated.


Security vulnerability from clipboardy version

title is using<EMAIL_ADDRESS>which uses<EMAIL_ADDRESS>which in turn uses<EMAIL_ADDRESS>
<EMAIL_ADDRESS>contains a ReDoS vulnerability. Consider updating clipboardy to v4, which will likely resolve this issue.

Thanks @leerob for looking into this ❤


Renamed Classes Service->FlashServer and Flash->FlashServerHelper

Renamed Classes Service->FlashServer and Flash->FlashServerHelper to names better fitted for future development

resolved merge conflicts (i hope?)


None of my physical device or emulator/simulator is accepting isGooglePaySupported

I've tried in 3 different android real device and iPhone 11 and none have accepted the support. Is it correct?
tested on expo and bare react native CLI
import { StripeProvider, useGooglePay } from "@stripe/stripe-react-native";

function PaymentScreen() {
   const { isGooglePaySupported } = useGooglePay();
   if (!(await isGooglePaySupported({ testEnv: true }))) {
        Alert.alert("Google Pay is not supported.");
        return;

         const { error } = await initGooglePay({
            testEnv: true,
            merchantName: "anything",
            countryCode: "US",
            billingAddressConfig: {
              format: "FULL",
              isPhoneNumberRequired: true,
              isRequired: false,
            },
            existingPaymentMethodRequired: false,
            isEmailRequired: true,
          });

    if (error) {
      console.log(error.code, error.message);
      return;
    }
  }
  ...
}

function App() {
  return (
    <StripeProvider publishableKey="pk_test_xxx"  ...>
      <PaymentScreen />
    </StripeProvider>
  );
}

If I comment the conditional code the initGooglePay throws this error
[TypeError: _NativeStripeSdk.default.initGooglePay is not a function. (In '_NativeStripeSdk.default.initGooglePay(params)', '_NativeStripeSdk.default.initGooglePay' is undefined)]

otherwise isApplePaySupported its ok!
Which phones accept google payment?

Pixel XL, readmi 11, samsung a32

can you check your AndroidManifest.xml file for:
  <meta-data
    android:name="com.google.android.gms.wallet.api.enabled"
    android:value="true" />

I have already added this

We are relying on stripe-android's GooglePayPaymentMethodLauncher and returning the result of that, so I think that either there is missing app setup, or missing device setup for Google Pay.
If this only happens in production, it could be that one of these steps is unfinished


IxApplicationContext  not working anymore

What happened?
IxApplicationContext  was working  with Modal component and was successfully  passing the  data when I was using version 2.0.3
After upgrading ix version from 2.0.3 to 2.0.4, it stopped working.
What type of frontend frameware are you seeing the problem on?
React
Which version of iX do you use?
v2.0.4
Code to produce this issue.
<IxApplicationContext>
  ....
  </IxApplicationContext>

Please provide detailed code which outlines your problem. The basic functionality of preventing the creation of a new context is working properly. The current test code is shown below. Please feel free to update it to represent your specific problem with the IxApplicationContext.
main.tsx:
import { BrowserRouter, Route, Routes } from 'react-router-dom';
import { IxApplicationContext } from '@siemens/ix-react';
import ReactDOM from 'react-dom/client';
import React from 'react';
import App from './App';

import<EMAIL_ADDRESS>import './index.css';

ReactDOM.createRoot(document.getElementById('root') as HTMLElement).render(
  <IxApplicationContext>
    <BrowserRouter>
      <Routes>
        <Route path="/" element={<App />} />
      </Routes>
    </BrowserRouter>
  </IxApplicationContext>
);

App.tsx:
import {
  IxButton,
  IxModalContent,
  IxModalFooter,
  IxModalHeader,
  Modal,
  ModalRef,
  showModal,
} from '@siemens/ix-react';
import React, { useRef } from 'react';

function CustomModal() {
  const modalRef = useRef<ModalRef>(null);

  const close = () => {
    modalRef.current?.close('close payload!');
  };
  const dismiss = () => {
    modalRef.current?.dismiss('dismiss payload');
  };

  return (
    <Modal ref={modalRef}>
      <IxModalHeader onCloseClick={() => dismiss()}>
        Header
      </IxModalHeader>
      <IxModalContent>Content</IxModalContent>
      <IxModalFooter>
        <IxButton outline onClick={() => dismiss()}>
          Cancel
        </IxButton>
        <IxButton onClick={() => close()}>OK</IxButton>
      </IxModalFooter>
    </Modal>
  );
}

function App() {
  async function show() {
    await showModal({
      content: <CustomModal />,
    });
  }

  return <IxButton onClick={show}>Show</IxButton>
}

export default App;

Alright, I will provide code snippet whenever I have time.

This issue will be closed due to inactivity. If the issue persists, please open a new one and include the additional information previously requested.


How to make LineEdit width smaller?

Hi,
Using the style attribute I'm trying to have a flx.LineEdit a width of 30px, but no matter what I try the minimum size is always somewhere around 80px. I also tried putting it inside a flx.HFix and setting it's width to something small, but then I get this:

(The left LineEdit is inside a HFix)
The code for this is:
with flx.HFix(flex=1):
    with flx.HFix(flex=1, style="max-width: 30px;"):
        item = flx.LineEdit(
            text="XX",
            flex=0,
            style=f"""
                font-weight: bold;
                text-align: center;
                width: 100%;
                display: block;
            """,
        )
    flx.Label(text=":", flex=1)
    line_edit_right = flx.LineEdit(
        text="XX",
        flex=0,
        style=f"""
            font-weight: bold;
            text-align: center;
            width: 100%;
            display: block;
        """,
    )

Any idea how to set a fixed width of a LineEdit?

Found the solution: it's DEFAULT_MIN_SIZE. By default its (100, 28).
So subclassing a LineEdit like so works:
class CustomLineEdit(flx.LineEdit):
    DEFAULT_MIN_SIZE = 5, 28


lollipop plot does not have domain info on grhc38 genome nexus

see e.g. https://grch38.genomenexus.org/variant/7:g.55181378C>T

Seems like the grch38.genomenexus.org/pfam/domain endpoint is being called with a list of numbers instead of proper pfam accession ids. We somehow call it with ["185.0", "361.0", "57.0", "713.0", "505.0"] and get an empty response as a result. The proper list should be something like ["PF00757", "PF07714", "PF14843", "PF01030", "PF01030"]

https://grch38.genomenexus.org/ensembl/canonical-transcript/hgnc/EGFR?isoformOverrideSource=mskcc
Looks like the pfamDomains information returned by this endpoint is incorrect:
{
    "transcriptId": "ENST00000275493",
    "geneId": "ENSG00000146648",
    "refseqMrnaId": "NM_005228",
    "ccdsId": "CCDS5514",
    "hugoSymbols": [
        "EGFR"
    ],
    "proteinId": "ENSP00000275493",
    "proteinLength": 1210,
    "pfamDomains": [
        {
            "pfamDomainId": "185.0",
            "pfamDomainStart": 338
        },
        {
            "pfamDomainId": "361.0",
            "pfamDomainStart": 480
        },
        {
            "pfamDomainId": "57.0",
            "pfamDomainStart": 167
        },
        {
            "pfamDomainId": "713.0",
            "pfamDomainStart": 965
        },
        {
            "pfamDomainId": "505.0",
            "pfamDomainStart": 636
        }
    ],
    "exons": [...],
    ...
}

Looks like the problem is the data file we get the pfam information from: https://raw.githubusercontent.com/genome-nexus/genome-nexus-importer/51d5840a3f09d4fc44f0280b57d79b1c24a75de8/data/grch38_ensembl95/input/ensembl_biomart_pfam.txt
This file has a Protein stable ID column but the data rows do not have any data corresponding for that column. In other words we have 7 columns in the header but data rows have only 6 columns. This causes incorrect parsing of the file.


Faceted Cylinders

I am not sure what these are technically called, but it would be nice to have them for designing nuts and screws.

https://math.stackexchange.com/questions/41940/is-there-an-equation-to-describe-regular-polygons


Feature Request: History or browser cache settings?

Feature Requested
As far as I know, the browser cache takes up about 1G or so, and I'd like to know where the cache folder is for this plugin, or can set its path.
Also hopefully there will be added functionality to delete history, cookies, cache, etc.
I see in the description that there is a Clear browsing history command, but after installing the latest version (0.9.12) I can't find it in the command panel of obsidian.
Relevant Screenshot
No response
Checklist

[X] The feature would be useful to more users than just me.

Fixed.


Redraw stars on end of window resize.

@toxoplasmotic Mind taking a look at this? For some reason I can't seem to request a review from you formally.

Sorry, GitHub email notifications were going straight to the spam folder.
The code looks ok to me. I assume the setTimeout and clearTimeout junk is necessary, or else why would it be there? :)

It's all good! Yeah, those are there to debounce the resize event. I didn't want to pull in something like underscore.js just to debounce events, so I just rolled my own with the help of SO.


ctx in workflow seems to assign null after task execution

SUMMARY
I have a simple workflow with a core.remote action to execute a shell script. The workflow input has a few variables and those are all accessible in the task itself, however, after the task is executed all these input variables are set to null values. It makes it difficult to get the hostname output from the results of the task. Even the vars are assigned null values if they're not being published.
action:
name: "<my action>"
pack: "<my pack>"
description: "does stuff"
runner_type: "orquesta"
entry_point: "workflows/<my workflow>.yaml"
enabled: true
parameters:
  kitchen_params:
    type: "object"
    default:
      file: "<my file var>"

  timeout:
    default: 300

  failed_string:
    default: "Error"

workflow:
version: 1.0
description: "does stuff"

input:
  - kitchen_params
  - hostname
  - failed_string
  - timeout
  - cwd

vars:
  - fail_str: <% ctx("failed_string") %>
  - host: <% ctx("hostname") %>

tasks:
  # [192, 55]
  execute_job:
    action: "pack_res_pentaho_reports.execute_my_job"
    input:
      kitchen_params: <% ctx("kitchen_params") %>
      hosts: <% ctx("hostname") %>
      timeout: <% ctx("timeout") %>
      cwd: <% ctx("cwd") %>
     # next:
       # - when: <% ctx().failed_string and (result().get(ctx().hostname).get('stderr').matches(ctx().failed_string) or result().get(ctx().hostname).get('stdout').matches(ctx().failed_string)) %>
         # do: fail

output:
  - msg: <% ctx() %>

The output of msg is:
{
  "output": {
    "msg": {
      "st2": {
        "action_execution_id": "<id>",
        "api_url": "https://<st2 url>/api/v1",
        "user": "<me>",
        "pack": "<my pack>",
        "action": "<my action>",
        "runner": "orquesta",
        "workflow_execution_id": "<id>"
      },
      "parent": {
        "re-run": {
          "ref": "<id>"
        },
        "trace_context": {
          "id_": "<id>"
        },
        "user": "<me>",
        "pack": "<pack>",
        "rbac": {
          "user": "<me>",
          "roles": [
            "admin"
          ]
        }
      },
      "kitchen_params": {
        "file": "<my file>",
      },
      "hostname": null,
      "failed_string": null,
      "timeout": 300,
      "cwd": null,
      "fail_str": null,
      "host": null
    }
  }
}

You can see everything except timeout is reassigned null values.  Even the vars fail_str and host are reassigned null values when they're assigned values early on.
I'm not sure if I'm missing something here or if this is a bug.
STACKSTORM VERSION
Paste the output of st2 --version:
st2 3.6.0, on Python 3.6.8
OS, environment, install method
OL7 in an HA cluster
Steps to reproduce the problem
View the action files above
Expected Results
After task execution the previous input and vars shouldn't be reassigned null values.
Actual Results
After task execution input and vars are reassigned null values.

Can you show how this <my pack>.<my action> is being called?

Can you show how the action <my pack>.<my action> is being called?

Its listed below, but after looking at it I think I realize what's happening.
The parent action executing the workflow doesn't have defaults set for those inputs so they're being set as null by default in the context. My assumption here was that <my pack>.<my action> defaults were being set in the context which isn't the case and makes sense that it isn't.
Is it Friday yet?
name: "<my action>"
runner_type: "remote-shell-cmd"
description: "does stuff"
enabled: true
parameters:
  kitchen_params:
    type: "object"
    required: true

  timeout:
    default: 300
  kwarg_op:
    immutable: true
    default: "-"
  cwd:
    default: "{{ kitchen_params.file.rsplit('/', 1)[0] }}"
  cmd:
    immutable: true
    default: "sh <path to shell script> -no-rep {% for k,v in kitchen_params.items() %}{{ kwarg_op }}{{ k }}='{{ v }}' {% endfor %}"
  hosts:
    default: "<my host>"
  username:
    immutable: true
    default: "<service username>"


Enable API Compat for TorchSharp

Can we enable API Compat for TorchSharp?   It’s part of the .NET SDK since 6.0.
Enabling it can be done with these steps:
.NET Package Validation - .NET | Microsoft Docs
This will help flag when changes are made that would break the API surface.  You can still choose to make those changes if you want to suppress the errors, but this will make it clear when breaking changes are made.

Sounds like a great idea. Can I talk you into volunteering to do it? :-)

Sure, I'll submit a change that does it.


PIR on GPU

http://developer.amd.com/resources/articles-whitepapers/opencl-optimization-case-study-simple-reductions/
Just a place to track progress

an initial version of this exists as of 3e1b8b61970930

A "should-be-pretty-efficient" version of this is in progress at https://github.com/ryscheng/pdb/tree/pipelined-pir

Resolved by #19


Can't compile osx

The dependancy gdk is failing to compile, but I can compile it if I pull it down separately.  I'd really like to try out SolidOak, but I could not compile it on Linux or OSX.
  Compiling gdk v0.0.1 (https://github.com/rust-gnome/gdk#7bd0d203)
/Users/tbelaire/.multirust/toolchains/nightly/cargo/git/checkouts/gtk-38cf3f4d9926c12a/master/gtk-sys/src/enums.rs:816:47: 816:60 error: use of undeclared trait name `std::num::FromPrimitive`
/Users/tbelaire/.multirust/toolchains/nightly/cargo/git/checkouts/gtk-38cf3f4d9926c12a/master/gtk-sys/src/enums.rs:816 #[derive(Clone, PartialEq, PartialOrd, Debug, FromPrimitive, Copy)]
                                                                                ^~~~~~~~~~~~~
/Users/tbelaire/.multirust/toolchains/nightly/cargo/git/checkouts/gtk-38cf3f4d9926c12a/master/gtk-sys/src/enums.rs:816:47: 816:60 note: in expansion of #[derive_FromPrimitive]
/Users/tbelaire/.multirust/toolchains/nightly/cargo/git/checkouts/gtk-38cf3f4d9926c12a/master/gtk-sys/src/enums.rs:816:47: 816:60 note: expansion site
error: aborting due to previous error

$ rustc --version
rustc 1.1.0-nightly (f9e53c7f2 2015-04-24) (built 2015-04-24)

Ah I think I just need to update my fork. I will do that tomorrow (i'm
drinking right now and won't be able to tonight...).
On May 1, 2015 7:26 PM, "Theo Belaire"<EMAIL_ADDRESS>wrote:

The dependancy gdk is failing to compile, but I can compile it if I pull
it down separately. I'd really like to try out SolidOak, but I could not
compile it on Linux or OSX.
Compiling gdk v0.0.1 (https://github.com/rust-gnome/gdk#7bd0d203)
/Users/tbelaire/.multirust/toolchains/nightly/cargo/git/checkouts/gtk-38cf3f4d9926c12a/master/gtk-sys/src/enums.rs:816:47: 816:60 error: use of undeclared trait name std::num::FromPrimitive
/Users/tbelaire/.multirust/toolchains/nightly/cargo/git/checkouts/gtk-38cf3f4d9926c12a/master/gtk-sys/src/enums.rs:816 #[derive(Clone, PartialEq, PartialOrd, Debug, FromPrimitive, Copy)]
^~~~~~~~~~~~~
/Users/tbelaire/.multirust/toolchains/nightly/cargo/git/checkouts/gtk-38cf3f4d9926c12a/master/gtk-sys/src/enums.rs:816:47: 816:60 note: in expansion of #[derive_FromPrimitive]
/Users/tbelaire/.multirust/toolchains/nightly/cargo/git/checkouts/gtk-38cf3f4d9926c12a/master/gtk-sys/src/enums.rs:816:47: 816:60 note: expansion site
error: aborting due to previous error
$ rustc --version
rustc 1.1.0-nightly (f9e53c7f2 2015-04-24) (built 2015-04-24)
--
Reply to this email directly or view it on GitHub
https://github.com/oakes/SolidOak/issues/17.

This is now fixed.

Yup, thanks.


Hyundai Azera: update torque params

Do you have any routes to back this up?

We don't want to leave PRs open without an immediate path to merging. You can open an issue and I'll check it out if you have no data.