Memory overhead

Hello!
Could you please provide information on the memory overhead per stored item when using LRU in Go?
Additionally, I have a use case where the key is a [32]byte and the value is a pointer to a struct. Which of the following approaches would be faster:
1.	Using go-freelru to store the key and a pointer to the struct.
2.	Using go-freelru to store the key and an index (e.g., uint64) which references a separate map holding all values.

Thank you!

Could you please provide information on the memory overhead per stored item when using LRU in Go?

The memory overhead of key and value is the size of the key and value types multiplied by the number of max number of elements (the number you set with the New functions).

Which of the following approaches would be faster:

In general: If you only need to read-access your values by key, store the struct in the LRU, and don't use a pointer.
If the value structs exceed a certain size (128?), the Go compiler won't embed the value and use pointers anyways.
If the value struct members need to be changed after storing the values in the LRU, use pointers.
When you say "index" into a "map", I am not sure what you are talking about.
If the uint64 value is an index into an array: the LRU maintains an internal array of your values anyways. So if you are using the index just for lookups, store the struct itself in the LRU.
If the uint64 value is the key for a Go map lookup, then yes, store it as value in the LRU.
Summary: This can be complex and there are lots of different use cases and corner cases. If in doubt, do your own benchmarks. Then you have a prove for whatever you decide for.


training errors with my own mdb datasets

I just use the tools/CreateDataset.py to create my owned train and validation dataset. But when running training, it throws the following exceptions:
/disk1/deeplearning/torch/install/bin/luajit: bad argument #3 to '?' (torch.*Tensor expected, got nil)
stack traceback:
[C]: at 0x7f900fc2f8b0
[C]: in function '__newindex'
./utilities.lua:33: in function 'str2label'
./DatasetLmdb.lua:82: in function 'allImageLabel'
./training.lua:84: in function 'trainModel'
main_train.lua:51: in main chunk
[C]: in function 'dofile'
...ning/torch/install/lib/luarocks/rocks/trepl/scm-1/bin/th:145: in main chunk
[C]: at 0x004064d0
anyone can help me how to fix the errors?
thanks

I have fixed the issue.

how you fix the errors?

@avr248 I had also faced a similar issue in my training of crnn. As far as I can recall the reason for mine was incorrect setting of maxT. I was training on a larger character set. Currently I use maxT=51 instead of default 26 given in the config.lua.

@simmoncn
@ravikantb
can you give you train example, like same image and label?
if I train chinese how about the follow images？( I want to recognition chinese words in scene image )

@ravikantb , what is maxT though, actually? By default, even though 36 classes are considered, maxT is only 26. What does that mean?


[Feature] Base spark image build is very slow and impacting ci/cd

Search before asking

[X] I searched the issues and found no similar issues.

Component
Library/core
Feature
While working, the build of the base spark image used by transforms enabled in the spark runtime, is very slow - about 20 minutes in ci/cd builds.  With the recent change on ci/cd to run each transform separately, this means that each spark-based transform is doing this.  Not too bad when only a transform is changed, but when the core library is changed, all transforms are built so that this is problem is even more painful.
It seems to be happening on this step
RUN wget https://archive.apache.org/dist/spark/spark-${SPARK_VERSION}/spark-${SPARK_VERSION}-bin-hadoop${HADOOP_MAJOR_VERSION}.tgz && \
    tar xf spark-${SPARK_VERSION}-bin-hadoop${HADOOP_MAJOR_VERSION}.tgz -C /opt && \
    mv /opt/spark-${SPARK_VERSION}-bin-hadoop${HADOOP_MAJOR_VERSION} /opt/spark

ans specifically the wget.
To build the image
cd data-processing-lib/spark
make image

Are you willing to submit a PR?

[ ] Yes I am willing to submit a PR!

We may have discussed, but using a base spark image would probably help this.

Why is the base image rebuilt every time a transform image is built? By default, the transform image uses a base image from a docker registry. That does not require rebuilding the base image for every CI/CD run. It sounds like something needs to be changed in the CI/CD pipeline itself.

++++1 to @cmadam


Rollbar* pods 2.0.0-beta.10 not all published

Describe the bug
The latest published version of the Rollbar* pods are inconsistent:
RollbarSwift 2.0.0-beta9
RollbarPLCrashReporter 2.0.0-beta9
RollbarNotifier 2.0.0-beta9
RollbarDeploys 2.0.0-beta.10
RollbarCommon 2.0.0-beta.10
As a result, it is not possible to reference the latest release across all the dependencies
Screenshots

*Rollbar-Apple SDK version: v2.0.0-beta.10
Calling the SDK from (x-mark all suitable):
[] Objective-C
[x] Swift
[] Other:

correct. trying to figure out why now the rest of pods fail validation during publishing...


Add cuDNN to darkness builds

See title

Swapped to the nvcr.io/nvidia/cuda:12.1.1-cudnn8-devel-ubuntu22.04 base image in quay.io/kenmoini/b-sep-ubnt22-cmake - however this causes the mAP analysis between 1k batches to fail and needs the darknet trainer to either increase the subdivisions to equal batch_size, or to exclude mAP calculations.


X-OAUTH2 authentication mechanism

It would allow to use OAUTH bearer tokens to authenticate on ejabberd.

I will be making a breaking change to the Config struct, to be able to pass credentials that are not passwords.
I am planning to change config from:
      config := xmpp.Config{
		Address:      "localhost:5222",
		Jid:          "test@localhost",
		Password:     "test",
	}

to:
      config := xmpp.Config{
		Address:      "localhost:5222",
		Jid:          "test@localhost",
		Credential:     xmpp.Password("test"),
	}

This will allow us to introduce a new credential: xmpp.OAuthToken("token")

Implemented by #117


Mock functions for i18n

Created a simple translate and sprintf function, that should act as a proxy for translation. These functions will work only in environment, where __ and sprintf functions are available on window (as in ManageIQ). If they are not available, it will return original string or mask.

@martinpovolny can you check it out?

@mzazrivec : what do you think?

This doesn't work.
Gettext needs that __(...) to find the strings to extract.
Wrapping that in a helper function just means we will have no strings..

(sprintf is just fine, but the "mock" translate needs to be called __, not translate)

@Hyperkid123 The translate() routine needs to be renamed to __(). We don't want to be using something special here.

@mzazrivec ok i will rename it
@himdel the helper function seems to be working just fine. I have just tested it and this is the result. This source
import React from 'react';
import { translate, sprintf } from '../global-functions';

export const TranslateDemo = () => (

Translated string 1: {sprintf(translate('%d%% in use of %d total'), 15, 50)}

Translated string 2: {translate('Submit')}

    ## next line won't work in react-ui-components dev server

Translated string 3: {__('Submit')}

);

will render this is manageIQ:

Is there something i am missing?

Is there something i am missing?

Your stuff works in run time, but you are missing the part where the strings are collected for translation. This is done by parsing the sources and collecting all the calls to __(args) and a several other functions.

@martinpovolny yes @himdel already explained.

@martinpovolny i have renamed the translate function to __(...) and tested it in ManageIQ (even non existing keys) and it seems to be working. When this is merged i think i have all i need to start working on the provider forms.

@martinpovolny @karelhala @himdel can we get this merged? Or is there something else you want me to do?


[Enhancement] Config for whitelist only

Would be cool to also have a whitelist, so if you run a server where you only want certain clothes, you don't have to mass blacklist every clothing item.
For example prison RP or similar.

Yeah im hanging out for it haha :)


Add support for Gurobi 7.0

Adds support for the upcoming release of Gurobi 7.0.

That was quick!


⚠ Bofrost.de has degraded performance

In 55e8802, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 887 ms

Resolved: Bofrost.de performance has improved in 4b4401c.


Parameters appear to be incorrect

The parameters appear to be incorrect.
Per this page: https://docs.microsoft.com/en-us/powershell/module/az.network/new-azapplicationgatewayfirewallexclusionconfig?view=azps-5.8.0
They are:
New-AzApplicationGatewayFirewallExclusionConfig
-Variable
-Operator
-Selector
[-DefaultProfile ]
[]

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: b4cf0428-ac89-d265-d2c2-0a0d932c99c9
Version Independent ID: 8200ffa3-22ec-39a8-6227-ed1cbe9043a4
Content: Web application firewall request size limits and exclusion lists in Azure Application Gateway - Azure portal
Content Source: articles/web-application-firewall/ag/application-gateway-waf-configuration.md
Service: web-application-firewall
GitHub Login: @vhorne
Microsoft Alias: victorh

@WiseOldHowell, Thanks for reaching out. We will investigate and update this thread.

@WiseOldHowell , the page you were referring to explains about "AzApplicationGatewayFirewallPolicyExclusion". Here is the page for global parameters "AzApplicationGatewayFirewallPolicySetting"
We are closing this issue for now. If there are further questions regarding this matter, please reply and we will gladly continue the discussion.


How to match BIDS IDs and CanProCo IDs

Context
The Montreal team would like to share spinal cord lesion segmentation obtained by @plbenveniste to the Toronto team (@leelisae) for the purpose of linking spinal cord lesion load with additional qMRI measures done in Toronto.
Problem
The Montreal team uses BIDS structure sent by the UBC team (internal git-annex SHA: a04d89739c769dc03f23fcda183df62c62f586a9), while the Toronto team uses the CanProCo original file name. How can we match files between the two teams?
Solutions
The file that has matched IDs for both datasets should be accessible by both teams. Is this file centralized at a single point on the UBC server? If so, could it be made accessible to all CanProCo researchers without having to ask for it (sending the file by email implies that the file sent will be out-of-sync with the original and maintained file, which is prone to error, eg: if either the BIDS or the original dataset is being updated).
Related issue #86

We are working on a more thorough solution, but in the meantime the participants.tsv file in Montreal's BIDS dataset can be used to link scans to the original CanProCo IDs. For example 'sub-tor092' corresponds to 'CAN-01-CON-092' and 'ses-M0' corresponds to M0. Sequences names in Montreal's BIDS dataset can be remapped back to original names (that @leelisae is using) like so:
T2w -> 3D-T2W-S
T2star -> Axial_Multi_Echo-S
acq-MT_MTS -> MTsat_ON_OFF-S
acq-T1w_MTS -> MTsat_T1-S
PSIR -> PSIR-S
acq-MToff_MTS -> MTsat_OFF-S
acq-MTon_MTS -> MTsat_ON-S
acq-MT_MTS -> MTsat-S
STIR -> STIR-S
To shed some light on this situation, @leelisae actually has direct access to UBCs internal server and has been pulling new scans regularly, rather than using the packaged BIDS structured datasets (like what Montreal has received). This is because she was previously UBC student and still has a UBC login and VPN access. The reason @leelisae's data is structured differently is because she is using the source data before it has been passed through our script that re-structures the dataset to BIDS.
Hope this helps!

Thank you for your inputs @zachvav. What I still don't understand, though, is that during a conversion with @leelisae this week, she mentioned that patients are also organized by phenotypes, and that the ID number could be the same (and what would distinguish them would be the phenotype). Eg: CAN-01-CON-02 and CAN-01-RRMS-02. Whereas in the case of the BIDS structure, the phenotype is not encoded, and hence there could not be two identical IDs used across phenotypes. Or maybe I misunderstood something from our conversation @leelisae? It would be worth clarifying

I believe @leelisae might have been talking about the ID numbers being shared between sites e.g. CAN-01-CON-02 and CON-02-CON-02. Within a site however ID numbers are not re-used between phenotypes. CAN-01-CON-02 and CON-01-RRMS-02 would not be valid.

@leelisae would you be able to confirm? Thank you

@zachvav is correct. I apologize, @jcohenadad - I misunderstood & miscommunicated. I meant to say that the ID numbers, at rare times, could be shared between sites (e.g., CAN-02-PPM-201 & CAN-03-RRM-201). It seems like once we receive the document from UBC matching filenames, we'd be good to go!

To clarify, the IDs between the BIDS dataset and the original are actually the same IDs, but just coded differently (without phenotype and with a three letter site code e.g. 'tor' rather then a side ID number). We do not have a document that matches IDs as they are already implicitly linked.
If it would be helpful to you @leelisae however, I can generate a one-time CSV that has the BIDS IDs of Montreal's data and their corresponding CanProCo IDs.

To clarify, the IDs between the BIDS dataset and the original are actually the same IDs, but just coded differently (without phenotype and with a three letter site code e.g. 'tor' rather then a site ID number). We do not have a document that matches IDs as they are already implicitly linked.
If it would be helpful to you @leelisae however, I can generate a one-time CSV that has the BIDS IDs of Montreal's data and their corresponding CanProCo IDs.

I would instead suggest to write a script that does the conversion based on this logic (simple regex), instead of creating a one-time CSV, because by experience, stuff that is supposed to be "one-time" ends up being reused 2 years later by someone else who does not have the context, and who will end up making mistakes.

Thanks for the suggestion. I have created a script to backwards match the BIDS NII files to files in our original structure on the MSMRI server and have sent Lisa the output.
To match files instead of just IDs, the conversion is actually slightly more complicated then simple regex. As an example, the BIDS structure recoded MT sequences like so: MTsat-S -> acq-MT_MTS and  MTsat_ON_OFF-S -> acq-MT_MTS. To go backwards we don't actually know whether acq-MT_MTS was MTsat-S or MTsat_ON_OFF-S without looking at the original file structure to see which MTSat sequences was present.
Because of this, the script itself requires access to both the BIDS and the original directory trees and therefore must be run from within UBCs network and would be unusable by external sites. Instead of including the script itself in the repo I suggest we include the CanProCo ID and the path of the corresponding original NIFTI on UBCs server (which is what @leelisae is using) in the participants.tsv file going forward.

Thank you both for your help!
@jcohenadad and/or @plbenveniste - Since it seems like we can now match the BIDS IDs to original CanProCo IDs, would I be able to receive your baseline (M0) SC lesion masks that you've already created?
Also, as we previously spoke:
@jcohenadad - Would you be able to write an example code to linearly register SC lesion masks in subject PSIR to subject MT space?
@plbenveniste - Would you be able to write a few sentences about the new SC lesion segmentation tool and send me any citations, so I could add this to the Methods section of the manuscript? Of course, I will include you as a co-author too.

@jcohenadad and/or @plbenveniste - Since it seems like we can now match the BIDS IDs to original CanProCo IDs, would I be able to receive your baseline (M0) SC lesion masks that you've already created?

Yes, @plbenveniste is on it. In fact, ideally, the segmentations should be pushed to the main repos by @zachvav, and a new version of the dataset re-sent to @leelisae

@jcohenadad - Would you be able to write an example code to linearly register SC lesion masks in subject PSIR to subject MT space?

Because your file structure (non-BIDS) is different than my file structure (BIDS), if I design a script based on my file structure it won't work on your file structure. So, my suggestion is that you send me an example subject, with your current analysis script, which I will modify to add the code for PSIR registration.
Moving forward, we should all be working with the same file structure.

@jcohenadad and/or @plbenveniste - Since it seems like we can now match the BIDS IDs to original CanProCo IDs, would I be able to receive your baseline (M0) SC lesion masks that you've already created? Or, do you advise that I still run Pierre-Louis' pipeline myself to re-generate SC lesion masks?

@leelisae You can find the manual segmentations for all the M0/baseline participant which were manually segmented in the following zip file canproco_M0_lesion_segmentations.zip.  However, some participants were not segmented because the image quality was good enough (the excluded subjects should all be in the following exclude.yml file).
To copy the lesion segmentations, I used the following line of code in the canproco repo:
find ./ -type f -name '*ses-M0*lesion-manual.*' -exec cp {} ~/Desktop/canproco_M0_lesion_segmentations \;

@plbenveniste - Would you be able to write a few sentences about the new SC lesion segmentation tool and send me any citations, so I could add this to the Methods section of the manuscript? Of course, I will include you as a co-author too.

Here is a brief description of the model created for automatic spinal cord lesion segmentation:
A deep learning model for cervical spinal cord MS lesions segmentation was developed using the self-configuring nnUNet v2 framework (https://pubmed.ncbi.nlm.nih.gov/33288961/). It is a region-based model, outputting a single segmentation image containing 2 classes representing the spinal cord and MS lesions. Training data was based on the CanProCo dataset (M0) and consisted of sagittal PSIR 0.7×0.7×3 mm3 (4 sites, 333 participants) and sagittal STIR 0.7×0.7×3 mm3 (1 site, 92 participants). The ground truth spinal cord labels were generated by the contrast-agnostic model (https://arxiv.org/abs/2310.15402) with manual corrections when required (~5% of the images), and the ground truth MS lesion labels were generated manually from scratch by a trained radiologist.
As for the citation:
Benveniste PL, Valošek J, Chen M, Molinier N, Eunyoung Lee L, Prat A, Vavasour Z, Tam R, Traboulsee A, Kolind S, Oh J, Cohen-Adad J. Automatic Segmentation of Spinal Cord MS Lesions Across Multiple Sites, Contrasts and Vendors. 9th annual Americas Committee for Treatment and Research in Multiple Sclerosis (ACTRIMS) Forum 2024, West Palm Beach, Florida	2024.

I agree it would be much easier if we all used the BIDS structure going forward! I have now included the masks provided by @plbenveniste in the BIDS repository on our end. Any new datasets that we send will include the M0 lesions masks.
While doing this I noticed that the following NII files do not have a corresponding .JSON file:
sub-mon006_ses-M0_PSIR_lesion-manual.nii.gz
sub-edm065_ses-M0_PSIR_lesion-manual.nii.gz
sub-mon052_ses-M0_PSIR_lesion-manual.nii.gz
sub-tor051_ses-M0_PSIR_lesion-manual.nii.gz

We don't actually need the JSON files for anything, so this isn't a problem itself; however, I wanted to make sure this is expected behavior and there aren't any files that have been accidentally missed.

Thanks for highlighting this issue @zachvav.
This is an issue for us. We use the JSON files to trace where the segmentations come from. I will investigate on this.

The problem comes from a previous manual labelling after receiving the new M0 batch from Erin (more details in issue #39).
To inspect each file history, I ran :
git log --follow -p ./derivatives/labels/sub-mon006/ses-M0/anat/sub-mon006_ses-M0_PSIR_lesion-manual.nii.gz

What was done:

For sub-mon006_ses-M0_PSIR_lesion-manual.nii.gz, sub-edm065_ses-M0_PSIR_lesion-manual.nii.gz and sub-tor051_ses-M0_PSIR_lesion-manual.nii.gz: JSON files were created and added to the dataset.
For sub-mon052_ses-M0_PSIR_lesion-manual.nii.gz the image was too blurry to get a precise lesion segmentation mask: therefore the mask was deleted. The image was added to the exclude.yml file.

Changes were pushed to branch plb/correct_4_files on our git-annex dataset.
Here is the updated zip file with the M0 lesion segmentation:
canproco_M0_lesion_segmentations.zip
Thanks again for your feedback @zachvav

@jcohenadad - Yes, I will send you an example subject and analysis script likely via dropbox later today.
Thank you all for your generous help! @jcohenadad @plbenveniste @zachvav

Yes, I will send you an example subject and analysis script likely via dropbox later today.

I suggest to put the analysis script in this repository, under e.g. lisa/. Code review/versioning will be much easier that way.

@jcohenadad - This is a friendly follow-up re: example code to linearly register SC lesion masks in subject PSIR to subject MT space, then, calculating MTR for ROIs excluding SC lesions. As a reminder, I sent you the example subject data & analysis script via email on Apr 25. Thank you!

sorry-- in singapore for ISMRM-- i won't have time to look at it until next week

@jcohenadad - This is a friendly follow-up re: example code to linearly register SC lesion masks in subject PSIR to subject MT space, then, calculating MTR for ROIs excluding SC lesions. As a reminder, I sent you the example subject data & analysis script via email on Apr 25. Thank you!

I've created a specific issue for this #91 (the current issue is about something else)


Currency Converter

This project made using typescipt with react and using ExchangeRate API which gives realtime rates of currencies and dynamically gives correct converted value, As api used it has capacity of 1500 requests, after that someone needs to renew the api, well in readme.md i have mentioned it all how to get new api key.
Again it shows very accurate conversion base on updated global market.
Screen shot;

readme?

readme?

their is readme, btw in latest pr i have updated it with better instructions
program codepeak 2023


Front React module

This PR adds the front module based on React along with separate user and role.
In addition, the following changes are made to the model:

Added the color attribute to PetType for more graceful representation in UI.
Added the generation attribute to Pet in order to show how to work with enums in react.

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

Hi,
looks good to me.
One thing that I'm not sure about is that if the code should really be in this repository, or if it should be in this repository: https://github.com/cuba-platform/cuba-petclinic
Currently we don't actively promote this repo here in the guides or anywhere else. Instead it is just used as a fork of the original one (https://github.com/cuba-platform/cuba-petclinic) to store the slight delta for the deployment (e.g. the custom database for each user session). The one that is used in any communication is this one: https://github.com/cuba-platform/cuba-petclinic
But this change seems to be more like a general thing that you want to promote, correct? If so, I think it would make more sense to create a PR in the original (promoted) repo then sync the changes to this repo in order to deploy it accordingly. But this would have the consequence that every new guide we create will also inherit the react front module.
WDYT?

Hi Mario
I think we shouldn't add it to the original repo, for the reason you mentioned.
We would like to present the React UI separately from other guides, so including it here is only for simplicity of maintaining the online demo.

Hi Mario,
We have a separate petclinit-react repo (https://github.com/cuba-platform/cuba-petclinic-react), but we don't want to add code for the deployment purpose as well as have two identical demo apps, so that I added required code to this repo.

Ok, i wasnt aware of that extra repo... that makes sense then :+1:


Detect this problem

Confused why mclogs didn’t auto detect this. This was the log for reference tho, the issue was actually in the log itself:
A potential solution has been determined:
     - Replace mod 'Entity Model Features' (entity_model_features) 0.2.8 with any version that is compatible with:
         - cem 0.7.1_S8_1.19-1.19.2

We only detected dependency problems, not incompatibilities, until now.
I created a PR for that: https://github.com/aternosorg/codex-minecraft/pull/53


microRTPS_client: use updated uORB API; improve usage

Describe problem solved by this pull request
A small cleanup on the microRTPS client side. Probably more to come in further iterations.

I would update this to use uORB::Subscription and uORB::Publication. You don't need to keep a copy of the data internally.
@(send_base_types[idx])_s data;
if (@(topic)_sub.updated(&data)) {
     serialize_@(send_base_types[idx])(&writer, &data, &data_buffer[header_length], &length);

    // transport_node, etc
}

Bringing this in as this is cleaner and working as expected.

@bkueng will address in a PR soon. Thanks for the review


Update Urllib3 Test Versions

Overview

Update urllib3 tests to run on a more up to date matrix of supported versions.

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

Project coverage is 77.73%. Comparing base (844558d) to head (48bd45f).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1216      +/-   ##
==========================================
- Coverage   81.51%   77.73%   -3.78%
==========================================
  Files         197      197
  Lines       21859    21859
  Branches     3827     3827
==========================================
- Hits        17818    16993     -825
- Misses       2911     3778     +867
+ Partials     1130     1088      -42

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


Integration with GPT

Just looking through this, it looks like its' for the hosted models but can I use my custom GPT via the ChatGPT API?

If it follows the same api specification, I could easily add support for changing the base api URL. Would that help?


Tags

It would be awesome if Another Notes App supported tagging notes, to view them in a more categorized way.

that would be just great! i've tried almost all note-taking apps out there and this app turned out to be the best one alternative for Google Keep. you can take a note just right away. yet only these 2 essential features are missing: Sync and Label. i'm looking forward for them.

@frknltrk Sync is probably not going to come back.
More information can be seen in issue #6.

Added with 836692af..7088b0e4


An on-screen Translator

Description of the new feature / enhancement
My bad that I am still bad at programing.
The translator would have one or 2 hotkeys depending on the implementation, one for each technique:
feature 1:
Pressing a certain hotkey will get you into selection/capture mode where you select a region and it got translated, press Esc to close the translation display.
feature 2:
Pressing a certain hotkey will get  you into live translation mode where the app will try to translate whatever text it finds on the screen (which will be a little delayed and very performance heavy), pressing the hotkeys again will disable the feature
the options:

selecting the online service/services to translate with.
selecting languages to download offline translations for.
select the amount of display dimming when the feature is enabled.
selecting the popup style and color.
region selection for live translation (which means a third hotkey, maybe) so you select to live translate from only a certain region, not the whole screen.
the option to select the translate from languages (Right Click is enough) and the translate to language.

Scenario when this would be used?
Reading documentations, browsing forums, using the web on the web on non native dialect, video games and videos/movies.
Supporting information
This is a mainly c++ open source software that gives some of the functionality: https://github.com/OneMoreGres/ScreenTranslator
and this is another implementation but in PYTHON, still, it may be of help: https://github.com/DeskTranslate/DeskTranslate
although, they are open-source, author permission is still preferred.

/dup  #18014


Update ID0092.yaml

@emanuelaoldoni I think this can be closed. Check if the file in the main branch is the right version. If so, you can "Close with comment"


Bug in live-updates on the dashboard

Story

Keeping the Dashboard in a background for a while (in my case it was over an hour) and then coming back leads to an "infinite" long list of recent blocks, and the browser tag gets completely unresponsive. I don't have a guess why that could have happened.
Acceptance Criteria

[ ] Bug is resolved
[ ] Mobile ok
[ ] Tested

Does transactions also have this bug?

I repro the bug and found out that it is highly probably because the react-flip-move have some issues to finish the animation. I inspect that the real block it will display is much larger than the not correct showing blocks and after few seconds it goes well.

I have not tested nor I observed it (it might be just due to the low traffic of transactions)

Maybe there is a parameter to flip-move that can help it. Alternatively, we can detect “out of focus tab” and just render without flip-move. In fact, it makes sense to do fewer requests when the tab is inactive.

In fact, it makes sense to do fewer requests when the tab is inactive.
Do you mean to do lazy request?

I mean that we don't need to send any requests while the tab is not active as users won't see the changes anyway, but the browser will have this constant load every 10 seconds.

The problem is getting reported by community: https://github.com/nearprotocol/stakewars/issues/96
We should fix this sooner rather than later.

Interesting, some folks reporting issues with Sequelize having a memory leak, comments continuing until last month:
https://github.com/sequelize/sequelize/issues/9276#issuecomment-438687763
Also, I did notice that SQLite is being used for production, which I found odd at first glance.
https://github.com/nearprotocol/near-explorer/blob/master/backend/config/database.js#L15
I ran near-explorer in Docker for about 30 minutes, looked at the filesystem (with docker exec -it CONTAINER_NAME /bin/sh) and saw that the file had grown to 12.6 megs. Not a huge deal, but it's obviously going to grow fast. I guess I've never seen SQLite used to power a database that's written to so often. Perhaps a solution might be to change the dialect to MariaDB?
This last link may be worth a read as well, especially near the bottom where it lays out arguments against the use of SQLite, although it does say the file can grow to be 140 TB 😮.
https://www.sqlite.org/whentouse.html


[CTA Section]: Horizontal line is shown as visible when there are 3 cards in a row

Engineering info:

Innovation Team engineer:
Innovation Team JIRA Ticket: https://jsw.ibm.com/browse/ADCMS-2431
DPO consulting engineer: N/A

Description

The CTA Section row shows a horizontal rule between rows even with only 3 content items before the row break.
The border issue looks to be happening on AEM because of additional padding top and bottom properties that were added, however, I think there's some improvement on the C4IBM side that we can do to eliminate this issue so that the addition and removal of the horizontal line depending on the number of items per row is managed better.
See - https://prod-author.roks.cms.cis.ibm.net/content/adobe-cms/language-masters/en/products/watson-orchestrate.html?wcmmode=disabled

Component(s) impacted
CTA Section
Browser
Chrome, Safari, Firefox, Microsoft Edge
Carbon for IBM.com version
v.1.35
Severity
Severity 3 = The problem is visible or noticeable to users but does not impede the usability or functionality. Affects minor functionality, has a workaround.
Application/website
AEM
Package
@carbon/ibmdotcom-web-components, @carbon/ibmdotcom-styles
CodeSandbox example
https://prod-author.roks.cms.cis.ibm.net/content/adobe-cms/language-masters/en/products/watson-orchestrate.html?wcmmode=disabled
Steps to reproduce the issue (if applicable)

Scroll to the bottom of this page (https://prod-author.roks.cms.cis.ibm.net/content/adobe-cms/language-masters/en/products/watson-orchestrate.html?wcmmode=disabled)

Release date (if applicable)
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct
[X] I checked the current issues for duplicate issues

@oliviaflory Can you help take a look at this issue and let me know what you think? Thanks!
cc: @jwitkowski79

The CTA Section row shows a horizontal rule between rows even with only 3 content items before the row break.
The border issue looks to be happening on AEM because of additional padding top and bottom properties that were added, however, I think there's some improvement on the C4IBM side that we can do to eliminate this issue so that the addition and removal of the horizontal line depending on the number of items per row is managed better.

@proeung

Yes, there should not be a horizontal rule below the 3 content items before a row break
CTA section is performing correctly in our C4IBM storybook
Can you clarify what improvements could be made? I would need to understand the changes and have our dev team weight in.
The current CTA section has 160px of padding on the bottom. Does the problem go away with the added padding removed? From a first look the additional top and bottom padding seem like they're throwing the content off from the rest of the page spacing.


fix(test) : fix filter dropdown WorkItemType test

Note: If there are pending changes to the PR, prefix the PR title with "WIP" and add the label "DO NOT MERGE"
Mandatory

[ ] What does this PR do?
This PR fixes the failing filter dropdown test because of the changes from backend

[ ] What issue/task does this PR references?

[ ] Are the tests Included?

Optional

[ ] Is the documentation Included?

[ ] Are the Release Notes included?

[ ] @mention(s) to expected reviewer(s) included

@Raunak1203 Your image is available in the registry. Run docker pull registry.devshift.net/fabric8-ui/fabric8-planner:SNAPSHOT-PR-2679 && docker run -it -p 5000:8080 registry.devshift.net/fabric8-ui/fabric8-planner:SNAPSHOT-PR-2679 and visit http://localhost:5000 to access it.


The config attributes {'clip_sample': False} were passed to PNDMScheduler, but are not expected and will be ignored

Hi,
Using the old method with captioned images as it seems to be working a lot better for training specific poses (not faces) vs the new one.
Set text encoding at 30%, getting the message in the subject. It does not break the training, but I am afraid it is not stopping the text encoder and it eventually encodes to 100% and "overcooks" the trained model
Can you please check?
Thanks

Progress:|████████                 | 30% 4139/13800 [9:02:01<20:31:36,  7.65s/it, loss=0.0145, lr=1.43e-6] SAVING CHECKPOINT: /content/gdrive/MyDrive/cydohc_step_4140.ckpt
**The config attributes {'clip_sample': False} were passed to PNDMScheduler, but are not expected and will be ignored. Please verify your scheduler_config.json configuration file.**
Converting to CKPT ...
Done, resuming training ...
Progress:|███████████              | 45% 6185/13800 [13:24:19<16:09:55,  7.64s/it, loss=0.0151, lr=1.15e-6]

Don't worry about that message, it's just an info, it doesn't break anything.

Ok, thank you


Inherit BaseChain from LightDispatchChain

What was wrong?
#998 introduced inheritance of LightDispatchChain -> Chain. For many methods, the Chain implementations will are broken if run in a LightDispatchChain. They expect a chaindb, but the dispatch chain only has a headerdb. It seems safer, easier to reason about, and quicker to isolate problems, if we only inherit BaseChain.
How was it fixed?

Move some key methods that don't depend on chaindb from Chain to BaseChain.
Require header as part of get_vm_class() so that it can be implemented in BaseChain

Cute Animal Picture

Hi @cburgdorf does this alternative approach to #998 look okay to you?

I rage merged this because it coincidentally contains a fix for #1007 (Unrelated to the main inheritance issue discussed here).
On the topic:
Your main point seems to be that inheriting from Chain makes the LightDispatchChain inherit methods that will be broken for it. That's a valid concern, so I will say that these methods aren't used anyway and if they throw an exception because we re-implement them to throw or if they throw because chaindb isn't there doesn't make a huge difference in the result. I do admit it feels cleaner to have these methods throw the proper NotImplementedError though.
However, it comes at a cost of missing out methods that the LightDispatchChain should inherit, some of them which this PR has moved into the BaseChain to tackle that. I wasn't sure if we want any implementations in the BaseChain at all or if it should stay entirely abstract. In that case, it may make sense to introduce yet another layer such as BaseChainMethods where these implementations could go?
Another thing to note is, that with the LightDispatchChain inheriting directly from BaseChain we will likely see this break again until we have integration tests for Trinity simply because it is easy to forget to update the LightDispatchChain whenever the BaseChain changes.
That said, I volunteer to do the integration tests for Trinity next week if no one beats me to it.

In that case, it may make sense to introduce yet another layer such as BaseChainMethods where these implementations could go?

Eventually, maybe. The time when we have enough information to do that cleanly is probably when we want to inherit from BaseChain for the Casper/sharding beacon chain. That will force us to focus on which assumptions need to be re-examined. At that point, we'll have a clearer idea of what should be defined at different inheritance layers (or we might come up with an entirely different solution by breaking it apart and composing classes).

we will likely see this break again until we have integration tests for Trinity

Yes, I agree this is a huge problem. I also agree that the best solution is adding integration tests. :)

That said, I volunteer to do the integration tests for Trinity next week if no one beats me to it.

Great! I'll race through Grace Hopper issues to see if I can beat you there. I just created #1008 to track. If I'm able to start taking a look, I'll "assign" it to myself. If I'm not assigned, it's all yours.

@cburgdorf if you merge my branches, would you mind using a merge commit instead of a squash commit? One reason I care is that I use (roughly) this shell script to clean up my local branches that have been merged upstream:
git branch -d $(git branch --merged master | grep -v master)

Using a squash commit defeats this approach :/
Obviously a minor thing, but it would be nice.

No problem!


Macros for locking / unlocking tables

Docs:

https://core.sasjs.io/mp__lockfilecheck_8sas.html
https://core.sasjs.io/mp__lockanytable_8sas.html

Closes #93

All tests are passing:

:tada: This PR is included in version 2.50.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


cmd/compile: out of memory compiling cmd/compile/internal/ssa with 1GB RAM

Building tip on Ubuntu 18.04 on a Digital Ocean VM with one 1GB of RAM at commit 83dfc3b0
phil@spare0:~/go/src$ uname -a
Linux spare0 4.15.0-30-generic #32-Ubuntu SMP Thu Jul 26 17:42:43 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

I can reproduce this out-of-memory condition 100% of the time (in the prove pass in SSA):
Building Go cmd/dist using /home/phil/go-bootstrap.
Building Go toolchain1 using /home/phil/go-bootstrap.

Building Go toolchain2 using go_bootstrap and Go toolchain1.
# cmd/compile/internal/ssa
fatal error: runtime: out of memory

runtime stack:
runtime.throw(0x9f727f, 0x16)
        /home/phil/go/src/runtime/panic.go:608 +0x72
runtime.sysMap(0xc02c000000, 0x4000000, 0xe7d258)
        /home/phil/go/src/runtime/mem_linux.go:156 +0xc7
runtime.(*mheap).sysAlloc(0xe5a580, 0x4000000, 0xe5a598, 0x7f0d87065308)
        /home/phil/go/src/runtime/malloc.go:619 +0x1c7
runtime.(*mheap).grow(0xe5a580, 0x3, 0x0)
        /home/phil/go/src/runtime/mheap.go:920 +0x42
runtime.(*mheap).allocSpanLocked(0xe5a580, 0x3, 0xe7d268, 0x400)
        /home/phil/go/src/runtime/mheap.go:848 +0x337
runtime.(*mheap).alloc_m(0xe5a580, 0x3, 0x50, 0x7f0d87351fff)
        /home/phil/go/src/runtime/mheap.go:692 +0x119
runtime.(*mheap).alloc.func1()
        /home/phil/go/src/runtime/mheap.go:759 +0x4c
runtime.(*mheap).alloc(0xe5a580, 0x3, 0x7f0d87010050, 0x7f0d87065270)
        /home/phil/go/src/runtime/mheap.go:758 +0x8a
runtime.(*mcentral).grow(0xe5ccb8, 0x0)
        /home/phil/go/src/runtime/mcentral.go:232 +0x94
runtime.(*mcentral).cacheSpan(0xe5ccb8, 0x1fe)
        /home/phil/go/src/runtime/mcentral.go:106 +0x2f8
runtime.(*mcache).refill(0x7f0d8b82a000, 0xc000020050)
        /home/phil/go/src/runtime/mcache.go:122 +0x95
runtime.(*mcache).nextFree.func1()
        /home/phil/go/src/runtime/malloc.go:749 +0x32
runtime.systemstack(0x455ad9)
        /home/phil/go/src/runtime/asm_amd64.s:351 +0x66
runtime.mstart()
        /home/phil/go/src/runtime/proc.go:1229

1GB of memory has been more than enough to build the toolchain in the past.
Barring any clever ideas about how to debug this, I'll try to bisect and hope that there was only one commit that reliably introduced this regression.

Likely a duplicate of https://github.com/golang/go/issues/26523. Can you try this patch as suggested https://github.com/golang/go/issues/26523#issuecomment-407206248 ?

Yes, I'll do that.

That patch is part of the go1.11 release, and building go1.11 still fails.

I'm going to try to bisect 74b56022a1f834b3edce5c3eca0570323ac90cd7...e0faedbb5344eb6f8f704005fe88961cdc6cf5f8 and see if that produces interesting results.

What version of Go is the bootstrap compiler? If I understand correctly, it is toolchain1 OOM'd, and toolchain1 is built with the bootstrap compiler with the bootstrap runtime.

Ah, fair point. I was using go1.11 as my bootstrap toolchain. (Interestingly, though, building go1.10.4 with go1.11 as the bootstrap toolchain works fine...)

My first round of bisecting blames commit e9137299bf74e1bcac358b569f86aef73c7c2ea6, but I'm going to bisect again with 1.10.4 as my bootstrap toolchain and see if that produces different results.

Go 1.11 compiler does more work, which of course has more code. So it is a double factor here if using Go 1.11 compiler to compile Go 1.11 compiler: it (may) use more memory (even compiling the same code), and it compiles more code.
Maybe a workaround is to use an older (or newer) bootstrap compiler?

make.bash on go1.11 using go1.10.4 as a bootstrap still fails. I'm bisecting the same commit range.

When bootstrapping with 1.10.4, bisect blames cc09212f59ee215cae5345dc1ffcd1ed81664e1b.
# bad: [e0faedbb5344eb6f8f704005fe88961cdc6cf5f8] cmd/go: add missing newlines in printf formats
# good: [74b56022a1f834b3edce5c3eca0570323ac90cd7] doc: note that x509 cert parsing rejects some more certs now
git bisect start 'e0faedbb' '74b56022a'
# good: [62adf6fc2d70d9270b4213218e622c15504966be] cmd/internal/obj: convert unicode C to ASCII C
git bisect good 62adf6fc2d70d9270b4213218e622c15504966be
# bad: [4eb1c84752b8d3171be930abf4281080d639f634] cmd/link: fix name section of WebAssembly binary
git bisect bad 4eb1c84752b8d3171be930abf4281080d639f634
# bad: [31ef3846a792012b0588d92251f3976596c0b1b1] cmd/compile: add rulegen diagnostic
git bisect bad 31ef3846a792012b0588d92251f3976596c0b1b1
# good: [cc0aaff40e02192356ccb65d8acf571d12f74a95] cmd/compile: fix Wasm rule file name
git bisect good cc0aaff40e02192356ccb65d8acf571d12f74a95
# good: [3080b7d0af65858400b13134c1c471e2cb35e647] runtime: unify fetching of locals and arguments maps
git bisect good 3080b7d0af65858400b13134c1c471e2cb35e647
# good: [8a16c71067ca2cfd09281a82ee150a408095f0bc] cmd/vet: -composites only checks imported types
git bisect good 8a16c71067ca2cfd09281a82ee150a408095f0bc
# bad: [7d61ad25f8b10c0a656ef709fb30c08f5974594b] crypto/x509: check EKUs like 1.9.
git bisect bad 7d61ad25f8b10c0a656ef709fb30c08f5974594b
# bad: [f2cde55cd60993e948dada9187d25211ec150a5e] runtime: use Go function signatures for memclr and memmove comments
git bisect bad f2cde55cd60993e948dada9187d25211ec150a5e
# good: [e9137299bf74e1bcac358b569f86aef73c7c2ea6] debug/pe: parse the import directory correctly
git bisect good e9137299bf74e1bcac358b569f86aef73c7c2ea6
# bad: [cc09212f59ee215cae5345dc1ffcd1ed81664e1b] runtime: use libc for nanotime on Darwin
git bisect bad cc09212f59ee215cae5345dc1ffcd1ed81664e1b
# good: [e86c26789dbc11c50c4c49bee55ea015847a97b7] runtime: fix darwin 386/amd64 stack switches
git bisect good e86c26789dbc11c50c4c49bee55ea015847a97b7
# first bad commit: [cc09212f59ee215cae5345dc1ffcd1ed81664e1b] runtime: use libc for nanotime on Darwin

That commit doesn't make much sense as the culprit either, but both bisects point to a regression introduced somewhere in or around May of this year.

What are the stats of the vm you are using? How many cores? Is any swap configured?
From my informal testing you need ~768mb of ram per core on a 64bit machine to complete ./all.bash.

On 19 Sep 2018, at 06:54, Phil<EMAIL_ADDRESS>wrote:
make.bash on go1.11 using go1.10.4 as a bootstrap still fails. I'm bisecting the same commit range.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

It's the cheapest Digital Ocean VM.  1 vCPU, 1GB memory, no swap:
phil@spare0:~$ cat /proc/swaps
Filename                                Type            Size    Used    Priority

It's less important to me how many resources one needs to build the toolchain, and more important that things are moving in the wrong direction. Shouldn't peak resource consumption by the compiler be determined by either the largest package (in the compiler front-end) or the largest function (in the back-end)? The out-of-memory condition doesn't occur in the linker, where I would expect resource consumption to grow in concert with the repo growing ~10% more code.

Additional anecdotal evidence of a memory use regression, though only for vmsize, not rss, which would make sense.

I think we should have a builder that has a relatively small amount of memory. Somewhat related, in https://github.com/golang/go/issues/26867 I reported how go test net OOM'd with a few gigabytes of available memory.
We can assume that Linux is fairly common on machines with less memory (small computers, routers, VMs, etc), and that a 64-bit architecture like amd64 should stress test the memory more than a 32-bit architecture would.
We already have special builders like linux-amd64-noopt, so I propose adding a linux-amd64-small. It could start at a limit of 2GB of memory, but we could lower that to 1GB or even lower once it's in place. I presume that we could also add extra limits to it, such as:

lowering the maximum number of open file descriptors
lowering the size of /tmp
lowering the maximum number of processes created by the user
giving the machine CPU power comparable to embedded devices (e.g. dual-core 1GHz)
lowering the size of the disk

/cc @dmitshur

i suggest add memory swap on/off @mvdan

@mvdan, let's not combine two bugs into one. It's hard to label & track that way.
Could you file a separate builder bug about a small config?  (but perhaps we could just make an existing builder (cgo, noopt?) be the small one... you could float that in the bug, or I could reply there later)
I'm going to remove the "Builders" label from this bug.

@bradfitz you're right - see the issue above.

I just tried building cmd/compile/internal/ssa with tip and it took just over 1G.

https://github.com/golang/go/issues/20104 is one big fix here

We've also started seeing this failure regularly on the openbsd/arm builder since around the 6th of March 2019 - a few examples:
https://build.golang.org/log/6c0247ef60f5ab34aae85aee05be681c7e4383cc
https://build.golang.org/log/7e3a4e361538049cb66dbd4a8f0f0b0b7a3b5955
https://build.golang.org/log/6ab6975603d179e1c684074fc23c89533f13f58e
https://build.golang.org/log/1df442b95529367697c1a58348201fc4d607bd13

pprof alloc_space for compiling package ssa with tip:
      flat  flat%   sum%        cum   cum%
  163.02MB  7.87%  7.87%   163.02MB  7.87%  cmd/compile/internal/gc.nodl
  139.42MB  6.73% 14.59%   214.49MB 10.35%  cmd/compile/internal/ssa.(*regAllocState).init
  128.29MB  6.19% 20.78%   135.81MB  6.55%  cmd/compile/internal/ssa.numberLines
   82.46MB  3.98% 24.76%   124.48MB  6.01%  cmd/compile/internal/ssa.cse
   81.94MB  3.95% 28.71%    82.44MB  3.98%  cmd/compile/internal/ssa.schedule
   79.78MB  3.85% 32.56%    79.78MB  3.85%  cmd/compile/internal/gc.scopePCs
   79.02MB  3.81% 36.37%    79.02MB  3.81%  cmd/compile/internal/ssa.(*Func).newValue
   63.01MB  3.04% 39.41%    67.01MB  3.23%  cmd/compile/internal/ssa.(*regAllocState).computeLive
   53.33MB  2.57% 41.99%    53.33MB  2.57%  cmd/compile/internal/gc.(*state).addNamedValue
   50.04MB  2.41% 44.40%    66.14MB  3.19%  cmd/internal/obj.(*LSym).writeAddr

My reactions to this:

nodl is normal. This is a big package.
(*regAllocState).init: CL 176221.
numberLines: #29279.
cse, schedule, newValue, computeLive, writeAddr: These doesn't seem unusual. It is the straightforward consequence of having many large functions. We could perhaps continue to add things to ssa.Cache, a la CL 176221.
scopePCs: I've never seen this in a compiler profile before. There might be cheap wins available. cc @dr2chase

This is milestoned 1.13.
If we want to fix it for 1.13, and the little chipping-away-at-the-edges work above doesn't do it, the only available fix I see is #20104. I'm happy to work on that, but there's a fair amount of code churn associated with that, more than I'd normally feel comfortable with during the freeze, so making that judgment call is above my pay grade.

It's possible we can do better in scopePCs, I'd need to think about it, but I think we can avoid the huge intermediate array of PCs-with-same-XPos (including column!)

@4a6f656c observed in #30981 (closed as dup of this issue):

[It is] worth noting that Go built fine on the same builder around Go 1.12 and the issue has gradually gotten worse (first the odd test time build failure, now regular build time failures) - in other words it has regressed between Go 1.12 and current.

@bradfitz @ianlancetaylor unless David's two CLs (outstanding) and mine (merged) get the builder green again, we'll need to make a call about how to proceed here. See https://github.com/golang/go/issues/27739#issuecomment-491036822.

David's first CL is in, and the opendsb/arm builder is currently pending, as opposed to failing quickly, so that is a good sign. Attempts to measure maxrss locally indicate that 1.12 and tip are now similar for package ssa. And compilecmp shows a nice overall memory usage reduction from 1.12 to tip:
name        old alloc/op      new alloc/op      delta
Template         38.3MB ± 0%       37.1MB ± 0%   -3.21%  (p=0.008 n=5+5)
Unicode          28.6MB ± 0%       28.1MB ± 0%   -1.84%  (p=0.008 n=5+5)
GoTypes           136MB ± 0%        125MB ± 0%   -8.41%  (p=0.008 n=5+5)
Compiler          638MB ± 0%        575MB ± 0%   -9.89%  (p=0.008 n=5+5)
SSA              2.19GB ± 0%       1.97GB ± 0%   -9.81%  (p=0.008 n=5+5)
Flate            25.2MB ± 0%       22.9MB ± 0%   -9.13%  (p=0.008 n=5+5)
GoParser         30.0MB ± 0%       27.6MB ± 0%   -7.92%  (p=0.008 n=5+5)
Reflect          84.8MB ± 0%       80.6MB ± 0%   -4.96%  (p=0.008 n=5+5)
Tar              37.4MB ± 0%       34.9MB ± 0%   -6.61%  (p=0.008 n=5+5)
XML              51.3MB ± 0%       45.9MB ± 0%  -10.67%  (p=0.008 n=5+5)
[Geo mean]       87.3MB            81.0MB        -7.29%

So pending some solid green from openbsd/arm, I think we might be good enough for 1.13 here. And then I'll undertake to fix this once and for all with #20104 for 1.14.

Attempting to compile github.com/hashicorp/packer via ports (sysutils/packer) in an AWS t2.small running FreeBSD 11.2. It seems to fail at the linking step with:
*** Error code 1

Stop.
make: stopped in /usr/ports/sysutils/packer

@lyda please file a new issue, and we'll investigate there. And please include a complete log and setup information. Thanks!

Will when I get a chance.

FTR the openbsd/arm builder has been passing again since 6081a9f landed - thanks.

Do we consider this closed?

Do we consider this closed?

Yes, I think so.

CL 213703 should help, if it goes in.


MudDateRangePicker incorrect spacing / size

Things to check

[X] I have searched the existing issues for this bug
[X] To rule out a caching problem I made sure the bug also happens in an incognito tab

Bug type
Component
Component name
MudDateRangePicker
What happened?
MudDateRangePicker margins are not correct, can not place in same row with other input
Expected behavior
Have the same height as other input fields
Reproduction link
https://try.mudblazor.com/snippet/maweuDaeckqDaIBN
Reproduction steps

Open reproduction link
Check spacing / size with eyes (or dev tool 😃 )

Relevant log output
No response
Version (bug)
7.7.0
Version (working)
7.5.0
What browsers are you seeing the problem on?
Chrome
On which operating systems are you experiencing the issue?
Windows
Pull Request

[ ] I would like to do a Pull Request

Code of Conduct

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

More example: https://try.mudblazor.com/snippet/GkmoYtkHUzBmpOPJ

I noticed this issue started in 7.6.0 as still exists in 7.7.0 :( No issue in 7.5.0
Maybe related to https://github.com/MudBlazor/MudBlazor/pull/9517

Yes, I can confirm that, it works in 7.5.0

It does'nt look good to have multiple input fileds inline with daterangepicker.

@ralvarezing @henon
Do you have any idea what can cause this issue?
It's since 7.6.0 , maybe after PR #9517 .

@ralvarezing @henon Do you have any idea what can cause this issue? It's since 7.6.0 , maybe after PR #9517 .

Actually I am trying to understand a similar bug that seems to be related to some inputs with AdornmentIcon.
https://github.com/MudBlazor/MudBlazor/issues/9573
Didn't got that much time to work on it, so I am not sure if it's the same problem, but I'll keep you updated if I found something

Unfortunately I have had to stay on v7.5.0 as this issue started in 7.6.0 :(

Ok, it's was kind of a simple fix but not easy to spot.
This was same as other cases, a missed Classname that needed to changed when a label is (or not) provided

Excellent news! Thank you.


[kf5notifications] new port

Describe the pull request
Adds new port.
Depends on:

[ ] #19439

[ ] #19816

[ ] #20213

Which triplets are supported/not supported? Have you updated the CI baseline?
All official, plus arm64-osx

Does your PR follow the maintainer guide?

Yes

This only fails in the CI, locally works. For some reason it looks into the wrong directory I suppose or it just be the CI is configured that way. Cause it refers to the location where snoretoast is installed before running the post install checks.

This only fails in the CI, locally works. For some reason it looks into the wrong directory I suppose or it just be the CI is configured that way. Cause it refers to the location where snoretoast is installed before running the post install checks.

Same exact experience.

The failures are like this:
Installing in D:/packages/kf5notifications_x86-windows/debug. Run D:/buildtrees/kf5notifications/x86-windows-dbg/prefix.sh to set the environment for KNotifications.
CMake Error in src/CMakeLists.txt:
  Imported target "SnoreToast::SnoreToastActions" includes non-existent path

    "D:/packages/libsnoretoast_x86-windows/include/snoretoast"

  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and references files it does not
  provide.

CMake Error in src/CMakeLists.txt:
  Imported target "SnoreToast::SnoreToastActions" includes non-existent path

    "D:/packages/libsnoretoast_x86-windows/include/snoretoast"

  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and references files it does not
  provide.

It is not reproducible locally tbh, no idea if we are doing anything wrong or there is something wrong with the CI.

CMake Error in src/CMakeLists.txt:
Imported target "SnoreToast::SnoreToastActions" includes non-existent path
"D:/packages/libsnoretoast_x86-windows/include/snoretoast"

in its INTERFACE_INCLUDE_DIRECTORIES.

and

It is not reproducible locally tbh, no idea if we are doing anything wrong or there is something wrong with the CI.

It is a packages path. You may have this path locally after building the dependency snoretoast. But it may be missing after removal & re-install from cache.
Please check the exported config from snoretoast for references to packages.

Ahh make sense, would check that.

It is a packages path. You may have this path locally after building the dependency libsnoretoast. But it may be missing after removal & re-install from cache.
Please check the exported config from libsnoretoast for references to packages.

This is more nuanced than that. Locally build Config.cmake has:
  INTERFACE_INCLUDE_DIRECTORIES "C:/vcpkg/packages/libsnoretoast_x64-windows-static/include/snoretoast"

The path is correct, and the headers are included in the cached package:
PS C:\vcpkg> cat .\installed\vcpkg\info\libsnoretoast_0.8.0_x64-windows-static.list
x64-windows-static/
x64-windows-static/include/
x64-windows-static/include/snoretoast/
x64-windows-static/include/snoretoast/config.h
x64-windows-static/include/snoretoast/snoretoastactions.h
x64-windows-static/share/
x64-windows-static/share/libsnoretoast/
x64-windows-static/share/libsnoretoast/LibSnoreToastConfig-debug.cmake
x64-windows-static/share/libsnoretoast/LibSnoreToastConfig-release.cmake
x64-windows-static/share/libsnoretoast/LibSnoreToastConfig.cmake
x64-windows-static/share/libsnoretoast/copyright
x64-windows-static/share/libsnoretoast/vcpkg_abi_info.txt
x64-windows-static/tools/
x64-windows-static/tools/libsnoretoast/
x64-windows-static/tools/libsnoretoast/snoretoast.exe

/azp run

Thanks for all the kf5Xxx ports!


Change auth flow if account does not exist during sign in

This PR changes the authentication flow when a user without an account tends to sign in, once we can't find the account of this user in the AuthCallbackPage, we show the CreateAccountForm and populate it with their intended details.
Follow this I extracted the create account process in to a form to be reused and performed some other related refactors.

@benmalcom I just tried on this PR locally and it is working as expected. Only thing that I would like to see as improvement is that is it possible to directly create an account from below page to next instead of double verification on email?

@hcho112 if I get what you're saying, you think it will be okay to directly create an account since they're already coming to this page from their inbox which proves they own the email right?

@benmalcom yes! Initially I was little concern about this might expose email being used. However, I realise that in order to get to next step, they need to verify via given email first so we don't have to worry about security. If so, next thing came to my mind is UX there from user perspective, they already proven that they are the owner of the email, therefore we should allow them to create account without double verifying it

@esaminu what do you think?

Fixed

Also tests are failing, would it be to do with flaky? or actual failure?

I actually manually tested this PR and it seems to work just fine. Should we merge it first or wait for test to be recovered?


adding tests for Message class

Adding tests for the Message class.  A few additions/tweaks while doing so:

filter test files to *.test.js
pulled declaration of hour out of function and up top.
defaulting body and meta to an empty object.
fixed issue in .say() where token and channel couldn't be overridden.
adds coveralls integration for code coverage

Changes Unknown when pulling fdb498dc140450f3ae24dd6dc6921aa358343275 on message-tests into ** on master**.

LGTM!
It would be nice to add another npm script alias like npm run coverage-lcov that would run npm run coverage -- --reporter=lcov


Add default sign in details

Great to be able to launch directly to Heroku :-)
Brought the credentials forward from the code.

Thanks @yieme :)


fix: update hints and add warnings for leading- classes

Changes included:

add tech docs link to the general message
suggest Toggle instead of segment-control
show hints for text-, leading-, shadow- classes
add a coming-soon message for replaced classes that are not yet documented

 Update migration plugin with more information on replacements


Create better connection management

[ ] DNS based discovery
[ ] Reconnecting after failure

@macat is this still needed? or does kubernetes take care of reconnecting. For the DNS based discovery were you talking about this idea https://github.com/namely/arnoldb/issues/103? or is this something else?

No this is not needed as we are going to fully deploy it in kubernetes. Closing it.


Header not getting changed on Daily , 3 Days view when changed date through goToDate in latest version.

@howljs

same on 7 days view

Begin working only after you have made your first swap to the left or right to alter the date.

@pateljoel I solved this by using useSyncedList.tsx file inside hooks folder from previous version.


[BIL-351] Published px-enterprise:<IP_ADDRESS>, stork:2.8.2, operator:1.6.1

What this PR does / why we need it:
Which issue(s) this PR fixes (optional)
Closes #
Special notes for your reviewer:

Do not merge this until you have the new version on the server marketplace.

@pault84 For both PX and PX-DR new versions have been added now successfully.


timeseries category timeseries-caegory-like and timeseries-group-like returns no data

the timeseries-category-like, timeseries-group-like parameters don't appear to work for the timeseries catelog.  It returns a blank dictionary when using.  Tried multiple regular expressions.  Would also like timeseries timeseries-group-like/timeseries-caegory-like parameters to work for location catelog.  only return locations that have timeseries in that timeseries-group, but that might be a separate issue.

Try it again on CWBI, we made some changes recently that I don't think have been pushed to cwms-data.usace.army.mil yet.

it is the same on CWBI-test.

I see what is wrong with the query.  Its looking for rows where aliased_item is null but loc_alias_group, loc_alias_category, ts_alias_group and ts_alias_category are always null when aliased_item is null.


add insert_after / insert_before to MultiProgress

Also introduce internal InsertLocation enum to clarify MultiProgress:push

Here's a rough cut of what I propose :)

Thanks!

Thank you too :)


Source and preprocessing of the documents

Hi, thank you for the lovely paper.
I am curious about the exact source and preprocessing of the documents used to augment the prompt.
The paper states:
We use passages (chunks of at most 100 tokens) from Wikipedia as documents within our input contexts. For each of the queries, we need a document that contains the answer and k − 1 distractor documents that do not contain the answer. To obtain a document that answers the question, we use the Wikipedia paragraph that contains the answer from the NaturalQuestions annotations.

And additionally in the Appendix:
We use a Wikipedia dump from late 2018 as our retrieval corpus.

Can you share the specific Wikipedia dump you used?
How did you preprocess the documents? Did you filter out HTML tags and such? If yes, could you share the preprocessing script/logic?
Thank you in advance :)

Hi @GianlucaDeStefano , for the distractor passages we simply used the set of wikipedia passages used in DPR: https://dl.fbaipublicfiles.com/dpr/wikipedia_split/psgs_w100.tsv.gz --- it's a fairly standard retrieval corpus for a lot of work in this space. I'm not 100% sure what they did in terms of pre-processing, etc, but the DPR paper or repo itself might be a better read in that regard. Looks like the dump is from Dec 20, 2018.

https://github.com/facebookresearch/dpr
https://arxiv.org/abs/2004.04906 , section 4.1

Hope that helps!


CASESession: Fix IPK size, it should be 16 bytes not 32

Problem
The IPK size was incorrect, it was declared as 32 bytes instead of 16 in CASESession.h. The spec is very clear about this and leaves no room for ambiguity. Like all symmetric keys in Matter, the IPK must be 16 bytes in length. See e.g. <IP_ADDRESS> AddOpCert command description:
"The IPK SHALL be provided as an octet string of length CHIP_CRYPTO_SYMMETRIC_KEY_LENGTH_BYTES."
Change overview
Conform the IPK size definition to the specification.
Testing

CASE is not fully enabled yet and the operational credentials server does not yet verify the IPK length, so regular operation is unaffected by this change. However the IPK size must be corrected before continuing hookup.

@tcarmelveilleux

@saurabhst @msandstedt @Damian-Nordic @jepenven-silabs ?


Link broken in Readme.md

in Readme.md you write An implementation of chapter two from this text. but the link is broken.. so I dont know which text you are referring to. Could you possibly give the full reference ? Thanks

Sorry about that. Here are fresh links that work for me.
https://pdfs.semanticscholar.org/8b0a/c702624bd1dc0a58b847a65bc6610c01cc48.pdf
https://www.amazon.com/Kalman-Filtering-Neural-Networks-Haykin/dp/0471369985


Add skipping index benchmark test

Description
This PR introduces a benchmark test focusing on the skipping index data structure. It is positioned between end-to-end benchmarking and low-level microbenchmarking. It aims to provide insights into the read and write performance of different skipping data structure using OpenSearch as index store.
The reasons behind this addition instead of E2E or microbenchmarking are:

End-to-End Benchmarking:

This type of benchmarking necessitates splitting test data into files and persisting them on disk. While feasible within the current test framework, this process is exceptionally slow for local testing. Future plans might include the addition of another benchmark test class that executes by submitting to a Spark cluster.
Additionally, it requires the presence of SQL plugin and UI in OpenSearch Dashboards, alongside the EMR-S Spark environment.

Microbenchmarking:

The implementation of Flint BloomFilter resides in flint-core, making it straightforward to incorporate into microbenchmarking.
However, other skipping data structures are implemented within Spark aggregate functions, posing challenges in isolating and testing the algorithms independently.

TODO

Check if any cache or other factors in Spark and OpenSearch may impact the test result
Include more metrics such as resource consumption, OS index size etc
Analyze test results and update user manual with recommendation

Test Cases
Please find details in the Javadoc on FlintSkippingIndexBenchmark. The test is based on Spark benchmark test framework and will be triggered manually.
Test Results
https://github.com/dai-chen/opensearch-spark/blob/add-skipping-index-benchmark-rebased/docs/benchmark-skipping-index.txt
Test Data (Generated)
The schema and size of skipping index written in the test:
curl "localhost:64541/_cat/indices?v"
health status index                                                                                uuid                   pri rep docs.count docs.deleted store.size pri.store.size
yellow open   flint_benchmark_bloom_filter_cardinality_64_adaptive_false_fpp_0.03_num_items_1000000 krhbKOALQB2Ezxn-9PRCZQ   1   1          1            0    902.3kb        902.3kb
yellow open   flint_benchmark_bloom_filter_cardinality_64_adaptive_true_fpp_0.03_num_candidates_10  qyYpKbY7R0C5plNn16QIXQ   1   1          1            0      4.8kb          4.8kb
yellow open   flint_benchmark_value_set_cardinality_64_max_size_100                                 wdhxAEv4QNSep0YXn3d2Uw   1   1          2            0      7.2kb          7.2kb
yellow open   flint_benchmark_value_set_cardinality_64_max_size_2147483647                          FcbPKJa2TLSKVmjSIOWlMA   1   1          2            0      7.2kb          7.2kb
yellow open   flint_benchmark_min_max_cardinality_64_default                                        WU8cLd6SSSKuppOSRvAREQ   1   1          2            0      6.7kb          6.7kb
yellow open   flint_benchmark_partition_cardinality_1_default                                       55R97W4zR3Kzt55BpgTzAA   1   1          1            0      3.1kb          3.1kb
yellow open   flint_benchmark_bloom_filter_cardinality_64_adaptive_true_fpp_0.03_num_candidates_5   e4sLSBtcROCJ4yIsd406gw   1   1          1            0      4.8kb          4.8kb
yellow open   flint_benchmark_bloom_filter_cardinality_64_adaptive_true_fpp_0.03_num_candidates_15  f9aqpip1TdeIjhT3imJQww   1   1          1            0      4.8kb          4.8kb
yellow open   flint_benchmark_bloom_filter_cardinality_64_adaptive_false_fpp_0.03_num_items_64      ATGUO7OnRi-f570mvWOhEQ   1   1          1            0      3.2kb          3.2kb

curl "localhost:64541/flint_benchmark_*/_mapping?pretty"
{
  "flint_benchmark_bloom_filter_cardinality_64_adaptive_true_fpp_0.03_num_candidates_15" : {
    "mappings" : {
      "properties" : {
        "value" : {
          "type" : "binary",
          "doc_values" : true
        }
      }
    }
  },
  "flint_benchmark_bloom_filter_cardinality_64_adaptive_false_fpp_0.03_num_items_1000000" : {
    "mappings" : {
      "properties" : {
        "value" : {
          "type" : "binary",
          "doc_values" : true
        }
      }
    }
  },
  "flint_benchmark_bloom_filter_cardinality_64_adaptive_true_fpp_0.03_num_candidates_5" : {
    "mappings" : {
      "properties" : {
        "value" : {
          "type" : "binary",
          "doc_values" : true
        }
      }
    }
  },
  "flint_benchmark_value_set_cardinality_64_max_size_2147483647" : {
    "mappings" : {
      "properties" : {
        "value" : {
          "type" : "long"
        }
      }
    }
  },
  "flint_benchmark_bloom_filter_cardinality_64_adaptive_false_fpp_0.03_num_items_64" : {
    "mappings" : {
      "properties" : {
        "value" : {
          "type" : "binary",
          "doc_values" : true
        }
      }
    }
  },
  "flint_benchmark_value_set_cardinality_64_max_size_100" : {
    "mappings" : {
      "properties" : {
        "value" : {
          "type" : "long"
        }
      }
    }
  },
  "flint_benchmark_partition_cardinality_1_default" : {
    "mappings" : {
      "properties" : {
        "value" : {
          "type" : "long"
        }
      }
    }
  },
  "flint_benchmark_min_max_cardinality_64_default" : {
    "mappings" : {
      "properties" : {
        "MinMax_value_0" : {
          "type" : "long"
        },
        "MinMax_value_1" : {
          "type" : "long"
        }
      }
    }
  },
  "flint_benchmark_bloom_filter_cardinality_64_adaptive_true_fpp_0.03_num_candidates_10" : {
    "mappings" : {
      "properties" : {
        "value" : {
          "type" : "binary",
          "doc_values" : true
        }
      }
    }
  }
}

Skipping index data written:
curl "localhost:64541/flint_benchmark_*/_search?pretty"
{
  "took" : 105,
  "timed_out" : false,
  "_shards" : {
    "total" : 9,
    "successful" : 9,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 12,
      "relation" : "eq"
    },
    "max_score" : 1.0,
    "hits" : [
      {
        "_index" : "flint_benchmark_bloom_filter_cardinality_64_adaptive_false_fpp_0.03_num_items_1000000",
        "_id" : "zItIYo4BM5f06XztvDKX",
        "_score" : 1.0,
        "_source" : {
          "value" : "AAAAA..."
        }
      },
      {
        "_index" : "flint_benchmark_bloom_filter_cardinality_64_adaptive_false_fpp_0.03_num_items_64",
        "_id" : "zYtJYo4BM5f06Xzt4TL2",
        "_score" : 1.0,
        "_source" : {
          "value" : "AAAAAQAAAAUAAAAIXfxLWNX6W3GBF/TxtjFPE7pdpOfrUCWgDKuuovFceYEu3SPLCdFRGprA9cOk07kApVD2oIHCron49EOAANoFZw=="
        }
      },
      {
        "_index" : "flint_benchmark_bloom_filter_cardinality_64_adaptive_true_fpp_0.03_num_candidates_10",
        "_id" : "zotJYo4BM5f06Xzt-zKD",
        "_score" : 1.0,
        "_source" : {
          "value" : "AAAAAQAAAAUAAAB1AAAAAAAAIAAAAAAAAAAAAAAAAAAAABAAAAAAQAAAAAAIAAAAARAAAAAAAAAEQQEAAADEBAAAAAASAgAAAEAMAAAgAAAAAAAAAQBAAAABgAACAAIAAAAAAAAAAAAAAAAAAAEAAAAAABAAAAAgAIAAAACABIBAAAAAEEACAAAAAAAAUCEAIIAAAAAAEAAIAAQBAAAEAAAAAAACAABAADAAAAAoAABAAAAAAJAAAAAAAAAAAAACAAAAAAAAAAAAAAACAAAAAAAAAAAAAACAgBgAAEEAAIAAAigAAAACEAAAAAAAAAIAAAAQAAABAAAAAAAAAAAAACAAAACACAAAAAAAAAAAIAABAAAAAAAABAAUAAgIABAAAAAAAQAAAkBAAAAAABAgBIDAAACgQAgAAAABAQAAAAAQAAACAACAAAAAAAAIQAAAAAAAAAAAAQAAAAAEAAAFwAAICgAAECQABAAEAKAEAAAAAAADAAAAAAECABAAGAAjgEAAAAACAAAAQAQAAAQgQAAgAAAAAAAAAIAAABAAAAIAAAAAAABAAIAAAgAAAACAAAAAAAAQAAKAAAAAAAAAAAAAQBAAAAAIIAAAYAAAAAAAABACAAAAAAAAAAAAUAAAAAAgQQABAABAAAABCACAAAAAAEIAAEAIAAAAgCAABAAAAAgAAACAAAAAEAAIgACAgAAAAAAAAAABAAAAAAAAAAACCAAABABAAABACAAAQAAAAAAAAIAAABAABQAAACAAAgAAAAAAAAAAmCAAoAAAAAAAAAAIEEAAAAAAAABAABAAQACAAAAAACAAAAAAIAAAAgAAIAAAICABAgAAAAABAIAAAABAAAAAAAAAAAwQAA4AQAAAAgAgAAAAAAAAgACAAAAAIIAQAAAAAAAAAQAAAAAAAAAQAAAABAAJACQQAIAQAAAAAAAAAAAAAAAAAAAgAAAAgAgACAAAAAIBAEAAQAAAAAAgAAAAABAAQAAAAAAAAEAAAACAAAAAAAAAAAAAAAAAAAEAEAEAAQkAAAAAAAAAIAAAAAAAAAAAAAgAAAAAAAAAAAAAAAACAAAAAAAAIgAAAAEEAAAAAQAAAAQgAAAAAAAAAASQAAABAAAAAAAAAAAAAAAgABAAAQABAAAAIAIAAAIIAAAAQAAAAAAAQAgAAAAIAIAAgABAAAQBAAAACAAAAAACIQAAAAAAAAAAAAAAAEQAAAAAEIAAAAQAAAAQEACAIAAAAEAAAAAAIEABAAEA"
        }
      },
      {
        "_index" : "flint_benchmark_bloom_filter_cardinality_64_adaptive_true_fpp_0.03_num_candidates_15",
        "_id" : "0ItKYo4BM5f06XztJTJf",
        "_score" : 1.0,
        "_source" : {
          "value" : "AAAAAQAAAAUAAAB1AAAAAAAAIAAAAAAAAAAAAAAAAAAAABAAAAAAQAAAAAAIAAAAARAAAAAAAAAEQQEAAADEBAAAAAASAgAAAEAMAAAgAAAAAAAAAQBAAAABgAACAAIAAAAAAAAAAAAAAAAAAAEAAAAAABAAAAAgAIAAAACABIBAAAAAEEACAAAAAAAAUCEAIIAAAAAAEAAIAAQBAAAEAAAAAAACAABAADAAAAAoAABAAAAAAJAAAAAAAAAAAAACAAAAAAAAAAAAAAACAAAAAAAAAAAAAACAgBgAAEEAAIAAAigAAAACEAAAAAAAAAIAAAAQAAABAAAAAAAAAAAAACAAAACACAAAAAAAAAAAIAABAAAAAAAABAAUAAgIABAAAAAAAQAAAkBAAAAAABAgBIDAAACgQAgAAAABAQAAAAAQAAACAACAAAAAAAAIQAAAAAAAAAAAAQAAAAAEAAAFwAAICgAAECQABAAEAKAEAAAAAAADAAAAAAECABAAGAAjgEAAAAACAAAAQAQAAAQgQAAgAAAAAAAAAIAAABAAAAIAAAAAAABAAIAAAgAAAACAAAAAAAAQAAKAAAAAAAAAAAAAQBAAAAAIIAAAYAAAAAAAABACAAAAAAAAAAAAUAAAAAAgQQABAABAAAABCACAAAAAAEIAAEAIAAAAgCAABAAAAAgAAACAAAAAEAAIgACAgAAAAAAAAAABAAAAAAAAAAACCAAABABAAABACAAAQAAAAAAAAIAAABAABQAAACAAAgAAAAAAAAAAmCAAoAAAAAAAAAAIEEAAAAAAAABAABAAQACAAAAAACAAAAAAIAAAAgAAIAAAICABAgAAAAABAIAAAABAAAAAAAAAAAwQAA4AQAAAAgAgAAAAAAAAgACAAAAAIIAQAAAAAAAAAQAAAAAAAAAQAAAABAAJACQQAIAQAAAAAAAAAAAAAAAAAAAgAAAAgAgACAAAAAIBAEAAQAAAAAAgAAAAABAAQAAAAAAAAEAAAACAAAAAAAAAAAAAAAAAAAEAEAEAAQkAAAAAAAAAIAAAAAAAAAAAAAgAAAAAAAAAAAAAAAACAAAAAAAAIgAAAAEEAAAAAQAAAAQgAAAAAAAAAASQAAABAAAAAAAAAAAAAAAgABAAAQABAAAAIAIAAAIIAAAAQAAAAAAAQAgAAAAIAIAAgABAAAQBAAAACAAAAAACIQAAAAAAAAAAAAAAAEQAAAAAEIAAAAQAAAAQEACAIAAAAEAAAAAAIEABAAEA"
        }
      },
      {
        "_index" : "flint_benchmark_bloom_filter_cardinality_64_adaptive_true_fpp_0.03_num_candidates_5",
        "_id" : "z4tKYo4BM5f06XztFDKb",
        "_score" : 1.0,
        "_source" : {
          "value" : "AAAAAQAAAAUAAAB1AAAAAAAAIAAAAAAAAAAAAAAAAAAAABAAAAAAQAAAAAAIAAAAARAAAAAAAAAEQQEAAADEBAAAAAASAgAAAEAMAAAgAAAAAAAAAQBAAAABgAACAAIAAAAAAAAAAAAAAAAAAAEAAAAAABAAAAAgAIAAAACABIBAAAAAEEACAAAAAAAAUCEAIIAAAAAAEAAIAAQBAAAEAAAAAAACAABAADAAAAAoAABAAAAAAJAAAAAAAAAAAAACAAAAAAAAAAAAAAACAAAAAAAAAAAAAACAgBgAAEEAAIAAAigAAAACEAAAAAAAAAIAAAAQAAABAAAAAAAAAAAAACAAAACACAAAAAAAAAAAIAABAAAAAAAABAAUAAgIABAAAAAAAQAAAkBAAAAAABAgBIDAAACgQAgAAAABAQAAAAAQAAACAACAAAAAAAAIQAAAAAAAAAAAAQAAAAAEAAAFwAAICgAAECQABAAEAKAEAAAAAAADAAAAAAECABAAGAAjgEAAAAACAAAAQAQAAAQgQAAgAAAAAAAAAIAAABAAAAIAAAAAAABAAIAAAgAAAACAAAAAAAAQAAKAAAAAAAAAAAAAQBAAAAAIIAAAYAAAAAAAABACAAAAAAAAAAAAUAAAAAAgQQABAABAAAABCACAAAAAAEIAAEAIAAAAgCAABAAAAAgAAACAAAAAEAAIgACAgAAAAAAAAAABAAAAAAAAAAACCAAABABAAABACAAAQAAAAAAAAIAAABAABQAAACAAAgAAAAAAAAAAmCAAoAAAAAAAAAAIEEAAAAAAAABAABAAQACAAAAAACAAAAAAIAAAAgAAIAAAICABAgAAAAABAIAAAABAAAAAAAAAAAwQAA4AQAAAAgAgAAAAAAAAgACAAAAAIIAQAAAAAAAAAQAAAAAAAAAQAAAABAAJACQQAIAQAAAAAAAAAAAAAAAAAAAgAAAAgAgACAAAAAIBAEAAQAAAAAAgAAAAABAAQAAAAAAAAEAAAACAAAAAAAAAAAAAAAAAAAEAEAEAAQkAAAAAAAAAIAAAAAAAAAAAAAgAAAAAAAAAAAAAAAACAAAAAAAAIgAAAAEEAAAAAQAAAAQgAAAAAAAAAASQAAABAAAAAAAAAAAAAAAgABAAAQABAAAAIAIAAAIIAAAAQAAAAAAAQAgAAAAIAIAAgABAAAQBAAAACAAAAAACIQAAAAAAAAAAAAAAAEQAAAAAEIAAAAQAAAAQEACAIAAAAEAAAAAAIEABAAEA"
        }
      },
      {
        "_index" : "flint_benchmark_min_max_cardinality_64_default",
        "_id" : "xotIYo4BM5f06XztZzKc",
        "_score" : 1.0,
        "_source" : {
          "MinMax_value_0" : 1,
          "MinMax_value_1" : 64
        }
      },
      {
        "_index" : "flint_benchmark_min_max_cardinality_64_default",
        "_id" : "x4tIYo4BM5f06XztbDII",
        "_score" : 1.0,
        "_source" : {
          "MinMax_value_0" : 1,
          "MinMax_value_1" : 64
        }
      },
      {
        "_index" : "flint_benchmark_partition_cardinality_1_default",
        "_id" : "xYtIYo4BM5f06XztYjIx",
        "_score" : 1.0,
        "_source" : {
          "value" : 1
        }
      },
      {
        "_index" : "flint_benchmark_value_set_cardinality_64_max_size_100",
        "_id" : "yItIYo4BM5f06XztcTK3",
        "_score" : 1.0,
        "_source" : {
          "value" : [
            60,
            52,
            31,
            2,
            54,
            25,
            4,
            48,
            27,
            19,
            50,
            42,
            21,
            44,
            23,
            15,
            46,
            38,
            17,
            61,
            40,
            11,
            63,
            34,
            13,
            5,
            57,
            36,
            28,
            7,
            59,
            51,
            30,
            9,
            1,
            53,
            32,
            24,
            3,
            55,
            47,
            26,
            49,
            20,
            43,
            22,
            14,
            45,
            37,
            16,
            39,
            18,
            10,
            62,
            41,
            33,
            12,
            64,
            56,
            35,
            6,
            58,
            29,
            8
          ]
        }
      }
      ...
    ]
  }
}

Issues Resolved
https://github.com/opensearch-project/sql/issues/1399
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@dai-chen do we want to move this to 0.4?

@dai-chen do we want to move this to 0.4?

Moved to 0.4. Will try to address the comments this week. Thanks!


TextBox FontSize property doesn't have any affect.

When setting TextBox Fontsize property nothing happens. I have tried both through code and the xaml side with no effect. This appears to be a bug on most controls including buttons. Luckily for buttons I have a work around. The workaround for buttons doesn't work on TextBox I'm guessing because it doesn't have the same hierarchy.
Attempts:
XAML file
<TextBox Name="UserInputTextBox" FontSize="35" />
code behind (using reactive UI):
public partial class LoginView : ReactiveUserControl<LoginViewModel>
{
    private ListBox _userNameListBox => this.FindControl<ListBox>("UserNameListBox");
    private TextBox _userInputTextBox => this.FindControl<TextBox>("UserInputTextBox");

    public LoginView()
    {
        InitializeComponent();

        this.WhenActivated(disposables => {
            this.Bind(ViewModel, vm => vm.UserInput, v => v._userInputTextBox.Text).DisposeWith(disposables);
            this.OneWayBind(ViewModel, vm => vm.SubmitEnabled, v => v._userInputTextBox.IsEnabled).DisposeWith(disposables);

            _userInputTextBox.FontSize = 35;
        });
    }
}

Button workaround:
		<Style Selector=".LoginButton > TextBlock">
			<Setter Property="FontSize" Value="35" />
			<Setter Property="Foreground" Value="White" />
		</Style>

Do you have a minimal project to reproduce? This issue is pretty weird and seems to not be a common one.

Im not sure what you mean by minimal project. I can't share the whole project as it's proprietary. Do you mean it is not common because people aren't changing the FontSize? Or the fact that FontSize doesn't affect anything? I am using the Material Avalonia  package to get some basic UI styling, but I wouldn't think that overrides when I'm setting the FontSize attribute.

 <TextBox FontSize="44" Text="Hello World"/>

Can't see any issues

In that case either create a minimal repo or ask the question in Material Avalonia. I'm pretty sure they probably have it set somewhere in styles.
https://github.com/AvaloniaCommunity/Material.Avalonia/blob/13d79e48689ca058a40ba30f06e7ef246ec7e763/Material.Styles/Button.xaml#L28

I'll ask the question there but I can override the Button FontSize it's the TextBox Im struggling with. Any idea how I would override it here. It looks like its using the control's FontSize property, but as I said trying to set it doesn't do anything.
https://github.com/AvaloniaCommunity/Material.Avalonia/blob/13d79e48689ca058a40ba30f06e7ef246ec7e763/Material.Styles/TextBox.xaml


Fix argsort inside numba.jit using kind='mergesort'

What does the code in this PR do / what does it improve?
As the title described.
Can you briefly describe how it works?
This PR is trying to solve https://github.com/XENONnT/straxen/issues/1175.
See https://numba.readthedocs.io/en/stable/reference/numpysupported.html#other-methods, numba supports kind='mergesort' in argsort function. And because mergesort is stable, see https://numpy.org/doc/1.22/reference/generated/numpy.sort.html, the result should be the same whatever package or platform we use.
Can you give a minimal working example (or illustrate with a figure)?
Please include the following if applicable:

[x] Update the docstring(s)
[ ] Update the documentation
[ ] Tests to check the (new) code is working as desired.
[ ] Does it solve one of the open issues on github?

Notes on testing

Until the automated tests pass, please mark the PR as a draft.
On the XENONnT fork we test with database access, on private forks there is no database access for security considerations.

All italic comments can be removed from this template.

Coverage: 93.469% (+0.02%) from 93.447% when pulling 0f4353f9da63d8ecc0be4a522cccfce4d9fde7d8 on fix_argsort into 9f71df501cfae5ea1a59a04acb120d04e8d6d0a6 on master.


File.join with a path kind

File.join always returns a native path:
https://github.com/crystal-lang/crystal/blob/72e6b02feba5efa3ebce3b4c768f22ca5512370a/src/file.cr#L851-L853
So if one wants to obtain a path of a particular kind, e.g. a POSIX path for use in Dir.glob, they have to ditch the File interface and instead use Path directly, or even write the highly inefficient Path.new(File.join(...)).to_posix.to_s. To keep File.join's convenience, I suggest an additional optional parameter that specifies the path kind:
class File
  def self.join(*parts : String | Path, kind : Path::Kind = Path::Kind.native) : String
  end

  # to keep parity with the other overload, always take `kind` as a named argument
  def self.join(parts : Enumerable, *, kind : Path::Kind = Path::Kind.native) : String
  end
end

Then instead of forwarding to Path.new, they would forward to Path.posix or Path.windows.

But File is all about native paths, I don't understand why it should also become a (duplicated) interface to pure paths

Wouldn't the Path constructors provide sufficient alternatives? Path.new(File.join(*args)).to_posix.to_s  can be simplified to Path.posix(*args).to_s. And that would be even easier to understand and more succinct than File.join(*args, kind: :posix).


Add phone code option in Login Screen

Need to edit the login screen and add the phone code option so anyone can access the app, current this is only for the India.

Yes pls bros add this feature, or can you pls help me how to add the feature to make it work in Nigeria


env variables do not set in created ubuntu container by chatflow

am creating a ubuntu 16.04 container using chatflow and i set the env variable  zosversion=2 but does not appear in container

the created container

Solution name: testubuntu2
Version: ubuntu:16.04
CPU: 1
Memory: 1024
Public key: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC8o0jEGYqe2k7J0TNL6Gg8h86ic3ReiC6THlBnOKPDiKProj/4uMTmi1Qf5OcLIdeHgcP+zy+ZL4kpP7N6VTALRPiTn6Lty6ZP+5mQocaJYosoGLzB6+lx1NW/zXtscv4V3goULiDEx9SBzSuD8wS0k00iHcRjmuFUIfERyYR8mjmWC/sRf1Y7qk9kQjFOLW5Sw0+RLrxr4l2ur/n8bDVgGVpzWypKIsqRU6Rf1HdXWmdAMCucPAkxR5WNies5QFOkyllxI6Fq+G9M0Uf+EubpfpC1oOMWjNFy781M4KZF+FXODcBlwevfvk0HH/5mTHOymIfwVV8vjRzycxjuQib3 pishoy@Bishoy-laptop
Env variables: zosversion=2
Solution expiration: 1d
IP Address: <IP_ADDRESS>

ssh container
ssh<EMAIL_ADDRESS>
jsx  version

3BOTDEVEL:3bot:jumpscaleX_threebot: git log -1
commit d83f639dd6cdfc69d56fc59a4979b3816ef5772c (HEAD -> development, origin/development, origin/HEAD)
Author: Rana Tarek Hassan<EMAIL_ADDRESS>Date:   Mon Apr 27 15:06:59 2020 +0200

    Pass bot to reservation register to view errors returned from register
3BOTDEVEL:3bot:jumpscaleX_threebot:

Either we remove the question altogether or fix.

I beleive we should remove the question alltogether I think the enviornments are only passed to the root/process aka entrypoint so it will not be passed on to the ssh server
@zaibon is this correct?
So in the case of our ubuntu solution we should indeed just remove them (for flist solution it could be usefull)

I think Jo's assumption is correct

verified


Update flyway-core to 8.4.2

Updates org.flywaydb:flyway-core from 7.15.0 to 8.4.2.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.flywaydb", artifactId = "flyway-core" } ]

labels: library-update, early-semver-major, semver-spec-major, commit-count:1

Superseded by #609.


Use modal component to wrap mobile chat UX

The previous fullscreen UX was confusing on mobile, based on user feedback. Switch to a modal view, just for mobile.
Screenshot

/gcbrun

/gcbrun


Incorrect gateway ID for MTCAP3 gateways

On chirpstack-mqtt-forwarder start, the gateway id is retrieved. However, for the Multitech MTCAP3 gateway, an incorrect gateway id is retrieved. The retrieved gateway ID should match the EUI of the installed LoRa card.
2024-10-22T15:46:59.485415+00:00 mtcap3 chirpstack-mqtt-forwarder[16915]: Reading gateway id
2024-10-22T15:46:59.493354+00:00 mtcap3 chirpstack-mqtt-forwarder[16915]: Received gateway id, gateway_id: 0016c0XXXXXXXXXX
root@mtcap3:/var/config/home/mtadm# mts-io-sysfs show lora/eui
00:80:00:XX:XX:XX:XX:XX
Specifying (or not) a gateway_id in the concentratord config does not change this behavior.
Using:
chirpstack-concentratord-sx1302 4.4.4
chirpstack-mqtt-forwarder 4.3.1
mLinux 6.3.0

The concentratord reads / uses the EUI embedded in the SX1302/3 chil, could
that explain the difference?
On Tue, Oct 22, 2024, 16:59 Nicolas Juteau @.***> wrote:

On chirpstack-mqtt-forwarder start, the gateway id is retrieved. However,
for the Multitech MTCAP3 gateway, an incorrect gateway id is retrieved. The
retrieved gateway ID should match the EUI of the installed LoRa card.
2024-10-22T15:46:59.485415+00:00 mtcap3 chirpstack-mqtt-forwarder[16915]:
Reading gateway id
2024-10-22T15:46:59.493354+00:00 mtcap3 chirpstack-mqtt-forwarder[16915]:
Received gateway id, gateway_id: 0016c0XXXXXXXXXX
@.***:/var/config/home/mtadm# mts-io-sysfs show lora/eui
00:80:00:XX:XX:XX:XX:XX
Specifying (or not) a gateway_id in the concentratord config does not
change this behavior.
Using:
chirpstack-concentratord-sx1302 4.4.4
chirpstack-mqtt-forwarder 4.3.1
mLinux 6.3.0
—
Reply to this email directly, view it on GitHub
https://github.com/chirpstack/chirpstack-mqtt-forwarder/issues/60, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AABIM6ORMW7NQ57XJ76Q54DZ4ZY63AVCNFSM6AAAAABQM3CXECVHI2DSMVQWIX3LMV43ASLTON2WKOZSGYYDKOBXGQYTEMA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

It appears you're right on this one (00:16:C0 IEEE MA-L is registred by Semtec). I don't understand though why Multitech don't provide the Semtec EUI on the gateway label as well as via the mts-io-sysfs command, but rather their own instead. I'll check with them.

Meanwhile, wouldn't be pertinent to provide a way to override the EUI used by chirpstack-mqtt-forwarder? I don't know if that's the point of the gateway_id parameter in concentratord, but it appears to have no effect on chirpstack-mqtt-forwarder right now.

The Concentratord config for the sx1302/3 does not provide a gateway_id config option, it is for the sx1301 only (as it does not have the EUI embedded in the chip):
https://www.chirpstack.io/docs/chirpstack-concentratord/configuration.html#chirpstack-concentratord-sx1302
But yes, it would be an idea to add a gateway_id config option to override the EUI provided by the sx1302/3 chip. If you would like to create a PR for this that would be great :-)


[Service Bus] isReceivingMessages on subscribe() output instead of receiver

This is the current shape of the API for the Receiver in v7 of Service Bus:
export interface Receiver<ReceivedMessageT> {
    close(): Promise<void>;
    entityPath: string;
    getMessageIterator(options?: GetMessageIteratorOptions): AsyncIterableIterator<ReceivedMessageT>;
    isClosed: boolean;
    isReceivingMessages(): boolean;
    peekMessages(options?: PeekMessagesOptions): Promise<ReceivedMessage[]>;
    receiveDeferredMessages(sequenceNumbers: Long | Long[], options?: OperationOptions): Promise<ReceivedMessageT[]>;
    receiveMessages(maxMessages: number, options?: ReceiveMessagesOptions): Promise<ReceivedMessageT[]>;
    receiveMode: "peekLock" | "receiveAndDelete";
    subscribe(handlers: MessageHandlers<ReceivedMessageT>, options?: SubscribeOptions): void;
}

The isReceivingMessages() is mainly useful for the subscribe() model and not so much for the others

It does not apply at all for peekMessages() and receiveDeferredMessages()
receiveMessages() doesnt really need this as one can check the status of the promise returned by it to know if the receiving is done or not
The iterator model does not need this as each loop can be awaited as well.

#9493 tracks the proposal to make subscribe() return a object that is closable.
This issue is to move the isReceivingMessages() into the above object.
Or at the very least, remove it from the Receiver and add it based on user feedback.
cc @richardpark-msft, @HarshaNalluru, @chradek

Side note: In Event Hubs, we went with isRunning on the Subscription that was returned bu subscribe().
Not sure if that was meant for a purpose different than what isReceivingMessages() in Service Bus would serve

I think we went with isRunning to signify that the subscription wasn't closed, since technically the subscription might not be receiving events yet if it hasn't connected to any partitions. It's technically correct...

I'd talked with @ramya-rao-a  about this - currently leaning towards removing it since it sounds like we added it because our receiver was unreliable (and this was a workaround for customers to detect that). There have been numerous reliability fixes in track 2 so removing this flag feels within reach.

Done with #9875


Tag grape project with "hacktoberfest" topic

Hey @dblock 👋
Could you consider to tag the Grape project with the “hacktoberfest” topic or have the “hacktoberfest-accepted” label?
https://hacktoberfest.com/participation/#maintainers
Thanks!

I added hacktoberfest to topics. We already havehacktoberfest-accepted from previous years!

We have a "you can help" label, https://github.com/ruby-grape/grape/issues?q=is%3Aopen+is%3Aissue+label%3A"you+can+help".

Awesome! Yes, that's a perfect naming as well. Thanks a lot!


added start/pause feature

PR Description 📜
Please include summary related to the issue you have fixed and describe your PR in brief over here by specifying the issue number on which you were working below
Fixes #2885

Mark the task you have completed ✅

[x] I follow CONTRIBUTING GUIDELINE & CODE OF CONDUCT of this project.
[x] I have performed a self-review of my own code or work.
[x] My changes generates no new warnings.
[x] I have followed proper naming convention showed in CONTRIBUTING GUIDELINE
[x] I have specified the respective issue number for which I have requested the new game.

Add your screenshots(Optional) 📸

Thank you soo much for contributing to our repository 💗

Thank you @Nisarg155 ,for creating the PR and contributing to our GameZone 💗
Review team will review the PR and will reach out to you soon! 😇
Make sure that you have marked all the tasks that you are done with ✅.
Thank you for your patience! 😀

Thank you  @Nisarg155 , for your valuable time and contribution in our GameZone 💗.
It’s our GameZone, so Let’s build this GameZone altogether !!🤝
Hoping to see you soon with another PR again 😇
Wishing you all the best for your journey into Open Source🚀


nf-core 1.14

PR checklist

[ ] This comment contains a description of changes (with reason).
[ ] If you've fixed a bug or added code that should be tested, add tests!

[ ] If you've added a new tool - have you followed the pipeline conventions in the contribution docs
[ ] If necessary, also make a PR on the nf-core/circrna branch on the nf-core/test-datasets repository.

[ ] Make sure your code lints (nf-core lint .).
[ ] Ensure the test suite passes (nextflow run . -profile test,docker).
[ ] Usage Documentation in docs/usage.md is updated.
[ ] Output Documentation in docs/output.md is updated.
[ ] CHANGELOG.md is updated.
[ ] README.md is updated (including new tool citations and authors/contributors).

did manual wipe of repos locally. local fork of repo got messy with dev branch


docs: add languages links

Description
See https://github.com/vitejs/docs-cn/issues/54

Additional context
We are going to need better support from VitePress in the future, but I think we should merge this first step so people can already discover the Chinese translation of the docs.

What is the purpose of this pull request?

[ ] Bug fix
[ ] New Feature
[x] Documentation update
[ ] Other

Before submitting the PR, please make sure you do the following

[x] Read the Contributing Guidelines.
[x] Read the Pull Request Guidelines and follow the Commit Convention.
[x] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
[x] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
[x] Ideally, include relevant tests that fail without this PR but pass with it.

I'll merge this one, we can later improve how it works.

The official website has not been updated.

@heng1025 we will deploy the docs together with Vite 2.1.6 soon


Documentation about roles in jwt validation is misleading

Hello,
Here about roles array: https://www.krakend.io/docs/authorization/jwt-validation/#:~:text=realm_access.roles.-,roles,-array says that:

When set, the JWT token not having at least one of the listed roles is rejected.

But below that at validation part: https://www.krakend.io/docs/authorization/jwt-validation/#validation-process

The configuration allows you to define the set of required roles. For example, a user who passes a token with roles A and B, can access an endpoint requiring "roles": ["A","C"] as it has one of the required options (A).

These 2 sentences are exactly the opposite. I think the second one is true which is (at least one role match can get endpoint access) where I can confirm via krakend-jose code ( https://github.com/krakend/krakend-jose/blob/master/jose.go#L86 )
Thank you

How are these sentences opposed?

the JWT token not having at least one of the listed roles is rejected.
Says that the token must contain one or more roles of the list

The configuration allows you to define the set of required roles. For example, a user who passes a token with roles A and B, can access an endpoint requiring "roles": ["A","C"] as it has one of the required options (A).
Says that a token which contains A can access because it contains one or more roles of the list.

How would you rephrase both? I don't understand how are you reading this.

Ok I think I misread it in the first place sorry, we can close this issue.


[processes] increase the wait interval for the manual process check test in k8s to avoid test flakiness

What does this PR do?
This increases the wait interval in the manual process check in the k8s end to end tests. This is because the workloadmeta module may not be ready when we fetch containers leading to missing container data.
Motivation
https://datadoghq.atlassian.net/browse/PROCS-4157
Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

/merge