Incorrect results with expression resolution

Describe the bug
DataFusion will sometimes resolve expressions incorrectly when the alias shadows an expression
To Reproduce
DataFusion CLI v37.1.0
> select a + b from (select 1 as a, 2 as b, 1 as "a + b");
+-------+
| a + b |
+-------+
| 1     | <- Should be 3
+-------+
1 row(s) fetched.
Elapsed 0.009 seconds.

Expected behavior
Result should be 3
Additional context
This was found by @peter-toth  in https://github.com/apache/datafusion/pull/10396

As @peter-toth  mentions in https://github.com/apache/datafusion/pull/10396#issuecomment-2099072200 this appears to be related to name resolution (not CSE). I checked with EXPLAIN VERBOSE and indeed the initial plan appears to be incorret
DataFusion CLI v37.1.0
> explain verbose select a + b from (select 1 as a, 2 as b, 1 as "a + b");
+------------------------------------------------------------+--------------------------------------------------------------------------------------------+
| plan_type                                                  | plan                                                                                |
+------------------------------------------------------------+--------------------------------------------------------------------------------------------+
| initial_logical_plan                                       | Projection: a + b                                                                          |
|                                                            |   Projection: Int64(1) AS a, Int64(2) AS b, Int64(1) AS a + b                              |
|                                                            |     EmptyRelation                                                                          |
| logical_plan after apply_function_rewrites                 | SAME TEXT AS ABOVE                                                                         |
| logical_plan after inline_table_scan                       | SAME TEXT AS ABOVE                                                                         |
| logical_plan after type_coercion                           | SAME TEXT AS ABOVE                                                                         |
| logical_plan after count_wildcard_rule                     | SAME TEXT AS ABOVE                                                                         |
| analyzed_logical_plan                                      | SAME TEXT AS ABOVE                                                                         |
| logical_plan after eliminate_nested_union                  | SAME TEXT AS ABOVE                                                                         |
| logical_plan after simplify_expressions                    | SAME TEXT AS ABOVE                                                                         |
| logical_plan after unwrap_cast_in_comparison               | SAME TEXT AS ABOVE                                                                         |
| logical_plan after replace_distinct_aggregate              | SAME TEXT AS ABOVE                                                                         |
| logical_plan after eliminate_join                          | SAME TEXT AS ABOVE                                                                         |
| logical_plan after decorrelate_predicate_subquery          | SAME TEXT AS ABOVE                                                                         |
| logical_plan after scalar_subquery_to_join                 | SAME TEXT AS ABOVE                                                                         |
| logical_plan after extract_equijoin_predicate              | SAME TEXT AS ABOVE                                                                         |
| logical_plan after simplify_expressions                    | SAME TEXT AS ABOVE                                                                         |
| logical_plan after rewrite_disjunctive_predicate           | SAME TEXT AS ABOVE                                                                         |
| logical_plan after eliminate_duplicated_expr               | SAME TEXT AS ABOVE                                                                         |
| logical_plan after eliminate_filter                        | SAME TEXT AS ABOVE                                                                         |
| logical_plan after eliminate_cross_join                    | SAME TEXT AS ABOVE                                                                         |
| logical_plan after common_sub_expression_eliminate         | SAME TEXT AS ABOVE                                                                         |
| logical_plan after eliminate_limit                         | SAME TEXT AS ABOVE                                                                         |
| logical_plan after propagate_empty_relation                | SAME TEXT AS ABOVE                                                                         |
| logical_plan after eliminate_one_union                     | SAME TEXT AS ABOVE                                                                         |
| logical_plan after filter_null_join_keys                   | SAME TEXT AS ABOVE                                                                         |
| logical_plan after eliminate_outer_join                    | SAME TEXT AS ABOVE                                                                         |
| logical_plan after push_down_limit                         | SAME TEXT AS ABOVE                                                                         |
| logical_plan after push_down_filter                        | SAME TEXT AS ABOVE                                                                         |
| logical_plan after single_distinct_aggregation_to_group_by | SAME TEXT AS ABOVE                                                                         |
| logical_plan after simplify_expressions                    | SAME TEXT AS ABOVE                                                                         |
| logical_plan after unwrap_cast_in_comparison               | SAME TEXT AS ABOVE                                                                         |
| logical_plan after common_sub_expression_eliminate         | SAME TEXT AS ABOVE                                                                         |
| logical_plan after optimize_projections                    | Projection: Int64(1) AS a + b                                                              |
|                                                            |   EmptyRelation                                                                            |
| logical_plan after eliminate_nested_union                  | SAME TEXT AS ABOVE                                                                         |
| logical_plan after simplify_expressions                    | SAME TEXT AS ABOVE                                                                         |
| logical_plan after unwrap_cast_in_comparison               | SAME TEXT AS ABOVE                                                                         |
| logical_plan after replace_distinct_aggregate              | SAME TEXT AS ABOVE                                                                         |
| logical_plan after eliminate_join                          | SAME TEXT AS ABOVE                                                                         |
| logical_plan after decorrelate_predicate_subquery          | SAME TEXT AS ABOVE                                                                         |
| logical_plan after scalar_subquery_to_join                 | SAME TEXT AS ABOVE                                                                         |
| logical_plan after extract_equijoin_predicate              | SAME TEXT AS ABOVE                                                                         |
| logical_plan after simplify_expressions                    | SAME TEXT AS ABOVE                                                                         |
| logical_plan after rewrite_disjunctive_predicate           | SAME TEXT AS ABOVE                                                                         |
| logical_plan after eliminate_duplicated_expr               | SAME TEXT AS ABOVE                                                                         |
| logical_plan after eliminate_filter                        | SAME TEXT AS ABOVE                                                                         |
| logical_plan after eliminate_cross_join                    | SAME TEXT AS ABOVE                                                                         |
| logical_plan after common_sub_expression_eliminate         | SAME TEXT AS ABOVE                                                                         |
| logical_plan after eliminate_limit                         | SAME TEXT AS ABOVE                                                                         |
| logical_plan after propagate_empty_relation                | SAME TEXT AS ABOVE                                                                         |
| logical_plan after eliminate_one_union                     | SAME TEXT AS ABOVE                                                                         |
| logical_plan after filter_null_join_keys                   | SAME TEXT AS ABOVE                                                                         |
| logical_plan after eliminate_outer_join                    | SAME TEXT AS ABOVE                                                                         |
| logical_plan after push_down_limit                         | SAME TEXT AS ABOVE                                                                         |
| logical_plan after push_down_filter                        | SAME TEXT AS ABOVE                                                                         |
| logical_plan after single_distinct_aggregation_to_group_by | SAME TEXT AS ABOVE                                                                         |
| logical_plan after simplify_expressions                    | SAME TEXT AS ABOVE                                                                         |
| logical_plan after unwrap_cast_in_comparison               | SAME TEXT AS ABOVE                                                                         |
| logical_plan after common_sub_expression_eliminate         | SAME TEXT AS ABOVE                                                                         |
| logical_plan after optimize_projections                    | SAME TEXT AS ABOVE                                                                         |
| logical_plan                                               | Projection: Int64(1) AS a + b                                                              |
|                                                            |   EmptyRelation                                                                            |
| initial_physical_plan                                      | ProjectionExec: expr=[1 as a + b]                                                          |
|                                                            |   PlaceholderRowExec                                                                       |
|                                                            |                                                                                |
| initial_physical_plan_with_stats                           | ProjectionExec: expr=[1 as a + b], statistics=[Rows=Exact(1), Bytes=Exact(8), [(Col[0]:)]] |
|                                                            |   PlaceholderRowExec, statistics=[Rows=Exact(1), Bytes=Exact(0), []]                       |
|                                                            |                                                                                |
| physical_plan after OutputRequirements                     | OutputRequirementExec                                                                      |
|                                                            |   ProjectionExec: expr=[1 as a + b]                                                        |
|                                                            |     PlaceholderRowExec                                                                     |
|                                                            |                                                                                |
| physical_plan after aggregate_statistics                   | SAME TEXT AS ABOVE                                                                         |
| physical_plan after join_selection                         | SAME TEXT AS ABOVE                                                                         |
| physical_plan after LimitedDistinctAggregation             | SAME TEXT AS ABOVE                                                                         |
| physical_plan after EnforceDistribution                    | SAME TEXT AS ABOVE                                                                         |
| physical_plan after CombinePartialFinalAggregate           | SAME TEXT AS ABOVE                                                                         |
| physical_plan after EnforceSorting                         | SAME TEXT AS ABOVE                                                                         |
| physical_plan after OptimizeAggregateOrder                 | SAME TEXT AS ABOVE                                                                         |
| physical_plan after ProjectionPushdown                     | SAME TEXT AS ABOVE                                                                         |
| physical_plan after coalesce_batches                       | SAME TEXT AS ABOVE                                                                         |
| physical_plan after OutputRequirements                     | ProjectionExec: expr=[1 as a + b]                                                          |
|                                                            |   PlaceholderRowExec                                                                       |
|                                                            |                                                                                |
| physical_plan after PipelineChecker                        | SAME TEXT AS ABOVE                                                                         |
| physical_plan after LimitAggregation                       | SAME TEXT AS ABOVE                                                                         |
| physical_plan after ProjectionPushdown                     | SAME TEXT AS ABOVE                                                                         |
| physical_plan                                              | ProjectionExec: expr=[1 as a + b]                                                          |
|                                                            |   PlaceholderRowExec                                                                       |
|                                                            |                                                                                |
| physical_plan_with_stats                                   | ProjectionExec: expr=[1 as a + b], statistics=[Rows=Exact(1), Bytes=Exact(8), [(Col[0]:)]] |
|                                                            |   PlaceholderRowExec, statistics=[Rows=Exact(1), Bytes=Exact(0), []]                       |
|                                                            |                                                                                |
+------------------------------------------------------------+--------------------------------------------------------------------------------------------+
77 row(s) fetched.
Elapsed 0.032 seconds.

It is caused by the columnize_expr function. Based on the comments, I guess columnize_expr is for special needs related to aggregation, and it was introduced in PR #55.
Maybe we can reimplement columnize_expr by directly comparing the aggregated output expressions instead of their display names. Let me try to fix this issue.

take

Wow https://github.com/apache/datafusion/pull/55 is a very old one. Thank you @jonahgao  -- this will be a great fix


Use 'DESO' instead of empty string for DAO coin limit orders

this makes a lot of sense given that go will interpret a missing string value in a struct as an empty string


loopback version update

Describe the bug

loopback version update

:tada: This issue has been resolved in version 5.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This issue has been resolved in version 5.0.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Library Updates Not Syncing

Any library updates made in the app are not syncing back to Kitsu.
09-30 23:08:33.973  3711  3778 D LibraryManager: Synchronizing 1 offline modifications...
09-30 23:08:34.222  3711  3778 E LibraryManager: Failed to synchronize library entry 96423765
09-30 23:08:34.222  3711  3778 E LibraryManager: retrofit2.HttpException: HTTP 400

Kitsune_2023-09-30_23-08-54.txt

Thanks for providing the logs. It is really strange that the server returns a 400 HTTP code. That would basically mean that the library update request was somehow malformed. Haven't seen that before yet.
It would be helpful if you could give me some more context, such as steps to reproduce.
But since I have completely refactored the library management in the latest update, it's quite possible that the bug no longer exists in v1.8.0. Therefore, please update to the latest version and if you encounter any errors again, feel free to respond to this issue or open a new one.

Thanks for taking a look. I have updated to v1.8.0 but the unfortunately has issues updating the library. The new error now shows in the GUI as "Failed to update library entry". The same error happens on WiFi or mobile data. I've checked DNS logs while on WiFi and there are no blocked entries that would like up with the testing (I run AdGuard Home for DNS ad blocking). Android Private DNS was disabled for mobile data testing, so no DNS filtering.
My device I'm using is a Google Pixel Fold, running the Android 14 QPR Beta 1 build U1B1.230908.003 (probably a huge factor).
I've made a screen recording on reproducing the error from a clean install (stored on OneDrive): https://1drv.ms/v/s!Akc_qyFJBJTajJAbAnoAzGKbAD-FsA
Here are the logs from the testing:
Kitsune_2023-10-01_07-40-48.txt
Please let me know if you need any additional information.

Thanks for the detailed information. Unfortunately I cannot reproduce the error on my device.
Could you please try the same thing with the debug build below and send the logs again. The debug build will also log the network requests and should give a bit more insight into what is going on.
Here's the debug build: https://workupload.com/file/MMqVJ2Svf78

I've just installed the debug build and reproduced the error. Please find the logs below.
Thanks for letting me know it will show up twice in the app drawer.
Kitsune_2023-10-01_09-14-32.txt

Sorry, I have deleted your comment as a precaution, because possibly sinsible user data could be logged in the debug logs.

The previous debug build logged all HTTP requests including the authentication request, which contained sensitive credentials. That's now fixed and there shouldn't be any sensitive user data in the logs now.
Here's the fixed build: https://workupload.com/file/v7k7vu6pHC4

Thanks for looking out. I've installed the newest debug build and reproduced the error. Please find the logs below.
Kitsune_2023-10-01_09-52-08.txt

Thanks a lot! I have found the source of the problem. Somehow a parameter "stability" is sent in the library update request, which should not be there.
Request body:
{"data":{"type":"libraryEntries","id":"123456","attributes":{"progress":4,"stability":0}}}
Response body:
"errors":[{"title":"Param not allowed","detail":"stability is not allowed.","code":"105","status":"400"}]}
I will look into that and try to track down where the paramter is coming from.

Thanks for the update! Great you were able to find the source of the issue.

Wow, it took longer than I thought to track down this odd "stability" property.  But the bug should be fixed now.
Could you test the build below to verify. If everything is working now, I will release a hot-fix tomorrow.
Fixed build: https://workupload.com/file/kmhsF9nT3y8

Awesome work! All looks good now; I updated an anime library entry successfully.
Logs attached for reference if you'd like to review:
Kitsune_2023-10-01_15-02-13.txt

Fix got released in v1.8.1.
Thanks for your help!


[torch-mlir] Cherrypick fix to fx_importer causing issues with int types.

Yesterday's bump to torch-mlir brought an update to the fx_importer which broke downstream tests. Cherry-picking the fix (which also includes a unit test to keep it from recurring).

Submitting around infra flake.


Allow choosing Opal versions

the easy path - use bundled opal runtime and compiler with tool. easy to get started. safe due to no mixing and matching compiler and runtime versions
your own static file (instead of vendor/opal-compiler.js)
one fetched from Bundler on the fly
stub out opal requires and supply it outside of webpack (like I did with https://github.com/wied03/webpack_spec_sandbox).

is what I do here https://github.com/cj/opal-connect/blob/master/lib/opal/connect/rake_task.rb and then I include it like:

config.entry = [
    './.connect/opal.js',
    './.connect/entry.js'
  ]

We might want to do 1) and 4).  so the latest version of opal compiled comes with opal-webpack so you can just include the loader and get going.  Thoughts?

A lot of in progress work here already in the other branch but #4 would support that. can explain more later.

Sorry.  Hasty response. That's exactly what I was thinking. Only part of #4
in the branch is it'll stub out opal requires for you if you ask.
But yeah. I was thinking you can lick whichever you want of the 4 and a
default is there like you said.
sent from my mobile device
On Apr 9, 2016 4:53 PM, "CJ Lazell"<EMAIL_ADDRESS>wrote:

is what I do here
https://github.com/cj/opal-connect/blob/master/lib/opal/connect/rake_task.rb
and then I include it like:

config.entry = [
'./.connect/opal.js',
'./.connect/entry.js'
]
We might want to do 1) and 4). so the latest version of opal compiled
comes with opal-webpack so you can just include the loader and get going.
Thoughts?
—
You are receiving this because you were assigned.
Reply to this email directly or view it on GitHub
https://github.com/cj/opal-webpack/issues/13#issuecomment-207867525

By opal requires, mean if I have a bunch of code (stuff from GEMs, wherever) and that code does a require 'opal', which isn't uncommon, and you've chosen to load it outside of webpack (like your example), then you don't want webpack to include anything. basically just syntatic sugar for adding 'opal' to the stubs list.

1, 2, and 4 are already done in the choose_opal_version branch. My next step is to work on 3 and then send you another PR.

Great.  I'll be around tonight 8pm central.

I may not be around tonight. Should be tomorrow though.

This is now coded up. I just need to document how the config works in the README and submit another PR.


Cadence tools refactoring for service

Is your feature request related to a problem? Please describe.
Currently a lot of features are written in CLI and not able to be used by service API.
For example: reset commmand, batch command, admin delete workflow command, etc.
Proposed Solution
Refactor the code in tools/ especially CLI into a way that can be built for both CLI and also a service.
https://github.com/uber/cadence/tree/master/tools/cli
Several options for being a service:

Add to current frontend service
Create a new service in this repo
Create new service in a new repo : this will make releasing versions easier

Additional context
No

👍 Totally agree for commands like batch-reset, etc.
For admin DB operation commands (for example adm delete workflow) I actually prefer to keep them separate from becoming part of cadence services. We can share the code, but making them a service API may make incident mitigation harder I guess? Like if cadence service is down due to some bad workflows and we require talking to cadence service to delete the bad workflows.

Right. I think only certain commands are needed. We certainly don't need to do for all.

Like if cadence service is down due to some bad workflows and we require talking to cadence service to delete the bad workflows.

Actually what I am suggested is to let existing CLI to do the same thing. E.g. deleting workflows should still talk to DB, resetting should still replaying history locally(so that it won't consume frontend's memory which may bring down the cluster)


Testexecution PostTermination mismatch in the initial and final configuration file

Assertion failure details
In RO Individual Services , following are the assertions that are failed because of this problem,

Provides expected properties in configuration class for 'ro-2-0-1-tcp-s-000'
Provides expected properties in configuration class for 'ro-2-0-1-tcp-s-001'
Provides expected properties in configuration class for 'ro-2-0-1-op-c-im-ro-2-0-1-000'
Provides expected properties in configuration class for 'ro-2-0-1-op-c-im-ro-2-0-1-001'
Provides expected properties in configuration class for 'ro-2-0-1-op-c-im-ro-2-0-1-002'
Provides expected length of server-ltp list for 'ro-2-0-1-http-c-tar-1-0-0-000'
Provides expected length of server-ltp list for 'ro-2-0-1-http-c-eatl-1-0-0-000'
Provides expected properties in configuration class for 'ro-2-0-1-http-c-cc-1-0-0-000'
Provides expected number of fc-port instances '10' in forwarding-construct
Provides expected number of fc-port instances '11' in forwarding-construct - count 2
Provides expected logical-termination-point 'ro-2-0-1-op-c-im-ro-2-0-1-001'

Reason  :
In the test execution, the expectation is , the initial configuration file should match the final configuration.
But there is a mismatch. This mismatch are consequences of the failures of other assertions. Once the other assertion failures will be resolved , this shall also be cleared.

Closing this issue as it is not observed in the recent release.


Add 'narrow' Feature to arrow-odbc to Control Unicode Handling in odbc-api Dependency

When using arrow-odbc, we are unable to retrieve column names containing Unicode characters from Oracle databases if the narrow feature is enabled in the odbc-api crate (which arrow-odbc depends on). This is because the narrow feature in odbc-api uses UTF-8 encoding, but Oracle's ODBC driver expects UTF-16 encoding for proper Unicode support.
Please add a narrow feature flag to arrow-odbc that allows users to enable or disable the narrow feature in the odbc-api dependency. This will give users control over the encoding used and ensure that Unicode column names are retrieved correctly from databases like Oracle that require UTF-16 encoding.
Request:

Add a narrow feature to arrow-odbc to control the narrow feature in odbc-api.
This change will allow users to disable the narrow feature when necessary, ensuring proper handling of Unicode characters.

Just to check, while narrow is active the ODBC standard suggestes that the client side encoding is used. On Windows this is usually something like latin1. On Linux most drivers seemed to ignore the standard and just use Utf8. On the other hand many Linux drivers struggle to implement Utf16 correctly.
I wonder if this time the Oracle driver sticks to the standard. Could you test if the system locale suggests to use UTF8? Is the something you can pass in the connection string to set the client encoding?
I am sympathetic to your cause though and will investigate how to best forward the decision to the user, while keeping the defaults intact.

I have tested several SQL tools, including DBeaver, unixODBC's isql and iusql, Rust's odbc-api, C++'s nanoodbc, and others.
Based on my test results, it appears that Oracle does not perform character encoding conversion when creating tables or fetching column names that contain characters outside the ASCII range.
When I create a column named "컬럼" (which means "Column" in Korean) in DBeaver and execute SELECT "컬럼" FROM TEST_TABLE, it works correctly. However, other tools fail to recognize "컬럼". DBeaver uses JDBC with UTF16 encoding.
Conversely, if I create a column with UTF8 encoding using other tools, DBeaver cannot recognize "컬럼".
The hexadecimal representation of the column name in each encoding is as follows:
UTF8: ec bb ac eb 9f bc
UTF16: ceec b7fc
In DBeaver, when creating a table, the execution results vary depending on the feature used:

With odbc-api and the narrow feature enabled, only part of the UTF16 data is retrieved:

Column ColumnDescription { name: [ec, fc], data_type: Varchar { length: Some(64) }, nullability: Nullable }

With odbc-api and the no arrow feature, the full UTF16 data is retrieved, and the string is successfully constructed:

Column ColumnDescription { name: [ceec, b7fc], data_type: Varchar { length: Some(64) }, nullability: Nullable }

When creating a table with UTF8 encoding using iusql, the execution results are:

With odbc-api and the narrow feature enabled, the string is successfully retrieved:

Column ColumnDescription { name: [ec, bb, ac, eb, 9f, bc], data_type: Varchar { length: Some(64) }, nullability: Nullable }

With odbc-api and the no arrow feature, incorrect UTF16 hex codes are returned, making it impossible to construct the string:

Column ColumnDescription { name: [ffec, ffbb, ffac, ffeb, ff9f, ffbc], data_type: Varchar { length: Some(64) }, nullability: Nullable }

Since tools using JDBC are commonly used and they handle UTF16-encoded column names (like those in Korean), I believe it would be beneficial to have the ability to enable or disable the narrow feature in odbc-api to correctly retrieve such column names.

Hello @yjhong79 ,
arrow-odbc 14.0.0 is released. It supports the wide feature flag. It can be used on non-windows platforms to use the wide UTF-16 version of the ODBC function calls.
Let me know if it works for you.
Best, Markus

Hello Markus,
Thank you for informing me about the release of arrow-odbc 14.0.0. I've tested it, and it works perfectly for my needs. The support for the wide feature flag is greatly appreciated.
Best regards, yjhong


Fix test setup for "cpp_locals"

The "extra_directives" were apparently never passed down into the test class and thus never used, leading to redundant identical test execution.
Also, the error tests should never need this duplication and should only run once.

@da-woods I think there are problems with the cpp_locals directive.

There's a mixture of different things there I think:

Some of those failures look like it's dropping the std argument to the C++ compiler when cpp_locals is set. That's probably just an issue in runtests somewhere.
Some of the tests just need manually disabling - essentially cdef some_cppclass x should fail in cpp_locals - it needs to be cdef some_cppclass x = some_cppclass(). That'll just be a case of identifying the tests those tests.
There's some that are generating invalid code/crashing the compiler.

I'll look into the second/third points relatively soon.
(I'm sure the extra directives did work at one point for at least some of the tests, because I did have to manually disable some myself.)

Looking at the memview_vector test: the problem there is that we're applying the cpp_locals directive to utility code and the utility code doesn't support it (for legitimate reasons).  We've already taken the decision that only a small number of directives end up being applied to utility code, and cpp_locals isn't one of them.  However, cpp_locals ends up being taken from Options._directive_defaults.
Is Options._directive_defaults supposed to be modified?  This is how we're passing the directives into the test.  I'd argue that either:

it shouldn't be and we should pass directives into the tests a different way
we need a more-private copy of _directive_defaults used by utility code that doesn't get modified.

https://github.com/cython/cython/pull/6375 fixes one of the issues seen


Final value of training loss

Thanks for your great work! What is the final value of training loss that can be achieved by using intermediate supervision loss？

was training on my custom dataset, wasn`t able to get less than 0.18


better doctest  support

Improvement on my #84.
This looks like a big change, but mostly its just dumping some code from doctest to doctestdrv.m which can:

chdir if it gets a directory
call itself for directory contents.

Todo/decisions:

[x] recursion support
[x] recursion default on/off?  off for now, could easily revisit
[x] better name for doctestdrv.  doctestraw?  its private so doesn't really matter.

Maybe more, but I think this is merge-able now.  @catch22 comments?

Thanks for your work on this.
How about doing the recursion in doctest_collect rather than in the new doctestdrv function?

Ok, makes sense.  But now I should rename it from doctest_collect.  Maybe doctest_core?  doctest_process? something else

I was thinking that doctest_collect would still do just the collecting of test targets (including recursion into directories if that option is specified), while doctest runs the tests.
Was there some technical reason that led you to merge collection & executation?

It was so that I could call chdir to descend into a directory, then call itself recursively on its contents.  I guess it just seems like a simpler design to me.
If I collect them all first, I need to make two traversals (once when collecting and then again when executing.  In practice, I need to record (at least) the path for each target.  I felt this leads to duplicated logic about e.g., class/functions in both the collect and run logic (both need to traverse directories for example).
Other than historical reasons, is there some advantage or feature enabled by collecting them all first?

I thought it was a nice "separation of concerns" to do the test collection and execution independently from each other. The plan that you sketched where you would record the path or working directory in the collection phase and have it used by the runner also sounds like a nice design to me (given that the collection logic alone was already somewhat complex even before the directory support).
However, I don't have a non-hypothetical use case that requires this design. As I also don't have a much time in the coming days to contribute anything useful please go ahead with whatever makes most sense to you right now - we can always refactor later on :smile:

Ok, that sounds good to me.  I certainly don't mind if its refactored later.
But I'm not in any hurry if you prefer to wait?  Or should I go ahead and merge now?

Please go ahead and merge it.


refactor(parser): remove start params for byte_search macro arms

Simplify byte_search macro a bit more.

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

Current dependencies on/for this PR:

#2553  👈
#2552
main

This stack of pull requests is managed by Graphite.

Merge activity

Mar 1, 8:07 AM EST: @Boshen started a stack merge that includes this pull request via Graphite.


log json like objects

Thank you for contributing to naz.
Every contribution to naz is important.
Contributor offers to license certain software (a “Contribution” or multiple
“Contributions”) to naz, and naz agrees to accept said Contributions,
under the terms of the MIT License.
Contributor understands and agrees that naz shall have the irrevocable and perpetual right to make
and distribute copies of any Contribution, as well as to create and distribute collective works and
derivative works of any Contribution, under the MIT License.
Now,
What(What have you changed?)
Why(Why did you change it?)

Codecov Report

Merging #41 into master will increase coverage by 0.04%.
The diff coverage is 95.65%.

@@            Coverage Diff             @@
##           master      #41      +/-   ##
==========================================
+ Coverage   87.47%   87.52%   +0.04%
==========================================
  Files           8        8
  Lines         575      577       +2
==========================================
+ Hits          503      505       +2
  Misses         72       72

Impacted Files
Coverage Δ

naz/__version__.py
100% <ø> (ø)
:arrow_up:

naz/hooks.py
85.71% <ø> (ø)
:arrow_up:

naz/throttle.py
91.83% <100%> (ø)
:arrow_up:

naz/ratelimiter.py
96.96% <100%> (ø)
:arrow_up:

naz/client.py
84.06% <94.73%> (+0.08%)
:arrow_up:

Continue to review full report at Codecov.

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


fix @deriving clash in rescript 9

See
https://github.com/rescript-lang/rescript-compiler/issues/5036
https://forum.rescript-lang.org/t/were-bs-deriving-jsconverter-and-bs-deriving-abstract-removed/1333/12
and https://github.com/reasonml-community/graphql-ppx/commit/b7aff4e26a878be0850e3e964b519f057b4f350a

Hi @davesnx
Has this made it into an proper release of styled-ppx or should i be pulling from git directly?

Hi @AlexMoutonNoble, this was merged a while ago. It shouldn't happen.
Let me try to reproduce and meanwhile if you have a repo with the issue please share it in an issue please!
Thanks for jumping into the PR

Is there some cache of installed ocaml code that I may have old/conflicting versions installed in?  Taking our web directory into a new git repo and building seems to succeed?

reset node_modules and still doing it. hmm.

@davesnx does this one work for you? https://github.com/noble-ai/styled-ppx-clash

Indeed fails, but the issue comes from the @deriving not much to do with styled-ppx (AFAIK)
FAILED: src/navi.ast

  We've found a bug for you!
  /Users/davesnx/Code/playground/styled-ppx-clash/src/navi.res:1:11-18

  1 │ @deriving(abstract)
  2 │ type urlDescriptorPartial = {
  3 │   @optional pathname: string,

  Ppxlib.Deriving: 'abstract' is not a supported type deriving generator

In your demo, there are some dependencies missing: rescript-react, bs-css and bs-css-emotion.
If you can try with https://github.com/davesnx/try-styled-ppx

Btw, feel free to jump on Discord and have it sorted: https://discord.gg/reasonml

The thing is, if i remove the styled-ppx, the example code compiles fine.
Will join the discord...thanks
A

Arg. Discovered the issue. Pushed a new version with a fix (0.34.0)

Rad thanks David. I dont see 0.34 pushed up yet but ill keep an eye out.

It's published (maybe it took a little longer after my comment<EMAIL_ADDRESS>Nevermind, let me know if you run into any issues we battle-tested at ahrefs.com but we don't use it in ReScript and some problems might appear, happy to fix them fast.


Number of commits not counted correctly

Gitea version (or commit ref): 1.4.3 built with: bindata, sqlite
Git version: git version 2.12.3
Operating system: Linux 4.4.138-94.39-default #1 SMP Mon Jun 18 13:27:26 UTC 2018 (baa07f9) x86_64 x86_64 x86_64 GNU/Linux
Database (use [x]):

[ ] PostgreSQL
[ ] MySQL
[ ] MSSQL
[X] SQLite

Can you reproduce the bug at https://try.gitea.io:

[ ] Yes (provide example URL)
[X] No
[ ] Not relevant

Log gist: no error is logged when accessing the commit count or list

Description
The number of commits is not counted correctly. as it can be seen from the screenshot. There are three commits, but it says "1 Commits" on the repository pages.
Also, the uncounted commits are not shown on the user's public activity list on their profile.
What could be done to have the repositories show the correct commit counts?
Screenshots

Do you have a git repository we can test on? Have you tried using the latest version of Gitea? I just compiled the version you have an tested it, I can't seem to reproduce.

@johanhugg I have used the release at https://github.com/go-gitea/gitea/releases/latest as binary, but not the v1.5.0-rc1 pre-relase, as we are using gitea in production. Sorry, I can't make that gitea install available online due to our firewall.
@lafriks The commits where pushed via ssh using password authentication. No warnings or errors are written to gitea.log when pushing or when viewing the commit count.
I noticed that only some commits are not counted - in other repos on that install, there are ten commits but the counter shows only seven. However, all commits where pushed from the same remote.
The partition is not mounted with "noexec", so #1231 does not seem to apply here.

@lafriks Now I see that the commit counter at the repo pictured in the screenshot has updated to three, which is correct. There have been more than 24 hours since the commits where made and pushed. No further pushes have been made to the repo in the meantime.
Could there be a problem clearing the cache on push/merge?

I ran into the same issue as well. Same setup (gitea on sqlite, version 1.4.3, amd64-linux); repository being https://neueland.iserlohn-fortress.net/gitea/aqua/smolbote. The repository is a converted mercurial repo.
Rerunning the gitea instance fixed the commit count.
Creating an empty repository however, and pushing a couple of commits to it properly updates the commit count. (This was done after rerunning the instance.)

Thanks @xiannox, rerunning the gitea instance fixed the commit counter for our problem as well, as far at least for now.
If there is no other solution, setting cronjob to regularly restart the instance could be an option, but I still hope someone can help finding another way.

@bkroll no need to restart. It is cached for 20hours so it will show correct after that anyway. You can also set smaller cache time in app.ini

Thanks @lafriks, I have set ITEM_TTL = 0 to deactivate caching, which provides a workaround to this problem. But now I have noticed that closing or referencing an issue from the commit message does not work either. Could those two problems be related? (I have checked that the noexec problem #1231 is not the case here.)
Is it normal that on ssh push to a gitea repo, no log is written to gitea.log with Debug log level? I'm not sure the hooks are running properly. Also, I have updated the instance to 1.5.0-rc2, but that did not solve the problems.

Check logs if there are any warnings or errors

Thanks @lafriks I watched gitea.log, http.log and xorm.log while I did the following:

pushed first file into empty repo:

"quick guide" still appears after pushing file
nothing logged

created new repo with "initialize repository" option activated, pushed with commit message close #1to close issue:

pushed changes appear in gitea
#1 in commit message is linked to issue page
no reference is displayed on the issue page itself
issue is not closed
nothing is logged.

machine:/etc/gitea # cat app.ini | grep LEVEL -B2
[log]
MODE      = file
LEVEL     = Debug

I tried the same steps on try.gitea.org. There, everything worked as expected. On my machine, I am running SLES 12 SP3 with git 2.12.3 on sqlite db.

Do you have SELinux enabled in enforced mode?

Check /var/log/audit.log if there is anything about gitea 3000 port

SELinux is not enabled, /var/log/audit/ is empty. I looked into /var/log/messages, there are only Macaron log lines in there, but no errors.

I can also confirm, fresh install of 1.5.0 of Gitea.  The only thing I did was create a mirrored repo from GitHub, after the automatic sync has pulled in a few commits I noticed that the commit count is never updated.  A restart of the Gitea instance fixed the count.

@SoulSeekkor There is a fix for mirrored repos already at https://github.com/go-gitea/gitea/pull/4720
@bkroll is this issue on a mirrored repo too or a regular one ?

@adelowo  Perfect, thank you!

@adelowo The issue occured in a regular repo, not a mirrored one.

I have only observed this kind of behavior when pushing via read/write deploy key, which is already reported a while ago in #3795

This happens to me whenever I push from terminal. Doesn't matter if over SSH or HTTPS. It looks like the commit never happened. The only way to see the new commit is to go to the correct branch and check commits.

@Akito13 what version are you using?

@Akito13 what version are you using?

1.6.0+rc1-123-g3379141d8
Though, I have to clarify: I actually don't care if the commits are counted incorrectly. That's not my problem. So I ignored that. But it bothers me, that I can't see pushes on the Dashboard or Public Activity if they are executed from a client in the terminal.

This bug is still not resolved, please do not close.

I still cannot replicate this on a regular repository through

You can check the steps to reproduce of #5058, it's easy.

The issue with deploy keys should be fixed by #5935 and its backport to v1.7 #5944. Is there anything else causing this?

Ok I'm gonna close this as fixed by #5935


The user will be able to filter the search by the movie / series name

Depends on completion of https://github.com/fredsonchaves07/movie-catch-api/issues/36


Error generated from Azure firewall policy rule collection group reports incorrect grammar.

This bug is being reported for the 'azurerm_firewall_policy_rule_collection_group.

Upon trying to use Dynamic blocks with 'each.value.rules/.

The following error is generated by Terraform module
'A reference to "each.value" has been used in a context in which it unavailable, such as when the configuration no longer contains the value its "for_each" expression. Remove this reference to each.value in your configuration to work around this error.

There is a grammatical error, the 'it' after in a context in which, is incorrect, it should be "is unavailable".

Please could this be updated?
Thanks

This issue tracker is for a command-line tool called "hub" which is written in Go, and has nothing to do with Azure firewall or Terraform. Your question seems unrelated to this project, and you should find a more appropriate forum to ask it in. Thank you.


Symfony4 support

Hello,
Is this project abandoned?
How can we use it on Symfony4?

any news on this topic

Sorry, i'm not working with symfony anymore and don't have time to maintain the project. I'll update the readme in that regard.
PRs are still welcome though.


Chest Donation Bug (players can steal)

LWC Version (/lwc admin version):
Main plugin: 1.9.4/
Server version (/version):
PaperSpigot: git-Paper-1452 (MC: 1.12.2) (Implementing API version 1.12.2-R0.1-SNAPSHOT).
Short five word summary of issue:
Players can steal out of /cdonation chests
Detailed description of problem:
Basically with chests that are set to /cdonation players can steal out of them, but only if they have the same item. So if I am to for example have 1 Oak Log in my hand and the chest I am looking at also has an Oak Log in it, if it normally click it, the Oak Log in my hand is added to the stack in the chest, but instead if I shift-click the Oak Log whilst I have an Oak Log on my cursor, it adds the Oak Log from the chest into my inventory.
When you have a chance, can you please look into this bug because personally for me it is quite major and is definitely dangerous in certain cases.

Thank you for the fast response, as much as I'd love to update my server to 1.13, some of the major plugins I currently have are unable to be updated (Mainly the World Generator plugin). Just let me know if anything happens and if you are able to fix this issue.
Thanks once again.

@RednedEpic Yes, in development build 57 for MC 1.13.1. I ran into some difficulties backporting it to older versions but I hope to get around to fixing it this coming weekend. I have been busy, sorry for the delay.

@RednedEpic I managed to fix the issues I encountered backporting the fix to older versions. The exploit seems to be fixed now in that version, but there is no download available for it yet. Tsuser1 wants to have it up on the build server tomorrow, but if he doesn't get around to it, feel free to message me on Discord (pop4959#1781) and I can get you an alternative download link.


Add Dicom events

/azp run net - eventgrid - tests

API change check
APIView has identified API level changes in this PR and created following API reviews.
Azure.Messaging.EventGrid


QOL: Extending zarf connect usability

Zarf Connect Default Stability
Add logic so default zarf connect commands will auto-detect when the standard ports are already being used and use a random open one instead of failing the command.

Using a port other than 45003 since that port was already used on my host machine

Zarf Connect Usability Improvement
Add a utility function so users can figure out which zarf connect commands are available from packages that have already been installed. Super useful for people who are not familiar with the packages that has already been deployed to a cluster.

List all connect options found within the cluster

Filter for connect options that contains part of an optional provided argument filter

We should probably look at these together 😆 https://github.com/defenseunicorns/zarf/pull/511/commits/b350f4ec31399e12698e266bb72f6111994e0129

Closing as this was also implemented in #586


[Snyk] Upgrade @graphql-tools/schema from 9.0.9 to 9.0.19

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade @graphql-tools/schema from 9.0.9 to 9.0.19.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 97 versions ahead of your current version.
The recommended version was released 7 months ago, on 2023-04-23.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Unified search graphql branch is deployed to platta: https://kuva-unified-search-pr119.api.dev.hel.ninja :rocket::rocket::rocket:

Unified search sources branch is deployed to platta: https://kuva-unified-search-sources-pr119.api.dev.hel.ninja :rocket::rocket::rocket:


Add missing dependencies on version.h

Summary of the Pull Request
Add a build-ordering-only dependency on version.vcxproj to all other vcxproj in the repo.

PR Checklist

[ x] Closes: #28618
[ ] Communication: I've discussed this with core contributors already. If work hasn't been agreed, this work might be rejected
[n/a] Tests: Added/updated and all pass
[n/a] Localization: All end user facing strings can be localized
[n/a] Dev docs: Added/updated
[n/a] New binaries: Added on the required places

[ ] JSON for signing for new binaries
[ ] WXS for installer for new binaries and localization folder
[ ] YML for CI pipeline for new test projects
[ ] YML for signed pipeline

[n/a] Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

Validation Steps Performed
I've run a bunch more builds and they have not failed.

Thanks for the trying it out @jaimecbernardo! That is certainly not expected - but I think I have an idea as to what is going on!  I will follow-up shortly.

Almost all projects depend (directly or indirectly) on SettingsAPI.vcxproj and/or logger.vcxproj, so I added the made the implicit dependency explicit there. This allowed me to remove a bunch of version.vcxproj references - and then add a few for projects that did not depend on those two common projects.

Any feedback @jaimecbernardo ?

Thanks for the changes @johnterickson ! Sorry for the wait.
We recently did the 0.74 release, so I currently have the team focused on regressions / hotfix material. I plan to get back to reviewing early next week.

@jaimecbernardo I've compiled and tested it on MS Edge arm64 and it works.

@johnterickson Hi, after this MR I can not build release local. Module PowerToysSetupCustomActions error LINK : fatal error LNK1104: cannot open input file installer\Debug\Version.lib, revert this commit all working fine, do you have any information about it? Thank you.

Sorry for the disruption! I am digging into this. I did notice that there were places where Release builds were using Debug dependencies.  This is similar: the Release setup is trying pull the Debug version.lib.

@quyenvsp WHEW - this was a bit of a wild goose chase!  Please check out #29232.


How to add redirect Thank you page after submit contact form

Hi guys,
I would like to redirect thank you page from contact us page after submit contact form, does anyone knows how to add code php in contact_me.php?
Thanks,
Shaun.

The contact_me.js file has the action in it to display the success message when the form is submitted successfully. You would need to go there and write a new function, replacing lines 33-46, with a function that redirects the user to a new page once a successful submission is made.


Update PIREP source to be acars instead of manual

Closes #82
See app/Models/Enums/PirepSource.php for the source type that is currently in PHPVMS7. This fix will display the PIREP as coming from acars

This is already resolved in the phpvms7 branch. Thank you anyways!

This is already resolved in the phpvms7 branch. Thank you anyways!

No dramas 😄


cloud: fix test_s3_storage

Signed-off-by: Yi Wu<EMAIL_ADDRESS>What problem does this PR solve?
Issue Number: close #10574
Problem Summary: test_s3_storage is only available when failpoint is available. Fixing it.
What is changed and how it works?
What's Changed: run test_s3_storage only when failpoint is available
Related changes
N/A
Check List
Tests
run the test
Release note
None

/build
/merge

/merge

/test


Allow property (dotted) access syntax for types with string index signatures

It doesn't make much sense to forbid property access (o.unknown) syntax on a type with a string index signature, but allow element access syntax (o['unknown']).
Note that this should only apply to types with an explicit string index signature — element access is currently allowed on any type if you don't pass --noImplicitAny, but this should not be true for property access.
Given
type Flags = {
  aLongName: boolean;
  anotherReallyLongOne: number;
  someOtherOnes: boolean;
  [other: string]: number | boolean;
}

Expected behavior:
function f(flags: Flags) {
  flags.aLongName; // ok
  flags.anUnknownName; // ok
  flags.aLongname; // ok, but misspelled
  flags['aLongName']; // ok
  flags['anUnknownName']; // ok
  flags['aLongname']; // ok, but misspelled
}

Actual behavior:
function f(flags: Flags) {
  flags.aLongName; // ok
  flags.anUnknownName; // error, unknown
  flags.aLongname; // error, misspelled
  flags['aLongName']; // ok
  flags['anUnknownName']; // ok
  flags['aLongname']; // ok, but misspelled
}

It doesn't make much sense to forbid property access (o.unknown) syntax on a type with a string index signature, but allow element access syntax (o['unknown']).

It makes a lot of sense to me - dotted access is used when the programmer expects the property to have some particular meaning. A map (string-indexed type) is homogeneous, thus the expectation is wrong:
var stuff: { [key: string]: string };

for (var i = 0; i < stuff.length; i++) { // oops, this is nonsense - the "length" property
                                         // doesn't have any special meaning on this object
    console.log(stuff[i]);
}

I'm strongly against this change. I don't have data for modern JS usage but it used to be that when people used objects as a hash table they used indexing access. It might have been because of experience with more rigid languages but I believe the real reason was because it is a different logical use and indexing conveys it to the reader. Also, if this gets merged in we'll lose valuable type checking.
My plea is if you decide to go for it, please add one of your "favourite" flags to turn it off.

@gcnew, the proposal is only limited to types that have index signatures, and not all types. does this change your feelings about it?

@mhegazy No. The reason is twofold: objective - we'll lose some static typing (because it will no longer mean that "known" properties are hard checked) and subjective - it incentivises dot access for hashes, which adds burden on the reader.

Good suggestion.  Will help in declaring types/interfaces for JSON structure which are received via API's

Agreed, this proposal make sense.

TLDR: this is an excellent change. The imomportant thing here is that one should not have to resort to using the any type to access a property.
@jeffreymorlan

It makes a lot of sense to me - dotted access is used when the programmer expects the property to have some particular meaning. A map (string-indexed type) is homogeneous, thus the expectation is wrong:

I vehemently disagree. They are often heterogeneous and that is what makes them useful.
A common example is a dynamic collection of form fields. Each value has an often dramatically different shape from the others, with completely unrelated properties such as options lists, regex validators, function validators child fields and so on. Using index syntax to access this value has two purposes:

To access fields dynamically via external key, for example mapping from a property present in the current shape of the form model into the object to retrieve another child fields, options, or validators.
To retrieve the value of a statically known key which is a not valid identifier.

When writing JavaScript, I use the indexer syntax only when a key is not valid identifier. This was actually probably the most difficult part of adopting TypeScript for me, I got over at like 4 years ago but it is still annoying. Fundamentally this far less readable to have to use the string syntax.
@gcnew

I don't have data for modern JS usage but it used to be that when people used objects as hash tables they preferred indexing access.

Even if this is true, I don't see much value in it. It reflects, as you point out, experience with statically typed languages like Java that are unable to express flexible patterns like heterogeneous collections in the typesafe fashion.
Map<string, object> is only homogeneous in the most vacuous sense, it is in fact a static type offering no valuable type safety and a generic instantiation that has no place in a statically typed language that has union types.
As Douglas Crockford said, JavaScript objects are like little hashtables and this is a great thing.
I strongly support this change.

@aluanhaddad

Are you saying that they should be using classes for standard types and ES2015 Maps for everything else?

No! All I'm saying is that currently MapLikes are obvious and using dotted properties you are 100% safe. This suggestion blurs the line and chips away type safety. I'm a supporter of adding more guarantees, even if it means giving up some otherwise valid syntax.
The following stays the same:
type Coloured<T> = {
    colour: 'red' | 'green' | 'blue',
    value: T
}

declare const c: Coloured<string>;
c.color // Error: typo mistake

However this will change in a negative way:
type WithColour = {
    colour: string,
    [key: string]: string | undefined
}

declare const d: WithColour;
d.color // BAD! Currently an error, will no longer be
d['prop'] // it's obvious we venture into the unknown

d.prop // BAD: Does such a property exist? We'll no longer be sure :(

For me there are two distinct uses of JavaScript objects. One is for structured data - the properties are well know and enumerated in advance. The other is for Maps/Dictionaries/Hashes/you name it. This second one is completely different - we do dynamic lookup based on arbitrary keys for which a value might or might not exist. To be allowed to do this we provide an indexing signature on the type. For me it's only natural to use this very same indexing for access as well. It also conveys the idea that the object is a Map and there is a good chance a corresponding value not being present.

PS: Indexing signatures should always return T | undefined, and definitions like
type WithColour = {
    colour: string,
    [key: string]: string | undefined
}

should be illegal. The above definition can easily be broken:
declare const d: WithColour;
const key: string = true ? 'colour' : '';
d[key] = undefined;

d.colour // says type `string` but the value is actually `undefined`..

@gcnew I understand why you feel that way, but it is cumbersome to be required to use subscripting syntax to access a "dynamic feeling js object".
The only alternative is resorting to any which is much worse. Obviously it is just syntactic sugar, and not much at that, but it is very true to the nature of JavaScript.
That said, however, I appreciate the argument that the reduced safety might not be worth it, especially as type inference becomes more and more powerful, the need for dynamic dotted access becomes less and less of an issue.

I can see the argument on both, and feel both. Can we have an option to toggle that?
{
  "compilerOptions": {
     "allowDottedSyntaxForIndexes": true/false
  }
}

As @unional  said, I can't imagine this behaviour without an option, as it is a breaking change...

@abenhamdine it's not a breaking change - it's actually more permissive. More code will work, however, it's not necessarily clear to me at this time whether everyone's on board with the idea.

Ah yes, you're right, it's definitely not a breaking change, sorry.
But the change breaks the expectations of some developpers, so in this way, an option would be a good thing.
However, I think this change would be indeed very useful.

We discussed this in our design meeting today, and most of the team seemed in favor of moving forward.

Here's the PR again: #12671
Looking for reviewers!

We discussed this in our design meeting today, and most of the team seemed in favor of moving forward.

Why? I have yet to see anybody post any actual code that benefits from this change, that can't be written in a better way in TypeScript 2.1.
I've already demonstrated how this proposed change makes the type checker less effective at finding common errors and nobody seems to be able to concretely demonstrate the supposed upside. Even the original comment of this issue shows a misspelling going from a detected error to an undetected error!
There did used to be times when you'd want to use string-indexed types even when you know the set of valid properties, because variable indexing and mapping only worked on indexed types before, but the new keyof and related type operators fix that.

Here's an example of a function that returns the kind of object I'm thinking of:
function getPageParams() {
    var ret: ??? = {};
    if (location.hash) {
        for (var kv of location.hash.slice(1).split('&')) {
            var [k, v] = kv.split('=');
            ret[k] = decodeURIComponent(v);
        }
    }
    return ret;
}

The returned value has a type that currently can't be expressed properly. It's not a homogeneous { [key: string]: string } map; it's an object with some fixed set of properties each with a particular meaning - but that set is dependent on something only the caller knows (the current page). Today I'd probably type it as any, but that's unnecessarily weak since we at least know that the values must all be strings. { *: string } would be perfect.

What we need is a new kind of indexed type with its own syntax, maybe something like { *: T }

I am not against something like this, but my suggestion to add a new signature type was met with a lot of groans. 😄

Would this change be able to also improve object prototype type safety with index signatures? I've run into a lot of people using objects like maps but unaware their code could error if they used the object prototype methods directly. E.g.
interface Foo {
    [index: string]: string
}

const x: Foo = { hasOwnProperty: '' }

x.hasOwnProperty('bar') // Runtime error.

It'd be great for hasOwnProperty in this situation to have a union of the times so the developer wouldn't be able to shoot themselves.

Would this change be able to also improve object prototype type safety with index signatures? I've run into a lot of people using objects like maps but unaware their code could error if they used the object prototype methods directly.

No. this is rather cosmetic change. whatever you could access using x["propName"] before, after this change you should be able to access it as x.propName. No changes to the types are involved.

Thanks @mhegazy, is there an existing issue for this or would you like me to create one?

Not that I can find.

I am not against something like this, but my suggestion to add a new signature type was met with a lot of groans.

IMO be conscious to overloading, that's a road to messiness. 🍻

@unional sage advice 😄

@gcnew @unional I think it should've be more something like this to match noImplicitAny:
{
  "compilerOptions": {
     "noImplicitDynamic": true/false (default false)
  }
}

Can this feature be disabled via a flag? For users that prefer type safety to the convenience it provides.

I agree with @bondz and @gcnew  - I tend to use x["propName"] when I know the property may not exist.  I may even be using x[varStoringPropName] since I'm using a variable to tell me which property to access.  I know it's the same as using x.propName but the former feels more like a "here be 🐉 s" in my codebase and the latter is used 99% of the time since I know there's such a property.
I know it's only for certain types, and admittedly I don't use those types that often, but it does feel like something best put behind a flag if possible.
I'd rather see nameof implemented 😺

As @abenhamdine said, this change breaks the expectation of developers, but I would not add Yet Another Flag (TM) though. The flag situation is bad enough as it is
To be honest, even if I don't support this change, having an object that has both named properties and an index signature is a mix of concerns in the way that @gcnew explained. You either have a dictionary-like data structure, where the keys are data, or you have a structured object, where each property is known in the code and specially handled. Having a hybrid is just a source of WTFs/min, regardless of how TypeScript decides to handle it.

I agree with @bondz and @gcnew - I tend to use x["propName"] when I know the property may not exist. I may even be using x[varStoringPropName] since I'm using a variable to tell me which property to access. I know it's the same as using x.propName but the former feels more like a "here be 🐉 s" in my codebase and the latter is used 99% of the time since I know there's such a property.

Exactly, that's why it would have been great to distinguish the two differents cases on a per-object basis, and not in the whole code (without consideration of a global flag).

@use-strict I think the point of this addition is to be more idiomatic JavaScript to the native developer. This seems like a point where the dynamic nature of JavaScript is clashing with the type correctness that Typescript brings us.
@sandersn Instead of adding yet another flag, what do you think about changing the type of the noImplicitAny flag?
Option 1: A union type of  boolean | "StringIndexOnly" | "ObjectOnly".
Option 2: A union type of boolean | Array<FlagOption> where FlagOption = "StringIndex" | "Object". At some point, more options can be added later, and true/false can be deprecated.
Definitions:

true allow neither implicit any nor dotted string index access
false allow both implicit any and dotted string index access (default)
StringIndexOnly/StringIndex allows implicit any but not dotted string index access
ObjectOnly/Object allows dotted string index but not implicit any

This way it would reduce the number of flags needed in the tsconfig.json file and allow developers to gradually pick their level of enforcement.

Please see this as well: https://github.com/DefinitelyTyped/DefinitelyTyped/issues/15683

@massimocode Maybe they could instead add a per index signature explicit any only override like explicit [index: string]: any; to let the author decide typing enforcement. TypeScript 2.3???

That's definitely one possible approach but it would also mean updating loads of different type definitions and also getting into arguments with people about whether or not their typings should be explicit or not. Also technically probably more difficult to implement.
For me, a simple compiler flag would be awesome. That way different teams/projects can use different settings to suit their coding styles/preferences.

@massimocode They seem to be pretty much against having explicit any with index signature because it balances some internal sense of equality. I think your link shows an excellent example of where it fails. In that example, do explicit properties like $broadcast lose type definition? Maybe instead implicit [index: string]: any; would work better.

They allow operator overloads in languages like C# for implicit object assignment without boxing/unboxing issues. Syntax like that would make sense for any type of implicit conversion. In this case, it's implicit conversion to any.

@wizarrc Explicit properties still work fine. For example:
$rootScope.$on(false); // this gives an error
$rootScope.$one(false); // this does not give an error as it falls back to the indexer of type any

I personally think that the type definition is incorrect, but the following still applies:

Updating the type definition means breaking usage for everyone who's relying on the indexer. Personally I think this is a good thing but I can also imagine all the TypeScript haters who would have yet another anecdote to tell when they say "typescript is rubish becoz our bild keeps braking" (deliberately spelt like that because that's usually about how far their intellect goes)
There are some use cases where a dictionary might have helper methods on it. I've had a look on DefinitelyTyped and there seem to be quite a few valid use cases:
https://github.com/DefinitelyTyped/DefinitelyTyped/search?utf8=✓&q="[index%3A+string]%3A+any%3B"&type=
I definitely agree that this is a terrible coding/design practice given javascript's dynamic nature and probably why the ES6 Map has an explicit get(...) method, but having said that there's nothing in JavaScript that prevents this and from what I understand the point of TypeScript is to be able to apply strong typing to as many of the JavaScript usages as possible.

What if i have a interface like this
interface InterfaceSharedAmonyDifferentProjects
{
  method1():void;
  method2():void;
  [index: string]: any;
}

How is type safety enforcement supposed to work if different developers work on this interface in different projects? E.g. dev 1 changes some method signatures and dev 2 does not get compiler errors when he uses the new version of the interface in his project.
Or what about type definitions (e.g. jquery uses indexers)? When method signatures are changed, the user does not get type errors.
Very bad indeed. Please at least provide compiler flag for old behavior (and/or other indexer type) :)
PS. reverting back to TS 2.2 (sadly)

Why does jQuery have that index signature in the first place?

The return type of the indexer was originally HTMLElement but changed to any by this PR: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/413
I think someone thought $("body")["0"] was valid use case years ago.

We should nuke that from orbit. string -> any indexers are basically a free for all; this is probably hiding a lot of other bugs

Opened a PR to remove that line and found a bug on TSLint side that object-literal-key-quotes rule is not applied for interfaces with string indexers :smile:

I believe this change made more evil then good. What I can't understand why it wasn't introduced via an compiler option, or at least an options for old behavior was provided. It's too nuclear change.
You may say "just remove index signature".  But in our case it's not easy to do. We have a hierarchy of UI components with corresponding Options interfaces for them (a component's constructor accept an object of component's Options interface). But there're also mixins which provide shared logic for components. And sometimes there should be set options for a component with options for mixin and they are not part of component Options interface. So base component class has indexing signature to allow extensibility.
But now we lost typing for component Options at all.
I guess that it's unlikely that the feature will be rolled back but please provide an option to revert pre-2.2 behavior.

@evil-shrike Can you provide code examples of how your components have been affected by this change? Consider opening a separate issue referencing this thread so that it can be properly triaged.

What I am missing is something like:
type dotKeys = "key.1" |  "key.2" | "complex.key.defined.here" | "simple.key";
interface HasKeysWithDot{
    [x: dotKeys]: string;
}

or even better
type PropertyKeys = "normal" |  "key.test" | "design.long.test" | "with.number.1";
interface DefinedKeys<T> {
   [x:T]: string;
}
let objectWithDotPropertyKeys: DefinedKeys<PropertyKeys> = {
   "normal": "test",
   "key.test": "test2",
   "design.long.test": "test3"
}

Assigning object with dot keys is possible approach in javascript. There should be some typings for this.


UIs for creating, editing, viewing, and browsing rights statement shells

Adds UIs for creating, editing, viewing, and browsing rights statement shells (and associated acts). All fields are available to view and edit; additional validation dependent on rights basis will need to be added. A table was used in the rights shell detail view to show all fields, but that may not be the best way of presenting information.

@helrond I don't love the table either, but I wasn't sure of a better way. It looks like Aurora uses the timeline functionality of Bootstrap, which I wasn't sure how to implement it. Would it be better to just go with fields surrounded by <p> tags for now?

@bonniegee I think that timeline is an AdminLTE thing; it's not in Bootstrap.
Either just plain <p> tags or a definition list would work for now, I think.

Nice! I'm seeing the need for page titles, which I think are implemented in the views using the PageTitleMixin and page_title attribute.


Project structure services

Changes

Add services.py to allow third-party services from P' @NorakGithub request

Closes #2


fix: improve stability of Newton Raphson by symmetrizing the Hessian

Summary
This PR ensures that the Hessian computed locally in the NewtonRaphson strategy is numerically symmetric by computing
hessian = 0.5 * hessian + 0.5 * hessian.T

Indeed, floating point errors may make it slightly asymmetric as it is computed by pytorch, resulting in very low eigenvalues. This can be verified by running the introduced test on main, which fails without the patch;
Notes
The bug was originally spotted by @jeandut ;)
Please check if the PR fulfills these requirements

[x] If the feature has an impact on the user experience, the changelog has been updated
[x] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been added / updated (for bug fixes / features)
[x] The commit message follows the conventional commit specification

Thanks a lot for catching and correcting this with a test 😍

All credits to @jeandut for encountering the error

If its ok for you, we can merge my commit and then your PR to include it in the next week release :)

This is very helpful indeed, thanks! This is merged.


Add support for installing Liberty from the Liberty repository

a)InstallLiberty task was added to the plugin based on install-liberty
from Ant
b)Parameters were added to the plugin extension
c)Updated documentation

Looks pretty good. It would be better to move all these install properties into a separate object. Something like:
liberty {
    install {
      licenseCode="<license code>"
      runtimeUrl="<url to runtime.jar>"
   }
}

This would also match closer to what Maven plugin is using.

I made the changes to do this in the way you suggested. Now installFeature task work this way:
liberty {
    installLiberty {
        licenseCode = "<license code>"
        runtimeUrl = " <url to runtime.jar> "
    }
}
````

Please review @0df7048a9b86e2eb9e4c5e6a51bff71ff12734ef

Thanks!


Randomize hardwareConcurrency for better anti-fingerprinting protection

Currently it's fixed to 4, but it'd be better to return a random (valid) number, e.g., one of these. I'd be happy to submit a PR if desired. (I found a blog post discussing this, but can't remember where.)

PRs welcome, This is a good idea, although I suspect JS fingerprinting is a couple steps of this. Although it certainly wouldn't hurt. How I would implement this is make the override argument (not the switch itself) optional with a default of None. If the user does not provide an overide value (IE the override value is None), randomly select one. If you wanted to be realistic, you could draw from a hardware survey source like this: https://data.firefox.com/dashboard/hardware


OPA - Re-enabling OPA not always succeed.

What kind of request is this:
Bug
Steps to reproduce (least amount of steps as possible):

Create a cluster, navigate to dashboard
Navigate to OPA Gatekeeper
Click Enable
Wait for the App to be enabled and get redirected or refresh if stuck rancher/dashboard#746
Once OPA is enabled click in the 3 dots button and click in the Disable action
you should be redirected to the OPA Gatekeeper Description Page

Once here the Customize and Enable buttons should be available again

Click Enable

Result:

Rancher Logs show this error a few times:
2020/06/11 19:14:55 [ERROR] error syncing 'gatekeeper-system/gatekeeper-controller-manager': handler workloadServiceGenerationController: cannot find app namespace in labels of gatekeeper-system, requeuing
Other Information:
The rancher-gatekeeper-operator app is stuck in Deploying state.

In 2.4-head not getting redirected after clicking enable or disable is common but not in master (#746)
After some time the Customize and Enable button are clickable but I can't enable OPA again:

Environment information

Rancher version:

master-head (06/11/2020) b89c3a572

Installation option (single install/HA): Single
Cluster type: RKE (DO)

The API to deploy and remove charts, and the chart itself are totally different now, so this is not relevant anymore (though the new OPA chart might have different problems uninstalling or reinstalling)


Character Create.

This script copy smaples when create character ? I have rook sample and script not copy posx posy and posz to character.

No, it does not use samples, it creates the character in players table itself.

Then i must use default option on table ye ?
04.12.2016 19:21 "Daniel Speichert"<EMAIL_ADDRESS>napisał(a):

No, it does not use samples, it creates the character in players table
itself.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/DevelopersPL/DevAAC/issues/35#issuecomment-264720619,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AXJ6RnwB0LvWjlpKxbn2uOiHlkPvLYpPks5rEwScgaJpZM4LDpff
.

It would work. Or you can simply set default values on the model in DevAAC (that involves modifying DevAAC code).


chore(workspace): Remove kona-plasma

Overview
Removes the kona-plasma crate. Plasma has been removed from the protocol, in favor of external Alt DA implementations such as Celestia and EigenDA. This crate is unused and sits in kona as dead code at the moment.
As Celestia / EigenDA develops, we may add alt-da capability, but for now, there is no need to keep this code around.

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

Project coverage is 78.4%. Comparing base (4bdb187) to head (4b1f2c5).

Additional details and impacted files

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


Don't attempt to use pty=true if pty isn't available.

Hopefully fixes #62 by attempting to load the pty module to see if we're running on an OS that supports it.

@bonfirefan Can you check to see if this code works on your machine?

I didn't see this when I left the comment on the issue -- I think this is better than explicitly checking platform like I suggested.

Hey there! I can confirm that the pyt module error no longer halts execution for runtests. However, I'm encountering some other file not found issues which seem ALSO specific to windows - I'm likely going to switch to linux via a VMbox I have installed.

+1 for the expediency of using a virtual machine, but please file an issue
-- this really should work on windows!
On Wed, Aug 16, 2017 at 11:01 PM, bonfirefan<EMAIL_ADDRESS>wrote:

Hey there! I can confirm that the pyt module error no longer halts
execution for runtests. However, I'm encountering some other file not found
issues which seem ALSO specific to windows - I'm likely going to switch to
linux via a VMbox I have installed.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/City-Bureau/documenters-aggregator/pull/64#issuecomment-322962995,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAmuzHCi5I590TnhvGyZs5SbeQ3Db-sZks5sY7sXgaJpZM4O5EGX
.

--
David Eads | http://recoveredfactory.net
"Medical statistics will be our standard of measurement: we will weigh life
for life and see where the dead lie thicker, among the workers or among the
privileged." -- Rudolf Virchow


mne.io.read_raw_fil should support datasets without sensor positions

Describe the new feature or enhancement
It would be great to generalise mne.io.read_raw_fil so that it would read in data which didn't have channel positions, or the documentation should reflect that the positions.tsv file is required to use this method.
Describe your proposed implementation
The existing method can be used, but should have a case to handle an instance of this file missing.
Describe possible alternatives
n/a
Additional context
No response

@georgeoneill

Maybe a new on_pos_missing='raise' would be good. Then set the loc to nan if no positions provided

This should be pretty easy to implement. The code already assumes there is no position information for any sensors, but for some reason I forgot to get to check if position files exists in the current iteration of the code.

Thanks for looking into this


Timex.Ecto.DateTime fields and Phoenix.HTML.Form methods

Loving Timex so far, thanks for the great library!
It would be lovely if Timex DateTime fields would integrate with Phoenix.HTML's form methods (date_select, datetime_select, time_select, and friends).
This appears to need integrations on both sides:

When reading the current value of a Timex.Ecto.DateTime field for display in the form select
When writing the changes to a Timex.Ecto.DateTime field

I'm happy to contribute this feature, but I may need a little guidance on the best way to go about it.
(This may be outside the scope of what timex_ecto does. I'm open to suggestions in any direction that seems most profitable.)

Looks like that will need to be implemented as it's own library. I can add that to my TODO list, but if you want to work on such a thing, I'd be glad to provide advice/etc as needed. You could use phoenix_calendar as a reference implementation, since it should be almost identical really.

1

@bitwalker I hope @jerodsanto doesn't mind, but I simply needed it working ASAP and decided to give it a try myself.
First I followed your pointer and built https://github.com/Paradem/phoenix_timex inspired by phoenix_calendar, but it became clear that Phoenix.HTML.safe will simply allow us to use Timex in our templates directly (and get rid of the 'protocol Phoenix.HTML.Safe not implemented for...' error). @bitwalker I would appreciate any help with it since now it's including the time ("year-month-day h:m:s") when using a Timex.Ecto.Date struct.
What @jerodsanto seems to be requesting is to allow Ecto to take data from a Phoenix.HTML form and store it in a Timex field in the database. I also gave this a try and ended up with this PR. I would also appreciate it if @bitwalker could take a look

@kiliancs I don't mind at all! I got pulled away to something else and hadn't had a chance to work on this. :+1:

@kiliancs I've merged your PR, is there anything in particular you'd like me to look at in phoenix_timex?

Thanks @bitwalker :)
I think it would be great if you could suggest a way to format dates without time information. For example I have a database column with only a date and phoenix_timex formats it including the time information (all zeros).

@kiliancs Looking at the code, it looks like you are assuming Timex.Date and Timex.Time are structs, but they are not, they are just modules for working with either datetimes or times. The only struct in Timex itself is Timex.DateTime. When you pull a record from Ecto using timex_ecto, you are getting a Timex.DateTime struct out, so defining the protocol for the Timex.Ecto.* types probably isn't useful.
If you want to format the dates, you have two options the way I see it:

In your protocol, conditionally check if the time is 00:00:00 UTC, and if so, format it like a date without time.
Manually format the DateTime struct in your view using DateFormat.format.

Perhaps at some point in the future I'll introduce a Timex.Date struct for working purely on dates, it was a design decision early on to use a unified type to keep the complexity down, and it looks like this might be the one edge case where it's kinda awkward :(.

@bitwalker, I updated PhoenixTimex with your recommendations. I will release it as a Hex package in the next few days.

Right on! I left a comment on your commit, just one thing you may want to consider before publishing.


fix(oscal): deterministic OSCAL model write

Description
This fix implements sorting based on the fields we currently operate within on component-definition and assessment-results to  make determinism both an initial write activity as well as a corrective action.
Goal for OSCAL operations is to not assume anyone has always started with Lula - rather allowing for people to bring their OSCAL and enable Lula to provide value without strong opinionation. This is why the execution is centered on the write as opposed to creation of objects. This makes it applicable any time a file is written to - including compose, validate, evaluate, generate.
I see this change as important for those storing resources in version control. The component-definition.md document did not exist - So i've started an initial draft for iteration. we should make this a requirement each time a new model is introduced.
Please check my process - if there are more optimal ways to accomplish this I am all ears/eyes.
Edit: also added a cspell.json file to the repository to start tracking spelling because I apparently cannot spell satisfied
Related Issue
Fixes #542
Type of change

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Other (security config, docs update, etc)

Checklist before merging

[x] Test, docs, adr added or updated as needed
[ ] Schema Updates applied
[x] Contributor Guide Steps followed

istio-composed.yaml is probably there accidentally, just calling it out


README: Updates link to config/caps

Description
Fixes link behind "config/caps" in the README.md

Neither https://github.com/Shopify/kubeaudit#contribute nor https://github.com/Shopify/kubeaudit/blob/master/CODE_OF_CONDUCT.md giving me any hints about the CLA.
And it's only just a link I fixed. Maybe that's a bit too much of a fuss.

Hi @schnatterer! I'm sorry for missing this, the CLA form is here: https://cla.shopify.com/! Let me know if you have any questions, I'm sorry this was so difficult to find (it took me a minute too!)

@catherinejones Thanks, signed! How to rerun the check?

Hey @schnatterer, thanks for your contribution! You can re-run the check by commenting
I've signed the CLA!

I've signed the CLA!


ENH: scipy.sparse: copy keyword added to asformat method

I added a copy keyword to the asformat method of the sparse matrices in scipy.sparse.

Thanks for the comments. I made the proposed changes.

Looks good, merging.


Refactor in several libs to make this smaller and easier to reason about

Initially this repo was about integrating multiple small components into a simple retrieval system
it now growed a lot and got a lot more features
and it's becoming too big
to grow in a reasonable way, let's extract big components in smaller libs and use them here:

[ ] clip inference
[ ] clip back
[ ] clip filter

should be independent libs
img2dataset and autofaiss are already independent

Now even more important with clip client has it wouldn't need much dependencies at all if it was its own module

i might tinker with this refactor


Access children routes from parent StackNavigator

Hello,
I have the following issue.
My main navigator :
export default StackNavigator({
  login: {
    screen: LoginComponent,
  },
})

And in my component Login
class LoginComponent extends Component {

  static navigationOptions = {
    title: 'Register',
    header: ({ navigate }: any) => {
      return {
        right: (
          <Button title='next'
                  onPress={() => {
                    navigate('routeB');
                  }}/>
        ),
        visible: true,
      };
    },
  };

  render() {
    return (
      <View style={styles.container}>
        <SignupNavigator />
      </View>
    );
  }

}

which render a second navigator (children) called SignupNavigator
export default StackNavigator({
  routeB: {
    screen: ComponentB,
  },
})

My button never manages to go to the children routes routeB, am I missing something or doing something wrong here?
I tried using dispatch and create a full action but nothing works.

What renders for the first time when you open the app? From the snippet, looks like routeB with ComponentB renders by default.

My button never manages to go to the children routes routeB

Not sure how it would. Did you mean routes of routeB? Is routeB another Stack Navigator?

I updated my comment.
So basically when I render the app the defaultNav navigator renders with the LoginScreen as the main route.
This one render by default the ChildComponentA.
My issue is that I would like to go to the childRouteB from the DefaultParentComponent
``

I have the same problem here and now. I want to from a screen in the parent navigator, to access a screen in the child navigator. How can we do that?

Hi! In an effort to get the hundreds of issues on this repo under control I'm closing issues tagged as questions. Please don't take this personally - it's simply something we need to do to get the issues to a manageable point. If you still have a question I encourage you to re-read the docs, ask on StackOverflow, or ask on the #react-navigation Reactiflux channel. Thank you!


chore: start testing with .NET 5

Since .NET 5 is due for GA later this year, start testing on the current release candidate to ensure everything works smoothly.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

AWS CodeBuild CI Report

CodeBuild project: AutoBuildProject6AEA49D1-Blkkw9bQFn8A
Commit ID: f892d40807dfb83ad109648afb3de3f043c28bba
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: AutoBuildProject6AEA49D1-Blkkw9bQFn8A
Commit ID: 5bb31777cb3076e7fcbce0eae4762aafa2dd6024
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: AutoBuildProject6AEA49D1-Blkkw9bQFn8A
Commit ID: 8f67574a7401d5ef7214565e08b4db0e06a1daad
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: AutoBuildProject6AEA49D1-Blkkw9bQFn8A
Commit ID: 8d23d096cb635e73e8f6a61e05ead8385477c227
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: AutoBuildProject6AEA49D1-Blkkw9bQFn8A
Commit ID: b6d0e3be93d8964f6a8c506ca0f9b05686f9586e
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: AutoBuildProject6AEA49D1-Blkkw9bQFn8A
Commit ID: a4fee2d7318d3a848ee5959d1c0c2d1811dc01d2
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository


Warning in System: Access: Groups If the group has no member.

If a system group has no members, the following is displayed:
Warning: count(): Parameter must be an array or an object that implements Countable in /usr/local/www/system_groupmanager.php on line 388 0
OPNsense 19.1.5 (amd64, OpenSSL).

@datiscum thanks for reporting, it's probably a regression in php7.2 migration.


Added copyright page

Related Issue
[Cite any related issue(s) this pull request addresses. If none, simply state “None”]
Fixes:  #1072
Description
created and added a responsive copyright page.

Type of PR

[ ] Bug fix
[x] Feature enhancement
[ ] Documentation update
[ ] Other (specify): _______________

Screenshots / videos (if applicable)
[Attach any relevant screenshots or videos demonstrating the changes. Make sure to attach before & after screenshots in your PR.]
https://github.com/user-attachments/assets/441a0b7d-4796-460e-b271-41a57f96fbcf
Checklist:

[x] I have made this change from my own.
[ ] I have taken help from some online resources.
[x] My code follows the style guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly in hard-to-understand areas.
[ ] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.
[x] I have tested the changes thoroughly before submitting this pull request.
[x] I have provided relevant issue numbers and screenshots after making the changes.

@PriyaGhosal please review this pr. And also assign this pr to me with the necessary labels.

@PriyaGhosal please review this pr.

@samarth-6 i have resolved the conflicts now, please review it now. And if you find it worth merging do add necessary labels.

@Palmistry2310 Please see the conflicts . Resolve the conflicts . Ensure you pull all the latest changes before pushing your feature/bug fixes to the main branch.

@PriyaGhosal conflicts are resolved.

@Palmistry2310 Your pull request has been successfully merged! Don't stop here—continue contributing by addressing more issues and aiming to become a top contributor. Exclusive swag awaits for those who go the extra mile!
Great contribution ! 🎉


Fix child CollisionPolygon being transformed twice

Fixes #141
Also includes some lines where trailing spaces have been removed automatically.

Upon further investigation of the issue, it seems like the CollisionPolygon2D was not a child of the shape node. This PR probably doesn't fix the issue, but it does fix a issue.

I don't see how this even makes sense to check for because a CollisionPolygon2D cannot be a child of a SS2D_Shape

@mphe Ah I see, yes it can be an indirect child

I tried it out and this pull request leads to the wrong behaviour for the default scene tree layout. Because the inverse transform is no longer there, the polygon is translated and rotated further than it should be.
It works ok only when the CollisionPolygon is a (indirect) child.
#143 would be better where no transforms are applied at all. However, then the collision polygon does not correspond to the smartshape if it is transformed in a different way to the CollisionPolygon. Which is what #144 was for, since 1-to-1 correspondence of the smartshape with the CollisionPolygon is expected behaviour to me.

Just tested #144. Indeed it works flawlessly regardless of the whether the CollisionPolygon is a child or not.


Issue #1225: Support nfs server configuration

Fixes #1225

Ansible lint failure point is known issue:
https://github.com/ansible/ansible-lint/issues/2217
When we use include_playbook inside a block, it is not able to find the file and triggers load-failure issue.


Modified GitHub workflows

Added Docker building and analyzing.
For this to work you NEED to add Github secrets and modify the image names so it reflects is well.
Please contact for more info.

Hi Daan, sorry for the late reply as I'm traveling lately. Just wondering for this change, if I understand correctly, it will automatically build and push to Docker Hub? If that so, what would need from my side?
Thanks again on the hard work!

Hi Donald,
This has 3 workflows:

Docker builder and push to Docker Hub
Docker analyzer which can detect any critical vulnerabilities
CodeQL code scanning

What I need for the docker heb push are GitHub secrets. You can create these here on the website. Under Repo -> Environment secrets. These must be the docker hub name and pass.
CodeQL I updated the versions because the current ones are deprecated (v1).

Hi Daan, both secrets are set. Let me know if you think is ready to merge and we can try it out.

Yes just let me know which account you want to push it to, like what is the name? Mine would be dselen. But your secrets belong to something like Dzou?

Yes, my account should be donaldzou

Hi @donaldzou , then it should be done now. Please verify if you agree. And if the DOCKER_HUB_USERNAME and DOCKER_HUB_PASSWORD are inside the repo.
You can verify inside another branch if you'd like. Create like workflow test, before merging into main.

@donaldzou merge at will, it merges into another branch

@donaldzou please look into the branch 4.1-dev-workflows (or similar) and if you agree, you can merge it into main.

It looks good, will merge now and fingers crossed lol

Everything works! thank u!
btw, how do i set an overview on the docker hub page? is there a readme.md i can add?

Everything works! thank u!
btw, how do i set an overview on the docker hub page? is there a readme.md i can add?

Perhaps the README.md in the docker folder? With some modifications. I'll look into that, but I still need to do the language I promised.