Updating peer dependencies

Please provide a description so I can better understand your expectations.

This message still bugs me - I'm running ng4 (4.2.4 btw) with ng2-vis without any problems so far.
Could you please accept the pull request #33 ?
Thanks!


Index out of bounds in cosineDistance

Weird this didn't show up before, but I think it's because it's taking the domain to be dynamic.  In the first line, X comes in with domain {0..4, 0..4}  but this line seems to expect it to start at 1:  https://github.com/buddha314/numsuch/blob/master/src/core.chpl#L78
cosineDistance(X,X)
Xdom {0..4, 0..4}
dot(X[0,], X[1,]
dot(X[3,], X[4,]
dot(X[3,], X[5,]
dot(X[0,], X[2,]
../src/Core.chpl:82: error: halt reached - array index out of bounds: (5)
dot(X[0,], X[3,]
dot(X[0,], X[4,]
dot(X[0,], X[5,]
make: *** [core] Error 1

I worked around this in a way that seemed reasonable, but I'd still like @ben-albrecht 's opinion on it.  Essentially I did this:
    //forall i in Xdom.dim(1) {
    forall i in Xdom.dim(1).first..Xdom.dim(1).last {
      const x2 = Xii[i];
      //for j in i+1..Xdom.dim(1).size {
      for j in i+1..Ydom.dim(1).last {

in both functions.  I would make it a pull request, but I fixed it right in the middle of my branch for examples.

Going to close this and try to optimize at a later date if need be.

Sorry @buddha314 - I missed this in my notifications somehow.
Another solution is to reindex everything to 1-based indices at the start of the function, e.g.
X1 = X.reindex({1..X.size});


Consider using a command framework library

At the moment the command class (DimensifyCommand.java) is rather cluttered, at worst it's difficult to find the entire command/argument structure. Using something like ACF's popular annotation-based command framework would make it both easier to read and maintain/modify.

Using someone elses library will not be considered. I already have something in the works within IfyCore that I will be using instead. As for the command being a mess, I haven't gone through the cleanup stage of the plugin yet :) Aaaaalllll of the logic will be moved out of there after that phase.


Make rustdoc links work with the book

This PR contains the following changes:

Fix all warnings building the rustdoc documentation. Mostly internal crossreferenced urls. To make them work with the book, a new Python function has been added to the post_build.py script, which rewrites the urls in the generated HTML files.
Rename BreakpointsSematic to BreakpointsSemantic and breakpoints_sematic to breakpoints_semantic (note the n). This is a breaking change.

Thank you very much! Nice work!


[Improve][issues-72] build script improvement

Proposed changes
Issue Number: close #72
Problem Summary:
Currently, in the build.sh script. env checks such as thrift, java, maven, etc., needs to be optimized.

thrift needs to verify the version is 0.13.0
mvnw support(if not install maven)
check java env need to improvement

cc @JNSimba PTAL, thx


Cannot create or delete output nodes

in the UI there is now way to create or delete output nodes

We will create an output section in the top navigation ant allows adding of output nodes and removal, in the meantime editing the save manually seems to do the job.


Info symbol for 'Include Subdirectories in Dependencies' in block's properties shouldn't be clickable

Describe the issue
Hovering over info symbol:

changes cursor from arrow to a 'finger', which implies that it should be clicked. Which is not the case. If you click, the checkbox is selected, which is not what the user would expect.
To Reproduce

Hover over the info symbol in the 'Include Subdirectories in Dependencies' section of the block's properties.

The cursor will change, so the expected action is the 'i' symbol should be clicked.
The lag until the hover produces a message is long enough that the user would just click before it is shown.
The checkbox is now checked and no info message is shown.

Expected behavior
The click action on the info symbol of the 'Include Subdirectories in Dependencies' in the block's properties should not select the checkbox.
All the other 'i' symbols behave as expected.

With the release of elyra 3.0, the new properties editor displays the "info" wholeheartedly
so the info hover button will likely not be returning and we currently have no plans for a 2.x patch release for this. Will close in a few days unless any comments are made. Thanks


[TF2] Checking for updates via parsing server log fails with a syntax error

tf2server@athair:~$ ./tf2server restart
[  OK  ] Stopping tf2-server: Team Fortress 2
[ .... ] Update tf2-server: Checking for update
[  OK  ] Update tf2-server: Checking for update: Server logsgrep: /home/tf2server/log/console/tf2-server-console.log: No such file or directory

/home/tf2server/functions/fn_update_check: line 77: [: : integer expression expected
[  OK  ] Update tf2-server: Checking for update: Server logs: No update requested
[  OK  ] Update tf2-server: Checking for update: SteamCMD

No update available:
        Current version: 606753
        Available version: 606753
        https://steamdb.info/app/232250/

[  OK  ] Update tf2-server: No update available
[  OK  ] Starting tf2-server: Team Fortress 2

When I first ran the script, I believe the file wasn't even there (it's looking for a log without any time/date info in the name?), so I made it:
touch log/console/tf2-server-console.log
Its contents as of right now, many many restarts later:
tf2server@athair:~$ cat log/console/tf2-server-console.log
Console logging disabled: Bug in tmux 1.8 breaks logging
Currently installed: tmux 1.8

This is the command it generated and tried to execute:
grep -Ec "MasterRequestRestart" "/home/tf2server/log/console/tf2-server-console.log"
Running it directly in the terminal gives the proper output:
0
Something about the context the script executes in must keep it from running properly?

Please delete the functions dir and try again. I might of fixed this

Just wiped functions/ and tried again. Issue is still there...

thanks

does the file or directory not exist?

It's there, check my OP. Running the command from the terminal works just fine, but the script trips up on it for some reason that must have to do with the environment of the script.

Yeah im not sure myself as im unable to replicate. Can you post the output of details (remove passwords etc) so I can test on a similar system.

I'll do you one better, send me an RSA public key in the format SSHD recognizes and I'll let you log in and poke around. I'll scrub passwords now.

Okay, I can't wait much longer, thought you'd see this message tonight... here's the output from details:
tf2server@athair:~$ ./tf2server details

Distro Details
========================================================================================================================================================================================================
Distro:    Ubuntu 14.04.2 LTS
Arch:      x86_64
Kernel:    3.13.0-52-generic
Hostname:  athair.us
tmux:      tmux 1.8
GLIBC:     2.19

Performance
========================================================================================================================================================================================================
Uptime:    0d, 4h, 47m
Avg Load:  0.36, 0.25, 0.20

Mem:       total   used   free
Physical:  994M    922M   71M
Swap:      0B      0B     0B

Disk Usage
========================================================================================================================================================================================================
Disk available:  8.3G
Serverfiles:     14G

Team Fortress 2 Server Details
========================================================================================================================================================================================================
Server name:    CONFIG FILE MISSING!
Server IP:      XXX:27015
RCON password:  CONFIG FILE MISSING!
Status:         ONLINE

Service name:  tf2-server
User:          tf2server
Location:      /home/tf2server
Config file:   /home/tf2server/serverfiles/tf/cfg/tf2-server.cfg CONFIG FILE MISSING!!

Backups
========================================================================================================================================================================================================
No Backups created

Command-line Parameters
========================================================================================================================================================================================================
./srcds_run -game tf -maxplayers 24 -strictportbind -ip XXX -port 27015 +clientport 27005 +exec athairus/sourcetv.cfg +sv_pure 0 +tv_port 27020 +servercfgfile tf2-server.cfg -replay +map pl_badwater

Ports
========================================================================================================================================================================================================
Change ports by editing the command-line
parameters in tf2server.

Useful port diagnostic command:
netstat -atunp | grep srcds_linux

DESCRIPTION  DIRECTION  PORT   PROTOCOL
> Game/RCON  INBOUND    27015  tcp/udp
> SourceTV   INBOUND    27020  udp
< Client     OUTBOUND   27005  udp

Status: ONLINE


Whatsaap Link invalid

Describe the bug
When clicking on whatsaap button it opens an invalid link
To Reproduce
Steps to reproduce the behavior:

Go to 'site'
Click on 'whatsaap button'
See error

Expected behavior
I expected a group, community or a channel link to open to join
Screenshots

Desktop (please complete the following information):

iOS
Chrome
Version 130.0.6723.5

Additional context
I can fix the problem by changing the link and make it fix

@KhanjarSingh i have assigned you. please make the link such that it redirects to the whatsapp community

@Rizwan102003 the whatsaap link is dead can u provide me with the new whatsaap link?

@arushi2610 check this once

I really like your website and want to work on your project ,please assign this issue to me under gssoc-ext 2024


startOf('week') for moment.locale('en-ca') is not the same as for moment.locale('en-ca')

dt: moment()
    console.log(moment(dt).locale('en-ca').startOf('week')).format('MMM D')  //returns Jan 28
    console.log(moment(dt).locale('zh-cn').startOf('week')).format('MMM D')  //returns Jan 22

First console.log returns Jan 28 for locale('en-ca') which is a Sunday
Second console.log returns Jan 22 for locale('zh-cn') which is a Monday
Time is not in sync.

The locales have different definitions for the start of a 'week':
moment().locale('zh-cn').localeData().firstDayOfWeek(); // 1 - Monday
moment().locale('en-ca').localeData().firstDayOfWeek(); // 0 - Sunday

If you want to ignore the locale's definition of a week, you could use startOf('isoWeek') which always uses Monday as the start of the week.


 I understand that you might not test on this platform, which is why I wanted to bring this to your attention.
Version

OS: Linux aarch64
CVXPY Version: 1.1.7 and 1.1.8

Here's a log of the same errors in 1.1.10 https://gist.github.com/r-rmcgibbo/f4931b36a63e285d528ae989b4329201

@rmcgibbo thanks for notifying us. The first error is real, but it's not all that unexpected. ECOS_BB has known correctness issues and we no longer automatically select it on a user's behalf (they have to call ECOS_BB explicitly). The second problem certainly looks like numeric noise.
For the second problem, the fix is just to reduce the test's precision requirements.
There are probably several fixes for the first problem (which ultimately need to be along the lines of "inform the user that ECOS_BB is still broken but don't return an error that would make it look like the unittests failed"). @akshayka and @SteveDiamond I thought we encountered and fixed almost this exact same issue in the past. Does this look familiar to you two?

Am I correct that you don't believe this test failure is really specific to aarch64? It's just that ECOS_BB is a bit flaky, and the numerics happen to be slightly different between x86 and aarch64, without either necessarily being more likely to be correct in general.

@rileyjmurray I believe these tests were commented out/fixed for conda-forge. @rmcgibbo we should definitely fix the tests in general, lowering the precision for the latter test and doing something (not sure what lol) for the ECOS_BB test.

In 1.1.12, it looks like the tolerance issue might be fixed, but the ecos_bb failure is still there:
https://gist.github.com/r-rmcgibbo/4bf1b21010e6536bb18f2934ee160077#file-python38packages-cvxpy-L1366-L1383


Allow PSR log 2.0

Some tweaks in code (type compatibility) may be required.

Are there any plans to merge this?

Sorry I missed this PR. Are there any further changes required?

PSR log 2.0 added parameter types (3.0 added return types), there may be some tweaks required in case of some type juggling, but its unlikely in my option.

Superseded by #51.


wrong search collapse states on AI results

github.copilot.chat.search.semanticTextResults:true
Run a search. Minimize Text Results and open GitHub Copilot Results to load them
Use the top right collapse/expand button to expand/collapse.
Notice that only the AI Results node gets collapsed/expanded. :bug:

It seems that I'm calling tree.expandAll()
https://github.com/microsoft/vscode/blob/f26394d47799728503e3107f4807cf846966952c/src/vs/workbench/contrib/search/browser/searchActionsTopBar.ts#L131
which might be different for the AsyncDataTree. Not too sure about this.

@benibenj I noticed that AsyncDataTree.expandAll() only recursively opens nodes that have already been loaded. Is there a way to expand the whole tree?


[Bug]: Not working as intended - SOLVED

Are you on the latest version?

[X] I'm on the latest version

Is there a fix in progress related to your proposal?

[X] I have searched the existing issues

Describe the bug
Did all the steps mentioned in the website, But Discord is not showing Game Activity,
Its Not working.
Expected Behavior
No response
Dota 2 Patch
7.31d
Steps To Reproduce
No response
Anything else?
No response

Solution: I followed these steps

Let's do one more test.
Uninstall the service, if you have it installed; Manually copy the cfg file to your Dota 2 folder; Run the program using the command (Do not close the terminal); Open dota and enter the hero demo
The file is here: #1 (comment)

Source: https://github.com/andsfonseca/dota2-rpc-client/issues/1

@GTPang. I'm glad you found the solution in the previous thread. As it's still a basic version, the installation process is still a bit confusing.
Later, send us a print so we can see you with your favorite hero.
If you encounter any more problems, just let me know. I'll try to answer as soon as possible.

Hi, So I played the game later but it was not working so I had to follow the steps to start it again, maybe look into what the problem is, I will be happy to help.l

Thx @GTPang, help and suggestions are always welcome.


GCM registration is not ready with auth credentials

GCM registration is not ready with auth credentials

@iamakashrao it is not clear what the issue is here.  When posting an issue please provide a full description of the problem, the minimal code used to reproduce the problem, and any relevant device logs.
I am going to close this issue as I can't help with what's here, but please re-open the issue if you are able to provide the information requested.

Hi,
I am facing the same issue in xamarin ios app. while launching the app it is getting crash.  and showing those errors-
You have enabled the CloudMessaging service in Developer Console, but it appears as though your Podfile is missing the line: 'pod "Google/CloudMessaging" or you may need to run pod update in your project directory.
2017-11-18   Failed to configure Google: Missing expected subspecs.
2017-11-18  GCM | GCM library version 1.1.4
2017-11-18  <GMR/INFO> App measurement v.2003000 started
2017-11-18 <GMR/INFO> To enable debug logging set the following application argument: -GMRDebugEnabled (see http://goo.gl/Y0Yjwu)
Resolved pending breakpoint at 'AppDelegate.cs:218,5' to void edTheSIS.iOS.AppDelegate.<>c.b__25_0 (bool approved, Foundation.NSError err) [0x00006].
Resolved pending breakpoint at 'AppDelegate.cs:220,4' to void edTheSIS.iOS.AppDelegate.<>c.b__25_0 (bool approved, Foundation.NSError err) [0x00012].
2017-11-18 14:12:53.747 edTheSIS.iOS[339:] <GMR/INFO> App measurement enabled
Thread started:  #7
2017-11-18 14:13:01.033: GCM | GCM registration is not ready with auth credentials
2017-11-18 14:13:05.239 edTheSIS.iOS[339:84837] critical: Stacktrace:
Please help how to solve it


Firestore client does not retry on contention errors

Current behavior
We are using Google cloud functions in combination with Firestore. When multiple, in this example 2, cloud function instances attempt to process different data on the same documents within a transaction 1 of the instances throws a contention error. This is inline with what is documented here.
Expected behavior
Instance A & B both read document X inside of a transaction. Instance A updates document X before instance B can commit its changes. The expected behavior would be for the transaction on instance B to be retried because it cannot commit its changes due to the X being a "dirty read".
Environment details

OS: Ubuntu 19.10
Node.js version: 10.18.0
npm version:6.12
@google-cloud/firestore version: 2.6.1

Steps to reproduce
Even though we dont have clear reproduction steps, but after some investigation of the code,  the culprit is seems clear.
Looking at this line in the code, it looks like contention caused inside of the updateFunction for example caused by reading a document, will never trigger a retry.
Additional information
Below is a log output of 2 functions "colliding" and no retry being triggered.
The logs have been sanitized by removing all project references, document structures and data being sent over the wire.

Logs
d82a0kxaae6u - Firestore (2.6.1) 2019-12-17T15:41:47.651Z xqgri [Firestore.readStream]: Sending request: {\"database\":\"projects/<OBSCURED>/databases/(default)\",\"transaction\":{\"type\":\"Buffer\",\"data\":[OBSCURED]},\"documents\":[\"projects/<OBSCURED>/databases/(default)/documents/<OBSCURED>\"]}

d82a0kxaae6u - Firestore (2.6.1) 2019-12-17T15:41:47.651Z NA6v7 [Firestore.readStream]: Sending request: {\"parent\":\"projects/<OBSCURED>/databases/(default)/documents/<OBSCURED>\",\"structuredQuery\":{\"from\":[OBSCURED]},\"transaction\":{\"type\":\"Buffer\",\"data\":[OBSCURED]}

d82a0kxaae6u - Firestore (2.6.1) 2019-12-17T15:41:47.653Z Zajdo [Firestore.readStream]: Sending request: {\"parent\":\"projects/<OBSCURED>/databases/(default)/documents/<OBSCURED>\",\"structuredQuery\":{\"from\":[OBSCURED]},\"transaction\":{\"type\":\"Buffer\",\"data\":[OBSCURED]}}

d82a0kxaae6u - Firestore (2.6.1) 2019-12-17T15:41:47.783Z xqgri [Firestore.readStream]: Received response: {\"transaction\":{\"type\":\"Buffer\",\"data\":[]},\"readTime\":{\"seconds\":\"1576597307\",\"nanos\":697669000},\"found\":{OBSCURED},\"name\":\"projects/<OBSCURED>/databases/(default)/documents/<OBSCURED>\",\"createTime\":{\"seconds\":\"1576597302\",\"nanos\":737511000},\"updateTime\":{\"seconds\":\"1576597302\",\"nanos\":737511000}},\"result\":\"found\"}

d82a0kxaae6u - Firestore (2.6.1) 2019-12-17T15:41:47.783Z xqgri [Firestore._initializeStream]: Releasing stream

d82a0kxaae6u - Firestore (2.6.1) 2019-12-17T15:41:47.784Z xqgri [Firestore.getAll_]: Received document: projects/<OBSCURED>/databases/(default)/documents/<OBSCURED>

d82a0kxaae6u - Firestore (2.6.1) 2019-12-17T15:41:47.784Z xqgri [Firestore._initializeStream]: Received stream end

d82a0kxaae6u - Firestore (2.6.1) 2019-12-17T15:41:47.784Z xqgri [Firestore.getAll_]: Received 1 results

d82a0kxaae6u - Firestore (2.6.1) 2019-12-17T15:41:47.785Z xqgri [Firestore._initializeStream]: Forwarding stream close

d82a0kxaae6u - Firestore (2.6.1) 2019-12-17T15:41:47.785Z xqgri [Firestore._initializeStream]: Received stream end

d82a0kxaae6u - Firestore (2.6.1) 2019-12-17T15:41:47.785Z xqgri [Firestore.getAll_]: Received 1 results

90fwt868bz2k - Firestore (2.6.1) 2019-12-17T15:41:47.813Z YzliZ [Firestore.readStream]: Received response: {\"transaction\":{\"type\":\"Buffer\",\"data\":[]},\"readTime\":{\"seconds\":\"1576597307\",\"nanos\":746009000},\"found\":{OBSCURED},\"name\":\"projects/<OBSCURED>/databases/(default)/documents/<OBSCURED>\",\"createTime\":{\"seconds\":\"1576597302\",\"nanos\":737511000},\"updateTime\":{\"seconds\":\"1576597302\",\"nanos\":737511000}},\"result\":\"found\"}

90fwt868bz2k - Firestore (2.6.1) 2019-12-17T15:41:47.813Z YzliZ [Firestore._initializeStream]: Releasing stream

90fwt868bz2k - Firestore (2.6.1) 2019-12-17T15:41:47.814Z YzliZ [Firestore.getAll_]: Received document: projects/<OBSCURED>/databases/(default)/documents/<OBSCURED>

90fwt868bz2k - Firestore (2.6.1) 2019-12-17T15:41:47.815Z 6NU5q [Firestore.readStream]: Received response: {\"document\":{\"fields\":{OBSCURED},\"readTime\":{\"seconds\":\"1576597307\",\"nanos\":746009000},\"skippedResults\":0}

90fwt868bz2k - Firestore (2.6.1) 2019-12-17T15:41:47.888Z 6NU5q [Firestore._initializeStream]: Releasing stream

90fwt868bz2k - Firestore (2.6.1) 2019-12-17T15:41:47.890Z YzliZ [Firestore._initializeStream]: Received stream end

90fwt868bz2k - Firestore (2.6.1) 2019-12-17T15:41:47.890Z YzliZ [Firestore.getAll_]: Received 1 results

90fwt868bz2k - Firestore (2.6.1) 2019-12-17T15:41:47.891Z 6NU5q [Firestore._initializeStream]: Received stream end

90fwt868bz2k - Firestore (2.6.1) 2019-12-17T15:41:47.892Z YzliZ [WriteBatch.commit]: Sending 2 writes

90fwt868bz2k - Firestore (2.6.1) 2019-12-17T15:41:47.892Z YzliZ [ClientPool.acquire]: Re-using existing client with 100 remaining operations

90fwt868bz2k - Firestore (2.6.1) 2019-12-17T15:41:47.892Z YzliZ [Firestore._initializeStream]: Forwarding stream close

90fwt868bz2k - Firestore (2.6.1) 2019-12-17T15:41:47.892Z YzliZ [Firestore._initializeStream]: Received stream end

90fwt868bz2k - Firestore (2.6.1) 2019-12-17T15:41:47.893Z YzliZ [Firestore.getAll_]: Received 1 results

90fwt868bz2k - Firestore (2.6.1) 2019-12-17T15:41:47.893Z 6NU5q [Firestore._initializeStream]: Forwarding stream close

90fwt868bz2k - Firestore (2.6.1) 2019-12-17T15:41:47.893Z 6NU5q [Firestore._initializeStream]: Received stream end

90fwt868bz2k - Firestore (2.6.1) 2019-12-17T15:41:47.895Z YzliZ [Firestore.request]: Sending request: {\"database\":\"projects/<OBSCURED>/databases/(default)\",\"writes\":[{\"update\":{\"name\":\"projects/<OBSCURED>/databases/(default)/documents/<OBSCURED>\",\"fields\":{<OBSCURED>},{\"update\":{\"name\":\"projects/<OBSCURED>/databases/(default)/<path2>\",\"fields\":{<OBSCURED>},\"updateMask\":{\"fieldPaths\":[OBSCURED]},\"currentDocument\":{\"exists\":true}}],\"transaction\":{\"type\":\"Buffer\",\"data\":[OBSCURED]}

d82a0kxaae6u - Firestore (2.6.1) 2019-12-17T15:41:48.180Z Zajdo [Firestore._initializeStream]: Received stream error: { Error: 10 ABORTED: Too much contention on these documents. Please try again.\n at callErrorFromStatus (/srv/functions/node_modules/google-gax/node_modules/@grpc/grpc-js/build/src/call.js:30:26)\n at Http2CallStream.call.on (/srv/functions/node_modules/google-gax/node_modules/@grpc/grpc-js/build/src/call.js:79:34)\n at Http2CallStream.emit (events.js:194:15)\n at Http2CallStream.EventEmitter.emit (domain.js:459:23)\n at process.nextTick (/srv/functions/node_modules/google-gax/node_modules/@grpc/grpc-js/build/src/call-stream.js:75:22)\n at process._tickCallback (internal/process/next_tick.js:61:11)\n code: 10,\n details: 'Too much contention on these documents. Please try again.',\n metadata: Metadata { internalRepr: Map {}, options: {} } }

d82a0kxaae6u - Firestore (2.6.1) 2019-12-17T15:41:48.180Z Zajdo [Firestore._initializeStream]: Received initial error: { Error: 10 ABORTED: Too much contention on these documents. Please try again.\n at callErrorFromStatus (/srv/functions/node_modules/google-gax/node_modules/@grpc/grpc-js/build/src/call.js:30:26)\n at Http2CallStream.call.on (/srv/functions/node_modules/google-gax/node_modules/@grpc/grpc-js/build/src/call.js:79:34)\n at Http2CallStream.emit (events.js:194:15)\n at Http2CallStream.EventEmitter.emit (domain.js:459:23)\n at process.nextTick (/srv/functions/node_modules/google-gax/node_modules/@grpc/grpc-js/build/src/call-stream.js:75:22)\n at process._tickCallback (internal/process/next_tick.js:61:11)\n code: 10,\n details: 'Too much contention on these documents. Please try again.',\n metadata: Metadata { internalRepr: Map {}, options: {} } }

d82a0kxaae6u - Firestore (2.6.1) 2019-12-17T15:41:48.180Z Zajdo [Firestore._retry]: Request failed with unrecoverable error: { Error: 10 ABORTED: Too much contention on these documents. Please try again.\n at callErrorFromStatus (/srv/functions/node_modules/google-gax/node_modules/@grpc/grpc-js/build/src/call.js:30:26)\n at Http2CallStream.call.on (/srv/functions/node_modules/google-gax/node_modules/@grpc/grpc-js/build/src/call.js:79:34)\n at Http2CallStream.emit (events.js:194:15)\n at Http2CallStream.EventEmitter.emit (domain.js:459:23)\n at process.nextTick (/srv/functions/node_modules/google-gax/node_modules/@grpc/grpc-js/build/src/call-stream.js:75:22)\n at process._tickCallback (internal/process/next_tick.js:61:11)\n code: 10,\n details: 'Too much contention on these documents. Please try again.',\n metadata: Metadata { internalRepr: Map {}, options: {} } }

d82a0kxaae6u - Firestore (2.6.1) 2019-12-17T15:41:48.181Z xqgri [Firestore.runTransaction]: Rolling back transaction after callback error: { error:\n { Error: 10 ABORTED: Too much contention on these documents. Please try again.\n at callErrorFromStatus (/srv/functions/node_modules/google-gax/node_modules/@grpc/grpc-js/build/src/call.js:30:26)\n at Http2CallStream.call.on (/srv/functions/node_modules/google-gax/node_modules/@grpc/grpc-js/build/src/call.js:79:34)\n at Http2CallStream.emit (events.js:194:15)\n at Http2CallStream.EventEmitter.emit (domain.js:459:23)\n at process.nextTick (/srv/functions/node_modules/google-gax/node_modules/@grpc/grpc-js/build/src/call-stream.js:75:22)\n at process._tickCallback (internal/process/next_tick.js:61:11)\n code: 10,\n details: 'Too much contention on these documents. Please try again.',\n metadata: Metadata { internalRepr: Map {}, options: {} } },\n hooks:\n { abort: [], failure: [ [Function] ], success: [ [Function] ] } }

d82a0kxaae6u - Firestore (2.6.1) 2019-12-17T15:41:48.181Z xqgri [ClientPool.acquire]: Re-using existing client with 99 remaining operations

d82a0kxaae6u - Firestore (2.6.1) 2019-12-17T15:41:48.182Z NA6v7 [Firestore._initializeStream]: Received stream error: { Error: 10 ABORTED: Too much contention on these documents. Please try again.\n at callErrorFromStatus (/srv/functions/node_modules/google-gax/node_modules/@grpc/grpc-js/build/src/call.js:30:26)\n at Http2CallStream.call.on (/srv/functions/node_modules/google-gax/node_modules/@grpc/grpc-js/build/src/call.js:79:34)\n at Http2CallStream.emit (events.js:194:15)\n at Http2CallStream.EventEmitter.emit (domain.js:459:23)\n at process.nextTick (/srv/functions/node_modules/google-gax/node_modules/@grpc/grpc-js/build/src/call-stream.js:75:22)\n at process._tickCallback (internal/process/next_tick.js:61:11)\n code: 10,\n details: 'Too much contention on these documents. Please try again.',\n metadata: Metadata { internalRepr: Map {}, options: {} } }

d82a0kxaae6u - Firestore (2.6.1) 2019-12-17T15:41:48.183Z NA6v7 [Firestore._initializeStream]: Received initial error: { Error: 10 ABORTED: Too much contention on these documents. Please try again.\n at callErrorFromStatus (/srv/functions/node_modules/google-gax/node_modules/@grpc/grpc-js/build/src/call.js:30:26)\n at Http2CallStream.call.on (/srv/functions/node_modules/google-gax/node_modules/@grpc/grpc-js/build/src/call.js:79:34)\n at Http2CallStream.emit (events.js:194:15)\n at Http2CallStream.EventEmitter.emit (domain.js:459:23)\n at process.nextTick (/srv/functions/node_modules/google-gax/node_modules/@grpc/grpc-js/build/src/call-stream.js:75:22)\n at process._tickCallback (internal/process/next_tick.js:61:11)\n code: 10,\n details: 'Too much contention on these documents. Please try again.',\n metadata: Metadata { internalRepr: Map {}, options: {} } }

d82a0kxaae6u - Firestore (2.6.1) 2019-12-17T15:41:48.183Z NA6v7 [Firestore._retry]: Request failed with unrecoverable error: { Error: 10 ABORTED: Too much contention on these documents. Please try again.\n at callErrorFromStatus (/srv/functions/node_modules/google-gax/node_modules/@grpc/grpc-js/build/src/call.js:30:26)\n at Http2CallStream.call.on (/srv/functions/node_modules/google-gax/node_modules/@grpc/grpc-js/build/src/call.js:79:34)\n at Http2CallStream.emit (events.js:194:15)\n at Http2CallStream.EventEmitter.emit (domain.js:459:23)\n at process.nextTick (/srv/functions/node_modules/google-gax/node_modules/@grpc/grpc-js/build/src/call-stream.js:75:22)\n at process._tickCallback (internal/process/next_tick.js:61:11)\n code: 10,\n details: 'Too much contention on these documents. Please try again.',\n metadata: Metadata { internalRepr: Map {}, options: {} } }

90fwt868bz2k - Firestore (2.6.1) 2019-12-17T15:41:48.189Z YzliZ [Firestore.request]: Received response: {\"writeResults\":[{\"transformResults\":[],\"updateTime\":{\"seconds\":\"1576597308\",\"nanos\":116169000}},{\"transformResults\":[],\"updateTime\":{\"seconds\":\"1576597308\",\"nanos\":116169000}}],\"commitTime\":{\"seconds\":\"1576597308\",\"nanos\":116169000}}

d82a0kxaae6u - Firestore (2.6.1) 2019-12-17T15:41:48.214Z xqgri [Firestore.request]: Sending request: {\"database\":\"projects/<OBSCURED>/databases/(default)\",\"transaction\":{\"type\":\"Buffer\",\"data\":[OBSCURED]}}

d82a0kxaae6u - Firestore (2.6.1) 2019-12-17T15:41:48.341Z xqgri [Firestore.request]: Received response: {}

@mad-it Thanks for filing this issue. We currently retry transaction only when the commit fails. Our assumption is that any error that occurs within a transaction block is thrown by the user with the intent to abort the transaction. As shown in your logs, that logic is a little bit oversimplified. We will update the client to ignore errors during document reads. Please bear with us though as we are approaching the holidays and will not be able to address this beforehand.

This will be part of the 3.3 release.

@schmidt-sebastian Thanks for the fix, it looks like its actually retrying now! :tada:
It seems that there is still an issue tho. Ran a trace once again to verify what is happening and it seems that the transaction is retried with the exponential backoff introduced in https://github.com/googleapis/nodejs-firestore/pull/847 but we are getting contention on initializing the transaction.
Added some sanitized logs.

Logs
Firestore (3.3.2) 2020-01-07T12:50:06.089Z EJrXY [ClientPool.acquire]: Re-using existing client with 100 remaining operations
Firestore (3.3.2) 2020-01-07T12:50:06.089Z EJrXY [ClientPool.acquire]: Re-using existing client with 100 remaining operations
Firestore (3.3.2) 2020-01-07T12:50:06.089Z EJrXY [Firestore.request]: Sending request: {"database":"projects/projectId/databases/(default)"}
Firestore (3.3.2) 2020-01-07T12:50:06.225Z EJrXY [Firestore.request]: Received response: {"transaction":{"type":"Buffer","data":[]}}
{"data":{"message":"Transaction started."},"severity":"INFO"}
{"data":{"message":"Getting snapshots."},"severity":"INFO"}
Firestore (3.3.2) 2020-01-07T12:50:06.439Z EJrXY [ClientPool.acquire]: Re-using existing client with 100 remaining operations
Firestore (3.3.2) 2020-01-07T12:50:06.439Z EJrXY [ClientPool.acquire]: Re-using existing client with 100 remaining operations
Firestore (3.3.2) 2020-01-07T12:50:06.439Z PmK0q [ClientPool.acquire]: Re-using existing client with 99 remaining operations
Firestore (3.3.2) 2020-01-07T12:50:06.440Z PmK0q [ClientPool.acquire]: Re-using existing client with 99 remaining operations
Firestore (3.3.2) 2020-01-07T12:50:06.447Z ZaUED [ClientPool.acquire]: Re-using existing client with 98 remaining operations
Firestore (3.3.2) 2020-01-07T12:50:06.447Z ZaUED [ClientPool.acquire]: Re-using existing client with 98 remaining operations
Firestore (3.3.2) 2020-01-07T12:50:06.448Z EJrXY [Firestore.requestStream]: Sending request: {"database":"projects/projectId/databases/(default)","transaction":{"type":"Buffer","data":[]},"documents":["projects/projectId/databases/(default)/<documentPath>"]}
Firestore (3.3.2) 2020-01-07T12:50:06.448Z PmK0q [Firestore.requestStream]: Sending request: {"parent":"projects/projectId/databases/(default)/<documentPath>","structuredQuery":{"from":[{}],"where":{"fieldFilter":{}},"transaction":{"type":"Buffer","data":[xxx]}}
Firestore (3.3.2) 2020-01-07T12:50:06.458Z ZaUED [Firestore.requestStream]: Sending request: {"parent":"projects/projectId/databases/(default)/<documentPath>","structuredQuery":{"from":[],"where":{}}},"transaction":{"type":"Buffer","data":[xxx]}}
Firestore (3.3.2) 2020-01-07T12:50:06.593Z PmK0q [Firestore.requestStream]: Received response: {"document":null,"transaction":{"type":"Buffer","data":[]},"readTime":{"seconds":"1578401406","nanos":531068000},"skippedResults":0}
Firestore (3.3.2) 2020-01-07T12:50:06.593Z PmK0q [Firestore._initializeStream]: Releasing stream
Firestore (3.3.2) 2020-01-07T12:50:06.595Z PmK0q [Firestore._initializeStream]: Received stream end
Firestore (3.3.2) 2020-01-07T12:50:06.612Z ZaUED [Firestore.requestStream]: Received response: {"document":{},"name":"projects/projectId/databases/(default)/<documentPath2>","createTime":{"seconds":"1555019896","nanos":853245000},"updateTime":{"seconds":"1578143084","nanos":250413000}},"transaction":{"type":"Buffer","data":[xxx]},"readTime":{"seconds":"1578401406","nanos":539724000},"skippedResults":0}
Firestore (3.3.2) 2020-01-07T12:50:06.612Z ZaUED [Firestore._initializeStream]: Releasing stream
Firestore (3.3.2) 2020-01-07T12:50:06.615Z ZaUED [Firestore._initializeStream]: Received stream end
Firestore (3.3.2) 2020-01-07T12:50:07.228Z EJrXY [Firestore._initializeStream]: Received initial error: { Error: 10 ABORTED: Too much contention on these documents. Please try again.
    at callErrorFromStatus (/srv/functions/node_modules/@grpc/grpc-js/src/call.ts:79:24)
    at Http2CallStream.call.on (/srv/functions/node_modules/@grpc/grpc-js/src/call.ts:132:28)
    at Http2CallStream.emit (events.js:194:15)
    at Http2CallStream.EventEmitter.emit (domain.js:459:23)
    at process.nextTick (/srv/functions/node_modules/@grpc/grpc-js/src/call-stream.ts:183:14)
    at process._tickCallback (internal/process/next_tick.js:61:11)
  code: 10,
  details: 'Too much contention on these documents. Please try again.',
  metadata: Metadata { internalRepr: Map {}, options: {} } }
Firestore (3.3.2) 2020-01-07T12:50:07.228Z EJrXY [Firestore._initializeStream]: Received stream end
Firestore (3.3.2) 2020-01-07T12:50:07.229Z EJrXY [Firestore._initializeStream]: Releasing stream
Firestore (3.3.2) 2020-01-07T12:50:07.229Z EJrXY [Firestore._retry]: Retrying request that failed with error: { Error: 10 ABORTED: Too much contention on these documents. Please try again.
    at callErrorFromStatus (/srv/functions/node_modules/@grpc/grpc-js/src/call.ts:79:24)
    at Http2CallStream.call.on (/srv/functions/node_modules/@grpc/grpc-js/src/call.ts:132:28)
    at Http2CallStream.emit (events.js:194:15)
    at Http2CallStream.EventEmitter.emit (domain.js:459:23)
    at process.nextTick (/srv/functions/node_modules/@grpc/grpc-js/src/call-stream.ts:183:14)
    at process._tickCallback (internal/process/next_tick.js:61:11)
  code: 10,
  details: 'Too much contention on these documents. Please try again.',
  metadata: Metadata { internalRepr: Map {}, options: {} } }
Firestore (3.3.2) 2020-01-07T12:50:07.229Z ##### [ExponentialBackoff.backoffAndWait]: Backing off for<PHONE_NUMBER>625104 ms (base delay: 1000 ms)
Firestore (3.3.2) 2020-01-07T12:50:07.746Z EJrXY [Firestore.requestStream]: Sending request: {"database":"projects/projectId/databases/(default)","transaction":{"type":"Buffer","data":[xxx]},"documents":["projects/projectId/databases/(default)/<documentPath>"]}
Firestore (3.3.2) 2020-01-07T12:50:07.904Z EJrXY [Firestore._initializeStream]: Received initial error: { Error: 10 ABORTED: Too much contention on these documents. Please try again.
    at callErrorFromStatus (/srv/functions/node_modules/@grpc/grpc-js/src/call.ts:79:24)
    at Http2CallStream.call.on (/srv/functions/node_modules/@grpc/grpc-js/src/call.ts:132:28)
    at Http2CallStream.emit (events.js:194:15)
    at Http2CallStream.EventEmitter.emit (domain.js:459:23)
    at process.nextTick (/srv/functions/node_modules/@grpc/grpc-js/src/call-stream.ts:183:14)
    at process._tickCallback (internal/process/next_tick.js:61:11)
  code: 10,
  details: 'Too much contention on these documents. Please try again.',
  metadata: Metadata { internalRepr: Map {}, options: {} } }
Firestore (3.3.2) 2020-01-07T12:50:07.904Z EJrXY [Firestore._initializeStream]: Received stream end
Firestore (3.3.2) 2020-01-07T12:50:07.904Z EJrXY [Firestore._initializeStream]: Releasing stream
Firestore (3.3.2) 2020-01-07T12:50:07.905Z EJrXY [Firestore._retry]: Retrying request that failed with error: { Error: 10 ABORTED: Too much contention on these documents. Please try again.
    at callErrorFromStatus (/srv/functions/node_modules/@grpc/grpc-js/src/call.ts:79:24)
    at Http2CallStream.call.on (/srv/functions/node_modules/@grpc/grpc-js/src/call.ts:132:28)
    at Http2CallStream.emit (events.js:194:15)
    at Http2CallStream.EventEmitter.emit (domain.js:459:23)
    at process.nextTick (/srv/functions/node_modules/@grpc/grpc-js/src/call-stream.ts:183:14)
    at process._tickCallback (internal/process/next_tick.js:61:11)
  code: 10,
  details: 'Too much contention on these documents. Please try again.',
  metadata: Metadata { internalRepr: Map {}, options: {} } }
Firestore (3.3.2) 2020-01-07T12:50:07.905Z ##### [ExponentialBackoff.backoffAndWait]: Backing off for 1420.5420701214282 ms (base delay: 1500 ms)
Firestore (3.3.2) 2020-01-07T12:50:09.326Z EJrXY [Firestore.requestStream]: Sending request: {"database":"projects/projectId/databases/(default)","transaction":{"type":"Buffer","data":[xxx]},"documents":["projects/projectId/databases/(default)/<documentPath>"]}
Firestore (3.3.2) 2020-01-07T12:50:09.464Z EJrXY [Firestore._initializeStream]: Received initial error: { Error: 10 ABORTED: Too much contention on these documents. Please try again.
    at callErrorFromStatus (/srv/functions/node_modules/@grpc/grpc-js/src/call.ts:79:24)
    at Http2CallStream.call.on (/srv/functions/node_modules/@grpc/grpc-js/src/call.ts:132:28)
    at Http2CallStream.emit (events.js:194:15)
    at Http2CallStream.EventEmitter.emit (domain.js:459:23)
    at process.nextTick (/srv/functions/node_modules/@grpc/grpc-js/src/call-stream.ts:183:14)
    at process._tickCallback (internal/process/next_tick.js:61:11)
  code: 10,
  details: 'Too much contention on these documents. Please try again.',
  metadata: Metadata { internalRepr: Map {}, options: {} } }
Firestore (3.3.2) 2020-01-07T12:50:09.464Z EJrXY [Firestore._initializeStream]: Received stream end
Firestore (3.3.2) 2020-01-07T12:50:09.465Z EJrXY [Firestore._initializeStream]: Releasing stream
Firestore (3.3.2) 2020-01-07T12:50:09.465Z EJrXY [Firestore._retry]: Retrying request that failed with error: { Error: 10 ABORTED: Too much contention on these documents. Please try again.
    at callErrorFromStatus (/srv/functions/node_modules/@grpc/grpc-js/src/call.ts:79:24)
    at Http2CallStream.call.on (/srv/functions/node_modules/@grpc/grpc-js/src/call.ts:132:28)
    at Http2CallStream.emit (events.js:194:15)
    at Http2CallStream.EventEmitter.emit (domain.js:459:23)
    at process.nextTick (/srv/functions/node_modules/@grpc/grpc-js/src/call-stream.ts:183:14)
    at process._tickCallback (internal/process/next_tick.js:61:11)
  code: 10,
  details: 'Too much contention on these documents. Please try again.',
  metadata: Metadata { internalRepr: Map {}, options: {} } }
Firestore (3.3.2) 2020-01-07T12:50:09.465Z ##### [ExponentialBackoff.backoffAndWait]: Backing off for 2587.952641330125 ms (base delay: 2250 ms)
Firestore (3.3.2) 2020-01-07T12:50:12.054Z EJrXY [Firestore.requestStream]: Sending request: {"database":"projects/projectId/databases/(default)","transaction":{"type":"Buffer","data":[xxx]},"documents":["projects/projectId/databases/(default)/<documentPath>"]}
Firestore (3.3.2) 2020-01-07T12:50:12.191Z EJrXY [Firestore._initializeStream]: Received initial error: { Error: 10 ABORTED: Too much contention on these documents. Please try again.
    at callErrorFromStatus (/srv/functions/node_modules/@grpc/grpc-js/src/call.ts:79:24)
    at Http2CallStream.call.on (/srv/functions/node_modules/@grpc/grpc-js/src/call.ts:132:28)
    at Http2CallStream.emit (events.js:194:15)
    at Http2CallStream.EventEmitter.emit (domain.js:459:23)
    at process.nextTick (/srv/functions/node_modules/@grpc/grpc-js/src/call-stream.ts:183:14)
    at process._tickCallback (internal/process/next_tick.js:61:11)
  code: 10,
  details: 'Too much contention on these documents. Please try again.',
  metadata: Metadata { internalRepr: Map {}, options: {} } }
Firestore (3.3.2) 2020-01-07T12:50:12.191Z EJrXY [Firestore._initializeStream]: Received stream end
Firestore (3.3.2) 2020-01-07T12:50:12.191Z EJrXY [Firestore._initializeStream]: Releasing stream
Firestore (3.3.2) 2020-01-07T12:50:12.192Z EJrXY [Firestore._retry]: Retrying request that failed with error: { Error: 10 ABORTED: Too much contention on these documents. Please try again.
    at callErrorFromStatus (/srv/functions/node_modules/@grpc/grpc-js/src/call.ts:79:24)
    at Http2CallStream.call.on (/srv/functions/node_modules/@grpc/grpc-js/src/call.ts:132:28)
    at Http2CallStream.emit (events.js:194:15)
    at Http2CallStream.EventEmitter.emit (domain.js:459:23)
    at process.nextTick (/srv/functions/node_modules/@grpc/grpc-js/src/call-stream.ts:183:14)
    at process._tickCallback (internal/process/next_tick.js:61:11)
  code: 10,
  details: 'Too much contention on these documents. Please try again.',
  metadata: Metadata { internalRepr: Map {}, options: {} } }
Firestore (3.3.2) 2020-01-07T12:50:12.192Z ##### [ExponentialBackoff.backoffAndWait]: Backing off for 3871.6061597913904 ms (base delay: 3375 ms)
Firestore (3.3.2) 2020-01-07T12:50:16.065Z EJrXY [Firestore.requestStream]: Sending request: {"database":"projects/projectId/databases/(default)","transaction":{"type":"Buffer","data":[xxx]},"documents":["projects/projectId/databases/(default)/<documentPath>"]}
Firestore (3.3.2) 2020-01-07T12:50:16.188Z EJrXY [Firestore._initializeStream]: Received initial error: { Error: 10 ABORTED: Too much contention on these documents. Please try again.
    at callErrorFromStatus (/srv/functions/node_modules/@grpc/grpc-js/src/call.ts:79:24)
    at Http2CallStream.call.on (/srv/functions/node_modules/@grpc/grpc-js/src/call.ts:132:28)
    at Http2CallStream.emit (events.js:194:15)
    at Http2CallStream.EventEmitter.emit (domain.js:459:23)
    at process.nextTick (/srv/functions/node_modules/@grpc/grpc-js/src/call-stream.ts:183:14)
    at process._tickCallback (internal/process/next_tick.js:61:11)
  code: 10,
  details: 'Too much contention on these documents. Please try again.',
  metadata: Metadata { internalRepr: Map {}, options: {} } }
Firestore (3.3.2) 2020-01-07T12:50:16.189Z EJrXY [Firestore._initializeStream]: Received stream end
Firestore (3.3.2) 2020-01-07T12:50:16.189Z EJrXY [Firestore._initializeStream]: Releasing stream
Firestore (3.3.2) 2020-01-07T12:50:16.190Z EJrXY [Firestore._retry]: Request failed with error: { Error: 10 ABORTED: Too much contention on these documents. Please try again.
    at callErrorFromStatus (/srv/functions/node_modules/@grpc/grpc-js/src/call.ts:79:24)
    at Http2CallStream.call.on (/srv/functions/node_modules/@grpc/grpc-js/src/call.ts:132:28)
    at Http2CallStream.emit (events.js:194:15)
    at Http2CallStream.EventEmitter.emit (domain.js:459:23)
    at process.nextTick (/srv/functions/node_modules/@grpc/grpc-js/src/call-stream.ts:183:14)
    at process._tickCallback (internal/process/next_tick.js:61:11)
  code: 10,
  details: 'Too much contention on these documents. Please try again.',
  metadata: Metadata { internalRepr: Map {}, options: {} } }
Firestore (3.3.2) 2020-01-07T12:50:16.193Z EJrXY [Firestore.runTransaction]: Rolling back transaction after callback error: { error:
   { Error: 10 ABORTED: Too much contention on these documents. Please try again.
       at callErrorFromStatus (/srv/functions/node_modules/@grpc/grpc-js/src/call.ts:79:24)
       at Http2CallStream.call.on (/srv/functions/node_modules/@grpc/grpc-js/src/call.ts:132:28)
       at Http2CallStream.emit (events.js:194:15)
       at Http2CallStream.EventEmitter.emit (domain.js:459:23)
       at process.nextTick (/srv/functions/node_modules/@grpc/grpc-js/src/call-stream.ts:183:14)
       at process._tickCallback (internal/process/next_tick.js:61:11)
     code: 10,
     details: 'Too much contention on these documents. Please try again.',
     metadata: Metadata { internalRepr: Map {}, options: {} } },
Firestore (3.3.2) 2020-01-07T12:50:16.193Z EJrXY [ClientPool.acquire]: Re-using existing client with 100 remaining operations
Firestore (3.3.2) 2020-01-07T12:50:16.193Z EJrXY [ClientPool.acquire]: Re-using existing client with 100 remaining operations
Firestore (3.3.2) 2020-01-07T12:50:16.195Z EJrXY [Firestore.request]: Sending request: {"database":"projects/projectId/databases/(default)","transaction":{"type":"Buffer","data":[xxx]}}
Firestore (3.3.2) 2020-01-07T12:50:16.333Z EJrXY [Firestore.request]: Received response: {}

@mad-it What is the write rate for the document in question? It is a bit surprising to me that the contention issue exists for so long. We may to investigate with the backend team why your transactions are failing even with retry.
The actual failure that you see is expected though. We only retry five times, after which we will forward the last error to the API surface.

@schmidt-sebastian the document in question is only written to by 1 or 2 instances at most. But the issue does not seem to be the document which is being written to, it seems to be that Firestore cannot acquire a lock( assumption here) to start a transaction.
As you can see in the log I purposely left a log line stating "Transaction started" which is the first thing that happened in the so called "updateFunction".
As you can see in the logs, that line is only printed once meaning it never retries the provided "updateFunction" because it fails on reinitializing the transaction scope.

Do you mind filing a customer support request that contains your project ID, the document path and approximate timestamps? https://cloud.google.com/support/
I am not able to look at the backend logs, but our support team can on request.

We have received all necessary information.

Any new information come to light regarding this issue?

Our backend team took a look at the request logs. It sounds like we didn't really solve the problem yet.
What they are seeing is the following sequence of events:

BeginTransaction
Read (fail)
Read (fail)
Read (fail)
Read (fail)
Read (fail)

This re-reading is done because we changed the configuration. The retries are now happening, but hidden from our SDK and in the networking layer. Instead, we need to modify the SDK to do these retries ourselves so we can rollback the previous transaction. This would then look as such:

BeginTransaction
Read (fail)
Rollback
BeginTransaction
Read (success)

Please bear with us as we make the necessary changes.


Allow to have the fade-in effect only on main page

Why do you thing this change is needed?

@er-vin I agree with you. The fade effect is nice on the home page but unnecessary on content page. I propose to only use it on the main page and don't add a config option for this.

I'd prefer a config option, as not all users may have only the first page as a landing page. Otherwise :+1:

@er-vin Would you give this a rebase?

Sure, would gladely give it a shot, I'm super busy work wise for the coming two week though, so please be a bit patient.

Alright, now rebased.
Man... porting my website to the new master isn't a walk in the park, still have a couple of things broken. I guess you can expect a couple more pull requests. ;-)

Thank you @er-vin for the contribution!


Drawing with canvas fails to round lines

Setting
window.L_PREFER_CANVAS = true;

to gain some performance using canvas I got this result:

As you can see those island and some other corners are too sharp so I checked leaflet lib and found:
ctx.lineCap = 'round';
ctx.lineJoin = 'round';

Unfortunately this is not currently working, go to (nearly) line 5118 and change "_drawPath" function to this (just for testing, note the alert):
_drawPath: function () {
	var i, j, len, len2, point, drawMethod;

	this._ctx.beginPath();

	for (i = 0, len = this._parts.length; i < len; i++) {
		for (j = 0, len2 = this._parts[i].length; j < len2; j++) {
			point = this._parts[i][j];
			drawMethod = (j === 0 ? 'move' : 'line') + 'To';
if(drawMethod == 'lineTo'){
    alert(this._ctx.lineJoin);
}
			this._ctx[drawMethod](point.x, point.y);
		}
		// TODO refactor ugly hack
		if (this instanceof L.Polygon) {
			this._ctx.closePath();
		}
	}
}

Then if you run this modified code you'll get "miter" in the alert screen but It should be "round". To workaround this bug you can fill lineCap and lineJoin again with correct values but Im not sure if it is the correct approach for the issue:
_drawPath: function () {
	var i, j, len, len2, point, drawMethod;

	this._ctx.beginPath();
	this._ctx.lineCap  = 'round';
	this._ctx.lineJoin = 'round';

	for (i = 0, len = this._parts.length; i < len; i++) {
		for (j = 0, len2 = this._parts[i].length; j < len2; j++) {
			point = this._parts[i][j];
			drawMethod = (j === 0 ? 'move' : 'line') + 'To';

			this._ctx[drawMethod](point.x, point.y);
		}
		// TODO refactor ugly hack
		if (this instanceof L.Polygon) {
			this._ctx.closePath();
		}
	}
}

Almost this solves the bug for me.

Thanks

Is this reproducible on master?

Seems fixed at first sight, may it only affect stable version.
Anyway window.L_PREFER_CANVAS = true; stopped working and I was unable to find some doc to enable it via params so I has to hack to code to enable it.
Thanks

@sombra2eternity there's a different syntax for this now. See debug/vector/vector2.html for an example.


Red alert has to be toggled with two head card swipes at the same time

Description

Red alert can only be triggered by two heads wiping their cards in a threshold of around a second, the card wippers has to be in separate directions so it actually requires coordination
Reproduction

Screenshots

Additional context

tfw CE is the only one alive

Same for ERT call imo. If an admin is online give them the choice to cancel the ERT call.


Replace web Server with Carbon UI Server

Replace web Server with Carbon UI Server

#https://github.com/wso2/product-apim/pull/1937

#https://github.com/wso2/product-apim/pull/1937


Adding globalData to ContentZone and Types interfaces

Two modifications have been made to the original code;

ContentZone.tsx now destructures globalData and adds it to the props object passed to the Agility Module component
globalData was added to the Types interfaces for ModuleProps, DynamicModuleProps and ContentZoneProps so that globalData can continue to be prop drilled down into the modules.

Purpose of PR
To allow global data to be pulled in at build time via GetStaticProps in [...slug].tsx in the root of your pages folder and passed into modules.

Looks awesome! Thank you - this will be included in an updated version today.


There is no documentation for some rules

Description
Four of the rules has no documentation.
Steps to Reproduce

Visit the links:

https://github.com/xjamundx/eslint-plugin-promise/blob/HEAD/docs/rules/no-promise-in-callback.md
https://github.com/xjamundx/eslint-plugin-promise/blob/HEAD/docs/rules/no-callback-in-promise.md
https://github.com/xjamundx/eslint-plugin-promise/blob/HEAD/docs/rules/avoid-new.md
https://github.com/xjamundx/eslint-plugin-promise/blob/HEAD/docs/rules/prefer-await-to-callbacks.md

Partially addressed in #215

Related discussion about the reasons for avoid-new: https://github.com/eslint-community/eslint-plugin-promise/issues/111

I agree that rules should be documented.


Can't ssh into raspiblitz after closing my terminal window.

I left my raspiblitz v1.3 syncing via torrent and then closed the terminal window on my mac.
When I returned a few hours later and tried to ssh in I got this:
Connection reset by <IP_ADDRESS> port 22
On the raspiblitz screen, it flashes this across the whole screen:
[18600.378472] EXT4-fs error (device sda1): ext4_find_entry: 1455: inode #2: comm sshd: reading directory 1block 0
Did an error occur or do I just have to wait until its fully sync'd before I can get back in?

Aew you using an RPI3 or 4? What power supply (what is the Amper output)?
This looks very much like a HDD error, possibly:

the most common is a problem is with the power supply, need > 3A -> use a good one from the shopping list or a Y-cable with external power or powered USB hub
faulty HDD - need to change an start fresh

You can asses the disk state connecting to  a Linux computer (usb booted Ubuntu fro example) or format it and run a surface check on you Mac.

I'm using a RPI4 and the suggested Official Raspberry Pi 4 Power Supply (USB-C).
I went ahead and plugged the disk into my Mac, erased its contents, and ran "First Aid" on it. It didn't report any errors. I'm going to reflash the SD card with v1.3 and try again.

Process:

I passed the hardware setup.
Proceeded to the Bitcoin node setup.
Entered name for the pi and passwords A & B.
Went to format the HDD:

*** Formatting the HDD ***
WARNING ALL DATA ON HDD WILL GET DELETED - CAN TAKE SOME TIME
Wait until you get a OK or FAIL
mke2fs 1.44.5 (15-Dec-2018)
/dev/sda1 contains a hfsplus file system labelled 'Untitled'
Creating filesystem with 244190208 4k blocks and 61054976 inodes
Filesystem UUID: f139afe9-9550-4af9-bea5-4acbda8cfccf
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848
Allocating group tables: done
Writing inode tables: done
Creating journal (262144 blocks): done
Writing superblocks and filesystem accounting information: done
format ext4 done - wait 6 secs
FAIL - was not able to format the HDD to ext4 with the name 'BLOCKCHAIN'
And now I'm not sure how to proceed.

After looking at #545 and seeing their voltage was ~1.2V and noticing mine is less than this, I need a better PSU.

First off the power supply is weak. I recommend you buy a new one. 1.2V is def not enough and the test shows your RPi CPU is throttling (slowed down) significantly in an attempt to compensate for the low voltage.


[Fix] commander :add status_changed when battery is low

battery low shows now in flight, good work! 👍


bead commands should also work in subfolders

Behavior should be same as with git. If I am inside a bead workspace, say input/data1, I should still be able to do bead status and bead input add.

5e4d3bd54bcb32d963cb148d1f43472a89b70567 should take care of this


Incorrect results from tfprof

I was profiling a few matrix multiplications with tfprof but couldn't make sense of the output. The per-op timing results are hard to believe to be true.
Code:
import tensorflow as tf
import tensorflow.contrib.tfprof as tfprof

dim = 6000
n = 5
with tf.device('/gpu:0'):
    X, Y, Z, _X, _Y = [], [], [], [], []
    for i in range(n):
        X.append(tf.random_uniform([dim, dim], 0, 10, name='X' + str(i)))
        Y.append(tf.random_uniform([dim, dim], 0, 10, name='Y' + str(i)))
        _X.append(tf.placeholder(dtype=tf.float32, shape=[dim, dim]))
        _Y.append(tf.placeholder(dtype=tf.float32, shape=[dim, dim]))
        Z.append(tf.matmul(_X[i], _Y[i]))
    W = tf.ones([dim, dim])
    for i in range(n):
        W = tf.matmul(W, Z[i])

sess = tf.Session(config=tf.ConfigProto(gpu_options=tf.GPUOptions(allow_growth=True)))
sess.run(tf.global_variables_initializer())
X_, Y_ = sess.run([X, Y])

run_metadata = tf.RunMetadata()
run_options = tf.RunOptions(trace_level=tf.RunOptions.FULL_TRACE)
W_ = sess.run(W,
              {_i: i_ for _i, i_ in zip(_X + _Y, X_ + Y_)},
              options=run_options,
              run_metadata=run_metadata)

tfprof.model_analyzer.print_model_analysis(
    tf.get_default_graph(),
    run_meta=run_metadata,
    tfprof_options=tfprof.model_analyzer.PRINT_ALL_TIMING_MEMORY)

Output:
_TFProfRoot (0B/1296.00MB, 0us/778.18ms)
  MatMul (144.00MB/144.00MB, 162.51ms/162.51ms)
  MatMul_1 (144.00MB/144.00MB, 145.03ms/145.03ms)
  MatMul_2 (144.00MB/144.00MB, 145.07ms/145.07ms)
  MatMul_3 (144.00MB/144.00MB, 162.69ms/162.69ms)
  MatMul_4 (144.00MB/144.00MB, 162.57ms/162.57ms)
  MatMul_5 (144.00MB/144.00MB, 241us/241us)
  MatMul_6 (144.00MB/144.00MB, 21us/21us)
  MatMul_7 (144.00MB/144.00MB, 16us/16us)
  MatMul_8 (144.00MB/144.00MB, 10us/10us)
  MatMul_9 (144.00MB/144.00MB, 19us/19us)
  ones (144.00MB/144.00MB, 6us/6us)

Graph:

As shown in the profiling output, MatMul_[0-4] take 1,000 -10,000x longer than MatMul_[5-9]. However, they are all matrix multiplications of the same size!
Environment info
Operating System: Ubuntu 14.04.5
Installed version of CUDA and cuDNN:
-rw-r--r-- 1 root root 556000 Mar  1 12:58 /usr/local/cuda/lib64/libcudadevrt.a
lrwxrwxrwx 1 root root     16 Mar  1 12:58 /usr/local/cuda/lib64/libcudart.so -> libcudart.so.8.0
lrwxrwxrwx 1 root root     19 Mar  1 12:58 /usr/local/cuda/lib64/libcudart.so.8.0 -> libcudart.so.8.0.61
-rwxr-xr-x 1 root root 415432 Mar  1 12:58 /usr/local/cuda/lib64/libcudart.so.8.0.61
-rw-r--r-- 1 root root 775162 Mar  1 12:58 /usr/local/cuda/lib64/libcudart_static.a

If installed from binary pip package, provide:

A link to the pip package you installed:
tensorflow_gpu-1.0.1-cp27-cp27mu-manylinux1_x86_64.whl

The output from python -c "import tensorflow; print(tensorflow.__version__)".
1.0.1

As a reference, I profile the same program with NVIDIA Visual Profiler. It shows that each matrix multiplication (MatMul_[0-9]) takes around 65-75us.
In comparison, tfprof doubles the amount of runtime of MatMul_[0-4] while counting that of MatMul_[5-9] almost as zero.

@panyx0718 would you mind taking a look at this?

Looking. It seems tfprof correctly reports the stats returned in RunMetadata. However, why RunMetadata (from tensorflow internal) gives such result is being investigated.

I looked into the tensorflow internals a bit deeper. The numbers gathered in gpu_tracer.cc (~ln 580) using CUPTI Activity API are consistent with NVIDIA Visual Profiler (NVVP). But these numbers are not used in RunMetadata.
I can see the GPU perf numbers being used in direct_session.cc (~ln 535) to build the cost model. But the annotated cost graph is not incorporated into RunMetadata or used by tfprof.
The numbers in RunMetadata are from executor.cc (~ln 1360) which are purely CPU-based. Thus, the numbers are actually GPU kernel launch time rather than kernel execution time.

@bowang Those numbers should be in the RunMetadata - but they will be shown as kernel times on a device with name "/gpu:0/stream...".  If you use the timings from the  "/gpu:0" device you will just see the time taken to enqueue the CUDA kernels  (i.e. the time spent in MatMulOp::Compute())
This is liekly to be a problem with tfprof, not the tracing.  I expect that the chrome timeline will show the correct behavior.  (if it doesn't then this is a TF bug!)

@prb12 Thanks for the explanation.
So looks like tfprof is tracking the MatMulOp::Compute(). It is actually the CPU kernel schedule time.
While the needed ones are the actually GPU execution time, which is in gpu:0/stream.
Another place I found is in the compute_cost in cost_graph, which can be propagated to Python via the:
config = tf.ConfigProto(
graph_options=tf.GraphOptions(build_cost_model=1))

@prb12 Just verified with chrome timeline where the GPU timing is correct under "/gpu:0/stream...".
@panyx0718  It would be very helpful to correct it in tfprof.

A fix has been submitted, will be released.

@panyx0718 Can you refer me to the commit that fixes this issue?

https://github.com/tensorflow/tensorflow/commit/404db0358aacc0fc2319fc333df4cc5bc0fc404a
On Tue, Mar 28, 2017 at 10:50 AM, Bo Wang<EMAIL_ADDRESS>wrote:

@panyx0718 https://github.com/panyx0718 Can you refer me to the commit
that fixes this issue?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tensorflow/tensorflow/issues/8569#issuecomment-289849860,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACwQe5iansiCjJJZuQ10ljnSy4Va5D1Lks5rqUh5gaJpZM4MjKHs
.

--
Thanks
Xin

Thanks @panyx0718

@panyx0718 I am seeing similar issue even after picking 404db03.
_TFProfRoot (0B/1584.00MB, 0us/1.72sec)
MatMul (144.00MB/144.00MB, 343.61ms/343.61ms)
MatMul_1 (144.00MB/144.00MB, 343.71ms/343.71ms)
MatMul_2 (144.00MB/144.00MB, 343.74ms/343.74ms)
MatMul_3 (144.00MB/144.00MB, 343.45ms/343.45ms)
MatMul_4 (144.00MB/144.00MB, 343.58ms/343.58ms)
MatMul_5 (144.00MB/144.00MB, 169us/169us)
MatMul_6 (144.00MB/144.00MB, 25us/25us)
MatMul_7 (144.00MB/144.00MB, 22us/22us)
MatMul_8 (144.00MB/144.00MB, 21us/21us)
MatMul_9 (144.00MB/144.00MB, 21us/21us)
ones (144.00MB/144.00MB, 5us/5us)

@jeevandev I might have re-introduced the problem during some recent changes. Let me take a look

I noticed the RunMetadata has format changes that break tfprof's assumptions.

Thanks for letting us know. I guess we can reopen the issue?

Sure, I'm fixing it.

@jeevandev I submitted a fix, might take a some time to release

Thank you. Can you pls point us to the commit?

d78a121
Can you try the latest version


Evmos chain retake fails

Restake fails with error signature verification failed; please verify account number (0) and chain-id (): unauthorized
There was an update at "2023-03-31", but since that restake works properly until "2023-04-05".

Hi

Restake fails with error signature verification failed; please verify account number (0) and chain-id (): unauthorized
There was an update at "2023-03-31", but since that restake works properly until "2023-04-05".

Hello @ekhvalov  A support ticket has been opened for you. Talk to a EVMOS Dev on the Live support page so that your issue can be looked into. CLICK HERE

Restake fails with error signature verification failed; please verify account number (0) and chain-id (): unauthorized
There was an update at "2023-03-31", but since that restake works properly until "2023-04-05".

Hello @ekhvalov A support ticket has been opened for you. Talk to a EVMOS Dev on the Live support page so that your issue can be looked into. CLICK HERE

Hello @RandyHarold Which ticket?

Restake fails with error signature verification failed; please verify account number (0) and chain-id (): unauthorized

There was an update at "2023-03-31", but since that restake works properly until "2023-04-05".

Hello @ekhvalov A support ticket has been opened for you. Talk to a EVMOS Dev on the Live support page so that your issue can be looked into. CLICK HERE

Hello @RandyHarold Which ticket?

You should chat visit the website to create a ticket with the Dev so your issues will be attend to

Ubiquitous scammers, damn them! 🤬

@ekhvalov sorry for the delays. So that error is a bit suspect - it suggests your script is unable to get some key information like the Chain ID, which shouldn't happen really. Are you seeing any other errors when you run the script? I'm assuming this is an error when running the script as a validator, rather than an error being shown in the restake.app UI?

@tombeynon Thanks for the answer. The error was fixed, so I'll close it.


Upgrade to Python3.

90% of changes is getting eager results of map(), which is otherwise lazy
in Python3 (represented by adhoc "map" object). Beyond that, there're
removals of types which are no longer in Python3 (long, unicode), and
literally the only noticeable change is to account for different AST
structure to encode function parameters.

As a follow up to #7, this patch updates Numpile to run on Python3.
I would recommend to keep Python2 version in a branch, just in case (for parties who may still be interested in Python2). In other words, to run:
git checkout master
git checkout -b python2
git push origin HEAD
git checkout master

before applying this patch.
Actually, a similar branch probably should have been created for the original llvmpy version too. It can be done now still:
git co -b llvmpy 931a1715f0f3e33e6b2f9e7defd93062b6fff2e3
git push origin HEAD

Thanks!

@sdiehl, Thanks for finding time to review and merge these patches! Any comments on the proposal to create python2 and/or llvmpy specific branches in the repo?


Bump grpc & netty version

cherry-pick 16cbf9c0142c20c29b71fb94bd59f049647aac79
cherry-pick the commit since the following security issue.

Bump grpc & netty version

We want to try netty io_uring feature
The new aws client we are going to introduce relies on newer version of netty
Current grpc & netty versions do not match. (https://github.com/grpc/grpc-java/blob/master/SECURITY.md)

N/A
pr-link: Alluxio/alluxio#17413 change-id: cid-8bfb171d1660c6da96977129b62b6b6640625f4c
What changes are proposed in this pull request?
Please outline the changes and how this PR fixes the issue.
Why are the changes needed?
Please clarify why the changes are needed. For instance,

If you propose a new API, clarify the use case for a new API.
If you fix a bug, describe the bug.

Does this PR introduce any user facing changes?
Please list the user-facing changes introduced by your change, including

change in user-facing APIs
addition or removal of property keys
webui

cc @Xenorith @beinan

alluxio-bot, merge this please.

alluxio-bot, merge this please.

^^ this PR is a critical dependency bump. please avoid cherry picking this PR to the release branch for the time being.


Extensions > install and enable vscode-smoketest-check extension smoke test sometimes fails

Example runs:

https://dev.azure.com/monacotools/Monaco/_build/results?buildId=267204&view=results
https://dev.azure.com/monacotools/Monaco/_build/results?buildId=267252&view=results
https://dev.azure.com/monacotools/Monaco/_build/results?buildId=267507&view=results

Logs:
VSCode Smoke Tests (Electron)
       Extensions
         install and enable vscode-smoketest-check extension:
Error: Timeout: get element '.extension-editor .monaco-action-bar .action-item:not(.disabled) .extension-action.uninstall' after 20 seconds.
      at Code.poll (D:\a\_work\1\s\test\automation\out\code.js:204:23)
      at async Code.waitForElement (D:\a\_work\1\s\test\automation\out\code.js:163:16)
      at async Extensions.installExtension (D:\a\_work\1\s\test\automation\out\extensions.js:51:9)
      at async Context.<anonymous> (out\areas\extensions\extensions.test.js:15:13)

Looked all failed instances and it is caused because of the network issues on the machine. Hence closing it as no fix.

How did you determine that? Just wondering because I saw that in https://dev.azure.com/monacotools/Monaco/_build/results?buildId=277192&view=logs&j=260a512b-e5ca-5cf1-3f8e-20c0fa41efc9&t=ecad4960-5379-5108-563e-8a65e2414e29&s=a56e7651-4213-56af-9488-c25fe636c10c too but I can believe it's just network issues because we've had a lot of that in CI lately

How did you determine that?

From the logs mostly.


.sphinx: lxddoc - minimalistic templating tool for the sphinx doc

Closing for now as we still need to debate the approach.


Add ability to scan all running processes using -e (Windows only)

Simple additions to enable scanning across all running processes, currently implemented on Windows only.
Processes that begin or end whilst yara is running will not be scanned as the process list is built once at startup.

I'm closing this because I never received a reply to the query above and the effort required to reconcile code changes is now excessive.


Generate real Byron transactions

We need a TxGen (see #855) instance for ByronBlockOrEBB ByronConfig. Currently, we're not generating any transactions in the consensus tests for real Byron blocks (we are for mock blocks).
It would be great if we could reuse the existing generators from cardano-ledger.

@intricate do you think you could take this on? The idea was to do something similar to your UTxO tests in cardano-ledger, where you generate and elaborate.

Notes:

cardano-ledger contains Hedgehog generators for the UTxO and transactions, but they simply generate arbitrary values for most fields. The chance that a transaction is valid w.r.t. to some UTxO is close to zero.
Conclusion: we cannot use these generators to generate real Byron transactions.

cardano-ledger-specs contains Hedgehog generators for an abstract UTxO and abstract transactions. Using these generators, we can generate a valid transaction w.r.t. to some UTxO. The generated abstract transaction first has to be elaborated into a concrete transaction. Simply put: abstract = cardano-ledger-specs types, concrete = cardano-ledger types. The cardano-ledger repository contains functions to perform this elaboration.
In our situation we have a concrete UTxO (current ledger state) for which we want to generate valid and invalid concrete transactions. We have the following steps:
concrete UTxO ---> abstract UTxO ---> abstract TX ---> concrete TX
              (1)                (2)              (3)

abstract a concrete UTxO into an abstract UTxO: missing
generate an abstract transaction w.r.t. an abstract UTxO: available
elaborate an abstract transaction into a concrete transaction: available

So step 1 is missing. I'm not sure about the feasibility of it. Moreover, I don't think we, consensus, should be the ones implementing it. The ledger teams seem better positioned to do this (if feasible, of course). So for now I eliminate this route.

cardano-ledger and cardano-ledger-specs use Hedgehog for property testing and have Hedgehog generators, whereas we, the consensus team, use QuickCheck for property testing and want QuickCheck generators.
Fortunately, there exists an easy way to create a QuickCheck generator based on a Hedgehog generator. It loses Hedgehog's shrinking, though. But that is something we could potentially live with.

Actually, the context in which we generate these transactions does not allow us to use a QuickCheck nor Hedgehog Gen directly: it is not being run directly inside a property. It is in fact in a MonadRandom m => ... -> m (GenTx blk) context.
However, I have managed to plug in a Hedgehog generator in this context:
..
import           Hedgehog (Seed (..), Size (..))
import           Hedgehog.Internal.Gen (Gen, evalGen)
import           Hedgehog.Internal.Tree (treeValue)
..

testGenTx _numCoreNodes cfg _ledgerState = runGen genGenTx
  where
    runGen :: forall m a. MonadRandom m => Gen a -> m a
    runGen gen = do
      seed <- genSeed
      case evalGen (Size 30) seed gen of
        Nothing -> runGen gen
        Just ta -> return $ treeValue ta

    genSeed :: forall m. MonadRandom m => m Seed
    genSeed = do
      let mn = toInteger (minBound :: Word64)
          mx = toInteger (maxBound :: Word64)
      a <- fromInteger <$> generateBetween mn mx
      b <- fromInteger <$> generateBetween mn mx
      return $ Seed a (if even b then succ b else b)

    -- Dumb generation of random transactions
    genGenTx :: Gen (GenTx (ByronBlockOrEBB cfg))
    genGenTx = mkByronTx . UTxO.annotateTxAux <$>
      UTxO.genTxAux protocolMagicId

    protocolMagicId = Genesis.gdProtocolMagicId
                    . Genesis.configGenesisData
                    . pbftGenesisConfig
                    . encNodeConfigExt
                    . unWithEBBNodeConfig
                    $ cfg

In conclusion: I believe (with advice from @dnadales) we may have to bite the bullet and write a(n) (in)valid transaction ourselves that looks at the current (concrete) UTxO.

@mrBliss

cardano-ledger contains Hedgehog generators for the UTxO and transactions, but they simply generate arbitrary values for most fields. The chance that a transaction is valid w.r.t. to some UTxO is close to zero.

Note that these aren't the generators we use for conformance testing. The UTxO generators, which generate transactions w.r.t. a valid abstract UTxO, are in module Ledger.UTxO.Generators.

Oh, it seems you're aware of this :) I should have kept on reading ...

Closing in favour of #1194.


Please add Rochester NY

!!!

Hi @seylea and @sarahallee ,
To add your city, please provide email addressed and an email for us to use! Check out the guidelines here and submit an new request: https://github.com/defund12/defund12.org/blob/gh-pages/EMAIL_TEMPLATE_STYLE_GUIDE.md
Thanks for contributing!


in Dubizzle, we have a requirement to:

in Dubizzle, we have a requirement to:

in conversations list screen: display participant name . make participant name bold if there is unread message
in conversation messages screen: display participant name, photo, presence and last seen
presence style change in case of online. presence should be hidden in case of other statuses

@hishamdubizzle Thanks for making a PR!
One of the problems you seem to face is that Atlas is currently not flexible enough for your needs. We're hoping to change that with the next version of Atlas (called Layer UI).
I'm going to take the changes you've done above as feedback for what we're doing right now, and hopefully Layer UI will let you achieve all of the above without having to make your own fork.
As far as merging these changes is concerned, we cannot simply merge them in, since there are many other developers who depend on Atlas working a certain way, and your changes might not be consistent with what they need. We can't make all these changes for other developers without making them all optional.
So for the time being, I think the best place for these changes is in your own fork.


Optimize Scene Composition.

See tvgSceneImpl.h:
bool Scene::Impl::render(RenderMethod& renderer)
...
/* OPTIMIZE ME: if the scene has just one simple shape, the composition is not required,
It would be better if the condition checks whether the only child is another scene or not. */
    //Half translucent. This condition requires intermediate composition.
    if ((opacity < 255 && opacity > 0) && (paints.count > 0)) {
        uint32_t x, y, w, h;

...
Currently Composition is always triggered regardless of its children condition. We can avoid unneccesary composition if the only child is not the scene.

https://github.com/Samsung/thorvg/pull/258


Update repositories.txt - Library name change for Alfredo_NoU3

I'm the maintainer for this library. I am about to start distributing the board that this library is written for, and it is gonna bug me forever if this isn't fixed before the community that uses my board starts using this library. Thank you!

@ArduinoBot


fix: Some grammatical corrections

Done some grammatical corrections on the website.

Your commit message was not correct so the app has not been released.
We can wait for the next evolution to include your changes or push an empty commit to the main branch to force the release

My bad, I didn't see that it was a "docs" commit. I'm going to push an empty commit.

NP.
Did you squash for the merge ? I think that squashing would have override your commit, but not sure since there is only one commit :thinking:

That's what I was wondering. Every repo on lenra-io is set to "squash on merge", maybe not this one 😆


DTSPB-3107 Add businessArea tag CFT for probate

Resolves # . (This is applicable only if this pull request relates to a GitHub issue, delete the line otherwise)
Notes:

this is to satisfy tagging levels required by 21st Nov

Tim explained not needed


Fix Alamofire validation not being performed on uploadMultipart

Resolves #1590
Alamofire validation was not being performed on .uploadMultipart requests. I've added a backing unit test for this.

Codecov Report

Merging #1591 into master will increase coverage by 4.36%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #1591      +/-   ##
==========================================
+ Coverage   82.05%   86.41%   +4.36%
==========================================
  Files           5       25      +20
  Lines         156      839     +683
==========================================
+ Hits          128      725     +597
- Misses         28      114      +86

Impacted Files
Coverage Δ

Sources/Moya/MoyaProvider+Internal.swift
93.12% <100%> (ø)

Sources/Moya/MultiTarget.swift
100% <0%> (ø)

Sources/Moya/URLRequest+Encoding.swift
100% <0%> (ø)

Sources/Moya/Plugins/CredentialsPlugin.swift
100% <0%> (ø)

Sources/Moya/Plugins/NetworkActivityPlugin.swift
100% <0%> (ø)

Sources/Moya/MultipartFormData.swift
62.06% <0%> (ø)

Sources/Moya/URL+Moya.swift
100% <0%> (ø)

Sources/Moya/Moya+Alamofire.swift
82.6% <0%> (ø)

Sources/Moya/MoyaProvider.swift
81.53% <0%> (ø)

... and 14 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 77cd637...7532434. Read the comment docs.

          1 Warning

:warning:
Consider adding supporting documentation to this change. Documentation can be found in the docs directory.

  Generated by :no_entry_sign: Danger

@sunshinejr No problem, I added some spacing between the tests. LMK if this is 👌


#724: Fix readme following removal of profiler.sh

I've updated the documentation. This required a bit more changes, since README previously referred to profiler.sh script, while asprof is not a script.


Is mini-vg available for neural-motifs?

iterative message passing project had released mini-vg dataset, i wanna know if it is available for neural-motifs,thanks.

iterative message passing project had released mini-vg dataset, i wanna know if it is available for neural-motifs,thanks.

have you slove this problem?


Ingest Astro CLI docs

Please describe the feature you'd like to see
Currently the ingest for astro docs and astro learn uses github markdown pages.  The docLink points to the github page.
Ingest the astro cli  docs to Ask-Astro from astro-cli docs
Describe the solution you'd like
Ingest the astro cli  docs to Ask-Astro from astro-cli docs
Are there any alternatives to this feature?
Current ingest is okay for RAG performance.
Additional context
Ingest the astro cli  docs to Ask-Astro from astro-cli docs
Acceptance Criteria

[ ] All checks and tests in the CI should pass
[ ] Unit tests
[ ] Integration tests (if the feature relates to a new database or external service)
[ ] Example DAG
[ ] Docstrings in reStructuredText for each of  methods, classes, functions and module-level attributes (including Example DAG on how it should be used)
[ ] Exception handling in case of errors
[ ] Logging (are we exposing useful information to the user? e.g. source and destination)
[ ] Improve the documentation (README, Sphinx, and any other relevant)
[ ] How to use Guide for the feature (example)

Note:

[ ] After the implementation is complete, the data should be ingested to the dev database and the dev slackbot should be deployed.
[ ] This change should be tested by @vatsrahul1001 and after his take on quality of response, this should be merged

@vatsrahul1001 I've tested and deployed to dev. Could you please test it when you're available? Thanks!


WinAppDriver cannot locate elements on Modal window's Modal window

I'm trying to automate a Windows Printer Driver Application on windows 10 pro with newest WinAppDriver v1.2.1.WinAppDriver.
The test script cannot locate any element on the Preferences Window, which is a Modal window's Modal Window.
The test scenario is as below:

The test script starts notepad.exe, locate and click Print menu item, the Print Modal window shows.
Then locate and click the Preferences button on the Print Modal window, the Preferences Modal window shows.
Then try to click elements on the Preferences Modal Window, it fails.

Here is my sample code, using Appium-Python-Client library:
from appium import webdriver

desired_caps = {}
desired_caps["app"] = "C:\\Windows\\notepad.exe"
desired_caps["platformName"] = "windows"

driver = webdriver.Remote(
    command_executor='http://<IP_ADDRESS>:4723',
    desired_capabilities= desired_caps)

driver.find_element_by_name("ファイル(F)").click()
driver.find_element_by_accessibility_id("6").click()

# click elements on the Print modal window
driver.find_element_by_accessibility_id("1010").click()

# click elements on the Preferences modal window
driver.find_element_by_xpath("/Pane[@ClassName=\"#32769\"][@Name=\"デスクトップ 1\"]/Window[@ClassName=\"#32770\"][@Name=\"印刷設定\"]/Tab[@ClassName=\"SysTabControl32\"]/TabItem[@Name=\" 拡張機能 \"]").click()
driver.find_element_by_xpath("/Pane[@ClassName=\"#32769\"][@Name=\"デスクトップ 1\"]/Window[@ClassName=\"#32770\"][@Name=\"印刷設定\"]/Button[@ClassName=\"Button\"][@Name=\"設定(E)...\"]").click()
driver.find_element_by_xpath("/Pane[@ClassName=\"#32769\"][@Name=\"デスクトップ 1\"]/Window[@ClassName=\"#32770\"][@Name=\"印刷設定\"]/Window[@ClassName=\"#32770\"][@Name=\"セキュリティ印刷設定\"]/CheckBox[@ClassName=\"Button\"][@Name=\"セキュリティ印刷(S)\"]").click()

The WinAppDriver's log:
{"status":7,"value":{"error":"no such element","message":"An element could not be located on the page using the given search parameters."}}

I also have tried relative xpath expressions, and by name or by accessibility id. Did not succeed.
I also have tried the WADLibrary client library. It had same phenomenon.
I also have tried some other versions of WinAppDriver, all failed except the old version of WinAppDriver v1.1.4

Is there any other way to locate elements on the descendant Modal window (i.e the Preferences Modal window)?

@ivercan I suppose that "Preferences Modal Window" is a new window, try to switch https://github.com/microsoft/WinAppDriver/blob/master/Docs/FAQ.md
var allWindowHandles = session.WindowHandles;
// Assuming you only have only one window entry in allWindowHandles and it is in fact the correct one,
// switch the session to that window as follows. You can repeat this logic with any top window with the same
// process id (any entry of allWindowHandles)
session.SwitchTo().Window(allWindowHandles[0]);

@Shakevg your reply is very helpful!
I tried treating it as a new window, and using relative xpath. it works.
thanks!


First PR

Hey @CallmeHenry thnx for contributing , Contribute in this year's Hacktoberfest in October 2020 and follow me on Github and Star this repo for updates and notifications about the project.


Cakephp3 header format

Cakephp3 accepts header in different notation than the oAuth2 package (league/oauth2-server).
HTTP/1.1 400 Bad Request
should be
HTTP/1.1 400: Bad Request
in Cakephp3 in order not to cause an error in the header method of Network/Respone.

Closed because #19 was opened.


Make package command deal with a configuration directory argument

Currently if we run datasette package on a configuration directory we'll get an exception when we try to hard link to the directory. This PR copies the tree and makes the Dockerfile run inspect on all *.db files.

Not currently using this myself and it looks like this code has been reworked, so I assume this has been fixed no.w


Update tunnelbear to 3.0.16

After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} left no offenses.
[x] The commit message includes the cask’s name and version.

Additionally, if updating a cask:

[x] If the sha256 changed but the version didn’t,
provide public confirmation by the developer: https://www.virustotal.com/en/file/7ae86056d7ddc991f537be9b029f471eb446366adc3c4b0e0d4b9b45c24e07be/analysis/

@slothdog I've updated your PR to include codesigning verification via VirusTotal.