[US] Bind additional view navigation to the main tab pane to visualize the data

As a user, I want to navigate my main view between the additional view available, so that I can see the data displayed in different ways.

MoSCoW
Risk
Story Points

Must
Low
3

Acceptance Criteria
Given a table has more than a default view, clicking on other views should update the tab pane with the selected view
Risks
Pre-requisites
N/A
Tasks

[x] Refactor Additional View navigation bar to update the selected view type
[x] Show the selected view type in the tab pane (section in red box)
[x] Make selected view type be the default on first load
[x] Make the navigation properties persistent so the user doesn't have to reselect the view type  when navigating away and coming back(user experience)

Extra details:

Signing off!


Remove deprecated fields prefix and postfix for sources,conditions,target

Is your feature request related to a problem? Please describe.
Time to remove obsolete code
Describe the solution you'd like
Field prefix and postfix have been deprecated in favor of transformers on the 2021/01/03.
It's need time to do some cleanup
Describe alternatives you've considered
Additional context
Cleanup example and documentation as well

https://www.updatecli.io/docs/stages/target/#_parameters
https://www.updatecli.io/docs/stages/source/#_parameters

@dduportal the current issue is set for 0.19 but I would like to release 0.19 soon
Any objections to move this issue to release 0.20?

No objections for moving it to 0.20.

moved to 0.20.0 milestone
I'm willing to take it (like #413 )
It needs #412 to be merged

Closed by https://github.com/updatecli/updatecli/pull/591


[MLS Spec change] Add make target to extract TLS stanzas (#620)

Link to the exact changes
https://github.com/mlswg/mls-protocol/pull/620
Description of the changes

Added a short python program to extract the TLS presentation language stanzas into a single file.
Added extract-tls make target to run it.
An equivalent one liner option (only in the Makefile) is commented out.

Editorial.


refactor crosswalk local_id

Somewhat related to #15, and maybe a way to address some of the concerns raised there, should the crosswalk simply key by local_id instead of the local_id being embedded?
Currently the crosswalk is a list of objects like
[{"local_id":"cat-1","COMID":"9731278"},...]
After working with this in a couple places, I think it makes sense to factor out the common local_id and simply key by that.  Then even if we end up in a 1:many scenario, or different crosswalk definitions for waterbodies than catchments, there is still a unique mapping.  Propose changing crosswalk to something like
{
    "cat-1": {
            "COMID":"9731278",
            "site_no":"123456789",
            "other_ref":"point to something"
    },
    "cat-2": {
            "COMID":"00000000",
            "site_no":"987654321",
            "other_ref":"point to something"
    }
}

Also add "outlet comid" as "other ref".


Wired behavior when together use type and extends

code:
type T = "a" | "b" | "c" | "x"
type U = "x" | "y" | "z" | "a"

type a = T extends U ? never : T;  //type a = "a" | "b" | "c" | "x"

type b = Exclude<T, U>              // type b = "b" | "c"

question:
Exclude is defined by < T extends U ? never : T>
type a: T and U act like a whole type
type b: T ,U took in to type Exclude, the behavior was changed, T treated like using the operator "in" to spread T, U just like a whole type
Is there any document or achieve to describe this.
forgive my poor English.

I didn't understand at first and tried it myself on the playground:
type T = "a" | "b" | "c" | "x"
type U = "x" | "y" | "z" | "a"

type Ext<R> = R extends U ? never : R;
type T1 = Ext<T>; // "b" | "c"
type T2 = T extends U ? never : T; // "a" | "b" | "c" | "x"

Although T1 and T2 seem to describe the same type, they don't.

You've discovered distributive conditional types.  I agree that the difference in behavior when a type alias is inlined is weird (ideally there would have been a dedicated syntax to mark distributive conditional types), but it's intended.

So basically T1 is equal to
Ext<"a"> | Ext<"b"> | Ext<"c"> | Ext<"x">
=> ("a" extends U ? never : "a") | ... | ("x" extends U ? never : "x")
=> "b" | "c"

but T2 is equal to
("a" | "b" | "c" | "x") extends U ? never : ("a" | "b" | "c" | "x")
=> "a" | "b" | "c" | "x"

because the latter does not go through a generic type alias?
To be fair, the relevant part in the docs could be clearer regarding this distinction. In general that part its very hard to understand and could almost be written in chinese :rofl:

ideally there would have been a dedicated syntax to mark distributive conditional types

@mattmccutchen would I be reading this correctly to imply that putting a generic with union parameter inside a condition currently forces the union to distribute over the generic? Does there happen to be a plan allowing for us to opt-out of this behavior?

would I be reading this correctly to imply that putting a generic with union parameter inside a condition currently forces the union to distribute over the generic?

Yes.

Does there happen to be a plan allowing for us to opt-out of this behavior?

Wrap the type parameter and the test type in a tuple type:
type Weird<T> = [T] extends [string]
    ? WithString<T>
    : T;

I think I've seen this documented somewhere, but I can't find it now.  Anyway, it belongs in the handbook entry for conditional types.

Wrap the type parameter and the test type in a tuple type

Oh, wow... Yeah that definitely belongs in the docs!

Same weird behavior:
type Factory<T = undefined> = T extends undefined
  ? () => void
  : (value: T) => void

let withArgsSimple: Factory<{ data: string }>
let withArgsComplex: Factory<{ data: string } | { value: string }>

withArgsSimple({ data: "" }) // Ok
withArgsComplex({ data: "" }) // Error


updates for Core 18: jack daniels

Issue being fixed or feature implemented

What was done?

How Has This Been Tested?

Breaking Changes

Checklist:

[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have added or updated relevant unit/integration/functional/e2e tests
[ ] I have made corresponding changes to the documentation

For repository code-owners and collaborators only

[ ] I have assigned this pull request to a milestone

Codecov Report

Merging #166 (7764a9c) into feature-quorum-rotation (3bbf280) will decrease coverage by 0.03%.
The diff coverage is 25.00%.

@@                      Coverage Diff                      @@
##             feature-quorum-rotation     #166      +/-   ##
=============================================================
- Coverage                      45.58%   45.55%   -0.04%
+ Complexity                      5325     5318       -7
=============================================================
  Files                            369      369
  Lines                          41054    41031      -23
  Branches                        5614     5595      -19
=============================================================
- Hits                           18715    18690      -25
- Misses                         20398    20399       +1
- Partials                        1941     1942       +1

Impacted Files
Coverage Δ

...a/org/bitcoinj/params/JackDanielsDevNetParams.java
0.00% <0.00%> (ø)

...ava/org/bitcoinj/quorums/SimplifiedQuorumList.java
59.25% <100.00%> (ø)

.../src/main/java/org/bitcoinj/quorums/LLMQUtils.java
20.75% <0.00%> (-3.78%)
:arrow_down:

...src/main/java/org/bitcoinj/wallet/WalletFiles.java
83.63% <0.00%> (-1.82%)
:arrow_down:

...rc/main/java/org/bitcoinj/core/MasternodeSync.java
30.49% <0.00%> (-0.71%)
:arrow_down:

...e/src/main/java/org/bitcoinj/core/BloomFilter.java
75.34% <0.00%> (-0.69%)
:arrow_down:

...g/bitcoinj/wallet/AuthenticationKeyChainGroup.java
18.25% <0.00%> (-0.65%)
:arrow_down:

...ore/src/main/java/org/bitcoinj/core/PeerGroup.java
51.66% <0.00%> (-0.47%)
:arrow_down:

.../java/org/bitcoinj/wallet/FriendKeyChainGroup.java
39.86% <0.00%> (-0.42%)
:arrow_down:

.../main/java/org/bitcoinj/evolution/QuorumState.java
49.37% <0.00%> (-0.32%)
:arrow_down:

... and 16 more

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 3bbf280...7764a9c. Read the comment docs.


No CSI data output following successful flash (IDFGH-8995)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.
esp3.3.2-dev
Operating System used.
macOS
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
None
What is the expected behavior?
I am expecting to receive csi data after flashing the programme from https://github.com/StevenMHernandez/ESP32-CSI-Tool successfully.
What is the actual behavior?
No csi data appears after the programme has been successfully flashed following the command:
Olivers-MacBook-Pro:active_sta olivercustance$ idf.py flash monitor
The image below shows the end part of the output after running the above command. Therefore my civ file is empty also.

Steps to reproduce.

By following the https://github.com/StevenMHernandez/ESP32-CSI-Tool programme
...

Build or installation Logs.
Olivers-MacBook-Pro:active_sta olivercustance$ idf.py flash monitor
Executing action: flash
Serial port /dev/cu.usbserial-0001
Connecting..............
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting......
Detecting chip type... ESP32
Running ninja in directory /Users/olivercustance/esp32-csi-tool/active_sta/build
Executing "ninja flash"...
[1/4] Performing build step for 'bootloader'
ninja: no work to do.
[3/4] cd /Users/olivercustance/esp/esp-idf/components/esptool_py && /usr/local/Cellar/cmake/3.25.1/b...l/active_sta/build" -P /Users/olivercustance/esp/esp-idf/components/esptool_py/run_serial_tool.cmake
esptool.py esp32 -p /dev/cu.usbserial-0001 -b 460800 --before=default_reset --after=hard_reset write_flash --flash_mode dio --flash_freq 40m --flash_size 2MB 0x8000 partition_table/partition-table.bin 0x1000 bootloader/bootloader.bin 0x10000 active-sta.bin
esptool.py v3.3.2-dev
Serial port /dev/cu.usbserial-0001
Connecting....
Chip is ESP32-D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 0c:b8:15:cd:af:50
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x00001000 to 0x00007fff...
Flash will be erased from 0x00010000 to 0x000eafff...
Compressed 3072 bytes to 103...
Writing at 0x00008000... (100 %)
Wrote 3072 bytes (103 compressed) at 0x00008000 in 0.1 seconds (effective 235.8 kbit/s)...
Hash of data verified.
Compressed 26224 bytes to 16164...
Writing at 0x00001000... (100 %)
Wrote 26224 bytes (16164 compressed) at 0x00001000 in 0.8 seconds (effective 255.4 kbit/s)...
Hash of data verified.
Compressed 893040 bytes to 522364...
Writing at 0x00010000... (3 %)
Writing at 0x0001c7f0... (6 %)
Writing at 0x00025ae6... (9 %)
Writing at 0x000396c2... (12 %)
Writing at 0x0003fc37... (15 %)
Writing at 0x00045a99... (18 %)
Writing at 0x0004b203... (21 %)
Writing at 0x00050aac... (25 %)
Writing at 0x000560c8... (28 %)
Writing at 0x0005b927... (31 %)
Writing at 0x0006127b... (34 %)
Writing at 0x00066a36... (37 %)
Writing at 0x0006c0e9... (40 %)
Writing at 0x00071389... (43 %)
Writing at 0x000766aa... (46 %)
Writing at 0x0007ba53... (50 %)
Writing at 0x000810a9... (53 %)
Writing at 0x000869f1... (56 %)
Writing at 0x0008c688... (59 %)
Writing at 0x0009222f... (62 %)
Writing at 0x00097b44... (65 %)
Writing at 0x0009e30c... (68 %)
Writing at 0x000a546c... (71 %)
Writing at 0x000ad9fe... (75 %)
Writing at 0x000b4d8b... (78 %)
Writing at 0x000bb7bb... (81 %)
Writing at 0x000c2d7d... (84 %)
Writing at 0x000ca8f0... (87 %)
Writing at 0x000d31e8... (90 %)
Writing at 0x000da2df... (93 %)
Writing at 0x000dfb97... (96 %)
Writing at 0x000e52ff... (100 %)
Wrote 893040 bytes (522364 compressed) at 0x00010000 in 13.5 seconds (effective 529.3 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
Executing action: monitor
Serial port /dev/cu.usbserial-0001
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting....
Detecting chip type... ESP32
Running idf_monitor in directory /Users/olivercustance/esp32-csi-tool/active_sta
Executing "/Users/olivercustance/.espressif/python_env/idf4.3_py3.8_env/bin/python /Users/olivercustance/esp/esp-idf/tools/idf_monitor.py -p /dev/cu.usbserial-0001 -b 1552000 --toolchain-prefix xtensa-esp32-elf- /Users/olivercustance/esp32-csi-tool/active_sta/build/active-sta.elf -m '/Users/olivercustance/.espressif/python_env/idf4.3_py3.8_env/bin/python' '/Users/olivercustance/esp/esp-idf/tools/idf.py'"...
/Users/olivercustance/esp/esp-idf/tools/idf_monitor.py:518: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead.
  if StrictVersion(serial.VERSION) < StrictVersion('3.3.0'):
--- idf_monitor on /dev/cu.usbserial-0001 1552000 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---

More Information.
No response

Thanks for reporting, would you please raise an issue in issue tracker https://github.com/StevenMHernandez/ESP32-CSI-Tool ? Thanks.

I have done thanks.

Thanks for reporting, feel free to reopen.


Fix recorder purge

Description:
Fix wrong syntax from: https://github.com/home-assistant/home-assistant/pull/10279

I'm also seeing a weird issue on line 280;
hass_1  | 2017-11-03 16:29:56 ERROR (MainThread) [homeassistant.components.recorder.util] Error executing quer
y: Not naive datetime (tzinfo is already set)
hass_1  | 2017-11-03 16:29:56 ERROR (MainThread) [homeassistant.core] Error doing job: Exception in callback $
function Recorder.run.<locals>.register at 0x7f570847c840>
hass_1  | Traceback (most recent call last):
hass_1  |   File "uvloop/cbhandles.pyx", line 47, in uvloop.loop.Handle._run (uvloop/loop.c:48400)
hass_1  |   File "/usr/lib/python3.6/site-packages/homeassistant/components/recorder/__init__.py", line 280, i
n register
hass_1  |     run = dt_util.UTC.localize(event.time_fired) + \
hass_1  |   File "/usr/lib/python3.6/site-packages/pytz/__init__.py", line 237, in localize
hass_1  |     raise ValueError('Not naive datetime (tzinfo is already set)')
hass_1  | ValueError: Not naive datetime (tzinfo is already set)

@pvizeli , sorry to have caused inconvenience and thanks for catching this. PR #10279 passed both local tests and tox that exercised these lines so keen to understand what went wrong here. I thought lines 363-364 were sufficient to provide a valid function reference for use later in the code:
363:                 async_track_point_in_time = \
364:                     self.hass.helpers.event.async_track_point_in_time

Appreciate any feedback you can spare on this.

@PeteBa correct
@lwis I address you comment with last commit

@pvizeli 👍

@lwis, for my benefit, can I ask what database you are using with recorder. Is it sqlite or something different ?

@peteba postgres

@lwis, thanks
OK, so lesson learned is some db return timezone aware timestamps whereas others are naive (that and testing on sqlite alone is not enough !) For future reference, there is a method in recorder/model.py that provides some db normalisation i.e. event.to_native().time_fired would work too.


First use of HOOBS and neato plugin

Good morning, I am totally new in the use of HOOBS. I have got it started this morning and loaded & installed the Neato plugin. That worked, a screen popped up and asked me for the email address and the password, filled in the screen and saved the changes. I can see my userid and password in the HOOBS plugin config and when I logon to the Neato web site with these credentials I can get in without issues. However in the log I see the messages as displayed in the attached file. Any idea ?

Got it working now, but sure why, because config looks the same 😥


Japanese localization please

I know this document is pretty new but I would like to request Japanese Localized document for this.

ドキュメントの詳細
⚠ このセクションを編集しないでください。 docs.microsoft.com で必須です ➟ GitHub の問題のリンク。

ID: d18912e1-fcca-5ea6-869c-10548a5bde04
Version Independent ID: f06260f5-3204-57a7-0ceb-ddb12cabd81d
Content: About Azure Migrate
Content Source: articles/migrate/migrate-services-overview.md
Service: azure-migrate
GitHub Login: @rayne-wiselman
Microsoft Alias: raynew

@KeiroKamioka0000 Thanks for the comment. We are actively investigating and will get back to you shortly with an update.

Assigning @rayne-wiselman for visibility and document enhancement / request considerations.

Hi,
Thanks for your feedback. articles are picked up automatically for localization on a periodic basis.
No action for article #please-close


Support for iOS

I didn't find any info on iOS support.
Since this is a C++ library, my first, most probably wrong expectation, would be that it does not present a big hurdle to port it to iOS.
Is iOS support planned?

FlatUI currently does all its rendering through its FPLBase, which we just got working on iOS: http://google.github.io/fplbase/fplbase_guide_ios.html
Doing the same with FlatUI would just mean creating project files for it with CMake, similar to that page.

I didn't find any info on iOS support. Since this is a C++ library, my first, most probably wrong expectation, would be that it does not present a big hurdle to port it to iOS. Is iOS support planned?

iOS has it's own coding base and I'm sure it's own much more native GUI library supported by Apple


Revert "Roll Flutter Engine from 9692f09afd67 to cbb96d0b06d7 (2 revisions)"

Reverts flutter/flutter#112883
Reverting for the failures in https://ci.chromium.org/ui/p/flutter/builders/prod/Windows platform_channel_sample_test_windows/1804/overview

@keyonghan for revert tag failure

@keyonghan for revert tag failure

@ricardoamador Have we added retry for graphqlErrors error?

Odd. Let me take a look.

Ah I suspect that this is because both the warning label and revert label were added.

Ah okay so there is no conflict between labels but I am looking into why that check was considered required when the revert label was present. The bot did merge the pull request after Zach readded the label.


feat: sync matched items even if unassigned

Fixes #70
Checklist

[x] Assign labels to PR.
[x] Ensure PR title matches the conventional commits format.

CodiumAI Agent Commands
As required run the following CodiumAI Agent commands:

Request PR update using @CodiumAI-Agent /describe
Request PR review using @CodiumAI-Agent /review (and if required update with @CodiumAI-Agent /review -i)
Request PR improvement suggestions with @CodiumAI-Agent /improve --extended

@CodiumAI-Agent /describe

Title
Enhance Task Synchronization and Add Related Tests

PR Type:
Enhancement, Tests

PR Description:
This PR enhances the task synchronization process in the sync_project function of the sync.py file. The changes allow tasks to be synced even if they are unassigned or if the assignee does not match an Asana user, as long as the tasks have previously been matched. The PR also includes a new test case for the matching_user function when the ado_user is None.

PR Main Files Walkthrough:
ado_asana_sync/sync/sync.py: The changes in this file mainly focus on the sync_project function. The function now checks if a task has previously been matched before deciding to skip it. If a task is unassigned or the assignee does not match an Asana user, the function will still sync the task if it has been previously matched. The matching_user function has also been updated to return None when the ado_user is None.
tests/sync/test_sync.py: A new test case has been added to the TestMatchingUser class. This test case, test_matching_user_ado_user_none, checks that the matching_user function returns None when the ado_user is None.

@CodiumAI-Agent /review

PR Analysis

🎯 Main theme: The main theme of this PR is to enhance the synchronization of tasks between Azure DevOps and Asana. It modifies the existing logic to also sync tasks that are not assigned or whose assignee does not match an Asana user, as long as they have been matched previously.
📝 PR summary: This PR introduces changes to the synchronization logic between Azure DevOps and Asana. It allows tasks that are not assigned or whose assignee does not match an Asana user to be synced, provided they have been matched previously. It also includes a new test case for the scenario where the Azure DevOps user is None.
📌 Type of PR: Enhancement
🧪 Relevant tests added: Yes
🔒 Security concerns: No security concerns found

PR Feedback

💡 General suggestions: The PR looks well-structured and the changes are well-documented. The logic seems to be sound and the code is clean. It's good to see that a new test case has been added to cover the new logic. However, there are a few areas where the code could be improved for better readability and efficiency.

 🤖 Code feedback:

relevant file: ado_asana_sync/sync/sync.py
suggestion: It seems like the existing_match object is being updated multiple times throughout the code. It might be more efficient to collect all the necessary updates first and then update the object once. This could potentially reduce the number of writes to the database and improve performance. [medium]
relevant line: existing_match.ado_rev = ado_task.rev

relevant file: ado_asana_sync/sync/sync.py
suggestion: The matching_user function now has a new condition to return None if ado_user is None. This is a good addition, but it would be helpful to add a comment explaining why this condition is necessary, for the sake of future maintainers. [medium]
relevant line: if ado_user is None:

relevant file: ado_asana_sync/sync/sync.py
suggestion: The getattr function is used to get the gid attribute of asana_matched_user. This is a good use of getattr, but it might be more readable to use a default value of None instead of not providing a default at all. This would make it clear that None is expected if the attribute does not exist. [medium]
relevant line: assigned_to=getattr(asana_matched_user, "gid", None),

How to use

Tag me in a comment '@CodiumAI-Agent' and add one of the following commands:
/review [-i]: Request a review of your Pull Request. For an incremental review, which only considers changes since the last review, include the '-i' option.
/describe: Modify the PR title and description based on the contents of the PR.
/improve [--extended]: Suggest improvements to the code in the PR. Extended mode employs several calls, and provides a more thorough feedback.
/ask <QUESTION>: Pose a question about the PR.
/update_changelog: Update the changelog based on the PR's contents.

To edit any configuration parameter from configuration.toml, add --config_path=new_value
For example: /review --pr_reviewer.extra_instructions="focus on the file: ..."
To list the possible configuration parameters, use the /config command.

@CodiumAI-Agent /improve --extended

How to use PR-Agent

Tag me in a comment '@CodiumAI-Agent' and add one of the following commands:
/review [-i]: Request a review of your Pull Request. For an incremental review, which only considers changes since the last review, include the '-i' option.
/describe: Modify the PR title and description based on the contents of the PR.
/improve [--extended]: Suggest improvements to the code in the PR. Extended mode employs several calls, and provides a more thorough feedback.
/ask <QUESTION>: Pose a question about the PR.
/update_changelog: Update the changelog based on the PR's contents.

To edit any configuration parameter from configuration.toml, add --config_path=new_value
For example: /review --pr_reviewer.extra_instructions="focus on the file: ..."
To list the possible configuration parameters, use the /config command.


java.lang.NoSuchMethodError: No virtual method isAssignableFrom()

Summary:
After doing the latest OneBusAway release build and updating from v2.4.4 to v2.5, I'm seeing a crash after updating the app, which seems to trigger a registration for Embedded Social push notifications (if you're logged in with an Embedded Social account).
Here's the stack trace:
2019-04-15 17:45:28.850 30037-30418/? E/AndroidRuntime: FATAL EXCEPTION: intent processor #2
    Process: com.joulespersecond.seattlebusbot, PID: 30037
    java.lang.NoSuchMethodError: No virtual method isAssignableFrom(Ljava/lang/reflect/Type;)Z in class Lcom/google/common/reflect/TypeToken; or its super classes (declaration of 'com.google.common.reflect.TypeToken' appears in base.apk)
        at com.microsoft.rest.Validator.validate(Validator.java:49)
        at com.microsoft.embeddedsocial.autorest.MyPushRegistrationsOperationsImpl.putPushRegistration(MyPushRegistrationsOperationsImpl.java:112)
        at com.microsoft.embeddedsocial.server.model.notification.RegisterPushNotificationRequest.send(RegisterPushNotificationRequest.java:38)
        at com.microsoft.embeddedsocial.data.storage.NotificationServiceCachingWrapper.registerPushNotification(NotificationServiceCachingWrapper.java:66)
        at com.microsoft.embeddedsocial.fcm.TokenSyncAdapter.synchronize(TokenSyncAdapter.java:44)
        at com.microsoft.embeddedsocial.server.sync.DataSynchronizer.synchronizeEntity(DataSynchronizer.java:94)
        at com.microsoft.embeddedsocial.server.sync.DataSynchronizer.synchronizeProducer(DataSynchronizer.java:70)
        at com.microsoft.embeddedsocial.server.sync.DataSynchronizer.synchronize(DataSynchronizer.java:42)
        at com.microsoft.embeddedsocial.service.handler.SynchronizationHandler.handleIntent(SynchronizationHandler.java:58)
        at com.microsoft.embeddedsocial.service.handler.SynchronizationHandler.handleIntent(SynchronizationHandler.java:24)
        at com.microsoft.embeddedsocial.base.service.IntentProcessor$IntentHandlerAdapter.run(IntentProcessor.java:234)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
        at java.lang.Thread.run(Thread.java:764)

When doing the release and trying to obfuscate via Proguard, I was getting the following warning that was blocking the build:
"Warning: com.microsoft.rest.Validator: can't find referenced method 'boolean isAssignableFrom(java.lang.reflect.Type)' in program class com.google.common.reflect.TypeToken"

So, in this commit I added the following to our Proguard rules:
-dontwarn com.microsoft.rest.Validator

This lets me build the project, but then results in the above runtime exception.
After talking with @acrown-msft it looks like the ES SDK uses a ES Java API library (https://github.com/Microsoft/EmbeddedSocial-Java-API-Library), which uses an older version of a REST library (https://github.com/Azure/autorest-clientruntime-for-java), which is using an older version of Guava (18).  OBA Android is stripping out this older version of Guava in favor of v26, which is being used by Firebase and other OBA dependencies.  As a result, we get a runtime error because this method doesn't existing in v26 of the Guava library.
@acrown-msft is going to look at updating the ES Java API library dependency to use a newer version of the REST library, which is using a newer version of Guava.
Here's the
Steps to reproduce:

Install OBA v2.4.4 - https://github.com/OneBusAway/onebusaway-android/releases/tag/v2.4.4
Log into EmbeddedSocial
Install OBA v2.5.0 - https://github.com/OneBusAway/onebusaway-android/releases/tag/v2.5.0
Start up app

Expected behavior:
Not crash
Observed behavior:
It crashes
Device, Android, and Embedded Social SDK version:
What version of the Embedded Social SDK did you use?
    // Embedded Social SDK
    implementation('com.acrowntest.test:sdk:0.7.4@aar') {
        transitive = true
    }

Samsung Galaxy S8+ w/ Android 9.0

OBA Android issue - https://github.com/OneBusAway/onebusaway-android/issues/976


chore: NebulaGraph prompt optmization

Was preparing for a demo project of NebulaGraphQAChain to find out the prompt needed to be optimized a little bit.
Please @hwchase17 kindly help review.
Thanks!

Thanks @hwchase17 for the blazing fast merge!


ModuleNotFoundError: No module named 'airflow.models.BaseOperator'

I am running in aws-mwaa-local-runner
I wrote custom operator as below,not sure why it says no module found
import os
import sys
import csv
import tempfile
import logging
from contextlib import closing
from io import BytesIO, TextIOWrapper, BufferedRandom
from airflow.models.baseoperator import BaseOperator
from airflow.hooks.S3_hook import S3Hook
from airflow.contrib.hooks.snowflake_hook import SnowflakeHook
from utils.files import is_gz_compressed, compress_gz

logger = logging.getLogger(__name__)

class BaseUploadToS3(BaseOperator):
    """Extract data and compress to gzip format and upload to S3 location with s3_key
        Parameters
       ***************

But got below error

Broken DAG: [/usr/local/airflow/dags/a_dag.py] Traceback (most recent call last):
  File "/usr/local/airflow/dags/a_dag.py", line 8, in <module>
    from custom_operators.mssql_to_s3_operator import MsSqlToS3Operator
  File "/usr/local/airflow/dags/custom_operators/mssql_to_s3_operator.py", line 3, in <module>
    from airflow.models.BaseOperator import BaseOperator
ModuleNotFoundError: No module named 'airflow.models.BaseOperator'

When I checked inside the docker with python3
[airflow@6902213e0fbe ~]$ clear
[airflow@6902213e0fbe ~]$ python3
Python 3.7.10 (default, Jun  3 2021, 00:02:01)
[GCC 7.3.1 20180712 (Red Hat 7.3.1-13)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from airflow.models.BaseOperator import BaseOperator
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'airflow.models.BaseOperator'
>>>

@KarthikRajashekaran What was the solution?


proto: remove concept of head from execution api

Summary
Updated the execution service to no longer include the concept of head, with corresponding documentation updates.
Background
Latest blocks are already final, and we don't receive proposed blocks.
Changes

Removed head from CommitmentState
Renamed CreateBlock to ExecuteBlock
Update spec documentation
Updated sequence diagram

Testing
Tested via CI tests, am expecting a breaking protobuf failure.
Breaking Changelist

This is a full proto breaking change, but on an unimplemented API.

Merging to make spec more correct, since shared externally.
Feel free to leave more comments on verbiage and such will gladly make a follow up.


net/http: logical race in (*net/http.Transport).CancelRequest

With go version go1.4.1 linux/amd64, there's a logical race in (*net/http.Transport).CancelRequest between the readLoop goroutine at https://github.com/golang/go/blob/release-branch.go1.4/src/net/http/transport.go#L935 and the goroutine that calls Close on the response Body at https://github.com/golang/go/blob/release-branch.go1.4/src/net/http/transport.go#L908 .
The closure on line 908 can cause the net.Conn to be handed off to the connection pool before the canceler is cleared on line 935. A call to CancelRequest at this time will then close the connection, even though it's been returned to the pool. The next request to pull that net.Conn out of the pool will fail.
Contexts make this condition easy to trigger: if a monitor goroutine waits on ctx.Done before calling CancelRequest, it's easy to come up with code that would cause the Context to be canceled upon successful completion of the request (e.g. to clean up after context.WithTimeout).

Confirmed with this program https://play.golang.org/p/M1-NTl3odt

This is a dup of #9496 but both have good information.
In any case, https://go-review.googlesource.com/8550 fixes it.


bill_daily_update.py failing on OpenStates data

Daily run of bill_daily_update.py returns:
Finished fetching page 1 of 106 of bill updates
Failed to update records 'current_role'
Database connection closed
Update finished
Last update timestamp: 2024-07-02T12:33:26.931622+00:00
Fetching bill updates
Finished fetching page 1 of 106 of bill updates
Failed to update records 'current_role'
Database connection closed
Update finished

So, the database is "frozen" in time since before July 2nd. The OpenStates API requests appear to go through successfully, but the results are not getting parsed.

Issue has been discovered! Within an OpenStates API response, we might see sponsor JSON keys with different internal structures:
{'name': 'Seyarto',
'entity_type': 'person',
'person':
	{'id': 'ocd-person/d9462f08-2b27-4969-8436-9a1c21534a40',
	'name': 'Kelly Seyarto',
	'party': 'Republican',
	'current_role':
		{
			'title':
			'Senator',
			'org_classification': 'upper',
			'district': '32',
			'division_id': 'ocd-division/country:us/state:ca/sldu:32'
			}
		},
	'primary': True,
	'classification': 'author'
	}
****************************************************************************************************
{'name': 'Dahle',
'entity_type': 'person',
'primary': False,
'classification': 'coauthor'}

The original if clause on line 70 of bill_openstates_fetch.py did not properly handle cases like the second sponsor object example shown above.

After pushing the bug fix and deploying it to the server, I'll have to monitor the server for the next few hours while the batch updates are processed. This will be standard practice if/when database updates are interrupted in the future.

Re-running these changes on ca_dev did not update the schema as expected - it reveals that any breakage in snapshot updates blocks updates to the front-end tables.


Allow custom form for batch actions

Hi @jowilf,
I would like to create a PR to try to resolve this issue https://github.com/jowilf/starlette-admin/issues/21#issuecomment-1354299135
I'm not master on frontend, but I try to make this works for my application. The idea is each action will have own form html to custom the input for each action.
Could you have a look? Please feel free to reject if you have any better plan or solution.
Thanks

Thanks for your review. I will improve when I get time.
Feel free to push to PR if you get time too, because you are best.

Thank you all for your contributions


Dan

I don't know if my new node (visualization) is good from a validation standpoint, but it would be good to show Philip to get his gears turning.

ok, looks like if failed.

I can work with you to show you how to get it to pass, if you like. Invite me to a meeting, if you want.
Bill
Sent from my iPhone

On May 20, 2020, at 5:34 PM, dhuston<EMAIL_ADDRESS>wrote:

ok, looks like if failed.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


👷♀ FIX: @type should always exist

resources always have a type, the class should reflect that

I'm wrong, it turns out @type is optional!


unhandled promise rejection in async tests

I can't seem to get this to work.  If a routine under test uses promises at some point and catches any errors returning the result to the callback function, it's not possible to throw assertion exceptions in the test code without resulting in an unhandled promise rejection and the test timing out
Consider the following:

const assert = require('assert');

function test (cb) {
    new Promise((resolve, reject) => reject(new Error('aw snap!')))
        .then(result => cb(null, result))
        .catch(err => cb(err));
}

describe('test', () => {
    it('should function properly', done => {
        test(err => {
            assert.equal(err.message, 'oops!');
            done();
        });
    });
});

Results in:
$ mocha

  test
(node:15999) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 2): AssertionError: 'aw snap!' == 'oops!'
^CTerminated

I don't understand why the assert.equal throw isn't handled - the only promise in play here is in the test function and it is handled and returns the error to the first parameter of cb properly.  I would call catch on the promise in the test code, but as far as I can tell there is no promise to attach a catch to!
To get this to work, I need to wrap assertion code in a try/catch and call done with the error if one is encountered.... which is not ideal.
    it('should function properly', done => {
        test(err => {
            try {
                assert.equal(err.message, 'oops!');
            } catch (e) {
              return done(e);
            }
            done();
        });
    });

Or, attach a event handler for unhandledRejection on process which, again, is not ideal
process.on('unhandledRejection', e => { throw e; });

Is there a reason mocha doesn't do this itself, i.e.:
diff --git a/lib/runner.js b/lib/runner.js
index b024e0d..21c56f9 100644
--- a/lib/runner.js
+++ b/lib/runner.js
@@ -827,6 +827,7 @@ Runner.prototype.run = function (fn) {

   // uncaught exception
   process.on('uncaughtException', uncaught);
+  process.on('unhandledRejection', uncaught);

   if (this._delay) {
     // for reporters, I guess.

With that modified directly in the node_modules directory everything works as expected.

We have #2640 for the unhandled rejection detection, for what it's worth. (Closing this as a duplicate of that as far as resolution on Mocha's end, but feel free to discuss your particular case here further as needed.)
However, the caveat I mentioned there applies here: the function named test in your example will swallow any errors thrown in the error-handling path by the callback passed to handle errors from the function itself, which is potentially problematic in real uses and not just in tests. Possible fixes include not using promises internally in such functions, or (if you can change their API) making them return the promise, or (if you are ok with swallowing errors in the callback as long as you know not to let it happen) documenting that the callback's error-handling path MUST NOT throw and adding try-catch to the test as shown here. (There may be other solutions, but I'm not sure if there are any other good ones.)

To address this specific case in more detail:

I don't understand why the assert.equal throw isn't handled - the only promise in play here is in the test function and it is handled and returns the error to the first parameter of cb properly.

The reject(...) error is being handled by being passed to the cb. The cb is the little function passed to test in your test (it), which is what's throwing the assertion. So you're throwing out of the catch handler and not handling that. It's equivalent to if you inlined the code thus:
const assert = require('assert');

describe('test', () => {
    it('should function properly', done => {
        new Promise((resolve, reject) => reject(new Error('aw snap!')))
            //.then will never be called from the rejected promise
            .catch(err => { // this handles the `new Error` rejection above
                assert.equal(err.message, 'oops!'); // this may throw
                done();
            }); // this promise may now be rejected with an assertion error thrown out of the catch block
        // because promise is neither returned nor used further, if it ended up rejected then that's unhandled
    });
});

I would call catch on the promise in the test code, but as far as I can tell there is no promise to attach a catch to!

Well, there is, it's just never leaving the function in which it's created... which at least partly defeats the purpose of using promises instead of callbacks: they're intended to give us back the ability to handle errors in the caller's scope (among other design patterns from synchronous programming).

A couple unrelated promise programming tips:

new Promise((resolve, reject) => reject(<error>)) can be simplified to Promise.reject(<error>) and new Promise((resolve, reject) => resolve(<value>)) can be simplified to Promise.resolve(<value>)
.catch(error => <function>(error)) can be simplified to .catch(<function>)

Thank you for the very detailed explanation!  It completely makes sense that calling cb in catch block is still technically in the promise and any exceptions thrown there go unhandled.
This came up refactoring an existing callback-based service to integrate with some new promise-based code. I think for now I'll keep the unhandledRejection handler there in the test code and make absolutely sure the code path after cb can't throw.
I suppose it would make sense to rework the entire code path to use promises...  no half measures, Walt

Hello,
Could you please let me know how can I implement cases when is expected that promise should be rejected and contain 'my_message' message?

function(args).catch((err) => {
expect(err.message).to.equal('expected');
})
it's not what I want, as I also need to require that the promise should be rejected.

@martin-ayvazyan13, please open a new issue...


Snapshoting mulitple elements returns empty objects

Describe the bug
If you use toMatchSnapshot(); after a cy.get() that returned multiple elements, the final snapshot will look something like this: [{}, {}, {}]
To Reproduce
Steps to reproduce the behavior:

cy.get('div').toMatchSnapshot(); when there are mutiple divs in the current context.

Expected behavior
An array of stringified dom elements.
Desktop (please complete the following information):

OS: Windows
Cypress Version 3.6.1

This is the same issue as #67, there's an open pull request (#79) with a fix for this.

Gud


Indicate .NET, packed or other binaries FLOSS doesn't handle well

Warn users similar to capa. Arose in issue #346

could use capa for this


FrozenFuture no longer resolve

The Future::Output type of FrozenFuture is now Never rather than (), which means the FrozenFuture never resolves anymore (it is always Pending).
This spares the user the need to implicilty prevent the scope from returning with a loop, as the call to freeze now suffices.
This is a breaking change. See changelog for details.

superseded by freeze_forever


Error in calculation of fan speed

The calculation of the fan speed (RPM) in get_fan_status() is overly complex and wrong. It ignores leading zeroes in the hex values, leading to incorrect speeds being calculated.
My solution:
Replace the two lines of code
        IntakeFanRPM = int(1875000 / int(''.join([str(int(data[9], 16)), str(int(data[10], 16))])))
        ExhaustFanRPM = int(1875000 / int(''.join([str(int(data[11], 16)), str(int(data[12], 16))])))

by the following two lines:
        IntakeFanRPM = int(1875000 / (int(data[9], 16) * 256 + int(data[10], 16)))
        ExhaustFanRPM = int(1875000 / (int(data[11], 16) * 256 + int(data[12], 16)))

Fixed in commit https://github.com/Mosibi/whr_930/commit/c4cc7b0242b6ae547d30f34d1944cd41402d09b0


Benchmark scenario with high volume

Description
In my experience, the numbers used in the calculation show a low to medium utilization scenario.
This is probably the scenario that most (~80%) Keycloak users will encounter.
However, 10-20% of the Keycloak projects I have seen have a high to very high utilization scenario, e.g. 1,000,000 - 10,000,000 concurrent user sessions (with at least one client).
Discussion
https://github.com/keycloak/keycloak/pull/24913#discussion_r1402329545
Motivation
Enable admins to configure Keycloak properly in high volume scenarios.
Details
No response

I'm marking this issue "help wanted" as the team is focusing on multi-site deployments at the moment.
If someone wants to run those tests with a higher number of sessions, there is https://www.keycloak.org/keycloak-benchmark/benchmark-guide/latest/report/rosa-benchmark-key-results as a guide, and we're happy to support that person.


[Feature Request] improved timestamp shortcuts

Currently (just upgraded to 0.2.2) time parameters can only be set as epoch-time-milliseconds. The AWS cli supports ISO 8601 timestamps, as well as epoch time.
Could using "2021-03-11T19:00:00Z" be added?
Also, it would be really clever if there was also a shortcut following the pattern of "now()" or "now(-1d)" or "now(-1h)" when specifying times for fetching logs and such.

Oh. I'm on aws-cli/1.16.51 -- maybe that's a CLI v2 feature?

Oops! RTFM: Available in the AWS CLI version 2 only
But maybe the notion of translating "now()" is still a valid feature request? Otherwise, feel free to close.
Thanks!


Unauthorized characters in file names on windows

Command:
screenshoteer  --url https://vk.se
OS:
Windows 10
output:
https://vk.se true (node:32328) UnhandledPromiseRejectionWarning: Error: ENOENT: no such file or directory, open 'C:\Users\marcu\Desktop\Västerbottens-Kuriren | Västerbottens nyhetsportal undefined<PHONE_NUMBER>443.png'   -- ASYNC --     at Page.<anonymous> (C:\Users\marcu\AppData\Roaming\npm\node_modules\screenshoteer\node_modules\puppeteer\lib\helper.js:144:27)     at C:\Users\marcu\AppData\Roaming\npm\node_modules\screenshoteer\index.js:45:16     at <anonymous>     at process._tickCallback (internal/process/next_tick.js:188:7) (node:32328) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1) (node:32328) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
this character "|" you can not have in a file / folder name on windows

+1 on this. Seeing the exact same thing.
Looks like an image is written using the  tag. As such, sites like msn.com and disney.com, which use the pipe (!) character in their titles, run afoul of Windows file naming rules.
I imagine simple "Windows filename-safe" regex can alleviate this.
Great tool, thanks!

I just updated 1.0.3 version with  filename-safe regex.


fix: deprecation warning in the comment command

Description
Fix the deprecation warning of using the showChanges API from @gitbeaker/rest.
Current Behavior
$ pnpm changesets-gitlab comment
DeprecationWarning: This endpoint was deprecated in Gitlab API 15.7 and will be removed in API v5. Please use the "allDiffs" function instead.
(Use `node --trace-deprecation ...` to show where the warning was created)

Expected Behavior
No warning was emitted.
Additional Information
I changed the type of the argument in the hasChangesetBeenAdded function from the inferred type
ReturnType<MergeRequests['allDiffs']>

to the concrete type
Promise<MergeRequestDiffSchema[]>

because I think checking something we don't really use (paginated or not) does not make a lot of sense.

You're on fire! Thanks very much.


Some work on Filters

Currently only "works" on ItemFilters. NBT writing seems to work but reading does not.

Also, please don't use GUIs textures with optionally painted slot backgrounds. It doesn't play nice with ghost slots.


Move the build log to where the images are

The logs should live in the same directory as the images that have been built.
Moved from: https://github.com/ManageIQ/manageiq/issues/421

Since building images are split to multiple machines now and not all build machines have access to the same fileshare, we'll have to upload logs to somewhere to implement this change.  I think only a few of us look at the logs and those are the people who have access to the logs already, so probably not worth the effort.  Closing.


[r] Discussion: R one-based indexing vs. soma_joinid

This ticket is for capturing discussions & decisions!

In the R ecosystem all vector and array indexing is one-based, which users/devs are highly accustomed to.
The SOMA abstract specification defines both dense & sparse arrays to have zero-based offset indexing. Although we need to reinterpret that slightly for R, that's not inherently problematic because it's entirely natural to treat R array offsets/positions as one-based instead.
Bigger papercuts arise from soma_joinid, which we define as follows:

Every SOMADataFrame must contain a column called soma_joinid, of type int64 and domain [0, 2^63-1]. The soma_joinid column contains a unique value for each row in the SOMADataFrame, and intended to act as a joint key for other objects, such as SOMASparseNDArray.

Note that soma_joinid can take the value 0, but needn't -- in principle they can be any unique numbers throughout the specified domain (although in current practice they do usually equal zero-based row numbers in the obs/var dataframes).
This will cause friction any time we have an NDArray dimension indexed by a soma_joinid, including all X matrices and the Census' feature-dataset presence matrix. Because soma_joinid can take the value zero, it seems we need to add one to it in order to populate a one-based dimension of an R sparseMatrix:
https://github.com/single-cell-data/TileDB-SOMA/blob/4e009065cdd94bb2803eac6e441e5613f268ee0a/apis/r/R/SOMASparseNDArray.R#L174-L175
Yet this is in some sense inappropriate, because soma_joinid is defined as an actual ID, not an offset/row number.
Here's an example R vignette / upstream Python notebook; where, because the R sparseMatrix dimensions are effectively soma_joinid+1, to access it by soma_joinid found from other dataframes, we need to explicitly add one to those IDs.

A few strawperson ideas for discussion:

Implicitly add one to soma_joinid everywhere, including dataframes as well as sparseMatrix dimensions.

Reservations about implicitly changing an ID, not an offset/row number.
Will there be various corner cases where we might miss the implicit adjustment?
Should we then admit that soma_joinid is just the row number in the obs/var dataframe? (see final note below)

Amend SOMA spec to exclude zero from the domain of soma_joinid.

Is a breaking spec change after we declared v1.0, that would also trigger code changes to Census builder at minimum.
Would probably also reveal corners where we've conflated soma_joinid with row number in the var/obs dataframe. (This could be a pro or con depending on how you look at it!)

Don't change code or spec; just rely on thorough documentation with prominent warnings & explanation.

Final note: this is also related to discussion/debate on the utility of SOMADenseNDArray. If we really want to support dense arrays (which the spec generally uses soma_joinid for the dimensions) then it seems we'd need to tighten the definition of soma_joinid to at least roughly correspond to obs/var dataframe row numbers. Otherwise I can say I have one (1) cell with soma_joinid = 2^63-1, and that's valid yet effectively unrepresentable with dense arrays.

Expectations for this issue:

There is, of course, no magical, one-please-all solution
Let's get a write-up of the various choices available and the plusses & minuses for each
Schedule a team meeting
Get buy-in from the team
Formulate a plan

Attempting to distill the key dilemma:

Hopefully not too controversial: array & matrix offsets should be zero-based in Python API and one-based in R API.
Important distinction: soma_joinid is not an offset, as the SOMA spec currently defines the base concept; it's just an id for each observable/variable (needs not start at zero/one, nor form a contiguous range).

Corollary: it's not really appropriate for our R stuff to implicitly add one to soma_joinid, since it's an id, not an offset.

However, SOMA also uses soma_joinid as the axis indices/offsets for X matrices (and the Census feature/dataset presence matrix)
Therefore, for populating the R sparseMatrix with one-based dimensions, the rock = soma_joinid may be zero; hard place = it seems wrong to "arbitrarily" add one to it.

soma_joinid is not an offset, as the SOMA spec currently defines the base concep

This is true for sparse arrays; not true for dense ones
If we go 1-up everywhere that's fine -- data generated before that will be readable by Python, and data generated after that will be readable by Python and R ...
... all would be well as long as we forever abandon any hope of any return to dense matrices, ever.

I fully agree that soma_joinid is not an offset, it's just an identifier (key).
Throwing out an idea for discussion:

The obs and var dataframes should maintain both a soma_joinid and offset.
The offset is the (TileDB) Dim and the soma_joinid becomes a (TileDB) Attr of obs and var DataFrames, rather than it's Dim. Since this would be newly introduced, we could have it be 1-based. Schema changes might look like this:

In obs and var: Dim(name='soma_offset', domain=(1, N)), Attr(name='soma_joinid', domain=(0,N-1))
In dense arrays: Dim(name='soma_offset_dim_{0,1}', domain=(1, N))
In sparse arrays: Dim(name="soma_joinid_dim_{0,1}', domain=(0, N-1))

The soma_joinid is used for accessing sparse arrays.
The soma_offset is used for accessing dense arrays.

E.g., If an obs query is performed to find a set of rows, and the returned rows are used to access a sparse X, the obs.soma_joinid values are used to retrieve data from X.  If a dense obsm (embedding)  is accessed, the obs.soma_offset values are used to retrieve data from obsm.
My rambling thoughts that led up to the above proposal:
Querying obs or var for a contiguous slice of rows [N:M] is biologically meaningless. Similarly, one never (meaningfully) needs to retrieve a contiguous slice along an X axis.  Retrieving a contiguous range of obs, var or dense array is only useful if you're grabbing an arbitrary set of rows for testing or inspection. So I don't really understand the cases where an R or Python user needs to think about the "meaning" of an offset or soma_joinid value, or explicitly specifying a 0 or 1 value in a query. If one is intent on querying a DataFrame or Matrix (either dense or sparse!) for an arbitrary range, you do so using the offsets. And if these offsets happen to be 0-based, then yes, R users need to consider this when making these arbitrary range queries. If an R user is querying obs to get offsets for a dense array, and the dense array is 0-based, then the R user needs to do the 1-biasing on all the offset values. But as proposed above, we can just go with 1-based Dims for dense arrays and make R users happy. Querying sparse arrays should be straightforward, since soma_joinid values can just be blindly passed through from an obs query result to a sparse matrix query; I don't see that an R user would be "handling" these values in a way where they cared whether a 0 value existed in the set of soma_joinids; a 0 value would only be "seen" if you're debugging your code and inspect the id values.

@atolopko-czi Thanks, I think you're right that the idea of range-slicing on either soma_joinid or offset is ill-conceived.
I need to push back on one point though,

I don't see that an R user would be "handling" these values in a way where they cared whether a 0 value existed in the set of soma_joinids; a 0 value would only be "seen" if you're debugging your code and inspect the id values.

We have the specific challenge that the R sparseMatrix axes begin at 1, so we simply cannot instantiate it with a soma_joinid == 0 unless we somehow change the ids. It's annoying that this "technicality" is spec-breaking for the (primary) sparse case, but I think, unfortunately, that is the case =(

@atolopko-czi I like your idea.
A priori I do not like having two columns which (in practice) will differ only by one. However, other options are also fraught. As compromises go, your soma_offset/soma_joinid approach puts the burden of +1/-1 solely and squarely at creation time and from everywhere downstream no other software needs to remember (or risk forgetting) any shift-by-one logic.
My only ask is that for obs and var we keep soma_joinid as the dim and make soma_offset an attr, rather than the other way around -- as at present most of our arrays are sparse, and the soma_offset (which is destined for dense arrays) should be a bit off to the side, and the soma_joinid (which is for sparse arrays) should be more front-and-center.

@atolopko-czi my reasoning:

Perhaps I should let go of ... using soma_offset as the dim on obs and var leaves open the possibility of someday storing obs and var as dense dataframes ...
However I stick with my position: better to have what we do currently use (soma_joinid) remain the dim before and after this change.

I fully agree with Mike's concerns about implicitly adding one to soma_joinid. As I mentioned in our meeting last week (but failed to write up here—my apologies), presenting a user with a value that differs from what's on disk—even by one—feels wrong and confusing.
Regarding the challenge of indexing R sparse matrices with soma_joinds.  If we concede they are indeed IDs and not offsets (at least in the sparse case) we could consider populating the dimension labels of sparse matrices with the soma_joinids.
Here's an example using the snippet @eddelbuettel shared in slack earlier:
i <- c(0,2,4)
j <- c(1,3,5)
x <- c(100,200,300)
M <- sparseMatrix(i, j, x = x, index1=FALSE, repr="T")

dimnames(M) <- list(
  as.character(seq.int(0, max(i))),
  as.character(seq.int(0, max(j)))
)
M

## 5 x 6 sparse Matrix of class "dgTMatrix"
##   0   1 2   3 4   5
## 0 . 100 .   . .   .
## 1 .   . .   . .   .
## 2 .   . . 200 .   .
## 3 .   . .   . .   .
## 4 .   . .   . . 300

This explicitly treats soma_joinids as keys/IDs and provides a visual reminder that they're 0-based. It's also possible to index the matrix using the original soma_joinid values if they're passed as a string/character.
M["0", "1"]
## [1] 100

Of course, there's still potential for making the same off-by-one error if they forget to make that conversion.
M[0, 1]
## numeric(0)

But we're still maintaining the integrity of soma_joinid and allowing users to index by ID or by offsets.

I'd like to throw my support behind constraining soma_joinid to be an offset rather than an ID. Specifically, I'd like to require that obs has a soma_joinid ranging from [0, n_obs] sequentially with no gaps, and that each var has a soma_joinid ranging from [0, m_var] sequentially with no gaps. These both would be generated during SOMA creation and are consistent within the various sub-arrays of a given SOMA
Arrays in X layers, obsm, varm, obsp, and varp would have soma_joinid in the in the ranges [0, max(obs$soma_joinid)] and [0, max(var$soma_joinid)] sequentially, but with gaps allowed. This stems from Seurat v5 and how we handle gapped matrices
Note: I'm going to write in Seurat terminology (because it's easier for me and consistent with Seurat vignettes/help pages and additional documents I've prepared about v5); a Seurat <> SOMA dictionary is provided below the break

Seurat <> SOMA terminology dictionary

cells/cell name: obs_id
features/feature name: var_id
cell-level meta data: obs
feature-level meta data: var
assay: measurement
slot (v3) or layer (v5): X layer
Seurat object: SOMA experiment

In Seurat v3, every assay must have the same cells, in the same order, and every slot within each assay must have the same features. Features did not have to be consistent between assays, only within. All of this was done using character indexing, because it's easy. However, one major goal of Seurat v5 was to break both of these constraints on the Seurat object
For Seurat v5, we allow assays to not only have different features, but now different cells. We also allow layers within assays to have different cells and features from one another. We do this by defining a canonical set of cells that are present in the Seurat object, as well as a canonical set of cells and features present. When creating a Seurat object in v5, we gather a list of all unique cell and feature names across all matrices and assays provided and index them sequentially from 1 to N_cells/M_features. We then order each matrix and assay based on the sequential index of cells and features. Finally, we store the canonical cell and feature index and order in presence matrices and use this as our map between cell or feature name and index in the matrix. For example, if we have two matrices

matrix m1 with cells cell1, cell2, cell4, and cell5
matrix m2 with cells cell2, cell3, and cell5

Our resulting canonical set will be

cell1
cell2
cell4
cell5
cell3

And both m1 and m2 will be reordered based on those indexes. As such, Seurat index 4 will always refer to cell5, and we can refer back to our presence matrices to figure out where index 4 is for both m1 and m2; this index is valid for this Seurat object only. When creating a new Seurat object, including new versions of the same data, new indexes are generated for the set of cells and features provided. The sole purpose of the index is to join cell and feature names to physical location within the layer matrices and other sub-objects
In SOMA (much like Seurat v5), the sole purpose of soma_joinid would to match a meaningful term (obs_id, var_id, other bit of meta data in obs or var) to an index that can be quickly queried in every other array within a SOMA. We can obviate the need for presence matrices as the soma_joinid will be present in each array, so we can simply find where the requested soma_joinids  are and pull those dimensions
I cannot see a reason for the user to care about soma_joinid, either under the status quo or under my proposal, so applying constraints shouldn't matter. Moreover, this constraint would allow gapped arrays in obsm/varm/X layers/etc, enabling full support for Seurat v5
Furthermore, because we will have the full space of soma_joinid for both obs and var, and we know that soma_joinid is sequential, it will allow us to easily pad gapped arrays into full matrices when needed for Seurat v3 and Scanpy/Anndata

Thanks @mojaveazure , I think your input will rightly be very influential to our direction here. I'm largely in agreement, but need to press us on this point --

As for whether or not the R API should automatically translate soma_joinid from 0-based to 1-based, I don't think that's necessary. As pointed out by @eddelbuettel and @aaronwolen, we can create sparse matrices using zero-based indexes

I heard two ideas for this, neither of which is fully ideal:

(due to @aaronwolen above) Set dimnames(sparseMatrix) to as.character(soma_joinid) -- but then end user has to always access the matrix in this unusual way, as numeric row/col indexing is still one-based.
(due to @eddelbuettel in slack) Initialize with sparseMatrix(i,j,data,index1=FALSE) -- accepts zero-based inputs, but then one still accesses the matrix using one-based indexes.

LMK if I missed a better approach? If not, then these seem not much better to me than the status quo, which requires user to explicitly add one to soma_joinid to access any sparseMatrix indexed thereby.
(To be clear, I think it should be doable to have the R bindings implicitly add one to any dataframe column or array dimension named soma_joinid, so that the values in the obs/var dataframe column match the indexes with which the sparseMatrix is naturally accessed; but, it's a complication to account for in the decision matrix here.)

One possible way of automatically adjusting soma_joinid as we read out the data frame: rewrite the column in SOMADataFrame::soma_reader_transform(), something like:
soma_reader_transform = function(x) {
    tab <- arrow::as_arrow_table(arrow::RecordBatch$import_from_c(x[[1]], x[[2]]))
    tab$soma_joinid <- tab$soma_joinid + 1
    tab
}

The other possible place to do it would be in the as.data.frame(arrow::Table), but we'd need to make our own subclass of arrow::Table to override that implementation.
@eddelbuettel @aaronwolen any POV on these ideas? I'll admit I'm a bit less bullish on rewriting the id's (as part of "Option 1") after looking into more here. I don't suppose it's possible to do the equivalent of SELECT soma_joinid+1 when we send the query into TileDB before the above points?

"Conceptually" we could shiedl all access to sparseMatrix (an internal, non-user facing) package by a layer of indirection giving the user a 'one-adjusted view' of the data. (Similar to your SELECT soma_joindid + 1.)

@eddelbuettel flipping this in the opposite direction, I think might be the best solution so far!
library(Matrix)

setClass("sparseMatrixZeroBased", contains = "dgCMatrix")
sparseMatrixZeroBased <- function (...) {
  new("sparseMatrixZeroBased", sparseMatrix(...))
}
setMethod("[", signature(x = "sparseMatrixZeroBased", i = "numeric", j = "numeric"),
          function (x, i, j) {
            as(x, "dgCMatrix")[i + 1, j + 1]
          })

sparse_mat <- sparseMatrixZeroBased(i = c(0, 1, 2),
                                    j = c(0, 2, 1),
                                    x = c(3, 5, 1),
                                    index1 = FALSE,
                                    dims = c(4, 4))

> print(sparse_mat)
4 x 4 sparse Matrix of class "sparseMatrixZeroBased"

[1,] 3 . . .
[2,] . . 5 .
[3,] . 1 . .
[4,] . . . .
> print(sparse_mat[0:1,0:1])
2 x 2 sparse Matrix of class "dgCMatrix"

[1,] 3 .
[2,] . .

When are users going to be realizing a SOMA array as a matrix, then accessing via soma_joinid? AFAIKT, we don't have a matrix-like interface to SOMA. We allow users to read arrays in as sparse matrices, but how often are users going to be doing that directly instead of reading a SOMA in as a Seurat or SingleCellExperiment object? Both of those objects have names instead of join IDs, so users will use names (or subset() queries or whatever SCE offers) to slice their data. Furthermore, because soma_joinid is so difficult to access, I can't see any user pulling it for use
Moreover, when are users going to be using soma_joinid at all? At best, a user could perform a query similar to which() to get the index of obs/var that matches some filter, but we don't offer that functionality. We don't offer a way to slice SOMAs (eg. [.SOMAExperiment) in general; instead, we offer experiment queries, which handle all indexing themselves
All in all, because soma_joinid is generally useless to the end user, I don't think we need to worry about 1-based or 0-based. If we really are worried, we could ensure that soma_joinid is always realized as an integer64, which will cause errors when trying to subset a Matrix
> library(bit64)
> library(Matrix)
> sparse_mat <- sparseMatrix(i = c(0, 1, 2), j = c(0, 2, 1), x = c(3, 5, 1), index1 = FALSE, dims = c(4, 4))
> sparse_mat
4 x 4 sparse Matrix of class "dgCMatrix"

[1,] 3 . . .
[2,] . . 5 .
[3,] . 1 . .
[4,] . . . .
> soma_joinids <- seq.integer64(0, 2)
> soma_joinids
integer64
[1] 0 1 2
> sparse_mat[soma_joinids, soma_joinids]
Error in sparse_mat[soma_joinids, soma_joinids] :
  invalid or not-yet-implemented 'Matrix' subsetting

@mojaveazure It's a fair question...the original motivating example for filing this issue was this draft R vignette (a port of this python notebook), which accesses a SOMASparseNDArray indexing which genes are present in which datasets. The key operation illustrated is taking a subset of soma_joinids from the var/obs dataframe and using those to access the corresponding bits from the presence matrix -- highly prone to silent off-by-one errors currently.
I defer to you on how realistic a use case this is, but, I was tasked to port the notebook :sweat_smile: (There are multiple things wrong with the current draft right now; I need to revise it once we resolve this)
I'm going to keep hacking on sparseMatrixZeroBased today to see if it has some fatal flaw, but otherwise I think it may be the simplest solution for our key dilemma.

For this task, I would wager that the presence matrix would be more useful if it was named rather than relying on integer indexing. Seurat v5 is introducing presence matrices (already available in v4, but not widely used at the moment), if you'd like to see how we handle this task
I'm also not sure sparseMatrixZeroBased is the correct solution; we allow users to pull matrices in three representations

TsparseMatrix (internal default)
RsparseMatrix (not commonly used)
CsparseMatrix (most common)

And these can be either dMatrix or lMatrixobjects (I'm exploring the latter for use with v5 presence matrices).sparseMatrixZeroBasedis an implementation ofdgCMatrix, but doesn't account for the other permutations of sparse matrices. If you want to extend sparse matrices, I might (hesitantly) recommend overriding [` for `Matrix` objects
Example: (rough idea off the top of my head, haven't tested)
# define for CsparseMatrix, RsparseMatrix, and TsparseMatrix
# define for: (or `methods::setClassUnion("anynumber", c("integer", "numeric"))`)
# - i = numeric, j = numeric
# - i = numeric, j = missing
# - i = missing, j = numeric
# - i = integer, j = integer
# - i = integer, j = missing
# - i = missing, j = integer
# - i = integer, j = numeric
# - i = numeric, j = integer
# Can (probably) get away with defining as a separate function and embedding that as `definition`
setMethod(
  f = "[",
  signature = c(x = "CsparseMatrix", i = "numeric", j = "numeric")
  definition = function(x, i, j, ..., drop = FALSE, index0 = FALSE) {
    if (isTRUE(index0)) {
      i <- i + 1L
      j <- j + 1L
    }
    return(callNextMethod(x, i, j, ..., drop = drop))
  }
)

@mojaveazure @eddelbuettel Here's a fleshing out of sparseMatrixZeroBased based on extraordinary abuse of the dynamic class system. I'm both proud of and horrified by it. Going to sleep on this one =)
https://gist.github.com/mlin/03a3a93a4197bbfc464985eb5e0684a3#file-zerobasedsparsematrix-r
(For those trying to follow along: this is a possible distinct solution the key dilemma by wrapping sparseMatrix so that it accepts zero-based indexes directly. Although that's unconventional for R, multiple commenters have noted that users ought not care about the specific values in the soma_joinid matrix dimensions, only that they're consistent with those found in the obs/var dataframe -- and this could provide that without changing the SOMA spec or transforming the soma_joinid values at runtime.)

@eddelbuettel @mojaveazure @aaronwolen @johnkerl After sleeping on this again, I realized that the zero-based shim would be much better as a distinct wrapper object instead of subclassing all the sparseMatrix implementations. This is probably what Dirk had in mind originally, but I went down a false path in #1306 from to the initially-promising starting point above. The new approach in #1313 is much cleaner and less error-prone, and I'm now confident this is the best solution at last. Please review, officially!
My confidence is partly based on separate effort to implement the next-best alternative, excluding zero from the domain of soma_joinid. That has to touch more parts of our collective system, including a Census rebuild, and is also technically a breaking spec change to SOMA 1.0. And I haven't gotten it to actually work yet =( For reference: https://github.com/chanzuckerberg/cellxgene-census/pull/426/files https://github.com/single-cell-data/TileDB-SOMA/pull/1312/files
cc @pablo-gar @maniarathi

Nice work. I quite like what you did there -- the 'view-only' shim does what we want.
One somewhat trivial addition is to outlaw writing to such a matrix.  I.e. using your test data
> library(tiledbsoma)
> sm <- Matrix::sparseMatrix(i = 1:3, j = 1:3, x = c(41, 42, 43))
> mat <- matrixZeroBasedView(sm)
> mat[0:1, 0:1]
2 x 2 sparse Matrix of class "dgCMatrix"

[1,] 41  .
[2,]  . 42
> mat[0, 0]
[1] 41
> mat[0, 0] <- 42
Error: I'm sorry, Dave. I'm afraid I can't do that.
>

Not with the exact same error message, but you get the idea.  My quick draft used
modified   apis/r/R/utils-matrixZeroBasedView.R
@@ -46,6 +46,22 @@ matrixZeroBasedView <- function(one_based_matrix) {
   }
 }

+
+#' Zero-based matrix element assigment
+#'
+#' This method errors as a read-only view is implemented.
+#'
+#' @param x The matrix viewed in zero-based mode.
+#' @param i Row index, zero-based
+#' @param j Column index, zero-based
+#' @param val The to-be assigned value
+#'
+#' @return Nothing as the method errors.
+#' @export
+`[<-.matrixZeroBasedView` <- function(x, i, j, value) {
+    stop("I'm sorry, Dave. I'm afraid I can't do that.", call. = FALSE)
+}
+
 #' dim
 #'
 #' @param x


Stuck when interacting with containers or interactables

Steps to Reproduce (as best as you can)
It is unkown what behavior causes the issue, ke what task, as the task which was being executed in the videos has been done many times before. We will have tk do some digging to try and find out what happened.
Expected Behavior
Resolve cursor slot or other issues prior to using the container so we don't get stuck. Also, wtf is going on with the canera?
Actual Behavior (What lead to the bot getting permanently stuck)
Bot cycles through different duct tape solutions in an attempt to resolve issue with container but ultimately gets stuck in a loop
Crashlogs and Screenshots (if applicable)
(you may drag + drop text logs and images here, thanks GitHub)
latest.log

Other mods (if applicable)
sodium
starlight
baritone
fabric api
iris
Discord username (if you want updates)
Developer Notes (leave this blank)
Difficulty: Hard/???
Estimated Time Required: About a month
Once development starts.

There seems to be a few different issues from the log file. In order to isolate this, I need you to provide a more specific steps to Reproduce so I can find out exactly what's causing this. If I fix what's just in the log, then it may not resolve this issue fully.
See my example issue for guidance.

There seems to be a few different issues from the log file. In order to isolate this, I need you to provide a more specific steps to Reproduce so I can find out exactly what's causing this. If I fix what's just in the log, then it may not resolve this issue fully.
See my example issue for guidance.

Here is a good example
https://github.com/gaucho-matrero/altoclef/issues/248

Video:
https://youtu.be/76jzbsz5ygs
https://youtu.be/9b_pB7kgzFM

To have the bot run in the background:
Press F3 + P to set Minecraft to not pause on focus lost (you only need to do this once)
Alt + Tab over to a different application

Thank you for the videos.
This seems to be related to using container stlye blocks, such as furnaces, or interact blocks such as beds.
If the bot has something in the cursor, then it may have an issue using it. I'm not sure why it keeps putting items in the cursor though.
I dont think this has to do with the command line being open however. I think it would have been stuck either way.
In any case, I am labeling this a major bug and will let you know when development to resolve it begins.

This is caused by the bots inventory getting full of items it wants to protect. Im not sure if it happens when the inventory is mostly full. It shouldn't, but it may still get stuck.
We plan to resolve this with smarter container and inventory systems in the future.


Enable host offloading lowering and tests on GPU

This enables some of the host offloading tests and hooks up the rematerialization lowering on GPUs.

This depends on https://github.com/openxla/xla/pull/10185

The XLA part landed, so this PR should be ready. Could you please review this PR?

I have started the CI runs on the PR, let's see if all of them pass.

Can you please squash all the commits?

Can you please squash all the commits?

Done.


Release version 0.4.3 so we can all have the joy of LogTarget

Having this write to stderr makes it basically useless in tests, and it would be really nice to have the LogTarget feature.

I published env_logger 0.4.3 including the LogTarget feature.
https://docs.rs/env_logger/0.4.3/env_logger/struct.LogBuilder.html#method.target


Bump SQLAlchemy in the requirements.txt

Fixes #9153 (well, the real fix is in https://github.com/cms-sw/cmsdist/pull/4888)

Basic tests on my VM and agent running on MySQL went all fine. Given that it's been merged against cmsdist, let me merge it here as well.


A NullPointerException is thrown when /oauth2device_authorization and /oauth2/authorize use the same OAuth2AuthorizationConsentAuthenticationProvider

Describe the bug
A NullPointerException is thrown when /oauth2device_authorization and /oauth2/authorize use the same OAuth2AuthorizationConsentAuthenticationProvider.

To Reproduce

OAuth2DeviceAuthorizationRequestAuthenticationProvider

OAuth2AuthorizationCodeRequestAuthenticationProvider

OAuth2AuthorizationConsentAuthenticationProvider

Expected behavior
Hope to return normally.

Written incorrectly, no problem


Setup my lab environment => Exercise 1 => Account Info Screen

At the end of this exercise students get the following screen:

How to proceed? Can the instructions please be amended to provide clarify (i.e. do they need to enter this info, ignore it, etc.)?

@davidyack Can you please amend the instructions to cover the current sign-up workflow?

Entering<PHONE_NUMBER> is sufficient for the phone number.

@skulthm-ms Have you had a chance to investigate this item?
This gap in instructions is creating a range of issues for attendees and MCTs.
Example from session today, one of my attendees wanted to create the environment in her locale and got this error:

This is all within the supported ALH (Skillable). We really need to bring this aspect of the instructions up to date with actual Power Platform behavior to position attendees towards success with the labs. We cannot leave them to guess and/or try various permutations to find the ones that work.

@VitalyMCT Since you have a class right now. I would recommend that you enter "0123456789" or "0000000000" as phone number and "unitedstates" as locale/region. This is strictly when using an account from the ALH, NOT for personal trial accounts. We are looking into way to suppress the dialog box within the supported ALH.

@skulthm-ms My class has long since passed this setup step, so any fixes would be much too late for it. We already had to develop our own fixes to get the attendees to complete the associated steps.
I am investing a lot of time to file the issues in this repo in the hope they would be investigated fully and have updates made to instructions as a result. I am hoping this would start to happen on a cadence that's of a reasonably prompt frequency.
This particular issue was filed over 1 month ago. There have not been any updates to instructions around it during all that time. I think there is a huge opportunity here to make improvements.
There is a better way to get attendees into the labs than giving them the official instructions + a long list of errata / handwritten workarounds / explanations of when to follow instructions and when to do something else / misc patches. The attendees should be able to simply rely on the official instructions, as written, to succeed with the PL-500 labs.

MOC Labs Review confirms this issue.

Updated instructions to include adding the dummy phone number<PHONE_NUMBER> to get past the screen.

@ephiax20
Regarding

Updated instructions to include adding the dummy phone number<PHONE_NUMBER> to get past the screen.

This only partially addresses the issue described in this ticket. We need to provide complete guidance to the attendees so they can be successful with the labs.
Email address: what should they be entering? The email address from the auto-assigned M365 tenant? Something else?
Country region: what should they be entering? Keep at default, which may be US? Use their locale (this, per the ticket, seems problematic, at least in some scenarios)? Something else?

During my testing, the email address was already populated by default.  It is normal in the instructions to only mention items which need to be changed and accept other defaults- but I can specifically add guidance to leave everything else as default if you think that's required??

@ephiax20 Yes, I think that would work. Any method of clarifying the steps that can be provided so the attendees can be successful is a valid solution IMO. Has someone validated whether US is the default across ALHs / ALH VM regions, etc.?


Find/filter in contact book or journal

Codecov Report

Merging #122 into master will increase coverage by 0.20%.
The diff coverage is 68.81%.

@@             Coverage Diff              @@
##             master     #122      +/-   ##
============================================
+ Coverage     67.03%   67.23%   +0.20%
- Complexity      537      560      +23
============================================
  Files            97       99       +2
  Lines          1905     1981      +76
  Branches        191      202      +11
============================================
+ Hits           1277     1332      +55
- Misses          567      579      +12
- Partials         61       70       +9

Impacted Files
Coverage Δ
Complexity Δ

...main/java/seedu/address/commons/core/Messages.java
0.00% <ø> (ø)
0.00 <0.00> (ø)

...ain/java/seedu/address/logic/parser/CliSyntax.java
90.90% <ø> (-0.76%)
1.00 <0.00> (ø)

.../seedu/address/logic/parser/FindCommandParser.java
57.97% <57.35%> (-42.03%)
14.00 <13.00> (+11.00)
:arrow_down:

...java/seedu/address/logic/commands/FindCommand.java
100.00% <100.00%> (ø)
1.00 <1.00> (-5.00)

...edu/address/logic/commands/FindContactCommand.java
100.00% <100.00%> (ø)
6.00 <6.00> (?)

...ddress/logic/commands/FindJournalEntryCommand.java
100.00% <100.00%> (ø)
6.00 <6.00> (?)

.../java/seedu/address/model/journal/Description.java
70.00% <100.00%> (+25.55%)
8.00 <1.00> (+2.00)

...rc/main/java/seedu/address/model/ModelManager.java
95.65% <0.00%> (+4.34%)
30.00% <0.00%> (+1.00%)

... and 2 more

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 f150c5a...fa91653. Read the comment docs.


Getting started: React Native 0.60 - Android Issue - Result: ERROR: The modules ['react-native-notifications', 'reactnativenotifications'] point to the same directory in the file system.

Hi,
I've been having issues getting react-native-notifications to build on a freshly created 0.60.0 project and having searched far and wide for fixes (google, stackoverflow, the issues archive here) I've drawn a blank so hoping someone smarter than ourselves can help us out! This post details every step from react-native init (0.60.0) to our blocking problem.
Issue: Unable to create Android build using the instructions on Install Instructions
Steps to reproduce:
Create a new project (0.60.0)

Install react-native-notifications - note: we use yarn add react-native-notifcations - should this make any difference?

Manual Step 1: Add a reference to the library's native code in your global settings.gradle:

Manual Step 2: Declare the library as a dependency in your app-project's build.gradle:
Note: compile is obsolete - the install instructions should give the example with implementation, but for sake of following the instructions precisely...

Manual Step 3: Add the library to your application class (e.g. MainApplication.java):
react-native 0.60.0 introduces auto-linking. The instructions say that you should add the following to MainApplication.java:
import com.wix.reactnativenotifications.RNNotificationsPackage; ...     @Override     protected List<ReactPackage> getPackages() {         return Arrays.<ReactPackage>asList(             new MainReactPackage(), 	        // ... 	        // Add this line: 	        new RNNotificationsPackage(MainApplication.this)         );
However, the format of the package lists has changed to:
@Override     protected List<ReactPackage> getPackages() {       @SuppressWarnings("UnnecessaryLocalVariable")       List<ReactPackage> packages = new PackageList(this).getPackages();       // Packages that cannot be autolinked yet can be added manually here, for example:       // packages.add(new MyReactNativePackage());       return packages;     }
With React 0.60.0 auto-linking (should) negate the need to specify the RNNotificationsPackage, however, it results in the following error :
Result: ERROR: The modules ['react-native-notifications', 'reactnativenotifications'] point to the same directory in the file system.

Any ideas on how to resolve this?
More info:
package.json
{
  "name": "notifications",
  "version": "0.0.1",
  "private": true,
  "scripts": {
    "start": "react-native start",
    "test": "jest",
    "lint": "eslint ."
  },
  "dependencies": {
    "react": "16.8.6",
    "react-native": "0.60.0",
    "react-native-notifications": "^1.5.0"
  },
  "devDependencies": {
    "@babel/core": "^7.5.0",
    "@babel/runtime": "^7.5.1",
    "@react-native-community/eslint-config": "^0.0.5",
    "babel-jest": "^24.8.0",
    "eslint": "^6.0.1",
    "jest": "^24.8.0",
    "metro-react-native-babel-preset": "^0.55.0",
    "react-test-renderer": "16.8.6"
  },
  "jest": {
    "preset": "react-native"
  }
}

android/build.gradle
// Top-level build file where you can add configuration options common to all sub-projects/modules.

buildscript {
    ext {
        buildToolsVersion = "28.0.3"
        minSdkVersion = 16
        compileSdkVersion = 28
        targetSdkVersion = 28
        supportLibVersion = "28.0.0"
    }
    repositories {
        google()
        jcenter()
    }
    dependencies {
        classpath("com.android.tools.build:gradle:3.4.1")

        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
    }
}

allprojects {
    repositories {
        mavenLocal()
        maven {
            // All of React Native (JS, Obj-C sources, Android binaries) is installed from npm
            url("$rootDir/../node_modules/react-native/android")
        }
        maven {
            // Android JSC is installed from npm
            url("$rootDir/../node_modules/jsc-android/dist")
        }

        google()
        jcenter()
    }
}

android/settings.gradle
rootProject.name = 'notifications'
apply from: file("../node_modules/@react-native-community/cli-platform-android/native_modules.gradle"); applyNativeModulesSettingsGradle(settings)
include ':app'

include ':reactnativenotifications'
project(':reactnativenotifications').projectDir = new File(rootProject.projectDir, '../node_modules/react-native-notifications/android')

android/src/build.gradle
apply plugin: "com.android.application"

import com.android.build.OutputFile

/**
 * The react.gradle file registers a task for each build variant (e.g. bundleDebugJsAndAssets
 * and bundleReleaseJsAndAssets).
 * These basically call `react-native bundle` with the correct arguments during the Android build
 * cycle. By default, bundleDebugJsAndAssets is skipped, as in debug/dev mode we prefer to load the
 * bundle directly from the development server. Below you can see all the possible configurations
 * and their defaults. If you decide to add a configuration block, make sure to add it before the
 * `apply from: "../../node_modules/react-native/react.gradle"` line.
 *
 * project.ext.react = [
 *   // the name of the generated asset file containing your JS bundle
 *   bundleAssetName: "index.android.bundle",
 *
 *   // the entry file for bundle generation
 *   entryFile: "index.android.js",
 *
 *   // https://facebook.github.io/react-native/docs/performance#enable-the-ram-format
 *   bundleCommand: "ram-bundle",
 *
 *   // whether to bundle JS and assets in debug mode
 *   bundleInDebug: false,
 *
 *   // whether to bundle JS and assets in release mode
 *   bundleInRelease: true,
 *
 *   // whether to bundle JS and assets in another build variant (if configured).
 *   // See http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Build-Variants
 *   // The configuration property can be in the following formats
 *   //         'bundleIn${productFlavor}${buildType}'
 *   //         'bundleIn${buildType}'
 *   // bundleInFreeDebug: true,
 *   // bundleInPaidRelease: true,
 *   // bundleInBeta: true,
 *
 *   // whether to disable dev mode in custom build variants (by default only disabled in release)
 *   // for example: to disable dev mode in the staging build type (if configured)
 *   devDisabledInStaging: true,
 *   // The configuration property can be in the following formats
 *   //         'devDisabledIn${productFlavor}${buildType}'
 *   //         'devDisabledIn${buildType}'
 *
 *   // the root of your project, i.e. where "package.json" lives
 *   root: "../../",
 *
 *   // where to put the JS bundle asset in debug mode
 *   jsBundleDirDebug: "$buildDir/intermediates/assets/debug",
 *
 *   // where to put the JS bundle asset in release mode
 *   jsBundleDirRelease: "$buildDir/intermediates/assets/release",
 *
 *   // where to put drawable resources / React Native assets, e.g. the ones you use via
 *   // require('./image.png')), in debug mode
 *   resourcesDirDebug: "$buildDir/intermediates/res/merged/debug",
 *
 *   // where to put drawable resources / React Native assets, e.g. the ones you use via
 *   // require('./image.png')), in release mode
 *   resourcesDirRelease: "$buildDir/intermediates/res/merged/release",
 *
 *   // by default the gradle tasks are skipped if none of the JS files or assets change; this means
 *   // that we don't look at files in android/ or ios/ to determine whether the tasks are up to
 *   // date; if you have any other folders that you want to ignore for performance reasons (gradle
 *   // indexes the entire tree), add them here. Alternatively, if you have JS files in android/
 *   // for example, you might want to remove it from here.
 *   inputExcludes: ["android/**", "ios/**"],
 *
 *   // override which node gets called and with what additional arguments
 *   nodeExecutableAndArgs: ["node"],
 *
 *   // supply additional arguments to the packager
 *   extraPackagerArgs: []
 * ]
 */

project.ext.react = [
    entryFile: "index.js"
]

apply from: "../../node_modules/react-native/react.gradle"

/**
 * Set this to true to create two separate APKs instead of one:
 *   - An APK that only works on ARM devices
 *   - An APK that only works on x86 devices
 * The advantage is the size of the APK is reduced by about 4MB.
 * Upload all the APKs to the Play Store and people will download
 * the correct one based on the CPU architecture of their device.
 */
def enableSeparateBuildPerCPUArchitecture = false

/**
 * Run Proguard to shrink the Java bytecode in release builds.
 */
def enableProguardInReleaseBuilds = false

/**
 * Use international variant JavaScriptCore
 * International variant includes ICU i18n library and necessary data allowing to use
 * e.g. Date.toLocaleString and String.localeCompare that give correct results
 * when using with locales other than en-US.
 * Note that this variant is about 6MiB larger per architecture than default.
 */
def useIntlJsc = false

android {
    compileSdkVersion rootProject.ext.compileSdkVersion

    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }

    defaultConfig {
        applicationId "com.notifications"
        minSdkVersion rootProject.ext.minSdkVersion
        targetSdkVersion rootProject.ext.targetSdkVersion
        versionCode 1
        versionName "1.0"
    }
    splits {
        abi {
            reset()
            enable enableSeparateBuildPerCPUArchitecture
            universalApk false  // If true, also generate a universal APK
            include "armeabi-v7a", "x86", "arm64-v8a", "x86_64"
        }
    }
    signingConfigs {
        debug {
            storeFile file('debug.keystore')
            storePassword 'android'
            keyAlias 'androiddebugkey'
            keyPassword 'android'
        }
    }
    buildTypes {
        debug {
            signingConfig signingConfigs.debug
        }
        release {
            // Caution! In production, you need to generate your own keystore file.
            // see https://facebook.github.io/react-native/docs/signed-apk-android.
            signingConfig signingConfigs.debug
            minifyEnabled enableProguardInReleaseBuilds
            proguardFiles getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro"
        }
    }
    // applicationVariants are e.g. debug, release
    applicationVariants.all { variant ->
        variant.outputs.each { output ->
            // For each separate APK per architecture, set a unique version code as described here:
            // https://developer.android.com/studio/build/configure-apk-splits.html
            def versionCodes = ["armeabi-v7a": 1, "x86": 2, "arm64-v8a": 3, "x86_64": 4]
            def abi = output.getFilter(OutputFile.ABI)
            if (abi != null) {  // null for the universal-debug, universal-release variants
                output.versionCodeOverride =
                        versionCodes.get(abi) * 1048576 + defaultConfig.versionCode
            }
        }
    }
}

dependencies {
    implementation fileTree(dir: "libs", include: ["*.jar"])
    implementation "com.facebook.react:react-native:+"  // From node_modules
    compile project(':reactnativenotifications')

    // JSC from node_modules
    if (useIntlJsc) {
        implementation 'org.webkit:android-jsc-intl:+'
    } else {
        implementation 'org.webkit:android-jsc:+'
    }
}

// Run this once to be able to run the application with BUCK
// puts all compile dependencies into folder libs for BUCK to use
task copyDownloadableDepsToLibs(type: Copy) {
    from configurations.compile
    into 'libs'
}

apply from: file("../../node_modules/@react-native-community/cli-platform-android/native_modules.gradle"); applyNativeModulesAppBuildGradle(project)

android/app/src/main/javaj/com/notifications/MainApplication.java
package com.notifications;

import android.app.Application;

import com.facebook.react.PackageList;
import com.facebook.react.ReactApplication;
import com.facebook.react.ReactNativeHost;
import com.facebook.react.ReactPackage;
import com.facebook.soloader.SoLoader;
import com.wix.reactnativenotifications.RNNotificationsPackage;

import java.util.List;

public class MainApplication extends Application implements ReactApplication {

  private final ReactNativeHost mReactNativeHost = new ReactNativeHost(this) {
    @Override
    public boolean getUseDeveloperSupport() {
      return BuildConfig.DEBUG;
    }

    @Override
    protected List<ReactPackage> getPackages() {
      @SuppressWarnings("UnnecessaryLocalVariable")
      List<ReactPackage> packages = new PackageList(this).getPackages();
      // Packages that cannot be autolinked yet can be added manually here, for example:
      // packages.add(new MyReactNativePackage());
      return packages;
    }

    @Override
    protected String getJSMainModuleName() {
      return "index";
    }
  };

  @Override
  public ReactNativeHost getReactNativeHost() {
    return mReactNativeHost;
  }

  @Override
  public void onCreate() {
    super.onCreate();
    SoLoader.init(this, /* native exopackage */ false);
  }
}

Hi @kirkryan, this issue is getting in react-native version 0.60. It is not a react-native-notifications module issue.
Can u solve this issue???

Hi @kirkryan, did you solve this issue???

If anyone is looking for a solution:

open  a new file named react-native.config.js in your root folder, add the following content:
module.exports = { dependencies: { 'react-native-notifications': { platforms: { android: null } } } };

root/android/app/src/main/java//MainApplication.java:
add to:

@Override
protected List getPackages() {
@SuppressWarnings("UnnecessaryLocalVariable")
List packages = new PackageList(this).getPackages();

 packages.add(new RNNotificationsPackage(MainApplication.this));
return packages;

}

I wasted almost two days for this issue. I'm trying to install react-native-push-notification. I think i downgrade my version anything below than 0.60

If anyone is looking for a solution:

open  a new file named react-native.config.js in your root folder, add the following content:
module.exports = { dependencies: { 'react-native-notifications': { platforms: { android: null } } } };
root/android/app/src/main/java//MainApplication.java:
add to:

@override
protected List getPackages() {
@SuppressWarnings("UnnecessaryLocalVariable")
List packages = new PackageList(this).getPackages();

 packages.add(new RNNotificationsPackage(MainApplication.this));
return packages;

}

Tried with no sucess. I got this:
`ERROR: Unable to resolve dependency for ':app@debug/compileClasspath': Could not resolve project :reactnativenotifications.
Show Details
Affected Modules: app
ERROR: Unable to resolve dependency for ':app@debugAndroidTest/compileClasspath': Could not resolve project :reactnativenotifications.
Show Details
Affected Modules: app
ERROR: Unable to resolve dependency for ':app@debugUnitTest/compileClasspath': Could not resolve project :reactnativenotifications.
Show Details
Affected Modules: app
`

I got the same issues on 2.1.3
Downgrade to 2.0.6 resolve issue form me.