Accessibility VoiceOver issue: footer links text have surrounding whitespace

Description of the issue
There are links in the footer (screenshot attached), which have whitespace surrounding the text content.
If you use the VoiceOver screen reader with Google Chrome on MacOS. When you read the links, it also reads out the extra whitespace.
Steps to reproduce the issue
View issue in the Browser:
Referencing the screenshot attached below, viewing the source of the footer reveals the extra whitespace on the footer-links text.
VoiceOver reading issue in the Browser:

Go to the footer element.
Enable VoiceOver for screen reading.
Use ⌘+⌥+A to read out the content.
Let it read out the support links in the footer.

Actual vs Expected Behaviour
Expected Behaviour:
Whenever VoiceOver reads the footer-link text, it should only read the text.
Actual Behaviour:
Whenever VoiceOver reads the footer-link text, it reads out the text and whitespace.

Possible Solution
According to the Nunjucks documentation

Normally the template engine outputs everything outside of variable and tag blocks verbatim, with all the whitespace as it is in the file. Occasionally you don't want the extra whitespace, but you still want to format the template cleanly, which requires whitespace.

You can tell the engine to strip all leading or trailing whitespace by adding a minus sign (-) to the start or end block or a variable. This is applied in the screenshot attached below
Environment (where applicable)

Operating system: MacOS Ventura 13.5
Browser: Google Chrome
Browser version: Version 115.0.5790.114 (Official Build) (x86_64)
GOV.UK Frontend Version: 4.7.0

Screenshots

Hi @irfan-mehmood. Thanks for raising this issue. Sorry it's taken so long to respond.
Could you clarify the readout from VoiceOver when you get this issue? I wasn't able to replicate this in the environment specified. I did notice that VoiceOver announces the space around the visually hidden heading just before the list of links in the footer, which is intentional as per https://github.com/alphagov/govuk-frontend/pull/3836. I want to clarify you're not referring to this before we proceed.

I tested the design system page in Safari, Chrome and Firefox using Voice Over and couldn't reproduce this issue. It's possible that it's not longer present, as @irfan-mehmood's screenshot is showing that link as "accessibility", whereas it is now "accessibility statement" (so this content has had updates at some point).
Not to get sidetracked, but in testing, the spaces around the Support Links heading were announced in Safari and Chrome (still using Voice Over here - it announced "space, Support Links, level 1 space" ). I understand that this code change is intended to fix other issues noted in #3836, but the statement in that pull request is that "this is unlikely to block any users and the user numbers for MacOS VoiceOver are small compared to other assistive technologies".
Agreed with the first part, but do we have any evidence that suggests MacOS Voice Over users are comparatively small in number? If all we have to go on is the GOV.UK 2016 assistive technology survey or the WebAIM Screen Reader Survey, then that assertion might not hold up.


Changes the async approach to avoid critical sections

which was causing some crashes on application shutdown

:+1:


About High Load Servers

Hi,
We're testing new drivers in a small group of customers in a production environment.
The system working idea is simple:
Web Server < - > API Server < - > DB Server
There're thousands of requests are coming to API server every second, we're not directing all of them to SQL Server and using Redis as in-memory cache server in API server.
Redis has an option for re-using socket that used (pconnect) only using a couple of local ports of API Server. All servers sitting in the same datacenter with 10GBits network connections each. So we're not having any connectivity issues between servers. But sometimes we're getting "Communication link failure", and when it starts we get hundreds of them filling our log for lets say 10 to 15 seconds long.
We suspect TIME_WAIT states of local ports, may be we're going out of ports on API Server for different reasons. Yesterday we've some problems about it using curl, we fixed it (curl exhausts local ports with TIME_WAITS on web server). We can get detailed error explanation from curl like: "Address already in use" (means we exhaust all the local ports)
And the question:
Does the driver has some limitation like: only use port numbers betwen x and y at the local machines outgoing ports. Or can I get detailed information about communication link failures?
Windows Server 2012 R2 x64
IIS
PHP 7.1 x64 NTS
ODBC 13.1 x64
MSSQL PHP Driver 7.1 x64 NTS

@mlhkr What version of SQL Server are you using? I am not aware of any such limitations in the driver but we can look into it. Is there anyway you can share some sample schema and a repro script? Also check out this article while we investigate: https://support.microsoft.com/en-us/kb/942861

@meet-bhagdev,
Thanks for the link but actually I checked it before when we have this problem for the first time. But that does not help us. And I don't know if we can prepare a repro script about this because I can't say we're getting this when we do something. All I can say is all the different queries dropping at the same time when this problem starts:
[12-Dec-2016 20:59:32 Etc/GMT-3] PHP Fatal error:  Uncaught PDOException: SQLSTATE[08S01]: [Microsoft][ODBC Driver 13 for SQL Server]Communication link failure in C:\WWWROOT\API\some_script.php:29 Stack trace: #0 C:\WWWROOT\API\some_script.php(29): PDO->prepare('SELECT * FROM d...') #1 {main}   thrown in C:\WWWROOT\API\some_script.php on line 29
But we're also sure there's no communication problem between the servers at this time and there's no errors on windows event logs. So is there any code or something else which I can get more detailed error information from the driver? Like: "address already in use" or "link failure caused by....".
Thanks

I think I solve it... We've some deadlock problem with our DB but the solution is a little bit long and as a temporary solution we wrote a code which runs every 10 seconds to detect and kill the harmless select deadlocks. Now I check the deadlock times and communication link failure times... They all match.
Sorry for wrong issue raise and thanks again...

Hi All,
Reopening the thread because seems like problem is back again.
A Question:
Can a deadlock leads to "SQLSTATE[08S01]: [Microsoft][ODBC Driver 13 for SQL Server]Communication link failure" ? We check many things, API server free port, sql server 2016 ports, etc... But can't solve the issue.

Maybe this could help... we experienced something similar on rackspace cloud (virtual) servers. Looks like open stack have issues with virtualized NICs that hace TCP offloading enabled. Disabled offloading in both web server and db server and the issue went away.

Hi David,
They're Windows Server 2012 R2s and all chimneys disabled by default, I also recheck them to be sure

When we try to kill it with our "deadlock killer" job.
lets say we kill only 10 deadlocked pids but in our php logs we've tens of thousands of rows.
so here comes the question:
if a pooled connection dropped / killed by sql server, does this effects other connections made from that server to sql server (in case api server)?
That should be our problem because looks like it.

@mlhkr you can disable connection pooling by setting ConnectionPooling attribute in the connection string to false (or 0), see: https://docs.microsoft.com/en-us/sql/connect/php/connection-pooling-microsoft-drivers-for-php-for-sql-server

Closing due to inactivity. @mlhkr if you still have this issue, feel free to reopen it.


LUCENE-10333: Speed up BinaryDocValues with a batch reading on LongValues

See https://issues.apache.org/jira/browse/LUCENE-10333
PS: I'm pushing these codes to quickly see if this approach makes sense to you, I'll add some more tests if this can pass the the first round review :)

personally I'm not a fan of the api change on LongValues and the additional complexity in DirectReader just to read blocks of 2 values at a time.
I'd be more interested in a more general solution: e.g. a new docvaluesformat that compresses the values in blocks with FOR/PFOR, similar to the compression of the postings lists? It should be possible to do now that DocValues has forward-only next/advance api (again similar to Postings).

Thanks a lot for so quick feedback! Using FOR/PFOR sounds promising, i'll give it a try.

Might be easiest to prototype a new DocValuesFormat (I would fork the existing Lucene90 as a start)? That's how I would attack the problem. Then I'd try to remove (at least some) usages of stuff like DirectReader and instead use iterators that decompress FOR/PFOR blocks, much like the postings lists?
It's a heavy duty investigation / big task, as there are two cases (dense and sparse). For dense case if we want docid 500, we know how to get to its value (500 % BLOCKSIZE). For the sparse case, some docs may be missing: perhaps we also need skipdata, again like the postings does.

Thank you very much for your guidance! This is of great help to me. I will fork a new DocvalueFormat for this experiment.
Actually, what I thought at first was to only change the structure of addresses, implementing a new LongValues to replace the DirectReader or DirectMonotonicReader to read addresses, e.g. a ForUtilLongValues. When users try to get long through an index, It will use ForUtil to decompress the required block (of course, caching the block there and if the next call in the same block we can reuse it). Then it seems that I don't need to care about the skip data for sparse situations as IndexDISI will help me to get the index related to current docid. In this way, all i need to care is only the new implementation of LongValues. I wonder if this approach will make sense?
Thanks a lot for so quick feedback and your patience!

This seems like it is worth investigating! We just try to speed up the "addressing" without dealing with all the rest of docvalues (which may be much more complex change).

FYI @gsmiller and I looked into using a FOR-like encoding for doc values at https://issues.apache.org/jira/browse/LUCENE-10033. In short, this made queries that look at most docs like the Browse* faceting tasks much faster, but the queries that only look at a subset of the index like HighTermMonthSort much slower.
I like this change, it's a net win that is not only going to speed up binary doc values but also sorted set and sorted numeric doc values, which also use a direct monotonic reader to map doc IDs to value indexes? DirectMonotonicReader#binarySearch uses a similar idea to avoid doing the same operation over and over again. Let's update this pull request to limit the impact to the API to DirectMonotonicReader, since it's the only LongValues impl where we ever need to read two consecutive values at the same time?

@jpountz Thanks a lot for the suggestion!

Let's update this pull request to limit the impact to the API to DirectMonotonicReader, since it's the only LongValues impl where we ever need to read two consecutive values at the same time?

Actually, DirectMonotonicReader is not the only impl using this, line 176 in DirectMonotonicReader could call the DirectReader#get(index, twin) .
I tried to limit the change to DirectMonotonicReader, and the luceneUtil shows the QPS increasing (mentioned in jira) decreased from 20%+ to around 7%.

I like this change, it's a net win that is not only going to speed up binary doc values but also sorted set and sorted numeric doc values, which also use a direct monotonic reader to map doc IDs to value indexes? DirectMonotonicReader#binarySearch uses a similar idea to avoid doing the same operation over and over again. Let's update this pull request to limit the impact to the API to DirectMonotonicReader, since it's the only LongValues impl where we ever need to read two consecutive values at the same time?

I guess I see it as optimizing corner cases, which is why improvements aren't reflected in the current luceneutil benchmarks? But as I mentioned, my biggest concern is adding stuff to LongValues api for this, IMO it isn't justified. I also am not a fan of doubling the compression logic for every BPV. But I'm not personally going to block the change, just please help out on the LongValues api part, and I'd like to see some realistic use-cases where we have benchmarks that it speeds things up.

Hi @rmuir @jpountz , Thanks a lot for all talking about this! I think i probably find out a better way there:

Actually, what I thought at first was to only change the structure of addresses, implementing a new LongValues to replace the DirectReader or DirectMonotonicReader to read addresses, e.g. a ForUtilLongValues. When users try to get long through an index, It will use ForUtil to decompress the required block (of course, caching the block there and if the next call in the same block we can reuse it).

I implemented this idea and see a good benchmark result based on the newest luceneutil (wiki10m) without seeing any obvious slower tasks. I raised a new issue about this: https://issues.apache.org/jira/browse/LUCENE-10334
                            TaskQPS baseline      StdDevQPS my_modified_version      StdDev                Pct diff p-value
                   OrNotHighHigh      694.17      (8.2%)      685.83      (7.0%)   -1.2% ( -15% -   15%) 0.618
                         Respell       75.15      (2.7%)       74.32      (2.0%)   -1.1% (  -5% -    3%) 0.146
                         Prefix3      220.11      (5.1%)      217.78      (5.8%)   -1.1% ( -11% -   10%) 0.541
                        Wildcard      129.75      (3.7%)      128.63      (2.5%)   -0.9% (  -6% -    5%) 0.383
                     LowSpanNear       68.54      (2.1%)       68.00      (2.4%)   -0.8% (  -5% -    3%) 0.269
                    OrNotHighMed      732.90      (6.8%)      727.49      (5.3%)   -0.7% ( -12% -   12%) 0.703
     BrowseRandomLabelTaxoFacets    11879.03      (8.6%)    11799.33      (5.5%)   -0.7% ( -13% -   14%) 0.769
                HighSloppyPhrase        6.87      (2.9%)        6.83      (2.3%)   -0.6% (  -5% -    4%) 0.496
                    OrHighNotMed      827.54      (9.2%)      822.94      (8.0%)   -0.6% ( -16% -   18%) 0.838
                     MedSpanNear       18.92      (5.7%)       18.82      (5.6%)   -0.5% ( -11% -   11%) 0.759
          OrHighMedDayTaxoFacets       10.27      (4.0%)       10.21      (4.3%)   -0.5% (  -8% -    8%) 0.676
                        PKLookup      207.98      (4.0%)      206.85      (2.7%)   -0.5% (  -7% -    6%) 0.621
             LowIntervalsOrdered      159.17      (2.3%)      158.32      (2.2%)   -0.5% (  -4% -    3%) 0.445
                    HighSpanNear        6.32      (4.2%)        6.28      (4.1%)   -0.5% (  -8% -    8%) 0.691
             MedIntervalsOrdered       85.31      (3.2%)       84.88      (2.9%)   -0.5% (  -6% -    5%) 0.607
                        HighTerm     1170.55      (5.8%)     1164.79      (3.9%)   -0.5% (  -9% -    9%) 0.753
                 LowSloppyPhrase       14.54      (3.1%)       14.48      (2.9%)   -0.4% (  -6% -    5%) 0.651
                      HighPhrase      112.81      (4.4%)      112.39      (4.1%)   -0.4% (  -8% -    8%) 0.781
                    OrNotHighLow      858.02      (5.9%)      854.99      (4.8%)   -0.4% ( -10% -   10%) 0.835
            HighIntervalsOrdered       25.08      (2.8%)       25.00      (2.6%)   -0.3% (  -5% -    5%) 0.701
                       MedPhrase       27.20      (2.1%)       27.11      (2.9%)   -0.3% (  -5% -    4%) 0.689
            MedTermDayTaxoFacets       81.55      (2.3%)       81.35      (2.9%)   -0.3% (  -5% -    5%) 0.762
                          IntNRQ       63.36      (2.0%)       63.21      (2.5%)   -0.2% (  -4% -    4%) 0.740
                          Fuzzy2       73.24      (5.5%)       73.10      (6.2%)   -0.2% ( -11% -   12%) 0.916
         AndHighMedDayTaxoFacets       76.08      (3.5%)       75.98      (3.4%)   -0.1% (  -6% -    7%) 0.905
                     AndHighHigh       62.20      (2.0%)       62.18      (2.4%)   -0.0% (  -4% -    4%) 0.954
           BrowseMonthTaxoFacets    11993.48      (6.7%)    11989.53      (4.8%)   -0.0% ( -10% -   12%) 0.986
                    OrHighNotLow      732.82      (7.2%)      732.80      (6.2%)   -0.0% ( -12% -   14%) 0.999
                          Fuzzy1       46.43      (5.3%)       46.45      (6.0%)    0.0% ( -10% -   11%) 0.989
                         LowTerm     1608.25      (6.0%)     1608.84      (4.9%)    0.0% ( -10% -   11%) 0.983
                       OrHighMed       75.90      (2.3%)       75.93      (1.8%)    0.0% (  -3% -    4%) 0.939
                       LowPhrase      273.81      (2.9%)      274.04      (3.3%)    0.1% (  -5% -    6%) 0.932
                      AndHighLow      717.24      (6.1%)      718.17      (3.3%)    0.1% (  -8% -   10%) 0.933
        AndHighHighDayTaxoFacets       39.63      (2.5%)       39.69      (2.6%)    0.1% (  -4% -    5%) 0.862
                      OrHighHigh       34.63      (1.8%)       34.68      (2.0%)    0.1% (  -3% -    4%) 0.821
                 MedSloppyPhrase      158.80      (2.8%)      159.09      (2.6%)    0.2% (  -5% -    5%) 0.832
                       OrHighLow      257.77      (2.9%)      258.46      (4.6%)    0.3% (  -7% -    8%) 0.826
                      AndHighMed      133.43      (2.1%)      133.79      (2.7%)    0.3% (  -4% -    5%) 0.726
               HighTermMonthSort      145.28     (10.8%)      145.88     (11.2%)    0.4% ( -19% -   25%) 0.905
                   OrHighNotHigh      834.99      (6.1%)      839.62      (5.7%)    0.6% ( -10% -   13%) 0.766
                      TermDTSort       83.66      (9.6%)       84.30     (11.1%)    0.8% ( -18% -   23%) 0.817
       BrowseDayOfYearTaxoFacets    11639.59      (5.1%)    11777.38      (6.0%)    1.2% (  -9% -   12%) 0.502
                         MedTerm     1473.62      (7.4%)     1493.79      (6.4%)    1.4% ( -11% -   16%) 0.530
            HighTermTitleBDVSort      114.98     (16.7%)      117.30     (18.8%)    2.0% ( -28% -   45%) 0.720
           HighTermDayOfYearSort      128.29     (17.2%)      132.83     (22.6%)    3.5% ( -30% -   52%) 0.577
            BrowseDateTaxoFacets       19.25     (20.4%)       26.77      (3.7%)   39.1% (  12% -   79%) 0.000
     BrowseRandomLabelSSDVFacets       10.38      (3.5%)       18.03      (6.8%)   73.7% (  61% -   87%) 0.000
           BrowseMonthSSDVFacets       15.71      (3.6%)       34.59     (12.4%)  120.1% ( 100% -  141%) 0.000
       BrowseDayOfYearSSDVFacets       14.31      (3.3%)       33.54     (12.9%)  134.4% ( 114% -  155%) 0.000

Unfortunately I noticed that the sorted queries that didn't become slower only didn't become slower because the field was also indexed with points, so the short-circuiting logic we have to progressively add a filter that only matches competitive documents hid the slowdown. If I hack the benchmark code to not use this optimization then sorted queries are all about 40-50% slower.

Hi @jpountz , I saw these words in https://issues.apache.org/jira/browse/LUCENE-10033. I wonder if i also need to do some hack to see the slower tasks? Could you tell me the concret changes since i'm not very familiar with it, Thanks!
And here is my localrun script:
#!/usr/bin/env python

# Licensed to the Apache Software Foundation (ASF) under one or more
# contributor license agreements.  See the NOTICE file distributed with
# this work for additional information regarding copyright ownership.
# The ASF licenses this file to You under the Apache License, Version 2.0
# (the "License"); you may not use this file except in compliance with
# the License.  You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

import competition
import sys

# simple example that runs benchmark with WIKI_MEDIUM source and taks files
# Baseline here is ../lucene_baseline versus ../lucene_candidate
if __name__ == '__main__':
  sourceData = competition.sourceData()
  comp =  competition.Competition()

  facets = (('taxonomy:Date', 'Date'),('sortedset:Month', 'Month'),('sortedset:DayOfYear', 'DayOfYear'),('sortedset:RandomLabel', "RandomLabel"))
  index = comp.newIndex('lucene_baseline', sourceData, facets=facets, indexSort='dayOfYearNumericDV:long')
  candidate_index = comp.newIndex('lucene_candidate', sourceData, facets=facets, indexSort='dayOfYearNumericDV:long')

  #Warning -- Do not break the order of arguments
  #TODO -- Fix the following by using argparser
  if len(sys.argv) > 3 and sys.argv[3] == '-concurrentSearches':
    concurrentSearches = True
  else:
    concurrentSearches = False

  # create a competitor named baseline with sources in the ../trunk folder
  comp.competitor('baseline', 'lucene_baseline',
                  index = index, concurrentSearches = concurrentSearches)

  # use the same index here
  # create a competitor named my_modified_version with sources in the ../patch folder
  # note that we haven't specified an index here, luceneutil will automatically use the index from the base competitor for searching
  # while the codec that is used for running this competitor is taken from this competitor.
  comp.competitor('my_modified_version', 'lucene_candidate',
                  index = candidate_index, concurrentSearches = concurrentSearches)

  # start the benchmark - this can take long depending on your index and machines
  comp.benchmark("baseline_vs_patch")


Document has checks

Documents grammyjs/grammY#218

Is it ready for translation?

Apparently you forgot to put the tag on it to notify the translators. I saw that the ES and ZH documentation hasn't been updated yet.

They were notified internally.

Sorry for missing you out.

Santuy


[WIP][SPARK-18886][CORE] Make locality wait time be the time since a TSM's available slots were fully utilized

What changes were proposed in this pull request?
Currently the time window that locality wait times are measuring is the time since the last task launched for a TSM. The proposed change is to instead measure the time since this TSM's available slots were fully utilized.
The number of available slots for a TSM is determined by dividing all slots among the TSMs according to the scheduling policy (FIFO vs FAIR).
Why are the changes needed?

cluster can become heavily underutilized as described in SPARK-18886

How was this patch tested?
PoolSuite
TaskSchedulerImplSuite
TaskSetManagerSuite
Thoughts on this approach?
@viirya
@squito
@kayousterhout

Can one of the admins verify this patch?

Can one of the admins verify this patch?

ok to test

Test build #114755 has started for PR 26696 at commit 06ca01f.

Merged build finished. Test PASSed.

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

Sufficient discussions are needed for this problem. AFAIK, the issue of delay scheduling is: it has a timer per task set manager, and the timer gets reset as soon as there is one task from this task set manager gets scheduled on a preferred location.
A stage may keep waiting for locality and not leverage available nodes in the cluster, if its task duration is shorter than the locality wait time (3 seconds by default).
A simple solution is: we never reset the timer. When a stage has been waiting long enough for locality, this stage should not wait for locality anymore. However, this may hurt performance if the last task is scheduled to a non-preferred location, and a preferred location becomes available right after this task gets scheduled, and locality can bring 50x speed up.
I don't have a good idea now. cc @JoshRosen @tgravescs @vanzin @jiangxb1987

Test build #114755 has finished for PR 26696 at commit 06ca01f.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

retest this please

Test build #114760 has started for PR 26696 at commit 06ca01f.

Merged build finished. Test PASSed.

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

AFAIK, the issue of delay scheduling is: it has a timer per task set manager, and the timer gets reset as soon as there is one task from this task set manager gets scheduled on a preferred location.
A stage may keep waiting for locality and not leverage available nodes in the cluster, if its task duration is shorter than the locality wait time (3 seconds by default).

By adjusting the locality wait time, can't users make better trade off between locality and cluster utilization? In this case, users can set a smaller locality wait time.

@viirya The locality wait time is a global config, not per job/stage. Even if it's per job/stage, I'm not sure how to set an optimal value.

Test build #114760 has finished for PR 26696 at commit 06ca01f.

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

Merged build finished. Test PASSed.

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

Can you please expand on the description?  It sounds like you are saying you fill in all available slots no matter what locality and then reset the timer?  Which would essentially bypass the locality wait on all tasks in the first "round" of scheduling, which is not what we want.

, if its task duration is shorter than the locality wait time (3 seconds by default).

It doesn't have to be strictly shorter then wait time as long the harmonics of when tasks finish and get started is shorter then that. I've seen that happen before.

A simple solution is: we never reset the timer. When a stage has been waiting long enough for locality, this stage should not wait for locality anymore. However, this may hurt performance if the last task is scheduled to a non-preferred location, and a preferred location becomes available right after this task gets scheduled,

Your always going to have a race condition where if you wanted a bit longer you would have got locality, there is no way around that.  I don't think just waiting a flat timeout makes sense.  For instance, if I have 10,000 tasks you are saying you only wait 3 seconds (by default) and then all of them can be scheduled.  If you only have 10 executors (with 1 core), only 10 can run in parallel that doesn't even try to get locality on the 9,990 other tasks.
I've been thinking about options here and the one that seems the most straight forward to me is making it delay scheduling on a "slot".  Here a "slot" is a place you can put a task.  For example if I have 1 executor with 10 cores (default 1 cpu per task) then I have 10 slots.   When a slot becomes available you set a timer to be whatever the currently locality level is for that slot.  The reason to use slots and not entire executors is I could schedule 1 task on an executor with 10 slots and the other 9 would be wasted if you set the timer per executor.
When the timer goes off for that slot, you check to see if anything can be scheduled on it at that locality, if not you set the timer again to fall back to the next locality level (node -> rack).
This way you aren't wasting available resources.   If you really want your tasks to wait for locality just set the timeout on those higher.
Another option is per task, but I think that involves more tracking logic and will use more memory.
I think the per slot logic would work fine with the job scheduler scenario with the Fair scheduler as well.
The way spark does it now just seems broken to me, even in the job scheduler case. At some point you just want to run, if you don't again you can simply increase the timeout.  I'm going to go re-read the jira's to make sure I'm not missing anything though.  Note if someone is really worried about getting rid of existing logic we could keep it and have a config, but personally think we shouldn't.
thoughts?

The per-slot timer sounds promising to me. I'll think more about it in the following days.

so I re-read SPARK-18886 and really the solution mentioned by Kay was very similar - by using slots. In there she mentions it might be complicated to actually code up and use with the Fair scheduler, so the actual design/code changes will need to be investigated further to see how much change it actually requires, but that still seems like the best solution to me.

@tgravescs
Timers per slot will have issues when a stage finishes while slots are waiting. Then the next stage would ignore locality for those slots. It is more natural to think of the stages/tasks as having timers since they are the ones being starved, not the resources/slots.
The approach in this PR is similar to what Kay described. Only increase locality levels when your slots are not being utilized for some period of time.

yeah my approach changes it to be slot delay vs task delay, but it also depends on what we define as task delay, this approach is a lot less code change but need to think through the use cases more.

What were the particular critiques of this PR?
I suggest reading, particularly Kay's comments, SPARK-18886 as well as the comments in this old PR.
Below ideas I have seen (and some I tried) have the following issues:

Never reset timer: delay scheduling only works on first wave (as @tgravescs  pointed out)
Per slot timer: delay scheduling should apply per task/taskset (as I pointed out above) which might lead you to #3
Per slot per stage timer: tasks can be starved by being offered many different slots, each starting a new timer). also too much bookkeeping
Per task timer: you still need a way to distinguish between when a task is waiting for a slot to become available vs it has them available but is not utilizing them (which is what this PR does). To do this right seems to be this PR + more timers.

I'm not very familiar with the resource manager part. To confirm: the task scheduler keeps tracking all the available resources (executor id -> # of cores), and this information is provided by the cluster manager. Tash scheduler decides the # of slots for each TaskSetManager, and TaskSetManager uses this info to decide if it has utilized all its slots and reset the timer if necessary.
is my understand corrected?

Overall I think this is a good approach as far as doesn't require a lot of changes and from what I've thought about so far gets what we want.  I still need to look at the specifics of the fairscheduler more though as well.
So when to reset (or if you reset) is definitely still a question, arguably you should never reset back to a lower level. If the definition is a task delay then it should just be a delay from when it was submitted.  In your current implementation when it falls back is unpredictable.  If I happen to schedule on a node local and I'm full then fall back, but if I scheduled on node local and then at ANY, then it stays ANY.   You could take the other approach and always reset it back when you are fully utilized or set it back to whatever lowest was in that pass, but then you could end up always waiting the 3 seconds for non-node local again, which seems to go against the definition of the task delay.  It really feels like we should never reset it.
For a true per task timer the question still comes into play when do you start that timer, some people may say from when stage was submitted, some might say from when the task possibly could have run (which then you have to define that) because is that when there was enough slots, etc.

Note on the fairscheduler side - I think you do have the issue Kay brought up in v2 of comment: https://issues.apache.org/jira/browse/SPARK-18886?focusedCommentId=15931009&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15931009
But on one hand I would argue its not really an issue, or perhaps if its truly not being fair then just a bug, but I'm not super familiar with fairscheduler so need to spend some more time on it.  I also need to look at your logic for computing if its utilized or not when using fair scheduler.

I assume it fixes the performance on https://github.com/apache/spark/pull/26633? thanks for adding more unit tests, did run any manual tests as well?
Sorry haven't gotten back to this, hopefully later today or tomorrow will look more at fair scheduler

so looking at the fairscheduler side of this it brings me back to the real question of what is the definition of a task wait.  If you look at Kay's example:

This relates to your idea because of the following situation: suppose you have a cluster with 10 machines, the job has locality preferences for 5 of them (with ids 1, 2, 3, 4, 5), and fairness dictates that the job can only use 3 slots at a time (e.g., it's sharing equally with 2 other jobs). Suppose that for a long time, the job has been running tasks on slots 1, 2, and 3 (so local slots). At this point, the times for machines 6, 7, 8, 9, and 10 will have expired, because the job has been running for a while. But if the job is now offered a slot on one of those non-local machines (e.g., 6), the job hasn't been waiting long for non-local resources: until this point, it's been running it's full share of 3 slots at a time, and it's been doing so on machines that satisfy locality preferences. So, we shouldn't accept that slot on machine 6 – we should wait a bit to see if we can get a slot on 1, 2, 3, 4, or 5.

She is essentially saying that I want my task to wait a bit when a slot becomes available and a task could be scheduled on it.    This mostly comes into play when you have multiple tasksets of jobs being scheduled, if you only have a single job using fifo with one taskset it really doesn't matter.
If you have the case Kay mentions and the next time you get a slot offered to you is over the delay when the task set fell all the way back to ANY locality, it would immediately schedule on that and it wouldn't delay at all.  Now if you strictly go by the definition of how long a task waiting that would be fine, but if its from when it could have been scheduled that is to aggressive.

hi folks, thanks for leaving more comments.
I am currently on vacation until the 15th of Dec, so will likely not be able to respond.
Once I get back I'll address comments.

arguably you should never reset back to a lower level.

Yea I was thinking the same thing, but I decided not to touch that part yet, since I have mostly thought about when to reset.

Note on the fairscheduler side - I think you do have the issue Kay brought up in v2 of comment: https://issues.apache.org/jira/browse/SPARK-18886?focusedCommentId=15931009&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15931009

I do not believe this PR has that issue, as once the non-greedy taskset has waited its locality wait time it will increase locality level since it wasn't able to take advantage of its slots. Her proposed v1 solution had that problem since it only increased locality level if there were slots not being used by any job.

I assume it fixes the performance on #26633? thanks for adding more unit tests, did run any manual tests as well?

I haven't looked in depth at their problem, but it does seem it would solve most of the problem.
I have not yet had the chance to run manual tests.

so looking at the fairscheduler side of this it brings me back to the real question of what is the definition of a task wait. If you look at Kay's example:

I did not catch your point from the comment that started with above quote. This PR handles the case she mentioned since locality level would not increase because it is utilizing all its available slots (timers will keep getting reset). That means when the taskset is offered the new non-local resource, it wouldn't immediately take advantage of it

Test build #115003 has started for PR 26696 at commit 15d8353.

Merged build finished. Test PASSed.

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

Test build #115004 has started for PR 26696 at commit 624c417.

Merged build finished. Test PASSed.

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

Test build #115004 has finished for PR 26696 at commit 624c417.

This patch fails build dependency tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Test build #115003 has finished for PR 26696 at commit 15d8353.

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

Merged build finished. Test PASSed.

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

@squito would be interested in your opinion on when/if we reset the timeout.
If we never reset it, which is time from stage submit, that might not wait enough. If we leave it as is you could get a bit of unpredictability. (see my comment: https://github.com/apache/spark/pull/26696#issuecomment-561672267)
I don't think any approach we take will be perfect its just finding that balance between waiting to long and not enough.
This is something I need to think about some more as well.

The locality wait time is a global config, not per job/stage. Even if it's per job/stage, I'm not sure how to set an optimal value.

hmm, i think the locality wait time is still a global config here. Can it make easier to set an optimal value?

@squito
thanks a lot doing a thorough review of the tests.
I'll add more test cases and comments as suggested

I'm not sure yet about resetting the timer.  Just writing down some thoughts -- it would be better to reset the timer if either (a) more executors have been added with better locality (which is very common with dynamic allocation, especially during initial "warmup" phase of a job which reads a large input) or (b) another stage / job has finished, and so now you've got access to local resources which used to be "pinned" to the higher priority stage.
(a) feels like something we could address by only allowing resetting after TaskSetManager.computeValidLocalityLevels() changes the valid set.
(b) I'm not sure ... you could detect a change in the total number of running tasksets, but you really want to do it even before prior tasksets have totally finished, but still have the last wave running.
I'm also not sure we should necessarily reset the timer even in these cases.  eg. you might only add one local executor out of 1k, is it really worth resetting?  Its certainly easier to understand what's happening if you never reset.

back from vacation and updated the PR trying to address all the comments so far.
let me know if I left one of your comments out.

Merged build finished. Test PASSed.

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

Test build #115430 has started for PR 26696 at commit 168ab30.

Test build #115430 has finished for PR 26696 at commit 168ab30.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

retest this please

Test build #115508 has started for PR 26696 at commit 168ab30.

Merged build finished. Test PASSed.

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

Test build #115508 has finished for PR 26696 at commit 168ab30.

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

Merged build finished. Test PASSed.

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

Test build #115538 has started for PR 26696 at commit f9a85f9.

Merged build finished. Test PASSed.

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

Test build #115538 has finished for PR 26696 at commit f9a85f9.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

@bmarcott thanks for the update, I probably won't have time to review until the new year due to holidays

Here is an approach which avoids trying to simulate any type of scheduling logic.
This change resets locality timers only when no resources have been rejected due to delay scheduling.
The complication in this change is that resetting the locality timer is dependent on when TaskSchedulerImpl.resourceOffers is called with all resources, rather than a single resource.
That is guaranteed to happen only as frequent as spark.scheduler.revive.interval which defaults to 1s. This means there would be problems if locality.wait.time is smaller than the revive interval.
Ways around this would be to either make the revive interval at least as small as locality wait or to always offer all free resources on calls to TaskSchedulerImpl.resourceOffers. We could also restrict how low you could make locality wait timeout...
Thoughts or know of any other issues with this approach?

happy new year folks 🎉 🎈

offer 1 resource that was rejected - no timer reset
offer all resources with no rejects - timer is reset
offer 1 resource, no reject - timer is reset
offer 1 resource that was rejected - no timer reset
offer 1 resource, no reject - no timer reset because previous offer was rejected

There are 4 "offer 1 resource", typo?

thanks for the update and proposal. I think it would be useful to add in a high level description of what exactly the approach is trying to do.  You have how its trying to do it and an example but I think what its trying to do is as useful.
Please correct me if I'm wrong, but I think essentially at a high level you are proposing to only reset the timer whenever all the currently free resources are scheduled on.  So if you start out with 4 executors, you don't reset the timer until all of them have been scheduled. At that point you reset the timer. Which means that when a running task finishes and you go to start a new one or a new executor comes in, it has to wait the timeout.
And for the fair scheduler case, the way you are passing the flags in handles it resetting the timer if it has used its fair share?
Also just to clarifying a few things:

offer 1 resource, no reject - timer is reset
so the assumption here is that we are out of all resources because we either had 1 task finish or we added a new executor and if nothing was rejected we scheduled that fully and we were fully scheduled before this offer?     This is why you have the last line :  offer 1 resource, no reject - no timer reset because previous offer was rejected -> since previous offer was rejected there are still free resources so we don't reset.

One remaining case that isn't handled:
Before any "all free resource" offer, all free resources are offered one by one and all not rejected.
This case should reset the timer, but won't with current impl.

So I assume by this you mean the startup case, but I'm not sure that is true. You get an "all free resource" case when you first submitTasks.
I think there are 2 cases - static allocation and dynamic allocation. Generally with static you will get your executors before you start any application code, so it won't matter if it makes offers before that.  With dynamic allocation generally you won't have any executors so this perhaps is the case on submitTasks you offer all but there are no offers because no executors yet.  Which case are you referring to?

offer 1 resource that was rejected - no timer reset
offer all resources with no rejects - timer is reset
offer 1 resource, no reject - timer is reset
offer 1 resource that was rejected - no timer reset
offer 1 resource, no reject - no timer reset because previous offer was rejected

There are 4 "offer 1 resource", typo?

no. Did I make a mistake?

ah it's an event sequence. sorry I misread it.
I'd like to see the high-level description as well. What this PR does is pretty clear: if a TSM doesn't fully utilize its slots because of delay scheduling, fall back to the next locality level after "locality wait" time.
It's unclear to me how the new proposal implements it.

I think it would be useful to add in a high level description of what exactly the approach is trying to do

I agree. We should all have a good idea of what the goal is here.
I understand the high level goal to be to only let delay scheduling be delaying the taskset for the period determined by locality wait. Delaying in this case means not scheduling a task, when it would have, if were not for delay scheduling (indicated by the new boolean return by TSM). We know there has been no delay when there have been no rejects since and including an "all resource offer".
I am now refraining from using the term "all resources utilized, " since there are other reasons they may not be fully utilized, such as blacklisting, which would have caused problems with my previous approach.

Please correct me if I'm wrong, but I think essentially at a high level you are proposing to only reset the timer whenever all the currently free resources are scheduled on. So if you start out with 4 executors, you don't reset the timer until all of them have been scheduled. At that point you reset the timer.

It is not strictly required that all 4 executors be utilized. The new approach directly measures effects due to delay scheduling. As long as there are no rejects due to delay scheduling the timer is reset.

Which means that when a running task finishes and you go to start a new one or a new executor comes in, it has to wait the timeout.

The timer is per TSM, not per task, so a single task doesn't necessarily have to wait when another one completes. The same applies to executors.
As long as the TSM is not rejecting resource offers due to delay scheduling, the timer is reset.

And for the fair scheduler case, the way you are passing the flags in handles it resetting the timer if it has used its fair share?

New flags are not passed it. New flags are returned by the TSM saying whether it rejected an offer due to delay scheduling.
Fair or FIFO scheduling are handled the same way in the new approach. the scheduling determines what resources are offered to which TSMs, and the TSMs return whether they were "delayed."
I believe another interesting bug which exists in master code (timer reset on task launched), is that assume because of FAIR scheduling (or any other reason) a TSM cannot launch tasks for the locality wait period. currently that TSM would be penalized and would increase its locality level.
With the new approach I linked: there would be an all resource offer and that TSM would be offered 0 resources, but it also wouldn't reject any resources due to delay scheduling, so the timer would be reset.

Also just to clarifying a few things:

offer 1 resource, no reject - timer is reset

so the assumption here is that we are out of all resources because we either had 1 task finish or we added a new executor and if nothing was rejected we scheduled that fully and we were fully scheduled before this offer? This is why you have the last line : offer 1 resource, no reject - no timer reset because previous offer was rejected -> since previous offer was rejected there are still free resources so we don't reset.
Whatever assumptions or circumstances caused the case, the fact is that the TSM is not being delayed due to delay scheduling in that case, so the timer should be reset.

When an "all resource offer" has no rejects, we know there is no delay, so we can reset the timer.
For single offers, we only know there has been no delay if there hasn't been any delay since the last all resource offer.

So I assume by this you mean the startup case, but I'm not sure that is true. You get an "all free resource" case when you first submitTasks.
I think there are 2 cases - static allocation and dynamic allocation. Generally with static you will get your executors before you start any application code, so it won't matter if it makes offers before that. With dynamic allocation generally you won't have any executors so this perhaps is the case on submitTasks you offer all but there are no offers because no executors yet. Which case are you referring to?

No, I believe the approach doesn't matter whether executors are statically or dynamically allocated.
The case I am referring to is: imagine you have 2 resources and an "all resource offer" is scheduled every second. when TSM1 is submitted, it'll also get an "all resource offer", and assume it rejects both, causing a prexisting TSM2 to utilize them. Assume those 2 tasks finish, and the freed resources are offered one by one to TSM1, which accepts both, all within 1 second (before any "all resource offer"). This should reset the timer, but it won't in the implementation.

ah it's an event sequence. sorry I misread it.
Sorry if it wasn't clear. I relabeled it as an event sequence.

I'd like to see the high-level description as well. What this PR does is pretty clear: if a TSM doesn't fully utilize its slots because of delay scheduling, fall back to the next locality level after "locality wait" time.
It's unclear to me how the new proposal implements it.

Hopefully my description above cleared it up. But lemme know if I am missing something or if it needs more explanation.

Thanks for taking a look!

hope you had a good weekend. any new thoughts?

timers will be reset only if there were no resources rejected due to scheduling delay since the last offer which included all free resources.

Is this the key point? I'm not familiar with the resource offer part. When an offer is not "all resource", we never reset the timer?

Is this the key point?

yes

I'm not familiar with the resource offer part.

I listed all the different cases in which all resource offers and single resource offers are made in one of my comments above. Hope that helps.

When an offer is not "all resource", we never reset the timer?

You can reset the timer on a single resource offer if there have been no rejects since the last all resource offer.

sounds good, can you open a new PR for your new idea? then we can review and leave comments.

sorry my delay on this, I agree with @cloud-fan  can you open a new pr with the new method as it seems like a reasonable approach I just have to walk thru all the scenarios again.

@bmarcott  please close this


add instructions/scripts for running PostGIS in a Docker container

add instructions/scripts for running PostGIS in a Docker container

Thanks!


Nested effects and Dynamic effects not applied correctly？

When apply Nested effects or Dynamic effects on a creature, it will work when I use it from the convenient-effects UI, but it will not work when I use it from the same name feature.
ex：Cast Enlarge/Reduce spell will apllied to "Enlarge/Reduce effect”.

Is this with the midi integration?

Yes - when I tested it I was using the setting for Convenient Effects: 'Apply CE, if absent apply Item effects'. When I click the feature from the character sheet, it only applies the top level effect, but not the nested effects.

What version of midi do you have installed?

10.0.35 - Just updated yesterday hoping that would fix it

Fixed on my end in 4.2.0


The test "Test parallel usage of single client" is failing sometimes

Fixed in 0b84e16f03a6749874d97a4efa2754f2a319328a, turned out to just be a mistake in the test itself


Difference between revision and a version?

Hy!
I'm new to CQRS/ES architecture and I'm experimenting with my own implementation in node.
Usually in CQRS examples I saw, the word "version" refers to a number which increments every time an event is stored to ensure optimistic concurrency.
But since in this implementation there is both "version" and "revision", I suppose a "revision" is this number which increments every time an event is saved and a "version" refers to command and event "signature" (so it's incremented only when property is changed/added and similar).
Could you please confirm is my assumption correct or is it used differently?

You got it half right.
The "revision" refers to the aggregate and it is basically a number incremented with each event ( and appended to it ) to control concurrency and the right order of denormalization ( with help from revisonGuardStore if you use adrai/node-cqrs-eventdenormalizer ).
The "version" refers to the command and it allows you to have two versions of the same command, useful in a scenarios when you change the command expected payload ( ie. producing version 2 of the command ), but some components of your system dispatch older versions of the command.

Understood! :)
Thank you.


[bug] CoinbaseWalletSDK is not a constructor error on development env using vite

Is there an existing issue for this?

[X] I have searched the existing issues

Package Version
0.3.1
Current Behavior
Can't use CoinbaseWalletConnector with Vitejs on development.

Expected Behavior
It shouldn't give error on development env.
Steps To Reproduce
create a vite react-ts app. After that:
package.json:
{
  "name": "wagmitestvite",
  "private": true,
  "version": "0.0.0",
  "scripts": {
    "dev": "vite",
    "build": "tsc && vite build",
    "preview": "vite preview"
  },
  "dependencies": {
    "ethers": "^5.6.4",
    "lodash-es": "^4.17.21",
    "react": "^18.0.0",
    "react-dom": "^18.0.0",
    "util": "^0.12.4",
    "wagmi": "^0.3.1"
  },
  "devDependencies": {
    "@esbuild-plugins/node-globals-polyfill": "^0.1.1",
    "@types/react": "^18.0.0",
    "@types/react-dom": "^18.0.0",
    "@vitejs/plugin-react": "^1.3.0",
    "typescript": "^4.6.3",
    "vite": "^2.9.5"
  }
}

vite.config.ts:
import {defineConfig} from 'vite'
import react from '@vitejs/plugin-react'
import NodeGlobalsPolyfillPlugin from "@esbuild-plugins/node-globals-polyfill";

// https://vitejs.dev/config/
export default defineConfig({
    plugins: [react()],
    optimizeDeps: {
        esbuildOptions: {
            // Node.js global to browser globalThis
            define: {
                global: 'globalThis',
            },
            // Enable esbuild polyfill plugins
            plugins: [
                NodeGlobalsPolyfillPlugin({
                    buffer: true
                })
            ]
        }
    }
})

tsconfig.json:
{
  "compilerOptions": {
    "target": "ESNext",
    "useDefineForClassFields": true,
    "lib": ["DOM", "DOM.Iterable", "ESNext"],
    "allowJs": false,
    "skipLibCheck": false,
    "esModuleInterop": false,
    "allowSyntheticDefaultImports": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "module": "ESNext",
    "moduleResolution": "Node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": true,
    "jsx": "react"
  },
  "include": ["./src"]
}

main.tsx:
import React from 'react';
import ReactDOM from 'react-dom/client';
import './index.css';
import App from './App';
import {InjectedConnector} from 'wagmi/connectors/injected'
import {WalletConnectConnector} from 'wagmi/connectors/walletConnect'
import {CoinbaseWalletConnector} from 'wagmi/connectors/coinbaseWallet'
import {Chain, createClient as createWagmiClient, WagmiProvider} from 'wagmi';
import {getDefaultProvider, providers} from "ethers";

const chains = [
    {
        id: 56,
        name: 'Binance Smart Chain',
        nativeCurrency: {
            name: 'BNB',
            symbol: 'BNB',
            decimals: 18,
        },
        rpcUrls: {
            default: 'https://bsc-dataseed.binance.org',
            default2: "https://bsc-dataseed1.defibit.io/",
            default3: "https://bsc-dataseed1.ninicoin.io/"
        },
        blockExplorers: {
            etherscan: {
                name: 'BNB Smart Chain Explorer',
                url: 'https://bscscan.com'
            },
            default: {
                name: 'BNB Smart Chain Explorer',
                url: 'https://bscscan.com'
            }
        }
    }
]

export const coinbaseWalletConnector = ({chainId}: { chainId?: number | undefined }) => new CoinbaseWalletConnector({
    chains,
    options: {
        appName: "wagmi",
        chainId: chainId,
        jsonRpcUrl: "https://bsc-dataseed.binance.org"
    }
});

export const injectedConnector = new InjectedConnector({
    chains,
    options: {
        shimDisconnect: true
    }
});

export const walletConnectConnector = ({chainId}: { chainId?: number | undefined }) => new WalletConnectConnector({
    chains,
    options: {
        chainId,
        qrcode: true,
    },
})

const connectors = (config: { chainId?: number | undefined }) => {
    return [
        injectedConnector,
        coinbaseWalletConnector(config),
        walletConnectConnector(config)
    ]
}

const provider = ({chainId}: { chainId?: number | undefined }): any => {
    if (!chainId) return getDefaultProvider();
    const chain = chains.find((tempChain) => tempChain.id === chainId) as Chain;
    const providerUrl = chain.rpcUrls.default;

    const jsonRpcProvider = new providers.JsonRpcProvider(providerUrl, chainId);

    return jsonRpcProvider
}

const wagmiClient = createWagmiClient({
    autoConnect: true,
    connectors,
    provider
});

ReactDOM.createRoot(document.getElementById('root')!).render(
    <React.StrictMode>
        <WagmiProvider client={wagmiClient}>
            <App/>
        </WagmiProvider>
    </React.StrictMode>
)

App.tsx:
import React from 'react';
import './App.css';
import {useAccount, useBalance, useConnect} from "wagmi";

function Balance() {
    const {data: account, isError: isErrorAccount, isLoading: isErrorLoading} = useAccount()
    const {data: balance, isError: isErrorBalance, isLoading: isLoadingBalance} = useBalance({
        addressOrName: account?.address,
    })

    if (isErrorLoading) return
Loading account…

    if (isErrorAccount) return
Error loading account

    if (isLoadingBalance) return
Fetching balance…

    if (isErrorBalance) return
Error fetching balance

    return (

            Account: {account?.address}

            Balance: {balance?.formatted}

    )
}

function App() {
    const {connect, isConnected, connectors} = useConnect();

    return (

                {
                    connectors.map(connector => (
                        <button key={connector.id} onClick={() => connect(connector)}>{connector.name} CONNECT</button>
                    ))
                }
                {isConnected && <Balance/>}

    );
}

export default App;

Link to Minimal Reproducible Example (CodeSandbox, StackBlitz, etc.)
No response
Anything else?
It might happen because of using pnpm as package manager, idk

@tmm Official vite-react example has same issue too

I am having the same issue with web3-onboard

getting this with remix as well

@tmm hmm still getting the same error on wagmi 0.3.5.  Applied the patch in the example and it works now! Thank you so much

I see that it still doesn't work on vite-react example. I've updated the wagmi package version to 0.3.5 but still same error occures.

@tmm @jcheese1 @ilterugur
For some wired reason, vite is making a nested default export for Coinbase. Tried using yarn, pnpm and npm and all fail. So I would guess that Vite is failing.
If I try to import the module directly in my app there's not double default.

Left, import directly in app. Right, current module

Notice the property default repeated twice with the raw import without accessing default first. If I access the default property twice, the connector works.

@cesargdm good find! seems related to https://github.com/vitejs/vite/issues/7112


Fix/prepare for production

Mainly removed redundant env vars and prevented a couple of "Cannot read property * of undefined" errors

Don't worry. It is already the code running on the VM


Update for Babel 6

Refs: http://babeljs.io/blog/2015/10/29/6.0.0/

Hi @Naddiseo,
Do you intend to work on this soon, or do you need some help ?
/cc @veggiemonk

@oligot, I would happily accept a PR; I have some (work) time constraints at the moment that's causing me to neglect this plugin.

@Naddiseo Sorry to hear about your time constraints, I hope it goes well for you. I am sure it is not too difficult to make the change. Plus, there are already a lot of plugins out there like this one.
@oligot Are you on to this? :smile: :v:

I'll start to work on it (I first need to understand how babel plugins work).

@oligot, I have some time today, so I'm going to give this a stab; I wanted to add some tests too.

@oligot, it's going to take some time to finish this. The plugin structure is quite different from babel 5, and I can't find any other (upgraded) plugins for reference; everyone else seems to be having the same issues that I'm running into.

@oligot, @veggiemonk I've pushed an experimental branch on https://github.com/Naddiseo/babel-plugin-mjsx/tree/babel6 which seems to work. Would you be able to do some limited testing of it and let me know if there any problems?

@Naddiseo woaw cool, thanks a lot. Will be testing it today.

I will also test it today.

@Naddiseo this looks great.
When do you expect to merge this with the main branch?

@sebastiansandqvist, my plan was to wait until I can run it across my code base at work, but I also want to wait until babel 6 is more stable before upgrading. This babel 6 version of the plugin has also changed slightly in how it emits white-space, so more feedback from people about any effects of that would be helpful.

A bit late, but still useful:
https://github.com/thejameskyle/babel-plugin-handbook
A guide on how to create Babel plugins

Created a release. Let me know if you have any problems.

By any chance, could you recommend a way to test this with jspm?

I have never used jspm before. I would assume that you could add plugins to a .babelrc file, and tell jspm to use babel in some way. Sorry I can't be of more help.


solves #14

@MathieuAA I've removed the blueprint option for vuejs as I assumed we don't need it anymore or am I wrong?

@MathieuAA any progress in this? I know it's summer and hot 😅

Oh! Sorry!! I thought it was merged a long time ago. I completely forgot about this one. Don't hesitate to ping as soon as possible (~1 day) if you expect something from me, I have lots of things on my plate right now and I'm not finding the time to do what I always want...


CF Time Fix - Phoenix like

From the ashes it shall rise....
See #715
Testing:

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

Superseded by #725 to resolve conflicts.


Triggers removal

Can you give more details about how db trigger removal works? I am encountering some scenarios where triggers shouldn't be removed (on scheduler shutdown/restart), but maybe there's something I'm missing.

I'm not as familiar with the Quartz internals for shutdown and restart.
This project is pure a job repository so there really aren't very many
smarts in it. I tried to follow the built-in implementation very closely.
Although, it is likely I made some mistakes along the way as I recently
found with #1. Could you provide a unit test eliciting the problem you are
seeing?
On Wed, Oct 12, 2016 at 1:43 AM Claudiu Constantin<EMAIL_ADDRESS>wrote:

Can you give more details about how db trigger removal works? I am
encountering some scenarios where triggers shouldn't be removed (on
scheduler shutdown/restart), but maybe there's something I'm missing.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/chrisdrobison/mongodb-quartz-net/issues/2, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABu24YdBUdQWY_mKPM4-kOLB1bN8sszuks5qzI-ngaJpZM4KUdVO
.

I'll close this one for now until more feedback is given.

When I'll have some time I'll look again into this in order to better identify and describe the issue. I finally decided over sqlite jobstore for my particular case.


Add uaa BOSH link to provide credentials

After discussing with @sreetummidi , we've decided to not do this work.


Provide support for multiple etcd endpoints

We probably could use native gRPC LB for this.

Aggregation of events from same transaction.
If a transaction is made, e.g. put 3 key changes at once, then its not possible via a watcher to get this changes at once. Therefore, it is not possible to determine when related changes have been fully received.
Each event of the same response is processed by its own, a watcher is not able to detect the end of a transaction this way.
watcher.py:
 for event in response.events:
        await self._process_callback(
            watcher_callback,
            rtypes.Event(
                event.type,
                event.kv,
                event.prev_kv if watcher_callback.prev_kv else None,
            ),
        )


Fixed Yaml Format Error

with CONCOURSE_OAUTH_CLIENT_ID Key

What this PR does / why we need it:
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Special notes for your reviewer:

Good catch! Thanks!


Loading a JPG image gives an image with an alpha channel

Godot 3.0.6
As found in https://github.com/godotengine/godot/issues/18882#issuecomment-389115304, loading a JPG  gives an image with an alpha channel, even though JPG cannot contain one.

Yeah, its still present in 3.1 ex:
var image = Image.new()
image.load("res://Moon.jpg")
var format = image.get_format() # format is 5 which is FORMAT_RGBA8


Clicking "Maximise" button in Windows causes crash

file:///C:/tiny-rtx/src/utils.mjs:12
        throw new Error(`Vulkan assertion failed with ${key}`);
        ^

Error: Vulkan assertion failed with VK_ERROR_OUT_OF_DATE_KHR
    at ASSERT_VK_RESULT (file:///C:/tiny-rtx/src/utils.mjs:12:15)
    at RayTracingDemo.VulkanApplication.drawDefaultFrame (file:///C:/tiny-rtx/src/VulkanApplication.mjs:126:3)
    at RayTracingDemo.drawFrame (file:///C:/tiny-rtx/src/index.mjs:174:8)
    at Timeout.drawLoop [as _onTimeout] (file:///C:/tiny-rtx/src/index.mjs:152:9)
    at ontimeout (timers.js:436:11)
    at tryOnTimeout (timers.js:300:5)
    at listOnTimeout (timers.js:263:5)
    at Timer.processTimers (timers.js:223:10)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>start: `node --experimental-modules ./main.mjs --verbose-log`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

I'm seeing this issue on my machine as well.

I didn't add swapchain recreation yet.


Fix sourcemaps errors and update test

This huge PR brings next improvments:
Tests
First of all i rewrite tests using Tape and change folder structure.  It's more convinient way for testing, also such tests more flexible and can be debugged with Node debugger. Bash scripts is not cross-platform solution (Windows does'not support bash scripts without extra tools).
Besides i've added some new test cases. I'll describe this test cases later.
Issues
The main issue i've tried to solve, is duplicating files in sourcemaps (https://github.com/huston007/ng-annotate-loader/issues/24 see last comment, also https://github.com/huston007/ng-annotate-loader/issues/23).

Generally, problem is here:
var generator = SourceMapGenerator.fromSourceMap(new SourceMapConsumer(annotateMap));
generator.applySourceMap(new SourceMapConsumer(inputSourceMap), filename);

outputSourceMap = generator.toJSON();

inputSourceMap.sources should have same path and name as annotateMap.sources.
Otherwise outputSourceMap will be have duplicate files in sources.
Example:

As you can see in screenshot, outputSourceMap.sources has two entries, becuase sources in inputMap and annotateMap have diffrent slahes and path (relative/absoulte)
Therefore we see the first problem:
Sourcemap doesn't care about forward slahes
If you are using *nix system you have never got this error. See what mozilla/source-map team think about this https://github.com/mozilla/source-map/issues/91
So solution is simple, we need normalize pathes everewhere.
There is a big problem with accepatance tests, we can't simulate this behaviour, it means somebody on unix system can rewrite something and tests will not report any problems. (i think we need to refactor loader, and write unit test for mergeMap() function)
Prefixed resource path
Sometimes webpack (or not?), emit map with sources prefixed by loader name:

node_modules\tslint-loader\index.js!c:\opensource\ng-annotate-loader\cases\typescript\file-to-annotate.ts

Actually i don't know when and why it happend. I spend a lot of time to find the reason. But all i found was awesome-typescript-loader + tslint as preloader processed '*.ts' file caused this behaviour.
In our project, eslint cuase the same when precessing *.js files.
I added special test case typescript which cover this issue.
I was looking for a solution for a long time, i've tried few diffrent approaches, but finally is very simple:
 var filename = normalizePath(this.resourcePath);
inputSourceMap.sourceRoot = '';
inputSourceMap.sources[0] = filename;

Source map in loader always have just one entry in sources and this entry the same to processed file. We override entry, with normalized resource path.
Some loaders return sources with relative path and filled sourceRoot. We clear sourceRoot, because we override path with absoulte url, and we don't need prefix.
Issues with sourceRoot
SourceMapGenerator can merge maps even if they have not absolutely the same sources.
It can merge relative with absoulte path but only if correct source root is provided.
Sourcemaps from ngAnnotate always have absolute path, but inputSourceMap.sources can be diffrent it depend on loader.
Sometimes it has relative path + sourceRoot (babel-loader), sometimes only relative path (typescipt-loader), sometimes absolute path.
Solution the same as in previous issue: explicit set absolute path and clear sourceRoot.
I've added test case uglifyjs which cover this issue.
Dependecies
I've updated all dependecies, and update test references (because babel6 generate diffrent output)
Also i've added .editorconfig to help writing code in same code style.

Test failed. Interesting. Webpack Hash in source maps is diffrent... need another way to check sourcemaps valid. Dirty checking files is not good solution.

@thekip Great job! I need some time to get into it. Thank you for the PR!

Problem not only in hash (
Diffrent between unix/windows line endings.
I already fixed that in generated source, but the same mistake exist in maps as well, and it's not so easy to fix.

Last to commits bring next improvments:

Bugfix: when ngAnnotate do nothing on file it still generate sourcemap (i don't know what exactly mapped inside), when this map merged with input map it produce new broken merged map.

So i check, if source code are the same (nothing was to annotate) I just return input sourcemap without merging.
This is old bug, but previously we didn't notice that because it breaks a duplicate file in maps.

Change the way how maps are tested. I've created special file sourcemap-checkpoints.js for each test case, which used as reference for sourcemap.
This is more intelegent way to test maps, because we exactly know work this map or not as if tested in browser.
Also this fix issues with crlf/lf.

Any progress on it?

This is ready to merge, wait for @huston007
@hekike You can use my fork, untill it merged to original packet.

@thekip @hekike Oh that cool! Didn't noticed that it started passing the build. Merging.

@huston007 thanks ;)
When do you plan to release it?

@hekike I have to perform some testing before. You could help me if you try and say it works for you : )

@huston007 I use it about half month in our huge project (codebase about 3mb) and it works. My teammates didn't report any issues related to that.
You can run it on yours project, and test it as well.

@thekip Yep I will. Thank you for the job you've done.


Is the keystroke for platformio-ide-terminal:new changed?

I'm not sure if my memory is correct. I'm used to type shift-cmd-t to open the terminal, but apparently it is alt-cmd-t to open the terminal in the settings.
So, I"m asking if the keystroke was changed or not? Sorry, this is my fingers' memory, I really don't know why my fingers always type shift-cmd-t
Second question, if the above question is no, please ignore the following question.
I've changed the keystroke setting to shift-cmd-t, so I won't mess up while I need to open the terminal or close it. However, if this keystroke was changed, why? should I change it to shift-cmd-t?
Thank you :)

Thank you for reaching out.
A short answer is yes, the keymap in macOS apparently conflicted, and a PR was submitted by @navalkishore30 to address this. See commit https://github.com/platformio/platformio-atom-ide-terminal/commit/cb12f3127edb8364add8e53fe041aac5d28670fa
I think were open to improving on this as long as there's no conflicts with Atom. I will be testing out this in a couple of days.

thank you  👍


Update sbt to 1.2.8

Updates org.scala-sbt:sbt from 1.2.7 to 1.2.8.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention @scala-steward in the comments below.
Have a fantastic day writing Scala!

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

labels: semver-patch

Thanks!


NavView and Alt + Left KeyBoardAccelerators

We're having an issue with WinUI NavView and the Alt + Left KeyboardAccelerator.
Initially we added the KeyboardAccelerator in the page constructor (following guidance from
https://docs.microsoft.com/en-us/windows/uwp/design/basics/navigation-history-and-backwards-navigation), but doing this the "Alt + Left" Tooltip is showing all over the app.
We saw in your samples (https://docs.microsoft.com/en-us/windows/uwp/design/controls-and-patterns/navigationview#code-example) that you are adding the accelerator in the NavView Loaded event handler. Moving the code here results in not showing the tooltip.
Is NavView_Loaded or Page_Loaded the correct place to add KeyboardAccelerators?
Working on this we also noticed that the NavView BackButton does not have a tooltip. Should this tooltip de provided out of the box (like the Hamburger Button does) or are we missing something?
I'll attach a generated app so you can see what we are generating.
NavViewTooltip.zip
Tracking issue on our side is https://github.com/Microsoft/WindowsTemplateStudio/issues/2650

Filed on engineering team (Internal tracking link)

Leaving as open until we have closure on the internal side of things.

@ranjeshj @jevansaks Can we close this issue now? The corresponding issue over at WindowsTemplateStudio has been closed and it sounds like the fix for this was already added back then.

No objections from me.

Hi
Adding keyboardAccelerators to WinUI 3 Preview 4 Templates in WindowsTemplateStudio I've verified that this tooltip issue still happens.

@jevansaks or @chingucoding do you remember this one?

Could it be that there is a regression in WindowsTemplateStudio for the preview4 version? Or is the Preview 4 NavView different from the WinUI 2 one?

@sibille FYI

@jevansaks Jevan Saks FTE or @chingucoding do you remember this one?

Looks like the internal bug I linked earlier is still active.

I just double checked and can confirm that this issue is still happening, both on WinUI 2.5 and WinUI3 Preview 4.
We currently add the keyBoardAccelerators in the OnLoaded Event, but if I move them back to the ViewModel initialization I can see the Alt+ Left Tooltip pop up again.

Repro app (using WinUI 2.5): App1.zip
Can we reopen this? Will also create a tracking issue on our side.


Create a section to organize projects in readme.md

There are lots of projects available here, can we have a section or table to organize these projects alphabetically , so people can easily access

Assign this to me!

@DhanushNehru  PR is done
Kindly Review and merge it!


Erorr ddev start after update 1.2.6

Is there an existing issue for this?

[X] I have searched the existing issues

Run a Diagnostic and Paste Link Here
Hello, i updated ddev to last version but now i cant start projects, when i execute ddev start fire this message:
The docker version currently installed does not seem to meet ddev's requirements: 19.3.12 is less than 20.10.0-alpha1
failed to RunSimpleContainer to inspect database version/type: failed to create/start docker container ({GetExistingDBType-myproject-lRzWqX 0xc00025a1e0 0xc0000d8000 <nil> <nil>}):API error (400): invalid IP address in add-host: "host-gateway", output=
Expected Behavior
Start de project.
Actual Behavior
start the project
Steps To Reproduce
Update ddev to 1.2.6 with apt-get (ubuntu)
go to any project and execute ddev start
Fire this error
failed to RunSimpleContainer to inspect database version/type: failed to create/start docker container ({GetExistingDBType-myproject-lRzWqX 0xc00025a1e0 0xc0000d8000  }):API error (400): invalid IP address in add-host: "host-gateway", output=
Anything else?
No response

Hi @elrokket - Could you please edit to include the output of ddev debug test as was requested?
It looks like this is probably a Docker problem rather than ddev, so please make sure you've restarted docker itself and even rebooted your computer.
Following the troubleshooting docs may help you as well. Things like this are often firewall, vpn, etc.

Please share the .ddev/.ddev-docker-compose-full.yaml in tryddevproject-25256 - it would be a lot better as a gist or other pastebin, or as a textfile please.

Not exists

It's in the .ddev directory of every project. It's created on ddev start. You may not see it because you're on linux and dotfiles are hidden by default. ls -a .ddev/.ddev* will show it to you. Or just get me .ddev/.ddev-docker-compose-base.yaml.

It's in the .ddev directory of every project. It's created on ddev start. You may not see it because you're on linux and dotfiles are hidden by default. ls -a .ddev/.ddev* will show it to you. Or just get me .ddev/.ddev-docker-compose-base.yaml.

i cant start because is the error fired, only create /web folder

Fixed, the problem is with 19 of docker, i updated with this command:
 sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
and now are working, thanks and sorry for your time.

Glad it's working for you!


install patchelf dep on linux

I'm guessing that BuildExecutable.jl should probably install patchelf on linux distros?
https://github.com/Rory-Finnegan/Playground.jl/issues/43

Yes, it would be good to automate the installation of patchelf on linux.

Fixed by #24.


prysmgrpc doesn't implement SignedBeaconBlockProvider

The SignedBeaconBlockProvider interface was recently changed to return *spec.VersionedSignedBeaconBlock instead of *spec.SignedBeaconBlock.
The http package implements this change, but prysmgrpc still implements the previous interface.
How can we call `SignedBeaconBlock when connected to Prysm? Or is this still a work in progress?
Thanks!

I've forked & updated prysmgrpc to implement this change, but without support for Altair (unlike the http package). This allows me to keep using the interface without resorting to type assertions.
Please let me know if this makes sense as a pull request.

With prysm implementing the standard HTTP API we're moving away from the prysmgrpc module and using http instead.  We expect this to be fully available in advance of the mainnet Altair upgrade.

That makes sense, thanks!


add support for eg 015 phones

add support for Eg phone numbers that starts with 015

It should be standardized to this length and the users also able to disable length restrictions if they chose to do so

@profnandaa done 👍


Why the write performance of PebblesDB and TitanDB is significantly lower than RocksDB ?

Why is it that when I conduct microbenchmark tests using the ycsb-c, the results show that the write performance of PebblesDB and TitanDB is significantly lower than RocksDB? This clearly doesn't seem reasonable. I haven't made any changes to the configuration or workload; I'm just conducting the tests. What could be causing this?

Or is it because I conducted the tests with 16 threads?


Add commit log integration test

This is PR 1 in three PR's that together will improve the performance of the commitlog bootstrapper. This PR just adds the integration tests so that the other two PRs can be merged with confidence.
Adds a commit log integration test. Most of that code was written by prateek, but I made a few small changes to:

Remove an unnecessary sleep (the commitlogs Close() method waits for all writes to complete so the sleep was not necessary)
Increased defaultIntegrationTestFlushInterval to 100ms based on feedback from Rob
Increased the amount of data generated by the integration test such that it was enough (in my experience testing it) to detect concurrency / parallelism issues.
Rename computeMetricIndexes to generateUniqueMetricIndexes based on Rob's feedback
Replace named function with anonymous defer based on Rob's feedback

Coverage increased (+0.2%) to 77.305% when pulling 6d597a029388a754939398ca95a626b53c1f2ec1 on richardartoul:ra/add-commit-log-integration-test into b400c41816f489b6f33b13c0849a41e7fc1cb540 on m3db:master.

Coverage increased (+0.1%) to 77.28% when pulling 6d597a029388a754939398ca95a626b53c1f2ec1 on richardartoul:ra/add-commit-log-integration-test into b400c41816f489b6f33b13c0849a41e7fc1cb540 on m3db:master.

Coverage increased (+0.2%) to 77.299% when pulling 6b2efdb0d314b3bdd350812dff22152788fc267d on richardartoul:ra/add-commit-log-integration-test into b400c41816f489b6f33b13c0849a41e7fc1cb540 on m3db:master.

Coverage increased (+0.2%) to 77.392% when pulling d053d9826ceb416ebc680511bc0efc05a016a040 on richardartoul:ra/add-commit-log-integration-test into b400c41816f489b6f33b13c0849a41e7fc1cb540 on m3db:master.

Can't commandeer because the origin branch isn't off the m3db repo, continuing work in #320


Displaying several columns in one tab/panel

Hello,
I'm interested in displaying more than one column on a single tab/panel.
Which file/folder should I be looking at to accomplish this? Thanks!

 If you have added multiple lists in the River5 lists folder, you should see a tab for each list. Are you asking how to display multiple rivers next to each other?

@andysylvester Not exactly. For example, let's say I have the river "ESPN" and it displays all the breaking stories from the sporting world. Rather than 1 view, I would like to have 2 or 3  columns that are populated with the ESPN rss feed. See pictures as an example:
https://cdn.colorlib.com/wp/wp-content/uploads/sites/2/three-column-wordpress-themes.jpg

@TsterRM -- I can see the utility of something like that, but that's not really something River5 does. It's about aggregations of feeds. You want to display a single feed. You have to start somewhere else. And you really do have to be a programmer to do that. Or hire one. ;-)

@scripting Understood, thank you very much for your input. I appreciate it!


Thank you for making this library

I know issues are not really for this, but thank you very much for this library. It reduces boilerplate so much!
If you need help from the community to maintain it, make sure to let us know. In the Readme or with a pinned issue for instance. Since the project is pretty small, it should be relatively easy for people to jump in and help if needed.
Cheers, and thanks again.

Thank you, really. It means a lot.
My full-time job caused me to burn out, to be honest. I was wanting to help with issues but I couldn't manage to do it.
I tried to do fix some of the problems people mentioned today.  If you have suggestions, I planning to spend more time on the library.

Glad you're feeling better then :) No worries at all. Open source can be very taxing. I also burned out on some open source projects. It's basically giving your personal time for free, for other people, so it can feel exhausting when it starts becoming some kind of duty. Take it easy, let others help, and take as many breaks as you need!


test: remove old Node.js version testing

What is the purpose of this pull request? (put an "X" next to item)
[ ] Documentation update
[ ] Bug fix
[ ] New feature
[x] Other, please explain: Tests
What changes did you make? (Give an overview)
Remove the test for the legacy Node.js version, I find it useless to test that we don't run in older versions of Node.js.
The user should be responsible to run old versions.
Instead what we can do is to clearly state in README.md what Node.js versions we support, that should be >=12.0.0 as now v12 is EOL, maybe we should wait for the next major version of standard to remove Node v10 from the support list.
Thoughts?
Which issue (if any) does this pull request address?
Ref: https://github.com/standard/standard/issues/1663#issuecomment-870581010

I'm actually 👎 on this change after reading the description of the test:
# Special test for the oldest version of Node.js that we "support"
# even though the linter won't actually run. Test that the command
# line program exits cleanly.

The intent of the test is to ensure that we fail silently on non-supported old node.js versions, thus making it simple for projects that supports a wider version range than us to still include us in their test script on all node versions.
(It could however do with some more added versions, as the jump from 0.10 to <10.12 is quite large, just testing on 0.10 doesn't ensure that it fails silently on eg 6.x)

Closing.
It's probably better to have more than necessary automated tests than not enough.


Use ElevenLabs for TTS

Currently it uses pyttsx3 ; could use ElevenLabs instead, as suggested by @NirantK .

Commit c76b6c2 uses coqui-ai/TTS instead of pyttsx3 for text-to-speech, as suggested by @NirantK .
This is a better option, as coqui-ai/TTS is open-source, unlike ElevenLabs .


BasicObject.new.to_nil

BasicObject.new.to_nil

does not work. I just lost tons of money on this.

:bangbang: :warning: Need an patch for it ASAP :warning: :bangbang:

@bbenezech fixed :godmode:


cyma

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.2
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 120
deps=[c]

/trunk merge


Enable docker based builds

Reference dev docker in the documentation and do a number of fixes to make it work, including integration tests (tested only in simulation mode, though should work also in HW mode if you pass the sgx device and PSW socket to docker ...)

Did update the PR (mostly) as discussed:

ported some stuff from PDO, e.g., support for SGX HW-mode and enabling addition of custom packages.
dockerfile is now also a bit more parameterized
docu is now more expansive (and should now be consistent)

One thing, though, i gave up is to set the docker image to the same git branch/state as the host.  Just using the branch name doesn't work in the common use-cases as there is a mismatch on remote names and the approach from PDO to use the host repo as repo to pull from in docker also doesn't work well for a development image (in PDO i used it for unit-tests).  Hence, to test the docker image, you will have to change FPC first to the branch of this PR or it will fail in the tests as the peer's port is not properly forwarded as the core.yaml change is missing ...


Make wiki 0.2.3

MAKE WIKI

RETURN WHOLE OBJECT FOR AUTHOR GETTING IN COMMENT STUFFF

MAKE THE 1 MORE API IN THAT ISSUE
PUT UNION LITERLALLY EVERYWHERE YOU CAN FIND


let folks know you have this plugin

from reading the room, there seems to be a broader move from cypress/puppeteer to playwright.
in order to let folks know about this plugin, it might be useful to mention it in the following places:

nrwl/nx slack (there is a #nx-plugins channel where folks mention cool plugins)
the plugins directory
a comment on the youtube video that the official nx channel made a few days ago .  They crash-course playwright and the only comment is actually a q about a plugin!

I can do any of these for you if you like, but don't want to step on toes of course :)

Thanks @ludicast!
We've added your suggestion to our backlog, and will get to it as soon as we can 😄

cool - apparently this is the template to submit your plugin if ya'll wanted : https://github.com/nrwl/nx/blob/master/.github/PULL_REQUEST_TEMPLATE/COMMUNITY_PLUGIN.MD

fyi @mcalthrop / @andreacaldera - seems there's now 2 playwright plugins in the directory: https://nx.dev/community
if you want this plugin to be used externally - so the community can use/enjoy your hard work - you probably should jump on this
(and if you only care about internal usage, you probably should set this repo private :))

Thanks @ludicast
We did create a PR on NX to add this to their community https://github.com/nrwl/nx/pull/12458
We are taking to NX and trying to get in but if you liked this plugin it'd be good to get a shout out from you ;-)

@ludicast the plugin has been added to NX community, thanks for your support!!


Add field to schema

Is it possible to add a new field to the schema?

I decided to implement it by myself with the help of the Solr Schema API here and using the HttpClient.

I decided to implement it by myself with the help of the Solr Schema API here and using the HttpClient.


Flatten the app

██████╗ ███████╗ ██████╗
██╔══██╗██╔════╝██╔════╝
██████╔╝█████╗  ██║
██╔══██╗██╔══╝  ██║
██║  ██║██║     ╚██████╗
╚═╝  ╚═╝╚═╝      ╚═════╝

move campaigns into the main page
add about page
access donation form also via the dontaion pills

Please note: I'm not happy yet with the text content on the main page and about page. I'd propose to shift some content to the about page and keep the text in the main page much shorter. The text inside the main page could include a link into the about page as well. Last but not least misses the app a reference into THIS github project (e.g. inside header or footer and also inside the about page).
Beside that please try out locally, if the new app flow makes sense and is more beneficial compared to the previous version.

BTW some of the changes like removing the card around the intro text on the main page I consider experimental. Having Cards all over creates an consistant look especially on mobile, but also consumes additional space. On a non-mobile webpage it might also feel a bit too much and just text might feel a bit more lightweight.
Definetly something to talk about.


minified js causes Opera Issues (ajaxmin 4.45.4416.14249)

Opera does not like the minified js produced by ajaxmin  This is even after upgrading the the latest ajaxmin nuget package (4.45.4416.14249.)
The issue seems to be around the in keyword as show here http://gyazo.com/f516d9499e3d1e87bc30ecef8a8f32e1. That line is from jquery 1.7.1
The following issue on ajaxmin codeplex site refers to something similar http://ajaxmin.codeplex.com/workitem/16850.
Is it possible for us to include our choice of min tool (yui, closure etc)?

I have just tested my app removing the local copy of jquery and linking directly to the jquery google cdn version and everything works so it is def an issue with ajaxmin and jquery.

Try enabling the ajaxmin kill switch like this:
bundles.AddPerSubDirectory<ScriptBundle>("scripts", b => b.Processor = new ScriptPipeline
{
    Minifier = new MicrosoftJavaScriptMinifier(new CodeSettings { KillSwitch = 0x40000000000 })
});

Thanks, will try this afternoon
On Feb 6, 2012 10:27 AM, "Andrew Davey" <
<EMAIL_ADDRESS>wrote:

Try enabling the ajaxmin kill switch like this:
bundles.AddPerSubDirectory<ScriptBundle>("scripts", b => b.Processor = new
ScriptPipeline
{
   Minifier = new MicrosoftJavaScriptMinifier(new CodeSettings {
KillSwitch = 0x40000000000 })
});

Reply to this email directly or view it on GitHub:
https://github.com/andrewdavey/cassette/issues/157#issuecomment-3826309


PSFS doesn't work with<EMAIL_ADDRESS>

Describe the bug
PSFS doesn't work with<EMAIL_ADDRESS>It fails with error:
PHP Fatal error:  Trait 'PSFS\base\types\traits\SingletonTrait' not found in .../vendor/psfs/core/src/base/Logger.php on line 30
Seems something related to the psr-4 section of composer.json of PSFS.
To Reproduce
Steps to reproduce the behavior:

Install PHP 7.4
Open any project.
Run local server.
Make an API request and see error.

Expected behavior
Local server runs without issues.
Screenshots
Desktop (please complete the following information):

OS: MacOS Big Sur 11.2.1 M1

Additional context

Solved and upgraded the requirements from php7.1 to php7.2


Pretraining accuracy for retromae v1

Great job!
Hello , i wonder if you can tell me the training mlm accuracy of encoder and decoder. Im training my retromae model now.

Hi, I am also quite interested in this work. Could you tell me how much the loss function of the model decreased when you were training the model on Wikipedia? I am trying to pretrain a BERT encoder using retromae v1 on my local dataset (a document pool extracted from Wikipedia).  But I have no idea if my model is fully trained?