Upload required

Hello,
I wonder how to define upload as required. For others fields you can use validation rules with the field name, but the upload field don't have any names, so how to make it required ?
Regards,

Not sure if there is possible right now (i will take a look).
Maybe is time to start thinking on another upload component...

http://blueimp.github.io/jQuery-File-Upload/index.html

+1 for the plugin linked above. Very good plugin that may help for a better integration of upload system to magicform.

Hello,
Any update with this ? I don't have enought october cms skill (yet) to help, but the jquery file upload solution linked above could be a very good solution.

Hello @Alex360hd, i made a few test some time ago (unfortunately don't have to much free time).
Using the plugin it's easy, the difficult part is the integration with October attachments and saving the files before submit the form.
The current upload was easy because there was already a plugin doing all this task.
I'm interested on this issue, but as i say, don't have free time right now :disappointed:

Hello,
Do you have an edge version of the module with the integration with the jquery file upload plugin ? To clearly see what's missing with october attachments to make it works.

@Zmove don't have any code, i've deleted my tests because was useless, sorry

For anyone coming across this issue a hacky way around this I have implemented is by adding a session within the checkUploadAction function in ComponentUtils.php in the traits folder. This triggers and adds the session when a file is uploaded.
Within MagicForm.php in the onFormSubmit method check if _uploader is set. If isset then check for the file uploaded session created above. If it's not found add to the $rules and $msgs variables to output the validation message.
If you may multiple forms and some might not require the file upload you may need to add a hidden field which can be checked if isset along with the _uploader field.
Finally add the Session::forget() method when the record is saved to the database and within the onRemoveAttachment method in the fileuploader.php file (incase a user removes the file and forgets to add another).
Hope this helps.

Hi! I saw this post and I have the same need...
How can I make file upload required on a Form within magic forms plugin?
Any help will be very welcome!
@TonnnnUK gave a great solution but I don't know how to implement...
If anyone have a simplest way, it will be fine!
Thank you in advance!


Sell side does not loop/check after a new order is opened.

isActive in the first constructor should be set to true instead of false.

complete.


Unable to upgrade to 1.23.1

vscode-inno-updater.log:
May 11 08:36:25.298 INFO Starting: C:\Program Files\Microsoft VS Code\Code.exe, false
May 11 08:36:25.301 INFO Checking for running Code.exe processes... (attempt 1)
May 11 08:36:25.311 INFO Code.exe is running, wait a bit
May 11 08:36:25.812 INFO Checking for running Code.exe processes... (attempt 2)
May 11 08:36:25.825 INFO Code.exe is running, wait a bit
May 11 08:36:26.326 INFO Checking for running Code.exe processes... (attempt 3)
May 11 08:36:26.340 INFO Code.exe is not running
May 11 08:36:26.340 INFO Checking for possible conflicting running processes... (attempt 1)
May 11 08:36:26.354 INFO Inno Updater v0.4.3
May 11 08:36:26.354 INFO Starting update, silent = false
May 11 08:36:26.509 INFO do_update: "C:\Program Files\Microsoft VS Code\Code.exe", _
May 11 08:36:26.509 INFO move_update: "C:\Program Files\Microsoft VS Code\unins000.dat", _
May 11 08:36:26.511 INFO Delete: "api-ms-win-core-console-l1-1-0.dll" (attempt 1)
May 11 08:36:26.513 INFO Delete: "api-ms-win-core-datetime-l1-1-0.dll" (attempt 1)
May 11 08:36:26.515 INFO Delete: "api-ms-win-core-debug-l1-1-0.dll" (attempt 1)
May 11 08:36:26.518 INFO Delete: "api-ms-win-core-errorhandling-l1-1-0.dll" (attempt 1)
May 11 08:36:26.523 INFO Delete: "api-ms-win-core-file-l1-1-0.dll" (attempt 1)
May 11 08:36:26.526 INFO Delete: "api-ms-win-core-file-l1-2-0.dll" (attempt 1)
May 11 08:36:26.529 INFO Delete: "api-ms-win-core-file-l2-1-0.dll" (attempt 1)
May 11 08:36:26.530 INFO Delete: "api-ms-win-core-handle-l1-1-0.dll" (attempt 1)
May 11 08:36:26.536 INFO Delete: "api-ms-win-core-heap-l1-1-0.dll" (attempt 1)
May 11 08:36:26.539 INFO Delete: "api-ms-win-core-interlocked-l1-1-0.dll" (attempt 1)
May 11 08:36:26.542 INFO Delete: "api-ms-win-core-libraryloader-l1-1-0.dll" (attempt 1)
May 11 08:36:26.543 INFO Delete: "api-ms-win-core-localization-l1-2-0.dll" (attempt 1)
May 11 08:36:26.545 INFO Delete: "api-ms-win-core-memory-l1-1-0.dll" (attempt 1)
May 11 08:36:26.546 INFO Delete: "api-ms-win-core-namedpipe-l1-1-0.dll" (attempt 1)
May 11 08:36:26.549 INFO Delete: "api-ms-win-core-processenvironment-l1-1-0.dll" (attempt 1)
May 11 08:36:26.550 INFO Delete: "api-ms-win-core-processthreads-l1-1-0.dll" (attempt 1)
May 11 08:36:26.553 INFO Delete: "api-ms-win-core-processthreads-l1-1-1.dll" (attempt 1)
May 11 08:36:26.554 INFO Delete: "api-ms-win-core-profile-l1-1-0.dll" (attempt 1)
May 11 08:36:26.555 INFO Delete: "api-ms-win-core-rtlsupport-l1-1-0.dll" (attempt 1)
May 11 08:36:26.556 INFO Delete: "api-ms-win-core-string-l1-1-0.dll" (attempt 1)
May 11 08:36:26.558 INFO Delete: "api-ms-win-core-synch-l1-1-0.dll" (attempt 1)
May 11 08:36:26.559 INFO Delete: "api-ms-win-core-synch-l1-2-0.dll" (attempt 1)
May 11 08:36:26.560 INFO Delete: "api-ms-win-core-sysinfo-l1-1-0.dll" (attempt 1)
May 11 08:36:26.562 INFO Delete: "api-ms-win-core-timezone-l1-1-0.dll" (attempt 1)
May 11 08:36:26.563 INFO Delete: "api-ms-win-core-util-l1-1-0.dll" (attempt 1)
May 11 08:36:26.564 INFO Delete: "api-ms-win-crt-conio-l1-1-0.dll" (attempt 1)
May 11 08:36:26.565 INFO Delete: "api-ms-win-crt-convert-l1-1-0.dll" (attempt 1)
May 11 08:36:26.569 INFO Delete: "api-ms-win-crt-environment-l1-1-0.dll" (attempt 1)
May 11 08:36:26.570 INFO Delete: "api-ms-win-crt-filesystem-l1-1-0.dll" (attempt 1)
May 11 08:36:26.571 INFO Delete: "api-ms-win-crt-heap-l1-1-0.dll" (attempt 1)
May 11 08:36:26.573 INFO Delete: "api-ms-win-crt-locale-l1-1-0.dll" (attempt 1)
May 11 08:36:26.574 INFO Delete: "api-ms-win-crt-math-l1-1-0.dll" (attempt 1)
May 11 08:36:26.575 INFO Delete: "api-ms-win-crt-multibyte-l1-1-0.dll" (attempt 1)
May 11 08:36:26.576 INFO Delete: "api-ms-win-crt-private-l1-1-0.dll" (attempt 1)
May 11 08:36:26.577 INFO Delete: "api-ms-win-crt-process-l1-1-0.dll" (attempt 1)
May 11 08:36:26.578 INFO Delete: "api-ms-win-crt-runtime-l1-1-0.dll" (attempt 1)
May 11 08:36:26.580 INFO Delete: "api-ms-win-crt-stdio-l1-1-0.dll" (attempt 1)
May 11 08:36:26.581 INFO Delete: "api-ms-win-crt-string-l1-1-0.dll" (attempt 1)
May 11 08:36:26.582 INFO Delete: "api-ms-win-crt-time-l1-1-0.dll" (attempt 1)
May 11 08:36:26.583 INFO Delete: "api-ms-win-crt-utility-l1-1-0.dll" (attempt 1)
May 11 08:36:26.584 INFO Delete: "bin" (attempt 1)
May 11 08:36:26.586 INFO Delete: "blink_image_resources_200_percent.pak" (attempt 1)
May 11 08:36:26.587 INFO Delete: "Code.exe" (attempt 1)
May 11 08:36:26.593 INFO Delete: "Code.VisualElementsManifest.xml" (attempt 1)
May 11 08:36:26.595 INFO Delete: "CodeSignSummary.md" (attempt 1)
May 11 08:36:26.596 INFO Delete: "content_resources_200_percent.pak" (attempt 1)
May 11 08:36:26.596 INFO Delete: "content_shell.pak" (attempt 1)
May 11 08:36:26.598 INFO Delete: "d3dcompiler_47.dll" (attempt 1)
May 11 08:36:26.600 INFO Delete: "ffmpeg.dll" (attempt 1)
May 11 08:36:26.602 INFO Delete: "icudtl.dat" (attempt 1)
May 11 08:36:26.604 INFO Delete: "libEGL.dll" (attempt 1)
May 11 08:36:26.605 INFO Delete: "libGLESv2.dll" (attempt 1)
May 11 08:36:26.606 INFO Delete: "locales" (attempt 1)
May 11 08:36:26.655 INFO Delete: "msvcp140.dll" (attempt 1)
May 11 08:36:26.656 INFO Delete: "natives_blob.bin" (attempt 1)
May 11 08:36:26.657 INFO Delete: "node.dll" (attempt 1)
May 11 08:36:26.660 INFO Delete: "pdf_viewer_resources.pak" (attempt 1)
May 11 08:36:26.660 INFO Delete: "resources" (attempt 1)
May 11 08:36:26.731 INFO Delete: "resources" (attempt 2)
May 11 08:36:27.061 INFO Delete: "resources" (attempt 3)
May 11 08:36:27.654 INFO Delete: "resources" (attempt 4)
May 11 08:36:28.532 INFO Delete: "resources" (attempt 5)
May 11 08:36:29.928 INFO Delete: "resources" (attempt 6)
May 11 08:36:32.098 INFO Delete: "resources" (attempt 7)
May 11 08:36:35.139 INFO Delete: "resources" (attempt 8)
May 11 08:36:38.763 INFO Delete: "resources" (attempt 9)
May 11 08:36:42.847 INFO Delete: "resources" (attempt 10)
May 11 08:36:47.856 INFO Delete: "resources" (attempt 11)
May 11 08:36:53.917 INFO Delete: "resources" (attempt 12)
May 11 08:37:01.955 INFO Delete: "resources" (attempt 13)
May 11 08:37:10.415 INFO Delete: "resources" (attempt 14)
May 11 08:37:20.244 INFO Delete: "resources" (attempt 15)
May 11 08:37:31.831 INFO Delete: "resources" (attempt 16)
May 11 08:37:44.682 INFO Delete: "resources" (attempt 17)
May 11 08:37:59.174 INFO Delete: "resources" (attempt 18)
May 11 08:38:15.434 INFO Delete: "resources" (attempt 19)
May 11 08:38:33.542 INFO Delete: "resources" (attempt 20)
May 11 08:38:53.789 INFO Delete: "resources" (attempt 21)
May 11 08:39:15.864 INFO Delete: "resources" (attempt 22)
May 11 08:39:40.101 INFO Delete: "resources" (attempt 23)
May 11 08:40:06.620 INFO Delete: "resources" (attempt 24)
May 11 08:40:35.428 INFO Delete: "resources" (attempt 25)
May 11 08:41:06.716 INFO Delete: "resources" (attempt 26)
May 11 08:41:40.546 INFO Delete: "resources" (attempt 27)
May 11 08:41:40.552 ERRO The directory is not empty. (os error 145)

Looks like duplicate of #47911.
Does reinstalling help?

Yes,  downloading an reinstalling worked just fine.
I submitted the issue since I received this message when the upgrade failed.
[image: image.png]
/Eigil
fre. 11. mai 2018 kl. 09:11 skrev Christof Marti<EMAIL_ADDRESS>
Looks like duplicate of #47911
https://github.com/Microsoft/vscode/issues/47911.
Does reinstalling help?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/49672#issuecomment-388280702,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIat18tFbzh6a1cwy3dkia9bt37lPTqVks5txTmVgaJpZM4T6_2o
.

--
Med vennlig hilsen
Eigil Sletbak
Mobil: 48075032

Not that important, a message box asking me to attach log file
(vscode_inno-updater.log) )and crate a new issue on GitHub.
fre. 11. mai 2018 kl. 13:17 skrev Christof Marti<EMAIL_ADDRESS>
The image didn't make it through email, I think. Could you append it
through GitHub's web UI?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/49672#issuecomment-388335479,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIat1_1x_kxBE83t2X7h7XW8lTbRh0rvks5txXNWgaJpZM4T6_2o
.

--
Med vennlig hilsen
Eigil Sletbak
Mobil: 48075032

Has this been still an issue for you?

No, solved by re-istallation.
tir. 29. mai 2018 kl. 09:11 skrev João Moreno<EMAIL_ADDRESS>
Has this been still an issue for you?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/49672#issuecomment-392675003,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIat1_ueS0FWc7-OnppQo0ePovzRL4dUks5t3PSOgaJpZM4T6_2o
.

--
Med vennlig hilsen
Eigil Sletbak
Mobil: 48075032

Same issue on updating to 1.24.1 from 1.23.1.
vscode-inno-updater.log


B 20034 int

Agility ticket
Summary
This PR updates B-19507 so that the application_parameters table can hold a wider array of parameters.
The tests here are to validate that 19507 still functions as expected.
How to test
Couple of setup things you need to do first:

make db_dev_migrate (this will create the application_parameters table
You'll need to fill in a row with a value in parameter_name, 'parameter_value' and id, updated_at and created_at will auto populate
In your .envrc, set export FEATURE_FLAG_VALIDATION_CODE_REQUIRED=true
Now fire up your client and server

For the happiest path

Access MM as a customer
Login as a brand new customer
You should now see the validation code screen
Input the code you slapped in the application_parameters table
It should now let you progress through the profile set up

For the saddest path

Access MM as a customer
Login as a brand new customer
You should now see the validation code screen
Input anything other than the code you put in the database
You should see an error screen and not be able to progress
You can have as many attempts as you want when inputting the code (this was a requirement from Kipp)

Screenshots

Mobile

Mobile

Okay, so I talked with @deandreJones and let's make a few changes to this to avoid any issues in production.
Instead of renaming the column, keep the validation_code column and add the new columns instead.
Then we can do a follow up story and remove the validation_code column once we know everything is working correctly.

Fails

:no_entry_sign:
Yarn Audit Issues Found:
high - PDF.js vulnerable to arbitrary JavaScript execution upon opening a malicious PDF
Package pdfjs-dist
Patched in >=4.2.67
Dependency of @transcom/react-file-viewer
Path @transcom/react-file-viewer > pdfjs-dist
More info https://github.com/advisories/GHSA-wgrm-67xf-hhpq
1 high vulnerabilities and 0 critical vulnerabilities found

  Generated by :no_entry_sign: dangerJS against 4c9412479897ce1963e5f476ae1ce2d37712984c


Verify and manually correct results for r20200722

With this new release https://github.com/spine-generic/data-multi-subject/releases/tag/r20200722, QC and manual correction needs to be performed and then uploaded to this repository. More specifically:

Check the cause of the errors (log files with prefix err.)
Run sg_generate_figure, check for outliers and report the cause for these outliers
Create a .yml file that lists the data to correct, upload it here, Julien will package the data for correction (with sg_package_for_correction)
Run manual correction (with sg_manual_correction)

Details for doing the QC available here

Is mountSinai ==> mountSinai hospital (Canada)?

So far, I have checked QC for DWI data using moco_dwi_mean keyword in "Search" feature. I list below my findings.
worse SC segmentation using sct_deepseg_sc in a few slices:
sub-vuiisAchieva01_dwi_moco_dwi_mean.nii.gz
sub-vuiisAchieva04_dwi_moco_dwi_mean.nii.gz
sub-vuiisAchieva06_dwi_moco_dwi_mean.nii.gz
sub-perform03_dwi_moco_dwi_mean.nii.gz
sub-stanford01_dwi_moco_dwi_mean.nii.gz
sub-sapienza01_dwi_moco_dwi_mean.nii.gz
sub-mniS03_dwi_moco_dwi_mean.nii.gz
no template warped using sct_warp_template:
sub-mountSinai03_dwi_moco_dwi_mean.nii.gz
a few slices of template missing after warping using sct_warp_template:
sub-dresden02_dwi_moco_dwi_mean.nii.gz
sub-queensland04_dwi_moco_dwi_mean.nii.gz
a few slices of template badly warped using sct_warp_template:
sub-stanford01_dwi_moco_dwi_mean.nii.gz
sub-sapienza01_dwi_moco_dwi_mean.nii.gz
sub-sapienza05_dwi_moco_dwi_mean.nii.gz
sub-ubc02_dwi_moco_dwi_mean.nii.gz
sub-nottwil01_dwi_moco_dwi_mean.nii.gz
sub-beijingVerio02_dwi_concat_moco_dwi_mean.nii.gz
sub-oxfordFmrib01_dwi_moco_dwi_mean.nii.gz - totally bad
bad FOV?:
sub-beijingPrisma03_dwi_moco_dwi_mean.nii.gz
bad image quality:
sub-perform01_dwi_moco_dwi_mean.nii.gz
sub-beijingVerio02_dwi_concat_moco_dwi_mean.nii.gz
sub-vuiisAchieva04_dwi_moco_dwi_mean.nii.gz

I can not find any vertebrae labeling in QC for t2w images. Is this normal?

Here is the list of QC false segmentation or labelings for t1w and t2w images. I can also send the .yml file:
FILES_SEG:

sub-beijingGE03_T1w_RPI_r.nii.gz
sub-brnoUhb02_T1w_RPI_r.nii.gz
sub-brnoUhb05_T1w_RPI_r.nii.gz
sub-brnoUhb07_T1w_RPI_r.nii.gz
sub-brnoUhb08_T1w_RPI_r.nii.gz
sub-pavia04_T1w_RPI_r.nii.gz
sub-perform02_T1w_RPI_r.nii.gz
sub-perform03_T1w_RPI_r.nii.gz
sub-perform06_T1w_RPI_r.nii.gz
sub-cmrra02_T2w_RPI_r.nii.gz
sub-tokyo750w02_T2w_RPI_r.nii.gz
sub-tokyo750w06_T2w_RPI_r.nii.gz
FILES_GMSEG:
sub-brnoUhb01_acq-T1w_MTS_crop.nii.gz
FILES_LABEL:
sub-brnoUhb01_T1w_RPI_r.nii.gz
sub-brnoUhb08_T1w_RPI_r.nii.gz

@valosekj and @PaulBautin thank you for the review 💯
once https://github.com/neuropoly/spinalcordtoolbox/pull/2734 is merged (should be first thing tomorrow), we can merge https://github.com/spine-generic/spine-generic/pull/146, and then you can start doing the manual correction.

FILES SCSEG:
Some files (example) have an unexpected "rms" prefix.

Some files (example) have an unexpected "rms" prefix.

Some Philips sites included T2star as 4D data (all echoes), so we had to average all echoes. We didn't want to overwrite the data so we decided to add the rms suffix. @charleygros how and where is this suffix unexpected? (e.g. are you working in a specific pipeline that is expecting exact file names based on the spine-generic documentation? are you referring to the BIDS convention? (this is a derivatives), etc.). Thanks

Some files (example) have an unexpected "rms" prefix.

Some Philips sites included T2star as 4D data (all echoes), so we had to average all echoes. We didn't want to overwrite the data so we decided to add the rms suffix. @charleygros how and where is this suffix unexpected? (e.g. are you working in a specific pipeline that is expecting exact file names based on the spine-generic documentation? are you referring to the BIDS convention? (this is a derivatives), etc.). Thanks

Sorry... I expressed myself poorly.
I got this issue when using our loader, which look at the image name, eg sub-tokyoIngenia04/anat/sub-tokyoIngenia04_T2star (here), then go in the derivatives/labels folder to grab the associated segmentation with a given suffix, eg _gmseg-manual. So in this example, I would expect to find derivatives/labels/sub-tokyoIngenia04/anat/sub-tokyoIngenia04_T2star_gmseg-manual.nii.gz... which wasn't the case because of this rms suffix!
Does it make sense?
A solution would be to upload  on the repo the average image, ie sub-tokyoIngenia04/anat/sub-tokyoIngenia04_T2star_rms.nii.gz, so that we could use the GT that you generated on the averaged image.

ahhhhh! of course! i didn't think of that problem 🧐.
well that's annoying. I would like to avoid adding processed files under the main BIDS folder (i.e. root/sub-*), as this is against BIDS conventions (i.e. only unprocessed data can go on the root-- the rest is derivatives).
so, I see two solutions:

we create a derivatives/sct/ folder under this repos

problem: people downloading this repos will also download these collateral files (which are specific to a project)

we create another repos, dedicated to ivadomed (or other projects), that only includes the derivatives (labels/ sct/) of interest. Will the loader be happy if you point the "raw" data to derivatives/sct?

^ discussion to be continued to another issue https://github.com/spine-generic/data-multi-subject/issues/13
as this issue is specifically about the manual correction of some of the processed datasets

@valosekj can you please make a yml file with the files listed in https://github.com/spine-generic/data-multi-subject/issues/9#issuecomment-662897952 so i can package you the data for the manual corrections?

@PaulBautin can you please upload a yml file for the files listed in https://github.com/spine-generic/data-multi-subject/issues/9#issuecomment-663263703 so i can package the data for you

@jcohenadad, yml file cannot be uploaded in github comments. Should i send it directly to you or in database_mri slack?

yml file cannot be uploaded in github comments.

well, make it a zip 😉

Here is the zipped yml file with the list of QC false segmentations or labelings for t1w and t2w images
err_file_t1w_t2w.zip

FileNotFoundError: [Errno 2] No such file or directory: 'results-multi_20200722/data_processed/sub-brnoUhb01/anat/sub-brnoUhb01_acq-T1w_MTS_crop_gmseg.nii.gz'

@PaulBautin you probably made a mistake-- sub-brnoUhb01_acq-T1w_MTS_crop.nii.gz is not used for GM seg

Ah, i'm actually not sure about this one. Could you look at it   ==>

you’re looking at warp_template function, not deepseg_gm.

@valosekj can you please make a yml file with the files listed in #9 (comment) so i can package you the data for the manual corrections?

I am attaching yml file below.
Because only SC segmentation is done on DWI data, I included filenames only under FILES_SEG key.
I also included a few subjects with low data quality under FILES_SEG key to verify their images in high-quality:
sub-perform01_dwi_moco_dwi_mean.nii.gz:

sub-beijingVerio02_dwi_concat_moco_dwi_mean.nii.gz:

sub-vuiisAchieva04_dwi_moco_dwi_mean.nii.gz:

How I mentioned in https://github.com/spine-generic/data-multi-subject/issues/9#issuecomment-662897952, there are also subjects with poor template --> dwi registration. In several cases, these subjects are these with bad SC segmentation, so registration of template will be probably improved after manual SC correction.
But also, a few subjects with sufficient SC segmentation have then poor template --> dwi registration, e.g.
sub-ubc02_dwi_moco_dwi_mean.nii.gz
Sufficient SC segmentation:

Poor template --> dwi registration:

Have we determined way how to improve this registration for problematic subjects?
err_file_dwi_valosek_29-07-2020.yml.zip

you’re looking at warp_template function, not deepseg_gm.

Oups my bad, should i remove it from the list or set as a different name of category?

you’re looking at warp_template function, not deepseg_gm.

Oups my bad, should i remove it from the list or set as a different name of category?

please read the doc: https://spine-generic.readthedocs.io/en/latest/analysis_pipeline.html#quality-control

Ok, i have to verify the GM segmentation. sorry for the delay.

Here is the corrected zipped yml file with the list of QC false segmentations or labelings for t1w and t2w images.
err_file_t1w_t2w_corrected.zip

@valosekj can you please make a yml file with the files listed in #9 (comment) so i can package you the data for the manual corrections?

I am attaching yml file below.
Because only SC segmentation is done on DWI data, I included filenames only under FILES_SEG key (I left FILES_GMSEG and FILES_LABEL empty).
I also included a few subjects with low data quality under FILES_SEG key to verify their images in high-quality:
How I mentioned in #9 (comment), there are also subjects with poor template --> dwi registration. In several cases, these subjects are these with bad SC segmentation, so registration of template will be probably improved after manual SC correction.
But also, a few subjects with sufficient SC segmentation have then poor template --> dwi registration, e.g.
sub-ubc02_dwi_moco_dwi_mean.nii.gz
Have we determined way how to improve this registration for problematic subjects?
err_file_dwi_valosek_29-07-2020.yml.zip

--> i'll generate a package and @alexfoias will send it to you
@valosekj i've create a specific issue for DWI data quality: https://github.com/spine-generic/data-multi-subject/issues/14
can you please report the low data quality in this issue, with screenshots from your QC report as you did, but without the segmentation overlaid (so we can look at the data).

@valosekj here are the packaged data:
data_dwi_valosek_29-07-2020.zip

@PaulBautin @valosekj i've clarified the doc for uploading corrected files: https://spine-generic.readthedocs.io/en/latest/analysis_pipeline.html#upload-the-manually-corrected-files

Should a segmentation that cannot be corrected be discarded? What should be done with original subject (non segmented)? example: sub-cmrra02_T2w_RPI_r.nii.gz:

this is just a problem of QC visu— open the actual seg and image.

Hmm, could it be an error while defacing?

sh... indeed, it is. thank you for spotting this @PaulBautin 🏅
@alexfoias please fix this, thanks.

no template warped using sct_warp_template:
sub-mountSinai03_dwi_moco_dwi_mean.nii.gz

@valosekj this is caused by https://github.com/spine-generic/spine-generic/issues/76
so we should indeed exclude this site from the next analysis. I will upload a sct_run_batch.yml in this repository with the sites to exclude.

@PaulBautin related to https://github.com/spine-generic/data-multi-subject/issues/9#issuecomment-665953657
Is it sub-cmrra02_T2w ?

yes, sub-cmrra02_T2w_RPI_r.nii.gz

@jcohenadad I cannot find on duke/sct_testing/bids the multi-subject dataset before defacing. I also looked on duke/mri, but I cannot find cmrra. Do we have somewhere the original data  (I checked in my email but I couldn't find cmrra)?

@alexfoias could you get an old backup from duke? that’s what it’s for

manually-corrected data now released: https://github.com/spine-generic/data-multi-subject/releases/tag/r20200801


Indicate support for RTL

Most views look fine in RTL. Enable it in the manifest.

Coverage decreased (-0.3%) to 33.472% when pulling 31019efbaa85c526a26a3c5c035079541b10de6b on kruton:rtl-layout-support into 94ec21527ffc1d6303234e415e48c71686cae494 on connectbot:master.


Communication Chat - Update WIP preview version (2020-11-01-preview3)

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Changelog

Renaming $maxPageSize to maxPageSize
Referenceing common Error Schema
Add ChatMessageType property and allow sending RichText Html
Mark required properties to indicate they are not nullable.
Expose Message' sequenceId to allow clients to sort message withing the same conversation.

Please ensure to add changelog with this PR by answering the following questions.

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[X] Other, please clarify - Incremental update to our work in progress version in preparation for GA

When you are targeting to deploy new service/feature to public regions? Please provide date, or month to public if date is not available yet.
We're currently in public preview
When you expect to publish swagger? Please provide date, or month to public if date is not available yet.
If it's an update to existing version,  please select SDKs of specific language and CLIs that require refresh after swagger is published.

[X] SDK of .NET (need service team to ensure code readiness)
[X] SDK of Python
[X] SDK of Java
[X] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[ ] No, no need to refresh for updates in this PR

Contribution checklist:

[X] I commit to follow the Breaking Change Policy of “no breaking changes
[X] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

[ ] Ensure to check this box if one of the following scenarios meet updates in the PR, so that label “WaitForARMFeedback” will be added automatically to involve ARM API Review. Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs, all “removals” and “adding a new property” no more require ARM API review.

Adding new API(s)
Adding a new API version
Adding a new service

[X] Please ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If there are following updates in the PR, ensure to request an approval from API Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in stable version
[ ] Removing properties in stable version
[ ] Removing API version(s) in stable version
[ ] Updating API in stable version with Breaking Change Validation errors
[ ] Updating API(s) in preview over 1 year

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

Hello @tjprescott
We are rolling out more updates to our WIP API version in preparation for general availability. This version is not published yet so breaking changes in it would have no impact.

Hello @tjprescott
We are rolling out more updates to our WIP API version in preparation for general availability. This version is not published yet so breaking changes in it would have no impact.


Stop supporting Azure

Focus on platforms that are more integrated, and don't require creating and connecting multiple resources, and are easier for users to track expenses.

[x] Remove Azure-specific files, ie deploy_azure.py.
[x] Remove Azure-specific blocks in simple_deploy.py
[x] Remove Azure-specific tests.
[x] Remove references to Azure in documentation.
[x] Search entire codebase for "azure".
[x] Make sure current unit tests pass.
[x] Make sure current integration tests pass.
[x] Merge back to main.
[x] Search for Azure in any open issues.
[x] Make new release.
[x] Announce changes; goal is to make a stable API while supporting 2-3 platforms.

Rationale

I initially targeted Azure because I was looking for one platform in addition to Heroku, to build out a proof of concept about supporting multiple platforms. I was also learning about Azure deployments at the time.
I don't have anything against Azure for deployment of larger projects. However, I don't think it's well suited for someone's first deployment, and that's the priority in the pre-1.0 phase of this project.
One of the main criteria for platforms to support initially is that it's easy for users to delete a project after they deploy it. This is especially important so that people can be confident they're not going to be accruing charges.
With platforms like Heroku and Platform.sh, you can delete a simple project and know that all of its resources are destroyed. With Azure, where resources like the app and the db are separate, it can be much more difficult for people unfamiliar with the platform to be confident they have truly destroyed everything.
There are some broader aspects of this project to work out, and supporting a more complex platform like Azure makes some of that work harder.
I am not overly familiar with Azure, and it's hard to be confident that I'm taking the best approach to a default initial depoloyment on Azure without more feedback from someone more experienced with Azure deployments.
We can always come back to supporting Azure, and as the overall project becomes more mature it will be easier to reimplement support.
The best reference for current support of Azure, once it's removed, is probably in the version of deploy_azure.py at the time of this writing.

Smaller tasks

[ ] Update code files

[x] Remove files: deploy_azure.py, deploy_messages_azure.py.
[ ] Update simple_deploy.py

[ ] Update tests

[ ] unit tests
[ ] integration tests

[ ] Update docs

[ ] Remove azure_deployments.md
[ ] Update changelog.
[ ] main readme
[ ] cli_args.md
[ ] contributing.md
[ ] integration_tests.md
[ ] unit_tests.md

[ ] Update other files

[ ] manifest

Working notes

[ ] Pass unit tests after removing deploy_azure.py and deploy_messages_azure.py.

13 tests fail initially.
All pass; was a simple import issue. simple_deploy.py still has references to Azure, but they're just CLI args at this point.

It will probably be appropriate to revisit Azure support in the post-1.0 phase. When revisiting Azure support, check out this deployment guide.


fix ttl.md typo in word 'publish'

@KristobalJunta Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.

@pivotal-issuemaster This is an Obvious Fix

@KristobalJunta This Pull Request contains an obvious fix. Signing the Contributor License Agreement is not necessary.

Thank you!


offset partition download

Hello,
i'd like to download one partition in separate parts because phone gets hot after some time and reboots. so i figured out i could do it in parts (eg. 512MB). so is it possible to set offset/size of downloaded data? and how? could you give me some example usage please

after a half day of plugging/unpluging/freezing phone i managed to download whole image using bash to modify partitions.py and set offset/size manuall with increments (i'm not into python so that was the fastest way for me). but i think adding this feature would be nice ;) for cases like mine

i forgot to mention i needed to correct get_partitions procedure. for my d855 it needs to be like this:
name_cmd = 'ls -l /dev/block/platform/msm_sdcc.1/by-name'
not:
name_cmd = 'ls -l /dev/block/bootdevice/by-name'
anyway... great tool! thanks ;)

I have added an --offset option to dump-file.py, is that sufficient to close this issue?

i dont have time to check myself but if it can accept argument like 'from:to' or so then sure it does what i needed :)

If you need to read bytes 100 to 120 (length 20), you would use:
python dump-file.py --offset 100 --size 20

That should be good right? :-) (Can this issue be closed then?)

yup that seems good enough :)

Great, thanks for your feedback!


Python 3 support and new release

Hi. Homebrew maintainer here (Homebrew is a package manager for mac, linux and windows). I wanted to ask what the status is for Python 3 support?
We are going through the list of Python 2 libraries, see https://github.com/Homebrew/homebrew-core/issues/47050.
Any timeline for proper Python 3 support?

It supports python 3 currently in master, so I’ll make a release.

@iMichka Tagged 2.0 and published to pypi

Thanks, it worked! We updated the package here on our side: https://github.com/Homebrew/homebrew-core/pull/48328


expect.instanceOf static

Clear and concise description of the problem
When verifying an object, I'm sometimes only interested in the general shape wihtout needing to know the exact value. For example, the following tests that the mock has been called with an object where req and res are undefined, and event is an H3Event.
const middlewareOpts = middlewareMock.mock.calls[0][0];
expect(middlewareOpts.event).toBeInstanceOf(H3Event);
expect(middlewareOpts.req).toBeUndefined();
expect(middlewareOpts.res).toBeUndefined();

The middlewareMock.mock.calls[0][0] accessor kinda stinks though in my opinion...
Suggested solution
Adding a instanceOf method to ExpectStatic would allow us to do something like this instead:
expect(middlewareMock).toHaveBeenCalledOnce();
expect(middlewareMock).toHaveBeenCalledWith(
  expect.objectContaining({
    res: undefined,
    req: undefined,
    event: expect.instanceOf(H3Event),
  }),
);

Which looks a lot nicer to me (even if it's 4 more rows)
Alternative
Not doing it, since there's already a functional way to doing it
Additional context
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

Just looked again and found out expect.any(H3Event) does this... a bit confused by the name


Allow for using a dockerfile build instead of buildpacks

For existing projects or those without build pack support, it would be nice to give an escape hatch using a dockerfile. (maybe through a --dockerfile option?)
FWIW, Kaniko can do this in a rootless way with similar permissions to the buildpack runner and there's a task in the tekton hub.

This is actually being worked on upstream as an extension of the buildpacks project

Let's close this waitging for news from the buildpacks project.
@agracey if you have any reference that we can link to this issue to track down the development of this it would be nice to have it here. :slightly_smiling_face:


fallback to localstorage

cc @ianstormtaylor

:+1:

me and @ianstormtaylor discussed fallback to temp store a bit and we decided that we should deploy without it, if the environment doesn't have both localStorage and cookies we should why first.


Time wait for toogle in Android

Hello!!!
I want to use this plugin to generate a light that turns on and turn off rapidly (100 milliseconds at about).
In iOs it works very well, but I'm having trouble in android.
Thank you very much for your time.
My idea:
window.plugins.flashlight.available(function(isAvailable) { banSoportaLed = isAvailable; });
intervalColores = $interval(function() {
if(banSoportaLed){
window.plugins.flashlight.toggle();
}
}, 100);
What is the waiting time to turn on and turn off?
Regards!
P/D: The plugin in Android work fine for turn on and off with a button.

My code:
intervalColores = $interval(function() {
if(window.plugins.flashlight.isSwitchedOn()){
window.plugins.flashlight.switchOff(null, null, true);
}else{
window.plugins.flashlight.switchOn();
}
}, 100);
With this code able to improve the speed in android.
But it is still slow than other applications store.
Any Solution??
Thanks


i18n(it): Update nav.ts

Description (required)
Updated the nav.ts to include the latest changes and to correct some mistakes
Related issues & labels (optional)
This is a small part of a bigger list of PRs aimed at bringing the current Italian translation on par with the english version. For the full list click here

I see there is a new e-commerce page in guides section that has been added after the PR has been made.
You might wanna add that one too 💯
Otherwise
LGTM


ManifestMapper feature

As we're using different asset generator in webpack ( https://github.com/ztoben/assets-webpack-plugin ) we need option to format the manifest array before it's stored in cache.
So this is my attempt at adding new option to provide this mapper for ManifestLoader

Hello, thanks for your contribution! At first glance, it looks great. I'll try to give it a proper look during the weekend 🤞


Deprecate the usage of /etc/hardware-exporter-config.yaml

The prometheus-hardware-exporter accept command line flags instead of config file. We should directly render the config file as the command line flag in the hardware-exporter.service.j2. This will reduce our effort to maintain two config files.

@chanchiwai-ray I suspect that most if not all changes would end up in the config file, and not in the systemd service (meaning that we already kind of are maintaining only one of those two). Why would it be better to move the config values to CLI options?

This was only to make the charm code cleaner: we don't need to explicitly render config -> render service -> start service when installing the exporter, but that's more of a refactoring

I'm afraid that we won't handle this one (priority is very low). I will close this request


Feature request: Close on mouse move

Unlike the old/standard Fliqlo project, this is a great project.
I would like the option to have it close on mouse movement, as well as just by click or keypress.
Preferably, I would think this option should be enabled by default as most screensavers close on movement.

It does for me. Exit on mouse movement, that is.

My mouse has a built in sleep feature, so depending on how long my mouse has been inactive I may have to click one of it's buttons to wake it up first. But either way mouse movement closes the screensaver for me too.

I have the screensaver automatically start after 3 minutes, and my mouse does not go to sleep.
After re-checking, it only seems to close if I continue to move the mouse for over a second. Is this an intended feature?

Sounds like an issue with your mouse or maybe pointer speed settings. If my mouse isn't asleep, the screensaver closes with the slightest bit of movement of it.

I believe I have average mouse settings, it only seems to close quickly if I move it agressively.
I have attached my mouse speed settings below, along with the example speed.

After checking the movement event, I have discovered that it does check if it has moved such a distance.
Removing the check closed the program as soon as it started (the mouse moved 0 pixels).
Lowering it from 5 to a lower number (like 2) did not help, but 0 did fixed my problem.
I will make a pull request with the change now, and I hope this helps others who experience the same issue as me.


[BUG]: Thrown/Ammunition Items Not Creating Item Piles on miss

Discord Username
No response
Browsers
Chrome
What Happened?
When a thrown or ammunition weapon attack misses it will not create an item pile. It will go into the target tokens inventory it seems. Can confirm it still works in version 1.0.2 but broke after that point.

Reproduction Steps
1. Set so thrown items create item in target inventory on hit and item pile on miss
2.  On miss it will correctly be placed in the target inventory, on miss however it will also be placed in their inventory even if it should've become an item pile

Relevant Log Output
No relevant output on the logs since this is a normal behavior it's just happening on the wrong condition.

Hi! Thanks for reaching out!
This is a data collection bug that is related to MdiQOL (not their problem, I did something wrong). I'm currently investigating and will update and fix as soon as possible.
Sorry for this inconvenience.


[SPARK-10261][Documentation, ML] Fixed @Since annotation to ml.evaluation

Can one of the admins verify this patch?

add to whitelist

ok to test

Merged build triggered.

Merged build started.

Test build #41874 has started for   PR 8554 at commit 3d64efd.

Test build #41874 has finished for   PR 8554 at commit 3d64efd.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/41874/
Test PASSed.

Merged build triggered.

Merged build started.

Test build #41919 has started for   PR 8554 at commit 2252758.

Test build #41919 has finished for   PR 8554 at commit 2252758.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
class BinaryClassificationEvaluator(@Since("1.2.0") override val uid: String)
class MulticlassClassificationEvaluator (@Since("1.5.0") override val uid: String)

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/41919/
Test PASSed.

Merged build finished. Test PASSed.

Merged build triggered.

Merged build started.

Test build #42064 has started for   PR 8554 at commit 85a3de9.

Test build #42064 has finished for   PR 8554 at commit 85a3de9.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
class BinaryClassificationEvaluator @Since("1.4.0") (@Since("1.4.0") override val uid: String)
class MulticlassClassificationEvaluator @Since("1.5.0") (@Since("1.5.0") override val uid: String)
final class RegressionEvaluator @Since("1.4.0") (@Since("1.4.0") override val uid: String)

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/42064/
Test PASSed.

@yu-iskw Could you make a pass?

Sure! I'll check it.

yu-iskw  could you please reivew this.

@yu-iskw  could you please reivew this.

LGTM

Merged into master. Thanks!


Reverse proxying GRPC calls does not work

1. What version of Caddy are you running (caddy -version)?
Caddy 0.9.5
2. What are you trying to do?
I am trying to use caddy as a reverse proxy to a GRPC server.
3. What is your entire Caddyfile?
See 7. below.
4.
See 7. below.
5. What did you expect to see?
Working GRPC calls.
6. What did you see instead (give full error messages and/or log)?
No errors or log output of any kind. The grpc-server never receives anything from caddy.
The client only sees that the connection was closed by the (caddy) server before any sensible data could be sent or received.
I have sniffed the traffic using wireshark. The entire communication of one call consists of the following steps:

TCP SYN+ACK Client <-> Server
HTTP/2 SETTINGS package Client -> Server
TCP FIN+ACK Client <-> Server (FIN initiated by the sever)

It seems like caddy doesn't know what to do with a SETTINGS package or doesn't support something requested in that package and just terminates the connection.
I know my way around HTTP/1 a little but I don't really know anything about HTTP/2 or SETTINGS packages. The only thing I found out is that a SETTINGS package does not contain any request (GET/POST etc.) and thus no URL. So caddy can't know to which vserver/middleware it should route the package, thus the problem is most likely not in the proxy middleware but somewhere in the initial connection handling. I haven't looked at the caddy code yet though. I will try to come around to doing that soon.
I have researched GRPC proxing and caddy before and I found these related issues. I have created a new one though because I would consider them related but different enough from this to justify a new issue.

#631 Apparently grpc proxing does not work out-of-the-box with go1.6
#54 This seems to ask for a far larger amount of features. I don't need any fancy REST <-> GRPC converter, I simply want to have a caddy server on ports 80/443 and at the same time want to be able to have a grpc server on those ports.

7. How can someone who is starting from scratch reproduce this behavior as minimally as possible?
I have created a little test suite in go, which mostly automates testing if GRPC works. See this repo for the source code, including a Caddyfile with which I tested this.
It provides a go package where you can run go test -v on and it will tell you if everything is working or not.

Does HTTP/2 translates to gRPC compatibility ?

I don't know what you mean exactly. gRPC uses HTTP/2 as its transport layer, so it should be possible.
Here is the gRPC documentation about the wire protocol. I have only skimmed it myself but hope to find the time to read it in depth in the next few days.

Ok, I did some further investigating and it seems that caddy is not actually serving http/2 requests.
I went into the initial (*Server).ServeHTTP in here with a debugger and the request showed the method to be "PRI" which is not actually a valid method but is what a http/1 server would parse if a http/2 client tries to connect to it. See here.

After some reading I found out that most http/2 implementations (including go's net/http) implementation seems to necessitate tls

Yes. :) Spec allows a plaintext variant of HTTP/2 but in practice nobody (really) does this. HTTP/2 in practice requires TLS.

On the direct connection a last HEADERS package after the last DATA package is sent by the server to the client. That package is missing in the caddy -> client communication leading to the "server closed the stream without sending trailers" error.

Perhaps a bug in the recent trailer support that was merged in? I'm just speculating. Maybe @lhecker would know more about this -- he does good work, I'm always glad to have his help. :smile:

This problem is caused by gRPC's server trying to minimize the number of frames they send. The gRPC client on the other hand relies on that behavior. If there's a non-official gRPC solution at either end or in between (like Caddy) it inadvertently breaks down.
It's important to note here that Caddy is extremely likely to be fully HTTP/2 compliant at this point, just like e.g. nghttp2. But both fail to properly proxy gRPC connections, due to the official libraries implementing HTTP/2 quite poorly and thus failing to handle Caddy's/nghttp2's frame ordering.
You can fix your test repo for instance by deleting this code and replacing it with this:
grpcServer := grpc.NewServer()
pb.RegisterTestServiceServer(grpcServer, &testServiceServer{})
http.ListenAndServeTLS(host, "../server.crt", "../server.key", grpcServer)

This will use grpc-go's ServeHTTP method instead, which uses the proper HTTP/2 implementation of Go's stdlib. The downside is that it's quite a bit slower than Serve (relatively - it's still multiple magnitudes faster than e.g. REST APIs).
I'll try to debug Caddy though and see if we can tweak our code somehow to make it work out of the box. I'm not entirely sure if that's possible though since we don't control the actual HTTP/2 framing.

Thanks for the feedback! It indeed works with the changes you provided.

See, I told you @lhecker was a wizard! 🎩
Should I close this issue then?

Alright I found the exact reason why Caddy fails (if someone else wants to debug this as well)… This is the response Caddy receives from the gRPC server:
 1: Framer 0xc42022c8c0: read HEADERS flags=END_HEADERS stream=1 len=14
 2: decoded hpack field header field ":status" = "200"
 3: decoded hpack field header field "content-type" = "application/grpc"
 4: Transport received HEADERS flags=END_HEADERS stream=1 len=14
 5: Framer 0xc42022c8c0: read DATA stream=1 len=28 data="\x00\x00\x00\x00\x17\n\x15This is an echo Test."
 6: Transport received DATA stream=1 len=28 data="\x00\x00\x00\x00\x17\n\x15This is an echo Test."
 7: Framer 0xc42022c8c0: read HEADERS flags=END_STREAM|END_HEADERS stream=1 len=24
 8: decoded hpack field header field "grpc-status" = "0"
 9: decoded hpack field header field "grpc-message" = ""
10: Transport received HEADERS flags=END_STREAM|END_HEADERS stream=1 len=24

Line
Meaning
Caddy code

1-4
response headers
link

5-6
response body
link

7-10
response trailers
link

The issue now is that there is no god damn "Trailer" header coming from the gRPC server!
This causes our code to not be aware that trailers: res.Trailer is nil and len(res.Trailer) will thus return 0.
Since we then don't set the trailer header Go will then silently ignore whatever we set at the end.
If I use ServeHTTP in the gRPC server instead (which again causes it to use the official Go HTTP/2 implementation) it looks vastly different:
  : Framer 0xc420268000: read HEADERS flags=END_HEADERS stream=1 len=41
  : decoded hpack field header field ":status" = "200"
  : decoded hpack field header field "content-type" = "application/grpc"
* : decoded hpack field header field "trailer" = "Grpc-Status"
* : decoded hpack field header field "trailer" = "Grpc-Message"
  : Transport received HEADERS flags=END_HEADERS stream=1 len=41
  : Framer 0xc420268000: read DATA stream=1 len=28 data="\x00\x00\x00\x00\x17\n\x15This is an echo Test."
  : Transport received DATA stream=1 len=28 data="\x00\x00\x00\x00\x17\n\x15This is an echo Test."
  : Framer 0xc420268000: read HEADERS flags=END_STREAM|END_HEADERS stream=1 len=12
  : decoded hpack field header field "grpc-status" = "0"
  : Transport received HEADERS flags=END_STREAM|END_HEADERS stream=1 len=12

Please note the 2 log lines I marked with a star.
I think this issue should stay open since it'd be awesome if gRPC worked out of the box, but I'm not sure how to solve this. Or do you, @mholt?

I'm not familiar with gRPC so I'm afraid I don't know how to fix this either :( It's too bad that gRPC doesn't send a trailers header.
Is it safe to assume if the content-type is application/grpc that trailers will be sent?

Yeah… I also already thought about simply adding a special case just for gRPC. But I noticed just now that the "trailer" header is not a "MUST" but a "SHOULD" in the HTTP RFCs. Even Go's http documentation makes it clear that it should be possible to set trailers without mentioning their names in the "trailer" header first. But strangely it doesn't work in our case.

Hmm. That is odd. Maybe the code we borrowed from the std lib is incomplete, or something?
gRPC does seem popular enough that I wonder if, in the interim, it merits its own special case (an if statement), as long as we tag it with a TODO comment. What do you think? We can either debug what we've got or add a special case.

Fixed it. lol 😎
It still needs a finishing touch though - I'll submit a PR later today or tomorrow. Spoiler: The trick is using http.TrailerPrefix (search for TrailerPrefix) to set unannounced trailers after writing the body, since otherwise they're ignored by Go. Man… Magic string prefixes… And people say Go has a well engineered stdlib… HA! Surprise: It doesn't. ☹
Anyways @mholt: Say… How adamant are you about the ordering of these parameters. That a copy operation is not ordered left-to-right grinds my gears to a halt. Really. 😂 I'd really like to change it to src -> dst instead, but if you don't want any unnecessary changes like that I won't touch it of course.

Boy have I stared an avalanche. 😁
I guess this is the moment for praise:
I love caddy and the community around it! You people are just lovely.
@mholt Great work on maintaining this project and I am positively surprised how present you are in each and every issue submitted! 👍
@lhecker Brilliant work too, thanks so much for going way deeper than I would have managed with this problem. 👍
Thanks to you all!

@lhecker Awesome, nice job! I am surprised that it was the header string prefixes. I'm sure there is a reason they did it that way... it does seem a little hacky though. Oh well.
The (dst, src) ordering is that way because, I think, tradition. This is how memcpy works in C. Also, that's how the io package copy's methods are designed. I agree it's a little weird, but that seems to be normal. 🤷♂
I await the PR. :) Bonus points if it has a test!

@mholt I changed a few more things apart from the above. 😶
For instance I split up ReverseProxy.ServeHTTP() into a ReverseProxy.serveRegular() and ReverseProxy.serveWebsocket() to finally make that method a little bit smaller and easier to read.
I also optimized copyHeader: This just wastes precious CPU cycles while Go is busy canonicalizing the header name. It's unnecessary since the header name is already canonicalized of course (since it's coming from a http.Header and not a random source). One can just write it as dst[k] = append(dst[k], vv...) which is shorter and faster!
Well… stuff like that. I'll split it up in different commits to make it easier to revert just in case.

Sounds great @lhecker! Thanks.

@targodan Are you able to build from source? I haven't had a chance to review @lhecker's PR yet but would you be able to build with his patch and see if it works for you?

This didn't seem to fix it. Or I did something wrong.
This is what I did:
git clone https://github.com/mholt/caddy.git
cd caddy
git checkout a2261e610bd27426c2a4f07a066ed706ca0e9e49
cd caddy
./build.bash
sudo ./caddy -conf .......

Then I ran my test again from here and I still got the following error:
client_test.go:163: Error while reading from stream.
client_test.go:164: rpc error: code = Internal desc = server closed the stream without sending trailers

@mholt @targodan I'm currently in the process of moving which is why I'm so short on time regarding this bug.

This didn't seem to fix it. Or I did something wrong.

Either I did something wrong when testing your code or you indeed did something differently or wrong.
Here's what I did:

I applied the following changes to make the code compile correctly

NOTE: With Go you should try and set up a workspace and always use fully specified import paths instead of relative ones.
diff --git a/client/client.go b/client/client.go
index 145ebe4..129a336 100644
--- a/client/client.go
+++ b/client/client.go
@@ -6,7 +6,7 @@ import (
 	"crypto/tls"
 	"os"

-	"./pb"
+	"github.com/targodan/caddyGrpcTest/client/pb"
 	"google.golang.org/grpc"
 	"google.golang.org/grpc/credentials"
 )
diff --git a/client/client_test.go b/client/client_test.go
index 6cd1215..15c4dbc 100644
--- a/client/client_test.go
+++ b/client/client_test.go
@@ -8,7 +8,7 @@ import (
 	"strings"
 	"testing"

-	"./pb"
+	"github.com/targodan/caddyGrpcTest/client/pb"
 )

 var connHosts []string
diff --git a/server/main.go b/server/main.go
index d5640ce..d369c9f 100644
--- a/server/main.go
+++ b/server/main.go
@@ -2,7 +2,7 @@
 //go:generate protoc -I "../proto/" "../proto/service.proto" --go_out=plugins=grpc:server/pb
 package main

-import "./server"
+import "github.com/targodan/caddyGrpcTest/server/server"
 import "os"
 import "fmt"

diff --git a/server/server/server.go b/server/server/server.go
index d2e2974..bd92f5c 100644
--- a/server/server/server.go
+++ b/server/server/server.go
@@ -7,7 +7,7 @@ import (
 	"net"
 	"os"

-	"./pb"
+	"github.com/targodan/caddyGrpcTest/server/server/pb"

 	"golang.org/x/net/context"

Compiled caddy

git pull --all
git checkout fix_1502
cd caddy
./build.bash

Compiled caddyGrpcTest

cd client
go generate
cd ../server
go generate

Start caddy

sudo ./caddy -conf Caddyfile -host localhost -port 443 -log=stdout

Start the server (in terminal tab 1)

cd server
go run main.go ":4242"

Run the client tests directly (in terminal tab 2)

cd client
TEST_HOSTS="<IP_ADDRESS>:4242" go test

Results in:
PASS
ok  	github.com/targodan/caddyGrpcTest/client	0.034s

Run the client tests over caddy (in terminal tab 2)

TEST_HOSTS="<IP_ADDRESS>:443" go test

Results in:
PASS
ok  	github.com/targodan/caddyGrpcTest/client	0.033s

Did I do something wrong here?

Sorry, I made the mistake. 🙈
I compiled caddy outside of the gopath wich propably caused it to use the not-updated version from my gopath for any imports.
The fix works. 😄
PS: I didn't close the issue yet because I don't know if you guys keep issues open until the release is out or not. As far as I am concerned it can be closed.


Inconsistent bower.json

Currently, bower.json declares the javascript files under src/ as main files, but also ignores the source folder.
As a consequence, when trying to use the package with bower, only the minified files under dist/ get installed, but the (broken) references to the original source files get inserted as managed dependencies.
My suggestion would be not to ignore the src/ folder, which includes the sources in the package. Alternatively, one could change the main files to be from dist/, but this would make it harder to use the non-minified sources for development.

Moreover, bower.json references a file nga11yfocus.css, which does not seem to exist.

I believe I have this fixed in version 0.0.8 - can you validate?

src/ is now properly visible, but the source file nga11yfocus.js is missing in the declaration.

OK, now I have all the src files and the dist files in the main section so that both minified and unminified versions are available in the published repo

Which commit is this? I see no changes to bower.json in the published 0.0.10 release... Did this get lost maybe?

grrr...merge failure and trying to get something done too quickly...0.0.11 should now finally be fixed

Just tried 0.0.11, but the results are still not what I was expecting (though I must say that my bower experience is still somewhat limited).
Some background:

We are using 'grunt wiredep' to automatically wire dependencies into the main html file.
The setup was generated by a vanilla yeoman setup for angular, so I would expect that it is fairly standard.
The wiredep tool simply takes all the main files from bower and puts them into the index.html file.

So the result now is, that I get BOTH the original as well as the minified files into my index.html.
Looking at the spec, it seems to suggest that one should not declare minified files here.
Sorry for the confusion, but I am just trying to make 'convention over configuration' actually work :-)

@alexkrauss thanks for that additional information. I somehow missed that bower is not supposed to have minified files in the main. I have updated it now.

Works now with 0.0.12. Thanks.


Remove Appveyor support for Linux

Linux support on Appveyor has slowed the Appveyor CI down to the point where it is slower than Travis. I don’t see much point keeping it.

Agreed.


LinkedList Implementation of Stack in C++.

Hi @aaryahjolia
I am Shivansh Jain. I want to contribute by adding linkedlist implementation of stack in C++ language. Kindly assign me this task for GSSoc'23.

Hi, I am Tanisha Saini. I have a strong expertise in C++ & DSA. I want to contribute to this issue. please assign it to me for GSSOC'23.

Hey @aaryahjolia .
I'm Vyshnavi , a contributor in GSSOC'23.
Can you please assign this to me in c++.

Hi @aaryahjolia,
I am a GSSOC contributor.
Can you please assign this to me.


Video aspect ratio issues

It seems that osu!stable masks all videos to 4:3 if there are no WidescreenStoryboard option, while osu!lazer stretches all backgrounds and videos to full width maintainig their original aspect ratio, regardless of settings. osu-parsers and osu-js use osu!lazer's implementation with unmasked video layer.
And now we have the situation, where i stretched all backgrounds to full width and you disabled video stretching at all in the latest update. The thing i want to say is if beatmap has WidescreenStoryboard enabled with 16:9 background and non 16:9 video, that can cause next rendering issue:

Possible solution to this can be stretching all videos as it's done in osu!lazer. I prefer stretching videos and backgrounds more than than leaving blank space on the sides, since it allows you to fit everything to one size.

Changing the scaling policy to the full width is also limited to the playfield size which is not a 16:9.


04/24/2018 02:35 : Create Pull Request for branch prTesting_2018042402 -> master

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

split/updateTestRef.md
:white_check_mark:Succeeded

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.


Test failure: TestInvalidRequestLines

This test fails occasionally with the following error:
System.NullReferenceException : Object reference not set to an instance of an object.
   at System.Collections.Generic.Dictionary`2.FindEntry(TKey key)
   at System.Collections.Generic.Dictionary`2.TryGetValue(TKey key, TValue& value)
   at Castle.DynamicProxy.ModuleScope.GetFromCache(CacheKey key)
   at Castle.DynamicProxy.Generators.BaseProxyGenerator.GetFromCache(CacheKey key)
   at Castle.DynamicProxy.Generators.BaseProxyGenerator.ObtainProxyType(CacheKey cacheKey, Func`3 factory)
   at Castle.DynamicProxy.Generators.ClassProxyGenerator.GenerateCode(Type[] interfaces, ProxyGenerationOptions options)
   at Castle.DynamicProxy.DefaultProxyBuilder.CreateClassProxyType(Type classToProxy, Type[] additionalInterfacesToProxy, ProxyGenerationOptions options)
   at Castle.DynamicProxy.ProxyGenerator.CreateClassProxyType(Type classToProxy, Type[] additionalInterfacesToProxy, ProxyGenerationOptions options)
   at Castle.DynamicProxy.ProxyGenerator.CreateClassProxy(Type classToProxy, Type[] additionalInterfacesToProxy, ProxyGenerationOptions options, Object[] constructorArguments, IInterceptor[] interceptors)
   at Moq.Proxy.CastleProxyFactory.CreateProxy(Type mockType, ICallInterceptor interceptor, Type[] interfaces, Object[] arguments)
   at Moq.Mock`1.<InitializeInstance>b__20_0()
   at Moq.PexProtector.Invoke(Action action)
   at Moq.Mock`1.InitializeInstance()
   at Moq.Mock`1.OnGetObject()
   at Moq.Mock.GetObject()
   at Moq.Mock.get_Object()
   at Moq.Mock`1.get_Object()
   at Microsoft.AspNetCore.Server.Kestrel.InMemory.FunctionalTests.BadHttpRequestTests.TestBadRequest(String request, String expectedResponseStatusCode, String expectedExceptionMessage, String expectedAllowHeader) in /_/test/Kestrel.InMemory.FunctionalTests/BadHttpRequestTests.cs:line 202
--- End of stack trace from previous location where exception was thrown ---
------- Stdout: -------
| [0.001s] TestLifetime Information: Starting test TestInvalidRequestLines-" / HTTP/1.0
|                                    -Invalid request line: '" / HTTP/1.0\x0D\x0A' at 2018-09-11T20:08:19
| [0.047s] TestLifetime Information: Finished test TestInvalidRequestLines-" / HTTP/1.0
|                                    -Invalid request line: '" / HTTP/1.0\x0D\x0A' in 0.0439119s

Other tests within that build may have failed with a similar message, but they are not listed here. Check the link above for more info.
This test failed on 2.2.
CC @muratg
This issue was made automatically. If there is a problem contact ryanbrandenburg.

Please use this workflow to address this flaky test issue, including checking applicable checkboxes and filling in the applicable "TODO" entries:

Is this actually a flaky test?

No, this is a regular test failure, fix the test/product (TODO: Link to commit/PR)
Yes, proceed below...

Is this test failure caused by product code flakiness? (Either this product, or another product this test depends on.)

[ ] File a bug against the product (TODO: Link to other bug)
Is it possible to change the test to avoid the flakiness?

Yes? Go to the "Change the test!" section.
No?

[ ] Disable the test (TODO: Link to PR/commit)
[ ] Wait for other bug to be resolved
[ ] Wait for us to get build that has the fix
[ ] Re-enable our test (TODO: Link to PR/commit)
[ ] Close this bug

Is it that the test itself is flaky? This includes external transient problems (e.g. remote server problems, file system race condition, etc.)

Is there is a way to change our test to avoid this flakiness?

Yes? Change the test!

[ ] Change the test to avoid the flakiness, for example by using a different test strategy, or by adding retries w/ timeouts (TODO: Link to PR/commit)
[ ] Run the test 100 times locally as a sanity check.
[ ] Close this bug

No?

Is there any logging or extra information that we could add to make this more diagnosable when it happens again?

Yes?

[ ] Add the logging (TODO: Link to PR/commit)

No?

[ ] Delete the test because flaky tests are not useful (TODO: Link to PR/commit)

This comment was made automatically. If there is a problem contact ryanbrandenburg.

Same as https://github.com/aspnet/Mvc/issues/8157, parking on @dougbu 's plate.

I'm going to close this issue as dupe since there's a tracking issue in MVC.


[NCL-3548] Update swagger def to PNC 1.3.0 REST

This is the initial PR to update the Swagger REST definitions to the current PNC 1.3.0 REST endpoints.
A separate PR will be created to add flags to use the temporary build feature. I want to create 2 separate PRs to make the PR review easier.
Notable changes are the imports in the __init__.py. We don't use any of those models since we really use the <Model>Rest classes instead in the Swagger definitions.
Lots of APIs got changed to support temporary builds. There's also a rename of 'rebuildAll' to 'forceRebuild' for the build method in build configuration set API. The relevant code using that method got updated for the rename.

@janinko  Yup swagger autogenerated, and I did a tiny change on our side for the rename of 'rebuildAll'

Thanks for the review! :)


EDITOR. New node id after update is displayed as root node

And the root node has 'direc parent : ' with no id.

It was due to different value.
But there is even more. Need to fix it


Use explicit relative imports

switch from implicit relative imports to explicit relative imports as recommended by Guido: https://peps.python.org/pep-0328/#guido-s-decision
sort import order using isort

close #508

Could you please fix the CI errors?

Do the scripts actually run correctly when using relative imports?
In my experience, if you use relative imports like that and you run the scripts in the normal way, like
python3 pruned_transducer_stateless2/decode.py
you get errors like "cannot use relative import because decode.py is not part of a package"
(this is from memory, may not be exact).
That's why I don't tend to use them.


Updated validations.py script

Closes: #1
Updated validations.py python script
Fixed the behaviour of validate_user function in validations.py
Fixes #<issue_number_goes_here>

It's a good idea to open an issue first for discussion.

[ ] Tests pass
[ ] Appropriate changes to README are included in PR

@googlebot I signed it!


[Bug]: Cannot use bazel vendor with grpc module

What happened?
I tried to use bazel vendor and got an error:
ERROR: in tag at https://bcr.bazel.build/modules/grpc-java/1.62.2/MODULE.bazel:89:15: no repository visible as '@com_google_protobuf_javalite' to the repository '@@grpc-java~', but referenced by label '@com_google_protobuf_javalite//:protobuf_javalite' in attribute 'target' of tag 'override'. Is the module 'grpc-java' missing a bazel_dep or use_repo(..., "com_google_protobuf_javalite")?
    Fetching module extension maven in @@rules_jvm_external~//:extensions.bzl; starting

Version
Development (host) and target OS/architectures:
Linux.
Output of bazel --version:
coryan@corws:~/repros/bzlmod-vendor$ bazel --version
bazel 7.2.1

Version of relevant rules from the WORKSPACE or MODULE.bazel file:
bazel_dep(name = "rules_cc", version = "0.0.9")
bazel_dep(name = "grpc", version = "1.63.1.bcr.1")

Language(s) and/or frameworks involved:
C++
How to reproduce
Create a small MODULE.bazel file

# cat MODULE.bazel
"""Repro a problem with `bazel vendor` and gRPC."""

module(name = "bzlmod-vendor")

bazel_dep(name = "rules_cc", version = "0.0.9")
bazel_dep(name = "grpc", version = "1.63.1.bcr.1")
------

And then try to use it:

# bazel vendor --vendor_dir=vendor

Any other information?
No response

FWIW, bazel vendor seems to work well with the development version of Bazel:
USE_BAZEL_VERSION=last_green bazelisk vendor --vendor_dir=/tmp/vendor //:all //generator/... //docfx/...

However, bazel mod deps remains broken:
USE_BAZEL_VERSION=last_green bazelisk mod deps //:all
ERROR: in tag at https://bcr.bazel.build/modules/grpc-java/1.62.2/MODULE.bazel:89:15: no repository visible as '@com_google_protobuf_javalite' to the repository '@@grpc-java~', but referenced by label '@com_google_protobuf_javalite//:protobuf_javalite' in attribute 'target' of tag 'override'. Is the module 'grpc-java' missing a bazel_dep or use_repo(..., "com_google_protobuf_javalite")?. Type 'bazel help mod' for syntax and help.

FWIW, bazel vendor seems to work well with the development version of Bazel:

The vendor command is still somewhat experimental; so it's expected that older versions of it might be broken. We'll try to "officially" launch the vendor command in 7.3.0.

However, bazel mod deps remains broken:

grpc-java version 1.62.2 has a bug (missing a use_repo declaration). bazel mod deps runs all extensions, which unearths this bug. It has been fixed in 1.64.0.

Shouldn't grpc be fixed to refer to a non-buggy version of grpc-java?  Or maybe it should not use grpc-java at all?  It is not clear to me that it needs it.
And shouldn't you yank grpc-java 1.62.2 then?

Shouldn't grpc be fixed to refer to a non-buggy version of grpc-java?

I believe the dependency comes transitively from googleapis, which indeed needs fixing. I'm working on it right now.

And shouldn't you yank grpc-java 1.62.2 then?

We normally only yank module versions that have security vulnerabilities, or are just outright unusable. Having a bug does not immediately warrant yanking. (Plus, yanking 1.62.2 would just mean you'd get an error message saying it was yanked; you'd still need to introduce a higher version of it into your dep graph to build successfully.)

And shouldn't you yank grpc-java 1.62.2 then?

We normally only yank module versions that have security vulnerabilities, or are just outright unusable. Having a bug does not immediately warrant yanking. (Plus, yanking 1.62.2 would just mean you'd get an error message saying it was yanked; you'd still need to introduce a higher version of it into your dep graph to build successfully.)

Ah, that makes sense.  Thanks for taking the time to explain.

Shouldn't grpc be fixed to refer to a non-buggy version of grpc-java?

I believe the dependency comes transitively from googleapis, which indeed needs fixing. I'm working on it right now.

FWIW, I was able to override googleapis in google-cloud-cpp to use a much smaller MODULE.bazel  patch and fewer dependencies:
https://github.com/googleapis/google-cloud-cpp/blob/8c9b8525fdab9a48b45d93292b5ca2b84605fee3/bazel/googleapis.modules.patch#L29-L48
Though I realize that may not work in the context of BCR.


Remove Screen-parameter for determining Touchscreen capability

Previously the current Viewport was used to determine the Window Manager Screen. This didn't work for SubViewports.
fix #67505
fix #64687
DisplayServer::screen_is_touchscreen will likely never utilize its parameter p_screen.
This PR replaces this function by DisplayServer::is_touchscreen_available() with the same functionality.
This solves the problem, that a SubViewport was used for determining the screen, which resulted in error messages.
Updated 2022-11-03: Fix merge conflict
Updated 2022-11-24: Fix more locations that have the same problem
Updated 2022-12-06: Updated based on conversation in RocketChat: parameter p_screen of screen_is_touchscreen should be removed, because it is unlikely that it will ever get implemented.

Thanks!


[PE-D][Tester B] Bug on name

Some name may contains . or / in between and also the display result is not shown correctly to the error raised. Example of an Western name and a Malay name respectively

Labels: severity.High type.FunctionalityBug
original: huanghao1998/ped#5

Our feature is able to tolerate majority of possible user inputs, and the users are also given plenty of room to work around implemented conditions. Deemed not a bug, hence closed.


Upgrade Play! version from 2.6.17 to 2.6.20

Upgrade:

Play! version from 2.6.17 to 2.6.20,
Twirl version from 1.3.14 to 1.3.15.

New 1.0.0-rc4-SNAPSHOT snapshot deployed


Fix documentation generation

The generation of the API docs is currently broken because it has not yet been ported from the ias.cs.tum.edu domain. Either
a) manually install API docs on knowrob.org, or
b) set up automated doc generation and deployment (preferred)

Is this still unresolved? At least I can't read the API documentation. I would highly appreciate, if I can get access to the json_prolog API documentation.
Thank you!

I have not looked into doc generation yet, sorry.
Will do that later this year.


Made the ingress annotations variable & fixed secret in the JAVA_OPTION_TOOLS

See Comments in #30 , that one can be closed,  this is de new one. I couldn't cherry-pick the changes into the old pull request.

There are still some issues:
When I clone this chart chart:
and do an install with like:
cd charts/alfresco-search-services
helm upgrade --install search -f values.yaml -f values-local.yaml .
Everyting works fine!
Then I package this chart with helm package alfresco-search-servies
Then I create a new chart
version: 1.0.2
dependencies:
  - name: alfresco-search-service
    repository: oci://harbor.contezza.nl/alfresco-helm-charts
    version: 1.0.2-753eb3e
    condition: alfresco-search.enabled

Then it firstly complains about a backend port in the ingress, so I add this to the yaml file:
  service:
    externalPort: 80

So my new yaml file is then:
global:
  tracking:
    auth: secret
    sharedsecret: secret

alfresco-search-service:
  searchServicesImage:
    repository: alfresco/alfresco-search-services
    tag: 2.0.6
  ingress:
    enabled: true
    hostName: localhost
    basicAuth: YWRtaW46JGFwcjEkVVJqb29uS00kSEMuS1EwVkRScFpwSHB2a3JwTDd1Lg==
  resources:
    requests:
      memory: "1000Mi"
      cpu: "1000m"
    limits:
      memory: "4000Mi"
      cpu: "2000m"
  environment:
    SOLR_HEAP: "3g"
    SOLR_JAVA_MEM: "-Xms2g -Xmx3g"
  service:
    externalPort: 80

Then I get a non working ingress locally als on the Kubernetes cluster

So this piece of code is still probably not working:
    {{- if .Values.ingress.hostName }}
    host: {{ tpl .Values.ingress.hostName . }}
    {{- end }}

Hi @shazada ,
It sounds pretty strange you get this error with the packaged charts but not with the local sources.
Regarding the externalPort this is something I saw and addressed using the $servicePort instead of the value itself.
All other occurrence of this values are defaulted and I could not reproduce the issue.
I have done the following:

Create a master chart cd /tmp && helm create mychart
Checkout your branch in a different folder
Package the chart as-is helm package . -d /tmp/mychart/charts/
Add the following dependency to /tmp/mychart/Chart.yaml:dependencies:
   - name: alfresco-search-service
     version: 1.0.2

6. Copy your example values file (without the `.service.externalPort` value) to `/tmp/mychart/more-values.yaml`
7. run helm template: `helm template /tmp/mychart -f more-values.yaml`

This gives me no error and the following ingress:

```yaml
---
# Source: mychart/charts/alfresco-search-service/templates/ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: release-name-alfresco-search-service-solr
  annotations:
    nginx.ingress.kubernetes.io/auth-secret: release-name-alfresco-search-service-ingress-secret
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/auth-realm: Authentication Required - Alfresco Search
      Services
    nginx.ingress.kubernetes.io/auth-type: basic
    nginx.ingress.kubernetes.io/whitelist-source-range: <IP_ADDRESS>/0

spec:
  rules:
  - http:
      paths:
      - path: /solr
        pathType: Prefix
        backend:
          service:
            name: release-name-alfresco-search-service-solr
            port:
              name: solr
    host: localhost

This sounds all good to me tbh. I'm wondering if you may have mised up version and you're not pulling the charts you think you are pulling.
At this point. I'm pretty confident moving forward with the PR and proceed to CI build/tests.
To do so we would however need you bump the Chart.yaml & Chart.lock files (otherwise CI will complain).
I would recommend using a pre-release like 1.0.3-alpha.1

Sorry I was a off for a few days, I'll respond asap.

Wat do you mean by:
To further proceed please bump the chart version to a pre-release so we can kick start tests
?

And it's difficult for me to keep changing the chart if weeks go by, this chart is already in Acceptance at the customer and is now being reviewed by the customer. So I can't keep changing versions and try different charts. Hopefully we can just accept this version and if it also works on your side and then see if we can keep improving the chart.

And it's difficult for me to keep changing the chart if weeks go by, this chart is already in Acceptance at the customer and is now being reviewed by the customer. So I can't keep changing versions and try different charts. Hopefully we can just accept this version and if it also works on your side and then see if we can keep improving the chart.

Yes, I understand. We've been you and I successively off for weeks which didn't help...
The problem at the moment is that there are conflicts between your branch and the main branch of our repo that needs resolving.
I your customer is currently reviewing this exact branch/code, maybe the best for this time would be for you to package and server the chart from this branch and serve it via your own chart registry for this version?
We can branch from Contezza:Contezza/main and open a new PR where we resolve conflicts and merge to release a 1.1.0-prerelease so you Contezza:Contezza/main remains what your customer is reviewing?

Hi @shazada,
I was working on branching and resolving conflict and add tests. The tests actually showed the resulting ingress is kind of broken in case someone wants to setup another ingress type due to the type of values merging helm does:
# Source: alfresco-search-service/templates/ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: release-name-alfresco-search-service-solr
  annotations:
    haproxy.org/auth-realm: My custom Realm requires auth
    haproxy.org/auth-secret: staging/solradmin
    haproxy.org/auth-type: basic-auth
    haproxy.org/whitelist: <IP_ADDRESS>/24
    kubernetes.io/ingress.class: haproxy
    nginx.ingress.kubernetes.io/auth-realm: Authentication Required - Alfresco Search Services
    nginx.ingress.kubernetes.io/auth-type: basic
    nginx.ingress.kubernetes.io/whitelist-source-range: <IP_ADDRESS>/0

Even though the nginx annotations are completely absent from the helm values passed at install time.
For that reason I have removed the ingressclass annotation from the value file as anything else but nginx id likely to work as expected at present time. Other nginx annotation can still be added to the values and should override as expected.
Pending PR here: https://github.com/Alfresco/alfresco-helm-charts/pull/52/files

superseeded by #52


unexpected keyword argument 'params'

I'm getting this error when I run the file.  I got the access token with my firebase API and loaded it on the library but when I try to get the fields I got the following error.
Traceback (most recent call last):
File "", line 17, in
File "/lib/ufirestore/ufirestore.py", line 229, in get
File "/lib/ufirestore/ufirestore.py", line 104, in get
File "/lib/ufirestore/ufirestore.py", line 52, in send_request
TypeError: unexpected keyword argument 'params'

I am also getting same error, i think it might be due to b/c we are using latest version of micropython


Updated base.yaml

added libqt5x11extras5-dev for ubuntu

I'll merge this but if you want to release something it's strongly recommended to add fedora and debian rules in addition to ubuntu rules.


Fix arcade daily pipeline

(Opening this issue manually while https://github.com/dotnet/dnceng/issues/4405 is preventing automatic issue creation)
Fix the arcade-daily pipeline to make sure secrets are properly cycled.
https://dnceng.visualstudio.com/internal/_build?definitionId=1020

Release Note Category

[ ] Feature changes/additions
[ ] Bug fixes
[ ] Internal Infrastructure Improvements

Release Note Description

Well, fixed one secret... gotta fix another :D

Pipeline is working again. Closing.


Slider's minimum and maximum value

the ability to set the minimum and maximum values for the volume slider

Can you describe this more? My understanding is set lowest value that slider allow you got and highest value right? So if normal slider goes from 0-100 and you want to limit to 30-70 that means volume can only be in between right?

Yes


loading pretrain model

how is it possible to use the API for loading a pre-train model?

Currently not all the models support pre-trained models. Mean algorithm is one of them that supports pre trained model.
Specify this in the algorithm 'pretrained-model-path:'folder_name'.'  This is for loading a pre-trained model.
Specify this in the algorithm 'save-model-path':'folder_name' to save a model. This is  for saving thr model.

We are looking for contributors to contribute the part for saving and loading algorithms.


fix trash_move

the same as https://github.com/arsenetar/send2trash/pull/41
this bug prevents using jupyter* in research environments where file systems aren't always local
e.g. https://github.com/jupyterlab/jupyterlab/issues/5781 and our own use at https://cri.uchicago.edu/
cc @annawoodard

As mentioned over at https://github.com/arsenetar/send2trash/pull/41#issuecomment-765086792 this appears to be an issue with not detecting device mounts correctly.  The current implementation in send2trash is supposed to try the following:

User's home trash if the file is on the same device
The top directory trash of the device (.Trash) where the file exists
The user specific top directory trash of the device (.Trash-uid) where the file exists

send2trash does not currently support trashing across mounts and should detect this and fail before the move (based on comments in various threads this seems this is not the case as noted prior).  We can add the implementation of:

If both (1) and (2) fail (that is, no $topdir/.Trash directory exists, and an attempt to create $topdir/.Trash-$uid fails), the implementation MUST either trash the file into the user's “home trash” or refuse to trash it."

where send2trash adds a 4th option of trashing to the user's home if 1-3 are not applicable.  However, this is not going to address the error in this case from what I am seeing as the device checks or related items are failing upstream of the actual move call.
Testing this in Debian with a mounted drive results in expected behavior, network drives should behave the same as well, although I know there are numerous different types. Locking at jupyterlab/jupyterlab#5781 I noticed that there may have been a symlink involved although in my testing links both to files and parent folders appear to result in the expected behavior.
From #26 it seems like this might have something to do with this as well:

Now, /vol/test and /vol/test2 have the same device, but each of them mounts on different point.

I'll look into that case.

although I know there are numerous different types

I cannot begin to cover how widely varied NFS are on research clusters - you're talking about everything from samba (i.e. your run of the mill home networking type thing) to gpfs (which we use to support summit the #1 machine on the top500). I'm not sure what the exact idiosyncrasies of trash files are but I'm also not sure why this solution shutil + os.remove is so flawed that it would warrant preventing researchers from using jupyter. Granted you're not the maintainer of jupyter and arguably they should fork (or something) but I just don't see what the problem is with merging my solution (or anyone else's solution) as a reasonable fix to a serious blocker for lots of people.

Looking into #26, I can reproduce the error as described, so I image this is actually the root cause.  Mounts on the same device return the same device id, however in terms of what is considered a device to underlying tools they are not considered the same device.  Likely the issues being encountered in jupyter are related to this.  It would be great to know what the arguments to trash_move() and their respective stat output is for the failing cases to fully identify those issues.
The fix in this PR as well as #41 may not be addressing the root issue.  I can see one case where the behavior of os.rename() may be incorrect, but have others where it may be correct as well and "fixing it" with shutil + os.remove would be incorrect behavior.  Since stat and rename disagree on what they consider a device, I am looking for clarification from the freedesktop.org on the Trash specification's intention in these sort of scenarios.

There is a published pre-release package at https://pypi.org/project/Send2Trash/1.8.1b0/ should address most causes of the issues, if there are still issues, I will need more details on the specific environments.


Wheels for pyodide/pyscript

Hi!
I'm curious, is it possible to create wheels that would target pyodide in order to use rdkit as python package through pyscript? And if it is, do you think that it's a good idea to invest into that?
I know that there is rdkit.js as a fall back option, but still I want to ask this question as I think for python users would be more intuitive to install pypi package instead of setting up JS object.
Here is a code snippet to try to install rdkit
<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Add rdkit to pyscript</title>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <link href="css/style.css" rel="stylesheet">
<!-- Add pyscript link -->
    <link rel="stylesheet" href="https://pyscript.net/latest/pyscript.css" />
    <script defer src="https://pyscript.net/latest/pyscript.js"></script>
    <py-config>
      terminal = false
      docked = false
      packages = ["rdkit"]

      [splashscreen]
      autoclose = true

      [[interpreters]]
      src = "https://cdn.jsdelivr.net/pyodide/v0.23.4/full/pyodide.js"
      name = "pyodide-0.23.4"
      lang = "python"

    </py-config>
  </head>
  <body>

  </body>
</html>

Hi. This is a great idea, and I've already looked into this. Currently, Pyodide isn't supported by cibuildwheel, which I use for building the Python wheels. However, there are intentions to provide support (https://github.com/pypa/cibuildwheel/issues/1454), and once this integration is completed, I'll revisit the idea.

Cool!
Thank you for the fast response and the great work on this project in general :)
Just out of curiosity, will there be an opportunity to help out with this because it will "just work (c) Todd Howard" or it will actually work without any additional effort? :)

Sure, thanks for offering to help. I hope it will just work; but due to the build dependencies of RDKit, I believe this will be challenging (even after cibuildwheel has support).

I will leave this issue open then :)

Is there any update on this?

I get that Pyodide wheels would be fantastic, but without cibuildwheel's support for Pyodide, it's going to be a challenge. Even if cibuildwheel does support Pyodide, another hurdle will be building the Boost library (and possible others libraries) for Pyodide.
However, please feel free to open a PR for that.

Seems like the cibuildwheel issue is resolved.
I can try to look into it
https://github.com/pypa/cibuildwheel/pull/1456

Thanks, that'd be wonderful.


Exception 400 from http://localhost:50342/oauth2/token

This is autogenerated. Please review and update as needed.
Describe the bug
Command Name
az webapp list
Errors:
400 Client Error: Bad Request for url: http://localhost:50342/oauth2/token
Traceback (most recent call last):
python3.6/site-packages/knack/cli.py, ln 215, in invoke
    cmd_result = self.invocation.execute(args)
cli/core/commands/__init__.py, ln 631, in execute
    raise ex
cli/core/commands/__init__.py, ln 695, in _run_jobs_serially
    results.append(self._run_job(expanded_arg, cmd_copy))
cli/core/commands/__init__.py, ln 688, in _run_job
    six.reraise(*sys.exc_info())
...
python3.6/site-packages/msrestazure/azure_active_directory.py, ln 598, in set_token
    self.scheme, _, self.token = get_msi_token(self.resource, self.port, self.msi_conf)
python3.6/site-packages/msrestazure/azure_active_directory.py, ln 486, in get_msi_token
    result.raise_for_status()
python3.6/site-packages/requests/models.py, ln 940, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 400 Client Error: Bad Request for url: http://localhost:50342/oauth2/token

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az webapp list

Expected Behavior
Environment Summary
Linux-4.15.0-1077-azure-x86_64-with-debian-stretch-sid
Python 3.6.5
Installer: DEB

azure-cli 2.4.0 *

Additional Context

webapp

hi @pourpak are you met the issue on Cloudshell? If yes, this is a known issue of Cloudshell, simliar to https://github.com/Azure/azure-cli/issues/13233. To solve it, please use Azure CLI on a local machine or run az login in Cloud Shell and retry the command.. Let us know if any other need.

This issue is tracked at #11749. If you see it happening again, please kindly let us know.


[BP-3.0][FLINK-35431][doc] Migrate references in Flink CDC documentation from Debezium 1.9 to 2.0

Seems Debezium team has brought 1.9 docs back in https://github.com/debezium/debezium.github.io/commit/1da0427ad77ccc9e858649bce3178b5bb6930387 and links like https://debezium.io/documentation/reference/2.0/connectors/db2.html#db2-temporal-types are available again. Not sure if we should revert this or when will CDC upgrade Debezium base package. Thoughts? @GOODBOY008 @leonardBang

Nice catch，use 1.9 is better than 2.0


[ISSUE #4002]Optimize some mqadmin command execution results output

Make sure set the target branch to develop
What is the purpose of the change
#4002
The optimized display:

Brief changelog
XX
Verifying this change
XXXX
Follow this checklist to help us incorporate your contribution quickly and easily. Notice, it would be helpful if you could finish the following 5 checklist(the last one is not necessary)before request the community to review your PR.

[x] Make sure there is a Github issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a Github issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[x] Format the pull request title like [ISSUE #123] Fix UnknownException when host config not exist. Each commit in the pull request should have a meaningful subject line and body.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[x] Write necessary unit-test(over 80% coverage) to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
[x] Run mvn -B clean apache-rat:check findbugs:findbugs checkstyle:checkstyle to make sure basic checks pass. Run mvn clean install -DskipITs to make sure unit-test pass. Run mvn clean test-compile failsafe:integration-test  to make sure integration-test pass.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

Coverage decreased (-0.04%) to 51.84% when pulling 8dfa481dfffce3fce62b4f3fd2b58fc335483abd on zhangjidi2016:optimze_output into c1aeca291ea686a2b7f01ffec30132f5a370a2ab on apache:develop.

Coverage decreased (-0.04%) to 51.84% when pulling 8dfa481dfffce3fce62b4f3fd2b58fc335483abd on zhangjidi2016:optimze_output into c1aeca291ea686a2b7f01ffec30132f5a370a2ab on apache:develop.

great job. clusterList command seams to be optimized in your previous pr.


I try facebook_hack.py it not wokr.

pls help

This is an old script and its not working since facebook changed its name
to meta, renaming the script to hack_meta WILL work
On Tue, 10 Sept, 2024, 5:58 am X3eRo0, @.***> wrote:

image.png (view on web)
https://github.com/user-attachments/assets/9c207889-b1a0-406e-8adb-09be3272095e
pls help
—
Reply to this email directly, view it on GitHub
https://github.com/deut-erium/hacking_tools/issues/1, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJPOQB4CXQY2A52EUM7Z5F3ZVY4LDAVCNFSM6AAAAABN5TNENCVHI2DSMVQWIX3LMV43ASLTON2WKOZSGUYTKMJWGAZDGNY
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

.


baseUrl not working as described?

Assuming following example:
var express = require('express');
var router = express.Router();

router.use('/*', function (req, res) {
  console.log(req.baseUrl);
  res.end();
});

var app = express();
app.use('/base/url', router);
app.listen(3000);

If I understand correctly this should always log /base/url. However when I fetch for instance /base/url/some/path this logs the fill path (/base/url/some/path) instead. Is this a bug or am I misunderstanding the documentation?

Yes, it is a misunderstanding. Because you put '/*', it causes the entire path to be the base. Just remove that argument or change it to '/'.

Another option is you can change router.use('/' to router.all('/' so your function is no longer mounted and is instead a route. Basically baseUrl is the mount base, and .use alters this.

perfect, thanks for the explanation!

No problem! And please, if you have suggestions for improving documentation or even want to make PRs, we welcome them at https://github.com/strongloop/expressjs.com :) It's not always easy to write from the right perspective!


[Q] Adding footer to a worksheet or workbook on printing

I've tried adding a footer to a worksheet with the below options to a worksheet. But in the print, the footer is not shown
workbook.addWorksheet('sheet', {
    pageSetup: {
      fitToPage: true,
      paperSize: 9,
      horizontalCentered: true,
      margins: {
        left: 0.1,
        right: 0.1,
        top: 1,
        bottom: 1,
        header: 1,
        footer: 1,
      },
    },
    headerFooter: {
      firstFooter: 'Copyright 2020, Company Name, All Rights Reserved.',
    }
});

Am I doing something wrong here or exceljs doesn't support footers for print?
Also Insert -> Headers and Footers section is disabled when opened with LibreOffice Calc. (I didn't test with Microsoft excel)

#1325 also related to this


[question] Missing information?

is it supposed to be missing information on my controller?

Hi. Yes. It's not relevant for the controller.