There are some files that are not decompressed: Output log

Output log:
Import: Game file 'data.unity3d' has been found
Import: Unable to read GameSkin, because some assemblies are missing
Import: Unable to read Amphibians_data, because some assemblies are missing
Import: Unable to read Arctic_data, because some assemblies are missing
Import: Unable to read Australia_data, because some assemblies are missing
Import: Unable to read Baby Animals_data, because some assemblies are missing
Etc...

It inform you that ripper unable to export monobehaviours, because you didn't include assemblies in processing.

@mafaca Oh, okay. And in that case what should I do or if it can be done?

If you need to export monobehs, drop game assemblies along with other files. If you don't, just ignore those warnings.


Fixing the rounding at the bottom of recently played cards

Hello, I would like to fix the rounding of the recently played card, so that all the corners would be rounded correctly
Original

Clone

Hey @h3nrey I've assigned this to you, happy codding :)


hashHistory does not support push. It only supports pushState

This is an issue because other parts of the code assume push to be available. https://github.com/reactjs/react-router/blob/master/modules/Link.js#L100
Version
2.0.0
Steps to reproduce
import { hashHistory } from 'react-router';
console.log(hashHistory.push) # undefined
I would love to make a pr, but I am not sure what the right fix should be. Currently I added the push function myself before passing the hashHistory into the Router.
hashHistory.push = (param) => {
  if (_.isString(param)) {
    hashHistory.pushState(null, param, null);
  } else {
    hashHistory.pushState(param.state, param.pathname, param.query);
  }
};

Your install is messed up.

it works with<EMAIL_ADDRESS>but<EMAIL_ADDRESS>broke it.


Consider removing .pem files on postinstall

This is just an aesthetic change, but the giant red messages in chrome about .pem files is pretty scary for people that don't understand they are just warnings.  We handle this in our chrome extensions with an npm postinstall hook that removes them in all the dependencies.  See https://github.com/iceddev/git-splainin/blob/master/package.json#L20 and https://github.com/iceddev/git-splainin/blob/master/gulpfile.babel.js#L41-L43 for an example.

I am aware of this, but this only occurs when installing the extension in developer mode. When the extension is published on the store it won't come with node_modules directory and it won't present red messages.

Thanks for considering it.  We had some developers working on projects that thought these were actual errors, so we added the postinstall to improve contributor workflow.

If you want, you can send a PR for that.
That would be nice.
Pozdrav,
Mario Basic
http://basicit.company

From: Blaine<EMAIL_ADDRESS>Sent: 30.6.2015. 20:55
To<EMAIL_ADDRESS>Cc: Mario<EMAIL_ADDRESS>Subject: Re: [chrome-wakatime] Consider removing .pem files on postinstall (#33)
Thanks for considering it.  We had some developers working on projects that thought these were actual errors, so we added the postinstall to improve contributor workflow.

Reply to this email directly or view it on GitHub:
https://github.com/wakatime/chrome-wakatime/issues/33#issuecomment-117301551


'Dynamic Routing : Adding nested routes' not working when page is refreshed OR URL typed on address bar

Reproduction
Is the same as https://github.com/vuejs/router/issues/1777 but with new information (page refresh)
Steps to reproduce the bug
If the page added by addRoutes is refreshed, the page does not appear.
It only works with programmatic navigation (push)
I believe that if I can load the main component (APP) after adding the routes (which I obtained through an API request), it will work
Expected behavior
Page loads
Actual behavior
page not load
Additional information
As commented, it was reported previously, but no solution was provided

The reason is on the other issue…


Customizing macOS app bundle with flet pack not working

As described here: https://flet.dev/docs/guides/python/packaging-desktop-app/#customizing-macos-bundle
Code example to reproduce the issue:
flet pack app/app.py --name Tuttle --icon app/assets/images/icon.png --product-name Tuttle --product-version 1.0

Describe the results you received:
The resulting .app file gets the name and the icon. However, when starting the app with double click:

the app appears in the Dock with the custom name and icon and a startup animation
the app disappears from the Dock
after some loading time, the app reappears in the Dock:

with the flet default icon
with the name "Flet"
apparently unaffected by the --product-name and --product-version arguments

Flet version (pip show flet):
Version: 0.3.2

Operating system:
macOS 13.1

Try running it on a different computer. While developing/testing the feature I noticed macOS does a really hard caching of app bundles. You can also inspect Flet app bundle to see if its AppIcon.icns and .plist contains modified data. It's being unpacked into $HOME/.flet/bin/{version}/{product-name}.app folder.
Also, this gist to clear icon cache helped me a lot.

I don't know why, but what worked for me is deleting the content of ~/.flet/bin.
Clearing the cache did not work, possibly because of permissions.

Good. What do you have there when running your bundled app?

A folder flet-0.3.2 with the customized .app bundle.
ps.

How to set icon, product name etc. when running the app before packaging (flet app/app.py)
Can the icon be set from an .icns file instead of a .png file?

Try flet build.


Error while export objects as text "[17367042] The type '5056' was not defined for the function."

If I try to export objects as text I get this error.
Image is mcr.microsoft.com/dynamicsnav:2016-cu12-de
PS C:\run> Export-NAVApplicationObject -Username test -Password test -DatabaseName test -Path c:\test.txt -DatabaseServer test.database.windows.net
Export-NAVApplicationObject : : [17367042] The type '5056' was not defined for the function.
At line:1 char:1
+ Export-NAVApplicationObject -Username n4devvm -Password Java6667 -Dat ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Export-NAVApplicationObject

Are you trying to use the export-navapplicationobject to export objecs from an Azure SQL Server?
I don't know whether that is supported - but it has likely nothing to do with docker.
I think you would find the same behavior if you download the DVD, install it and try, right?

Are you trying to use the export-navapplicationobject to export objecs from an Azure SQL Server?
I don't know whether that is supported - but it has likely nothing to do with docker.

Yes. It worked definitely from an azure sql server until last week very well.
It still works with these images
mcr.microsoft.com/dynamicsnav:2017-cu14-de-ltsc2019
mcr.microsoft.com/dynamicsnav:2018-cu12-fi-ltsc2019
It's the same azure database server with same credentials, just another database.

Not sure whether NAV 2016 supports Azure SQL at all.
You can try to download and install the DVD and see whether it gives the same result.

I tested the export with another database for nav2016 on the same Azure SQL. mcr.microsoft.com/dynamicsnav:2016-cu12-de works also with Azure SQL.
It seems to be something with this specific database.


autogenerated-437

Should the new generated resource specs be put into the magic-module-specs/specs folder?
Magic Modules does not seem to need the author and version_added fileds in terraform.yaml files.
There seems to be a different name in resources.json (apimanagementdiagnostic) and the new generated resource folder (apimanagementapidiagnostic).

Hi @zikalino , let me answer the questions here:

Should the new generated resource specs be put into the magic-module-specs/specs folder?

I think so.

Magic Modules does not seem to need the author and version_added fileds in terraform.yaml files.

You are right, they are only required in Ansible. I have sent you a sample ansible.yaml and terraform.yaml before my vacation, you can take a look.

There seems to be a different name in resources.json (apimanagementdiagnostic) and the new generated resource folder (apimanagementapidiagnostic).

I think it is not necessary for you to change that file.


[CT-2243] [Regression] dbt seed doesn't work on certain cases (large row counts)

Is this a regression in a recent version of dbt-redshift?

[X] I believe this is a regression in dbt-redshift functionality
[X] I have searched the existing issues, and I could not find an existing issue for this regression

Current Behavior
I'm not 100% sure when does it happen, but I'm unable to seed CSVs that I previously was able to seed.
I'm getting the following error:
17:00:52  Finished running 14 seeds, 2 hooks in 0 hours 1 minutes and 22.77 seconds (82.77s).
17:00:52
17:00:52  Completed with 3 errors and 0 warnings:
17:00:52
17:00:52  Runtime Error in seed numeric_column_anomalies_training (data/training/numeric_column_anomalies_training.csv)
17:00:52    'h' format requires -32768 <= number <= 32767
17:00:52
17:00:52  Runtime Error in seed dimension_anomalies_training (data/training/dimension_anomalies_training.csv)
17:00:52    'h' format requires -32768 <= number <= 32767
17:00:52
17:00:52  Runtime Error in seed any_type_column_anomalies_training (data/training/any_type_column_anomalies_training.csv)
17:00:52    'h' format requires -32768 <= number <= 32767
17:00:52
17:00:52  Done. PASS=11 WARN=0 ERROR=3 SKIP=0 TOTAL=14

Expected/Previous Behavior
I should be able to seed them.
Steps To Reproduce

Load this file to your seeds directory.
Run dbt seed.

Here's another file if needed.
Relevant log output
No response
Environment
- OS: macOS
- Python: 3.9.6
- dbt-core (working version): 1.4.0
- dbt-redshift (working version): 1.4.0
- dbt-core (regression version): 1.5.0b2
- dbt-redshift (regression version): 1.5.0b1

Additional Context
No response

Thanks for discovering and reporting this @elongl 🏆
I was able to confirm this as a regression introduced in dbt-redshift 1.5.0b1. My guess is that it has something to do with us using a new database driver. We migrated from using psycopg2 to redshift-connectorin https://github.com/dbt-labs/dbt-redshift/pull/251.
It appears to be something related to the length of the seed file rather than the content itself.
e.g., the dimension_anomalies_training.csv you provided me gave the exception you reported, but once I split the same content into a max of 3000 lines per file instead, it worked.
I don't think it's purely the number of lines since numeric_column_anomalies_training.csv needs to be split into files with fewer number of lines than dimension_anomalies_training.csv. So probably something having to do with an underlying number of bytes instead.

A workaround you can use:

set the max batch size for seeds within your project

macros/get_batch_size.sql
{% macro get_batch_size() %}
  {{ return(1000) }}
{% endmacro %}

If this hits the beta, it's not a "regression" TM ;)
So I'll remove the label.
@dbeatty10, do you think that it's just the SQL statement that's too long?
Looking at the log:
[0m21:39:05.373543 [debug] [Thread--1 (]: Redshift adapter: Error running SQL: insert into "ci"."DBT_fleid_2243"."dimension_anomalies_training" ("updated_at", "platform", "version", "user_id") values
(%s,%s,%s,%s),(%s,%s,%s,%s),(%s,%s,%s,%s)...
...
(%s,%s,%s,%s),(%s,%s,%s,%s),(%s,%s,%s,%s)
[0m21:39:05.373706 [debug] [Thread-1 (]: Redshift adapter: Rolling back transaction.
[0m21:39:05.373798 [debug] [Thread-1 (]: On seed.ct_2243.dimension_anomalies_training: ROLLBACK
[0m21:39:05.554898 [debug] [Thread-1 (]: Timing info for seed.ct_2243.dimension_anomalies_training (execute): 2023-03-01 21:38:57.320592 => 2023-03-01 21:39:05.554739
[0m21:39:05.555464 [debug] [Thread-1 (]: On seed.ct_2243.dimension_anomalies_training: Close
[0m21:39:05.586023 [debug] [Thread-1 (]: Runtime Error in seed dimension_anomalies_training (seeds/dimension_anomalies_training.csv)
  'h' format requires -32768 <= number <= 32767

That last error 'h' format requires -32768 <= number <= 32767 still feels like a data value issue to me. Are we sure it's a specific row that's fishy towards the end of the file?
@sathiish-kumar does that ring a bell to you at all?

@Fleid confirming with my colleague who manages the python driver on whether she has seen this before. Without knowing too much about what the exact query was, one guess here is if the data type that is being used is incorrect (they appear to be using string instead of a number type?)? Apologies if this is an already foregone conclusion.

You can take inspiration from how we insert rows if you're interested.

@Fleid yes, I think the statement is too "long", and it just depends what too "long" actually means 🤔
This thread has an interesting comment:

Just discovered another limit ... you can only insert up to 32,768 (short/2byte) parameters into a SQL statement. Something you can definitely hit before 16MB, if you have small columns.

@sathiish-kumar it really looks like the statement is just too long now, but it wasn't before.
That's what surprising to me though @dbeatty10, was the previous connection library working some magic under the scene to split that up? Or some default option changed? That's weird.

Yeah, I'm not sure how psycopg2 was handling this differently than redshift-connector 🤷

After discussion with the Redshift team, there isn't anything that can be done at library level. If we want to restore the behavior, we will need to add new functionality in dbt-redsfhit.
Short term, there is nothing to be done except:

staying on the older library (dbt-redshift 1.4)
splitting the seeds in 5 to 10K files and union-ing them post ingestion

Medium term, I was thinking of closing this issue as won't fix and opening a new issue asking for help for an enhancement. But I'd rather just re-tag this one if nobody minds.

@Fleid Care to elaborate a bit about why is this a no-fix?
I think it's a pretty basic feature that dbt offers and it's not going to work on one of the most popular adapters.

@Fleid converted this from a bug into an enhancement / feature request. And then he also labeled it as help_wanted if a motivated community member wants to take it on. He did these conversions instead of closing this issue as wontfix and then opening a brand new issue.
I didn't deeply consider how you insert rows @elongl, but maybe something similar might be a good path forward here.

Thanks @dbeatty10 :)
@elongl this is an imperfect but honest take on the topic:

Seeds are not built to handle "large" volume of data. The fact that "large" row counts could be loaded via dbt-redshift in the first place, to me is a nice side effect more than a core capability. This is my personal opinion, and I recognize that it's a bit spicy
We want the new library to connect to Redshift much more than not breaking large row counts seeds. The connector unlocks a lot of scenarios, and using it remove long term tech debt. Plus there are workarounds for large seeds
Restoring the lost capability requires development time, which is weighted against all the other work that needs to happen in dbt-redshift and the other adapters we support. It's of low priority against the rest of that work. The mechanism for us then is to tag the work as help_wanted and hope a contributor will be able to help

I recognize that this is not a satisfactory answer. Something worked in 1.4, and we know it won't in 1.5. I'm sorry we can't do better.

@misteliy we totally understand your perspective on this.
Regardless of how this is labeled (bug vs. enhancement), these three options are the best we can offer at this time:

workaround using get_batch_size
label this issue as help_wanted with the hope that a open-source contributor will raise a pull request that we can review
continue using dbt-redshift 1.4.x until one of the above works

@dbeatty10 @Fleid even if we agree that loading "large" files is not a right use-case for dbt seed, we just can't say it's not a bug, it's a feature and move on for plenty of reasons:

That issue breaks existing dbt projects without any prior notice.
Such decision should be taken on dbt-core level, not dbt-redshift, be documented as a breaking change, and be consistent across various adapters.
Proper logic should be handled on the dbt side (e.g. rejecting seeds above some file size), not by some random error with no obvious meaning.
The "right usage" boundaries should be clearly defined, now we don't even know what "large" file means due to the above point.

Personally I disagree with labelling such significant regressions with help_wanted label and just shifting the responsibility onto the community, because such attitude lowers trust in the project's stability and maturity. dbt-core is of course an open-source library, but dbt Labs itself is not a non-profit company and this way you also affect your actual customers. I strongly believe any bugs breaking existing projects should be treated with a high priority by dbt team.
Having said that, of course we are going to play with a workaround, but I really wanted to highlight it shouldn't be a way to go.
By the way, what does help_wanted really mean at the moment? You would accept a fix or you would rather accept making this bug an actual feature? It's not really clear what's your direction here.

I would highly encourage the AWS team to look into psycopg2 and how they magically solved the problem of “large” seeds. To me this is clearly a driver issue because with the previous version it worked. So maybe you can share the technical response of the AWS team which details out how psycopg2 is solving it and why it’s not possible with the AWS native redshift driver…

@jaklan your points are entirely valid. I 100% agree that the proper way to address this issue is by keeping it as a bug, and either fixing it, or handling the new behavior in a more elegant way (like the ones you described). I had hoped that my initial comment reflected that point of view, but now I'm realizing I may not have been clearer on that.
But I need to be realistic. We don't have the capacity to do that at the moment. I'd rather flag it to the community as an area where we need help, than let it rot in my backlog. Because that is what would happen right now. It's a hard decision, but between seed size and any of the other open regressions (% being rejected where it shouldn't, timeouts being shortened to uselessness, transactions not being committed, or SSL support being dropped...), I'm prioritizing the later. That is because either the impact is wider/deeper or there is no workaround yet.
When the rest of these regressions are handled, and if this issue is not resolved by the community in the meantime, we can certainly re-visit this decision. I'm sorry I don't have a better answer here, and I hope you understand.

Workaround
We lowered the default batch size for seeds  to try to help mitigate this issue (https://github.com/dbt-labs/dbt-redshift/pull/468).
Since the workaround doesn't address the root cause, we are leaving this issue open in the meantime.
Root cause
redshift_connector is a descendent of pg8000, and the root cause is discussed in https://github.com/tlocke/pg8000/issues/120#issuecomment-1288381859.

A solution may involve implementing setinputsizes.
pg8000's implementation could be used as an inspiration.

@dbeatty10 so it is going back to AWS https://github.com/aws/amazon-redshift-python-driver/blob/910be71314229e5b2febc60ddf8b8bcc992ea5f0/redshift_connector/cursor.py#L471-L476 after all? Is the team aware and working on it?

just opened https://github.com/aws/amazon-redshift-python-driver/issues/165 to see if we can have the issue resolved upstream. thanks everyone for your help getting to the bottom of this!


[BUG] Volume stuck in "Attaching" state

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Install k3s
install iscsi-initiator-utils
install longhorn using kubectl with following changes to the template on longhorn.io:

    default-data-path: "/data/longhorn"
    replica-soft-anti-affinity: true

install ingress
take example config https://longhorn.io/docs/1.0.2/references/examples/#block-volume
created volume shows as "attaching" in the UI and stays in this state

Expected behavior
The volume should be attached.
Log
Log from longhorn-manager (this looks irrelevant to me):
...level=warning msg="HTTP handling error websocket: the client is not using the websocket protocol: 'websocket' token not found in 'Upgrade' header"
...level=error msg="Error in request: websocket: the client is not using the websocket protocol: 'websocket' token not found in 'Upgrade' header"

Environment:

Longhorn version: 1.0.2
Kubernetes version: v1.18.8+k3s1
Node OS type and version: CentOS 8

Check the csi-plugin logs, via kubetail -n longhorn-system csi-plugin.
You can also attach a support bundle, it will include the csi-plugin logs.

Same Issue on K8S 18.3

@g574 @obeyler is this issue still relevant?

@g574 @obeyler is this issue still relevant?


Files added as tab using URL with "Website" option don't open in Office desktop app from New Teams app.

Steps to reproduce
The New Teams app doesn't open files that were added as tab using URL with "Website" option. Below steps were followed to add the files as tab from Classic Teams app by several users in our organization.
Add File as tab using URL with Website:

Click "Add a tab" on a chat and select "Website".
Enter "Tab name" and "URL"
Click "Save"

Open the file within Tab & Desktop app from Teams:

Click the newly added tab and it loads the file within the Tab.
Further, select "Editing" then click "Open in Desktop App"

Users have switched to New Teams app as Classic Teams app is going to be deprecated by March 31, 2024.  The files that were added as tabs using URL with "Website" no longer open within the Tab and/or "Open in Desktop App".
Expected behavior
In Classic Teams app, files added as tab via URL using "Website" option loads the file within the tab. Users could further select "Editing" then "Open in Desktop App" and file gets launched in respective office app (Word, Excel, Powerpoint, etc.)

Actual behavior
In New Teams app, the files added using URL with "Website" option no longer open within the Tab and/or "Open in Desktop App".  In some instances, the tab was loading the file but when trying to "Open in Desktop App" it never launches the file in respective office app (Word, Excel, Powerpoint, etc.)
Error details
The file tab added as tab via URL using "Website" option now reports following message:
You're viewing content from .... Be sure you trust this site before using it. If the site doesn’t load properly, open it in a browser.

The Website tab is not going to work the same in the New Teams Client as it did in the Classic Teams Client. Customers who currently depend on the Website tab should switch to using apps and if an app is not available, they will need to add a configurable tab to their Teams App in order to support these scenarios.


Unique Validator doesn't display custom message when used with Combination.

When unique validation used with more than one attribute it's not displaying correct validation message.
[[employee', 'product'], 'unique', 'targetAttribute' => ['employee', 'product'], 'message' => 'Product already assigned to this employee.'],
What I am expecting :
Product already assigned to this employee.
What I get :
The combination "58"-"2" of Employee and Product has already been taken.
Note: Working on previous versions.
Additional info

Q
A

Yii version
2.0.9

duplicates #12152

Thanks, don't know about it.


Fix broken links

Status
Ready
Related Issues
fixes: https://github.com/demisto/content-docs/issues/83
Description
Fixes several broken links

fixed build issue, please review


KIP-297: MINOR: move FileConfigProvider to provider subpackage

This moves FileConfigProvider to the org.apache.common.config.provider package to more easily isolate provider implementations going forward.
Committer Checklist (excluded from commit message)

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

@kkonstantine  has requested more changes, so https://github.com/apache/kafka/pull/5177 can be used to unblock the build for now

retest this please

retest this please

retest this please

retest this please

Thanks @ijuma , added the subpackage to the public JavaDoc

retest this please

retest this please


My dono rank isn't activatting.

Here is the email to show i did buy it.

i didnt know the screenshot was gonna be that big, mybad

Removed the image because it has sensitive information. Can you please DM me on Discord directly so we can sort it? According to your payment method, eChecks can take up to 7 business days to activate.


enhance copy/paste options using right-click

Changes from the last PR:

Check user-select css prop to avoid copying elements with user-select: none;
Fix paste behavior on buttons with a more strick check, line  (can't reproduce this bug, my test cases are much more modest than the entire Keet application, but I am confident that it's fixed)
Fix the "Inspect Element" option, the bug was caused by a singleton state don't being updated, my fix was passing the state as a parameter

After feedback, I've tried to keep to the PR as simple as possible by:

copy/paste text only
user-select check is no more needed
removed the "Copy Link", it was a bonus thing and also would need the user-select check

re-pushed, 'cause I forgot to run lint


Lets store line column information on Nodes

Up until now YARP has avoided storing line column information on nodes to keep memory usage low, but it seems clear that this information is worth the additional memory. In addition in the future we can work to reduce this memory with some careful bitpacking if it ends up being a problem.
There are a number of places where column and newline information is important to have and we don't have today,

at lex time we do not know the current line or column number.
when emitting parse errors we do not yet know the line number.
We can construct the line numbers after parsing, but likely have to construct them in each place that we emit code to be consumed by another library (serialize.c needs to construct its line information, compile.c needs to construct its line information)

Here is a potential plan for adding this information to the AST:

Use the existing line/col calculation which happens after parse to convert the serialize & Ruby AST output to use line/col instead of byte offset. Now consumers have the API that we plan to switch to and the rest of the changes are internal.
Change the lexer to consume newlines in only one place so lex state can keep track of line number before tokens are emitted. (Also build the newline array the same as how we build it with a second pass to prove we successfully captured all newline information)
Attach the new line/col information to nodes and remove all post-processing line column information tracking. While doing this make sure that setting and retrieving newline information is done through a method to allow us to change the internal storage of the line/col information in the future if memory is adversely effected.

Follow up work:
Once this is done, adding a new line flag to nodes similar to CRuby's NL flag should be easier to do, but I consider this a different task that should eventually grow its own issue.

cc: @eregon and @enebo Did I capture the main issues you all identified? I am thinking we should reverse our "we only store byte offsets" decision and I think we have good reasons to do it.

cc: @eregon and @enebo Did I capture the main issues you all identified? I am thinking we should reverse our "we only store byte offsets" decision and I think we have good reasons to do it.

We can't store line & column instead of offset, because of https://github.com/Shopify/yarp/pull/757#issuecomment-1501074287. I.e., it would be terribly inefficient to actually find the relevant section in the source then.
Although maybe that could be avoided for execution purposes by ensuring there is no need to read from the source and all the relevant information is stored in node fields or so.
I think YARP needs to track or be able to find out line and column during lexing and parsing, so that it can emit proper parse errors of the format line:column: some parse error. I don't think we currently have a need to serialize line or column information.

@eregon you mention in #757 that we can derive line only if coverage is enabled but we need line numbers for any live thrown errors during execution so we 100% need to emit line info whether coverage is on or not.  This was part of my original request having every single node derive line but only emit if the line changed (e.g. no newline node flag) and having to bin search a newline table when parser already had to do line calcs during parse for error checking (feels a bit inefficient).
I think the only concerns with maintaining line (and/or column) is just memory it takes to store it and where (parse structs or only in serialize).
Your performance of column determination I don't understand.  Are you saying we need to calculate uncommon parse errors during build/parse quickly?  Or is there some more common use of columns I am missing?

After meeting the direction is specified in #808.  This can be closed.

@eregon could you show me where column is used after parse in MRI or JRuby?  I don't see it.
I think it would very easy for TR to just pass offsets and JRuby to pass line + offsets.  The original push back seemed to be specifying extra things in config.yml.  I plan on short term just making my own branch since I do not feel I am past a discovery phase.  Once I finish WIP of a running YARP in JRuby I will figure out if there are general changes which benefit us all AND whether deviation has a substantial pay off over one format.  Having said that I thought we all agreed for now line would be in serialized blob.

@eregon could you show me where column is used after parse in MRI or JRuby? I don't see it.

I don't know, besides RubyVM::AbstractSyntaxTree.

I wonder if YARP landing will necessitate this going away?  The trees do not match and even if they did it contains internal state which reflects a different approach.  Not specific to column but just a realization that this is a coarse edge in migrating to YARP.

Yes, I think we've mentioned it in the past. Anything under RubyVM is anyway unstable experimental stuff, and RubyVM::AbstractSyntaxTree particularly because it doesn't even have a way to access a child node by name and the child positions are not guaranteed. Hence, it'll be good to get rid of that hack and have a proper parser API.

So we're now storing the line offsets and can use that to calculate the line/column as necessary. Fundamentally this is an implementation detail, effectively we now have this information.
So at this point we need to figure out how to get it into the serialized form, and what that information should look like. Should we include the table of newline offsets and then provide functions to get the start line/end line as necessary? Should we include all of the information on every node? I'm not clear on the answers to these @enebo, @eregon

@kddnewton JRuby needs them, and it would be rather costly for them to compute them when deserializing (it would be Java code that needs warmup + the cost to deserialize the table, and so delays general startup/warmup).
TruffleRuby (at least currently) doesn't need lines, it only needs start + length.
I think we should do this via an env var or some kind of configuration or so, to decide whether to serialize start + length or both (start + length and line). It would then be dealt with at templating time (needed e.g. to have only the corresponding fields in Node).
Like:
class Node {
  <%= 'public final int line;' if ENV["SERIALIZE_LINE"] == "true" %>
}

(and likely move ENV["SERIALIZE_LINE"] == "true" to a serialize_line? predicate for convenience in bin/template.rb)
So like https://github.com/ruby/yarp/issues/808#issuecomment-1503797613 but I think it's good to avoid serializing line when not needed, currently I think only JRuby wants it in serialization (e.g. for Ruby nodes it would be memory overhead)

@enebo Maybe JRuby would only need line and not start + length? That means no column information then and no way to find where a node is in the source. I think that's probably better for later, when we are sure there is no need for start + length for compilation in JRuby.
It's also connected to not serializing locations at all.

See https://github.com/ruby/yarp/issues/1099#issuecomment-1622003671
I think we don't need to store line numbers in nodes, if we have O(1) offset->line conversion (https://github.com/ruby/yarp/pull/1087).
So I will optimistically close this, and I think instead we should serialize the line offsets/bit vectors.


Fix problem with no_std deployments.

bit-reverse has a default feature that enables std. To make it work with no_std, this removes the default features, as described in the bit-reverse README file.

Thanks! I’ll give this a merge once I’m at a machine again.
Have you given it a try or did you just find that while browsing through the code?

On Apr 9, 2019, at 11:28 PM, Tim Boldt<EMAIL_ADDRESS>wrote:
bit-reverse has a default feature that enables std. To make it work with no_std, this removes the default features, as described in the bit-reverse README file.
You can view, comment on, or merge this pull request online at:
https://github.com/RandomInsano/pscontroller-rs/pull/16
Commit Summary
Fix problem with no_std deployments.
File Changes
M Cargo.toml (2)
Patch Links:
https://github.com/RandomInsano/pscontroller-rs/pull/16.patch
https://github.com/RandomInsano/pscontroller-rs/pull/16.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

I gave it a try and it allowed my code to compile and run on my Blue Pill (STM32F103) with the embedded-hal.
I then tested with my Lynxmotion PS2 V4 controller and ran into issues with the controller not being recognized. However, I think my problem was independent of the change in this PR.  I looked at the SPI bus with a logic analyzer, and saw 0x01 0x42 on the CMD, but no response on DATA. I think the problem is how I had the ATT pin set up.

I own something very similar from Amazon and it worked just fine... What value pull-up resistor are you using on the ATT line?
I dug into some of your repos and you’ve done this sort of thing before...
Regards,
Edwin

On Apr 15, 2019, at 8:37 PM, Tim Boldt<EMAIL_ADDRESS>wrote:
Lynxmotion PS2 V4

What value pull-up resistor are you using on the ATT line?

I believe that's exactly where I went wrong. I'm so used to consumer I2C devices, which all include at least a vaguely acceptable pull-up resistor, that it never occurred to me to add one.

Alright! Got a chance to sit down and test and can confirm things are working great! I ran through the playstation example and notice that my cheap wireless knockoff special updated its state far slower than a wired controller would have (about once per second).
As far as the pull-up resistor, I'm using 1KΩ and it's working well up to 100KHz. I think when I checked the PS2 using a simple voltage divider circuit it was something much lower like 250Ω, but don't hold me to that. :)
Thanks again for catching that feature flag. I need to figure out an easy way to make sure no_std really means no_std while I'm doing testing on the Pi. Let me know how it ends up working out, and if you've got any ideas for issue #13!


Fix Kubeflow Helm Chart - different variable expected on notebook controller

Summary
Current KF Artifacts reference CULL_IDLE_TIME, the helm chart still contains the original value IDLE_TIME.
Updating it to new naming will make the feature work again as expected.

Message from the maintainers:
Impacted by this bug? Give it a 👍. We factor engagement into prioritization.

Mix up in deployed version


Type incompatibilities with Ethers

SafeEventEmitterProvider is not type-compatible with Ethers. Specify, when passing an instance of SafeEventEmitterProvider to Ethers v5's Web3Provider class, the following type error is produced:
[tsserver 2345] [E] Argument of type 'SafeEventEmitterProvider' is not assignable to parameter of type 'ExternalProvider | JsonRpcFetchFunc'.
  Type 'SafeEventEmitterProvider' is not assignable to type 'ExternalProvider'.
    Types of property 'sendAsync' are incompatible.
      Type '(req: JsonRpcRequest<unknown>, callback: (error: unknown, providerRes?: any) => void) => void' is not assignable to type '(request: { method: string; params?: any[] | undefined; }, callback: (error: any, response: any) => void) => void'.
        Types of parameters 'req' and 'request' are incompatible.
          Type '{ method: string; params?: any[] | undefined; }' is missing the following properties from type 'JsonRpcRequest<unknown>': jsonrpc, id

With Ethers v6's BrowserProvider class, the following type error occurs:
[tsserver 2345] [E] Argument of type 'SafeEventEmitterProvider' is not assignable to parameter of type 'Eip1193Provider'.
  Property 'request' is missing in type 'SafeEventEmitterProvider' but required in type 'Eip1193Provider'.

Closed by technical proposals for Provider and Ethers: https://app.zenhub.com/workspaces/shared-libraries-621e46b4d7103800171d1b02/issues/zh/244


Add a secondarySort parameter to topologicalSort

This makes it possible to enforce a topological sort but ensure that
within that, existing nodes are sorted lexically as much as possible.

I might not have time for a closer review until Monday.
What is the use case?

My specific use-case is wanting to sort a list of BUILD targets topologically, but also cluster them by directory as much as possible to avoid redundant buildozer commands.


export onnx model problem

I run wenet/bin/export_onnx.py and successfully output encoder.onnx 、decoder.onnx
I also check the code - torch_asr_decoder.cc ,
    auto outputs = model_->torch_model()
                       ->get_method("forward_encoder_chunk")(inputs)
                       .toTuple()
                       ->elements();

    torch::Tensor ctc_log_probs = model_->torch_model()
                                      ->run_method("ctc_activation", chunk_out)
                                      .toTensor()[0];

  auto outputs =
      model_->torch_model()
          ->run_method("forward_attention_decoder", hyps_tensor, hyps_length,
                       encoder_out, opts_.reverse_weight)
          .toTuple()
          ->elements();

why no ouput ctc.onnx?
thanks

The way how we export the model is related to the way how we use it. Please refer the gpu runtime.

The way how we export the model is related to the way how we use it. Please refer the gpu runtime.


Tiny update to documentation and comments: moveit.py -> copyit.py

Changed out of date references

Thanks! Looks like this has been forgotten for ages.


Fixing a bug with ordering of elements

Currently, when adding an element, we find an element that starts with the same id, and add the element after that. So an identifier.value element should be added after a identifier element. However, if there is an id element, then the identifier.value element would be added after that, since identifiier.value starts with id. This fixes that issue by checking for a . or : since these demarcate the complete path elements.

Sorry for the force-push, I am forgetful of my rebasing today.


Cannot change type for variables

Duplicate of #47 as that class typedef will only exist if the objc info is parseable, and NSResponder was not parsed as shown by method names.
It is worth noting that when it is functional, you wouldn't add the pointer to the type, just the type, as it's type-deffed to be a pointer to the struct. I'm aware that that's non-standard and confusing and will be changing it soon.


Log scale with axis y / y2

Tried to tackle this with relative success:
https://jsfiddle.net/f2nenq10/6/
Known issues:

stacked bar chart
padding with data labels

Any help with this would be appreciated.

Codecov Report

Merging #2100 into dev will decrease coverage by 0.48%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##              dev    #2100      +/-   ##
==========================================
- Coverage   64.13%   63.65%   -0.49%
==========================================
  Files           1        1
  Lines        4450     4504      +54
==========================================
+ Hits         2854     2867      +13
- Misses       1596     1637      +41

Impacted Files
Coverage Δ

c3.js
63.65% <0%> (-0.49%)
:arrow_down:

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 461bcdd...9674c90. Read the comment docs.

@panthony any way we can re-open and merge?


Katas not marked as completed

Some of the katas never gets marked as completed for me.
The funny thing is that the kata "Metaprogramming: Lisp-style Generic Functions" [http://www.codewars.com/kata/metaprogramming-lisp-style-generic-functions] works as some kind of divider. I still haven't solved this one.
When the kata list is sorted by "Latest", katas that appear before the divider kata are correctly marked as completed when solved, while katas that appear after it never gets marked as completed.
I've tried to solve the katas multiple times and in different languages, but it doesn't make any difference to this odd behaviour.
It's no hurry, just a bit inconvenient when I'm looking for new katas to solve. Let me know if I can do anything to help you figure it out.
Thanks for a wonderful site!!!

I have the same problem for some months now. Really hard to find katas I've not already completed...

I'm also affected.
I think it happened after I solved my 1000th kata, I never had this problem before.

Issue https://github.com/Codewars/codewars.com/issues/282 might be related to this.

The App.data.completedCodeChallengeIds array on the kata page is exactly 1000 entries long, which makes me think that Balkoth's comment is correct.  I recently went over 1000 and now my searches are not being filtered properly.

Closing old issue. App.data.completedCodeChallengeIds is no longer limited to 1000 items.


Fix error message formatting

LGTM

I don't think this adds much value. Can we established how the connection have been closed (i.e. TCP FIN or RST) and report:

who initiated connection closure
whether it has been closed gracefully (FIN) or abruptly (RST)

@maciejzaleski this doesn't change the information being logged. Just adds a missing space and moves a quote mark.


A question for benchmarks shown in the paper.

I notice that there is a gap between FewNERD official baselines and the ones that come from the performance reported in your paper. Specifically, in the INTER 5 way 1-2 shot setting, ProtoBERT got 44.44 F1 score in your paper while in the FewNERD official benchmarks, it got just 38.83 F1 score. In fact, not only the ProtoBERT model, but all models in the INTER 5 way 1-2 shot setting have the same issue. We can see that in INTER 5 way 1-2 shot setting, StructShot has a F1 score of 57.33, which even exceeds the performance reported in the INTER 5way 5-10 shot setting. Why is this possible? Are there some misunderstandings or the benchmarks just have some problems?

Hi, Thank you very much for bringing up this issue! I have been also a little bit puzzled to see them different from what we used. About the one case where 1-shot performance was higher than 5-shot, I remember being a little surprised to see that one as well.
After a quick investigation, I have found that both the paper and the website results have changed since we wrote the paper. All our results are directly from the version: Few-NERD. I remember checking the benchmark website close to the end of last year and saw these same results. Looks like both the benchmark results and the paper has changed since then. Interestingly, these updated results may make CONTaiNER come out on top in both 10-way 1-2 shot and 5-way 1-2 shot as well in Few-NERD inter task. But it needs more investigation to see if that's the case.


CodePilot menu item doesn't install after restargin Xcode 6.3.2/6.4b3

20/05/15 13:38:42,132 Xcode[1574]: WARNING: Failed to load plugin at path: "/Users/bartekchlebek/Library/Application Support/Developer/Shared/Xcode/Plug-ins/CodePilot3.xcplugin", skipping. Error: Error Domain=NSCocoaErrorDomain Code=3588 "The bundle “CodePilot3” couldn’t be loaded." (dlopen(/Users/bartekchlebek/Library/Application Support/Developer/Shared/Xcode/Plug-ins/CodePilot3.xcplugin/Contents/MacOS/CodePilot3, 265): Symbol not found: _OBJC_CLASS_$_IDESourceCodeDocument
  Referenced from: /Users/bartekchlebek/Library/Application Support/Developer/Shared/Xcode/Plug-ins/CodePilot3.xcplugin/Contents/MacOS/CodePilot3
  Expected in: flat namespace
 in /Users/bartekchlebek/Library/Application Support/Developer/Shared/Xcode/Plug-ins/CodePilot3.xcplugin/Contents/MacOS/CodePilot3) UserInfo=0x7f850be00ca0 {NSLocalizedFailureReason=The bundle couldn’t be loaded., NSLocalizedRecoverySuggestion=Try reinstalling the bundle., NSFilePath=/Users/bartekchlebek/Library/Application Support/Developer/Shared/Xcode/Plug-ins/CodePilot3.xcplugin/Contents/MacOS/CodePilot3, NSDebugDescription=dlopen(/Users/bartekchlebek/Library/Application Support/Developer/Shared/Xcode/Plug-ins/CodePilot3.xcplugin/Contents/MacOS/CodePilot3, 265): Symbol not found: _OBJC_CLASS_$_IDESourceCodeDocument
  Referenced from: /Users/bartekchlebek/Library/Application Support/Developer/Shared/Xcode/Plug-ins/CodePilot3.xcplugin/Contents/MacOS/CodePilot3
  Expected in: flat namespace
 in /Users/bartekchlebek/Library/Application Support/Developer/Shared/Xcode/Plug-ins/CodePilot3.xcplugin/Contents/MacOS/CodePilot3, NSBundlePath=/Users/bartekchlebek/Library/Application Support/Developer/Shared/Xcode/Plug-ins/CodePilot3.xcplugin, NSLocalizedDescription=The bundle “CodePilot3” couldn’t be loaded.}

The only workaround I've come up so far for this is #41
I suppose there might be a better way, but for now that will help those encountering this problem.

It's weird that during the first launch it works but after restarting Xcode it stops working.
Xcode 6.3.2 and 6.4b3 have that dialogue about a 3rd party bundle which appears during the first launch.

I guess the plugin loading flow has changed because of that and causes this issue somehow.

I have the same behaviour as @bartekchlebek. It also loads for the first time for me as well, but fails to do so for the subsequent launches.
Seems like all Xcode updates are killing CodePilot

Works now. Sweet !

Awesome! Thanks for feedback 👍🏼


{AKS} Update AKS live test pipeline

This checklist is used to make sure that common guidelines for a pull request are followed.
{AKS} Update AKS live test pipeline
Related command

General Guidelines

[ ] Have you run azdev style <YOUR_EXT> locally? (pip install azdev required)
[ ] Have you run python scripts/ci/test_index.py -q locally? (pip install wheel==0.30.0 required)
[ ] My extension version conforms to the Extension version schema

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your pull request is merged into main branch, a new pull request will be created to update src/index.json automatically.
You only need to update the version information in file setup.py and historical information in file HISTORY.rst in your PR but do not modify src/index.json.

AKS


Add retries when creating a state reader in the dump ledger script

There is a rare race condition where the latest history archive snapshot is not fully published in S3 / cloudflare. In that case, we are able to obtain the latest sequence number but the requests to obtain the bucket list may fail. When that happens the dump ledger script fails here
https://github.com/stellar/go/blob/master/exp/tools/dump-ledger-state/main.go#L233-L235
with an error which looks like:
unable to get checkpoint HAS at ledger sequence 31389055: Bad HTTP response '404 Not Found' for GET 'https://history.stellar.org/prd/core-live/core_live_001/history/01/de/f5/history-01def57f.json'

To make the dump ledger script more reliable we can we can retry MakeSingleLedgerStateReader() with a time delay if it fails with a 404 error.

According to https://github.com/stellar/stellar-core/blob/master/docs/history.md this shouldn't happen:

The root HAS file is also the last file written to the history archive when any update is made, so represents an atomic "commit point" to changes to the archive.

I started checking S3 consistency model and found this:

Amazon S3 provides read-after-write consistency for PUTS of new objects in your S3 bucket in all Regions with one caveat. The caveat is that if you make a HEAD or GET request to a key name before the object is created, then create the object shortly after that, a subsequent GET might not return the object due to eventual consistency.

So I think the issue we experienced should not happen until someone made HEAD/GET request to https://history.stellar.org/prd/core-live/core_live_001/history/01/de/f5/history-01def57f.json before it was created.
Sharing just in case someone is wondering how it happened in the future because it confused me too.

Woohoo, S3 is now strongly consistent!

@tamirms could you check whether the strong consistency of S3 resolves the problem?

@tamirms could you check whether the strong consistency of S3 resolves the problem?

I will close the issue and reopen if the error occurs again

I will close the issue and reopen if the error occurs again


Add support for sharing and bulk saving (and sharing) of spatial anchors

Builds on top of PR https://github.com/GodotVR/godot_openxr_vendors/pull/121 (marking this one as draft until that one is merged)
This PR adds support for sharing and bulk saving (and sharing) of developer-created spatial anchors.
I was able to fully test bulk saving, but only partially test sharing. To really test sharing would need a dedicated sample project, because it would require using Meta's Platform SDK as well as implement some kind of multiplayer networking. That's out of scope for the simple demo here.

@dsnopek If you want I can write a demo project on this. I have been wanting these features and would gladly test these out!
---- Demo flow ----

Users start the App Lab demo project
User ID's get put into a database
User creates an anchor and shares it with all ID's in the database.
User's start the app again they fetch all anchors found.

Does this sound okay for a demo project?
Feel free to add more requirements to the demo :-)

If you want I can write a demo project on this. I have been wanting these features and would gladly test these out!

Thanks, that'd be really cool!
Regarding the demo flow: so, would you store and share anchors with everyone who has ever opened the app? I think we'd ideally only want the users who are physically in the same place to share anchors with each other, and we really don't need to store the anchors longer than the "game session". So, if we could have some kind of "session code" or something the players could both enter, and then the anchors are only shared among that group, and then the sessions could be cleaned up after some time.

If you want I can write a demo project on this. I have been wanting these features and would gladly test these out!

Thanks, that'd be really cool!
Regarding the demo flow: so, would you store and share anchors with everyone who has ever opened the app? I think we'd ideally only want the users who are physically in the same place to share anchors with each other, and we really don't need to store the anchors longer than the "game session". So, if we could have some kind of "session code" or something the players could both enter, and then the anchors are only shared among that group, and then the sessions could be cleaned up after some time.

So, keep it session based so that the anchor uuid is not available when the session has been closed off. Do you expect full multiplayer or just 2 players entering a session code to send and retrieve anchor uuids based on the session?
I don't know if Godot has a relay for networking like Unity, so non-peer to peer might be hard to pull off as I still have to delve into Godot multiplayer.
PS: I tried to build the branch you made with the setup in the README.md but I ran into some issues:
FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':godotopenxrkhronos:buildCMakeDebug[arm64-v8a]'.
> com.android.ide.common.process.ProcessException: ninja: Entering directory `C:\GodotOpenSource\godot_openxr_vendors\godotopenxrkhronos\.cxx\Debug\2c5b28v6\arm64-v8a'
  [1/5] Building CXX object CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/classes/openxr_fb_spatial_entity_query.cpp.o
  [2/5] Building CXX object CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/classes/openxr_fb_scene_manager.cpp.o
  [3/5] Building CXX object CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/classes/openxr_fb_spatial_entity.cpp.o
  [4/5] Building CXX object CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o
  [5/5] Linking CXX shared library ..\..\..\..\build\intermediates\cxx\Debug\2c5b28v6\obj\arm64-v8a\libgodotopenxrvendors.so
  FAILED: ../../../../build/intermediates/cxx/Debug/2c5b28v6/obj/arm64-v8a/libgodotopenxrvendors.so
  cmd.exe /C "cd . && C:\Users\sixar\AppData\Local\Android\Sdk\ndk\23.2.8568313\toolchains\llvm\prebuilt\windows-x86_64\bin\clang++.exe --target=aarch64-none-linux-android21 --gcc-toolchain=C:/Users/sixar/AppData/Local/Android/Sdk/ndk/23.2.8568313/toolchains/llvm/prebuilt/windows-x86_64 --sysroot=C:/Users/sixar/AppData/Local/Android/Sdk/ndk/23.2.8568313/toolchains/llvm/prebuilt/windows-x86_64/sysroot -fPIC -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security   -fno-limit-debug-info  -static-libstdc++ -Wl,--build-id=sha1 -Wl,--no-rosegment -Wl,--fatal-warnings -Wl,--no-undefined -Qunused-arguments   -Wl -shared -Wl,-soname,libgodotopenxrvendors.so -o ..\..\..\..\build\intermediates\cxx\Debug\2c5b28v6\obj\arm64-v8a\libgodotopenxrvendors.so CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/classes/openxr_fb_hand_tracking_mesh.cpp.o CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/classes/openxr_fb_passthrough_geometry.cpp.o CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/classes/openxr_fb_render_model.cpp.o CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/classes/openxr_fb_scene_manager.cpp.o CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/classes/openxr_fb_spatial_entity.cpp.o CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/classes/openxr_fb_spatial_entity_query.cpp.o CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/classes/openxr_meta_passthrough_color_lut.cpp.o CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/export/export_plugin.cpp.o CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/export/khronos_export_plugin.cpp.o CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/export/lynx_export_plugin.cpp.o CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/export/meta_export_plugin.cpp.o CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/export/pico_export_plugin.cpp.o CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/extensions/openxr_fb_body_tracking_extension_wrapper.cpp.o CMakeFiles/godotopenxrvendors.dir/fa7c5edc4290f5902517ca4b076c991a/src/main/cpp/extensions/openxr_fb_composition_layer_secure_content_extension_wrapper.cpp.o CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/extensions/openxr_fb_face_tracking_extension_wrapper.cpp.o CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/extensions/openxr_fb_hand_tracking_aim_extension_wrapper.cpp.o CMakeFiles/godotopenxrvendors.dir/ac45f2af4304af6d396ddde662877119/common/src/main/cpp/extensions/openxr_fb_hand_tracking_capsules_extension_wrapper.cpp.o CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/extensions/openxr_fb_hand_tracking_mesh_extension_wrapper.cpp.o CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/extensions/openxr_fb_passthrough_extension_wrapper.cpp.o CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/extensions/openxr_fb_render_model_extension_wrapper.cpp.o CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/extensions/openxr_fb_scene_capture_extension_wrapper.cpp.o CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/extensions/openxr_fb_scene_extension_wrapper.cpp.o CMakeFiles/godotopenxrvendors.dir/ac45f2af4304af6d396ddde662877119/common/src/main/cpp/extensions/openxr_fb_spatial_entity_container_extension_wrapper.cpp.o CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/extensions/openxr_fb_spatial_entity_extension_wrapper.cpp.o CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/extensions/openxr_fb_spatial_entity_query_extension_wrapper.cpp.o CMakeFiles/godotopenxrvendors.dir/ac45f2af4304af6d396ddde662877119/common/src/main/cpp/extensions/openxr_fb_spatial_entity_storage_extension_wrapper.cpp.o CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/extensions/openxr_htc_facial_tracking_extension_wrapper.cpp.o CMakeFiles/godotopenxrvendors.dir/ac45f2af4304af6d396ddde662877119/common/src/main/cpp/extensions/openxr_meta_spatial_entity_mesh_extension_wrapper.cpp.o CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/util.cpp.o  -landroid  -llog  C:/GodotOpenSource/godot_openxr_vendors/common/../thirdparty/godot-cpp/bin/libgodot-cpp.android.template_debug.arm64.a  ../../../../../thirdparty/khronos_openxr_sdk/arm64-v8a/libopenxr_loader.so  -latomic -lm && cd ."
  ld: error: undefined symbol: OpenXRFbSpatialEntitySharingExtensionWrapper::get_singleton()
  >>> referenced by openxr_fb_spatial_entity.cpp:448 (C:/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/classes\openxr_fb_spatial_entity.cpp:448)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/classes/openxr_fb_spatial_entity.cpp.o:(godot::OpenXRFbSpatialEntity::share_with_users(godot::TypedArray<godot::OpenXRFbSpatialEntityUser> const&))
  >>> referenced by register_types.cpp:95 (C:/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp\register_types.cpp:95)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(initialize_plugin_module(godot::ModuleInitializationLevel))

  ld: error: undefined symbol: OpenXRFbSpatialEntitySharingExtensionWrapper::share_spaces(XrSpaceShareInfoFB const*, void (*)(XrResult, void*), void*)
  >>> referenced by openxr_fb_spatial_entity.cpp:448 (C:/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/classes\openxr_fb_spatial_entity.cpp:448)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/classes/openxr_fb_spatial_entity.cpp.o:(godot::OpenXRFbSpatialEntity::share_with_users(godot::TypedArray<godot::OpenXRFbSpatialEntityUser> const&))

  ld: error: undefined symbol: OpenXRFbSpatialEntityStorageBatchExtensionWrapper::get_singleton()
  >>> referenced by register_types.cpp:101 (C:/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp\register_types.cpp:101)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(initialize_plugin_module(godot::ModuleInitializationLevel))

  ld: error: undefined symbol: OpenXRFbSpatialEntityUserExtensionWrapper::get_singleton()
  >>> referenced by register_types.cpp:110 (C:/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp\register_types.cpp:110)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(initialize_plugin_module(godot::ModuleInitializationLevel))

  ld: error: undefined symbol: OpenXRFbSpatialEntitySharingExtensionWrapper::OpenXRFbSpatialEntitySharingExtensionWrapper()
  >>> referenced by class_db.hpp:118 (C:/GodotOpenSource/godot_openxr_vendors/common/../thirdparty/godot-cpp/include\godot_cpp/core\class_db.hpp:118)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(void* godot::ClassDB::_create_instance_func<OpenXRFbSpatialEntitySharingExtensionWrapper>(void*))

  ld: error: undefined symbol: OpenXRFbSpatialEntitySharingExtensionWrapper::_bind_methods()
  >>> referenced by openxr_fb_spatial_entity_sharing_extension_wrapper.h:42 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\extensions\openxr_fb_spatial_entity_sharing_extension_wrapper.h:42)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(OpenXRFbSpatialEntitySharingExtensionWrapper::initialize_class())
  >>> referenced by openxr_fb_spatial_entity_sharing_extension_wrapper.h:0 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\extensions\openxr_fb_spatial_entity_sharing_extension_wrapper.h:0)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(OpenXRFbSpatialEntitySharingExtensionWrapper::_get_bind_methods())
  >>> referenced by openxr_fb_spatial_entity_sharing_extension_wrapper.h:0 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\extensions\openxr_fb_spatial_entity_sharing_extension_wrapper.h:0)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(OpenXRFbSpatialEntitySharingExtensionWrapper::_get_bind_methods())

  ld: error: undefined symbol: OpenXRFbSpatialEntityStorageBatchExtensionWrapper::OpenXRFbSpatialEntityStorageBatchExtensionWrapper()
  >>> referenced by class_db.hpp:118 (C:/GodotOpenSource/godot_openxr_vendors/common/../thirdparty/godot-cpp/include\godot_cpp/core\class_db.hpp:118)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(void* godot::ClassDB::_create_instance_func<OpenXRFbSpatialEntityStorageBatchExtensionWrapper>(void*))

  ld: error: undefined symbol: OpenXRFbSpatialEntityStorageBatchExtensionWrapper::_bind_methods()
  >>> referenced by openxr_fb_spatial_entity_storage_batch_extension_wrapper.h:42 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\extensions\openxr_fb_spatial_entity_storage_batch_extension_wrapper.h:42)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(OpenXRFbSpatialEntityStorageBatchExtensionWrapper::initialize_class())
  >>> referenced by openxr_fb_spatial_entity_storage_batch_extension_wrapper.h:0 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\extensions\openxr_fb_spatial_entity_storage_batch_extension_wrapper.h:0)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(OpenXRFbSpatialEntityStorageBatchExtensionWrapper::_get_bind_methods())
  >>> referenced by openxr_fb_spatial_entity_storage_batch_extension_wrapper.h:0 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\extensions\openxr_fb_spatial_entity_storage_batch_extension_wrapper.h:0)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(OpenXRFbSpatialEntityStorageBatchExtensionWrapper::_get_bind_methods())

  ld: error: undefined symbol: OpenXRFbSpatialEntityUserExtensionWrapper::OpenXRFbSpatialEntityUserExtensionWrapper()
  >>> referenced by class_db.hpp:118 (C:/GodotOpenSource/godot_openxr_vendors/common/../thirdparty/godot-cpp/include\godot_cpp/core\class_db.hpp:118)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(void* godot::ClassDB::_create_instance_func<OpenXRFbSpatialEntityUserExtensionWrapper>(void*))

  ld: error: undefined symbol: OpenXRFbSpatialEntityUserExtensionWrapper::_bind_methods()
  >>> referenced by openxr_fb_spatial_entity_user_extension_wrapper.h:42 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\extensions\openxr_fb_spatial_entity_user_extension_wrapper.h:42)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(OpenXRFbSpatialEntityUserExtensionWrapper::initialize_class())
  >>> referenced by openxr_fb_spatial_entity_user_extension_wrapper.h:0 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\extensions\openxr_fb_spatial_entity_user_extension_wrapper.h:0)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(OpenXRFbSpatialEntityUserExtensionWrapper::_get_bind_methods())
  >>> referenced by openxr_fb_spatial_entity_user_extension_wrapper.h:0 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\extensions\openxr_fb_spatial_entity_user_extension_wrapper.h:0)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(OpenXRFbSpatialEntityUserExtensionWrapper::_get_bind_methods())

  ld: error: undefined symbol: godot::OpenXRFbSpatialAnchorManager::_notification(int)
  >>> referenced by openxr_fb_spatial_anchor_manager.h:46 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\classes\openxr_fb_spatial_anchor_manager.h:46)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(godot::OpenXRFbSpatialAnchorManager::notification_bind(void*, int, unsigned char))
  >>> referenced by openxr_fb_spatial_anchor_manager.h:0 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\classes\openxr_fb_spatial_anchor_manager.h:0)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(godot::OpenXRFbSpatialAnchorManager::_get_notification())
  >>> referenced by openxr_fb_spatial_anchor_manager.h:0 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\classes\openxr_fb_spatial_anchor_manager.h:0)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(godot::OpenXRFbSpatialAnchorManager::_get_notification())

  ld: error: undefined symbol: godot::OpenXRFbSpatialAnchorManager::_bind_methods()
  >>> referenced by openxr_fb_spatial_anchor_manager.h:46 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\classes\openxr_fb_spatial_anchor_manager.h:46)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(godot::OpenXRFbSpatialAnchorManager::initialize_class())
  >>> referenced by openxr_fb_spatial_anchor_manager.h:0 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\classes\openxr_fb_spatial_anchor_manager.h:0)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(godot::OpenXRFbSpatialAnchorManager::_get_bind_methods())
  >>> referenced by openxr_fb_spatial_anchor_manager.h:0 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\classes\openxr_fb_spatial_anchor_manager.h:0)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(godot::OpenXRFbSpatialAnchorManager::_get_bind_methods())

  ld: error: undefined symbol: vtable for godot::OpenXRFbSpatialAnchorManager
  >>> referenced by openxr_fb_spatial_anchor_manager.h:0 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\classes\openxr_fb_spatial_anchor_manager.h:0)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(godot::OpenXRFbSpatialAnchorManager::OpenXRFbSpatialAnchorManager())
  >>> referenced by openxr_fb_spatial_anchor_manager.h:0 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\classes\openxr_fb_spatial_anchor_manager.h:0)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(godot::OpenXRFbSpatialAnchorManager::OpenXRFbSpatialAnchorManager())
  >>> the vtable symbol may be undefined because the class is missing its key function (see https://lld.llvm.org/missingkeyfunction)

  ld: error: undefined symbol: godot::OpenXRFbSpatialEntityBatch::_to_string() const
  >>> referenced by openxr_fb_spatial_entity_batch.h:41 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\classes\openxr_fb_spatial_entity_batch.h:41)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(godot::OpenXRFbSpatialEntityBatch::to_string_bind(void*, unsigned char*, void*))
  >>> referenced by openxr_fb_spatial_entity_batch.h:0 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\classes\openxr_fb_spatial_entity_batch.h:0)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(godot::OpenXRFbSpatialEntityBatch::_get_to_string())
  >>> referenced by openxr_fb_spatial_entity_batch.h:0 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\classes\openxr_fb_spatial_entity_batch.h:0)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(godot::OpenXRFbSpatialEntityBatch::_get_to_string())

  ld: error: undefined symbol: godot::OpenXRFbSpatialEntityBatch::_bind_methods()
  >>> referenced by openxr_fb_spatial_entity_batch.h:41 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\classes\openxr_fb_spatial_entity_batch.h:41)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(godot::OpenXRFbSpatialEntityBatch::initialize_class())
  >>> referenced by openxr_fb_spatial_entity_batch.h:0 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\classes\openxr_fb_spatial_entity_batch.h:0)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(godot::OpenXRFbSpatialEntityBatch::_get_bind_methods())
  >>> referenced by openxr_fb_spatial_entity_batch.h:0 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\classes\openxr_fb_spatial_entity_batch.h:0)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(godot::OpenXRFbSpatialEntityBatch::_get_bind_methods())

  ld: error: undefined symbol: godot::OpenXRFbSpatialEntityUser::_to_string() const
  >>> referenced by openxr_fb_spatial_entity_user.h:39 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\classes\openxr_fb_spatial_entity_user.h:39)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(godot::OpenXRFbSpatialEntityUser::to_string_bind(void*, unsigned char*, void*))
  >>> referenced by openxr_fb_spatial_entity_user.h:0 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\classes\openxr_fb_spatial_entity_user.h:0)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(godot::OpenXRFbSpatialEntityUser::_get_to_string())
  >>> referenced by openxr_fb_spatial_entity_user.h:0 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\classes\openxr_fb_spatial_entity_user.h:0)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(godot::OpenXRFbSpatialEntityUser::_get_to_string())

  ld: error: undefined symbol: godot::OpenXRFbSpatialEntityUser::_bind_methods()
  >>> referenced by openxr_fb_spatial_entity_user.h:39 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\classes\openxr_fb_spatial_entity_user.h:39)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(godot::OpenXRFbSpatialEntityUser::initialize_class())
  >>> referenced by openxr_fb_spatial_entity_user.h:0 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\classes\openxr_fb_spatial_entity_user.h:0)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(godot::OpenXRFbSpatialEntityUser::_get_bind_methods())
  >>> referenced by openxr_fb_spatial_entity_user.h:0 (C:/GodotOpenSource/godot_openxr_vendors/common/../common/src/main/cpp/include\classes\openxr_fb_spatial_entity_user.h:0)
  >>>               CMakeFiles/godotopenxrvendors.dir/C_/GodotOpenSource/godot_openxr_vendors/common/src/main/cpp/register_types.cpp.o:(godot::OpenXRFbSpatialEntityUser::_get_bind_methods())
  clang++: error: linker command failed with exit code 1 (use -v to see invocation)
  ninja: build stopped: subcommand failed.

  C++ build system [build] failed while executing:
      @echo off
      "C:\\Users\\sixar\\AppData\\Local\\Android\\Sdk\\cmake\\3.22.1\\bin\\ninja.exe" ^
        -C ^
        "C:\\GodotOpenSource\\godot_openxr_vendors\\godotopenxrkhronos\\.cxx\\Debug\\2c5b28v6\\arm64-v8a" ^
        godotopenxrvendors
    from C:\GodotOpenSource\godot_openxr_vendors\godotopenxrkhronos

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.

Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

For more on this, please refer to https://docs.gradle.org/8.2/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.

BUILD FAILED in 4m 28s
9 actionable tasks: 8 executed, 1 up-to-date

Do you expect full multiplayer or just 2 players entering a session code to send and retrieve anchor uuids based on the session?

I think just being able to spawn anchors in their shared environment is enough. The players will be in the same physical space, so they don't need avatars or anything else :-)

I don't know if Godot has a relay for networking like Unity, so non-peer to peer might be hard to pull off as I still have to delve into Godot multiplayer.

Peer-to-peer networking is possible via WebRTC. I think Meta has or had a relayed multiplayer service that was available via the Platform SDK, which could also be a possibility if that's still around?
Anyway, the multiplayer part is definitely one of the challenges of making a sample for this!

PS: I tried to build the branch you made with the setup in the README.md but I ran into some issues:

Try cleaning up some of the build artifacts:
rm -rf */.cxx */build

... and then rebuilding.

Do you expect full multiplayer or just 2 players entering a session code to send and retrieve anchor uuids based on the session?

I think just being able to spawn anchors in their shared environment is enough. The players will be in the same physical space, so they don't need avatars or anything else :-)

I don't know if Godot has a relay for networking like Unity, so non-peer to peer might be hard to pull off as I still have to delve into Godot multiplayer.

Peer-to-peer networking is possible via WebRTC. I think Meta has or had a relayed multiplayer service that was available via the Platform SDK, which could also be a possibility if that's still around?
Anyway, the multiplayer part is definitely one of the challenges of making a sample for this!

PS: I tried to build the branch you made with the setup in the README.md but I ran into some issues:

Try cleaning up some of the build artifacts:
rm -rf */.cxx */build

... and then rebuilding.

I managed to build the plugin just fine this time! Thank you. Still a bit confused on where the output is and how the import process works for the plugin. Do I need godot 4.3 for this?

I Only see this and no other files (besides the hidden .bin directory). How would I drag in a node/use the plugin?

Do I need godot 4.3 for this?

At the moment, you need to use Godot's master branch, however, 4.3-dev6 should come out very soon (maybe even today!) which should work.

I Only see this and no other files (besides the hidden .bin directory). How would I drag in a node/use the plugin?

If the plugin has loaded correctly, you should be able to add any of the nodes defined in it just like you would add any native nodes, ie press Ctrl-A and find OpenXRFbSpatialAnchorManager on the list, for example.
Taking a look at the demo project would probably be a good way to get started. We don't have any documentation yet, although, that's also something we're hoping to fix soon. :-)

I managed to get it to work but I do have some questions in regards to creating anchors and sharing/loading them:
func create_anchor(node: Node3D):
	spatial_anchor_manager.create_anchor(node.transform) // This returns void, and I don't see a way to get the created anchor to then share it.

On Wed, May 1, 2024 at 3:13 AM Baka @.***> wrote:

I managed to get it to work but I do have some questions in regards to
creating anchors and sharing/loading them:
func create_anchor(node: Node3D):
spatial_anchor_manager.create_anchor(node.transform) // This returns void, and I don't see a way to get the created anchor to then share it.
image.png (view on web)
https://github.com/GodotVR/godot_openxr_vendors/assets/67325807/fd192b69-f046-4d63-8303-32017c24b8aa

Take a look at the demo project - it creates anchors, uploads them to the
cloud, and even has a commented out line that would share them with a given
user.
Anyway, the short answer to your question is that almost everything with
spatial anchors is done asynchronously (and sometimes in multiple steps) so
you need to connect to signals to get the result of many actions. In this
case, you'll want to connect to the openxr_fb_spatial_anchor_tracked
signal. (I haven't rebased it yet, but the latest version of the PR this PR
is built on now has an is_new argument on that signal, so you can tell
the difference between created and loaded anchors.)

Message ID: @.***>

On Wed, May 1, 2024 at 3:13 AM Baka @.> wrote: I managed to get it to work but I do have some questions in regards to creating anchors and sharing/loading them: func create_anchor(node: Node3D): spatial_anchor_manager.create_anchor(node.transform) // This returns void, and I don't see a way to get the created anchor to then share it. image.png (view on web) https://github.com/GodotVR/godot_openxr_vendors/assets/67325807/fd192b69-f046-4d63-8303-32017c24b8aa
Take a look at the demo project - it creates anchors, uploads them to the cloud, and even has a commented out line that would share them with a given user. Anyway, the short answer to your question is that almost everything with spatial anchors is done asynchronously (and sometimes in multiple steps) so you need to connect to signals to get the result of many actions. In this case, you'll want to connect to the openxr_fb_spatial_anchor_tracked signal. (I haven't rebased it yet, but the latest version of the PR this PR is built on now has an is_new argument on that signal, so you can tell the difference between created and loaded anchors.)
…
Message ID: @.>

Alrighty, thank you
I managed to set up some anchor creation and saving code already, is the PlatformSDK from meta already in this project? If not I will see if I can write some GDExtension for what I need

is the PlatformSDK from meta already in this project?

No, although, there is a community maintained integration here:
https://github.com/decacis/godot_oculus_platform
I suspect there will be an official one from Meta sometime in the near future :-)

is the PlatformSDK from meta already in this project?

No, although, there is a community maintained integration here:
https://github.com/decacis/godot_oculus_platform
I suspect there will be an official one from Meta sometime in the near future :-)

Alrighty, I have just finished writing the logic for the PlatformSDK + Database in order to test the spatial anchors. Small issue: Godot 4.3 dev needs an android export template, and I have no clue on where to get those

Alrighty, I have just finished writing the logic for the PlatformSDK + Database in order to test the spatial anchors. Small issue: Godot 4.3 dev needs an android export template, and I have no clue on where to get those

I believe you'll need to create them yourself, this page in the docs is relevant. When testing things in the godot_openxr_vendors demo and needing to update the export templates, I have a script that does the following in my local godot repo:
scons platform=android target=template_debug arch=arm64
cd platform/android/java
./gradlew generateGodotTemplates

This creates android_source.zip in the bin directory. Then it takes the contents of that zip and then, now moving to the godot_openxr_vendors directory, pastes all of its contents in demo/android/build, overriding the other files there (not deleting .gdignore). Then in the file demo/android/.build_version, I'll set the version to 4.3.dev.
Hopefully that helps you out!

I believe you'll need to create them yourself

Actually, since Godot 4.3-dev6 was just released today, you should be able to use that rather than compiling Godot yourself:
https://godotengine.org/article/dev-snapshot-godot-4-3-dev-6/

Alrighty, that will probably work out better than. Where can I post the
demo project when it is done?
On Wed, May 1, 2024, 22:58 David Snopek @.***> wrote:

I believe you'll need to create them yourself
Actually, since Godot 4.3-dev6 was just released today, you should be able
to use that rather than compiling Godot yourself:
https://godotengine.org/article/dev-snapshot-godot-4-3-dev-6/
—
Reply to this email directly, view it on GitHub
https://github.com/GodotVR/godot_openxr_vendors/pull/128#issuecomment-2089130463,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQBU633IR2M5OMPKJ6M6VYLZAFJQNAVCNFSM6AAAAABGTM2CSGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBZGEZTANBWGM
.
You are receiving this because you commented.Message ID:
@.***>

I will be working on this during my free time but I'll try to finish it by
next sunday so the anchors can be tested properly.
On Wed, May 1, 2024, 23:06 Arne Six @.***> wrote:

Alrighty, that will probably work out better than. Where can I post the
demo project when it is done?
On Wed, May 1, 2024, 22:58 David Snopek @.***> wrote:

I believe you'll need to create them yourself
Actually, since Godot 4.3-dev6 was just released today, you should be
able to use that rather than compiling Godot yourself:
https://godotengine.org/article/dev-snapshot-godot-4-3-dev-6/
—
Reply to this email directly, view it on GitHub
https://github.com/GodotVR/godot_openxr_vendors/pull/128#issuecomment-2089130463,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQBU633IR2M5OMPKJ6M6VYLZAFJQNAVCNFSM6AAAAABGTM2CSGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBZGEZTANBWGM
.
You are receiving this because you commented.Message ID:
@.***>

Where can I post the demo project when it is done?

Maybe you could make a new repo on GitHub?

I will be working on this during my free time but I'll try to finish it by next sunday so the anchors can be tested properly.

Wow, that's quite fast! But don't stress yourself out if you find out that you need some more time :-)

https://github.com/GodotVR/godot_openxr_vendors/pull/121 was merged, so this PR can come out of draft!

Rebased and taken out of draft!


WIP add /analysis/latest route & improve scrolling

related to #103

Hey @maracuja-juice,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 0835b280-60fd-11e9-872d-3ffbb4cd282a


Add UI Mockup and Change CI/CD Link

On second thoughts, would it be possible to downsize the photo to be a size that is similar to the original photo in order to adhere to the given requirements?


Use pretrained ResNet50 model for Face Recognition on my own dataset

I want to build a face recognizer using the pretrained models given in the repository. Currently facing the issue with the distance threshold as with different faces the distances are coming very small whereas for same faces the distance is coming large, in most cases. My questions are:

Am I calculating the embedding correctly?
How face comparison should be done in order to reach LFW level accuracy?

I have already referenced this #6 and #8 but couldn't come up with a concrete solution.
import os
os.environ['TF_CPP_MIN_LOG_LEVEL'] = '3'
import cv2
import numpy as np
import tensorflow as tf

from .modules.models import ArcFaceModel
from .modules.utils import set_memory_growth, load_yaml, l2_norm

class ArcFaceResNet50:
    def __init__(self):
        set_memory_growth()
        self.cfg = load_yaml(os.path.join(os.path.dirname(os.path.abspath(__file__)), \
                                     './configs/arc_res50.yaml'))

        self.model = ArcFaceModel(size=self.cfg['input_size'],
                             backbone_type=self.cfg['backbone_type'],
                             training=False)

        ckpt_path = tf.train.latest_checkpoint(os.path.join(os.path.dirname(os.path.abspath(__file__)), \
                                                            './checkpoints/' + self.cfg['sub_name']))
        if ckpt_path is not None:
            print("[*] load ckpt from {}".format(ckpt_path))
            self.model.load_weights(ckpt_path)
        else:
            print("[*] Cannot find ckpt from {}.".format(ckpt_path))
            exit()

    def get_embeddings(self, frame_rgb, bounding_boxes):
            faces = []
            for x1, y1, x2, y2 in bounding_boxes:
                face_patch = frame_rgb[y1:y2, x1:x2, :]
                resized = cv2.resize(face_patch, (self.cfg['input_size'], self.cfg['input_size']), interpolation=cv2.INTER_AREA)
                normalize = resized.astype(np.float32) / 255.
                faces.append(normalize)
            faces = np.stack(faces)
            if len(faces.shape) == 3:
                faces = np.expand_dims(faces, 0)
            # Run prediction
            embeddings = l2_norm(self.model(faces))
            return embeddings

Thanks in advance!

Hi @iamrishab , nice to hear from you~
I briefly explain what I know, and hope that can help you.

The calculating of the embedding vector should like bellow (I thinks the code part you proved didn't have obvious mistake)
Crop RGB format [0~255]  face image with alignment method  -> re-scale to [0~1] -> feed into pre-train model -> normalize output embedding vector
In the LFW dataset use threshold 1.32 to distinguish identity by l2-norm distance between embedding vectors.

Hi @peteryuX thank you for your response.
I will surely try this out and revert in case of any further queries.

hi, @iamrishab I have some problem，how did you solve it ?


Modify receipt parse

modify receipt parser & call parser
remove duplicated RetCode
rename some methods

Codecov Report

Merging #72 into dev will increase coverage by 0.00%.
The diff coverage is 0.00%.

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


Can we get rid of n_bits in Cet?

The field n_bits of Cet represents the number of relevant bits of the price range used when calculating adaptor points based on oracle announcements, and decryption keys based on oracle attestations.
This appears to be an optimisation. One could simply multiply by all the leading, zero bits of the price range. That may be inexpensive and it would allow use to remove this n_bits field which we have to remember for every CET.
Before we do anything, we need to determine if n_bits is simply an optimisation. Also, we may need to modify maia as part of this change.
Originally posted by @luckysori in https://github.com/itchysats/itchysats/pull/1295#discussion_r797100686

This project is unmaintained


Cannot add a hashtag to internal links

Q
A

Bug?
no

New Feature?
yes

Actual Behavior
You cannot add a hashtag if you select internal link in page settings.
Expected Behavior
It would be great to be able to add an optional hashtag to internal links.

@berndhep What do you think about that? Should we add this? And if yes, should it simply be another field in the white box that appears when internal link is selected?

@danrot Sounds legitimate but let's discuss possible side issues first.

@aureliusm We have discussed this feature request, but we decided against implementing it. The problem with these hashtags is, that we don't have any possibility to check whether they really exist or not. And that's actually the strength of the internal link page type: It is guaranteed that the destination exists. So a workaround for what you want to do is to use the external link content type, I hope that is ok for you.


Temp controller fix patch

While the new input mapping system gets put back in the oven.

Cannot merge, you are reverting Lynx support

The master branch is mostly fixed. I think this PR is irrelevant now.

Cannot merge, you are reverting Lynx support

I know the master branch should be mostly fixed now and this is irrelevant, but I saw that the Lynx support commit had calls that looked like they relied on the new input system, so while I'd rather not have, I included it.


Elixir API

As a developer, I want to interface with Potterhat through Elixir API so I can interact with Potterhat without setting up as a separate service.

Approach:

Add :ethereumex as a potterhat's dependency
Create a new PotterhatClient module that extends Ethereumex.Client.BaseClient. Similar to Ethereumex.HttpClient.
Implement a PotterhatClient.post_request/2 that relays the request through  PotterhatRPC.EthForwarder

Work is paused as there are too many dependency conflicts with omisego/ewallet so Elixir API will not be useful until omisego/ewallet dependencies are upgraded.


⚠ Jenkins Plugins Artifactory has degraded performance

In e0d9bf1, Jenkins Plugins Artifactory (https://get.jenkins.io/plugins/artifactory/) experienced degraded performance:

HTTP code: 200
Response time: 1235 ms

Resolved: Jenkins Plugins Artifactory performance has improved in cef7424 after 12 minutes.


(Suggestion) Add icon for janet-mode

Patch that adds an icon for the Janet programming language.
https://janet-lang.org/

Can you make the icon square please? :)

I resized the image.


What is the purpose of the DBC Feeder's elm2canbridge?

As described in the documentation, the elm2canbridge module makes use of several STN2100 specific ST commands and thus does not seem to work with generic ELM327 based dongles.
I was wondering if there are plans to extend support to ELM327 based dongles or if this module is simply here to support the Kuksa.val  CANOPi dongle (and whatever chip set it is currently based on)?

Originally the code was created for the first version of the KUKSA hardware, that only had an OBD interface based on the STN2120. It allows you to use the STN to listen to a "raw" CAN bus without begin limited to the OBD protocol.
While the current hardware version has native CAN ports, it still has an STN, that could act as "third" CAN interface. Even when not using all CANs, using the OBD port  might still be "easier" in some situations, e.g. for Tesla vehicles there are aftermarket cables that make the vehicle CAN (just the raw CAN bus) available as a OBD socket  (from mechanic, electric perspective), where you could plug the hardware directly.
The current code  is limited to STN variants and does not work  "native" ELMs or clones. That could however be changed in code. It even would need to be, as we are currently redesinging KUKSA hardware to not use STN2100 family chips but switching to "generic" ELM. The company doing the STN  can not supply them anymore in any meaningful quantitiy and reasonable timeframe, and they do not have any useful kind of sales/support, so keeping them is a bad idea. See also https://github.com/eclipse/kuksa.hardware/issues/11
However, meanwhile the Linux CAN ecosystem moved forward, and there seems to be a Linux socketcan driver now for ELM chips: https://github.com/norly/elmcan/tree/master If we/someone could confirm that this works and document it, it would be a good chance to get rid of some code in DBC provider.

Thanks for the detailed information :+1:

So, my understanding is that there would be no immediate benefit if I started to tidy up/improve the existing elm2canbridge, right? We should probably wait until you have settled for the new chip set or am I mistaken?

We have migrated CAN Provider (dbcfeeder) to a new repo. Long term my intention is to close all dbc/can-related issues in this repository. If we see the issue as still interesting or relevant we could create a new issue in the new repo, possibly referencing the old issue in the repository.
Suggested way forward:

I will migrate selected issues early 2024
If this issue has not been migrated but you want it to remain open please comment.
Remaining issues no one seems to be interested in will be closed around 2024-03-31


Pointer

Codecov Report

Merging #4 (939bbed) into main (596bb0f) will decrease coverage by 0.70%.
The diff coverage is 86.04%.

@@            Coverage Diff             @@
##             main       #4      +/-   ##
==========================================
- Coverage   70.02%   69.32%   -0.71%
==========================================
  Files           9        9
  Lines         417      427      +10
==========================================
+ Hits          292      296       +4
- Misses        125      131       +6

Impacted Files
Coverage Δ

src/PGEN.jl
100.00% <ø> (ø)

src/iterator.jl
53.33% <57.14%> (-6.67%)
:arrow_down:

src/difflist.jl
97.95% <100.00%> (+0.13%)
:arrow_up:

src/dosage.jl
39.36% <100.00%> (ø)

src/genotype.jl
76.81% <100.00%> (ø)

src/internal_structs.jl
68.18% <100.00%> (-3.82%)
:arrow_down:

src/uleb128.jl
92.85% <100.00%> (ø)

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 596bb0f...939bbed. Read the comment docs.


Building construction is finished instantly

construction of buildings may take some time.

Good idea. While implementing this we need to check the potential impact on AI code to ensure it won't break any assumptions.


Add New Ecolink Siren

ZWA ID: 4000

@zwave-js-bot import config 4000 from zwa

@AlCalzone What am I doing wrong here?

Nevermind, looks like we already have it.

Botty is a bit slow:


Cannot modify model

Hi Tomasz,
I have a problem while trying to integrate parser in my project. When I modify StackOnlyJsonField after the first generation my model wasn't re-generation and I couldn't find where files were generated. Could you please help me?
Best regards,
Alex

Hey (and merry Christmas :P),
I don't think the generated files can be easily found in the project structure - they are just compile-time temporary files stored somewhere on the disk outside of the repo. When I try to inspect them in the VS and copy the full path of those files, I can see that for me they are stored in the AppData\Local\Temp\VSGeneratedDocuments.
But nevertheless, the model should be regenerated on each build. So if you make a change to a model, the Intellisense may not pick it up right away, but the changes should be available after you rebuild the project.
If that's not the case, then I wonder - maybe the change caused some exception in the code generator. Though in this case I would expect the generated code not to be available at all - instead of it being stuck with the previous (first) version.
Could you please post some more details? What change did you make to your model?

@gallun320, were you able to resolve the issue?

@gallun320, were you able to resolve the issue?


Added double_linkedlist   in C

This program shows all basic operations done in double linked list

@YuweAEC    Please add hacktoberfest-accepted label and then merge it