text:
SodaCL metadata/table discovery

Generating and pushing table information such as: name, columns, database types will be performed by soda-core.
The original proposition looks like this:
profiling basic:
  tables:
    - SODATEST_%
    - include SODATEST_%
    - exclude SODATEST_%
  schema: enabled

We are however thinking about another top-level name along the lines of (based on a more explicit proposal from @janet-can:
discover tables:

I assume the rest of the controls are going to stay the same meaning that users should configure column profiling via this canonical sodaCL spec:
discover tables:
  tables:
    - SODATEST_%
    - include SODATEST_%
    - exclude SODATEST_%
  schema: enabled

@tombaeyens can you confirm this makes sense language-wise? Also, can you explain the intention behind the schema key? What does it control?

Agreed. Blessing given for naming the SodaCL top level entry discover tables:

schema key can be ignored and replaced with whatever keys make sense for the configuration of the table discovery feature.

Come to think of it, it probably does not need any configuration

Thanks @tombaeyens, I don't know what I would replace it with indeed so I guess it makes sense. We can always add later if we feel the need.

Based on this comment: https://github.com/sodadata/soda-core/issues/1256#issuecomment-1102370385
I am proposing to move sample data caputure to this DSL rather than the profile columns one.
The dsl for table discovery should therefore be:
discover tables:
  tables:
    - SODATEST_%
    - include SODATEST_%
    - exclude SODATEST_%
  collect sample data: true | false # this controls whether we capture a sample of the
    max sample size: 100 # not required, we will default to limit 500
    sampling method: random | limit
    random see: 42 # optional and only used when `sampling method` is `random` to allow for reproducibility.

collect sample data would enable sample data collection for all tables labelled for discovery. The max sample size argument will control the limit of rows to be sampled. It will default to 500 if users do not override it/configure it. The sampling method argument will control whether we just to a select * from table limit 100 or something select * from table sample row (100 rows)
NOTES:

We might, based on user-interest, allow sampling in more advanced fraction-based ways (for example see snowflake: https://docs.snowflake.com/en/sql-reference/constructs/sample.html) but it would require some more explicit controls over probabilities etc. and I would rather keep the language simple for now and think about the more advanced methods if required as I don't think people will really need that granular a set of controls for this feature.
Random-based sampling, may not work on dialects, we will therefore throw a warning to users and default to a select * from table limit 100 approach.

@tombaeyens what do you think?
@dirkgroenen FYI, I know you had some examples around sampling in your interactive mockups for data source onboarding.

@mathissedestrooper @bastienboutonnet collecting table samples is indeed also on a table level just like table discovery.  But I think it's important that the set of tables are distinct  for those 2 things.  I ll explain:
Querying a data source for all it's tables and ensuring that all tables are available in the Soda Cloud UI, is something that you typically want for all tables.  There is no real performance problem.
Capturing samples for all tables is much more demanding in terms of compute and storage requirements.  So that is something that you want to limit to a specific subset of tables.  At least that is my guess.
wdyt ?

authors: bastienboutonnet tombaeyens

repo: sodadata/soda-core


text:
Configuration path does not exist

I have added this code to my GitHub actions pipeline -
- name: Perform Soda Scan
uses: sodadata/soda-github-action@v1.0.2
env:
SODA_CLOUD_API_KEY: SODA_CLOUD_API_KEY
SODA_CLOUD_API_SECRET: SODA_CLOUD_API_SECRET
SNOWFLAKE_USERNAME: Username
SNOWFLAKE_PASSWORD: Password
with:
soda_library_version: v1.0.4
data_source: snowflake_soda_poc
configuration: ${{ github.workspace }}/soda/configuration.yaml
checks: ${{ github.workspace }}/soda/checks.yaml
It is adding /tmp/workspace/  as a prefix to my configuration path due to this i'm getting this error -
Configuration path '/tmp/workspace//home/runner/work/dbt_training/dbt_training/soda/configuration.yaml' does not exist
[17:08:14] Path "/tmp/workspace//home/runner/work/dbt_training/dbt_training/soda/checks.yaml" does not exist
Any help is appreciated...

Hey. Try not using github.workspace var in Your path. Simply define the path to the file relative to the root of the repo, so just ./soda/configuration.yaml (assuming soda is a root folder in the repo).
Same for checks file.
Ping me again if it helped or not.

Hi gregkaczan, thanks for the response. I tried removing github.workspace var in my path but still i'm getting the error.
[02:39:38] Configuration path '/tmp/workspace/./soda/configuration.yaml' does not exist
[02:39:38] Path "/tmp/workspace/./soda/checks.yaml" does not exist.
This is my project structure, am I missing any things?

THis is the issue which i'm facing...
Run sodadata/soda-github-action@v1.0.2
Run [[ "v1.0.4" ]] || { echo -e "\033[31;1;4m[Soda Library Github Action] Input: 'soda_library_version' is required\033[0m" ; exit 1; }
Run docker build
#0 building with "default" instance using docker driver
#1 [internal] load .dockerignore
#1 transferring context: 2B done
#1 DONE 0.0s
#2 [internal] load build definition from Dockerfile
#2 transferring dockerfile: 332B done
#2 DONE 0.0s
#3 [internal] load metadata for docker.io/sodadata/soda-library:v1.0.4
#3 ...
#4 [auth] sodadata/soda-library:pull token for registry-1.docker.io
#4 DONE 0.0s
#3 [internal] load metadata for docker.io/sodadata/soda-library:v1.0.4
#3 DONE 1.0s
#5 [internal] load build context
#5 transferring context: 541B done
#5 DONE 0.0s
#6 [1/3] FROM docker.io/sodadata/soda-library:v1.0.4@sha256:432e0ff11033d1deed64c3728eecc381031af6b085db0c77f77fdd356a3da7ca
#6 resolve docker.io/sodadata/soda-library:v1.0.4@sha256:432e0ff11033d1deed64c3728eecc381031af6b085db0c77f77fdd356a3da7ca done
#6 sha256:a032e966b886f1bc796b64b8992ada842ad5ac1a0f11f6109746c6dba24db1a1 0B / 206.74MB 0.1s
#6 sha256:798911fcd3a63a1c0e71388e220c8ea903c7b097445240a35f783e45f9b61e19 0B / 2.24MB 0.1s
#6 sha256:a516fe209ec158a93e313c16c338c1f40d895cdf11519f9403f701a1085ff2f3 6.49kB / 6.49kB done
#6 sha256:3153aa388d026c26a2235e1ed0163e350e451f41a8a313e1804d7e1afb857ab4 13.63MB / 29.53MB 0.2s
#6 sha256:432e0ff11033d1deed64c3728eecc381031af6b085db0c77f77fdd356a3da7ca 2.48kB / 2.48kB done
#6 sha256:a032e966b886f1bc796b64b8992ada842ad5ac1a0f11f6109746c6dba24db1a1 18.87MB / 206.74MB 0.4s
#6 sha256:798911fcd3a63a1c0e71388e220c8ea903c7b097445240a35f783e45f9b61e19 2.24MB / 2.24MB 0.3s done
#6 sha256:3153aa388d026c26a2235e1ed0163e350e451f41a8a313e1804d7e1afb857ab4 26.21MB / 29.53MB 0.4s
#6 sha256:90267fdbb62aff8ecce8f553b971a35d9dd77ab0c8647e35566fd93895647fb5 0B / 26.61MB 0.4s
#6 sha256:3153aa388d026c26a2235e1ed0163e350e451f41a8a313e1804d7e1afb857ab4 29.53MB / 29.53MB 0.5s done
#6 sha256:90267fdbb62aff8ecce8f553b971a35d9dd77ab0c8647e35566fd93895647fb5 13.63MB / 26.61MB 0.5s
#6 sha256:7331284d05ce1b245784676d279b3fc56a2f590bcf06b470d78de5e7a5a515d7 0B / 712B 0.5s
#6 extracting sha256:3153aa388d026c26a2235e1ed0163e350e451f41a8a313e1804d7e1afb857ab4
#6 sha256:a032e966b886f1bc796b64b8992ada842ad5ac1a0f11f6109746c6dba24db1a1 45.09MB / 206.74MB 0.7s
#6 sha256:90267fdbb62aff8ecce8f553b971a35d9dd77ab0c8647e35566fd93895647fb5 26.61MB / 26.61MB 0.7s done
#6 sha256:7331284d05ce1b245784676d279b3fc56a2f590bcf06b470d78de5e7a5a515d7 712B / 712B 0.7s done
#6 sha256:8a050e340e63c656fd717b234cf56648c49a9494e9523bfd5b8a889e954483d5 0B / 10.60MB 0.7s
#6 sha256:74c32a049964faf1d77a3fb312d38066b6e5001c03081e6d6852c528c176216c 0B / 93B 0.7s
#6 sha256:a032e966b886f1bc796b64b8992ada842ad5ac1a0f11f6109746c6dba24db1a1 65.01MB / 206.74MB 0.9s
#6 sha256:74c32a049964faf1d77a3fb312d38066b6e5001c03081e6d6852c528c176216c 93B / 93B 0.8s done
#6 sha256:07c7c5b3299b7ccc8c58f4afe7b8a6ccd71ea107eddfb8218e991b8249c26456 0B / 27.50kB 0.9s
#6 sha256:a032e966b886f1bc796b64b8992ada842ad5ac1a0f11f6109746c6dba24db1a1 79.22MB / 206.74MB 1.0s
#6 sha256:07c7c5b3299b7ccc8c58f4afe7b8a6ccd71ea107eddfb8218e991b8249c26456 27.50kB / 27.50kB 0.9s done
#6 sha256:931d46396003311331f995cdb1447200193d22387c3697eaee6d568969964ab5 0B / 710.07kB 1.0s
#6 sha256:a032e966b886f1bc796b64b8992ada842ad5ac1a0f11f6109746c6dba24db1a1 96.47MB / 206.74MB 1.1s
#6 sha256:8a050e340e63c656fd717b234cf56648c49a9494e9523bfd5b8a889e954483d5 1.05MB / 10.60MB 1.1s
#6 sha256:931d46396003311331f995cdb1447200193d22387c3697eaee6d568969964ab5 710.07kB / 710.07kB 1.1s done
#6 sha256:9708583fc2e6273901404fa80f1baa981f31e8c85681ebfaac24e3f593a96211 0B / 665.20MB 1.1s
#6 sha256:a032e966b886f1bc796b64b8992ada842ad5ac1a0f11f6109746c6dba24db1a1 109.05MB / 206.74MB 1.2s
#6 sha256:8a050e340e63c656fd717b234cf56648c49a9494e9523bfd5b8a889e954483d5 5.24MB / 10.60MB 1.2s
#6 sha256:a032e966b886f1bc796b64b8992ada842ad5ac1a0f11f6109746c6dba24db1a1 140.51MB / 206.74MB 1.4s
#6 sha256:8a050e340e63c656fd717b234cf56648c49a9494e9523bfd5b8a889e954483d5 10.60MB / 10.60MB 1.3s done
#6 sha256:1fbe1ec83f7ff8428515785a00a6f05ac6a57d06eabe59cb79028d2d1fd28d21 0B / 209.65kB 1.4s
#6 sha256:a032e966b886f1bc796b64b8992ada842ad5ac1a0f11f6109746c6dba24db1a1 154.14MB / 206.74MB 1.5s
#6 sha256:1fbe1ec83f7ff8428515785a00a6f05ac6a57d06eabe59cb79028d2d1fd28d21 209.65kB / 209.65kB 1.4s done
#6 sha256:a032e966b886f1bc796b64b8992ada842ad5ac1a0f11f6109746c6dba24db1a1 167.77MB / 206.74MB 1.6s
#6 sha256:a032e966b886f1bc796b64b8992ada842ad5ac1a0f11f6109746c6dba24db1a1 180.36MB / 206.74MB 1.7s
#6 sha256:a032e966b886f1bc796b64b8992ada842ad5ac1a0f11f6109746c6dba24db1a1 206.74MB / 206.74MB 1.9s
#6 sha256:9708583fc2e6273901404fa80f1baa981f31e8c85681ebfaac24e3f593a96211 37.75MB / 665.20MB 1.9s
#6 sha256:9708583fc2e6273901404fa80f1baa981f31e8c85681ebfaac24e3f593a96211 92.27MB / 665.20MB 2.3s
#6 extracting sha256:3153aa388d026c26a2235e1ed0163e350e451f41a8a313e1804d7e1afb857ab4 1.8s done
#6 sha256:a032e966b886f1bc796b64b8992ada842ad5ac1a0f11f6109746c6dba24db1a1 206.74MB / 206.74MB 2.6s done
#6 sha256:9708583fc2e6273901404fa80f1baa981f31e8c85681ebfaac24e3f593a96211 140.51MB / 665.20MB 2.7s
#6 extracting sha256:a032e966b886f1bc796b64b8992ada842ad5ac1a0f11f6109746c6dba24db1a1
#6 sha256:9708583fc2e6273901404fa80f1baa981f31e8c85681ebfaac24e3f593a96211 183.50MB / 665.20MB 3.0s
#6 sha256:9708583fc2e6273901404fa80f1baa981f31e8c85681ebfaac24e3f593a96211 220.20MB / 665.20MB 3.3s
#6 sha256:9708583fc2e6273901404fa80f1baa981f31e8c85681ebfaac24e3f593a96211 254.80MB / 665.20MB 3.6s
#6 sha256:9708583fc2e6273901404fa80f1baa981f31e8c85681ebfaac24e3f593a96211 293.60MB / 665.20MB 3.9s
#6 sha256:9708583fc2e6273901404fa80f1baa981f31e8c85681ebfaac24e3f593a96211 353.37MB / 665.20MB 4.3s
#6 sha256:9708583fc2e6273901404fa80f1baa981f31e8c85681ebfaac24e3f593a96211 396.36MB / 665.20MB 4.6s
#6 sha256:9708583fc2e6273901404fa80f1baa981f31e8c85681ebfaac24e3f593a96211 455.08MB / 665.20MB 5.1s
#6 sha256:9708583fc2e6273901404fa80f1baa981f31e8c85681ebfaac24e3f593a96211 492.97MB / 665.20MB 5.4s
#6 sha256:9708583fc2e6273901404fa80f1baa981f31e8c85681ebfaac24e3f593a96211 530.58MB / 665.20MB 5.7s
#6 sha256:9708583fc2e6273901404fa80f1baa981f31e8c85681ebfaac24e3f593a96211 574.62MB / 665.20MB 6.0s
#6 sha256:9708583fc2e6273901404fa80f1baa981f31e8c85681ebfaac24e3f593a96211 613.42MB / 665.20MB 6.3s
#6 sha256:9708583fc2e6273901404fa80f1baa981f31e8c85681ebfaac24e3f593a96211 665.20MB / 665.20MB 6.7s
#6 extracting sha256:a032e966b886f1bc796b64b8992ada842ad5ac1a0f11f6109746c6dba24db1a1 5.0s
#6 sha256:9708583fc2e6273901404fa80f1baa981f31e8c85681ebfaac24e3f593a96211 665.20MB / 665.20MB 9.2s done
#6 extracting sha256:a032e966b886f1bc796b64b8992ada842ad5ac1a0f11f6109746c6dba24db1a1 8.9s done
#6 extracting sha256:798911fcd3a63a1c0e71388e220c8ea903c7b097445240a35f783e45f9b61e19 0.1s done
#6 extracting sha256:90267fdbb62aff8ecce8f553b971a35d9dd77ab0c8647e35566fd93895647fb5 0.1s
#6 extracting sha256:90267fdbb62aff8ecce8f553b971a35d9dd77ab0c8647e35566fd93895647fb5 0.5s done
#6 extracting sha256:7331284d05ce1b245784676d279b3fc56a2f590bcf06b470d78de5e7a5a515d7 done
#6 extracting sha256:8a050e340e63c656fd717b234cf56648c49a9494e9523bfd5b8a889e954483d5
#6 extracting sha256:8a050e340e63c656fd717b234cf56648c49a9494e9523bfd5b8a889e954483d5 0.6s done
#6 extracting sha256:74c32a049964faf1d77a3fb312d38066b6e5001c03081e6d6852c528c176216c done
#6 extracting sha256:07c7c5b3299b7ccc8c58f4afe7b8a6ccd71ea107eddfb8218e991b8249c26456 done
#6 extracting sha256:931d46396003311331f995cdb1447200193d22387c3697eaee6d568969964ab5 0.1s done
#6 extracting sha256:9708583fc2e6273901404fa80f1baa981f31e8c85681ebfaac24e3f593a96211
#6 extracting sha256:9708583fc2e6273901404fa80f1baa981f31e8c85681ebfaac24e3f593a96211 5.1s
#6 extracting sha256:9708583fc2e6273901404fa80f1baa981f31e8c85681ebfaac24e3f593a96211 10.1s
#6 extracting sha256:9708583fc2e6273901404fa80f1baa981f31e8c85681ebfaac24e3f593a96211 15.2s
#6 extracting sha256:9708583fc2e6273901404fa80f1baa981f31e8c85681ebfaac24e3f593a96211 19.2s done
#6 extracting sha256:1fbe1ec83f7ff8428515785a00a6f05ac6a57d06eabe59cb79028d2d1fd28d21
#6 extracting sha256:1fbe1ec83f7ff8428515785a00a6f05ac6a57d06eabe59cb79028d2d1fd28d21 0.1s done
#6 DONE 36.3s
#7 [2/3] COPY entrypoint.sh /entrypoint.sh
#7 DONE 0.0s
#8 [3/3] RUN chmod +x /entrypoint.sh
#8 DONE 0.3s
#9 exporting to image
#9 exporting layers
#9 exporting layers 2.2s done
#9 writing image sha256:afda989c8b6df8713136fca9d73e4ded39b31125e119ec3c4fa4789626fe9ef0 done
#9 naming to docker.io/library/soda_action_dd5d440cacad6edb982f5f0be466aafc095a4cfc done
#9 DONE 2.2s
Run env > .env_file
Run docker run
[05:28:37] Soda Library 1.0.4
[05:28:37] Soda Core 3.0.39
[05:28:37] Configuration path '/tmp/workspace//home/runner/work/dbt_training/dbt_training/soda/configuration.yaml' does not exist
[05:28:37] Path "/tmp/workspace//home/runner/work/dbt_training/dbt_training/soda/checks.yaml" does not exist
[05:28:37] By downloading and using Soda Library, you agree to Soda's Terms & Conditions (https://go.soda.io/t&c) and Privacy Policy (https://go.soda.io/privacy).
[05:28:37] You have not configured Soda Library to work with Soda Cloud. Add Soda Cloud API keys (https://go.soda.io/configure) to run a scan.
[05:28:37] Error occurred while executing scan.
| Pre-scan validation failed, see logs for details.
Saving scan results to soda_scan_results_raw.json
[05:28:37] Data source 'snowflake_soda_poc' not present in the configuration. Configured data sources:
Traceback (most recent call last):
File "/usr/local/bin/soda", line 8, in
sys.exit(main())
File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 1157, in call
return self.main(*args, **kwargs)
File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 1078, in main
rv = self.invoke(ctx)
File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 1688, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 1434, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 783, in invoke
return __callback(*args, **kwargs)
File "/usr/local/lib/python3.9/dist-packages/soda/telemetry/soda_tracer.py", line 79, in wrapper
raise e
File "/usr/local/lib/python3.9/dist-packages/soda/telemetry/soda_tracer.py", line 72, in wrapper
result = fn(*original_args, **original_kwargs)
File "/usr/local/lib/python3.9/dist-packages/soda/cli/cli.py", line 230, in scan
sys.exit(scan.execute())
File "/usr/local/lib/python3.9/dist-packages/soda/scan.py", line 714, in execute
SodaCloud.build_scan_results(self, scan_metadata),
File "/usr/local/lib/python3.9/dist-packages/soda/cloud/soda_cloud.py", line 94, in build_scan_results
default_data_source = scan._get_or_create_data_source_scan(scan._data_source_name).data_source
AttributeError: 'NoneType' object has no attribute 'data_source'
Run echo -e "\033[36;1m-----------------------------\033[0m"

Still don't understand how the path gets constructed as
/tmp/workspace//home/runner/work/dbt_training/dbt_training/soda/configuration.yaml
and not as
/tmp/workspace/./soda/configuration.yaml
What is the contents of soda folder?
Are You perhaps running this on local runner?
Please provide action configuration in Your pipeline.
As this is not enough to figure out why the path is not found.
All the repo files, including soda folder are being mounted under the /tmp/workspace so it should be accessible there normally.

No we are getting these error - /tmp/workspace/./soda/configuration.yaml

the contents of soda folder are -

What do you mean by this? -  "Are You perhaps running this on local runner? and Please provide action configuration in Your pipeline."

It seems You configured the action to use soda/configuration.yaml but the file is actually soda/configuration.yml.
Notice the extension: yaml vs yml
Change config of the action in the pipeline to:
configuration: ./soda/configuration.yml
checks: ./soda/checks.yml

Hey man!!! thanks for pointing it out. It is fixed now. Thanks for your help. Really appreciate it. :)

Awesome, happy testing!

source: gharchive/issue

repo: sodadata/soda-github-action

license_type: permissive

license_source: github-api


text:
21BACB02_ADITHYANSUBHASH

Issue/Feature Description:
Authentication error in kjc web portal
Why this issue to fixed / feature is needed(give scenarios or use cases):
it takes too much of time
and facing network issues
How to reproduce, in case of a bug:
connecting with other network connections
Other Notes /  Environment Information: (Please give the env information, log link or any useful information for this issue)
nil

@kalaiselvikks76


text:
Prefilter don't use all the memory available

Expected Behavior
I'm giving to MMSeqs2 360G of memory with 36 threads. I was expecting that it will use all this memory to increase the prefiltering speed.
Current Behavior
During the prefiltering step, MMSeqs2 used only 10% of the memory. I think he is using 80% of the estimated memory consumption, because it compute 48G for the Estimated memory consumption,  but I'm not sure.
Context
I'm currently trying to create protein families with a large database. I have 50 million proteins to cluster. I write a workflow based on uniclust. I would to increase the speed of the workflow, particularly on prefilter step, without loose the sensibility. I tried to use --split-memory-limit to increase the memory but it's not working. There is another solution ?
Here it's the command line that I would to increase speed :
mmseqs search $INPUT $INPUT "$ALIGN_DIR/align" $TMP_DIR --max-seqs 1000 -c 0.8 --comp-bias-corr 1 -s 7 --alignment-mode 3 --min-seq-id 0.3 --threads 36
Your Environment
Architecture :        x86_64
Processeur(s) :       36
Thread(s) par cœur : 1
Cœur(s) par socket : 18
Socket(s) :           2
Nœud(s) NUMA :       2
Identifiant constructeur : GenuineIntel
Famille de processeur : 6
Modèle :             85
Nom de modèle :      Intel(R) Xeon(R) Gold 6150 CPU @ 2.70GHz
Révision :           4

Thanks for your work

The database is not large enough to use 300GB of RAM (See https://github.com/soedinglab/MMseqs2/wiki#memory-consumption). So it would be expected to use far less. However, if MMseqs2 was only uses 30GB of 300GB, then that would be weird. Could you post the full log?

The database is not large enough to use 300GB of RAM (See https://github.com/soedinglab/MMseqs2/wiki#memory-consumption). So it would be expected to use far less. However, if MMseqs2 was only uses 30GB of 300GB, then that would be weird. Could you post the full log?

It is very long so I prefer to give to you all the log in a file. You can find the search step from line 723 or below, but I prefer to give to you everything.
prefilter /env/cns/bigtmp2/PANFAM/PipelineProteome//CLUST/PANFAM80/panfam_subDB /env/cns/bigtmp2/PANFAM/PipelineProteome//CLUST/PANFAM80/panfam_subDB /env/cns/bigtmp2/PANFAM/PipelineProteome//ALIGN/635041581728617992/pref_0 --sub-mat nucl:nucleotide.out,aa:blosum62.out --seed-sub-mat nucl:nucleotide.out,aa:VTML80.out -k 0 --k-score 2147483647 --alph-size nucl:5,aa:21 --max-seq-len 65535 --max-seqs 1000 --split 0 --split-mode 2 --split-memory-limit 0 -c 0.8 --cov-mode 0 --comp-bias-corr 1 --diag-score 1 --exact-kmer-matching 0 --mask 1 --mask-lower-case 0 --min-ungapped-score 15 --add-self-matches 0 --spaced-kmer-mode 1 --db-load-mode 0 --pca 1 --pcb 1.5 --threads 36 --compressed 0 -v 3 -s 7.0

Query database size: 12187255 type: Aminoacid
Estimated memory consumption: 42G
Target database size: 12187255 type: Aminoacid
Index table k-mer threshold: 100 at k-mer size 6
Index table: counting k-mers
[=================================================================] 12.19M 26s 362ms
Index table: Masked residues: 43826477
Index table: fill
[=================================================================] 12.19M 38s 306ms
Index statistics
Entries:          3083105370
DB size:          18129 MB
Avg k-mer size:   48.173521
Top 10 k-mers
    GPGGTL	40332
    GQQVAR	22194
    GEGGVV	20313
    NAIAAG	18525
    YTGTPK	18522
    ALAIAR	16978
    GFVAVR	15587
    GPGGTT	14728
    GEGGTL	13758
    LAMHRT	13125
Time for index table init: 0h 1m 7s 827ms
Process prefiltering step 1 of 1

k-mer similarity threshold: 100
Starting prefiltering scores calculation (step 1 of 1)
Query db start 1 to 12187255
Target db start 1 to 12187255
[======

pipeline.log
Thanks

It is very long so I prefer to give to you all the log in a file. You can find the search step from line 723 or below, but I prefer to give to you everything.
prefilter /env/cns/bigtmp2/PANFAM/PipelineProteome//CLUST/PANFAM80/panfam_subDB /env/cns/bigtmp2/PANFAM/PipelineProteome//CLUST/PANFAM80/panfam_subDB /env/cns/bigtmp2/PANFAM/PipelineProteome//ALIGN/635041581728617992/pref_0 --sub-mat nucl:nucleotide.out,aa:blosum62.out --seed-sub-mat nucl:nucleotide.out,aa:VTML80.out -k 0 --k-score 2147483647 --alph-size nucl:5,aa:21 --max-seq-len 65535 --max-seqs 1000 --split 0 --split-mode 2 --split-memory-limit 0 -c 0.8 --cov-mode 0 --comp-bias-corr 1 --diag-score 1 --exact-kmer-matching 0 --mask 1 --mask-lower-case 0 --min-ungapped-score 15 --add-self-matches 0 --spaced-kmer-mode 1 --db-load-mode 0 --pca 1 --pcb 1.5 --threads 36 --compressed 0 -v 3 -s 7.0

Query database size: 12187255 type: Aminoacid
Estimated memory consumption: 42G
Target database size: 12187255 type: Aminoacid
Index table k-mer threshold: 100 at k-mer size 6
Index table: counting k-mers
[=================================================================] 12.19M 26s 362ms
Index table: Masked residues: 43826477
Index table: fill
[=================================================================] 12.19M 38s 306ms
Index statistics
Entries:          3083105370
DB size:          18129 MB
Avg k-mer size:   48.173521
Top 10 k-mers
    GPGGTL	40332
    GQQVAR	22194
    GEGGVV	20313
    NAIAAG	18525
    YTGTPK	18522
    ALAIAR	16978
    GFVAVR	15587
    GPGGTT	14728
    GEGGTL	13758
    LAMHRT	13125
Time for index table init: 0h 1m 7s 827ms
Process prefiltering step 1 of 1

k-mer similarity threshold: 100
Starting prefiltering scores calculation (step 1 of 1)
Query db start 1 to 12187255
Target db start 1 to 12187255
[======

pipeline.log
Thanks

Everything seems to be going alright. As this is a later clustering step, fewer sequences (~12M) remain to be clustered. The memory requirement goes down with the number of sequences remaining.

Everything seems to be going alright. As this is a later clustering step, fewer sequences (~12M) remain to be clustered. The memory requirement goes down with the number of sequences remaining.

Okay I was thinking this too but I would to be sure there was no problem.
So there is nothing to do to win time at this step, except changing the sensitivity or the max-seqs ?

Okay I was thinking this too but I would to be sure there was no problem.
So there is nothing to do to win time at this step, except changing the sensitivity or the max-seqs ?

What parameters did you use (the log doesn't show the call to mmseqs (easy-)cluster)? What MMseqs2 version/commit is this (please compile from a git checkout if you compile from source, not by downloading the tar.gz/zip)?
It seems like you are using the single step clustering, that should be much slower than the cascaded clustering.

What parameters did you use (the log doesn't show the call to mmseqs (easy-)cluster)? What MMseqs2 version/commit is this (please compile from a git checkout if you compile from source, not by downloading the tar.gz/zip)?
It seems like you are using the single step clustering, that should be much slower than the cascaded clustering.

At this step I just want to use search and use the result to cluster at 30% identity and 50% (after filter) like uniclust.
I'm currently using MMSeqs2 version 12.git113e321
When I use cluster I don't use the argument --single-step-clustering, so I think I'm doing a cascaded clustering.

At this step I just want to use search and use the result to cluster at 30% identity and 50% (after filter) like uniclust.
I'm currently using MMSeqs2 version 12.git113e321
When I use cluster I don't use the argument --single-step-clustering, so I think I'm doing a cascaded clustering.

I am not sure what exactly you are running currently. Could you make a list of all MMseqs2 commands you are running or link to the script you are running?
Using the Uniclust pipeline doesn't really make sense anymore, since it's extremely slow.
You should use multiple separate mmseqs cluster calls with --cluster-reassign at different --min-seq-id levels.

I am not sure what exactly you are running currently. Could you make a list of all MMseqs2 commands you are running or link to the script you are running?
Using the Uniclust pipeline doesn't really make sense anymore, since it's extremely slow.
You should use multiple separate mmseqs cluster calls with --cluster-reassign at different --min-seq-id levels.

Sorry for the delay, I had to work on another project.
The first step is to remove the fragments :

prefilter at --max-seqs 4000 --min-ungapped-score 100 --comp-bias-corr 0  -s 1
rescorediagonal --min-seq-id 0.9 -c 0.95 --cov-mode 1
cluster --cluster-mode 2
createsubdb
clusthash --min-seq-id 0.9
cluster --cluster-mode 2
createsubdb
createsubdb
filterdb
align -c 0.9 --alignment-mode 2 --min-seq-id 0.9 --comp-bias-corr 0
cluster --cluster-mode 2
createsubdb

The second step is to create family at 80% covery and 80% of identity :

mmseqs cluster --max-seqs 300 -c 0.8 --comp-bias-corr 1 -s 4 --kmer-per-seq 80 --alignment-mode 2 --min-seq-id 0.8 -e 0.001 --max-seq-len 32768 --max-rejected 2147483647 --cluster-mode 0
mmseqs createsubdb

The next step consists in aligning at 30% of identity and 80% of coverage :

mmseqs search --max-seqs 1000 -c 0.8 --comp-bias-corr 1 -s 7 --alignment-mode 3 --min-seq-id 0.3
mmseqs createsubdb

To finish I cluster at 50% of identity and 30% of identity :

 mmseqs filterdb --filter-column 3 --filter-regex '(0\.[5-9][0-9]{2}|1\.000)'
mmseqs clust cluster-mode 0 (at 50%)
mmseqs clust cluster-mode 0 (at 30%)

I hope you understand and you could help me to improve it.
Thanks

authors: jpjarnoux milot-mirdita

license: MIT


text:
easy-taxonomy for contigs

Not sure if this is a bug or if I am missing a flag that would make this all work as expected.
Expected Behavior
I wish to taxonomically annotate contigs using the mmseqs easy-taxonomy workflow.
I see from your documentation (https://github.com/soedinglab/MMseqs2/wiki#taxonomy-output-and-tsv) that it is possible to calculate the LCA of a contig predicted ORFs. With the output file produced listing the contig_name along with the total number of predicted ORFs and the number of those ORFs with top hits that agree with the assigned LCA of the contig.
Current Behavior
When I run the following command:
mmseqs easy-taxonomy contigs.fasta swissprotDB tax tmp

I get the following results files:
tax_lca.tsv
tax_report
tax_tophit_aln
tax_tophit_report

None of which contain the expected output described in the documentation.
I have had a look at using aggregatetax command, but run into problem with the createtsv command not reassigning the contig names correctly.
mmseqs createdb contigs.fasta contigsDb
mmseqs extractorfs contigsDb orfsAaDb --translate 1
mmseqs taxonomy orfsAaDb swissprotDB taxPerOrf tmp --tax-output-mode 2
mmseqs aggregatetaxweights swissprotDB orfsAaDb_h taxPerOrf taxPerOrf_aln taxPerContig --majority 0.5
mmseqs createtsv orfsAaDb contigsDb taxPerContig aggregatetaxResult.tsv

Your Environment
MMseqs2 Version: 113e3212c137d026e297c7540e1fcd039f6812b1
Pre-compiled binary

Thanks for your help in advance.
Cheers,
Tim.

easy-taxonomy does already what you want
here is the output of one contig of tax_lca.tsv with an added header:
CONTIG_NAME TAX_ID TAX_RANK NAME TOTAL_FRAGS ASSIGNED_FRAGS FRAGS_AGREEMENT
query  3702    species Arabidopsis thaliana    2       2       2       1.000

From what I understand, the last few numbers is what you want right?

So, your results are exactly what I am looking for, however, when I run mmseqs easy-taxonomy bin.1.fa NR bin.1.tax tmp --threads 24, I get the following output.
$ head -n 4 bin.1.tax_lca.tsv
scaffold00022005	2590670	species	Aestuariibacter sp. GS-14
scaffold00022061	1046	family	Chromatiaceae
scaffold00022138	2590670	species	Aestuariibacter sp. GS-14
scaffold00022216	2590670	species	Aestuariibacter sp. GS-14

For some reason, the 'FRAGS' columns are missing from my results file.

Can you post the first few lines of bin.1.fa please?

>scaffold00000068
CTGACGATCAGGCCGGCCGGATCATCGGCGCCGCGGTTGATCCGCAGGCCGGTCGCGAGG
CGCTGGAGGCGGGTGGAGAGGTCGGTGTTCGAGCGGTTCAGGTTGTTCTGCGCAATGAGC
GACGGAACATTCGTATTGATGCGAGCCATGGCAATCCTCCTTGATTGAGAGGCCCTTCGC
GGGAGCAGTCGTCAGGCGGTCTCGCGCCTGGAAGTCGGATTCGCCGCAAGTCGCGCGGCT
GCAGGCAGGACCGTCCCGCCCGGAGTGGCCTTCGCGCCGCGCGAACTCCCGCGCGGGCGG
AGTGAACCAAGCTCGCCACGGAACGCCGCGGCCTGCTGGTTCTCGTTCCTGATGGCGTCG
TACACCTCCTTGCGGTGCACCGCCACGGTTGCCGGCGCCTTGATGCCGATTCGCACCTTG
TCGCCGCGGATATCGACGATCGTGAGTTCGACGTCGTCGCCGATCATGATCGTCTCGTCG
ATCTGTCGTGAGAGCACCAGCATGTGCGGGCTCCTTTCTTGCGGGCATCCATGCCCGGTG

I just looked up when the commit you listed (113e3212c137d026e297c7540e1fcd039f6812b1) is is from and its ancient. please update to the latest release and everything should work fine.

Updating to the most recent version fixed the issue. My apologies, I didn't realize how old my version had gotten.

authors: TimothyStephens milot-mirdita


text:
[#66] Fix metrix server and gateway server bootstrap

Motivation:
Fix metrics server's bootstrap and gateway server's bootstrap
Modification:
Add spring-boot-maven-plugin for metrics and gateway server
Result:
Fixes #66
If there is no issue then describe the changes introduced by this PR.

https://github.com/sofastack/sofa-lookout/pull/65  @xzchaoo It will be closed.

source: gharchive/pull-request

authors: chpengzh luyiisme

repo: sofastack/sofa-lookout


text:
Evaluate "selectionDirection" property

The selectionDirection attribute of a textarea element can be set but according to the spec - http://www.w3.org/TR/html5/forms.html#dom-textarea/input-selectiondirection - this value does not actually do anything from a "setting" perspective, though it does contain a value during text selection to be used in a "getter" perspective.  Do we want to adjust the description of this property at #/demos/sl-textarea to align with this?
This then leads into the next item which is this attribute is set inconsistently across browsers.  Chrome on OS X at least does not have this value populated.  Given this (and other browsers should be tested too) do we even want to expose this property?  What role do we want this library to play?  Normalize across things or provide support pass-though and those environments that do will?
There is a skipped integration test for this component and property that needs to either be removed or built out depending on the outcome of this decision.

https://code.google.com/p/chromium/issues/detail?id=333622 is a bug against Chrome for this so perhaps it is isolated.

My opinion should carry the least weight on something like this.
Pass-through.

Update: tested on IE and returns undefined.

IMO we should not expose this property until it is supported consistently and is testable. We could pass through but it's just more mental overhead for the developer using the library.

I doubt the developer has any real use-case for this property right now.  Going the pass-through route enables us to pass the test and forget about it.  When someone actually has a use-case for it, it will hopefully work in their target browsers.
However, if there's no use-case; why have a test case?
(verified IE not liking this property in any capacity but does support the select event, oddly enough)

New solution to handle present and future.
Instead of binding the ember attribute to the dom property.... Why not set the ember attribute as a computed property based on selectionStart and selectionEnd.  Those tests already pass, just calculate "forward" and "backward" based on selectionStart < selectionEnd.

@SpikedKira Since some web browsers don't support the property, that would seem like a hacky solution to add the desired functionality.

@SpikedKira after some experimentation it seems that we cannot infer the selection direction based on selectionStart and selectionEnd because regardless of direction, the values remain consistent regardless of direction and don't "flip" as one would expect when changing selection direction. http://jsfiddle.net/4k69qyp7/3/

verified (start is always less than or equal to end)
looks like a skip :S

authors: SpikedKira azizpunjani erangeles notmessenger

repo: softlayer/sl-ember-components

license: mit

license_source: bigquery


text:
Add 'merged' field to pull request

This field appears to always exists in pull requests and is pretty useful.
Is adding a new field to a struct considered a breaking change? If so, it's going to be hard to fix missing fields.

@jasonwhite it's fine I'm due for a release soon that has enough changes that I'm probably going to bump the version any way

authors: jasonwhite softprops

repo: softprops/hubcaps


text:
Setting the namespace via a source AndroidManifest.xml's package attribute is deprecated.

Bug
Setting the namespace via a source AndroidManifest.xml's package attribute is deprecated.
Environment info
System:
  OS: macOS 13.5.2
Binaries:
  Node:
    version: 16.17.0
    path: ~/.nvm/versions/node/v16.17.0/bin/node
  npm:
    version: 9.8.0
    path: ~/.nvm/versions/node/v16.17.0/bin/npm
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 23.0
      - iOS 17.0
      - macOS 14.0
      - tvOS 17.0
      - watchOS 10.0
  Android SDK:
    API Levels:
      - "33"
    Build Tools:
      - 33.0.2
    System Images:
      - android-33 | Google APIs ARM 64 v8a
IDEs:
  Android Studio: 2022.3 AI-223.8836.35.2231.10671973
  Xcode:
    version: 15.0/15A240d
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 16.0.2
    path: /usr/bin/javac
  Ruby:
    version: 2.6.10
    path: /usr/bin/ruby
npmPackages:
  "@react-native-community/cli":
    installed: 11.3.8
    wanted: ^11.3.8
  react:
    installed: 18.2.0
    wanted: 18.2.0
  react-native:
    installed: 0.72.5
    wanted: 0.72.5

info Installing the app...

> Task :react-native-svg:processDebugManifest
package="com.horcrux.svg" found in source AndroidManifest.xml: /Users/***/node_modules/react-native-svg/android/src/main/AndroidManifest.xml.
Setting the namespace via a source AndroidManifest.xml's package attribute is deprecated.
Please instead set the namespace (or testNamespace) in the module's build.gradle file, as described here: https://developer.android.com/studio/build/configure-app-module#set-namespace
This migration can be done automatically using the AGP Upgrade Assistant, please refer to https://developer.android.com/studio/build/agp-upgrade-assistant for more information.

Library version: 13.9.0

hi did you fix this problem or found a fix for this?

No, it's just a warning. It doesn't stop me from installing the app.

Hello @VMBindraban,
Can you share the example app to reproduce that issue?
Thank you

@bohdanprog Installing the package and building the app will give this warning.

authors: VMBindraban ashen99 bohdanprog

repo: software-mansion/react-native-svg


text:
Svg Image pointerEvents="none" not working on Android

In an SVG with a transparent image I set pointerEvents="none" to allow another Image to receive the gesture events.
It is working fine on Web and on iOS.
It is not working on Android.
Here is a simple snack working fine on web and iOS and not working on Android that shows the problem.
In the snack if you tap on the smiling face on Android the gesture event is not firing.
https://snack.expo.dev/@lorenzoangelini/rn-svg-gesture-image-gesture-swallowing
Thank you, I am at your disposal for any need for clarification.

My performance here is exactly the opposite of yours. I set pointerEvents to have no effect on IOS, but it works on other devices

Hi @lorenzo-ange, @GrinZero,
The issue is related to React Native. My colleague fixed it. Here is the PR that resolves the problem.

authors: GrinZero bohdanprog lorenzo-ange


text:
Support casm serialised output

Problem
As of now,  lib target compilation (as opposed to starknet contract targets) is capable of producing CASM artefacts in a textual, human readable format only (equivalent to sierra-compile compiler cli). In contrast, starknet contract compilation uses serialisable json format instead. It is possible to define a similar serialisable casm format for non-contract projects as well. This alternative should be supported as an artefact of lib target compilation.
Proposed solution

Modify lib target properties to allow casm artefact format specification

lib target properties are defined here: https://github.com/software-mansion/scarb/blob/ba2c45574cf149a2d7422cb7c89aef5a203ec970/scarb/src/compiler/compilers/lib.rs#L18-L22
Analogously  to sierra artefact, it should allow casm and casm_text boolean inputs.
casm should create json serialized artefacts, while casm-text should create textual ones.
By default both should be disabled.
This properties will be available to users as casm and casm-text keys on [lib] object in Scarb.toml manifest files.

Modify lib target compiler to produce new artefacts.

This compiler abstraction is implemented in this file: https://github.com/software-mansion/scarb/blob/ba2c45574cf149a2d7422cb7c89aef5a203ec970/scarb/src/compiler/compilers/lib.rs#L39
Should read properties from previous point and produce artefacts accordingly to user specification.
Artefact for serialised output should be written with .casm.json extension into the target directory with target name as filename.
Artefact for textual output should be written with .casm extension into the target directory, with the same name.

Ensure new artefact type is produced

It should be enough to modify this test case https://github.com/software-mansion/scarb/blob/ba2c45574cf149a2d7422cb7c89aef5a203ec970/scarb/tests/build_targets.rs#L72

Notes
See https://github.com/software-mansion/scarb/pull/637/files for similar change introducing new artefact format.

Analogously  to sierra artefact, it should allow casm and casm_text boolean inputs.
casm should create json serialized artefacts, while casm-text should create textual ones.
By default both should be disabled.
This properties will be available to users as casm and casm-text keys on [lib] object in Scarb.toml manifest files.

I'm not entirely sure about this ones; perhaps we should consult this with Ori or Ariel. For CASM it kinda makes sense to still output text as the default, isn't it?

I'm not entirely sure about this ones; perhaps we should consult this with Ori or Ariel. For CASM it kinda makes sense to still output text as the default, isn't it?

I personally don't see the point of it since you there is no use for that output. I believe it is just something nice to look at.
Given the knowledge I have, for casm to make sense it needs to have some metadata that describes it such as Entrypoints, Builtins and Hints that it is using. If it is in something easily parseable format (such as json) it really helps other non-rusty tools.

I've asked Cairo team about this.

OK, discussed privately. Let's make JSON the default, and add casm-text option.

Hi @rodrigo-pino !
Are you working on this?

Hi @maciektr, sorry just did an initial scope analysis gathering what I needed to implement, I found in that search that I will need Sierra metadata as well since in order to made a Cairo 1 runner you require metadata that exists on both Sierra and Casm (but we can make separate PRs for
I haven't implemented much, but be sure I (or someone from the team) will take on this since we do need it at some point in not the far future. If you want to put it backlog or something, I understand. I'll ping you right here as soon as we are ready to take on this!

Sure, I understand completely! I will put it back to backlog, but it's still yours!

Closing as not planned since release of universal-sierra-compiler (software-mansion/universal-sierra-compiler) which should provide support for all different kinds of sierra to casm compilation.

authors: maciektr mkaput rodrigo-pino

repo: software-mansion/scarb


text:
Draft: Httpclient core

closes #1401

Looks good so far :) I think we'll need to come up with a better package name than sttp.client3.httpclient.HttpClientBackend though (and is it in monix as well)

Or maybe we should have sttp.client3.HttpClientSyncBackend at the top-level, and all the supporting classes inside .internal.httpclient?

Yeah I am aware.
And packaging for effects is ok ?

Hm I guess ... why wouldn't it be ok? :)

Just want to be sure

HttpClient tests are in a different package than implementations (e.g. HttpClientSyncHttpTest) - would be good to keep this consistent

This PR breaks clients that are using java8 & TryHttpURLConnectionBackend:
java.lang.UnsupportedClassVersionError: sttp/client3/TryHttpURLConnectionBackend$ has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0.
if you're going this path, pls remove TryHttpURLConnectionBackend completely; otherwise I'd recommend to publish java8 & java11 separately (although for *.core it will be hard to maintain 2 stacks)

Since 3.6.0 we have fully switched to Java 11 in sttp.
If you want to be up to date then I recommend changing to Java 11 as well.
If you cannot then use 3.5.2 as it is the last version which does not require Java 11.

authors: Pask423 adamw eugeniyk

repo: softwaremill/sttp


text:
Add files via upload

Edited to remove CSV reader error (Windows)

Hi @sammiebuzzard, I can't check the diff because it's too big, and also don't have a Win machine to test. Should I just merge?

Hi again @sammiebuzzard,
After diffing locally it seems that your PR mainly fixes char encoding by doing
with open(CORD19_CSVFILE, newline='',encoding='Latin1') as csvfile:

Is that correct?
If the issue using the notebook on Windows persists, I suggest to create a new PR based on the current state of main, as this PR has fallen behind quite a bit now.
What do you think?

Sorry I missed this yesterday @sdruskat, the char encoding was the one remaining problem I found for Windows machines, (the other issues I had were local dependencies so nothing to fix there). Would be useful to have in if it doesn't break anything elsewhere- which I don't expect it should- so I'll submit a new PR for the latest version.

authors: sammiebuzzard sdruskat

repo: softwaresaved/habeas-corpus


text:
Information Required from Rob

[ ] Color scheme
[ ] Sign up for GitHub
[ ] Invite to collaborate on this Repo
[ ] About Me text
[ ] Ask for Contact details for the site (email, phone)

Change colour scheme to grey - 77919D

authors: katpas sohilpandya

repo: sohilpandya/Bidlt


text:
update Dekadus Token

feature request - edit Dekadus Token logo-url
can you please check my PR with updated logo-url update Dekadus Token #8585.
Thanks JayPi

merged

repo: solana-labs/token-list


text:
Brunch Bytes Token

Please note: This repository is being rebuilt to accept the new volume of token additions and modifications. PR merges will be delayed.

I agree to not ping anybody on Discord/Twitter/email about this pull request. Instead I will inquire by posting a new comment in the pull request if needed.

PRs are reviewed in bulk and and can take up to two weeks to be merged.
This repository is managed using an auto merge action. Please ensure your PR has no deleted lines, and it will be merged.
Please provide the following information for your token.
Please include change to the src/tokens/solana.tokenlist.json file in the PR.
DON'T modify any other token on the list.
At minimum each entry should have

Token Address:
Token Name:
Token Symbol:
Logo: (logo should be uploaded under assets/mainnet//*.<png/svg>)
Link to the official homepage of token:
Coingecko ID if available (https://www.coingecko.com/api/documentations/v3#/coins/get_coins__id_):

Auto merge requirements
Your pull request will be automatically merged if the following conditions are met:

Your pull request only adds new tokens to the list. Any modification to existing
tokens will require manual review to prevent unwanted modifications.

Your pull request does not touch unrelated code. In particular, reformatting changes to unrelated
code will cause the auto merge to reject your PR.

Any asset files added correspond to the token address you are adding. Asset files
must be PNG, JPG or SVG files.

Your change is valid JSON and conforms to the schema. If your change failed validation,
read the error message carefully and update your PR accordingly.

No other tokens shares the same name, symbol or address.

For example, this change would be rejected due to unrelated changes:

The bot runs every 60 minutes and bulk-merges all open pull requests to prevent conflicts.
This means that you need to wait up to 60 minutes for your pull request to be merged or reprocessed.

I can help stop wasting your time refer this: #13481

Haha thanks, I'll figure it out.

authors: akeslo zakimzf


text:
Update solana.tokenlist.json ADD SOLBERRY

I agree to not ping anybody on Discord/Twitter/email about this pull request. Instead I will inquire by posting a new comment in the pull request if needed.

PRs are reviewed in bulk and and can take up to two weeks to be merged.
Please provide the following information for your token.
Please include change to the src/tokens/solana.tokenlist.json file in the PR.
DON'T modify any other token on the list.
At minimum each entry should have

Token Address:
Token Name:
Token Symbol:
Logo: (logo should be uploaded under assets/mainnet//*.<png/svg>)
Link to the official homepage of token:
Coingecko ID if available (https://www.coingecko.com/api/documentations/v3#/coins/get_coins__id_):

@bartosz-lipinski sir please update token  information fast


text:
update RGT logo

I want this to manually update. @keone plase kindly consider this request.

https://github.com/solana-labs/token-list/commit/c38157bb93cd411ed633686ea783f0d0cecaf66f

authors: andbandu keone


text:
Support storage quota

In relation to #240, #241, #249 and #253, we'd like to take a first step in supporting storage quota.
Immediate hurdles seem to be the efficient calculation of storage size for

new or updated documents (loading in memory loses streaming; possibly solved with reversable transactions);
currently stored containers (can only be done recursively; possibly solved with caching in store or metadata).

Some related questions/remarks:

Would we consider a transaction mechanism, or is the loss of streaming on write acceptable (given that most request will read)?
Would it impact anything whether we implement this before authentication (in a http handler) or after (in a resource store or data accessor)?
What about updates (PATCH)?

For inspiration: the NSS keeps a solid:storageUsage per solid:Account, calculated with get-folder-size, and compares it with a solid:storageQuota setting to prevent writes (POST/PUT/PATCH) from happening when the used space is higher than the quotum. This seems like a good base to start from, even if such quota are not strict (i.e. the last write operation can surpass it). It does not need to calculate the size of incoming data, works for PATCH requests as well, and is easy enough to implement.
Important question that remain are:

Where to keep track of the allowed/used space of a pod/container? We could do this in the corresponding meta file, if we are positive on not writing to it directly, or alternatively in a store that keeps track of this information per pod/container.
Where to perform the comparison/prevention: http handler, resource store or data accessor? I have a slight preference for the last one.

So, unless there are specific issues with this scope, the architecture proposed above addresses it the following way:

Provide abstraction to easily extend the quota system: We make a a single class to plug in strategies, which we interface as QuotaStrategy. We name the class QuotedDataAccessor, wrapping DataAccessor, since this seems to be the appropriate level for checking write operations.

Configure the quota size in bytes per pod in components.js: This is a first strategy, which just needs the quota as a constructor parameter. In the diagram, it is the globalSize number of the GlobalSizeQuotaStrategy, but we can perfectly make this a sizePerPod number in a SizePerPodQuotaStrategy.

Start with only support for file-based servers, with enough abstraction to easily add other backends, and provide abstraction for easy addition of a caching mechanism: Backend support will depend at least on [A] the way the current storage-use is calculated, and [B] the way the incoming storage-addition is calculated. In the diagram, [A] is abstracted from separately as a SizeReporter, while [B] is seen as part of the QuotaStrategy. This is mainly because of the existing architecural diagram of the CSS, which suggested such a structure to allow for caching. Of course, nothing prevents us form also abstracting [B] in a separate interface, should this be advantageous.

Enforce the quota (except for perhaps a couple of concurrency cases): As explained under the diagram, I propose to let the QuotedDataAccessor pass the incoming data stream to the limitStream method of the QuotaStrategy in order to place a limit within the stream. This prevents to much of the stream being written before detecting a quota violation. Other suggestions are welcome, of course.

Preventing corruption / maintain atomicity: As explained under the diagram, I propose to first write the limited data stream to a temporary location, and only move it to the requested location when the full stream is successfully written.

Make the quota (in bytes) easily accessible: Since not only the quota mechanis, but also possibly later other (admin) mechanisms need to access the quota, we should probably have a standard way of checking them. While not in the diagram, this could maybe be achieved by having the QuotaStrategy provide an extra method which can indicated the quota limiting a given resource.

Thanks for the very helpful comments, @RubenVerborgh!
Abstracting a bit further to a ValidatingAccessor with a Validator having a validateRepresentation(id, data, metadata), of which the QuotaValidator is an implementation, definitely seems like a good idea. I do have some questions about the rest of your suggestions.

Before reading the incoming stream: how mush space is left? And is that enough space for the advertised data size?

What would you take as 'advertised size'?

Could we refactor GlobalSizeQuotaStrategy to not be an implementation of QuotaStrategy, but rather a SizeReporter with a slightly different interface [for example] getAvailableSpace(container)/estimateSize(metadata) and/or trackAvailableSpace(container, representation).

The way I see it there are different roles:

Calculating the size of currently stored resources (depends on the backend but not on the idea of quota)
Providing the size limit of a resource (depends on the idea of quota but not on the backend)
Comparing the two (depends on the idea of quota and the result of 1 and 2)
Deciding what to do based on the comparison (depends on the idea of quota and the result of 3)

The SizeReporter is i.m.o. much more reusable if we keep it limited to 1. The other roles, while separable, were initially part of the QuotaStrategy. We could keep it that way, and pass the QuotaValidator a QuotaStrategy taking a SizeReporter, or just have multiple QuotaValidators (each with a diferent strategy) taking a SizeReporter. Optionally, we could indeed separate the provisioning of limits to a separate LimitReporter class.

limitStream might not need to return anything; it could just make the stream error when it exceeds the quota.

That might in deed be possible. Would you do that by just adding a listener to the stream and destroying it with an error if the quota are exceeded?

I would want to see a more explicit mechanism for the atomicity using temporary storage.

Yes, definitely. So I think there are three feasible options we've mentioned up till now, not sure which one we'd prefer:

Avoid the need of a temp mechanism, by making the write operations of existing DataAccessors atomic, possibly indicated by implementing an extra (empty) conceptual interface AtomicDataAccessor.

Provide an atomic moveResource(sourceId, targetId) method on the DataAccessor level, and use it in the ValidatingAccessor, which is either responsible for minting temp URIs itself or depends on another DataAccessor method getTemporaryIdentifier() (not sure why this would need a container parameter). I don't think both methods should belong to the same interface, so if we don't want to change the existing DataAccessor, I'd propose two separate ones (MoveableDataAccessor and TempIdProvider for example). Both are then dependencies of the ValidatingAccessor (not of the QuotaValidator, I think).

Pass the ValidatingAccessor two DataAccessors, one for the main storage and one for temporary storage. The ValidatingAccessor then first tries to write the resource to the temporary one, and on success writes it to the main one and deletes it from the temporary one. From the view of the main storage only, this is a single atomic write operation.

We'll start implementing on some assumptions, and fill in or change the details if someone has a strong preference/answer for the above points.

What would you take as 'advertised size'?

As indicated in the Content-Length header (although this is only bytes, and can be incorrect).

The SizeReporter is i.m.o. much more reusable if we keep it limited to 1.

Yeah, but something needs to (preferably incrementally) calculate the size of the incoming representation.
So that's why I would tie 1/2/3 together into a quota strategy, as they are all either counting bytes or triples (or whatever).

That might in deed be possible. Would you do that by just adding a listener to the stream and destroying it with an error if the quota are exceeded?

Yeah, think so. I don't think we need to pipe for that.
But maybe that's just an implementation detail, and this method should return (it might just return the same stream).

So I think there are three feasible options

Option 2 for me, but with different details (see my suggestion).

Option 2 for me, but with different details (see my suggestion).

@RubenVerborgh, your suggestion read more like a stream of multiple thoughts, so which one do you mean exactly? And what would be the rationale to opt for such a solution rather than the first or third option I proposed (in fact, your suggestions seems to evolve from the one to the other)?
Since quota do not need temporary storage as such, I would prefer not to get sidetracked too much into that specific solution for what is in fact just a need for atomicity. I'd therefore prefer starting from an AtomicDataAccessor interface in this quota epic, and keep abstract implementations of it (like one using temporary storage and swapping) out of scope for now.

Updated architecture proposal:

Since we switched from a global to a per pod implementation I am having issues trying to calculate the size of a person's pod.
In the EqualPodQuotaStrategy I should be able to return getAvailalbleSpace() when only given the identifier of the resource that will be written.
Is there we way to calculate the identifier of a pod's root folder given you only have the indentifier mentioned above?

According to the diagram posted by @woutermont I should Checks advertised size (content-length header, zero if unavailable) in QuotaValidator. However I am not sure how to retrieve that only being given the metadata: RepresentationMetadata.
I couldn't find a field that contained the desired content-length.
Any ideas on how I would get this data ?

I don't get the need for the AtomicDataAccessor here or what it exactly means. For reference, we also have an AtomicResourceStore interface that probably had a similar goal but is never used and every time I see it I keep thinking I should probably just remove it.
It depends a bit on your interpretation of "atomic", but afaik an atomic function/operation is one that can safely be called in a multithreaded (or similar as we have here) environment without having to worry about doing any kind of locking. Using that definition none of our current DataAcessors are atomic. Calling writeData twice on the same identifier without waiting for the promise to resolve will cause unexpected behaviour. This is why we have the LockingResourceStore to prevent these issues. So if you want an AtomicDataAccessor you would need an internal locking mechanism there which would greatly complicate the solution.
Now this might just be me having a different interpretation of "atomic" here. I do get the idea of wanting to replace a resource without corrupting it on error but I wonder if atomic is the correct word for that.
For the comments from @BelgianNoise:

Is there we way to calculate the identifier of a pod's root folder given you only have the indentifier mentioned above?

The only safe way I can think of would be to have the strategy have access to the list of all pods. Unfortunately there is currently no easy way to do that. #938 already did some attempts to make that metadata more easily accessible, but that would not be sufficient in this case since it only allows finding the pod base url if you have the WebID of the owner (and that PR is not going to merge soon since some rework is required). At this point I'm wondering if perhaps we want a component that adds the pod base url to incoming requests, or some other metadata that allows us to easily access knowledge about pods.
I don't think there is a quick and easy solution to this though, so perhaps that component has to way a bit until there is a better solution for it.

I couldn't find a field that contained the desired content-length.

You will need to create a new MetadataParser that reads the content-length header. Even better would be a generic MetadataParser that takes a header -> URI map as input and maps the given headers to the given metadata predicates. This could then be reused for the slug header parser.

I do get the idea of wanting to replace a resource without corrupting it on error but I wonder if atomic is the correct word for that.

Right, because that is indeed what I meant. This is, a.f.a.i.k., what is meant with 'atomicity' in the context of ACID transactions: such transactions are indivisible, i.e. either all changes are performed or none are. (Your interpretation would fall under the 'isolation' part of ACID.)
So, under that interpretation of 'atomicity', the quota epic should somehow have a guarantee that erroring data streams are not partially written. This could be specifically implemented in the ValidatingAccessor itself, e.g. with temporary resources as in earlier proposals, but since this class is actually not interested in how that atomicity is provided, I thought it better to leave it up to the wrapped accessors. Whether we end up writing multiple backend-specific AtomicDataAccessors, or a single wrapper that actually implements such a solution with temporary resource, is of no importance to the validation mechanism.

About detecting the pod: would it somehow be possible to traverse the parent container structure and detect something in the metadata of the pod root container?

About detecting the pod: would it somehow be possible to traverse the parent container structure and detect something in the metadata of the pod root container?

Also thought about that. You technically could go up the tree until you find pim:Storage metadata. But there's nothing stopping a user from marking another container also as storage so they could cheat the system like that.

I don't think there is a quick and easy solution to this though, so perhaps that component has to way a bit until there is a better solution for it.

@woutermont are you fine with just implementing a GlobalQuotastrategy for now as planned originally ?

About detecting the pod: would it somehow be possible to traverse the parent container structure and detect something in the metadata of the pod root container?

Also thought about that. You technically could go up the tree until you find pim:Storage metadata. But there's nothing stopping a user from marking another container also as storage so they could cheat the system like that.

Realized that we actually should be stopping a user from adding this metadata, so could potentially be a solution.

@joachimvh Is there already a way in which some other metadata is prevented from being added, or where would you propose we do that?

Not really since most metadata is prevented by simply not having a specific parser for it. This one is special in that it shares the same header/predicate as what is used to identify a resource as a container. We could have excluded it when we had a specific link type parser but now that it's generalized to a LinkRelParser it would be a bit ugly to hardcode that there. I'm thinking maybe extending the options for that class so we can (optionally) indicate a list of acceptable and/or unacceptable values for a relation. That way we can make sure rel=type is only used for indicating resource status.
It does complicate the situation a bit so also open for other suggestions. We could also wrap it in another class that removes the metadata again, but that seems a lot more cumbersome.

Done in #973, will be part of v3.0.0

authors: BelgianNoise RubenVerborgh joachimvh woutermont

repo: solid/community-server


text:
Handle parentless popups

Fixes #34

Coverage remained the same at 86.145% when pulling 41e445e4afdc4a0101a6404b84cac6a913dc50f5 on dan-f/popup-handle-no-parent into 8ae06cdbac316c791e8a4bba8f242f4ed80af94a on master.

Coverage remained the same at 86.145% when pulling 41e445e4afdc4a0101a6404b84cac6a913dc50f5 on dan-f/popup-handle-no-parent into 8ae06cdbac316c791e8a4bba8f242f4ed80af94a on master.

Coverage remained the same at 86.145% when pulling b67b6132bf3b7a8418f1cea7671854b93c5fef15 on dan-f/popup-handle-no-parent into 8ae06cdbac316c791e8a4bba8f242f4ed80af94a on master.

authors: coveralls dan-f

repo: solid/solid-auth-client


text:
Bugfix/remove jira links from initial revision

This PR handles historical items from the changelog where it concerns the fields "Epic Link" and "Parent" so that they are removed from the initial revision.
Unittests will fail until #559 is fixed :)
Fixes #563

Looks fine to me. @madkoo, @moerketh, what is the status on this PR? Ready to merge or does it need further changed?

Looks fine to me. @madkoo, @moerketh, what is the status on this PR? Ready to merge or does it need further changed?

@Alexander-Hjelm the unittests in this PR require the changelog history to be parsed in the correct order or they will fail. So this should wait for #580 to be merged.

authors: Alexander-Hjelm moerketh

repo: solidify/jira-azuredevops-migrator


text:
Question: Is there a store-like type of memo? If not, what's a better workaround?

Say there is a store named mousePosition which contains an adjusted version of the mouse location which gets updates on the mousemove event.
My goal is to create a memo which has a discrete version of the position such as the following:
function normaliseAxis(axis: number): number {
  return Math.ceil(axis / 100);
}

const normalisedPosition = createMemo(() => ({
  x: normaliseAxis(mousePosition.x),
  y: normaliseAxis(mousePosition.y)
}));

Here, the memo makes all of its downstream objects react on every mousemove event because the memo is an object whose reference gets recreated, similar to a signal.
Question 1
Is there a store-like version of a memo which automatically memoises each field of an object such that it won't make downstream objects react unless there is a change in a value?
Question 2
If there is no such structure as asked above, which of the following work-arounds would be a better choice and why?
Choice 1
const normalisedPositionX = createMemo(() => normaliseAxis(mousePosition.x));
const normalisedPositionY = createMemo(() => normaliseAxis(mousePosition.y));

Choice 2
const normalisedPosition = createMemo(
  (previousPosition) => {
    const newPosition = {
      x: normaliseAxis(mousePosition.x),
      y: normaliseAxis(mousePosition.y)
    };

    if (newPosition.x === previousPosition.x && newPosition.y === previousPosition.y)
      return previousPosition;

    return newPosition;
  },
  {x: 0, y: 0}
);

Here is a playground link illustrating the question: https://playground.solidjs.com/anonymous/a847c828-eab8-4ccb-a9af-789afdf45f18

Sorry posted it in the wrong repo.

repo: solidjs/solid-playground


text:
update to goober: ^2.1.7

fixes "Too much recursion" error: https://github.com/cristianbote/goober/issues/415
Semver should take care of this on update but I'm explicitly stating ^2.1.7 since the recursion issue might be a problem for people who recently upgraded to solid-styled-components: 0.27.4

Forced pushed to include "solid-js": "^1.3.3"

repo: solidjs/solid-styled-components


text:
Using  to Generate children of Component

I have a component that expects to receive a [children] array and interleaves them with other elements. In the parent, it sometimes makes sense to create the children with a <For each={children} />. The problem is that I'm getting a signal passed into the component now instead of an array of children. How do I handle that?
I tried
const children = typeof props.children === "function"
    ? props.children()
    : props.children

But this doesn't seem to be working.

Use Solid's children helper: https://github.com/solidjs/solid/blob/main/documentation/api.md#children
The problem is every time you access props.children you are recreating the children. If you wrap with children it will flatten out all nested reactivity and give you a signal you can work with.

authors: jcuenod ryansolid

repo: solidjs/solid


text:
perf: avoid unnecessary flat

Summary
splitProps calls Array.prototype.flat unnecessarily and this causes some delays when there are many keys.

How did you test this change?

var values = Array.from({ length: 100 }).map((v, i) => `value${i}`);
var tests = 1000;

// 24.216064453125 ms
function flat() {
  console.time("flat");
  for (let x = 1; x <= tests; ++x) new Set(values.flat());
  console.timeEnd("flat");
}

// 3.248046875 ms
function noflat() {
  console.time("noflat");
  for (let x = 1; x <= tests; ++x) new Set(values);
  console.timeEnd("noflat");
}

function benchmark() {
  flat();
  noflat();
}

benchmark();

To be fair I'd be shocked if the keys ever got over 12. I'm sure it is faster to access the index in any case and size add is minimal.

To be fair I'd be shocked if the keys ever got over 12. I'm sure it is faster to access the index in any case and size add is minimal.

In SUID there are 100 style properties, not counting those of the component itself, so almost all components are suffering a noticeable performance loss.
I'm rewriting the splitProps and mergeProps functions and the results are promising:
 ✓ test/component.bench.ts (14) 10175ms
   ✓ SplitProps bench (14) 10169ms
     name                              hz     min     max    mean     p75     p99    p995    p999     rme  samples
   · oldSplitProps(0, 15)      749,315.43  0.0011  0.6440  0.0013  0.0013  0.0025  0.0028  0.0056  ±0.73%   374658
   · oldSplitProps(5, 15)       79,454.92  0.0119  0.4475  0.0126  0.0122  0.0243  0.0272  0.0487  ±0.44%    39728
   · oldSplitProps(0, 100)     141,382.73  0.0060  0.6344  0.0071  0.0066  0.0131  0.0150  0.0546  ±0.85%    70692
   · oldSplitProps(0, 100)     150,166.61  0.0060  0.4528  0.0067  0.0065  0.0107  0.0127  0.0309  ±0.79%    75084
   · oldSplitProps(25, 100)     34,717.64  0.0266  0.5867  0.0288  0.0274  0.0543  0.0647  0.1569  ±0.62%    17359
   · oldSplitProps(50, 100)     19,133.93  0.0497  0.9156  0.0523  0.0508  0.0950  0.1050  0.3445  ±0.64%     9567
   · oldSplitProps(100, 25)     10,006.10  0.0951  0.5767  0.0999  0.0978  0.1806  0.2090  0.4054  ±0.56%     5004   slowest
   · newSplitProps(0, 15)    3,915,802.53  0.0002  0.4137  0.0003  0.0003  0.0005  0.0006  0.0009  ±1.03%  1957902   fastest
   · newSplitProps(5, 15)      161,671.67  0.0056  0.4263  0.0062  0.0059  0.0119  0.0134  0.0185  ±0.44%    80837
   · newSplitProps(0, 100)   3,230,220.71  0.0002  0.4634  0.0003  0.0003  0.0008  0.0009  0.0020  ±1.12%  1615111
   · newSplitProps(0, 100)   3,771,770.61  0.0002  0.4532  0.0003  0.0003  0.0006  0.0007  0.0014  ±1.14%  1885886
   · newSplitProps(25, 100)     98,431.00  0.0096  0.5372  0.0102  0.0098  0.0195  0.0205  0.0318  ±0.52%    49216
   · newSplitProps(50, 100)     44,437.02  0.0214  2.0083  0.0225  0.0218  0.0381  0.0440  0.0797  ±1.16%    22219
   · newSplitProps(100, 25)     22,471.33  0.0427  0.5490  0.0445  0.0434  0.0789  0.0902  0.1773  ±0.59%    11236

 BENCH  Summary

  newSplitProps(0, 15) - test/component.bench.ts > SplitProps bench
    1.04x faster than newSplitProps(0, 100)
    1.21x faster than newSplitProps(0, 100)
    5.23x faster than oldSplitProps(0, 15)
    24.22x faster than newSplitProps(5, 15)
    26.08x faster than oldSplitProps(0, 100)
    27.70x faster than oldSplitProps(0, 100)
    39.78x faster than newSplitProps(25, 100)
    49.28x faster than oldSplitProps(5, 15)
    88.12x faster than newSplitProps(50, 100)
    112.79x faster than oldSplitProps(25, 100)
    174.26x faster than newSplitProps(100, 25)
    204.65x faster than oldSplitProps(50, 100)
    391.34x faster than oldSplitProps(100, 25)

authors: juanrgm ryansolid


text:
Allow enable_venmo preference to have default Venmo behaviour

Before the developer only had two options of:

disable venmo, enable_venmo: false
enforce Venmo to be rendered, enable_venmo: true

These changes make so the preference has the option of "enabled",
"disabled" and "default", to allow more control over Venmo.
"default" will let PayPal to decide its availability, by not sending
Venmo as a value on "enable-funding" and "disable-funding" parameters.
More details:
https://developer.paypal.com/docs/business/javascript-sdk/javascript-sdk-configuration/#disable-funding
https://developer.paypal.com/docs/business/javascript-sdk/javascript-sdk-configuration/#enable-funding

Reviewed again! It looks good to me.

authors: DanielePalombo RyanofWoods


text:
🛑 zakazbiletov.kz is down

In 6a5b909, zakazbiletov.kz (https://zakazbiletov.kz/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: zakazbiletov.kz is back up in c1316d4 after 11 minutes.


text:
🛑 dauran.kz is down

In 68e43b6, dauran.kz (https://dauran.kz/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: dauran.kz is back up in 2f13d79 after 1 hour, 11 minutes.


text:
Module as a singleton

Using the def statement in module scope creates a self object in the module scope and makes the declared method a property on that object.
prop should behave in a similar fashion creating a property on the self with getters and setters just like in classes, supporting all the features a class property does.
By doing this, we have an uniform syntax that can be easier to reason about. We could simply say that a module is like a singleton, and that you can apply what you know about classes to modules, and vice versa.

The following would be a breaking change, so perhaps 2.0:
We could also say that anything on the self object is automatically exported (i.e., module.exports = self, or export default self), then we can say that var, let, const, class and similar declaration statements are used for declaring private members. In classes, var, let and const would create private variables. This could compile to an IIFE wrapping the constructor declaration that would be used to house the declared variables.
class Foo
    var bar = 1

compiles to:
var Foo = (function () {
   var bar = 1;
   return function Foo () {};
})();

With this, we would have mostly identical semantics for all kinds of declarations between modules and classes.

repo: somebee/imba


text:
BTG Balance incorrect

Always shows 0 even if some coins

It works for me. Can you provide steps to reproduce? Can you post an address that has BTG but the tool doesn't show it?


text:
Build libsai deb packages in github workflow

Needed step for exposing later as artifacts to consume by other pipelines

PR ready for review

repo: sonic-net/DASH


text:
Sorted files

Hey there
Have sorted codes into their respective programming languages folder

You can follow me on github

authors: sonumahajan swatkj


text:
Anki backend userstory10

all backend of US 10 ACCEPT freakin 409 test for POST mapping --> in progress

Looks good. Resolve the conflicts and its ready for merge :)

authors: OrestisBollano akkuebler


text:
Generate button still active when edit = false

In the field settings I've disabled editing (Editable field is set to false). When creating a new content type, the field is shown with a valid value. The field is gray instead of white, indicating the editable field is set properly. Still, the generate button is visible and actually creating a new value when clicked. This shouldn't be possible when edit = false.

Just installed 0.1.5 but the button's still there...

"dependencies": {
"@_sh/strapi-plugin-ckeditor": "^1.1.2",
"@strapi/plugin-i18n": "4.5.0",
"@strapi/plugin-users-permissions": "4.5.0",
"@strapi/provider-upload-cloudinary": "^4.5.0",
"@strapi/strapi": "4.11.0",
"better-sqlite3": "7.4.6",
"pg": "^8.9.0",
"strapi-plugin-populate-deep": "^1.1.2",
"strapi-plugin-website-preview": "^1.0.5",
"strapi-ulid": "^0.1.5"
},

A new version 0.1.6 has been released. It should be fine now.

Fixed, thank you!

authors: Jeffrey-IKUU soranoo

repo: soranoo/strapi-ulid


text:
String#undump

Adds undump to the String rbi file.
Motivation
undump
Test plan
NA

@DarkDimius ptal

Closing it as stale, please feel free to reopen.

authors: DarkDimius bigH

repo: sorbet/sorbet


text:
[Docs] Translate README.md to English

I can help with translation using Google Translate, and make it easier for everyone to use/contribute to this software, if you like.

Hi 👋, welcome to submit any PR.
However, it may only be possible to translate documents for now, because the current project code is not sorted out, I don't want to put out too ugly code.
Finally, sorry for taking so long to reply, we were on vacation last week. @Teraskull

authors: Teraskull soulteary

repo: soulteary/docker-flare


text:
Bind type fix

Parameterised types were not handled correctly in the bind method generation when we migrated from JavaWriter to JavaPoet.

Merging as discussed.

authors: glung jdamcd

repo: soundcloud/lightcycle


text:
movie card content fix

##483
Closes: #483
Description of Changes
Updated the movie card module to fix the bug.
Checklist:

[x] My code adheres to the established style guidelines of this project.
[x] I have conducted a self-review of my code.
[x] I have included comments in areas that may be difficult to understand.
[] I have made corresponding updates to the project documentation.
[x] My changes have not introduced any new warnings.

Screenshots

Original
Updated

Please provide any necessary screenshots to illustrate the changes made.

@sourabhsikarwar I have reviewed this PR and noticed that this is not the required solution.

@sourabhsikarwar I have reviewed this PR and noticed that this is not the required solution.

But on card it shows 2 times movie name as well as rating that why card looks bad .

Merge Conflicts @BhartiNagpure

@sourabhsikarwar  merge conflict review it.

Hey, Deployment build getting failed due to some error in it. @BhartiNagpure

@sourabhsikarwar can you please send me error msg because I'm not getting the error in vercel.

repo: sourabhsikarwar/Scene-Movie-Platform


text:
fix(cli): github action failing in microservice scaffold - backstage

github action failing in microservice scaffold - backstage
Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes #1905
Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Intermediate change (work in progress)

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[ ] Test A
[ ] Test B

Checklist:

[ ] Performed a self-review of my own code
[ ] npm test passes on your machine
[ ] New tests added or existing tests modified to cover all changes
[ ] Code conforms with the style guide
[ ] API Documentation in code was updated
[ ] Any dependent changes have been merged and published in downstream modules

@Tyagi-Sunny rebase and test

authors: Tyagi-Sunny yeshamavani


text:
plg: display errors when autocomplete rate limits trigger

Closes #2134
This bug has 2 parts to it:

Using the rate limited demo accounts, by design the headers retry-after return back the same time as when the request was made. This causes the error messages to constantly be displayed in the quick pick view
Also using the rate limited demo account, if you hard code the retry time to a later time (like 1 day after), the error message does not display anymore after being dismissed once.

This PR adds a check to see whether or not the errors have been added in the statusBar and to display the rate limited error if no other RateLimitError is present. This also makes sure the error is only displayed once, instead of spamming the user if autocomplete keeps getting triggered.
Before (bug 1):
https://github.com/sourcegraph/cody/assets/51868853/de5a963a-a5be-4677-a75c-4f154960a516
Before (bug2, after hardcoding a later retry-after date):
https://github.com/sourcegraph/cody/assets/51868853/ffcd7748-0827-4fca-b71f-e141112ead97
After:
https://github.com/sourcegraph/cody/assets/51868853/48078429-59dc-4ad8-a744-efb1e665a689
Test plan

login to https://sourcegraph.com using the free demo account (thread)
go to any file, trigger autocompletes multiple times and you will see only 1 error message displayed
click on the error, dismiss it, and trigger another autocomplete. you should see another error message displayed

I think something with the rate limited test account might be incorrect as it says "limit will reset in less than a minute". This isn't how our rate limiter works AFAIK?

There is clearly something I misunderstand about this header 😆  Should we remove the text that depends on the retry-after value?

Getting some clarity here: https://sourcegraph.slack.com/archives/C05AGQYD528/p1701859689434749

@kalanchan pushed some tweaks (https://github.com/sourcegraph/cody/pull/2135/commits/363a716c402be4f04a49eaabb175bc7a0d2bdf5c), think this is good to merge?

@philipp-spiess @DanTup THANKS ALL for reviewing and helping, feels good to be contributing back to the team 💪

authors: DanTup kalanchan philipp-spiess

repo: sourcegraph/cody


text:
Revert "chore: upgrade to biome@1.7.2 (#3989)"

This reverts commit 8257f64b3599db169214129a3477ee626ac64258.
We found that it causes biome to crash causing issues in the VS Code extension (and likely some files won't be linted the way we expected it to because of the crash):
pnpm biome

> @sourcegraph/cody@ biome /Users/philipp/dev/cody
> biome check --apply --error-on-warnings .

Biome encountered an unexpected error

This is a bug in Biome, not an error in your code, and we would appreciate it if you could report it to https://github.com/biomejs/biome/issues/ along with the following information to help us fixing the issue:

Source Location: crates/biome_js_semantic/src/semantic_model/scope.rs:115:33
Thread Name: biome::worker_9
Message: no entry found for key

Biome encountered an unexpected error

This is a bug in Biome, not an error in your code, and we would appreciate it if you could report it to https://github.com/biomejs/biome/issues/ along with the following information to help us fixing the issue:

Source Location: crates/biome_js_semantic/src/semantic_model/scope.rs:115:33
Thread Name: biome::worker_4
Message: no entry found for key

./vscode/src/configuration-keys.ts internalError/panic  INTERNAL  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✖ processing panicked: no entry found for key

  ⚠ This diagnostic was derived from an internal Biome error. Potential bug, please report it if necessary.

./lib/shared/src/models/types.ts internalError/panic  INTERNAL  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✖ processing panicked: no entry found for key

  ⚠ This diagnostic was derived from an internal Biome error. Potential bug, please report it if necessary.

Checked 739 files in 221ms. No fixes needed.

Test plan

pnpm biome works again

https://github.com/biomejs/biome/issues/2659 for some context

Disabling noRedeclare works. Let me land this instead of the revert.


text:
Fix severity link

This text looks like it is supposed to link somewhere but does not. Where should this link?
@andreeleuterio or @dcomas please take ownership of this PR and merge a fix.

@nicksnyder I believe it was linking to the section below in the doc. This Incident Response doc seems due for a review, for example we have outdated severity levels. @bcreager do you know if this is in scope for the Operational Maturity work?

just looking for a quick fix now, thanks!

authors: andreeleuterio nicksnyder

repo: sourcegraph/handbook


text:
bug: Selecting LLM model is not avaliable

IDE Information
RustRover 2024.1.3
Build #RR-241.17011.175, built on June 22, 2024
Licensed to Dedalus HealthCare GmbH
Runtime version: 17.0.11+1-b1207.24 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Windows 11.0
GC: G1 Young Generation, G1 Old Generation
Memory: 2048M
Cores: 16
Registry:
debugger.attach.dialog.enabled=true
ide.experimental.ui=true
org.toml.json.schema=false
org.rust.lang.cfg.attributes=false
transferSettings.vscode.onlyCargoToml=true
llm.ai.assistant.toolwindow.activation.on.start=false
terminal.new.ui.show.promotion=false
Non-Bundled Plugins:
GLSL (1.24)
com.intellij.properties (241.14494.150)
de.docs_as_co.intellij.plugin.diagramsnet (0.2.5)
com.jetbrains.edu (2024.5-2024.1-1069)
org.asciidoctor.intellij.asciidoc (0.42.2)
com.intellij.ml.llm (241.17011.2)
com.sourcegraph.jetbrains (6.0.3)
mobi.hsz.idea.gitignore (4.5.3)
WGSL (0.0.31)
Bug Description
According to the docs, it should be possible to select the LLM model:
But for me, this field is not available:

Additional context
No response

closing this as this should be fixed

authors: haraldreingruber-dedalus kalanchan

repo: sourcegraph/jetbrains


text:
Only log CodyInstalled and CodyUninstalled events on installs/uninsta…

…lls. Log settings change events on server and access token changes
Fixes https://github.com/sourcegraph/jetbrains/issues/43
Test plan
Unfortunately I don't know how to test this and this is a quick, drive-by edit (and hopefully a low risk change). If you aren't comfortable merging as-is, let me know and I can try to set up a dev environment to test.

Look at you @dadlerj writing Kotlin 😁 The diff seems safe to merge wrt. not introducing regressions in the functionality of the plugin itself. I can't speak for whether this resolves the analytics issues, I'll leave it to @sourcegraph/jetbrains-plugin or @Strum355 (who has worked most on the telemetry stuff) to approve the PR.

authors: dadlerj olafurpg


text:
Imports of private custom Go import paths fail

If there is a Go package at a custom import path, and the grapher doesn't see the go-import meta tags there, then graphing fails. It should be more tolerant of this case.
Resolving Go dep: sourcegraph.com/sourcegraph/sourcecode
unable to fetch information about Go package "sourcegraph.com/sourcegraph/sourcecode":
go-import meta tag not found at https://sourcegraph.com/sourcegraph/sourcecode
exit status 1 EOF

Fixed by 047fb11d03fda19a8a30bc2f1c52fffd49c0c3b9

repo: sourcegraph/srclib-go


text:
Defect: new armflang exploratory code generates MPI "invalid communicator" error

Avg response time

Defect/Bug Report
The armflang branch now contains a very short demonstration program to emulate the invocation of co_sum in the file src/extensions/co_sum-transformed.F90 along with a stripped-down version of the opencoarrays module supporting our new collaboration with Arm engineer and WG5 member Nathan Sircombe.  This represents a first attempt to use OpenCoarrays with the armflang compiler installed at the University of Oregon.  A detailed transcript of the results are below.  The relevant files are

src/extensions/Makefile, which successfully compiles and links the file below,
src/extensions/co_sum-transformed.F90,
src/extensions/opencoarrays.F90, which is a stripped-down version of our like-named file,
src/mpi/caf_mpi.c, all of which get compiled via mpifortandmpiccwrappingarfmlangto produce an executable program namedco_sum-transformed`.

Guidance from @afanfa or @scrasmussen about recommended next steps would be greatly appreciated.
Steps to Reproduce
$ ssh nic.uoregon.edu
$ ssh cerberus
$ srun -p jetson --pty /bin/bash
$ export ARM_HPC_COMPILER_LICENSE_SEARCH_PATH=/packages/arm
$ module use /packages/arm/opt/arm/modulefiles
$ module load Generic-AArch64/Ubuntu/16.04/suites/arm-compiler-for-hpc_eval/18.2
$ module load openmpi/3.0.2_arm-18.2
$ git clone -b armflang https://github.com/sourceryinstitute/opencoarrays
$ cd opencoarrays/src/extensions
$ cat co_sum-transformed.F90

program main
  use iso_fortran_env, only : error_unit
  use iso_c_binding, only : c_int,c_double,c_loc,c_char
  use opencoarrays
  implicit none

  integer(c_int) :: i,me(1),argc=0
  character(kind=c_char) :: argv(1)

  call caf_init(c_loc(argc),c_loc(argv))

  ! Verify collective sum of integer data by tallying image numbers
  me=this_image()
  call co_sum(me)
  if ( any(me/=sum([(i,i=1,num_images())])) ) call error_stop

  ! Wait for every image to pass
  call sync_all
  if (this_image()==1) print *, "Test passed."

  call caf_finalize()
end program

$ make
$ mpirun -n 1 ./co_sum-transformed
[jetson01:4279] *** An error occurred in MPI_Comm_rank
[jetson01:4279] *** reported by process [74252289,545460846592]
[jetson01:4279] *** on communicator MPI_COMM_WORLD
[jetson01:4279] *** MPI_ERR_COMM: invalid communicator
[jetson01:4279] *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
[jetson01:4279] ***    and potentially your MPI job)
[warn] Epoll MOD(1) on fd 25 failed.  Old events were 6; read change was 0 (none); write change was 2 (del): Bad file descriptor
[warn] Epoll MOD(4) on fd 25 failed.  Old events were 6; read change was 2 (del); write change was 0 (none): Bad file descriptor

This has been fixed on the armflang branch.

@rouson should we disable CI for this branch? Or try to install flang/f18 instead of GFortran?

@zbeekman Yes, please feel free to disable CI for the armflang branch.  Installing flang is a bear of a process that I have yet to install.  AFAIK, the only option for installing flang via package management is the package manager spack, but that appears to be broken and NVIDIA confirmed that space support for building flang is problematic.  Building it from source is probably not an option given the Travis-CI 1-hr limit and doing so is also not trivial.
Also, the only thing that currently works with armflang is a "Hello, world!" example that uses only this_image(), num_images(), error stop, and sync all.  Nothing that involves communication works yet -- not even collective subroutines.

authors: rouson zbeekman

repo: sourceryinstitute/OpenCoarrays


text:
FIX issue 552

Avg response time
coverage on master

Summary of changes
Currents checks for memory reallocation is incorrectly triggered by a singleton on 1st dim when referencing a coarray (delta == 1) in a derived type.
@rouson @gutmann @zbeekman Steps to Reproduce mentioned in #552 passes with the .dat files given.
+ mpiexec -np 4 ./test-ideal
 Number of images =            4
           1 domain%initialize_from_file('input-parameters.txt')
 ximgs=           2 yimgs=           2
 call master_initialize(this)
 call this%variable%initialize(this%get_grid_dimensions(),variable_test_val)
  Layer height       Pressure        Temperature      Water Vapor
      [m]              [hPa]             [K]            [kg/kg]
   9750.00000       271.047180       206.509430       9.17085254E-06
   7750.00000       364.236786       224.725372       7.91714992E-05
   5750.00000       481.825287       243.449936       5.01311326E-04
   3750.00000       628.424316       262.669800       2.46796501E-03
   1750.00000       809.217651       282.372711       9.08217765E-03
 ThompMP: read qr_acr_qg.dat instead of computing
 qr_acr_qg initialized:  0.104000002
 ThompMP: read qr_acr_qs.dat instead of computing
 qr_acr_qs initialized:   6.89999983E-02
 ThompMP: read freezeH2O.dat instead of computing
 freezeH2O initialized:  0.500000000
 qi_aut_qs initialized:   1.40000004E-02

 Beginning simulation...
 Model run time:  61.352 seconds
<rest truncated ...>

Rationale for changes
Should fix #552
Added a regression test covering this patch.
Toolchain
gcc 8.1.0 + patches
mpich 3.2.1
caf 2.1.0 + patches
Additional info and certifications
This pull request (PR) is a:

[x] Bug fix
[ ] Feature addition
[ ] Other, Please describe:

I certify that

[x] I reviewed and followed the contributing guidelines, including
- Increasing test coverage for all feature-addition PRs
- Increasing test coverage for all bug-fix PRs for which there
does not already exist a related test that failed before the PR
- At least maintaining test coverage for all other PRs
- Ensuring that all tests pass when run locally
- Naming PR  to indicate work in progress (WIP) and to attach the PR
to the appropriate bug report or feature request issue
- White space (no trailing white space or white space errors may
be introduced)
- Commenting code where it is non-obvious and non-trivial
- Logically atomic, self consistent and coherent commits
- Commit message content
- Waiting 24 hours before self-approving the PR to give another
OpenCoarrays developer a chance to review my proposed code

This is great to see!

FYI, test failure was on GCC 6 branch, due to #347 / #266 / #161 Re-triggered the test to see if it will pass on the second attempt, since this bug is non-deterministic

LGTM
Thank you, oh so very much, @neok-m4700 🎉 🙇 🙏
Without contributors like you Open Source projects like OpenCoarrays would be doomed! Thanks again for this contribution and all your hard work! 💯

Thanks for fixing this longstanding issue, @neok-m4700 !

I finally had a chance to test this out.  While it does indeed fix the issue for 4 images, and is able to communicate with a remote image, for me this is still breaking with >64 images.  It works with 63 and 64, but breaks with 65 (and up).  I've tried a number of larger sizes up to 720 and nothing works above 64 :( I don't think this is an issue with coarray-icar code as that code base has run fine with gfortran 6.3 and cray fortran up to much larger numbers of images.
Can anyone else reproduce this?
r1i4n6:tests> mpiexec -np 65 ./test-ideal
Attaching 36339 to 685660.chadmin1

===================================================================================
=   BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
=   PID 36431 RUNNING AT r2i1n30.ib0.cheyenne.ucar.edu
=   EXIT CODE: 11
=   CLEANING UP REMAINING PROCESSES
=   YOU CAN IGNORE THE BELOW CLEANUP MESSAGES
===================================================================================
[proxy:0:0@r1i4n6] HYD_pmcd_pmip_control_cmd_cb (/glade/u/home/gutmann/scratch/opencoarrays/OpenCoarrays/prerequisites/downloads/mpich-3.2/src/pm/hydra/pm/pmiserv/pmip_cb.c:885): assert (!closed) failed
[proxy:0:0@r1i4n6] HYDT_dmxu_poll_wait_for_event (/glade/u/home/gutmann/scratch/opencoarrays/OpenCoarrays/prerequisites/downloads/mpich-3.2/src/pm/hydra/tools/demux/demux_poll.c:76): callback returned error status
[proxy:0:0@r1i4n6] main (/glade/u/home/gutmann/scratch/opencoarrays/OpenCoarrays/prerequisites/downloads/mpich-3.2/src/pm/hydra/pm/pmiserv/pmip.c:206): demux engine error waiting for event
[mpiexec@r1i4n6] HYDT_bscu_wait_for_completion (/glade/u/home/gutmann/scratch/opencoarrays/OpenCoarrays/prerequisites/downloads/mpich-3.2/src/pm/hydra/tools/bootstrap/utils/bscu_wait.c:76): one of the processes terminated badly; aborting
[mpiexec@r1i4n6] HYDT_bsci_wait_for_completion (/glade/u/home/gutmann/scratch/opencoarrays/OpenCoarrays/prerequisites/downloads/mpich-3.2/src/pm/hydra/tools/bootstrap/src/bsci_wait.c:23): launcher returned error waiting for completion
[mpiexec@r1i4n6] HYD_pmci_wait_for_completion (/glade/u/home/gutmann/scratch/opencoarrays/OpenCoarrays/prerequisites/downloads/mpich-3.2/src/pm/hydra/pm/pmiserv/pmiserv_pmci.c:218): launcher returned error waiting for completion
[mpiexec@r1i4n6] main (/glade/u/home/gutmann/scratch/opencoarrays/OpenCoarrays/prerequisites/downloads/mpich-3.2/src/pm/hydra/ui/mpich/mpiexec.c:344): process manager error waiting for completion

Also, I assume this is a new bug we have stumbled across, so I can open a new issue, but I thought I would drop this here for now in case it is related still.

@gutmann , I see some mpich-3.2 in your path.
Can you try with mpich 3.2.1 ?
see https://github.com/sourceryinstitute/OpenCoarrays/issues/496#issuecomment-364530879

@gutmann: I know we have experienced problems with Failed images in the past, because they rely on some very new MPI features (even features that are not part of MPI-3, that are proposed for MPI-4).
It would be great if you could open a new issue (if you haven't already done so) to track this.
I would recommend trying to compile OpenCoarrays with -DCAF_ENABLE_FAILED_IMAGES=FALSE
Also, as pointed out by @neok-m4700 there was a bug fix in MPICH that may not be in 3.2 but definitely seems to be in 3.2.1.

Uggg it seems like maybe someone left a debug statement somewhere. I have
never seen this before. Are you building a Release configuration of
OpenCoarrays?
On Mon, Jul 2, 2018 at 2:41 PM Ethan Gutmann notifications@github.com
wrote:

Thanks @neok-m4700 https://github.com/neok-m4700 @zbeekman
https://github.com/zbeekman, recompiling with mpich 3.2.1 fixed that
problem (at least it runs with 72 images now), but now it prints ,
dst_type = 3). repeatedly (it seems to be something like once for each
send... so with lots of images it gets to be a lot of output and it spends
all it's time printing to the screen so it runs much slower.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sourceryinstitute/OpenCoarrays/pull/555#issuecomment-401896724,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAREPAqfPOzNVwenuEM3L05r7r-czLvhks5uCmlQgaJpZM4U0ciL
.

I also found out that dst_type message is printed to stderr not stdout if that helps. I installed mpich 3.2.1 using the opencoarrays install script via ./install.sh -y -j4 -p mpich -I 3.2.1.  This is using gcc 8.1, also installed via the install script.
I think this is built as a "release" (at least that is what it prints when it is building, I didn't set anything for it.)

FWIW, in opencoarrays src/mpi/mpi_caf.c I see fprintf(stderr, ", dst_type = %d", dst_type);

git blame points to 250fb067864b1584836a0ad4e6076160937e809e (For whatever that is worth)

Thanks for digging. I'll investigate further once I have some time to take
a look. It's possible that it just needs a simple preprocessor conditional
wrapping or similar.
On Mon, Jul 2, 2018 at 3:49 PM Ethan Gutmann notifications@github.com
wrote:

git blame points to 250fb06
https://github.com/sourceryinstitute/OpenCoarrays/commit/250fb067864b1584836a0ad4e6076160937e809e
(For whatever that is worth)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sourceryinstitute/OpenCoarrays/pull/555#issuecomment-401913973,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAREPLBDRXQalWOWLvFjPtjiIEb-7o6gks5uCnkxgaJpZM4U0ciL
.

Also, just to add in response to:

It would be great if you could open a new issue (if you haven't already done so) to track this.

I think we should leave this discussion here for now as (I think) the relevant line was touched as part of this Pull Request, we can certainly move it elsewhere if you think that would be more useful.

@gutmann Sorry, yes this was part of the huge commit where we, changed a lot of stuff. I has been fixed in my branch https://github.com/neok-m4700/OpenCoarrays/tree/perf
especially this commit https://github.com/neok-m4700/OpenCoarrays/commit/c7399d6a0e934517ccdd1450d3cf90d1cb19d906
@zbeekman
Since this is a WIP on #556, there is no PR yet, I'm waiting updates in the comments ...

Thanks, I've just commented out those lines for now and it seems to be running fine.  You all are awesome!

authors: gutmann neok-m4700 rouson zbeekman


text:
Add SUSE support

Description
Override package manager resource for SUSE to make it possible to use the cookbook with such distro.
Issues Resolved
#209
Check List

[ ] All tests pass. See TESTING.md for details.
[x] New functionality includes testing.
[x] New functionality has been documented in the README if applicable.

Done. I also updated readme and metadata.rb to reflect changes.

@vzabawski we made some recent changes to this main branch of this cookbook, can you please rebase and push it back up?

Hi @ramereth. Any updates on this PR?

Released as: 9.1.0

authors: kitchen-porter ramereth vzabawski

repo: sous-chefs/chef-splunk