Update the DSWx-HLS SAS for cal/val release

This PR updates the DSWx-HLS SAS after the mid-May point release:

Populate DSWx-HLS metadata fields dem_file, landcover_file, and worldcover_file.
(TODO) Add DSWx-HLS metadata to all DSWx-HLS product layers.

Hi @gshiroma, I noticed another discrepancy in the DSWx-HLS metadata regarding the SENSING_TIME field. It seems like for L30 datasets the field is set with both a beginning and end time, delimited by semi-colon:
>>> from osgeo import gdal
>>> ds = gdal.Open(".../output_dir/OPERA_L3_DSWx_HLS_LANDSAT-8_T22VEQ_20210905T143156_v2.0_001_B01_WTR.tif")
>>> ds.GetMetadata()['SENSING_TIME']
'2021-09-05T14:31:56.9300799Z; 2021-09-05T14:32:20.8126470Z'

This is fine, as we want a begin/end time to put into the output ISO XML.
However, for an S30 dataset, only a single time is available:
>>> ds = gdal.Open(".../output_dir/OPERA_L3_DSWx_HLS_SENTINEL-2A_T15SXR_20210907T163901_v2.0_001_B01_WTR.tif")
>>> ds.GetMetadata()['SENSING_TIME']
'2021-09-07T16:54:47.751044Z'

Is this the expected behavior for S30 datasets, or possibly a bug?

Hi @gshiroma, I noticed another discrepancy in the DSWx-HLS metadata regarding the SENSING_TIME field. It seems like for L30 datasets the field is set with both a beginning and end time, delimited by semi-colon:
>>> from osgeo import gdal
>>> ds = gdal.Open(".../output_dir/OPERA_L3_DSWx_HLS_LANDSAT-8_T22VEQ_20210905T143156_v2.0_001_B01_WTR.tif")
>>> ds.GetMetadata()['SENSING_TIME']
'2021-09-05T14:31:56.9300799Z; 2021-09-05T14:32:20.8126470Z'

This is fine, as we want a begin/end time to put into the output ISO XML.
However, for an S30 dataset, only a single time is available:
>>> ds = gdal.Open(".../output_dir/OPERA_L3_DSWx_HLS_SENTINEL-2A_T15SXR_20210907T163901_v2.0_001_B01_WTR.tif")
>>> ds.GetMetadata()['SENSING_TIME']
'2021-09-07T16:54:47.751044Z'

Is this the expected behavior for S30 datasets, or possibly a bug?

Hi @collinss-jpl , thank you so much again for reporting this. Good point, the metadata field SENSING_TIME is imported from the input HLS product and, as you also pointed out, they differ between L30 and S30 datasets. I'll make sure to make them consistent. I'll probably keep the original value for S30 datasets and I'll take the average value for L30 datasets. Thanks again.

Hi @gshiroma, I noticed another discrepancy in the DSWx-HLS metadata regarding the SENSING_TIME field. It seems like for L30 datasets the field is set with both a beginning and end time, delimited by semi-colon:
>>> from osgeo import gdal
>>> ds = gdal.Open(".../output_dir/OPERA_L3_DSWx_HLS_LANDSAT-8_T22VEQ_20210905T143156_v2.0_001_B01_WTR.tif")
>>> ds.GetMetadata()['SENSING_TIME']
'2021-09-05T14:31:56.9300799Z; 2021-09-05T14:32:20.8126470Z'

This is fine, as we want a begin/end time to put into the output ISO XML.
However, for an S30 dataset, only a single time is available:
>>> ds = gdal.Open(".../output_dir/OPERA_L3_DSWx_HLS_SENTINEL-2A_T15SXR_20210907T163901_v2.0_001_B01_WTR.tif")
>>> ds.GetMetadata()['SENSING_TIME']
'2021-09-07T16:54:47.751044Z'

Is this the expected behavior for S30 datasets, or possibly a bug?

Just created an issue #23 to address this comment. Thanks.

Hi @gshiroma, I noticed another discrepancy in the DSWx-HLS metadata regarding the SENSING_TIME field. It seems like for L30 datasets the field is set with both a beginning and end time, delimited by semi-colon:
>>> from osgeo import gdal
>>> ds = gdal.Open(".../output_dir/OPERA_L3_DSWx_HLS_LANDSAT-8_T22VEQ_20210905T143156_v2.0_001_B01_WTR.tif")
>>> ds.GetMetadata()['SENSING_TIME']
'2021-09-05T14:31:56.9300799Z; 2021-09-05T14:32:20.8126470Z'

This is fine, as we want a begin/end time to put into the output ISO XML.
However, for an S30 dataset, only a single time is available:
>>> ds = gdal.Open(".../output_dir/OPERA_L3_DSWx_HLS_SENTINEL-2A_T15SXR_20210907T163901_v2.0_001_B01_WTR.tif")
>>> ds.GetMetadata()['SENSING_TIME']
'2021-09-07T16:54:47.751044Z'

Is this the expected behavior for S30 datasets, or possibly a bug?

Hi @collinss-jpl , commit 602fc35 fixes this issue. Thank you again for reporting it.

Hi @hfattahi, @collinss-jpl , and @nemo794 . This PR is ready to be reviewed. Sorry for the delay. I was making sure we were addressing all known code issues before this cal/val delivery.

@gshiroma When I ran build_docker_image.sh on aurora this afternoon, tests/test_dswx_hls_workflow.py failed with a 'Temporary failure in name resolution' error:
>           raise ConnectionError(e, request=request)
E           requests.exceptions.ConnectionError: HTTPSConnectionPool(host='zenodo.org', port=443): Max retries exceeded with url: /record/
6819971/files/s30_louisiana_mississippi.tar.gz (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f24a7600190>: Fail
ed to establish a new connection: [Errno -3] Temporary failure in name resolution'))

/opt/conda/lib/python3.9/site-packages/requests/adapters.py:565: ConnectionError
------------------------------------------------------------- Captured stdout call --------------------------------------------------------------

Test dataset s30_louisiana_mississippi not found. Downloading file https://zenodo.org/record/6819971/files/s30_louisiana_mississippi.tar.gz.
============================================================ short test summary info ============================================================

FAILED tests/test_dswx_hls_workflow.py::test_workflow - requests.exceptions.ConnectionError: HTTPSConnectionPool(host='zenodo.org', port=443):...

========================================================== 1 failed, 1 passed in 5.59s ==========================

There were several of these errors; the above is the last one.  I first verified that the zenodo.org URL was OK.  Then I remembered that a similar error had occurred when I built the CSLC_S1 docker image on aurora last month.  The problem then and today was that 'docker run' was unable to resolve DNS hostnames.  There are several possible solutions, but a simple fix is to add the option '--network host' to the 'docker run' command in build_docker_image.sh, such as in
docker run --rm -u "$(id -u):$(id -g)" -v "$PWD:/mnt" -w /mnt -it --network host "${IMAGE}:$t" pytest /mnt/tests/

This option tells docker to have the host (aurora) perform DNS lookups.  After making the above change, I was able to build the docker image and successfully test it with the Greenland and Louisiana data sets.
Some of the other possible solutions require root privileges, e.g., rebooting the system or modifying various system files.  Aurora itself hasn't been rebooted for several months.  However, rebooting it or modifying its system files isn't a practical option for us.  It's also not clear why docker sometimes loses the ability to resolve hostnames.

Next batch of suggestions, all very small.

Thank you so much for all the suggestions, @nemo794 ! I don't see any critical change for now. I'll leave all comments here so we can address each of them in the next PR. Once you are done reviewing this PR, if you don't see anything critical, I'd ask you to please approve this PR so we can have it merged for this cal/val delivery.

Thank you so much, @nemo794 ! I looked at all the comments. You caught so many things! All comments are very helpful, and I'll make sure to address all of them in the next release.
I didn't find anything critical for this cal/val delivery. Since the current code was tested by @jshimada47 , @collinss-jpl , and me, I'd prefer to update the code now.
Would it be ok to defer these changes to the next delivery? I can create an issue to make sure we'll address these comments. Is that ok, @hfattahi ?
If you see anything critical please let me know.

Code changes look good to me from a PGE perspective, and I was able to create the image from this branch and run a PGE integration test without issues, so this looks good-to-go from my end.

Thank you so much, @collinss-jpl . I appreciate you taking the time to test this code for PGE integration.

This PR is approved so that it can be merged for the cal-val point release. As discussed, there is nothing critical for this release, and so the comments will need to be opened in a new issue and be addressed in the next release. Thanks again, Gustavo!

Thank you so much, @nemo794, for your in-depth review! I created issue #24 to make sure that we'll address all your comments.
@hfattahi , do you think we can merge this PR?

Hi again @gshiroma, sorry to say but I have another finding that needs to be addressed before this branch is merged. It looks like the PRODUCT_VERSION constant in the code has not been updated to match the version tags getting used with github: see https://github.com/nasa/PROTEUS/blob/main/src/proteus/dswx_hls.py#L2141 where the version is still set to 0.1, whereas the version used for the "mid_may" release is 0.3.
Since the PGE extracts this version from the tiff metadata for the output filenames, its very important that these versions are kept in sync. The PST team in particular is concerned with leveraging this version number so they can track any changes made to HLS parameters, etc...

Hi again @gshiroma, sorry to say but I have another finding that needs to be addressed before this branch is merged. It looks like the PRODUCT_VERSION constant in the code has not been updated to match the version tags getting used with github: see https://github.com/nasa/PROTEUS/blob/main/src/proteus/dswx_hls.py#L2141 where the version is still set to 0.1, whereas the version used for the "mid_may" release is 0.3, and I'm guessing will become 0.4 for this CalVal release.
Since the PGE extracts this version from the tiff metadata for the output filenames, its very important that these versions are kept in sync. The PST team in particular is concerned with leveraging this version number so they can track any changes made to HLS parameters, etc...

Hi @collinss-jpl , thank you for your comment. The PRODUCT_VERSION is not related to the PROTEUS tag. We are still reviewing how we are going to number the PRODUCT_VERSION.

Hi again @gshiroma, sorry to say but I have another finding that needs to be addressed before this branch is merged. It looks like the PRODUCT_VERSION constant in the code has not been updated to match the version tags getting used with github: see https://github.com/nasa/PROTEUS/blob/main/src/proteus/dswx_hls.py#L2141 where the version is still set to 0.1, whereas the version used for the "mid_may" release is 0.3, and I'm guessing will become 0.4 for this CalVal release.
Since the PGE extracts this version from the tiff metadata for the output filenames, its very important that these versions are kept in sync. The PST team in particular is concerned with leveraging this version number so they can track any changes made to HLS parameters, etc...

Hi @collinss-jpl , thank you for your comment. The PRODUCT_VERSION is not related to the PROTEUS tag. We are still reviewing how we are going to number the PRODUCT_VERSION.

@gshiroma I see, here's a little more background on a potential problem raised by PST in a tag-up we just had. They want to make sure they have a way to easily determine which output products are associated with the default HLS thresholds defined here. If, hypothetically, ADT decides that these defaults are to change, could we expect that PRODUCT_VERSION would be incremented to indicate as such?

Hi again @gshiroma, sorry to say but I have another finding that needs to be addressed before this branch is merged. It looks like the PRODUCT_VERSION constant in the code has not been updated to match the version tags getting used with github: see https://github.com/nasa/PROTEUS/blob/main/src/proteus/dswx_hls.py#L2141 where the version is still set to 0.1, whereas the version used for the "mid_may" release is 0.3, and I'm guessing will become 0.4 for this CalVal release.
Since the PGE extracts this version from the tiff metadata for the output filenames, its very important that these versions are kept in sync. The PST team in particular is concerned with leveraging this version number so they can track any changes made to HLS parameters, etc...

Hi @collinss-jpl , thank you for your comment. The PRODUCT_VERSION is not related to the PROTEUS tag. We are still reviewing how we are going to number the PRODUCT_VERSION.

@gshiroma I see, here's a little more background on a potential problem raised by PST in a tag-up we just had. They want to make sure they have a way to easily determine which output products are associated with the default HLS thresholds defined here. If, hypothetically, ADT decides that these defaults are to change, could we expect that PRODUCT_VERSION would be incremented to indicate as such?

HI @collinss-jpl , yes, this is still under discussion. There could be changes to HLS thresholds, the product itself (e.g., metadata fields/layers/structure), and the inputs (DEM, land cover, etc.). We are considering making this field a parameter of the runconfig, so the PGE would set the product version. But we haven't come to any decision now. Do you have any thoughts/suggestions?

Hi again @gshiroma, sorry to say but I have another finding that needs to be addressed before this branch is merged. It looks like the PRODUCT_VERSION constant in the code has not been updated to match the version tags getting used with github: see https://github.com/nasa/PROTEUS/blob/main/src/proteus/dswx_hls.py#L2141 where the version is still set to 0.1, whereas the version used for the "mid_may" release is 0.3, and I'm guessing will become 0.4 for this CalVal release.
Since the PGE extracts this version from the tiff metadata for the output filenames, its very important that these versions are kept in sync. The PST team in particular is concerned with leveraging this version number so they can track any changes made to HLS parameters, etc...

Hi @collinss-jpl , thank you for your comment. The PRODUCT_VERSION is not related to the PROTEUS tag. We are still reviewing how we are going to number the PRODUCT_VERSION.

@gshiroma I see, here's a little more background on a potential problem raised by PST in a tag-up we just had. They want to make sure they have a way to easily determine which output products are associated with the default HLS thresholds defined here. If, hypothetically, ADT decides that these defaults are to change, could we expect that PRODUCT_VERSION would be incremented to indicate as such?

HI @collinss-jpl , yes, this is still under discussion. There could be changes to HLS thresholds, the product itself (e.g., metadata fields/layers/structure), and the inputs (DEM, land cover, etc.). We are considering making this field a parameter of the runconfig, so the PGE would set the product version. But we haven't come to any decision yet. Do you have any thoughts/suggestions?

Ultimately I think it should be up to ADT when and why the version is incremented, so I think specifying it in the RunConfig is not the way to go.
The main goal is to establish the traceability such that the product version in the output filenames clearly indicates what revision/delivery/configuration of the SAS was used. That was why I thought it should be connected with the release tag version. As long as that traceability is maintained or documented somewhere I think we'll be able to keep the PST team satisfied.

Hi again @gshiroma, sorry to say but I have another finding that needs to be addressed before this branch is merged. It looks like the PRODUCT_VERSION constant in the code has not been updated to match the version tags getting used with github: see https://github.com/nasa/PROTEUS/blob/main/src/proteus/dswx_hls.py#L2141 where the version is still set to 0.1, whereas the version used for the "mid_may" release is 0.3, and I'm guessing will become 0.4 for this CalVal release.
Since the PGE extracts this version from the tiff metadata for the output filenames, its very important that these versions are kept in sync. The PST team in particular is concerned with leveraging this version number so they can track any changes made to HLS parameters, etc...

Hi @collinss-jpl , thank you for your comment. The PRODUCT_VERSION is not related to the PROTEUS tag. We are still reviewing how we are going to number the PRODUCT_VERSION.

@gshiroma I see, here's a little more background on a potential problem raised by PST in a tag-up we just had. They want to make sure they have a way to easily determine which output products are associated with the default HLS thresholds defined here. If, hypothetically, ADT decides that these defaults are to change, could we expect that PRODUCT_VERSION would be incremented to indicate as such?

HI @collinss-jpl , yes, this is still under discussion. There could be changes to HLS thresholds, the product itself (e.g., metadata fields/layers/structure), and the inputs (DEM, land cover, etc.). We are considering making this field a parameter of the runconfig, so the PGE would set the product version. But we haven't come to any decision yet. Do you have any thoughts/suggestions?

Ultimately I think it should be up to ADT when and why the version is incremented, so I think specifying it in the RunConfig is not the way to go.
The main goal is to establish the traceability such that the product version in the output filenames clearly indicates what revision/delivery/configuration of the SAS was used. That was why I thought it should be connected with the release tag version. As long as that traceability is maintained or documented somewhere I think we'll be able to keep the PST team satisfied.

Yes, that's a good point, @collinss-jpl . We are just not sure how to describe changes in the product because of updates in the PCM/PGE (including changes in the runconfig parameters populated by the PGE), or updates in any of the inputs, i.e., HLS product with a different version (e.g., v2.1), or updates to the DEM or landcover, for example. Another option is to divide the product version in two parts, one populated by the DSWx-HLS SAS and another by the PGE through the runconfig. Something like v.1.0.1, where 1.0 could come from DSWx-HLS SAS and 1 from the PGE.
Any thoughts @hfattahi ?

Hi again @gshiroma, sorry to say but I have another finding that needs to be addressed before this branch is merged. It looks like the PRODUCT_VERSION constant in the code has not been updated to match the version tags getting used with github: see https://github.com/nasa/PROTEUS/blob/main/src/proteus/dswx_hls.py#L2141 where the version is still set to 0.1, whereas the version used for the "mid_may" release is 0.3, and I'm guessing will become 0.4 for this CalVal release.
Since the PGE extracts this version from the tiff metadata for the output filenames, its very important that these versions are kept in sync. The PST team in particular is concerned with leveraging this version number so they can track any changes made to HLS parameters, etc...

Hi @collinss-jpl , thank you for your comment. The PRODUCT_VERSION is not related to the PROTEUS tag. We are still reviewing how we are going to number the PRODUCT_VERSION.

@gshiroma I see, here's a little more background on a potential problem raised by PST in a tag-up we just had. They want to make sure they have a way to easily determine which output products are associated with the default HLS thresholds defined here. If, hypothetically, ADT decides that these defaults are to change, could we expect that PRODUCT_VERSION would be incremented to indicate as such?

HI @collinss-jpl , yes, this is still under discussion. There could be changes to HLS thresholds, the product itself (e.g., metadata fields/layers/structure), and the inputs (DEM, land cover, etc.). We are considering making this field a parameter of the runconfig, so the PGE would set the product version. But we haven't come to any decision yet. Do you have any thoughts/suggestions?

Ultimately I think it should be up to ADT when and why the version is incremented, so I think specifying it in the RunConfig is not the way to go.
The main goal is to establish the traceability such that the product version in the output filenames clearly indicates what revision/delivery/configuration of the SAS was used. That was why I thought it should be connected with the release tag version. As long as that traceability is maintained or documented somewhere I think we'll be able to keep the PST team satisfied.

Yes, that's a good point, @collinss-jpl . We are just not sure how to describe changes in the product because of updates in the PCM/PGE (including changes in the runconfig parameters populated by the PGE), or updates in any of the inputs, i.e., HLS product with a different version (e.g., v2.1), or updates to the DEM or landcover, for example. Another option is to divide the product version in two parts, one populated by the DSWx-HLS SAS and another by the PGE through the runconfig. Something like v.1.0.1, where 1.0 could come from DSWx-HLS SAS and 1 from the PGE.
Any thoughts @hfattahi ?

@collinss-jpl and @gshiroma thanks for pointing this out. I agree with @gshiroma that the productVersion is not only the software version. I think "the algorithm software", "the inputs including ancillary" and "SDS version" should contribute to the product version. If the product is regenerated by a different SAS version, the different data version or different SDS version, I think the product version should be different. Of coarse, the algorithm/software will be Major and others will be minor or patch in a semantic versioning scheme.

Thank you, @hfattahi . This is very helpful. Let's bring back this discussion in our next meeting.

@rtburns-jpl , we got 3 approvals, but the merging is still blocked. It seems that the issue is that reviewers don't have "write access." Any ideas?

Hmm, thank you for the heads up. I will look into this.

Hmm, thank you for the heads up. I will look into this.

Thank you, @rtburns-jpl

@hfattahi It looks like we're currently unable to merge this. I haven't heard back yet but I expect we will need to request write access, which might require a couple days to be approved. Is there an alternate way we can provide this delivery?

@rtburns-jpl @gshiroma This is unfortunate. Is it possible to make a Docker image from Gustavo's branch?

Could it be anything related to the PR wad originated from the repo in the opera-adt org before moving it to NASA org?
Can you guys open a dummy PR and see if we have permission for that to merge?

It's easy to make a docker image locally, just run the build_docker_image.sh script.

@rtburns-jpl and @hfattahi , we created the Docker image locally. The biggest issue is the tagging that we provide in our documentation. We have two options, we either provide the tag as if existed or provide a tag from my own branch.

Uhm, it looks like I don't have permissions to tag a release =/

@rtburns-jpl , you probably would be able to do that (i.e. tag the release) for us. I guess you have write access, right? I wonder if there's anyone else on the team that also have write access so we can have two approvals and have this PR merged.

For the documentation can we use PR#. let's clarify the issue we are facing in the release notes. Make it clear that this release is made from your branch because of lack of admin permission on this repo. As soon as we get permission on our repo we will make a quick point release

For the documentation can we use PR#. let's clarify the issue we are facing in the release notes. Make it clear that this release is made from your branch because of lack of admin permission on this repo. As soon as we get permission on our repo we will make a quick point release

Sounds good, @hfattahi . I just created this release: https://github.com/gshiroma/PROTEUS/releases/tag/v0.4 .  @jshimada47 , I think we'll have to use that release for the documents =/

OK, I'll update the URLs in the documents.
Do you also want me to create an issue for product_version?  I'll just reference the comments in this PR.

OK, I'll update the URLs in the documents.
Do you also want me to create an issue for product_version? I'll just reference the comments in this PR.

Thank you, @jshimada47 . I wrote a draft note in the delivery summary. Please feel free to improve the text. Yes, that's a good idea to create the issue. I can do that now to save you time. Thanks!


security vulnerability detected while using deploy to heroku

Expected outcome:
Deploy to Heroku works and I can start logging hours.
     To protect your application you must take action. Your application
 !     is currently exposing its credentials via an easy to exploit directory
 !     traversal.
 !
 !          To read more about this security vulnerability please refer to this blog post:
 !     https://blog.heroku.com/rails-asset-pipeline-vulnerability
 !
 !     Push rejected, failed to compile Ruby app.
 !     Push failed

You're right. We haven't done any maintenance or updates to application in quite a while. We know some dependencies have some security vulnerabilities in them. Feel free to fix them and open up a PR :)

One fix for this would be #425


Cannot include libraries

I'm trying to include the drawing library from google.
I'm using vuejs and loading the google-maps-api with the gmaps-loader works fine, but I can't use the drawing library. My approach is:
import {Loader, LoaderOptions} from 'google-maps';
const loader = new Loader('API_KEY, options);
const options = ({libraries:"drawing"})

...

async test(){
            const google = await loader.load();
            const map = new google.maps.Map(document.getElementById('map'), {
                center: {lat: -34.397, lng: 150.644},
                zoom: 8,
            });
            var drawingManager = new google.maps.drawing.DrawingManager();
            drawingManager.setMap(map);

      }

When executing test(), I get the error:
 Error in v-on handler (Promise/async): "TypeError: Cannot read property 'DrawingManager' of undefined"
My guess is that the library is not loaded from google. How do I define const options properly so that it's loaded?
Thanks

Libraries should be an array libraries: ["drawing"]

Do you mean like that? :
    const loader = new Loader('AIzaSyB7JPzGq6_HCUfmc9WNU3kMg4eZIttxP_0',options);
    const options = {libraries: ["drawing"]};`

Like this, I still get the error. I should add that this project does not use typescript.

@davidkudera  Any idea? :)

Did you try to switch the two lines? First, define options and then loader:
const options = {libraries: ["drawing"]};
const loader = new Loader('API_KEY', options);

I would say that options will be undefined in your example because it's defined after it is used.

@davidkudera Thanks. It works now. I feel so dumb for missing the obvious, first define, then use. :)

@kevinunger no need to feel this way, something like this happened to all of us :wink:


uv 0.2.6 broke editable installs in a local folder

MRE:
git clone --depth 1 https://github.com/dagster-io/dagster.git
cd dagster/python_modules
uv pip install -e dagster -e dagster-pipes

on uv 0.2.5:
(dagster-3.11.7) dgibson@MacBook-Pro python_modules % uv pip install -e dagster -e dagster-pipes
Resolved 44 packages in 529ms
   Built dagster @ file:///Users/dgibson/dagster/python_modules/dagster
   Built dagster-pipes @ file:///Users/dgibson/dagster/python_modules/dagster-pipes                                                                                Downloaded 2 packages in 589ms
Uninstalled 2 packages in 2ms
Installed 2 packages in 1ms
 - dagster==1!0+dev (from file:///Users/dgibson/dagster/python_modules/dagster)
 + dagster==1!0+dev (from file:///Users/dgibson/dagster/python_modules/dagster)
 - dagster-pipes==1!0+dev (from file:///Users/dgibson/dagster/python_modules/dagster-pipes)
 + dagster-pipes==1!0+dev (from file:///Users/dgibson/dagster/python_modules/dagster-pipes)

On uv 0.2.6:
(dagster-3.11.7) dgibson@MacBook-Pro python_modules % uv pip install -e dagster -e dagster-pipes
error: Editable `dagster` must refer to a local directory

Thanks, taking a look.

Apologies, you can do uv pip install -e ./dagster -e ./dagster-pipes. I thought I had tested that pip also required a path separator for this. Will fix.

I actually wonder if pip will disallow this in the future... Because pip install dagster does not install ./dagster.

Fixed in https://github.com/astral-sh/uv/pull/3995.

Thanks! We'll add the path separator either way, seems more explicit if nothing else.

I think that's smart -- it's the most forwards-compatible.


After introducing custom user_path delete image does not work

Hey blueimp.
You have created awsome code, but I have an issue.
I have introduced a custom path to which files are uploaded and slightly changed the get_user_path the UploadHandler class. Upload works fine, but delte does not work.
Any idea ?
Many Thanks!
protected function get_user_path() {
if ($this->options['user_dirs']) {
return $this->get_user_id().'/';
}
return $this->objectid.'/';
}

Hi @startupper73,
get_user_path() is used by get_upload_path which in turn is used by the delete method:
https://github.com/blueimp/jQuery-File-Upload/blob/53992c2ddf43b0f43465d1a55c64d8ca02657118/server/php/UploadHandler.php#L1452-L1474
You probably wanna specifically debug this line here:
https://github.com/blueimp/jQuery-File-Upload/blob/53992c2ddf43b0f43465d1a55c64d8ca02657118/server/php/UploadHandler.php#L1460
Please also see #2190


Hi cleberz! You got the wrong project, please direct your PRs to wg/scrypt instead of my fork.

Hello @bannmann , I merged it intentionally to yours as I couldn't figure out how to issue a PR on top of your PR at https://github.com/wg/scrypt/pull/33 . Is such thing possible in Github? (I want to make sure I'm not getting credit for your code since mine is based off yours).
Thanks


add Github social login

working on 1.0.0-dev branch
based on Web Application Flow

[x] implement prototype code
[x] check with normal account
[x] check with 2FA enabled account


[DOCS] Fix grammatical errors in README file and Introduce License section

I want to fix the typos and grammatical errors in the README file and also want to introduce a LICENSE section showing the license in which the repository is licensed.
Here "for core work" will be replaced by "for the core work"

Kindly assign me this issue.

Hi @singodiyashubham87 - we have a license defined at an organisation level here: https://github.com/ministryofjustice/.github/blob/main/LICENSE
However, it's probably worth us making this clearer to contributors.

@dms1981 Still there are typos that need to be fixed, Kindly assign me this issue so that I can fix them.


Star "*" notation in Cargo.toml is not picking the correct dependency version

I just tried to compile the contract with the following Cargo.toml:
[package]
name = "fungible-token"
version = "0.1.0"
authors = ["Near Inc<EMAIL_ADDRESS>edition = "2018"

[lib]
crate-type = ["cdylib", "rlib"]

[dependencies]
serde = { version = "*", features = ["derive"] }
serde_json = "*"
near-sdk = "0.9.2"
borsh = "*"
wee_alloc = { version = "0.4.5", default-features = false, features = [] }

And received the following error:
warning: build failed, waiting for other jobs to finish...
error[E0277]: the trait bound `near_sdk::collections::map::Map<std::vec::Vec<u8>, u128>: borsh::ser::BorshSerialize` is not satisfied
  --> fungible-token/src/lib.rs:23:28
   |
23 | #[derive(BorshDeserialize, BorshSerialize)]
   |                            ^^^^^^^^^^^^^^ the trait `borsh::ser::BorshSerialize` is not implemented for `near_sdk::collections::map::Map<std::vec::Vec<u8>, u128>`
   |
help: trait impl with same name found
  --> /Users/maksymzavershynskyi/.cargo/registry/src/github.com-1ecc6299db9ec823/near-sdk-0.9.2/src/collections/map.rs:14:10
   |
14 | #[derive(BorshSerialize, BorshDeserialize)]
   |          ^^^^^^^^^^^^^^
   = note: perhaps two different versions of crate `borsh` are being used?
   = help: see issue #48214
   = help: add `#![feature(trivial_bounds)]` to the crate attributes to enable
   = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `near_sdk::collections::map::Map<std::vec::Vec<u8>, u128>: borsh::de::BorshDeserialize` is not satisfied
  --> fungible-token/src/lib.rs:23:10
   |
23 | #[derive(BorshDeserialize, BorshSerialize)]
   |          ^^^^^^^^^^^^^^^^ the trait `borsh::de::BorshDeserialize` is not implemented for `near_sdk::collections::map::Map<std::vec::Vec<u8>, u128>`
   |
help: trait impl with same name found
  --> /Users/maksymzavershynskyi/.cargo/registry/src/github.com-1ecc6299db9ec823/near-sdk-0.9.2/src/collections/map.rs:14:26
   |
14 | #[derive(BorshSerialize, BorshDeserialize)]
   |                          ^^^^^^^^^^^^^^^^
   = note: perhaps two different versions of crate `borsh` are being used?
   = help: see issue #48214
   = help: add `#![feature(trivial_bounds)]` to the crate attributes to enable
   = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `near_sdk::collections::map::Map<std::vec::Vec<u8>, Account>: borsh::ser::BorshSerialize` is not satisfied
  --> fungible-token/src/lib.rs:58:28
   |
58 | #[derive(BorshDeserialize, BorshSerialize)]
   |                            ^^^^^^^^^^^^^^ the trait `borsh::ser::BorshSerialize` is not implemented for `near_sdk::collections::map::Map<std::vec::Vec<u8>, Account>`
   |
help: trait impl with same name found
  --> /Users/maksymzavershynskyi/.cargo/registry/src/github.com-1ecc6299db9ec823/near-sdk-0.9.2/src/collections/map.rs:14:10
   |
14 | #[derive(BorshSerialize, BorshDeserialize)]
   |          ^^^^^^^^^^^^^^
   = note: perhaps two different versions of crate `borsh` are being used?
   = help: see issue #48214
   = help: add `#![feature(trivial_bounds)]` to the crate attributes to enable
   = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `near_sdk::collections::map::Map<std::vec::Vec<u8>, Account>: borsh::de::BorshDeserialize` is not satisfied
  --> fungible-token/src/lib.rs:58:10
   |
58 | #[derive(BorshDeserialize, BorshSerialize)]
   |          ^^^^^^^^^^^^^^^^ the trait `borsh::de::BorshDeserialize` is not implemented for `near_sdk::collections::map::Map<std::vec::Vec<u8>, Account>`
   |
help: trait impl with same name found
  --> /Users/maksymzavershynskyi/.cargo/registry/src/github.com-1ecc6299db9ec823/near-sdk-0.9.2/src/collections/map.rs:14:26
   |
14 | #[derive(BorshSerialize, BorshDeserialize)]
   |                          ^^^^^^^^^^^^^^^^
   = note: perhaps two different versions of crate `borsh` are being used?
   = help: see issue #48214
   = help: add `#![feature(trivial_bounds)]` to the crate attributes to enable
   = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to 4 previous errors

For more information about this error, try `rustc --explain E0277`.
error: could not compile `fungible-token`.

To learn more, run the command again with --verbose.

Notice that it complains about borsh version being incompatible with whatever version we use in near-sdk-rs. It seems like "*" notation does not pick the correct compatible version. After I replaced borsh = "*"  with borsh = "0.6.1" it compiled successfully.

We need to remove "*" from all our examples and stop advising people to use "*" notation.  CC @mikedotexe
We should finish https://github.com/near/near-sdk-rs/issues/142 and re-export at least borsh. CC @frol

CC @evgenykuzyakov

Note, reproducibility of this issue might be hard, since it might depend on the local cargo cache.

@nearmax I got this same when upgrading dependencies in pow-faucet. @evgenykuzyakov advised me to delete Cargo.lock and rebuild, and that worked
Would it work here as well?

Re-export is mostly done. AFAIK, all the issues are resolved, but @evgenykuzyakov is busy finishing the contracts, so he said he would have the bandwidth only the next week (it sounded fine to me). “*” versioning is very conservative and it will indeed try to keep Cargo.lock with minimal changes if possible causing such mismatches.

@frol @nearmax @evgenykuzyakov I'm still not clear on if we actually want this.

“*” versioning is very conservative and it will indeed try to keep Cargo.lock with minimal changes if possible causing such mismatches.

Does this mean we should stop using it? Or is it a normal Rust workflow to delete Cargo.lock when these sorts of issues are encountered?

@frol @nearmax @evgenykuzyakov I'm still not clear on if we actually want this.

“*” versioning is very conservative and it will indeed try to keep Cargo.lock with minimal changes if possible causing such mismatches.

Does this mean we should stop using it? Or is it a normal Rust workflow to delete Cargo.lock when these sorts of issues are encountered?

We have recurrent complains from people copying one of our examples and getting obscure compilation errors as you have observed. This is because of "" notation. "" notation is not meant to "fix" the dependencies mismatch, and the reason why it was introduced is because we thought it was. So now that we have observed that it does not fix anything and causes obscure compilation errors we need to finish re-export, and finally fix this issue.

we need to finish re-export, and finally fix this issue

Sorry, still not quite understanding, but I think that's because I'm thinking about this from the perspective of other apps, such as any created with create-near-app
Will the "re-exporting" change you're making here in near-sdk-rs allow other apps to use the * syntax without issue?

Will the "re-exporting" change you're making here in near-sdk-rs allow other apps to use the * syntax without issue?

It will make "*" unnecessary.

Even better! Thanks for the clarification.

obsolete.


Clarify in NPL doc that nodeportlocal.antrea.io is not for users

The nodeportlocal.antrea.io Pod annotation is managed by Antrea. If
users provide or modify the annotation, it may be overwritten by Antrea
or have unexpected behavior.
Fixes #3272
Signed-off-by: Antonin Bas<EMAIL_ADDRESS>

/skip-all


merge with master

Current coverage is 19.56%

Merging #35 into patrick will increase coverage by +16.38% as of a36167e

@@            patrick     #35   diff @@
=======================================
  Files            24      86    +62
  Stmts           157     961   +804
  Branches          4      63    +59
  Methods           0
=======================================
+ Hit               5     188   +183
- Partial           0       5     +5
- Missed          152     768   +616

Review entire Coverage Diff as of a36167e

Powered by Codecov. Updated on successful CI builds.


Thumbnails with slides are not synced

Thumbnails with slides are not synced if width of the thumbnails are set to viewport or exceeds.
I am using the following code which does not work
var timeSlides = $('.timeline-slides');
        timeSlides.sliderPro({
            width: '100%',
            height: 500,
            thumbnailsPosition: 'top',
            visibleSize: '100%',
            forceSize: 'fullWidth',
            arrows: true,
            buttons: false,
            waitForLayers: false,
            thumbnailWidth: 80,
            thumbnailHeight: 36,
            thumbnailPointer: false,
            autoplay: false,
            autoScaleLayers: true,
            breakpoints: {
                767: {
                    thumbnailWidth: $(window).width(),
                    height:300,
                    thumbnailHeight: 50,
                    fadeArrows: false,
                }
            },

Hi. The thumbnails are not meant to be used that way, but there is an alternative solution. Please see this discussion: https://github.com/bqworks/slider-pro/issues/81
Cheers


Enums from macros issues

Problem descriptions
Issue 1: Consider the macro definition:
#define MY_MACRO_TEST3_1<PHONE_NUMBER>	// Int32.MaxValue

The resulting macro definition is:
public enum MyMacroTest3Enum1 : uint
{
    MY_MACRO_TEST3_1 =<PHONE_NUMBER>
}

Note that the underlying base type is set to a uint rather than an int because Library.GetUnderlyingTypeForEnumValue(ulong value) uniformly use less-than comparisons where less-or-equal comparisons were wanted/intended.
Issue 2: Consider the macro definition:
#define MY_MACRO_TEST3_2<PHONE_NUMBER>	// Int32.MaxValue + 1

The resulting macro definition is:
public enum MyMacroTest3Enum2 : sbyte
{
    MY_MACRO_TEST3_2 = 0
}

This result is due to the fact unless a literal type suffix (e.g. 'u') is present, the ExpressionEvaluator always attempts to parse numbers as an Int32. The method Library.ParseEnumItemMacroExpression eats the exception and sets the return value to zero with no hint that anything went wrong.
Issue 3: If you attempt to work around Issue 2 by using a type suffix as in:
#define MY_MACRO_TEST3_2<PHONE_NUMBER>u	// Int32.MaxValue + 1

the translator throws an InvalidCastException in Library.ParseEnumItemMacroExpression where it attempts to first cast the boxed object value returned by the ExpressionEvaluator to an int so that it can then cast it to a ulong. Since the actual boxed value returned from the ExpressionEvaluator is a uint, the cast fails.
Issue 4: Consider the macro definition:
#define MY_MACRO_TEST3_3    -101

If you attempt to convert this macro definition into an enum item, the translator converts it to:
public enum MyMacroTest3Enum3 : uint
{
    MY_MACRO_TEST3_3 =<PHONE_NUMBER>3709551515
}

Note that the ExpressionEvaluator handles negative numbers, but the GenerateEnumFromMacros  mechanism does not. In particular, Library.ParseEnumItemMacroExpression silently coerces the negative value to an unsigned long resulting in the value<PHONE_NUMBER>3709551515. Negative numbers are of course supported in C# enum items.
Note that the coerced result won't fit into a uint which is the underlying base type for the enum. That results in compile-time errors of the generated C#. The issue here is that Library.GetUnderlyingTypeForEnumValue types the value as a PrimitiveType.ULong rather than a PrimitiveType.ULongLong.
Proposed improvements:

Mimic the C# compiler when parsing numbers in ExpressionEvaluator.EvaluateNumber to implicitly type values. That is, in C# if you write
var x =<PHONE_NUMBER>;  // int.MaxValue + 1

'x' will be typed as uint. Extend ExpressionEvaluator to do the same.

Use Enumeration.BuiltinType / Enumeration.Type to track the underlying type of the enumeration while it is being populated. This allows us to support any primitive (numeric) type for enum values.

Use the type information described above when populating symbols provided to the ExpressionEvaluator so that symbol values are appropriately typed when used in expressions evaluated by the ExpressionEvaluator.

Add more care when casting from the boxed type returned from ExpressionEvaluator to the actual numeric type to avoid cast exceptions.

Fix issues in Library.GetUnderlyingTypeForEnumValue and add support for supplying a minimum value so that primitive types representing signed values are supported.

Use the Diagnostics.Warning mechanism to at least write something to the console if there are issues evaluating an expression.

More tests.

Thanks for all the fixes, and all the tests!


Eq3btsmart more reliable

Description:
Applying these changes makes eq3btsmart thermostat remember the temperature/operation mode set by the user.
During update (performed every minute) it performs a check if the current thermostat settings are the same as user wants them to. If not, temperature/operation mode are changed.
After applying the changes temperature/operation mode are set almost immediately in most cases, as update is performed after every set_temperature/set_operation_mode and repeated in case of failure 2 times.
Code was running on my local HA instance for about 1 week and everything was working much better than before.
Related issue (if applicable): fixes #11554
Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.github.io#<home-assistant.github.io PR number goes here>
Example entry for configuration.yaml (if applicable):

Checklist:

[x] The code change is tested and works locally.

If user exposed functionality or configuration variables are added/changed:

[x] Documentation added/updated in home-assistant.github.io

If the code communicates with devices, web services, or third-party tools:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[x] New dependencies have been added to the REQUIREMENTS variable (example).
[x] New dependencies are only imported inside functions that use them (example).
[x] New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[x] New files were added to .coveragerc.

If the code does not interact with devices:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[x] Tests have been added to verify that the new code works.

Current implementation is ok as it is only temporarily enforced.

@rytilahti I would be 👍 if we come up with our own bluetooth controller that enforces sequential access. Would just be a pain to make sure that all integrations use it 😞 makes integrations no longer generic.

Thanks @karlkar and @rytilahti for the work done on eq3bt in 0.64.0, the valves management is indeed much more reliable now.

It is all thanks to @karlkar, I was merely an observer here :-)


Cannot withdraw my Lumens from - https://accountviewer.stellar.org/

Hi,
Could someone please advise. I am trying to withdraw my Lumens from "accountviewer.stellar.org. However, it states that "you don't have enough to cover this transaction." Is there a minimum for withdrawals?
Thank you.
Soleri

I am having similar issue, trying to find an answer also

Yes, the minimum account balance is 1XLM plus you need like 0.001XLM to pay for fees.
If you want reclaim all funds and close the account, check this tool: https://stellar.expert/demolisher/public


Gulp src reference

I have extended the Configuration variables and used them to define the PATH. Like this we can just do changes to the paths at one point. So we can now change the source and destination paths easily.
I have also added a folder created by webstorm in the .gitignore.

In my opinion, this needs some clean-up.

intendation: 2 spaces
use join(var, 'tesxt') instead of  var+'text' (at least `var + 'text')

Yeah, I agree with @ludohenin. @aboeglin would you fix these two points. Otherwise it is ready to be merged! Thanks for the PR!

Agreed, my editor indented to 4 spaces, I'll fix it and use join() where appropriate. I'll try to do it tonight.

Also now that I think about it, I could also update the readme file in the Configuration section to briefly describe it.

Ok it should be good now !

Looks good to me! Thanks for the PR!


fix composer.json : invalid characters

fix composer.json : invalid characters when install depedency

good working


the checkbox is not visible for selection

I'm submitting a ...  (check one with "x")
[ x] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, post on Stackoverflow or Gitter

Current behavior
the checkbox is not visible for selection. it is added but invisible
Expected behavior
I need checkbox selection.
Reproduction of the problem

What is the motivation / use case for changing the behavior?

Please tell us about your environment:

Table version:
11.3.0

Angular version:
angular 5.x

Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

Language: [all | TypeScript 2.9.x| ES6/7 | ES5]

Hello @halilpolathalil,
Could you provide a stackblitz demo in order to help you with your issue?
Cheers!

Hello @halilpolathalil,
Could you provide a stackblitz demo in order to help you with your issue?
Cheers!

Hi again,
I fiure out that there is checkbox in the cell but the borderline and the tick is invisible. when I add borderline manually it was like in the picture. How can I do it is visible with css.

You can provide custom template cells which implements any kind of checkbox.
For example, I do use the official Angular Material library in order to provide custom checkboxes to my cell template.
<ng-template #columnButton2 let-row="row" let-value="value" let-isSelected="isSelected" let-onCheckboxChangeFn="onCheckboxChangeFn" ngx-datatable-cell-template>
   <mat-checkbox [disabled]="disabledInput" [color]="'accent'" [checked]="checkedInput" (change)="onCheckboxChangeFn.call(undefined, $event)"></mat-checkbox>
</ng-template>

You can check how to pass custom cell templates at the official docs.
Cheers!

After upgrading to ng-8.2  / ngx-datatable 15.0.2 i also suddenly found the checkbox was missing, despite that i was using custom template cells as recommended above.
I'm not sure exactly why the following fix helped, but changing the TemplateRef's static option from false to true made my custom template work.
BEFORE
@ViewChild('checkboxTpl', { static: false}) checkboxTpl: TemplateRef<any>;
AFTER
@ViewChild('checkboxTpl', { static: true }) checkboxTpl: TemplateRef<any>;

After upgrading to ng-8.2 / ngx-datatable 15.0.2 i also suddenly found the checkbox was missing, despite that i was using custom template cells as recommended above.
I'm not sure exactly why the following fix helped, but changing the TemplateRef's static option from false to true made my custom template work.
BEFORE
@ViewChild('checkboxTpl', { static: false}) checkboxTpl: TemplateRef<any>;
AFTER
@ViewChild('checkboxTpl', { static: true }) checkboxTpl: TemplateRef<any>;

This is caused by Angular 8 new behaviour of ViewChild and ContentChild decorator, you can chek them out at the official docs.

When static is not provided, uses query results to determine the timing of query resolution. If any query results are inside a nested view (such as *ngIf), the query is resolved after change detection runs. Otherwise, it is resolved before change detection runs.

In my case I'm not necesarily using structural directives like ngIf, ngFor in the custom template refs. e.g. my checkbox field is a simple mat-checkbox. I have another field which has a mat-icon with [ngClass]...in both cases i need to set static: true for the templates to work as expected (i.e. without, the checkbox is hidden, or the ngClass doesn't get applied in the mat-icon example).
According to this article :
"{ static: true } needs to be set when you want to access the ViewChild in ngOnInit".
I'm wondering if this explains why the ngx-datatable library to require static: true "in general", and if so, i'm inferring that would mean custom cell templates in ngx-datatable can't use structural directives, which sounds like a big limitation. However, at a quick glance I can't validate this concern --  i did a quick test and got an *ngIf directive to work in a cell template with static: true .. go figure!
I say all this just to leave some context for potential use cases / bugs that may come up... I actually can't make head or tails of why things are working as they do in this area.

To be honest, the static flag doesn't apply to only structural directives but how Angular handles lifecycle hooks.
I forgot to point out the official notes about this change due to future full Ivy support on Angular 9: https://angular.io/guide/static-query-migration

You can provide custom template cells which implements any kind of checkbox.
For example, I do use the official Angular Material library in order to provide custom checkboxes to my cell template.
<ng-template #columnButton2 let-row="row" let-value="value" let-isSelected="isSelected" let-onCheckboxChangeFn="onCheckboxChangeFn" ngx-datatable-cell-template>
   <mat-checkbox [disabled]="disabledInput" [color]="'accent'" [checked]="checkedInput" (change)="onCheckboxChangeFn.call(undefined, $event)"></mat-checkbox>
</ng-template>

You can check how to pass custom cell templates at the official docs.
Cheers!

It is not work. My checkbox template can not be applied. The checkbox style of ngx template is applied automatically. I cant Not change the style of checkbox.

I had the same issue. Sometime I need to use "ng-deep::" to be sure to override the CSS style.


Initiate some documentation

Closes #19
This PR starts some documentation for the repo.

I updated the main README file to include a list of the figures and tables, how to generate figures, the contents of the sample-info and palettes folders, and some brief instructions for using renv.
For the instructions on generating figures, I added some info about what folders store what to the main README, but then created a separate README in the scripts directory. In that README I broke it up into figure set up and then actually generating the figures and listed each script.
The instructions for using renv I copied directly from sc-data-integration. They probably don't need to be this detailed, but sometimes its helpful to have the reminders?

The other thing I did was take the time to standardize how we are naming the scripts for generating each figure. I updated them to be in the following format: <figure/table>_<letter/number>-<figure description with words separated by underscores>.R
I'm sure these docs will continue to change and get updated, but let me know if there is anything obvious I missed here.

I made sure to consistently use figures and tables throughout. I want to keep the list in order of how I expect them to be displayed/ discussed in the paper, so I like keeping it as all one list.
I removed the section in the renv about dependencies. I don't think we need that at this stage anyways.
I added a clarifying statement about the s3_files being ignored.
This should be ready for another look @sjspielman!


Unable to create new records.

Laravel Version: 5.4.12
PHP Version: 5.6.25
Database Driver & Version: MySQL 5.6.31

Description:
Currently, it is featured that you cannot create a new record unless you create a new instance of the model. So if you would like to create the class once and use it again and again to create new records, it is not possible, since it updates the old records based on the ID present in the model object itself.
Steps To Reproduce:
`<?php
/**

Created by PhpStorm.
User: Gary
Date: 19/02/17
Time: 9:11 AM
*/

namespace  App\Repositories\SHRD;
use App\Models\FormResponse;
class formResonsesData {
private $modelPipeline = null;
function __construct(FormResponse $formResponse) {
    $this -> modelPipeline = $formResponse;
}

function getCounts() {
    return $this -> modelPipeline -> all() -> count();
}

function insertResponseData ($responseArray) {
    $failedInsertions = false;
    foreach ($responseArray as $resonseSubmission) {
        $modelPipeline = $this -> modelPipeline;
        $modelPipeline -> email_address =  $resonseSubmission -> hidden -> email;
        foreach ($resonseSubmission -> answers as $item => $value) {
            $modelPipeline [(string)$item] = $value;
        }
        $failedInsertions = $failedInsertions && $modelPipeline -> save();
    }
    return !$failedInsertions;
}

}`

$failedInsertions = $failedInsertions && $modelPipeline -> save(['create' => true]);

@taylorotwell The closed issue #18000 has it's description here. Could you please let me know if I need to describe it more?

Well this is the intended behavior
I'd suggest that you change your code to something like:
        $modelPipeline = $this -> modelPipeline;
        $data = $resonseSubmission -> answers;
        $data['email_address'] = $resonseSubmission -> hidden -> email;
        $failedInsertions = $failedInsertions && $modelPipeline :: create($data);

Remember to add this to your FormResponse model:
protected $guarded = ['id'];

Id is your primary key, everything else will be mass assigned, this should do what you want and you won't need the foreach anymore..

Oh, I didn't know that.Thanks!


[Tx-builder] Unable to download tx batches on Firefox & Safari browsers

Description
Batch download action is not working correctly on these browsers.
Browsers tested: Chrome, Brave, Firefox, Safari & Edge
Steps to reproduce
On either safari or firefox browsers, go to tx-builder safe app, create a dummy batch and try to download it
Expected result
.json file downloaded as expected
Obtained result

Hey @JagoFigueroa , I was checking this bug in the scope of https://github.com/safe-global/safe-react-apps/pull/698 and it seems to due to a missing CSP header -> https://bugzilla.mozilla.org/show_bug.cgi?id=1365502 . this is the intended behavior and a way to circumvent it would be to add blob: in the frame-src response header as per suggested in https://stackoverflow.com/a/66902961/7365255 . This would be done on the infra side tho.


chore(deps): update terraform terraform-ibm-modules/cos/ibm to v8.3.0

This PR contains the following updates:

Package
Type
Update
Change

terraform-ibm-modules/cos/ibm (source)
module
minor
8.2.13 -> 8.3.0

Release Notes

terraform-ibm-modules/terraform-ibm-cos (terraform-ibm-modules/cos/ibm)
v8.3.0
Compare Source
Features

add support to scope resource keys to 'None' role (#626) (49cd08a)

v8.2.14
Compare Source
Bug Fixes

deps: update terraform terraform-ibm-modules/kms-all-inclusive/ibm to v4.13.1 (#630) (078cc08)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

:tada: This PR is included in version 7.18.3 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Added event page

My music concert page made using html and css

.
closes #224

mention the issue it closes in the required format

done @pranjay-poddar . please merge it into main

@ilhamansari mention the issue number in PR


formatting changes

This pull request primarily focuses on refactoring the CSS styles and HTML structure of various Vue components in the project. The changes are mainly centered around the extraction of common styles to a global CSS file and the adjustment of HTML structure and class assignments to better use these styles.
CSS Centralization:

src/assets/global.css: Added new CSS classes .tiles-container, .tiles-text, and .error-message for common styling across different components.
src/main.ts: Imported the global.css file to make the CSS classes available globally across the application.

CSS Removal:

src/components/BreakdownComponent.vue: Removed the .tiles-container CSS class from the component's scoped styles as it's now globally available.
src/components/CopilotChatViewer.vue: Removed the .tiles-container CSS class from the component's scoped styles as it's now globally available.
src/components/MetricsViewer.vue: Removed the .tiles-container CSS class from the component's scoped styles as it's now globally available.
src/components/SeatsAnalysisViewer.vue: Removed the .tiles-container CSS class from the component's scoped styles as it's now globally available.

HTML Structure Refactoring:

src/components/BreakdownComponent.vue: Applied the .tiles-text CSS class to the appropriate div elements and modified the paragraph (p) elements to use the .text-h4 class for styling.
src/components/CopilotChatViewer.vue: Applied the .tiles-text CSS class to the appropriate div elements and modified the paragraph (p) elements to use the .text-h4 class for styling.
src/components/MetricsViewer.vue: Applied the .tiles-text CSS class to the appropriate div elements and modified the paragraph (p) elements to use the .text-h4 class for styling.
src/components/SeatsAnalysisViewer.vue: Applied the .tiles-text CSS class to the appropriate div elements, modified the v-card-item to use the .d-flex, .justify-center, and .align-center classes for styling, and modified the paragraph (p) elements to use the .text-h4 class for styling.

Don't know how to center a text that spans across two lines :( Any ideas?

Thanks so much for the so due refactoring!
I am adding some spacing in the cards so the two-liners are centralized. Looking like below


added context in config

What is the purpose of this change? What does it change?
Added --context flag to odo config
Was the change discussed in an issue?
fixes https://github.com/openshift/odo/issues/1371

How to test changes?
odo config view --context <dir>
odo config set --context <dir> Ports 8080/TCP
odo config set --context <dir> Name Test
odo config unset --context <dir> Name

should work

/retest

/assign @kadel

There is PR related to this https://github.com/openshift/odo/pull/1554. So should I wait for that to get merged?

Is this still blocked on something?

do we need https://github.com/openshift/odo/blob/50bc582c37ac682c96850c3400b86bf730860eaa/pkg/odo/cli/config/unset.go#L62 for all odo config @kadel
due to this each odo config ... command takes a long time

/ok-to-test

/hold cancel

do we need
odo/pkg/odo/cli/config/unset.go
Line 62 in 50bc582
o.context = genericclioptions.NewContext(cmd)
for all odo config @kadel
due to this each odo config ... command takes a long time

Preferably yes. If you dont want to invoke context, you will have to use NewConfigInfo().ContextExists() and then handle failure yourself.

Then probably for consistency we should keep the context as is

Code LGTM but waiting for CI to go green

Test looks good to me.
Verified locally too

do we need
odo/pkg/odo/cli/config/unset.go
Line 62 in 50bc582
o.context = genericclioptions.NewContext(cmd)
for all odo config @kadel
due to this each odo config ... command takes a long time

we need to fix  context, not remove it ;-)


RDS Data Security policy incorrect policy description

terrascan version: v1.3.2
Operating System: Any

Description
The description of AWS.RDS.DataSecurity.High.0414.json doesn't match what the associated rego policies does. This policy is checking weather the database instance has been encrypted, but the message is indicating that automated backups aren't enabled.
What I Did
Example terraform:
resource "aws_db_instance" "secureInstance" {
  allocated_storage                   = 20
  storage_type                        = "gp2"
  engine                              = "mysql"
  engine_version                      = "5.7"
  instance_class                      = "db.t2.micro"
  name                                = "mydb"
  backup_retention_period             = 90
  iam_database_authentication_enabled = true
  auto_minor_version_upgrade          = true
}

Here's the error message from Terrascan but as you can see above "backup_retention_period" was specified. What's missing is "kms_key_id".
$ terrascan scan -t aws .

Violation Details -

        Description    :        Ensure that your RDS database instances have automated backups enabled for point-in-time recovery. To back up your database instances, AWS RDS take automatically a full daily snapshot of your data (with transactions logs) during the specified backup window and keeps the backups for a limited period of time (known as retention period) defined by the instance owner.
        File           :        aws_db_instance.tf
        Line           :        5
        Severity       :        HIGH
        -----------------------------------------------------------------------

Scan Summary -

        File/Folder         :   /Users/therasec/programming/test_dirs/success
        IaC Type            :   terraform
        Scanned At          :   2021-02-04 03:04:00.301155 +0000 UTC
        Policies Validated  :   149
        Violated Policies   :   1
        Low                 :   0
        Medium              :   0
        High                :   1

Fixed in #542


BigInt support

Fixes #15096.
Additions:

The bigint primitive type, which is analogous to but distinct from number
Parsing of bigint literals, e.g. 123n. Per the ECMAScript proposal, literals can be expressed in binary (0b), octal (0o), hex (0x), or decimal formats. bigint literals, like number or string literals, are valid types. The config option experimentalBigInt must be set in order to use bigint literals.
Arithmetic operators work on bigint values and return bigint results
Updated the return type of the (JavaScript) typeof operator to include "bigint"
esnext.bigint lib file, which defines BigInt, BigIntConstructor, BigInt64Array, and BigUint64Array and adds *int64* methods to DataView
Three tests: parseBigInt to test parsing bigint literals, numberVsBigIntOperations to test that arithmetic operations accept and return the correct types, and warnExperimentalBigIntLiteral to test that using bigint literals without the --experimentalBigInt option throws an error

Notes:
bigint is now a reserved word.
The type of arithmetic operations with any types, e.g. <any>1 * <any>2, was left as number instead of changing it to the more accurate number | bigint in order to maintain compatibility. Binary arithmetic operations are not allowed on operands of number | bigint type because it is possible that their runtime types conflict.
Error messages referring to the type of arithmetic operands were updated, as was the type of typeof expressions, which required updating many reference baselines. Other than that, no existing tests' expected behaviors were changed.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: calebsander sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

The lint is failing because tslint doesn't know about the esnext.bigint library. Seems like a chicken-and-egg situation: this push is needed to add the esnext.bigint library, but tslint needs to already have the changes in order to lint successfully.

Also not sure how to avoid running the bigint tests on versions of Node.js below 10, since they will fail to compile.

cool, a big work

It is actually only a ~1000 line change, ignoring the rebuilt LKG and the updates to the reference baselines. If you would prefer it broken up, I could do the following:

To avoid needing to rebuild the LKG in order to compile the compiler, type-alias bigint to number in the compiler code and convert all typeof x === "bigint" instances to typeof x as string === "bigint"
Push the esnext.bigint lib separately, since it is not currently being used in the compiler code

Let me know whether it would be better to do this as 2 or 3 pulls instead of 1.

I reverted the LKG for now and removed references to bigint in the compiler code. The compiler should emit the same JS, but its typings are not as accurate. Once the LKG is rebuilt with this code, 74fd6d3 should be reverted so that the compiler code has the correct types.

Ah, another general remark: It looks like your parse handles it, but you need tests of bigint literals of all shapes and sizes with various configurations of numeric separators. I'd just add new entries to the numeric separator tests, myself, since those contain all kinds of literals with numeric separators in them.

@mhegazy had mentioned that we should enable bigInt only under --experimentalBigInt compiler options flag.

What features would you imagine being restricted without the flag? Just bigint literals? The fact that typeof can return "bigint"? The bigint type keyword? Compiling the esnext.bigint lib requires the bigint keyword to be recognized, so if that is disabled without the flag, the tsconfig.json file will have to be modified in order to build the lib. I had issues with tslint failing on new options in tsconfig.json, so I'm not sure how that would work.
I'm not sure an experimental flag is necessary; no existing code should break with the change unless it is using the bigint identifier. I'm also not convinced "experimental" really makes sense; this doesn't seem like a feature whose behavior is likely to change.

What features would you imagine being restricted without the flag? Just bigint literals?

yes. basically any expression of type bigint should be flagged.
I should add that we want the error reported only once in a compilation to avoid noise.

I'm not sure an experimental flag is necessary;

The flag is not necessary for valid code generation. the flag is needed to inform the user that there is potential change in semantics that could happen in a future release. that is the same as decorators.
The alternative here is not to include this feature until it reaches stage 4.

Just chipping in from the sides.  While the proposal is at Stage 3, by TC39's definition, there is a risk of implementation challenges which can effect the spec.  For example, this behaviour isn't fully settled, while it unlikely to impact the TypeScript implementation, the flag is the only way to underline to users that it isn't fully baked yet and until it has an ES release there is a danger of how it gets aligned.  It should be ES2019 but...
For something like this, it feels fairly important to flag it until the proposal reaches Stage 4.

Sure, that makes sense. I already added the flag. It will warn on any bigint literals, or if it sees the bigint keyword. I think I've addressed all the comments on the PR, with the exception of TypeFlags exceeding 30 bits. I looked into trying to fix it by factoring out the literal flags, but it looks like there are hundreds of locations that would have to be updated. I would rather keep that for a separate PR. I think this PR should be ready to merge if there are no further comments.
The Node.js 8 Travis job seems to have failed on the last build because npm couldn't resolve the jake executable. Not sure what would cause that. Otherwise, the builds are all passing.

I already added the flag. It will warn on any bigint literals, or if it sees the bigint keyword.

I think we don't want to error in the keyword, just the literals. We don't want to error when the node .d.ts updates to use bigints in stats, for example - just on usages we won't be downleveling.

I think we don't want to error in the keyword, just the literals. We don't want to error when the node .d.ts updates to use bigints in stats, for example - just on usages we won't be downleveling.

That sounds right to me. in general we should not error in an ambient context any ways..

Hmm, it seems like the Travis build failure on Node 8 is due to jake not being installed in the node_modules cache, since it went away when I removed the cache field from .travis.yml. Not sure what can be done to fix that, but I don't think there is any problem with the PR code.

Also need testcase for usage of bigint literals, type and BigInt() when esNext and when less than esNext with and without experimentalBigInt

Also need testcase for usage of bigint literals, type and BigInt() when esNext and when less than esNext with and without experimentalBigInt

experimentalBigInt and "target": "esnext" vs. pre-esnext are currently orthogonal options: experimentalBigInt controls whether errors are raised on bigint literals, whereas target only affects whether the esnext.bigint lib is included. Regardless of both options, bigint can be used as a type without raising any errors. (I'm not sure whether it makes sense to allow the bigint keyword without experimentalBigInt, but I think it should behave the same in ambient and non-ambient settings. I think @weswigham's point about not throwing errors just because @types/node is included is really more about included libraries vs. user-written code than about ambient vs. non-ambient contexts.)
The parseBigInt and warnExperimentalBigIntLiteral tests already verify the behavior of the having experimentalBigInt set and unset. I added tests verifying the behavior of variables and types declared in esnext.bigint with and without "target": "esnext", including the non-primitive resolution of bigint (to BigInt with "target": "esnext", and to {} without esnext).

So, question raised in #26330 - should bigints be allowed to index objects/arrays (probably?) and in that case, shouldn't they just be treated as numbers (since they have the same string representation)? And should such an addition affect the base keyof (eg, should keyof's constraint be string | symbol | number | bigint)?

Hmm, seems like kind of a slippery slope. Any value can technically be used as a key in JS, since any value can be converted to a string representation:
const a = {}
a[new Date] = 'abc'
a[function abc() {}] = 'abc'
a[[1, 2, 3]] = 'abc'
console.log(a)
/* Prints:
{ 'Fri Aug 10 2018 11:50:27 GMT-0700 (Pacific Daylight Time)': 'abc',
  'function abc() {}': 'abc',
  '1,2,3': 'abc' }
*/

I think key types only include number because there are several builtins (Array, TypedArrays, etc.) which are meant to be indexed with numeric indices. All of these can technically be indexed with bigint indices as well, but that is only because the bigint gets converted to its string representation first. This There are no instances in the standard library of types expressly indexed by bigint. I can't think of any situation in which a user-defined type would want to have a bigint index either. You could also always just declare it as a string index and then convert the bigint to a string before using it as an index. So I would probably lean towards not including bigint as an index type.

Agreed with @calebsander on https://github.com/Microsoft/TypeScript/pull/25886#issuecomment-412175959 where in we shouldn't include bigint in number signature. BigInt shouldn't affect signature (or keyof at all).

Alright, I'm fine with that - just wanted to bring it up. Also should probably add tests to document that we do error on such uses.

Just as a tip @calebsander, some of your commits aren't associated with your account. You may want to update your email addresses with GitHub.

@sheetalkamat you wanna help guide this to a merge for the next release?

@calebsander care to sync with master?

Synced.

Thank you @calebsander for this contribution. It should be available in tonight's nightly build.

Hey @calebsander, I just updated to the Nightly and now I am having TSLint issues, but it is compiling correctly. What were the flags to remove the warnings again? I think I noticed that you deleted them, or removed them.

I'm not sure what is required for TSLint to work, but for tsc to succeed you should only have to set "target": "esnext". This will prevent warnings for BigInt literals and include the esnext.bigint standard library declarations. The developers removed the experimentalBigInt flag; it's now indicated by setting the target version.

"esnext.bigint", where would I find these?
Thanks.

I do have my target already set at esnext, still not fixed on Atom or VS Code.

You need to set vscode to use your workspace version of typescript and install the @next version in your workspace - this hasn't shipped bundled with the editor yet, and won't until after the 3.2 release in the coming few weeks.

"esnext.bigint", where would I find these?

This is just the declaration file that specifies BigInt, BigInt64Array, etc. If you click Go to Definition in VS Code on the BigInt constructor, it should take you to the esnext.bigint file where it is defined (which should be node_modules/typescript/lib/lib.esnext.bigint.d.ts). As @weswigham said, you have to make VS Code use your workspace version of TypeScript. This esnext.bigint declaration file is automatically included when you target esnext, but you can also include it manually by adding it to lib in your tsconfig.json.

Saviours, thank you. I hope your information will help the next person.


style: #1424 Add missing originalRotation property

Thanks for submitting a PR! Please read these instructions carefully:

[x] Explain the motivation for making this change.
[x] Provide a test plan demonstrating that the code is solid.
[x] Match the code formatting of the rest of the codebase.
[x] Target the master branch, NOT a "stable" branch.

Motivation (required)
It adds a missing TypeScript property.
Test Plan (required)
Since there is no functional changes no new tests where added. All existing tests pass.

Thanks, this is an android only type right?

Thanks, this is an android only type right?

Yes, it is only used on android.


Update settings-that-can-be-modified-to-improve-network-performance.md

Docs discuss the range of TcpTimedWaitDelay is 30-300 but it has changed 2-300 on Windows Server 2012 R2.

Docs Build status updates of commit 8d4c073:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

biztalk/technical-guides/settings-that-can-be-modified-to-improve-network-performance.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit 86eafe3:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

biztalk/technical-guides/settings-that-can-be-modified-to-improve-network-performance.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit 61da871:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

biztalk/technical-guides/settings-that-can-be-modified-to-improve-network-performance.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit 39c1ef8:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

biztalk/technical-guides/settings-that-can-be-modified-to-improve-network-performance.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

@hiromi-shindo Thank you!


[New feature] Provisioning profiles searching

Hey guys.
The account I am working with has almost 2000 provisioning profiles. So method Spaceship::Portal::ProvisioningProfile.find_by_bundle_id working so long for me.
The apple developers portal supports searching capabilities. In case of provisioning profiles, it is just one additional parameter in Spaceship::PortalClient#provisioning_profiles
something like
module Spaceship
  class PortalClient < Spaceship::Client
    def search_provisioning_profiles(query, mac: false)
      req = request(:post) do |r|
        r.url "https://developerservices2.apple.com/services/#{PROTOCOL_VERSION}/#{platform_slug(mac)}/listProvisioningProfiles.action"
        r.params = {
          teamId: team_id,
          includeInactiveProfiles: true,
          onlyCountLists: true,
          search: "name=#{query}&type=#{query}&appId=#{query}&status=#{query}"
        }
      end

      parse_response(req, 'provisioningProfiles')
    end
  end
  module Portal
    class ProvisioningProfile < PortalBase
      class << self
        def search_provisioning_profiles(query, mac: false)
          profiles = client.search_provisioning_profiles(query, mac: mac).map do |profile|
            self.factory(profile)
          end

          # filter out the profiles managed by xcode
          profiles.delete_if(&:managed_by_xcode?)

          return profiles if self == ProvisioningProfile

          # only return the profiles that match the class
          profiles.select do |profile|
            profile.class == self
          end
        end
      end
    end
  end
end

This works faster than Spaceship::Portal::ProvisioningProfile.all and takes less memory
What do you think?

Nice work, bro!

@MaximSt Thanks for sharing! We are going to take a look at this and see about integrating it directly into Spaceship. Hope that you have a wonderful week! 👍

@MaximS how to I add this to my code so I can try it out I keep getting timeout errors right now.
I am hoping this will solve my problems. I have a huge account also.
thanks

@sfransen you can add cde above to initializer like spaceship.rb

Thank you @TKBurner

@MaximSt  I have the same situation as you do - this is great, thank you!
In the account that I manage, I have deleted tons of profiles managed by Xcode (with fastlane spaceship) and that speed up things. I also avoid configuring that account in Xcode so it won't create that managed profiles again.

Problem is that I have hundreds of developers and I have no control over their system
I didn't have a change to test this yet
I hope to find time today to test this
Where do I place this code by the way
Thanks
Sent from my iPhone5

On Apr 25, 2016, at 12:15 AM, Tsafrir<EMAIL_ADDRESS>wrote:
@MaximSt I have the same situation as you do - this is great, thank you!
In the account that I manage, I have deleted tons of profiles managed by Xcode (with fastlane spaceship) and that speed up things. I also avoid configuring that account in Xcode so it won't create that managed profiles again.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

While search might be a better option, this change, to enable pagination on the profiles works for our team, we have > 1000 profiles and well and our devs are adding more all the time:
def provisioning_profiles(include_invalid_profiles=true, mac: false)
      @page_size = 200
      paging do |page_number|
        req = request(:post) do |r|
          r.url "https://developerservices2.apple.com/services/#{PROTOCOL_VERSION}/#{platform_slug(mac)}/listProvisio..."
          r.params = {
            teamId: team_id,
            includeInactiveProfiles: include_invalid_profiles,
            onlyCountLists: true,
            pageSize:page_size,
            pageNumber:page_number,
            sidx: "name",
            sort: "name=dasc"
          }
        end

      parse_response(req, 'provisioningProfiles')
    end
  end

@MaximSt search still working for you? I started to run into 403 errors.


Rule proposal: detect very unnecessary useMemos

useMemo is meant to be used to stop recomputations happening frequently. There's no real need to use useMemo for really simple operations such as addition... and yet, I have anecdotally seen this type of code:
const value = useMemo(() => a + b + c);

Proposal: a lint rule that flags any useMemo call that only contains binary operators, unary operators, property access expressions[^1], and similar should-probably-not-be-memoized work?
[^1]: In theory, getters can make property accesses expensive... but that's not a common use for them.

That seems like it would be a very limited rule - it’d only be able to handle inline functions, and useMemo is often used with imported functions that can’t be statically analyzed.
Either way, this is hook-specific, so i think eslint-plugin-react-hooks is the proper place to file the issue.


"Theme is not defined" Error in @mui/material v6 sx Prop When Using pigment-css

Steps to reproduce
This works fine:
<Button
    variant='contained'
    sx={theme => ({
      bgcolor: theme.palette.common.black,
    })}
>
    Test
</Button>

However, this throws an error:
<Button
    variant='contained'
    sx={{
      bgcolor: theme => theme.palette.common.black,
    }}
>
    Test
</Button>

I would like to know if this behavior is intentional or if it’s a bug.
Current behavior
No response
Expected behavior
No response
Context
No response
Your environment

npx @mui/envinfo
  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.

Search keywords: pigment-css, v6

Yes, it's intended. Theme callback should not be a value of a CSS property.


Inclusive capture boundary for AnyBefore captor

Ticket: https://fetchrobotics.atlassian.net/browse/RIOT-13719
Description
The AnyBefore captor currently only captures data before the sequencing boundary but does not capture messages exactly at the sequencing boundary.
It would be useful to capture messages that are exactly at the boundary, so that driver messages may be synced with (optional) follower messages that are intentionally created with the same timestamps (in the case of a zero delay) or a fixed timestamp offset.
To avoid potential consequences to code that rely on this captor being non-inclusive, the captor can be made inclusive through a constructor argument (but is non-inclusive by default).
Tests

Unit tests modified/added for both non-inclusive and inclusive AnyBefore captors (successfully ran)
Ran the carl navigation suite for in simulation with the flow change (no issues encountered)

Open questions for reviewers

Looks good!  Let's get this merged somehow...

@briancairl Can you merge this?

I'd almost prefer this being a separate policy. A AnyAtAndBefore counterpart to AnyBefore with most of the same logic except for the inclusive check. I know its such a minor difference, but the runtime check every time nags me, and is somewhat antithetical to the "as much at compile time" philosophy of most of the other captor types.
If this is blocking, I can merge, but, I would encourage consideration. Let me know.

@briancairl Yeah, I can attempt to do that instead.
Both the submitted implementation and what you are proposing were considered during a prior discussion. It was felt that the runtime hit would be fairly insignificant, which led to choosing this particular implementation in favour of reducing code bloat. However, it makes sense to stay consistent with the philosophy used across the different captors, so I'll introduce a AnyAtAndBefore captor instead

@briancairl Would you happen to remember what website/tool you used to generate the captor behaviour diagrams in the README and have access to the modifiable file formats?

#59

@SomeshDaga it should be in a google drive (Google Draw) folder somewhere withing the Fetch org. Doing a quick search for AnyBefore or some other policy name should bring it up.


Upgrade to RC1

Certainly some magic in the change from beta8 to rc1, this was the small amount of info that helped
https://github.com/aspnet/Announcements/issues/98

Cripes! I know this is cutting edge stuff we're playing with but the amount of changes required is mental, especially with so little information. Thanks for this!

Yeah, the dotnet5.4 is a magical thing, what, really, what.... it works....

Why 5.4? So odd...

Someone knows, it's in this announcement https://github.com/aspnet/Announcements/issues/98 If you search Twitter for it you get some interesting results


[TS] nothing cannot be distinguished from undefined return

import {produce, nothing} from 'immer'

// Okay 👍
const A: undefined = produce({}, s => nothing)

// Error 😔
const B: {readonly a: number} = produce({a: 1}, s => void s.a++)

This will be fixed in v1.9.3

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


THEEDGE-2175 - fix missing data for resume image update

Signed-off-by: Jonathan Holloway<EMAIL_ADDRESS>Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes # (issue) THEEDGE-2175
Type of change
What is it?

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Documentation update
[ ] Tests update
[ ] Refactor

Checklist:

[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[x] I run go fmt ./... to check that my code is properly formatted
[x] I run go vet ./... to check that my code is free of common Go style mistakes
[x] I run make lint to prints out coding style mistakes and fix them

Test results are available in Ibutsu. The test run IDs are:
2abe85d1-3f34-42aa-b090-add5e64e0d57
f070ccb8-2efe-40a6-9c86-1dd3f68645c3


update ppp

Codecov Report

Merging #159 (dad6672) into master (365102d) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #159   +/-   ##
=========================================
  Coverage     57.35%   57.35%
  Complexity      501      501
=========================================
  Files           101      101
  Lines          1937     1937
  Branches        222      222
=========================================
  Hits           1111     1111
  Misses          763      763
  Partials         63       63

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 365102d...dad6672. Read the comment docs.


Rename and narrow to inspect skip only

We are not expected to flag pending, as it would blow up specs:

https://github.com/rubocop/rubocop-rspec/pull/1566#discussion_r1088923352
https://github.com/rubocop/rubocop-rspec/pull/1566#discussion_r1089015507
https://github.com/rspec/rspec-core/blob/79ec0fd5b5ebd13031a10960f293b8a4a43cb734/lib/rspec/core/pending.rb#L66

See also #1562 #1564

Before submitting the PR make sure the following are checked:

[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[x] Added tests.
[x] Updated documentation.
[x] Added an entry to the CHANGELOG.md if the new code introduces user-observable changes.
[x] The build (bundle exec rake) passes (be sure to run this locally, since it may produce updated documentation that you will need to commit).

Just to clarify: RSpec will raise an ArgumentError when you call pending with a block – so there is no point is us having a cop that checks if you are calling pending with a block.


Move skip RDO inner loop than prediction RDO

Otherwise, exactly the same prediction is done twice for skip and non-skip modes.
Best place  to compare skip/non-skip would be inside encode_block(), which will
return the RDO decision for skip flag together with rd_cost.

I'm not sure what this means, but as mentioned before, testing skip after making a decision for the prediction mode results in lower quality than not even testing skip at all, with current RD modelling.

I see, I will take care of this task.

On Jul 26, 2018, at 6:53 AM, Raphael Zumer<EMAIL_ADDRESS>wrote:
I'm not sure what this means, but as mentioned before, testing skip after making a decision for the prediction mode results in lower quality than not even testing skip at all, with current RD modelling.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

New skip RDO #474 has landed, https://github.com/xiph/rav1e/commit/c2d7b6af3bb081b85dbde6adccab5522802390a9 and it works flawlessly.

I assume this was fulfilled by #474, so closing.


fix:selectSetter的options支持方法stringSetter支持预览和去除边框

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Verb option help is not rendering Enum value options

 Issue by kensykora
Thursday Oct 01, 2015 at 14:32 GMT
Originally opened as https://github.com/gsscoder/commandline/issues/246

When I create a verb object with a verb that has an enum value option, the help for the verb is not rendering. See example here:  https://gist.github.com/kensykora/f486cdf239a823390409
Basically, any enum that's a positional parameter doesn't show up in autobuild help. It'd also be nice if the enum displayed it's string value rather than the int value, maybe even used the System.ComponentModel.DescriptionAttribute option?

 Comment by blakecausey
Wednesday Jan 20, 2016 at 20:30 GMT

This error appears to be in the TryParseHelpVerb method where the verb is fetched as the first item of the args parameter but for "help" the verb should be the second item. e.g. "myapp help commit" where "commit" is the verb.
The following line shows where it fetches the first item of args.
var verb = args.FirstOrDefault();

To prove my point, the following "if" statement looks for "help" in args[0] and will return if it does not find it as shown below:
if (string.Compare(args[0], helpInfo.Right.LongName, GetStringComparison(_settings)) == 0)

Below is the complete method.
private bool TryParseHelpVerb(string[] args, object options, Pair<MethodInfo, HelpVerbOptionAttribute> helpInfo, OptionMap optionMap)
{
    var helpWriter = _settings.HelpWriter;
    if (helpInfo != null && helpWriter != null)
    {
        if (string.Compare(args[0], helpInfo.Right.LongName, GetStringComparison(_settings)) == 0)
        {
            // User explicitly requested help
            var verb = args.FirstOrDefault();
            if (verb != null)
            {
                var verbOption = optionMap[verb];
                if (verbOption != null)
                {
                    if (verbOption.GetValue(options) == null)
                    {
                        // We need to create an instance also to render help
                        verbOption.CreateInstance(options);
                    }
                }
            }

            DisplayHelpVerbText(options, helpInfo, verb);
            return true;
        }
    }

    return false;
}

I'm unable to get the time to test my theory or even come up with a fix but most likely I would do something like:
var verb = args.Skip(1).FirstOrDefault();

 Comment by gsscoder
Monday Oct 05, 2015 at 22:42 GMT

:paperclip: Please read: #250. Thanks for collaboration and patience! :sweat_smile:
Giacomo
P.S.: valid only for me, if a main contrib. is available he's obviously free to support devs/users of the project.

 Comment by jkodroff
Monday Jun 20, 2016 at 13:29 GMT

@DanHarman I agree.  See: https://github.com/gsscoder/commandline/issues/326

 Comment by DanHarman
Wednesday Mar 09, 2016 at 16:04 GMT

Enum parsing with verbs as positional arguments is also currently case sensitive when I don't believe it should be.


Update Readme.md

The Azure OpenAI Support is still not functional. This can't be treat as done.

It's related to #181


add timestamp toggle in chart options (Table Viz)

Coverage remained the same at 81.57% when pulling 80b0818a353b1ca79a0168536025ee302de3973b on sid88in:tablevizenhance into d304ee005a976b2582f0be3b5bfc8cd9aa7c60e8 on airbnb:master.

Coverage remained the same at 81.57% when pulling 80b0818a353b1ca79a0168536025ee302de3973b on sid88in:tablevizenhance into d304ee005a976b2582f0be3b5bfc8cd9aa7c60e8 on airbnb:master.

@mistercrunch fixed the refactoring of timestamp choices.

Coverage increased (+0.02%) to 81.59% when pulling 7cc65bb4b537f9cdb37fe4cabf969f07843fd4f5 on sid88in:tablevizenhance into d304ee005a976b2582f0be3b5bfc8cd9aa7c60e8 on airbnb:master.

Coverage increased (+0.02%) to 81.59% when pulling 7cc65bb4b537f9cdb37fe4cabf969f07843fd4f5 on sid88in:tablevizenhance into d304ee005a976b2582f0be3b5bfc8cd9aa7c60e8 on airbnb:master.

Coverage increased (+0.007%) to 81.59% when pulling 61ce36417dc7d940af529ccb6cf6d06d7ab2791b on sid88in:tablevizenhance into 2f64c42062dc041408371dd0cecddd940e0bcf47 on airbnb:master.


New tooling for mgmt .NET sdk

This PR will make couple of fundamental changes the way management SDKs will be built
Changes:

Their will not be any need moving forward to download build tools by executing msbuild build.proj
1.1 Build tools will be downloaded implicitly
1.2 If you ever need to refresh build tools, you will need to delete the following directory rootDir\restoredPackages\microsoft.internal.NetSdkBuild.Mgmt.Tools directory and execute your build target again.
All existing scenarios to build SDKs are at parity with previous tool set.
Moving forward due to directory restructure, scope path will have to be changed appropriately (documentation will be updated in the next PR)
3.1 Instead of /p:Scope=SDKs\Compute
3.2 /p:Scope=sdk\compute\microsoft.azure.management.compute
3.3 /p:Scope=sdk\compute /p:ProjectCategory=mgmt
This does not support data-plane SDK projects (it might work, but not thoroughly tested, as communicated earlier that data plane SDK projects will not participate in this tool set)
Move all management specific targets under eng\mgmt
Update repo with the right set of test projects that we skipped in the CI jenkins job, now each project has an explicit property to skip tests

TODO:
Consolidate base targets (e.g. Clean, Build, ReBuild) with data plane targets
Workaround is to introduce new mgmtBuild.proj for building management plane SDKs
Lot of bugs/oddities will be squeezed out once the new directory structure is in place.
Block packages to be published if tests are skipped

@shahabhijeet I assume this PR is now obsolete and can be closed. We should use the comments as a set of clean-up workitems though.


Set-up the All-Contributors

"This is a specification for recognizing contributors to an open source project in a way that rewards each and every contribution, not just code."
Note : /all-contributors/all-contributors
https://github.com/all-contributors/all-contributors

Hi @bryanILKI
I just added the @all-contributors bot to ILKE. So this issue is resolved. I will close it


Reduce type set for Wasm in FFI

Wasm allows only a subset of C ABI compatbile datatypes. The types supported are 32-bit and 64-bit sized types. This means that a flag is needed to convert u8/i8 and u16/i16 to u32/i32 when building FFI API for wasm. This affects integers as function arguments or inside structures as well as repr(int) enums. A special care should be taken in handling bool type conversion

After some discussion with @Erigara it is decided that only primitives u8/i8 and u16/i16 will be special handled when wasm feature is activated. This means that references or aggregate types, such as &u8 or &[u8] will not be converted to *const u32 and (*const u32, usize) respectively, rather they will be turned into raw pointers *const u8 and (*const u8, usize). These types are repr(C) as are the types they dereference to. If any special handling is required, it is the callers responsibility.