Capture enter on chat send

...

@keybase/react-hackers

The commits 76329a3afbe9...e3c4249e3632 introduce visual changes on linux. :mag_right: 1 changed

Changed: Chat_Input-Emoji_Open (before) (after)


Fix ES6 modules handling

Hi there,
As discussed in #183, here is my fix for the ES6 modules.
So, let me walk through the changes:
How to detect if we have an ES6 module?
Thankfully, it seems like Babel 6 adds a constant: __esModule and set it to true if it is an ES6 Module.
So that:

If we have an Object.
It has a __esModule property which is equal to true

We have an ES6 module.
Drawback: What about others transpilers? Should we rely on an "implementation detail"? I would love to know the advice of a Babel developer here if possible.
What do we do once we know it's an ES6 module
There are two types of export in ES6:

Named exports: export const A_CONSTANT = 3
Default exports: export default MyComponentClass

Based on this, it gives us two properties on the module object:

default
A_CONSTANT (named exports)

So alright, we can just say: "take what is available" (either default or named export).
Problem: Which order? Do we prefer default exports to named exports?
I would argue that named exports first THEN default export is better when you have components, but that could be my own standard.
The thing is that most of the time you have:
export class MyComponent extends Component {
...
}

export default someDecorator(MyComponent)

The someDecorator may be something like connect (from react-redux) or reduxForm (from redux-form) and those depends on the context.
But we don't pass meaningful context (like in the real app).
So the simplest way to test them is to use the named export rather than the default one.
Drawback: One could argue that testing decorated components are not the goal of the playground.
I believe that it would be awesome to take a step to support decorated components which works like a dumb one.
Why do we include invalid components?
A cool thing added is that: even if you have invalid components (read: not React.createClass or React.DOM or React.Component stuff), Cosmos won't include them and ignore.
If we don't do that, when we render them, it seems like that an error is thrown and it's kind of impossible to know why or how it happens.

Suggestions
In my opinion, it makes DX++, we could add beautiful alerts like "hey! there are strange components in your tree, pay attention to what you write!" if we detect invalid components.
 Is your Webpack config alright?"
That's it.
If there are code style concerns, let me know and I'll do the changes.
Thanks again for this cool project :tada: !

Drawback: What about others transpilers? Should we rely on an "implementation detail"? I would love to know the advice of a Babel developer here if possible.

It is an implementation detail but it is inside Cosmos' scope, so I'm OK with this. One thing I would recommend is adding a disclaimer comment on top of if (component.__esModule) {, something like XXX: This is an implementation detail of Babel [insert link to docs or even source code].

I would argue that named exports first THEN default export is better when you have components, but that could be my own standard.

Until further data, this sounds like the best option. If we target the pure/dumb component via name in modules where a decorated component is exported, I think it works exactly as it should, since the decoration part is already tested elsewhere and is harder to mock.

A cool thing added is that: even if you have invalid components (read: not React.createClass or React.DOM or React.Component stuff), Cosmos won't include them and ignore.

Also OK. Just checking to be string or function type might not cover all cases, but as long as it doesn't provide false negatives, it's better than nothing!

In my opinion, it makes DX++, we could add beautiful alerts like "hey! there are strange components in your tree, pay attention to what you write!" if we detect invalid components.
 Is your Webpack config alright?"

Definitely. Cosmos is a dev tool, but a user facing tool nonetheless. If you have ideas feel free to open up new discussions in separate threads.

If there are code style concerns, let me know and I'll do the changes.

Only one concern. While it's an open debate, this project uses semicolons and I think either convention is better for readability than a combination. So if you don't mind please add semicolons where appropriate. Other than that it seems like we're good to go!
Thank you for your effort!

It is an implementation detail but it is inside Cosmos' scope, so I'm OK with this. One thing I would recommend is adding a disclaimer comment on top of if (component.__esModule) {, something like XXX: This is an implementation detail of Babel [insert link to docs or even source code].

You're completely right!

Until further data, this sounds like the best option. If we target the pure/dumb component via name in modules where a decorated component is exported, I think it works exactly as it should, since the decoration part is already tested elsewhere and is harder to mock.

That was what I thought, awesome!

Also OK. Just checking to be string or function type might not cover all cases, but as long as it doesn't provide false negatives, it's better than nothing!

I should add a comment and double-check my assumptions so that we don't have problems with this!

Definitely. Cosmos is a dev tool, but a user facing tool nonetheless. If you have ideas feel free to open up new discussions in separate threads.

Yes, I believe that: DX is UX for developers.

Only one concern. While it's an open debate, this project uses semicolons and I think either convention is better for readability than a combination. So if you don't mind please add semicolons where appropriate. Other than that it seems like we're good to go!

I have absolutely no problem with this, will add semicolons!
Awesome, will edit with your remarks ASAP and :rocket: !

@RaitoBezarius are you stilll interested in doing the last edits we
mentioned? No pressure because I know how these things are, but you were
really close to getting this merged. Thanks!
On Fri, Mar 4, 2016 at 11:45 PM, Lahfa Ryan<EMAIL_ADDRESS>wrote:

It is an implementation detail but it is inside Cosmos' scope, so I'm OK
with this. One thing I would recommend is adding a disclaimer comment on
top of if (component.__esModule) {, something like XXX: This is an
implementation detail of Babel [insert link to docs or even source code].
You're completely right!
Until further data, this sounds like the best option. If we target the
pure/dumb component via name in modules where a decorated component is
exported, I think it works exactly as it should, since the decoration part
is already tested elsewhere and is harder to mock.
That was what I thought, awesome!
Also OK. Just checking to be string or function type might not cover all
cases, but as long as it doesn't provide false negatives, it's better than
nothing!
I should add a comment and double-check my assumptions so that we don't
have problems with this!
Definitely. Cosmos is a dev tool, but a user facing tool nonetheless. If
you have ideas feel free to open up new discussions in separate threads.
Yes, I believe that: DX is UX for developers.
Only one concern. While it's an open debate, this project uses semicolons
and I think either convention is better for readability than a combination.
So if you don't mind please add semicolons where appropriate. Other than
that it seems like we're good to go!
I have absolutely no problem with this, will add semicolons!
Awesome, will edit with your remarks ASAP and [image: :rocket:] !
—
Reply to this email directly or view it on GitHub
https://github.com/skidding/cosmos/pull/184#issuecomment-192482321.

--
Best,
Ovidiu

@skidding My bad! Will push the commit right away!

@skidding Could you double-check if I didn't miss one? Thanks for pinging me >_<

Merged, your patch has been published under v0.7.2. Thanks!


EnableWebMvcSecurity is deprecated

Replaced reference to EnableWebMvcSecurity with EnableWebSecurity. Code example has already been changed.

Thanks. Did you sign the contributor's agreement (https://support.springsource.com/spring_committer_signup[contributor's agreement)?

Just did. Ref#<PHONE_NUMBER>27020037. Thanks for all of this awesome Spring stuff!

You are more than welcome.


Update DRK about message

Az.... did you... did you actually forget to yarn extract?

A wizard does not forget yarn extract.  He runs extract precisely when he means to.

Totally saw it tho.


Display Issues in under larger scaling settings

Describe the bug
i found some adaptive display bugs under largest font size and largest display size.

Button "New user?" and Button "Restore" can't be displayed completely.

i belive the buggy views are Button @id/fragment_setup_init_button_new, and @id/fragment_setup_init_button_restore_backup in activity_setup.xml .
text "Let's say your username is..." can't be displayed completely.

i belive the buggy view is LinearLayout @id/setup_how_1_ll  in fragment_setup_how1.xml .
text "Either on the fly or generated beforehand..." can't be displayed completely.

i belive the buggy view is LinearLayout @id/setup_how_2_SV  in fragment_setup_how2.xml .
text  "Let's say a spammer get..." can't be displayed completely.

i belive the buggy view is LinearLayout @id/setup_how_3_ll  in fragment_setup_how3.xml .

To Reproduce
Steps to reproduce the behavior:
use the largest display and font size in android settings
click button "New users?"
click button "Next"
click button "Next"
click button "Next"
Expected behavior
here are screen shots of buggy pages under default scaling settings.
1.

2.

3.

4.

Smartphone (please complete the following information):

Device: Pixel 2
OS: Android 10.0
Version: 5.4.2

Hi,
Thanks for the report! I'll look into this 😄


Not found on Maven Central

Not sure whats up, my project includes ton of libs from maven central, but this lib can't be resolved for some reason:
:desktop:jvmMain: Could not resolve com.appmattus.crypto:cryptohash:0.10.1.
But, obviously it's there:
https://central.sonatype.com/artifact/com.appmattus.crypto/cryptohash/0.10.1/overview

weird. it appears to be working for me in the sample app when I point to the dependency from maven central.
are you able to provide some of your code of how the dependency is added?
I'm also in the process of updating the projects dependencies and as part of that upgrading the upload process; we can see if that helps too although no reason it shouldn't work currently

I apparently just had something strange going on, it syncs perfectly fine now, sorry about that!

No worries


Create acm.txt

Association of Computing Machinery

@indranil-tiwary I am sorry, but ACM, with all the respect to this organization, is not a university, nor a college. I have to close this request without merging. Please ensure you are familiar with this repository rules located at the bottom of this page before submitting a new request. Thank you for the understanding!


Can GlobalNavigationBarDropdown behave like navigation item?

Hi there!
There are example of slds Global Navigation:
https://lightningdesignsystem.com/components/global-navigation/
In this example we can see menu item with submenu dropdown, so we can navigate to this item as well as to submenu items. In react slds we have GlobalNavigationBarDropdown which have submenu with links but it is not behave like menu link.

Is it possible to implement this behaviour using design-system-react?

I believe all the MenuDropdown props can be used by the Dropdown within GlobalNav folder. See https://react.lightningdesignsystem.com/components/dropdown-menus/#prop-openOn for hover effect. It's not shown in the example for GlobalNav because I believe there are some accessibility concerns with a hover-only implementation.

Yes, you are right about hover. But the question is different. GlobalNavigationBarDropdown can contain a list of links, but can't behave like link itself.
For example, we want to create a Home navigation item, and we want its drop-down list to contain links to recent actions on the Home page or links to specific items on the Home page.

I don't think it has that since the whole component is a dropdown and not just the little arrow button. There may be an onclick prop of dropdown though https://github.com/salesforce/design-system-react/blob/master/components/menu-dropdown/menu-dropdown.jsx#L272
You might be able to use that for navigation, but that means that keyboard users will get navigated somewhere else when they try to open a menu which is a bad experience.
I'm open to the component being updating to limit the dropdown click / keyboard enter / open the menu action to the arrow and not the text. I think that's the latest pattern in SLDS.

I think this will be fixed with SLDS alignment task #1647.


22K pretrain or 22Kto1K pretrain ? What is the pretrain of ImageNet22K Swin-B + UperNet?

Hi, to finetune on downstream tasks, we usually use the only 22K pretrained model.


fix!: rename SpanContext to SpanReference

Implements https://github.com/open-telemetry/opentelemetry-specification/pull/1075

Kind of too bad this one made it into the spec :/

Yeah - "someone" expressed the same sentiment to me privately 😄 . Let's hold off on merging this until next week? I don't think it's truly final yet.

There's a spec issue to revert this: https://github.com/open-telemetry/opentelemetry-specification/issues/1126

The change was reverted in the spec, this PR can be closed

I'll close this, however I've identified a bunch of changes we should make regardless (in another PR).


Document changes from US Core generator

We need a document that describes the differences between the US Core and Au Core structure and related changes to the generator.
It will help us in the future to contribute back to US Core generator and possible use it as it is.

I analyzed changes via automatic script which gets differences via git diff. With the help of the script, I realized that 16 files had been changed.
These changes do not include:

Deleted files;
Renamed files;
Renamed content inside of files.

The next comments will include differences with detailed descriptions.
1/16
File: generator.rb
Description: Adding the MDSummaryGenerator and using it in the generator workflow.
Reason: For the confluence users
Detailed changes:

Insert generator into the generator pipeline at the end
Add a method to run MDSummaryGenerator

2/16
File: group_generator.rb
Description: Sorting of the tests. Search tests, read tests, and other tests.
Reason: Search tests should come first because with these tests the test group data is first queried. Search tests use values stored in metadata. Reading tests use data from the resources that were obtained from search tests.
Detailed changes:

https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/group_generator.rb#L124

Description: Using a helper method to generate a group description
Reason: The creation of this method was justified by the need to use the same content in different documents, with different markup.
Detailed changes:

https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/group_generator.rb#L151

3/16
File: group_metadata_extractor.rb
Description: Updated the "ALL_VERSION_CATEGORY_FIRST_PROFILES" constant
Reason: The update is explained by differences from the US core list of profiles, in which the primary search must be carried out through the category.
Detailed changes:

https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/group_metadata_extractor.rb#L98

Description: Added the "ALL_VERSION_PATIENT_FIRST_PROFILES" constant
Reason: This was added because there are profile sets whose generated metadata does not contain search constants. Therefore, in this case, the search for the patient will be the primary search in their test group.
Detailed changes:

https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/group_metadata_extractor.rb#L103
https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/group_metadata_extractor.rb#L135
https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/group_metadata_extractor.rb#L143

Description: Updated the "ALL_VERSION_ID_FIRST_PROFILES" constant
Reason: Added because there are no search constants and there is no direct link to the patient. In this case, you need to search by ID.
Other notes: Maybe it should work in another way: like a provenance test group. In these cases, we get data from other test groups and we don't need to get data directly in current test groups.
Detailed changes:

https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/group_metadata_extractor.rb#L108
https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/group_metadata_extractor.rb#L126
https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/group_metadata_extractor.rb#L145

Description: Updated the "ALL_VERSION_NAME_FIRST_PROFILES" constant
Reason: Added because the generated metadata lacks a search by ID, a direct link to the patient, and constants for searching by attributes.
Other notes: Maybe it should be removed because profiles with this requirement do not exist in the March release (previously it was a HealthcareService)
Detailed changes:

https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/group_metadata_extractor.rb#L113
https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/group_metadata_extractor.rb#L122
https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/group_metadata_extractor.rb#L147

Description: Updated the profile method
Reason: The reason for adding this update is that there is a reference to a StructureDefinition in the profiles, which does not exist in IG.
Other notes: It appears that this patch is no longer required after the March release. The March release is missing a link to a non-existent profile. Required DELETE
Detailed changes:

https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/group_metadata_extractor.rb#L174

6/16
File: ig_resources.rb
Description: Updated the search_param_by_resource_and_name method
Reason: The reason for updating this method was the problem that some search parameters were missing or there were more than 1 of them.
Other notes: Initially, the method was a fairly simple search. It now contains conditional statements and several additional methods. It seems to me that there is a method there that can simply be removed, because it is a method that calls another method. METHOD EDITING REQUIRED
Detailed changes:

https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/ig_resources.rb#L93

7/16
File: must_support_metadata_extractor.rb
Description: Updated the handle_special_cases method by adding new remove_observation_method_attribute method
Reason: In some observation profiles method attribute should not exist as MS.
Detailed changes:

https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/must_support_metadata_extractor.rb#L335
https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/must_support_metadata_extractor.rb#L375

Description: Updated the handle_special_cases method by adding new remove_observation_value_attribute method
Reason: In some observation profiles value attribute should not exist as MS.
Detailed changes:

https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/must_support_metadata_extractor.rb#L336
https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/must_support_metadata_extractor.rb#L366
https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/must_support_metadata_extractor.rb#L406

Description: Updated the handle_special_cases method by adding new remove_lipid_result_attributes method
Reason: For some unknown reason, in one survey profile in particular, a large number of attributes are labeled as MS, but this should not be the case.
Other notes: It is required, if possible, to IDENTIFY and CORRECT the problem of the appearance of a large number of attributes marked as MS.
Detailed changes:

https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/must_support_metadata_extractor.rb#L337
https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/must_support_metadata_extractor.rb#L353

8/16
File: must_support_test.rb
Description: Updated the missing_extensions method
Reason: The reason for updating this method is that in the initial version, extensions were obtained only through the "extension" attribute. This update allows you to extract the extension from any part of the resource.
Detailed changes:

https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/must_support_test.rb#L87

8/16
File: naming.rb
Description: Updated naming constants
Reason: The reason for the update is to change links to profiles.
Other notes: You need to DOUBLE CHECK and find out how current the profiles and their names are.
Detailed changes:

https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/naming.rb#L4

10/16
File: read_test_generator.rb
Description: Updated resource_collection_string method by adding all_scratch_resources for some resource types
Reason: The reason for the update is the inability to obtain some resources from references. Therefore, a resource search is used across all received resources.
Other notes: At a minimum, you need to DELETE HealthcareService, and at a maximum, you need to understand the relevance of this update.
Detailed changes:

https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/read_test_generator.rb#L72

10/16
File: reference_resolution_test.rb
Description: Add a hardcoded profile with the version for the reference resolution
Reason: The reason was the lack of a profile on the terminology server of the same version as that used in the AU core.
Detailed changes:

https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/reference_resolution_test.rb#L162

13/16
File: search.rb.erb
Description: Add organization IDs to the search test template if it needs organization IDs
Reason: The reason for this addition is that tests associated with the Organization resource require IDs to be entered.
Other notes: There is a possibility that this code may be removed. DOUBLE CHECKING is required.
Detailed changes:

https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/templates/search.rb.erb#L21

Description: Add practitioner IDs to the search test template if it needs practitioners IDs
Reason: The reason for this addition is that tests associated with the Practitioner resource require IDs to be entered.
Other notes: There is a possibility that this code may be removed. DOUBLE CHECKING is required.
Detailed changes:

https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/templates/search.rb.erb#L26

Description: Add HealthcareService IDs to the search test template if it needs healthcare services IDs
Reason: The reason for this addition is that tests associated with the HealthcareService resource require IDs to be entered.
Other notes: Should be DELETED
Detailed changes:
https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/templates/search.rb.erb#L31

14/16
File: special_cases.rb
Description: Add RelatedPerson to constant called RESOURCES_TO_EXCLUDE
Reason: This constant stores a list of resources for which it is not necessary to create test groups. In this particular case, RelatedPerson is a dependency, but it is not contained in the AU Core, so tests are not created for it.
Detailed changes:

https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/special_cases.rb#L8

15/16
File: search_definition_metadata_extractor.rb
Description: full_paths method refactoring
Reason: I think now it's better to read
Detailed changes:

https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/search_definition_metadata_extractor.rb#L44

Description: multiple_or_expectation method update
Reason: It was necessary to update because there were probably some missing values in the data.
Other notes: Need to REVIEW
Detailed changes:

https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/search_definition_metadata_extractor.rb#L172

Description: values method update
Reason: It was necessary to add the ability to work with patternCoding
Other notes: Need to REVIEW

https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/generator/search_definition_metadata_extractor.rb#L182

16/16
File: search_test.rb
Description: search_params_with_values method update for Organization values
Reason: It is necessary for getting search params values for the Organization resource test group
Other notes: Maybe it can be removed if we don't need to use organization ids (RESEARCH)
Detailed changes:

https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/search_test.rb#L473
https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/search_test.rb#L506
https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/search_test.rb#L521
https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/search_test.rb#L547

Description: search_params_with_values method update for Practitioner values
Reason: It is necessary for getting search params values for the Practitioner resource test group
Other notes: Maybe it can be removed if we don't need to use practitioner ids (RESEARCH)
Detailed changes:

https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/search_test.rb#L476
https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/search_test.rb#L509
https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/search_test.rb#L527
https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/search_test.rb#L551

Description: search_params_with_values method update for HealthcareService values
Reason: It is necessary for getting search params values for the HealthcareService resource test group
Other notes: Should be REMOVED
Detailed changes:

https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/search_test.rb#L479
https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/search_test.rb#L512
https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/search_test.rb#L533
https://github.com/heathfrankel/inferno-au-core/blob/c7a2cca16d59d8bccbfdc01daef62503e202adda/lib/au_core_test_kit/search_test.rb#L555


Added helm to the popup ignore list

Helm manages it's own windows and doesn't interface with popup very well.

I'm afraid I can't accept this into Doom. I consider this as a personal customization and would rather leave this to private modules than make this the default, for a couple reasons:

I've tried to model the helm and ivy modules to act visually similar to CtrlP (vim), Goto-Anywhere (sublime text/atom), and command-T (textmate), as a reasonable default. I agree that it doesn'tt suit widescreens well, but I'd like to implement child frame support to address this).
The completion/helm module's defaults work fine with feature/popup. If this is not the case, that is a bug.
It is easier to put (set! :popup "^\\*helm" :ignore) in a private config than it is for another user to either remove that rule from display-buffer-alist or define a new rule to shadow the old one simply to reinstate the fallback behavior of +all.

That seems reasonable to me. I didn't think it would do anything to the default setup and I figured it would make customizing helm less confusing. It certainly took me awhile to figure out why my helm settings weren't applying. Perhaps there's a fix in popup that's less drastic than :ignore that maintains the original behavior.


Add ThreadPool::spawn_ok and spawn_obj_ok

Considering that spawn and spawn_obj never fail on the ThreadPool, it is desirable to add alternative methods that indeed cannot fail to spawn tasks.
I added this _ok suffix, otherwise that would be a breaking change. People's code would suddenly use the inherent method instead of the trait method, and likely get a compilation error because you can't call unwrap() on ().
Now that SpawnError unfortunately no longer contains the Future that failed to spawn, it is no longer possible to properly handle tasks spawn failures.

Thanks!


feat: update ascii for control modifiers

Issue #, if available:
#523
Description of changes:
Make sure ascii printing a circuit works with controlled gates
Testing done:
Manual and unit testing
Merge Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your pull request.
General

[x] I have read the CONTRIBUTING doc
[x] I used the commit message format described in CONTRIBUTING
[x] I have updated any necessary documentation, including READMEs and API docs (if appropriate)

Tests

[x] I have added tests that prove my fix is effective or that my feature works (if appropriate)
[x] I have checked that my tests are not configured for a specific region or account (if appropriate)

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

Failing due to lack of error mitigation schemas, need to get the latest main in, but there's a linter complaining about rst formatting of some bra-kets in doc strings. working through it


Transparent Background not revert when scan is destroyed

Seems like the background stays transparent when the sacn is destroyed

YES, body tag still have style="background-color: transparent;"

Use this to fix the error temporary.
`
import { Component, ChangeDetectorRef } from '@angular/core';
setTimeout(() => {
window.document.body.style.backgroundColor = '#FFF';
this.ref.detectChanges();
}, 500);
`

Use this to fix the error temporary.
`
import { Component, ChangeDetectorRef } from '@angular/core';
setTimeout(() => {
window.document.body.style.backgroundColor = '#FFF';
this.ref.detectChanges();
}, 500);
`

Thanks! Im using vanilla javascript. Can you provide more detail what does this.ref.detectChanges();
do and what is the equivalent code of it in vanilla javasript

Having the same issue here too. Where about does the above code go? As the background is still remaining transparent for me. I understand that based off the angular docs (https://angular.io/api/core/ChangeDetectorRef) that the change detector checks for changes in the view, however don't fully understand where this needs to go to perform properly.

@devleaf-matt
I found it work on my ionic3 project.
But not work on ionic4 project.

is there any turn around for this ? i really need the fix today

I wrote a quick and dirty workaround like this:
scan() {
        document.body.style.backgroundColor = 'transparent';

        QRScanner.show();
        QRScanner.scan(displayContents);

        function displayContents(err, text) {
          if(err){
            console.log('error', err);
          } else {
            alert(text);
            if (text) {
              QRScanner.hide();
              QRScanner.cancelScan();
              document.body.style.backgroundColor = '#FFF';
            }
          }
        }
      }

Any more info on this? I've found that both hide() and cancelScan() result in different body background colors. cancelScan() seems to revert it to transparent. Will this be fixed?

I have created a pull request that fixes this:
https://github.com/bitpay/cordova-plugin-qrscanner/pull/279
This bug was created by this previous commit:
https://github.com/bitpay/cordova-plugin-qrscanner/commit/c9531b85e93d4cf5b844b83f265975c683cbee11
Or, if my PR is not accepted, you can use my clone:
https://github.com/p3v9d5ui/cordova-plugin-qrscanner

I have created a pull request that fixes this:
#279
This bug was created by this previous commit:
c9531b8
Or, if my PR is not accepted, you can use my clone:
https://github.com/p3v9d5ui/cordova-plugin-qrscanner

We are facing the same issue, @p3v9d5ui PR should be approved.

Below code works for me
$("html").hide();
QRScanner.scan(displayContents);

function displayContents(err,text){
  if(err){
	alert("Something went wrong. Please try after some time.");
  }
  else{
	$("html").show();
	QRScanner.hide();
	QRScanner.cancelScan();
	alert(text);
  }
}

QRScanner.show();

Hope it helps, Happy coding!


Bug: Left Controls Top Tiles Border/Shadow Cut Off

Just updated to Version 10, and it seems that the topmost left tiles have the top border/shadows abruptly cut off. Everything else works as intended.

One more to add - again quite minor - the arrow when the right menu is collapsed points inward rather than outward.

Thanks. The cut off corners on top, believe it or not, it is also on
Foundry without modules!
Steve @.***> schrieb am So., 13. Nov. 2022, 13:18:

One more to add - again quite minor - the arrow when the right menu is
collapsed points inward rather than outward.
[image: Arrow Right]
https://user-images.githubusercontent.com/97303899/201537643-4a4efe80-a66c-4f2e-b3d7-1892d22c5cc8.png
—
Reply to this email directly, view it on GitHub
https://github.com/saif-ellafi/foundryvtt-minimal-ui/issues/112#issuecomment-1312790550,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGVIMO5AUMQ54ZF5XZ42WRLWIEWF3ANCNFSM6AAAAAAR7EI7RQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Ah I see. Thanks for clarifying! I suppose we'll be waiting for an update on their end, then. Thanks!
I appreciate you looking into these.


Block off unwanted users

We currently have the issue of someone using the webhook and spamming our discord which we don't want.
If someone gains access to the webhook, there is no way to prevent them from spamming the server.
Is there a solution to that?

is the plug-in still working for you? mine stopped working on the 18th of this month

@CANFGhost since the plugin does nothing except posting to the entered webhook URL's, there is no way to prevent this within the plugin.
It's something you should fix in Discord by either providing unique webhooks per user or generate a new one in case your webhook has been compromised.
They could spam your discord either way if they have the webhook URL and feel like doing it.

@lilfmdude What isn't working for u? It should still work without any problems.


Update Katib ROCKs to 0.16-rc.1 for CKF release 1.8

This issue tracks the process of updating Katib ROCKs to Katib's 0.16 for CKF release 1.8. For the process, we 're following our internal Kubeflow ROCK Images Best Practices that has a section about Upgrade of ROCK Images.
The changes that this process will introduce should match what the upstream has for version v0.16-rc.1.

katib-db-manager
db-manager Dockerfile has introduced the following changes
5d4
< ENV GRPC_HEALTH_PROBE_VERSION v0.4.15
21,24d19
< # Add GRPC health probe.
< RUN wget -qO /bin/grpc_health_probe https://github.com/grpc-ecosystem/grpc-health-probe/releases/download/${GRPC_HEALTH_PROBE_VERSION}/grpc_health_probe-linux-${TARGETARCH} \
<   && chmod +x /bin/grpc_health_probe
<
28d22
< COPY --from=build-env /bin/grpc_health_probe /bin/

which is expected according to https://github.com/canonical/katib-operators/issues/122#issuecomment-1687933708. Thus, we will not introduce those changes in the ROCK.

katib-ui-rock
We need to rewrite the ROCK due to it being based on the wrong dockerfile https://github.com/canonical/katib-rocks/issues/32.

grpc health checks
As discussed here, we 're following what was done upstream and removing the binary for health checks since

this type of ROCK images are not managed by charms. GRPC checks will be peformed by K8S on this images.


Playground precommit fix

Please add a meaningful description for your change here

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

Codecov Report

Merging #454 (49a5d91) into master (d9321d8) will decrease coverage by 0.43%.
The diff coverage is 31.94%.

@@            Coverage Diff             @@
##           master     #454      +/-   ##
==========================================
- Coverage   54.09%   53.67%   -0.43%
==========================================
  Files         279      283       +4
  Lines       33947    34276     +329
==========================================
+ Hits        18365    18398      +33
- Misses      14100    14389     +289
- Partials     1482     1489       +7

Flag
Coverage Δ

go
53.67% <31.94%> (-0.43%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

sdks/go/pkg/beam/runners/prism/internal/coders.go
92.05% <0.00%> (ø)

sdks/go/pkg/beam/runners/prism/internal/stage.go
90.72% <0.00%> (ø)

...dks/go/pkg/beam/runners/universal/runnerlib/job.go
0.00% <0.00%> (ø)

sdks/go/pkg/beam/artifact/stage.go
60.97% <11.11%> (-0.90%)
:arrow_down:

sdks/go/pkg/beam/io/mongodbio/coder.go
68.18% <33.33%> (-15.16%)
:arrow_down:

...s/go/pkg/beam/runners/universal/runnerlib/stage.go
40.47% <34.21%> (ø)

...o/pkg/beam/runners/prism/internal/worker/worker.go
63.17% <40.00%> (-1.42%)
:arrow_down:

sdks/go/pkg/beam/provision/provision.go
60.00% <60.00%> (+12.50%)
:arrow_up:

... and 3 files with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


TypeError: can't read property of args while $extend to $allOperations

Bug description
Property 'data' does not exist on type 'miesFindFirstArgs<InternalArgs & DefaultArgs> | miesCreateArgs<InternalArgs & DefaultArgs> | ... 12 more ... | miesGroupByArgs<...>'.
Property 'data' does not exist on type 'miesFindFirstArgs<InternalArgs & DefaultArgs>'.
How to reproduce
  prisma.$extends({
    query: {
      mies: {

        async $allOperations({ model, operation,  query , args}) {
          if (
            model == "mies" &&
            ["create", "upsert"].indexOf(operation) != -1
          ) {
            if (args.data) {

Expected behavior
No response
Prisma information
Not necessary. It is easy to reproduce.
Environment & setup

OS: MacOS
Database: PosgreSQL
Node.js version: 20

Prisma Version
prisma                  : 5.8.0
@prisma/client          : 5.8.0

 ["create", "upsert"].indexOf(operation) != -1 is not something TS can understand and narrow down the types of args down. Try replacing this line with operation === 'create' || operation === 'upsert'.


Don't use bioconda environments in docker image

See https://github.com/nf-core/chipseq/pull/10#issue-190796115 by @tiagochst:

Changed RUN conda env create -f /environment.yml to RUN conda env update -n root --file environment.yml  because of the source below:

If you are using the Conda package manager, avoid creating a Conda environment. Instead, update the root environment with whatever dependencies you want to install.
As an example to the above warning, it would be best practice to run this: RUN conda env update -n root --file environment.yml and avoid this: RUN conda env create -f environment.yml

https://docs.datascience.com/en/master/appendix-1/dockerfile-basics-and-best-practices-1.html

We should update all pipelines to use this method.

Didn’t we have that in the beginning and then switched to define a conda environment ? I just can’t remember anymore why and for what reason right now ..... will check this once I got my notebook back ....

The documentation just states, that one should not create Conda environments in Docker builds, but unfortunately not why. Can someone enlighten me?

@tiagochst - any ideas why this is the case? Also pinging @tsnowlan - you're not involved in this project at all sorry, but you know your stuff when it comes to Docker so perhaps you have some insight!

Looks like those are restrictions for the specific DataScience.com platform. They also say not to use ARG, custom ENTRYPOINT, etc., and those are definitely normally used dockerfile commands. Are you using their platform, or just using this as a best practices reference?
As to why they don't like conda environments, I have no idea. I see a number of other pages detailing how to set it up in both docker and singularity. They're from different times in the past few years as well so I don't think it's a matter of new or outdated practice. Might just be something for simplifying their ops requirements.

Are you using their platform, or just using this as a best practices reference?

Just thinking about best practices. @tiagochst - how did you come across these docs in the first place? Was there a reason that you were referring to them?
We currently have a line to avoid needing to activate the conda environment in the container:
ENV PATH /opt/conda/envs/nfcore-chipseq-1.4dev/bin:$PATH

I've always felt that this is a little hacky, so using the root environment feels cleaner somehow. But maybe we should keep things simple and stay with the current Dockerfile setup then. After all, it seems to work..

You can keep the old way if it was working and it was just a warning. I don't know the reason why use one instead of the another unless I ask who wrote the documentation.
I'm not sure how I came to that documentation. But,  I would say I found that by chance (I was looking to use conda with github repo, If I'm not wrong) and decided to change if it was working since it was a warning. There was no problem with the last code.

I have je same feeling: it looks cleaner but thought it’s bad practice to have everything in the root environment. As we are only using this environment in the container and are not creating more than that, I assume it would be fine too and feels a bit cleaner . Also we could get rid of the current special ENV hack ...

@apeltzer - I'm a bit confused. Are you saying that we should make the change or keep it as it is?

@apeltzer I dont get it now either :D

But my feeling is, that you go for root environment @apeltzer. I was just curious, if there is a strong reason, not to use conda environments in Dockerbuilds. If this is not the case, I vote for leaving the Dockerfile template as it is now.

+1 vote for leaving it as it is now if no practical differences.

+1

Hi everyone,
sorry for my ipad comment - trying to save typing there since I'm terrible on that "keyboard" they provide on ipads....
No there is no strong reason to NOT use them - only that they require a "hackish" ENV to add the binaries to the current PATH inside the container seems a bit "unclean" to me and I'd prefer the root solution for that purpose. However, changing everyone's containers just because of such a purely cosmetic thing is overkill for me too - so let's keep things as they are!
If we at some point find a technical reason why we shouldn't have the conda environments inside the container we can anyways migrate ;-)
Sorry for not being more clear with my comments on this

Ok cool, I think we have consensus 👍 Will close this issue now.


net::ERR_CERT_DATE_INVALID

Error: net::ERR_CERT_DATE_INVALID
at SimpleURLLoaderWrapper.<anonymous> (node:<REDACTED: user-file-path>:105:7047)
at SimpleURLLoaderWrapper.emit (node:events:526:28)

Go to Errors Site

This is the top error by machines

@sandy081 can we log the request url to telemetry that resulted in this failure ? It would help to validate if the SSL certificate has expired.

We can, but it seems like this error is not reported by the request service but instead by SimpleURLLoaderWrapper and not sure who is the caller to it.

SimpleURLLoaderWrapper is just native wrapper to the net module from Electron, the certificate error happens at the network layer hence the stack doesn't point back to RequestService. The above error is captured by the error event on the request object at https://github.com/microsoft/vscode/blob/e3dca06ca42e21184f1f75f7830ad67be5d96607/src/vs/platform/request/node/requestService.ts#L174

Closing as stale


Adjust paritioning / hash behavior to comply with java lib

So we had a problem here with java and go services working together. Even though they are using the same hash function, the behavior afterwards is slightly different.
While java is doing this:
Abs(Hash) % numPartitions
Sarama was doing this:
Abs(Hash % numPartitions
I updated that according to how the java lib is doing it :
https://github.com/apache/kafka/blob/fa1d0383902260576132e09bdf9efcc2784b55b4/clients/src/main/java/org/apache/kafka/clients/producer/internals/DefaultPartitioner.java#L69
https://github.com/apache/kafka/blob/fa1d0383902260576132e09bdf9efcc2784b55b4/clients/src/main/java/org/apache/kafka/common/utils/Utils.java#L821

Yes, because of the bitwise operation, the problem described in  https://github.com/Shopify/sarama/pull/709 will not happen again and the tests for it are green. The problem with that was with the max integer values.
Even though this modification halves the basic set, it shouldn't affect the even total distribution amongst the partitions.
On the other hand, since the implementation differs in the official client and presumably other languages, the partitioning doesn't match which leads to other problems which has a more grave effect on how the whole partitioning works and leads to inconsistency.

Makes sense, I agree this is a worthwhile change. I'm wondering if it should be shipped as a new partitioner though, in case there are users depending on the old implementation now without realizing it (e.g. because they never used the official client at all).

Making it an own partitioner would make sense for making a non-breaking migration possible even though, naturally, for us it means that we have to use this new hash function in every service.
Only other possible solution would be adjusting the version major numbers.

Thanks for reporting this, https://github.com/Shopify/sarama/commit/6967cdb516216f65c91b9ae11431901c8b12ecf5 adds a NewReferenceHashPartitioner based on this PR.


Error: integer out of range

💡 Summary
Getting 100+ errors for this:
ERROR:  integer out of range
STATEMENT:  UPDATE "instance" SET "driveUsage" = "driveUsage" + 197061 WHERE "host" = $1
📌 Environment
Misskey 12.69.0 PostgreSQL 10.15

#6807
#6977

@mei23 Are they all related? Is there a quick fix for this? So many log entries for this error and the issue has been opened since November 2020.

ここでスキーマ直したのにマイグレスクリプト書いてないのがいけない
https://github.com/syuilo/misskey/commit/6d4526576307d2ff62b3e512f2b9ce6cc9ffa3ab#diff-cde0f9bc7fbf190b07e782ab3cc550a78b469b9eec21b23f8e1eba89ce16cbbe


Finalize trip editor: Add deletion + more tooltips

Summary
This PR implements deletion of locations for existing trips using the Trip Editor, as well as useful tooltips for deletion and explaining weights to the user.
Deleting locations requires a cascading update for every following trip location, as we need to change the location numbers and update the markers on the map. These side effects required me to account for updating/removing markers from the editor map, splice the markers and locationPlaceObjects arrays, and remove event listeners that apply to locations that have changed number as a result of a deletion.
Screenshot
Tooltips for weight

Deletion feature

Test Plan
Run mvn package appengine:run. Mouse over the "Weight" label to see that the tooltip works. Delete some locations in a preexisting trip and add some more, and see that the trip is updated accordingly.

All the new features on My Trips work great, but when I went to check the itinerary page, I saw directions for what I assume were Josh's hardcoded test locations around Dallas instead of the trip I just saved. Not sure why this is happening since it worked during the demo, but we'll need to fix this by tomorrow's presentation.

All the new features on My Trips work great, but when I went to check the itinerary page, I saw directions for what I assume were Josh's hardcoded test locations around Dallas instead of the trip I just saved. Not sure why this is happening since it worked during the demo, but we'll need to fix this by tomorrow's presentation.

This is because I haven't merged in master. Since I didn't change any of the files in Josh's part, it won't make any difference once it is merged in.

All the new features on My Trips work great, but when I went to check the itinerary page, I saw directions for what I assume were Josh's hardcoded test locations around Dallas instead of the trip I just saved. Not sure why this is happening since it worked during the demo, but we'll need to fix this by tomorrow's presentation.

This is because I haven't merged in master. Since I didn't change any of the files in Josh's part, it won't make any difference once it is merged in.

Ah ok makes sense, lgtm then


Three Portraits from &

Hope to have sorted my various issues. Thanks for your patience.

Thanks for this. It appears that three poems are being deleted from XLI Poems in this merge request. Is that right?

I had reverted my own commits on those because the most recent repository indicated a merge conflict. Maybe I got that wrong?
I'm thinking about pulling a new fork from your project and starting fresh. I've mucked up the repository enough.

On May 13, 2021, at 7:06 AM, Ben Welsh @.***> wrote:
Thanks for this. It appears that three poems are being deleted from XLI Poems in this merge request. Is that right?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/ee-cummings-archive/cummings.ee/pull/110#issuecomment-840585444, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATXO4GOM5IVU55UQ3FJFY3TNPMHLANCNFSM44Z4XUPA.

That would be a fine solution. Totally normal.

Gotcha. Thanks.


Make the port column a little wider to stop truncation

For firefox+linux which renders slightly tighter it seems
Fixes #1711

replicasets and deployments need the same treatment. And hosts.

Bar comment, code LGTM, and looks good on Mac/Chrome
@rade could you confirm the port width fix viewed on Linux?

@rade could you confirm the port width fix viewed on Linux?

See https://github.com/weaveworks/scope/issues/1711#issuecomment-237305358 - i.e. I am no longer seeing that problem even without that change - looking at the images, it seems that the column width increased since I reported the problem.

re: replicasets, hosts and deployments this fixes it for those too, bad commit message.

re: replicasets, hosts and deployments this fixes it for those too, bad commit message.

And comment in the code!
Are you sure this fixes hosts? What does that have to do with kubernetes_ip?

Yes! and in the code.
Fixes hosts in the sense that the only place I could find an ip in the hosts panel was in the k8s section.

Fixes hosts in the sense that the only place I could find an ip in the hosts panel was in the k8s section.

Ah yes, good point. What an odd choice of columns - listing the IPs of pods but not containers.

More long term solution could be covered in #1735

Squashed


pkg/alertmanager: mergepatch alertmangaer containers

Instead of just appending user defined containers to the alertmanager
pods, use k8sutil.MergePatchContainers so that the default containers
can be modified.

lgtm modulo a question: does this change the current standard behavior in any way, i.e. are existing declarations potentially affected somehow?

The current behaviour is to just append the list of containers.  With the mergepatch change we still append containers unless the name matches an existing container.  The only cases where this would affect an existing configwould be where one or more of the patch containers matches the name of one of the default containers alertmanager or config-reloader.  Which might cause an error currently, since I'm not sure kube allows two containers with the same name?  So I don't think there is a significant risk of breaking existing configs.
Also, this brings the alertmanager use of the containers field in-line with prometheus and thanos ruler, so the behaviour is more consistent between the operators.

LGTM, thanks for the rationale!


Divide MBs by 10^6 and round the result

closes #1382

@wowshakhov please check build fail status by Travis.

Pull Request Test Coverage Report for Build 1909

6 of 9 (66.67%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.009%) to 53.787%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/app/shared/services/utils/utils.service.ts
0
1
0.0%

src/app/shared/pipes/convert-to-mb.pipe.ts
5
7
71.43%

Totals

Change from base Build 1904:
0.009%

Covered Lines:
9804

Relevant Lines:
16198

💛  - Coveralls


Fix CVE dependency issue

What type of PR is this?

What does this PR do / why is it needed ?

Which issue(s) this PR fixes:

Fix issue #1455   by update dependency org.yaml:snakeyaml:1.32 @epsstan
Other notes for reviewers:
Does this PR introduce a user-facing change?

This PR is stale because it has been open for 30 days with no activity. Please remove stale label or add any comment to keep this open. Otherwise this will be closed in 5 days.

This PR was closed because it has been inactive for 35 days. Please re-open if this PR is still relevant.


Fix #5602

Did you mean to close this @LukasCornille ?

Yes, for some reason I didn't manage to get all the files when cloning the repo and didn't have the time do what's required to create a decent pr. 😅


Replace all occurances of "epidemiology" with "memilio"

We should scan all references (documentation, directory names, cmake targets...) for "epidemiology" and consider renaming them to "memilio".
This is easily sed'd, but it will create a whole bunch of merge conflicts.

most occurences have been replaced in #99 and #66, remaining references are all in 'pycode/memilio-epidata/README', see #147 and #112


Added tvdbid for A Journey Through Another World: Raising Kids While …

…Adventuring (MAL 57380)

Mapping is already working, figured it might have been added already.

Mapping is already working, figured it might have been added already/mapping available elsewhere.

Most of the time, Season 1 will automatically work with Shinkro, so you don't have to map it.  There are a few exceptions but mapping is mostly required for Season 2 or more and Specials/OVAs.

@ppkhoa you can still add it. It doesn't hurt to have everything mapped. The mapping could be useful for another project or developer . So it's good to have it 😊


Calc temperature after latent heat release

Closes #1738
Adds method to adjust temperature and humidity for latent heat release.

Moves WetBulbTemperature and WetBulbTemperatureIntegral plugins into a new wet_bulb_temperature.py module as psychrometric_calculations is getting too big.
Moves _calculate_latent_heat method from WetBulbTemperature plugin to psychrometric_calculations so that it can be used in latent heat release calculations.
Adds extra tests for dry adiabatic methods to cover a higher altitude case.

Testing:

[x] Ran tests and they passed OK
[x] Added new tests for the new feature(s)

@MoseleyS can you fix the broken unit tests please, and generate a ticket about extending the psychrometric calculations documentation for future work.


Remove EndOfDeclarationMarker and MergeDeclarationMarker nodes

These nodes were added to attempt to preserve the emit behavior of an older version of the TypeScript compiler prior to the introduction of transforms. We're a long way away from TS 1.x at this point, and the complexity these nodes add aren't worth preserving specific emit as long as the resulting emit is compatible.
One thing of note is that in some cases we used to defer the emit of an export for a class until after static initializers or decorators have run. While that was intended to be consistent with native imports and exports when downleveling to CommonJS/System, our actual ES module emit fails to preserve this semantic. The only way to preserve this semantic consistently would be to wrap all downlevel classes that have statics/legacy decorators in IIFEs. However, IIFEs reduce readability and we've tried to avoid them unless absolutely necessary.
While it is technically feasible to access an undecorated class via an import with this change to CJS/System emit, it would be an exceedingly rare occurrence to do so accidentally. I think the slight non-conformance of the emit is worth the simplification of the AST and reduction in complexity for class-related transforms. Removing these marker nodes will also unblock the using declarations work.
If we find that we do want to adopt 100% semantic conformance for these exports, we can revisit wrapping such exported classes in IIFEs like we do for the new ES decorators emit.

Can you give an example of what semantic change this PR has? I'm having trouble coming up with something concrete before/after where you could access the undecorated class.

An easier example would be downlevel emit for class static fields:
export class C {
  static x = 1;
}

// before:
// target: es2017
// module: commonjs
class C {
}
C.x = 1;
exports.C = C;

// target: es2017
// module: esnext
class C {
}
C.x = 1;
export { C };

// after:
// target: es2017
// module: commonjs
class C {
}
exports.C = C;
C.x = 1;

// target: es2017
// module: esnext
class C {
}
C.x = 1;
export { C };

The difference here is the ordering of C.x = 1 and exports.C = C. The new emit is more consistent with the current module: esnext emit, but the old emit was more correct. Native class fields and native exports would only initialize the export binding after the class is initialized.
The only way you can see the uninitialized (or undecorated) class is if you have a cycle in your imports and run code during initialization that references the exported version of the class:
// file.ts
import { C as C2 } from "./file";
export class C {
  static x = C2.y;
  static y = 2;
}

This isn't much different than the same code without the circular import, so it's not much of a footgun.

It's important to note that export { C } is not executed as a statement. The export is essentially hoisted to the top of the file, so these two files are equivalent:
// a.ts
let x = 1;
export { x };

// b.ts
export { x };
let x = 1;

Thanks for explaining! If it comes to it, how difficult is the change to make it fully semantically equivalent? I know you want this to unblock using, so from that perspective it seems fine, but I can say I'm slightly worried about esoteric codebases which may regress (like codebases as circular as ours).
I know esbuild's output is resilient to this, though I think that's because it defines module exports via defineProperty and thus can hoist everything like ESM first, then do the transform: https://jakebailey.dev/esbuild-playground/#Ly8gQGZpbGVuYW1lOiBjb25maWcuanNvbgp7CiAgImVudHJ5UG9pbnRzIjogWyIvaW5kZXgudHMiXSwKICAiZm9ybWF0IjogImNqcyIKfQoKLy8gQGZpbGVuYW1lOiBpbmRleC50cwpleHBvcnQgY2xhc3MgQyB7CiAgc3RhdGljIHggPSAxOwp9

ESBuild isn't conformant with the spec either, since C is reachable from outside of the module before static fields are initialized. In the spec, the binding is only reachable after the class is initialized. See https://tc39.es/ecma262/#sec-runtime-semantics-bindingclassdeclarationevaluation.

Sure, but in that case, would it just be undefined rather than some partially completed value?

If it comes to it, how difficult is the change to make it fully semantically equivalent?

Not difficult, but it requires an IIFE. We intentionally did not do that because we preferred emit like:
class C {}
C.x = 1;

over
let C = (() => {
  class C {}
  C.x = 1;
  return C;
})();

and I'm pretty sure that opinion hasn't changed much, at least for static fields.

Sure, but in that case, would it just be undefined rather than some partially completed value?

For ESBuild? No, it would be in TDZ until class C {} is evaluated, then reachable but partially initialized until C.x = 1; is evaluated.

It's var C = class {} in the esbuild output, so I don't think there's TDZ unless I'm missing something.

If it comes to it, how difficult is the change to make it fully semantically equivalent?

Not difficult, but it requires an IIFE. We intentionally did not do that because we preferred emit like: [...]

Note though, that while it may be "not difficult", it is compounded for each new class feature, i.e.:
let C = (() => {
  let C = (() => {
    class C {}
    C.x = 1;
    return C;
  })();
  C = __decorate(C, [dec]);
  return C;
})();

It's var C = class {} in the esbuild output, so I don't think there's TDZ unless I'm missing something.

I stand corrected on that count. But there are still three observable states:

Not initialized
Partially initialized
Fully initialized

Right, and the way to get into the "partially initialized" state would be to try and use the class inside itself such that you get it before C.x = ... runs?
But yeah, it's effectively no better than what this PR does in that case.

Right, and the way to get into the "partially initialized" state would be to try and use the class inside itself such that you get it before C.x = ... runs?

Essentially, yes, which is why I said it would be exceedingly rare to end up in that state accidentally.

@typescript-bot perf test
@typescript-bot run dt
@typescript-bot test this
@typescript-bot user test this

Bit weird that you could observe the non-decorated class downlevel in some cases now, but if we're willing to accept that (and it seems like we are), this looks fine.

As I said up-thread, you can already observe them when using --module esnext (or --module nodenext) due to the mechanics of export { C }


Add support for tags

Looks for a label in the state.json with the tags key and parses it as a comma-separated list of values into ServiceTags in Consul.
// state.json
labels: [{
  key: "tags",
  value: "label1,label2,label3"
}]

// /v1/catalog/service/<service-id>
ServiceTags: [
  "label1",
  "label2",
  "label3"
]

I added this to the 0.3 branch that was just merged into the master.


Consuming a queue creates a new routing_key

I just want to consume an queue that another application is publishing. But at queue.rb, a router key is created at a bind.  I wonder if there could be a attribute to prevent this binding to create a undesirable routing_key.

@Tensho thoughts? I feel like we are drowning in options and would prefer to not add more unless there's a substantial interest.

@anacarolinacastro As I understand the basic idea behind any worker to have all the necessary information (options) to setup all RMQ components to consume the messages – exchange, queue and binding (with routing key) between them. This is by AMQP design – topology is programmable and application is responsible to declare it ("AMQP is a Programmable Protocol"). If any of the components exist, e.g. binding, bunny reuses it and doesn't create an extra one. So you just have to configure (specify) the corresponding worker options that reflects your existing binding.

@Tensho I think the complaint here is about the binding that every worker sets up even if it wouldn't be necessary because the topology is already set up "out of band".


Return type of some functions is incorrect.

Hi!
I have a function with a logic similar to the below function
function f(x: number) {
  if (x < 5) return true
  if (x > 20) return false
  return undefined
}

The return type inferred by the TypeScript compiler is boolean | undefined
The return type produced by TypeDoc is undefined | true | false

No big deal but still annoying...

@tomc974, the return types are defined by TypeScript.. If you think the type is incorrect you can create an issue on the TypeScript Project repo. Since it is not something TypeDoc changes I'll close this.
Because I'm curious, why would you want a true | false type rather than a boolean type? In my mind those are the same with the possible exception of allowing null.

@aciccarello It's the other way around. I do want the boolean | undefined type but TypeDoc generates  documentation with undefined | true | false. Try to run it on the provided example ;-)

@tomc974 Sorry, I misunderstood.
I've confirmed TypeDoc is outputting differently than TypeScript's implicit definition. If the function is explicitly given a boolean | undefined return type, that is respected by TypeDoc.

I see this with an interface method that has the signature writeValue(buffer: GrowableBuffer, value: VALUE, root?: boolean): void. The type for root shows up instead as root?: undefined | true | false. I have an abstract class that implements this interface with an abstract version of the method. Interestingly, it is also broken for the abstract class, but subclasses of the abstract class that implement this method have the correct documentation.

Fixed in 0.20.0 beta 30


ValueError when running training with Multi-GPU

Dear Team,
I am running training with 2 K80 Nvidia GPUs. I tried both dev branch with tf 1.2.0, python 3.6.2 with the following line:
python3 -m basic.cli --mode train --noload --num_gpus 2 --batch_size 30
However the program quits with the errors attached. We are a bit confused on how to track what's causing the error, and we are wondering if we could get some help?
Here starts the log of the error:
Traceback (most recent call last):
File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
"main", mod_spec)
File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/home/dawn-benchmark/tensorflow-qa-orig/bi-att-flow/basic/cli.py", line 112, in
tf.app.run()
File "/usr/local/lib/python3.6/dist-packages/tensorflow/python/platform/app.py", line 48, in run
_sys.exit(main(_sys.argv[:1] + flags_passthrough))
File "/home/dawn-benchmark/tensorflow-qa-orig/bi-att-flow/basic/cli.py", line 109, in main
m(config)
File "/home/dawn-benchmark/tensorflow-qa-orig/bi-att-flow/basic/main.py", line 24, in main
_train(config)
File "/home/dawn-benchmark/tensorflow-qa-orig/bi-att-flow/basic/main.py", line 83, in _train
models = get_multi_gpu_models(config)
File "/home/dawn-benchmark/tensorflow-qa-orig/bi-att-flow/basic/model.py", line 21, in get_multi_gpu_models
model = Model(config, scope, rep=gpu_idx == 0)
File "/home/dawn-benchmark/tensorflow-qa-orig/bi-att-flow/basic/model.py", line 68, in init
self._build_ema()
File "/home/dawn-benchmark/tensorflow-qa-orig/bi-att-flow/basic/model.py", line 298, in _build_ema
ema_op = ema.apply(tensors)
File "/usr/local/lib/python3.6/dist-packages/tensorflow/python/training/moving_averages.py", line 375, in apply
colocate_with_primary=(var.op.type in ["Variable", "VariableV2"]))
File "/usr/local/lib/python3.6/dist-packages/tensorflow/python/training/slot_creator.py", line 174, in create_zeros_slot
colocate_with_primary=colocate_with_primary)
File "/usr/local/lib/python3.6/dist-packages/tensorflow/python/training/slot_creator.py", line 149, in create_slot_with_initializer
dtype)
File "/usr/local/lib/python3.6/dist-packages/tensorflow/python/training/slot_creator.py", line 66, in _create_slot_var
validate_shape=validate_shape)
File "/usr/local/lib/python3.6/dist-packages/tensorflow/python/ops/variable_scope.py", line 1065, in get_variable
use_resource=use_resource, custom_getter=custom_getter)
File "/usr/local/lib/python3.6/dist-packages/tensorflow/python/ops/variable_scope.py", line 962, in get_variable
use_resource=use_resource, custom_getter=custom_getter)
File "/usr/local/lib/python3.6/dist-packages/tensorflow/python/ops/variable_scope.py", line 367, in get_variable
validate_shape=validate_shape, use_resource=use_resource)
File "/usr/local/lib/python3.6/dist-packages/tensorflow/python/ops/variable_scope.py", line 352, in _true_getter
use_resource=use_resource)
File "/usr/local/lib/python3.6/dist-packages/tensorflow/python/ops/variable_scope.py", line 682, in _get_single_variable
"VarScope?" % name)
ValueError: Variable model_1/loss/ExponentialMovingAverage/ does not exist, or was not created with tf.get_variable(). Did you mean to set reuse=None in VarScope?

It seems that the ExponentailMovingAverage doesn't help with the training processs. Disabling the related lines would solve this issue: https://github.com/stanford-futuredata/dawn-benchmark/blob/master/tensorflow_qa/bi-att-flow/basic/model.py#L299-L305
After resolving this issue, I also discovered a similar reuse-variable issue with the Adam Optimizer. It seems that there is an implicit global variable scope that's enforcing all the variables, including the ones created by the optimizers, to be reusable. Adding an explicit declaration of variable scope before the for-loop of gpu model creation would solve the issue:  https://github.com/stanford-futuredata/dawn-benchmark/blob/master/tensorflow_qa/bi-att-flow/basic/model.py#L17

hello:
I meet the same problem as you, but I don't understand your solution.
Which line did you disable to solve this issue? Can you say more details?
Thanks a lot!

Hey @distantJing:
Check this one:
https://github.com/kelayamatoz/bi-att-flow-lstm-extractor/blob/master/basic/model.py#L25-L36

Essentially you need to put the exponential smoothing variables into a different scope and make sure that each GPU gets a unique set of loss variables.

Dear Team,
I tried to train the model with 2 gpus using the following line:
/opt/python3/bin/python3 -m basic.cli --mode train --noload --debug --len_opt --batch_size 20 --num_gpus 2
Then I got an error:
ValueError: Attempt to have a second RNNCell use the weights of a variable scope that already has weights: 'prepro/u1/fw/basic_lstm_cell'; and the cell was not constructed as BasicLSTMCell(..., reuse=True).  To share the weights of an RNNCell, simply reuse it in your second calculation, or create a new one with the argument reuse=True.
What should I do ?

@kelayamatoz I found your repository
https://github.com/kelayamatoz/BiDAF-MultiGPU-Fix
And i ran it up on multi-gpus
Thanks a lot !

@chiahsuan156  i run the repository as your reffered https://github.com/kelayamatoz/BiDAF-MultiGPU-Fix,but i meet the same error as @dengyuning   do have you resolved it?


[Parent issue] Support for Apache Pulsar

Since there is a continious demand for it,
just an overview for current state of Support for Apache Pulsar:

when looking into beams i/o connector matrix pulsar is not listed yet:
https://beam.apache.org/documentation/io/connectors/

but there is a sdk package
Package org.apache.beam.sdk.io.pulsar
https://beam.apache.org/releases/javadoc/current/org/apache/beam/sdk/io/pulsar/package-summary.html

in v2.39 of beam a relatively basic pulsar io was introduced:
Implemented Apache PulsarIO https://beam.apache.org/blog/beam-2.39.0/
for details see:
https://issues.apache.org/jira/browse/BEAM-8218

there are some open issues in beam for pulsar:
https://github.com/apache/beam/issues?q=is%3Aissue+pulsar+is%3Aopen

#30688
#30152
#22054
#22027
#22025
#21714
#21560
#31079

there were also some non merged pull request marked as stale and automatically closed, which may be worth to have a look on
https://github.com/apache/beam/pulls?q=is%3Apr+pulsar+is%3Aclosed+label%3Astale

#26410
#22375
#22028
#22026
#17473
#16749

in general it would be a good longterm target, to reach the same quality of integration in Beam as there is for Kafka

Hey @hpvd - have you been able to make any progress on this issue? I agree that the current state of the IO isn't great right now, so there's some good contribution opportunity :)


Registering chain specific SignedExtensions

Currently the Polkadot registry logs warnings if the chain metadata contains unknown SignedExtensions. It appears that userExtensions can be passed into the setMetadata method however this is called in a number of places in txwrapper-core that don't allow us to do so. Do you have any thoughts on this?

Hey @jonnnnyw! Thanks for bringing this up. I personally don't see why txwrapper-core shouldn't support both signedExtensions, and userExtensions as option parameters to the various methods that use setMetadata.
I think point in case is polkadot-js's public API provides the userExtensions as a way to override any needed extensions within the metadata which can be seen in expandExtensionTypes here. That being said just to note, the api will still warn for any unknown userExtensions noted here.
@emostov @dvdplm, any thoughts.

Sounds good to me - and however the solution manifests we should have some docs with an example.
Just an idea, we could allow an optional param for the extensions when creating the metadata that will register extensions. But whatever we decide ideally it minimizes hard to debug issues (such as forgetting to register extensions in just one part of your code).

Setting up the metadata once (with any extensions the users wants) and then thread it through consistently sounds good but also like a big breaking change. For it to be beneficial we'd have to remove the possibility to add userExtensions everywhere (and signedExtensions as well? For consistency?) such that adding them when creating metadata is the only place where this can happen.
Sounds like it might be a bit too big of a change?

support both signedExtensions, and userExtensions as option parameters to the various methods that use setMetadata.

…so I think this is the better way to go. But yeah, open to dissenting opinions ofc!


Support linking static libs as an alternative to DLL import libs

When they are available, linking to static libs simplifies packaging/deployment, and it seems to be more common in Rust from what I've seen. The Microsoft.Web.WebView2 NuGet package for example supplies both a WebView2Loader.dll (with a WebView2Loader.dll.lib import lib) and WebView2LoaderStatic.lib. I'd like to be able to swap the static lib for the import lib to avoid needing to redistribute the DLL.
I don't know if this is the most appropriate way to implement it, but I have a prototype of Microsoft.Web.WebView2.winmd based on https://github.com/microsoft/win32metadata/pull/414 which uses WebView2LoaderStatic.lib instead of WebView2Loader.dll for the DllImport attributes. I'll link a draft PR I've got for this project which keys off of the .lib suffix to change the generated #[link] attribute and output a rustc directive in windows::build! to add the target directory to the linker search path. I also cloned the webview2 example as webview2-example to verify it works.

Hi Bill, I'm supportive of this but we'd need to drive this from the win32 metadata repo on whether and how to support static libs. It may be that a dedicated attribute may be more suitable to other languages rather than overloading the DllImport pseudo attribute.

Makes perfect sense, thanks. Keying off of the .lib suffix was just a proof of concept.

Closed thanks to #947


breaking: prepare for the next major version change

Summary by CodeRabbit

New Features

Introduced a new configuration file .coderabbit.yaml for project settings.
Added new functions for barcode reading and writing, including writeBarcodeFromBytes and purgeZXingModule.
Updated barcode processing functions to accept a broader range of input types.
Enhanced module preparation with new overloads for prepareZXingModule.
Added new constants for hash verification in global.d.ts.

Bug Fixes

Improved error handling in barcode reading functions.

Documentation

Enhanced clarity and consistency in README.md with updated installation instructions and function names.

Chores

Updated dependencies in package.json.
Modified build configuration in CMakeLists.txt.
Updated formatting configuration in .clang-format.

@coderabbitai configuration

@coderabbitai generate docstrings

https://github.com/coderabbitai generate docstrings

@coderabbitai generate docstrings

@coderabbit complete the changeset file.

@CodeRabbit complete the changeset file. Be sepcific and detailed. Add a full migration guide.


[Feature][Metrics] Seatunnel-Metrics

Search before asking

[X] I had searched in the feature and found no similar feature requirement.

Description
To build a seatunnel metrics system, the idea is to obtain task metrics through spark sink on&&flink reporter, and seatunnel processes the metrics in a unified manner, defines the interface in seatunnel to specify the seatunnel reporter rules, and the external system obtains the seatunnel parameters by implementing the interface.The following figure shows the process introduction:

Try to integrate the flink spark indicator style uniformly.
The main method of the interface void open() void stop() void report()
Working with configuration files   mission end command  metrics output method
Usage Scenario
When you need to view the running status of the seatunnel task and analyze the running efficiency, etc.
Related issues
No response
Are you willing to submit a PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

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

Great! Looking forward your contribute!


fix: Comparisons against scalar slices

Which issue does this PR close?
Closes 740.
Rationale for this change
Fixes comparisons against scalars on sliced arrays.
What changes are included in this PR?
Are there any user-facing changes?

Codecov Report

Merging #741 (cc39d1a) into master (34df13a) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #741   +/-   ##
=======================================
  Coverage   82.47%   82.47%
=======================================
  Files         168      168
  Lines       47690    47705   +15
=======================================
+ Hits        39330    39345   +15
  Misses       8360     8360

Impacted Files
Coverage Δ

arrow/src/compute/kernels/comparison.rs
95.20% <100.00%> (+0.12%)
:arrow_up:

Continue to review full report at Codecov.

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


decorator: Only URL-decode application/x-www-form-urlencoded requests

We previously parsed any request with method other than {GET, POST} and Content-Type other than multipart/form-data as if it were application/x-www-form-urlencoded.
Check that Content-Type is application/x-www-form-urlencoded before parsing the body that way. Restrict this logic to {DELETE, PATCH, PUT} (having a body at all doesn’t make sense for {CONNECT, HEAD, OPTIONS, TRACE}).
I verified that the libraries we care about all correctly send Content-Type: application/x-www-form-urlencoded automatically for {DELETE, PATCH, PUT}:

Python requests, given data as a dict
JavaScript fetch, given body as URLSearchParams
curl, given --data or --data-urlencode

Merged, thanks @andersk!


Move to the 21H1 Helix pool

The 19H1 pool is being decommissioned.

build is running w/ helix queuing

this actually worked!

@kmahone this is what you needed us to do, yeah?

@kmahone this is what you needed us to do, yeah?

Yes.


API page for bc2adls tool

It is also needed to rerun the export when it fails.
So you need the status and the possibility to start the export again. But also enable the fields again.
But also you can schedule it via Power Automate or Logic App or other tooling.

This is indeed a great way to automate the calling of most important functions on the ADLSE module. If the comments are too exhaustive, we could create the API page ourselves if you could please wait for an overall into the version 20 that we are undergoing on this app.

This is indeed a great way to automate the calling of most important functions on the ADLSE module. If the comments are too exhaustive, we could create the API page ourselves if you could please wait for an overall into the version 20 that we are undergoing on this app.

No problem to add the comments you have by myself. Just comment it and I will put it in.
Maybe it take a little bit longer because of the holiday season is almost there :)

@DuttaSoumya Do I need something on this pull request?

@DuttaSoumya I have split the API Page into two pages as discussed.

Few more comments

Changed your comments.
Waldo has created the site and AJ Kaufmann has created the site of the API guidelines.


[move-bytecode-util] Move ModuleCache to move-bytecode-util

Motivation
As promised in #9484 , I refactored ModuleCache to move-bytecode-util alogn with a sync and single thread version of ModuleCache.
Have you read the Contributing Guidelines on pull requests?
Yes

LEC dependency change summary:
target packages:
  A move-bytecode-utils 0.1.0 (workspace, path 'language/tools/move-bytecode-utils')
    * features: [none]

/land

:broken_heart: Test Failed - ci-test

/land


Update UI to display sample applications

Finalise once

[ ] parser classes are ready

Codecov Report

Merging #58 (fc67d51) into master (665bd1c) will decrease coverage by 7.91%.
The diff coverage is 10.21%.

 Learn more