Bugfix 19: Wait until loaded method of grid

PR Details
Fixed bug in method to wait for the loading overlay of a grid to disappear. There was a missing await, so the wait wasn't applied properly.
Description
Resolved bug by added the missing await. Also, took advantage of this change to:

Rename method to waitToBeLoaded()
Handled arguments as an object, so we are allowed to configure each one independently

Related Issue
#19 New waitUntilLoaded() method of grids doesn't wait properly for loading overlay to disappear
Types of changes

[ ] Docs change / refactoring / dependency upgrade
[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

[x] I have read the CONTRIBUTING document
[x] My code follows the code style of this project
[ ] My change requires a change to the documentation
[ ] I have updated the documentation accordingly (README.md for each widget)
[ ] I have added tests to cover my changes (at least 1 spec for each widget with the same coverage as the master branch)
[ ] All tests (new and existing) passed
[ ] A new branch needs to be created from master to evolve previous versions
[x] Increase version in package.json following Semantic Versioning
[x] Add the issue into the right project with the proper status (In progress)

Notice that PR #18 needs to be merged before this one, as the related branch of this one has been created from the branch of this related PR.

This PR fixes bug #19, so the merge closes it.


4.1.7: java.lang.NoClassDefFoundError: Could not initialize class io.netty.util.internal.PlatformDependent0

Expected behavior
No error
Actual behavior
Caused by: java.lang.NoClassDefFoundError: Could not initialize class io.netty.util.internal.PlatformDependent0
        at io.netty.util.internal.PlatformDependent.getClassLoader(PlatformDependent.java:881)
        at io.netty.channel.DefaultChannelId.defaultProcessId(DefaultChannelId.java:110)
        at io.netty.channel.DefaultChannelId.<clinit>(DefaultChannelId.java:78)
        at io.netty.channel.AbstractChannel.newId(AbstractChannel.java:107)
        at io.netty.channel.AbstractChannel.<init>(AbstractChannel.java:79)
        at io.netty.channel.nio.AbstractNioChannel.<init>(AbstractNioChannel.java:84)
        at io.netty.channel.nio.AbstractNioByteChannel.<init>(AbstractNioByteChannel.java:54)
        at io.netty.channel.socket.nio.NioSocketChannel.<init>(NioSocketChannel.java:97)
        at io.netty.channel.socket.nio.NioSocketChannel.<init>(NioSocketChannel.java:87)
        at io.netty.channel.socket.nio.NioSocketChannel.<init>(NioSocketChannel.java:80)
        at io.netty.channel.socket.nio.NioSocketChannel.<init>(NioSocketChannel.java:73)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
        at java.lang.Class.newInstance(Class.java:442)
        at io.netty.channel.ReflectiveChannelFactory.newChannel(ReflectiveChannelFactory.java:38)
        at io.netty.bootstrap.AbstractBootstrap.initAndRegister(AbstractBootstrap.java:319)
        at io.netty.bootstrap.Bootstrap.doResolveAndConnect(Bootstrap.java:163)
        at io.netty.bootstrap.Bootstrap.connect(Bootstrap.java:145)

Steps to reproduce
Minimal yet complete reproducer code (or URL to code)
Same as https://github.com/netty/netty/issues/6038
Netty version
4.1.7
JVM version (e.g. java -version)
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)

OS version (e.g. uname -a)
Fedora 24
Linux localhost.localdomain 4.8.16-200.fc24.x86_64 #1 SMP Fri Jan 6 18:13:39 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

@Scottmitch  Looks like an upport of https://github.com/netty/netty/commit/e5ac9d3c9e753008c9fa13f3631b06a45a182096 is needed

@Scottmitch can you take a look ?

PR https://github.com/netty/netty/pull/6042 was developed against 4.1 and merged into both 4.1 and 4.0 but was specifically target at getSystemClassLoader.  This issue is for PlatformDependent.getClassLoader which was not addressed ... let me investigate.

@jesperpedersen - You also verified #6042 in https://github.com/netty/netty/pull/6042#issuecomment-261929942. Did your use case or something else change?

No, nothing changed other than we switched to Netty 4.1.
Netty 4.0.43 worked, and reverting back to Netty 4.1.4 also worked.

No, nothing changed other than we switched to Netty 4.1.

To clarify ... your version of Netty changed? You verified on 4.x but you are now using 4.1, correct?

I originally verified with the patch for 4.0, since we ere using that version at the time. We later moved to 4.1, which I now have verified. So correct.

thx for clarifying ... based on https://github.com/netty/netty/pull/6251#issuecomment-273782967 you should now also be able to use 4.1.


After installing uNetworking/uWebSockets.js#binaries server doesn't starting

Hi @alexhultman and thanks for such great app.
I see that i can install uNetworking/uWebSockets.js#binaries, but after installing, can't start server. it fails, exactly token at .listen method missing.
It is known bug?
Node: v10.15.3
NPM: v6.4.1
OS: macOS 10.13.6

Available methods
uWS.HttpResponse {
  writeStatus: [Function: writeStatus],
  end: [Function: end],
  tryEnd: [Function: tryEnd],
  write: [Function: write],
  writeHeader: [Function: writeHeader],
  close: [Function: close],
  getWriteOffset: [Function: getWriteOffset],
  onWritable: [Function: onWritable],
  onAborted: [Function: onAborted],
  onData: [Function: onData],
  getRemoteAddress: [Function: getRemoteAddress] }

Passing host make it work :)


Set terminal title to reflect current page

Looks good for subreddits, but I think it gets too cluttered when it prints the entire submission URL.

How do you feel about just doing this for subreddits, unless you have any other ideas? Also I would suggest putting the rtv vX.Y.Z first so it doesn't get cut off if the window is too small.

How about I ellipsize the middle of the title string if it is over so many characters?
It seems to be common append program name after the filename in most applications

Do you have any examples? I don't see many applications that edit the terminal title in the first place. The one that I did find was elinks,  which I believe just uses the <title> element instead of the whole url.

vim
ncmpcpp
mps-youtube

Fair enough, thanks for providing examples. I think that cutting to 50 characters is good enough to address my concern.


Race condition in JsonRpcExecutor

Description
We started noticing that when we're frequently using the eth_call method, every now and then it would fail unexpectedly with the Block not found error.
After observing the logs I believe the issue is a race condition:
Logs from the time the error occured:
2022-07-28 13:39:11.899+00:00 | vert.x-worker-thread-15 | DEBUG | JsonRpcExecutor | JSON-RPC request -> eth_call [{to=0xd0f52767c5d2d3a5a1b5de558dc673ad35a4b7e8, data=0x003e36bf000000000000000000000000d0584d4d37157f7105a4b41ed8ecbdfafdb2547f}, latest]
2022-07-28 13:39:11.901+00:00 | vert.x-eventloop-thread-1 | DEBUG | B3PropagatorExtractorMultipleHeaders | Invalid TraceId in B3 header: null'. Returning INVALID span context.
2022-07-28 13:39:11.901+00:00 | vert.x-worker-thread-14 | DEBUG | JsonRpcExecutor | JSON-RPC request -> eth_call [{to=0xd0f52767c5d2d3a5a1b5de558dc673ad35a4b7e8, data=0x6adb038b}, latest]
2022-07-28 13:39:11.951+00:00 | vert.x-eventloop-thread-1 | DEBUG | B3PropagatorExtractorMultipleHeaders | Invalid TraceId in B3 header: null'. Returning INVALID span context.
2022-07-28 13:39:11.952+00:00 | vert.x-worker-thread-16 | DEBUG | JsonRpcExecutor | JSON-RPC request -> eth_blockNumber []
2022-07-28 13:39:12.001+00:00 | BftProcessorExecutor-IBFT-0 | DEBUG | IbftRound | Creating proposed block. round=ConsensusRoundIdentifier{Sequence=862, Round=0}
2022-07-28 13:39:12.002+00:00 | vert.x-eventloop-thread-1 | DEBUG | B3PropagatorExtractorMultipleHeaders | Invalid TraceId in B3 header: null'. Returning INVALID span context.
2022-07-28 13:39:12.003+00:00 | vert.x-worker-thread-2 | DEBUG | JsonRpcExecutor | JSON-RPC request -> eth_call [{to=0xd0f52767c5d2d3a5a1b5de558dc673ad35a4b7e8, data=0x003e36bf000000000000000000000000d0584d4d37157f7105a4b41ed8ecbdfafdb2547f}, latest]
2022-07-28 13:39:12.005+00:00 | BftProcessorExecutor-IBFT-0 | DEBUG | IbftRound | Sending commit message. round=ConsensusRoundIdentifier{Sequence=862, Round=0}
2022-07-28 13:39:12.006+00:00 | vert.x-eventloop-thread-1 | DEBUG | B3PropagatorExtractorMultipleHeaders | Invalid TraceId in B3 header: null'. Returning INVALID span context.
2022-07-28 13:39:12.006+00:00 | BftProcessorExecutor-IBFT-0 | DEBUG | IbftRound | Importing block to chain. round=ConsensusRoundIdentifier{Sequence=862, Round=0}, hash=0x402c2dad739593c3dd5a6efc5f051c1bdf6ab1eaef0240da42cb222652155e0f
2022-07-28 13:39:12.007+00:00 | vert.x-worker-thread-17 | DEBUG | JsonRpcExecutor | JSON-RPC request -> eth_call [{to=0xd0f52767c5d2d3a5a1b5de558dc673ad35a4b7e8, data=0x6adb038b}, latest]
2022-07-28 13:39:12.008+00:00 | BftProcessorExecutor-IBFT-0 | DEBUG | TransactionLogBloomCacher | Caching logs bloom for block 0x35e.
2022-07-28 13:39:12.009+00:00 | BftProcessorExecutor-IBFT-0 | INFO  | IbftBesuControllerBuilder | Produced #862 / 0 tx / 0 pending / 0 (0.0%) gas / (0x402c2dad739593c3dd5a6efc5f051c1bdf6ab1eaef0240da42cb222652155e0f)
2022-07-28 13:39:12.009+00:00 | BftProcessorExecutor-IBFT-0 | DEBUG | BaseBftController | New chain head detected (block number=862), currently mining on top of 861.
2022-07-28 13:39:12.056+00:00 | vert.x-eventloop-thread-1 | DEBUG | B3PropagatorExtractorMultipleHeaders | Invalid TraceId in B3 header: null'. Returning INVALID span context.
2022-07-28 13:39:12.056+00:00 | vert.x-worker-thread-19 | DEBUG | JsonRpcExecutor | JSON-RPC request -> eth_blockNumber []

Logs from other calls to eth_call that didn't fail:
2022-07-28 13:39:10.975+00:00 | vert.x-worker-thread-5 | DEBUG | JsonRpcExecutor | JSON-RPC request -> eth_call [{to=0xd0f52767c5d2d3a5a1b5de558dc673ad35a4b7e8, data=0x003e36bf000000000000000000000000d0584d4d37157f7105a4b41ed8ecbdfafdb2547f}, latest]
2022-07-28 13:39:10.984+00:00 | vert.x-eventloop-thread-1 | DEBUG | B3PropagatorExtractorMultipleHeaders | Invalid TraceId in B3 header: null'. Returning INVALID span context.
2022-07-28 13:39:10.986+00:00 | vert.x-eventloop-thread-1 | DEBUG | B3PropagatorExtractorMultipleHeaders | Invalid TraceId in B3 header: null'. Returning INVALID span context.
2022-07-28 13:39:10.987+00:00 | vert.x-worker-thread-7 | DEBUG | JsonRpcExecutor | JSON-RPC request -> eth_blockNumber []
2022-07-28 13:39:10.987+00:00 | vert.x-worker-thread-7 | DEBUG | JsonRpcExecutor | JSON-RPC request -> eth_call [{to=0xd0f52767c5d2d3a5a1b5de558dc673ad35a4b7e8, data=0x6adb038b}, latest]
2022-07-28 13:39:11.004+00:00 | BftProcessorExecutor-IBFT-0 | DEBUG | IbftRound | Creating proposed block. round=ConsensusRoundIdentifier{Sequence=861, Round=0}
2022-07-28 13:39:11.007+00:00 | BftProcessorExecutor-IBFT-0 | DEBUG | IbftRound | Sending commit message. round=ConsensusRoundIdentifier{Sequence=861, Round=0}
2022-07-28 13:39:11.009+00:00 | BftProcessorExecutor-IBFT-0 | DEBUG | IbftRound | Importing block to chain. round=ConsensusRoundIdentifier{Sequence=861, Round=0}, hash=0x9776c29ee0d9c5656f01f487b3e44c3f8bf329af4a827950cff34738a23a9c23
2022-07-28 13:39:11.011+00:00 | BftProcessorExecutor-IBFT-0 | DEBUG | TransactionLogBloomCacher | Caching logs bloom for block 0x35d.
2022-07-28 13:39:11.012+00:00 | BftProcessorExecutor-IBFT-0 | INFO  | IbftBesuControllerBuilder | Produced #861 / 0 tx / 0 pending / 0 (0.0%) gas / (0x9776c29ee0d9c5656f01f487b3e44c3f8bf329af4a827950cff34738a23a9c23)
2022-07-28 13:39:11.012+00:00 | BftProcessorExecutor-IBFT-0 | DEBUG | BaseBftController | New chain head detected (block number=861), currently mining on top of 860.
2022-07-28 13:39:11.078+00:00 | vert.x-eventloop-thread-1 | DEBUG | B3PropagatorExtractorMultipleHeaders | Invalid TraceId in B3 header: null'. Returning INVALID span context.
2022-07-28 13:39:11.078+00:00 | vert.x-worker-thread-9 | DEBUG | JsonRpcExecutor | JSON-RPC request -> eth_call [{to=0xd0f52767c5d2d3a5a1b5de558dc673ad35a4b7e8, data=0x003e36bf000000000000000000000000d0584d4d37157f7105a4b41ed8ecbdfafdb2547f}, latest]
2022-07-28 13:39:11.089+00:00 | vert.x-eventloop-thread-1 | DEBUG | B3PropagatorExtractorMultipleHeaders | Invalid TraceId in B3 header: null'. Returning INVALID span context.
2022-07-28 13:39:11.090+00:00 | vert.x-worker-thread-8 | DEBUG | JsonRpcExecutor | JSON-RPC request -> eth_call [{to=0xd0f52767c5d2d3a5a1b5de558dc673ad35a4b7e8, data=0x6adb038b}, latest]

2022-07-28 13:39:12.900+00:00 | vert.x-eventloop-thread-1 | DEBUG | B3PropagatorExtractorMultipleHeaders | Invalid TraceId in B3 header: null'. Returning INVALID span context.
2022-07-28 13:39:12.900+00:00 | vert.x-worker-thread-7 | DEBUG | JsonRpcExecutor | JSON-RPC request -> eth_blockNumber []
2022-07-28 13:39:12.930+00:00 | vert.x-eventloop-thread-1 | DEBUG | B3PropagatorExtractorMultipleHeaders | Invalid TraceId in B3 header: null'. Returning INVALID span context.
2022-07-28 13:39:12.931+00:00 | vert.x-worker-thread-4 | DEBUG | JsonRpcExecutor | JSON-RPC request -> eth_call [{to=0xd0f52767c5d2d3a5a1b5de558dc673ad35a4b7e8, data=0x003e36bf000000000000000000000000d0584d4d37157f7105a4b41ed8ecbdfafdb2547f}, latest]
2022-07-28 13:39:12.932+00:00 | vert.x-eventloop-thread-1 | DEBUG | B3PropagatorExtractorMultipleHeaders | Invalid TraceId in B3 header: null'. Returning INVALID span context.
2022-07-28 13:39:12.933+00:00 | vert.x-worker-thread-9 | DEBUG | JsonRpcExecutor | JSON-RPC request -> eth_call [{to=0xd0f52767c5d2d3a5a1b5de558dc673ad35a4b7e8, data=0x6adb038b}, latest]
2022-07-28 13:39:13.007+00:00 | BftProcessorExecutor-IBFT-0 | DEBUG | IbftRound | Creating proposed block. round=ConsensusRoundIdentifier{Sequence=863, Round=0}
2022-07-28 13:39:13.011+00:00 | BftProcessorExecutor-IBFT-0 | DEBUG | IbftRound | Sending commit message. round=ConsensusRoundIdentifier{Sequence=863, Round=0}
2022-07-28 13:39:13.013+00:00 | BftProcessorExecutor-IBFT-0 | DEBUG | IbftRound | Importing block to chain. round=ConsensusRoundIdentifier{Sequence=863, Round=0}, hash=0x821cee9098df3b642949b04ae0e9bd38f65d8098a0ab27db202fecbb15eb1755
2022-07-28 13:39:13.015+00:00 | BftProcessorExecutor-IBFT-0 | DEBUG | TransactionLogBloomCacher | Caching logs bloom for block 0x35f.
2022-07-28 13:39:13.015+00:00 | BftProcessorExecutor-IBFT-0 | INFO  | IbftBesuControllerBuilder | Produced #863 / 0 tx / 0 pending / 0 (0.0%) gas / (0x821cee9098df3b642949b04ae0e9bd38f65d8098a0ab27db202fecbb15eb1755)
2022-07-28 13:39:13.015+00:00 | BftProcessorExecutor-IBFT-0 | DEBUG | BaseBftController | New chain head detected (block number=863), currently mining on top of 862.
2022-07-28 13:39:13.017+00:00 | vert.x-eventloop-thread-1 | DEBUG | B3PropagatorExtractorMultipleHeaders | Invalid TraceId in B3 header: null'. Returning INVALID span context.
2022-07-28 13:39:13.018+00:00 | vert.x-worker-thread-8 | DEBUG | JsonRpcExecutor | JSON-RPC request -> eth_blockNumber []
2022-07-28 13:39:13.021+00:00 | vert.x-eventloop-thread-1 | DEBUG | B3PropagatorExtractorMultipleHeaders | Invalid TraceId in B3 header: null'. Returning INVALID span context.
2022-07-28 13:39:13.021+00:00 | vert.x-worker-thread-10 | DEBUG | JsonRpcExecutor | JSON-RPC request -> eth_getLogs [{fromBlock=0x35e, toBlock=0x35e, address=0xd0f52767c5d2d3a5a1b5de558dc673ad35a4b7e8, topics=[[0x9d5e3328d970a5c6148e8517851833559e79a94a9e23c376e4fee239d22b0bd1, 0x0c8c078f4dd07dbcb3760ab8ea213e22ae0a6f5131ac172980591d05e85ea41c, 0x274b9db18c1fe5545e1e46c41c24276caa16ea2666000637ed1d9517adcec0dc, 0x953e2be1a971fbc42605a647cf3cfe0ddfeb9ee42a202c2d78d3b24d7a3e1d15]]}]
2022-07-28 13:39:13.023+00:00 | vert.x-eventloop-thread-1 | DEBUG | B3PropagatorExtractorMultipleHeaders | Invalid TraceId in B3 header: null'. Returning INVALID span context.
2022-07-28 13:39:13.023+00:00 | vert.x-worker-thread-13 | DEBUG | JsonRpcExecutor | JSON-RPC request -> eth_blockNumber []
2022-07-28 13:39:13.035+00:00 | vert.x-eventloop-thread-1 | DEBUG | B3PropagatorExtractorMultipleHeaders | Invalid TraceId in B3 header: null'. Returning INVALID span context.

2022-07-28 13:39:13.860+00:00 | vert.x-worker-thread-14 | DEBUG | JsonRpcExecutor | JSON-RPC request -> eth_call [{to=0xd0f52767c5d2d3a5a1b5de558dc673ad35a4b7e8, data=0x6adb038b}, latest]
2022-07-28 13:39:13.904+00:00 | vert.x-eventloop-thread-1 | DEBUG | B3PropagatorExtractorMultipleHeaders | Invalid TraceId in B3 header: null'. Returning INVALID span context.
2022-07-28 13:39:13.904+00:00 | vert.x-worker-thread-16 | DEBUG | JsonRpcExecutor | JSON-RPC request -> eth_blockNumber []
2022-07-28 13:39:13.960+00:00 | vert.x-eventloop-thread-1 | DEBUG | B3PropagatorExtractorMultipleHeaders | Invalid TraceId in B3 header: null'. Returning INVALID span context.
2022-07-28 13:39:13.961+00:00 | vert.x-worker-thread-2 | DEBUG | JsonRpcExecutor | JSON-RPC request -> eth_call [{to=0xd0f52767c5d2d3a5a1b5de558dc673ad35a4b7e8, data=0x003e36bf000000000000000000000000d0584d4d37157f7105a4b41ed8ecbdfafdb2547f}, latest]
2022-07-28 13:39:13.962+00:00 | vert.x-eventloop-thread-1 | DEBUG | B3PropagatorExtractorMultipleHeaders | Invalid TraceId in B3 header: null'. Returning INVALID span context.
2022-07-28 13:39:13.963+00:00 | vert.x-worker-thread-18 | DEBUG | JsonRpcExecutor | JSON-RPC request -> eth_call [{to=0xd0f52767c5d2d3a5a1b5de558dc673ad35a4b7e8, data=0x6adb038b}, latest]
2022-07-28 13:39:14.002+00:00 | BftProcessorExecutor-IBFT-0 | DEBUG | IbftRound | Creating proposed block. round=ConsensusRoundIdentifier{Sequence=864, Round=0}
2022-07-28 13:39:14.003+00:00 | BftProcessorExecutor-IBFT-0 | DEBUG | IbftRound | Sending commit message. round=ConsensusRoundIdentifier{Sequence=864, Round=0}
2022-07-28 13:39:14.004+00:00 | BftProcessorExecutor-IBFT-0 | DEBUG | IbftRound | Importing block to chain. round=ConsensusRoundIdentifier{Sequence=864, Round=0}, hash=0xdecd60ebd89319caddabae991d531a5968f3630b2c07017cd553bee7be31b7c2
2022-07-28 13:39:14.005+00:00 | BftProcessorExecutor-IBFT-0 | DEBUG | TransactionLogBloomCacher | Caching logs bloom for block 0x360.
2022-07-28 13:39:14.005+00:00 | BftProcessorExecutor-IBFT-0 | INFO  | IbftBesuControllerBuilder | Produced #864 / 0 tx / 0 pending / 0 (0.0%) gas / (0xdecd60ebd89319caddabae991d531a5968f3630b2c07017cd553bee7be31b7c2)
2022-07-28 13:39:14.005+00:00 | BftProcessorExecutor-IBFT-0 | DEBUG | BaseBftController | New chain head detected (block number=864), currently mining on top of 863.
2022-07-28 13:39:14.007+00:00 | vert.x-eventloop-thread-1 | DEBUG | B3PropagatorExtractorMultipleHeaders | Invalid TraceId in B3 header: null'. Returning INVALID span context.
2022-07-28 13:39:14.007+00:00 | vert.x-worker-thread-19 | DEBUG | JsonRpcExecutor | JSON-RPC request -> eth_blockNumber []
2022-07-28 13:39:14.008+00:00 | vert.x-eventloop-thread-1 | DEBUG | B3PropagatorExtractorMultipleHeaders | Invalid TraceId in B3 header: null'. Returning INVALID span context.
2022-07-28 13:39:14.009+00:00 | vert.x-worker-thread-0 | DEBUG | JsonRpcExecutor | JSON-RPC request -> eth_getLogs [{fromBlock=0x35f, toBlock=0x35f, address=0xd0f52767c5d2d3a5a1b5de558dc673ad35a4b7e8, topics=[[0x9d5e3328d970a5c6148e8517851833559e79a94a9e23c376e4fee239d22b0bd1, 0x0c8c078f4dd07dbcb3760ab8ea213e22ae0a6f5131ac172980591d05e85ea41c, 0x274b9db18c1fe5545e1e46c41c24276caa16ea2666000637ed1d9517adcec0dc, 0x953e2be1a971fbc42605a647cf3cfe0ddfeb9ee42a202c2d78d3b24d7a3e1d15]]}]
2022-07-28 13:39:14.010+00:00 | vert.x-eventloop-thread-1 | DEBUG | B3PropagatorExtractorMultipleHeaders | Invalid TraceId in B3 header: null'. Returning INVALID span context.
2022-07-28 13:39:14.010+00:00 | vert.x-worker-thread-1 | DEBUG | JsonRpcExecutor | JSON-RPC request -> eth_blockNumber []

the fact that the error case has BftProcessorExecutor logs mixed with JsonRpcExecutor makes me believe that some sort of race condition is occuring, but that's all I was able to figure out.
Steps to Reproduce (Bug)

Start up Besu
Frequently call eth_call with with any smart contract method

Expected behavior:
No errors
Actual behavior:
Besu returns Block not found
Frequency:
We saw it occuring say after 2 or so minutes of running our software.
Versions
Docker image labels:
"org.label-schema.build-date": "2022-07-13T11:08Z",
"org.label-schema.description": "Enterprise Ethereum client",
"org.label-schema.name": "Besu",
"org.label-schema.schema-version": "1.0",
"org.label-schema.url": "https://besu.hyperledger.org/",
"org.label-schema.vcs-ref": "b85b39d3",
"org.label-schema.vcs-url": "https://github.com/hyperledger/besu.git",
"org.label-schema.vendor": "Hyperledger",
"org.label-schema.version": "22.7.0-RC2-SNAPSHOT"

Software version: 22.7.0-RC2-SNAPSHOT
We observed this issue on M1 MacBooks and also on our CI - which last time I checked was running various generations of Intel Xeon.

We are also seeing this bug, it's a blocker for us to use Chainlink with Besu. We need reliable RPC calls.
One example RPC call that triggered it:
curl -v --data '{"method":"eth_call","id":"1","params":[{"from": "0x0000000000000000000000000000000000000000", "to": "0x4c0ce02c1219ce5d2afffba97e484272a4637b49", "gas": 9800000, "data":"c41b813a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000084b90895ef775e63adfc50a4e15b5beea08c0b7f"}, "latest"],"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST http://besu-rpc-goerli.example.com

Note that this usually returns the correct payload:
{
  "jsonrpc": "2.0",
  "id": "1",
  "error": {
    "code": -32000,
    "message": "Execution reverted",
    "data": "0x08c379a00000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000001175706b656570206e6f74206e6565646564000000000000000000000000000000"
  }
}

The problem is intermittent.
Sometimes it instead returns "Block not found" error as detailed in the OP.

@samsondav I am assuming this was found on goerli based on the domain in your curl command. Is that true?  If so how frequently and how long did you loop this statement to create the "Block not found" error. I have not yet been able to reproduce it.

@samsondav, checking in again. Are you still seeing the error? If yes, we would love to help investigate the issue.

We still have this bug in our private QBFT deployment

same problem here.

I use Besu and call eth_call with ethersjs. besu version : besu-22.10.2
I run Besu on EC2 instance and call from another EC2 instance.
Error
something like this.
"error\\\" : {\\n    \\\"code\\\" : -32000,\\n    \\\"message\\\" : \\\"Block not found\\\"\\n  }\\n}\",\"error\":{\"code\":-32000},\"requestBody\":\"{\\\"method\\\":\\\"eth_call\\\",\\\"params\\\":[{\\\"to\\\":\\\"0x1e2f9e10d02a6b8f8f69fcbf515e75039d2ea30d\\\",\\\"data\\\":\\\"0xb4658bfb000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000001e000000000000000000000000000000000000000000000000000000000000000010000000000000000000000001d7022f5b17d2f8b695918fb48fa1089c9f854010000000000000000000000000b1ba0af832d7c05fd64161e0db78e85978e8082000000000000000000000000000000000000000000000018baaaf5637dd7aba00000000000000000000000000000000000000000000000008ac7230489e800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a9f3a3e8eac6461d83072dbc2ae64f765b46ab3400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000063a48dc7000000000000000000000000000000000000000000000000000001853ac800b200000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000003000000000000000000000000000000000000000000000000000000000000001c97d558b84456e3a943922ff6132fecd633bc4797909fe657bfd08cd82368bc1a27e01c22ea28745eaaeba45d5defcab0cdddb7ac3deac6bbed7abd3ce8218f7e\\\"},\\\"latest\\\"],\\\"id\\\":405348,\\\"jsonrpc\\\":\\\"2.0\\\"}\",\"requestMethod\":\"POST\",\"url\":\"http://<IP_ADDRESS>:8545\"},

frequency
sometimes I got the error.

I have not yet been able to reproduce it.


Querydsl in eclipse is not generating query type classes in maven project

I copyied the configuration to pom.xml,but when I build,I got the following error in eclipse:
You need to run build with JDK or have tools.jar on the classpath.If this occures during eclipse build make sure you run eclipse under JDK as well (com.mysema.maven:apt-maven-plugin:1.1.3:process:default:generate-sources)
I search the internet, I do as this http://stackoverflow.com/questions/24482259/eclipse-issue-with-maven-build-and-jdk-when-generating-qclasses-in-querydsl say, but till get the same error

hi ,I got this solved.Because I have both JDK1.7 and 1.8 installed on my computer, there is a kind of conflicts.
I removed both 1.7 and 1.8 ,reinstalled 1.8 and everything is fine.


Should @untool/react have @babel/core@7 as direct dependency?

I'm getting a couple of errors, when installing a new project, because @babel/preset-react has a peer dependency to @babel/core.
I don't think the downstream project should have to install @babel/core directly, because they don't use it in their applications.
Therefore I suppose that @untool/react should bring its own @babel/core.
Skimming through the code, it looks like @untool/webpack also has a direct dependency to @babel/core, same goes for jest-preset-hops.
On the topic of Hops: hops-react also adds babel plugins which have peer dependencies to @babel/core, therefore, both, @untool/react and hops-react should bring their own @babel/core I think.

I completely agree: @untool/react should definitely include @babel/Core as a dependency.


Add call for interns

@DanielaIgRo is it ready for another round of review?

Hey @xmnlab I think I have finished correcting what we had pointed out.


Batch Expectations of writeTagGroup?

We have some code to send a group of tag values:
// fooTag and barTag have been previously defined
fooTag.value = 123;
barTag.value = 456;
const outputGroup = new TagGroup();
outputGroup.add(fooTag);
outputGroup.add(barTag);
await plc.writeTagGroup(outputGroup);

In our PLC, we expect that foo and bar have both been changed for the same scan. But occasionally it seems that one tag is applied in one scan, and the other is applied later.
Again, this issue is flaky.. it seems that both tags usually get applied on the same scan, but every once in a while, it seems they don't.
Is this the expected behavior of Ethernet IP? Or are tag write groups supposed to be batched properly? Is there any way to write several tags to the PLC that will be picked up on the same scan?

I/O updates are asynchronous in Control/CompactLogix, so I would assume that is the issue you are seeing, but @cmseaton42 might be able to answer better.

Not only are different tags within groups not read/written all together, but tags with multiple elements can be partially written.   We've seen this a lot with some of our networking PLC code.   This is how the AB code works, nothing to do with the node-ethernet-ip library!
I've never seen anything written out of order, but definitely it is all written async to the execution of the PLC program.

I see in your code that you use writeTagGroup. I haven't used it in my applications, but I probably uses the Multiple-Service-Packet like readTagGroup in order to pack your individual requests into one batch.
According to CIP-Vol1. Appendix A - Multiple Service Packet
A-4.10.1 Service Requirements
The following list details requirements associated with the Multiple_Service_Packet service:
1. Performs services as an autonomous sequence of services.
2. Performs services in the sequence supplied.
3. Performs all services, reporting individual responses for each one.
4. Packs responses into the response buffer in the sequence in which they were executed.
5. A response timeout must be implemented for those service requests that do not guarantee a
response.
6. Each embedded service may return a success or failure, as indicted in the response
structure. If one or more service requests result in an error this service shall return an error.
The error code returned shall be 1Ehex (Embedded service error).
This service allows clients to submit a sequence of ‘embedded’ services in a single message
packet. The object processing the Multiple_Service_Packet shall not perform any other service
until the entire sequence of embedded services has been attempted.
so it looks like it depends on whether the cpu was able to process all of your write-services in one cycle. It would be interesting to see, if they get changed in the correct order in your case? Because according to spec, the CPU should be definitely handling them at least in the correct sequence.

Thanks for the responses!
@Penlane, looking at the implementation of this library, it seems that writeTagGroup does in fact write a Multiple Service Packet. The API does not clearly allow you to define an order, but it does seem possible.
The order of tag writes is defined by Object.keys(tags) within the tag group. So the order will be the same order of the tags as you first added to them to the group.
const outputGroup = new TagGroup();
outputGroup.add(fooTag); // fooTag will be the first tag written
outputGroup.add(barTag); // barTag will be the last tag written
outputGroup.add(fooTag); // this duplicate tag is ignored.. the order will not be affected
await plc.writeTagGroup(outputGroup); // will write fooTag, barTag in order

The trick now, is to program the PLC such that it can handle race conditions on batched tag writes.
Closing the issue for now because it seems that aside from some improved documentation about the order of grouped tag writes, this is not very actionable.

We have found that lots of tag write or multi-word write can be split across scans.  As I mentioned above, we have always seen the writes take place in exact operation order.
The way we worked around this was to write a single word first, called the header.  Usually a DINT.  Then we write all our data.  Then we write another word, called the footer, usually a DINT.    If we are writing to the PLC code, we first set the header value to X, set our data, then set the footer value to X.  In the PLC we check.  If header = footer, then we likely got "unsplit" data (we call the problem tearing). On the next update, we use X=X+1.
We do the same for data we read from the PLC.  The ladder writes the header value, then the data part, then the footer value.  In our client code we check whether the header and footer are equal.  Only then do we process the data.
It is not perfect but it is vastly better than what we were seeing before.


Maybe array typo

I'm not sure about that, but I think you do have a typo in this array.
I think it should be "abcdefghijklmnopqrstuvwxyz123456789".

Good catch.


Spanish: don't add . after short month/day names

A format DD-MMM-YYYY for Spanish will translate in 29-nov.-2013 but in 29-nov-2013 in Windows (and Java).
monthsShort : "ene._feb._mar._abr._may._jun._jul._ago._sep._oct._nov._dic.".split("_"),
weekdaysShort : "dom._lun._mar._mié._jue._vie._sáb.".split("_"),

I am seeing this for German locale as well.. maybe it's a good idea to fan out the fix to all locales that has a dot in it's monthsShort names?
And also it not only applies to -MMM-, the dot also looks weird when using formats like DD.MMM.YYYY (results in 29-nov.-2013) and DD/MMM/YYYY (results in 29/nov./2013) too.

Same in French for all shorted strings... Why are you adding this dot everywhere ?


Ionic 2 Android build fails with error (Can't find google-services.json file)

Cordova version 7.010
Ionic 2
plugin version 2.0.0-rc2
I must be missing the obvious but I am having an issue with the following. Quote from your installation guide.

As of version 2.0.0 the SENDER_ID parameter has been removed at install time. Instead you put your google-services.json (Android) and/or GoogleService-Info.plist in the root folder of your project and then add the following lines into your plugin.xml.
In the platform tag for Android add the resource-file tag:

<platform name="android">
  <resource-file src="google-services.json" target="google-services.json" />
</platform>

Is this /plugins/phonegap-plugin-push/plugin.xml where I add the reference? In this case obviously google-services.json is not found and my build fails. I've tried putting the google-services.json in plugin folder but build still fails.
Thanks

@morariu first, upgrade to using 2.0.0-rc4 as it removes the hook that copies that file and may cause you some issues. Second, the resource-file tag should be in the android platform tag in your config.xml file. Make those changes and let me know how it goes.

Thanks @macdonst now I'm on 2.0.0-rc4
There is a conflict with https://github.com/arnesson/cordova-plugin-firebase such as:

If I add the resource-file tag in config.xml I get the google-services.json" already exists!
If I don't add the resource-file tag anywhere I am getting the following:

A problem occurred evaluating root project 'android'.
> Failed to apply plugin [id 'com.google.gms.google-services']
   > For input string: "+"

@morariu yeah, those two plugins won't co-exist right now. I should send them a PR request so they stop copying the file via a hook. The second issue you are running into is issue #1718 and I'm trying to figure out a way to fix that.


feat: Add truncate option to flush command

Fixes #680
Passing --truncate to flush command executes a truncate SQL statement, instead of deleting log records.

Thanks @BinDruid for this PR. I left some comments. Please address the coverage as well.
Then we are good to merge it.

@hramezani
I refactored the TruncateQuery class and added another test case to cover unsupported databases.

Thanks @BinDruid for the update.
Please add a change log entry in (CHANGELOG.md)[https://github.com/jazzband/django-auditlog/blob/master/CHANGELOG.md].
Sorry, I forgot to mention it before.

Thanks @BinDruid


IGNITE-17368 Remove obsolete GridClient JDBC driver

Thank you for submitting the pull request to the Apache Ignite.
In order to streamline the review of the contribution
we ask you to ensure the following steps have been taken:
The Contribution Checklist

[ ] There is a single JIRA ticket related to the pull request.
[ ] The web-link to the pull request is attached to the JIRA ticket.
[ ] The JIRA ticket has the Patch Available state.
[ ] The pull request body describes changes that have been made.
The description explains WHAT and WHY was made instead of HOW.
[ ] The pull request title is treated as the final commit message.
The following pattern must be used: IGNITE-XXXX Change summary where XXXX - number of JIRA issue.
[ ] A reviewer has been mentioned through the JIRA comments
(see the Maintainers list)
[ ] The pull request has been checked by the Teamcity Bot and
the green visa attached to the JIRA ticket (see TC.Bot: Check PR)

Notes

How to Contribute
Coding abbreviation rules
Coding Guidelines
Apache Ignite Teamcity Bot

If you need any help, please email<EMAIL_ADDRESS>or ask anу advice on http://asf.slack.com #ignite channel.

Please take a look at classes from the org.apache.ignite.internal.processors.cache.query.jdbc package.
GridCacheQueryJdbcMetadataTask
GridCacheQueryJdbcTask
GridCacheQueryJdbcValidationTask
It seems we should consider to remove them as well.


Starting a kernel that isn't the latest ipykernel breaks all of lab

Starting a kernel that isn't the latest ipykernel breaks all of lab (the kernel will not start after the following error: UNKNOWN CONTROL MESSAGE TYPE: 'usage_request'). Fixing it requires a server restart

Reopening as the current fix does not seem to work in some cases.

Reopening, I can now reproduce the issue on my env.

The env is highly env sensible. For now the jupyter server extension is checking the version with https://github.com/Quansight/jupyterlab-kernel-usage/blob/cfe4033671cb7b534bf9032bf2ce1769d80a55d3/jupyterlab_kernel_usage/handlers.py#L16
This works fine assuming the adminstrator installs the same ipykernel version in the server env as the one effectively running (could be a remote one, or a process started in another env).


Implement Cookie based User session Handling

Description
A clear and concise description of what the PR does.

This PR does the following:

Adds ... Added CookieBanner Component and the CSS for the CookieBanner component
Fixes ... Fixed the Cookie for User session handling
Updates ... Added the CookieBanner Component

Related Issues
Link any related issues using the format Fixes #issue_number.
This helps to automatically close related issues when the PR is merged.

Placeholder: "Fixes #137"

Changes
List the detailed changes made in this PR.

Added a new feature by adding the Cookie based user session handling
Refactored the cookie
Fixed a bug in ...

Testing Instructions
Detailed instructions on how to test the changes. Include any setup needed and specific test cases.

Pull this branch.
Run npm install to install dependencies.
Run npm test to execute the test suite.
Verify that ...

Screenshots (if applicable)
Add any screenshots that help explain or visualize the changes.

Additional Context
Any additional context or information that reviewers should be aware of.

This PR is based on the following...

Checklist
Make sure to check off all the items before submitting. Mark with [x] if done.

[x] I have performed a self-review of my code
[x] I have commented my code, particularly in hard-to-understand areas
[x] My changes generate no new warnings
[x] I am working on this issue under GSSOC

Hello @Trisha-tech I have completed this issue and have raised the PR few weeks ago.But still not merged this PR.


Remove background of Avalonia's UpdateAvailableWindow

For dark mode compatibility and easier use (won't have to set UpdateWindowGridBackgroundBrush). Breaking change.
See also #351

Note that UseStaticUpdateWindowBackgroundColor is false in the 3.x preview versions (for Avalonia 11), so this won't be an issue by default in the future, so this is effectively fixed!


SparseArrays Interface

Keep track of missing SparseArrays function(alitie)s:

[ ] sprand
[ ] sprandn
[ ] Some alternative to sparse
[ ] spzeros(?)
[ ] spdiagm
[ ] blockdiag
[ ] rowvals
[ ] nzrange
[ ] droptol!
[ ] dropzeros[!]
[ ] permute[!] (not sure best way to implement this)

Closing this here. Some sort of SparseArrayCompatGB.jl will do this since the semantics of GraphBLAS and SparseArrays do not admit a common interface.


⚠ Garbage Collector has degraded performance

In afa49cf, Garbage Collector (https://gc.fef.moe/login) experienced degraded performance:

HTTP code: 200
Response time: 6649 ms

Resolved: Garbage Collector performance has improved in 8cee85e.


Add test suite for Vector2

Creates test_vector2.h
Adds test_vector2.h to test_main.cpp
Adds a whole bunch of tests in test_vector2.h

Part of https://github.com/godotengine/godot/issues/43440

This will conflict with #34668.

This will conflict with #34668.

Hi, how so? Is it the string representation?

Hi, I added some changes to fix the format and consistency issues @Calinou.
@aaronfranke is the conflict related to the string representation?

@JoseTMonagas Yes. I can adjust my PR if this is merged first, or I think it would be better to do it the other way around, but I want to make sure whoever merges this is aware of both PRs.

@aaronfranke Ok, I have no problem updating this for the conflict, it's also gonna be useful to have in mind when I do Vector3 as well.

@aaronfranke Updated with the fix, could you review it?

@Calinou  This is ready to be merged after #34668, I want to work on vector3 and Vector datatype, but ideally this would be done in another branch, can I branch of this same branch or do I have to wait for this to be merged so I can rebase master?

@Calinou This is ready to be merged after #34668, I want to work on vector3 and Vector datatype, but ideally this would be done in another branch, can I branch of this same branch or do I have to wait for this to be merged so I can rebase master?

Since the pull requests can be merged (almost) independently of each other, I recommend using separate branches based on master for each pull request. (Don't open pull requests directly from the master branch or you won't be able to update it until your pull request is merged.)

@Calinou @fire I updated the pr to make it mergeable regardless of whether it's merged before or after #34668.
I'll go around doing this change to my other Vectors PRs.

@aaronfranke Is this fully superseded by d9506cade1b52c31d4ead9b6f764bacb91bdca65, or are some tests in this PR worth salvaging?

In some ways, the tests here are more extensive than what we have. Namely, the tests that were merged don't include any tests for the comparison operators. This PR also has more tests for methods we already have tests for, I'm not sure if we need the additional tests, it depends if the extra tests are showing different use cases.
@JoseTMonagas Sorry for the extreme delay in reviewing this. If you are interested, you can salvage some of these tests and add them to the tests that are now in our codebase, and we can get them reviewed relatively quickly.

I'll close for now as this can't be merged as is, but a new PR to add/improve relevant tests from this PR (as well as #48063 and #48138) would be welcome. This can be done either by @JoseTMonagas if you're still around and motivated, or any other interested contributor.


Disallow a registry URI to be used as the namespace

Do not allow the namespace to be set to any namespace used by a SynBioHub repository.

Should likely disallow both http and https versions.

Done.  Both http and https variations are disallowed.


Blazor component should start rendering only after OnInitAsync is completed

Describe the bug
Currently, when we override component's OnInitAsync, blazor will render components immediately after sync part of [OnInitAsync] completes, and then wait for its async part completion and rerender component.
While the name [OnInitAsync] means that the component is still initializing and not ready, then it should also not be rendered.
Expected behavior
Component should wait for [OnInitAsync] to complete and then start its first rendering. If we put async code in this lifecyle, it would means that component needs some more data to be ready.

I think it is not a bug. With this behaviour component have a chance to display some info to the user like "loading data". Component is automatically rerendered when OnInitAsync is finished.

Like @Andrzej-W mentioned, this behavior is by design to allow rendering of content before the component has been initialized.

Was this changed? Currently when I'm running async function in OnInitAsync method the browser is just loading until the data is fetched.

I second to that. Something got broken in Preview 7. If I go to Blazor @page using GET (not by click) then the following occurs:

sync part of OnInitAsync gets executed
rendering is called afterwards as expected but NO output is sent to browser, Browser is waiting for response.
when the async part of OnInitAsync completes then rendering occurs again and only then the output is sent to browser.

This is apparently a bug which I have filed.

This is apparently a bug which I have filed.

@KrystofZacek What is the issue number for the issue you filed for this?

I guess it is 676312. It is still marked as new.
https://developercommunity.visualstudio.com/content/problem/676312/blazor-oninitasync-method-not-rendering-asynchrono.html

@KrystofZacek Thanks for reporting this issue!  Would you mind opening the same issue here in this GitHub repo? For Blazor framework related problems we track the issues here. You'll get a faster response that way.

No problem:
https://github.com/aspnet/AspNetCore/issues/12866


Panic when using double nested numerical accessors for structs

Rustfmt can't parse nested structs nested numerical accessors for structs
File will not parse when it contains a line like let turnirs_instances = Turnirs::get(&mut conn, info.0.0).unwrap();. Note the variable info which contains a single element, which in turn, also contains a single element. Both accessed via the index notation. The sample code, where I actually encountered the error is using Actix web framework but that is not what we should focus on.
To Reproduce
#[get("/{turnirsid}")]
pub async fn turnirs_single_handler(
    info: web::Path<(u32,)>,
    tmpl: web::Data<tera::Tera>,
) -> Result<HttpResponse, Error> {
    let mut conn = DB_WRAPPER.get_conn();

    // this is where the error happens
    let turnirs_instances = Turnirs::get(&mut conn, info.0.0).unwrap();
    let turnirs_results = Turnirs::count_turnirs_summary(&mut conn, info.0.0).unwrap();
    let mut context = Context::new();

    context.insert("turnirs", &turnirs_instances);
    // Note the incorrecto formatting below
    context.

    insert("turnirs_result", &turnirs_results);

    let s = tmpl
        .render("turnirs/turnirs_single.html", &context)
        .map_err(|_| error::ErrorInternalServerError("Template error"))?;

    Ok(HttpResponse::Ok().content_type("text/html").body(s))
}

If (for testing purposes) the variable accessor is changed to from info.0.0 to info.0 then the code snippet formats properly
Expected behaviour
#[get("/{turnirsid}")]
pub async fn turnirs_single_handler(
    info: web::Path<(u32,)>,
    tmpl: web::Data<tera::Tera>,
) -> Result<HttpResponse, Error> {
    let mut conn = DB_WRAPPER.get_conn();

    let turnirs_instances = Turnirs::get(&mut conn, info.0.0).unwrap();
    let turnirs_results = Turnirs::count_turnirs_summary(&mut conn, info.0.0).unwrap();
    let mut context = Context::new();

    // Note the code is formatted correctly here
    context.insert("turnirs", &turnirs_instances);
    context.insert("turnirs_result", &turnirs_results);

    let s = tmpl
        .render("turnirs/turnirs_single.html", &context)
        .map_err(|_| error::ErrorInternalServerError("Template error"))?;

    Ok(HttpResponse::Ok().content_type("text/html").body(s))
}

Meta
Note the edition only exists because of the async next to the function.
$ rustfmt src/views/same.rs --edition 2018
thread 'main' panicked at 'bad span: `.`: ``', src/tools/rustfmt/src/source_map.rs:52:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

rustfmt version: rustfmt 1.4.20-stable (48f6c32 2020-08-09)
From where did you install rustfmt?: rustup
How do you run rustfmt: rustfmt, cargo-fmt, via VSCode. all of them fail to parse the file with selectors like this.

A workaround is to use accessors like (info.0).0, but if it wasn't enforced by the compiler then I would not write this bug report.

Duplicate of #4355, resolved in the upcoming 1.4.23 release


Update keyword names that changed in new version

Keywords from getting started:
https://github.com/aparmendariz/mcf_docs/blob/27eea83c817133566aae2c143935c101d901d880/docs/source/getting_started.rst?plain=1#L217C1-L218C37
New keyword names:
https://github.com/aparmendariz/mcf_docs/blob/27eea83c817133566aae2c143935c101d901d880/docs/source/changelog.rst?plain=1#L87C1-L90C52
https://github.com/aparmendariz/mcf_docs/blob/27eea83c817133566aae2c143935c101d901d880/docs/source/changelog.rst?plain=1#L105C3-L110C1

Thanks for bringing this to my attention.
Fixed with 27d160b


Use typing.Self for @classmethod constructors

Change Summary
See https://peps.python.org/pep-0673/#use-in-classmethod-signatures

Related issue number

Checklist

[ ] Unit tests for the changes exist
[ ] Tests pass on CI and coverage remains at 100%
[ ] Documentation reflects the changes where applicable
[ ] changes/<pull request or issue id>-<github username>.md file added describing change
(see changes/README.md for details)
[x] My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

Please review

Great, thanks.


Improve documentation for using private registries

When updating k3s private registries configuration (under /etc/rancher/k3s/registries.yaml), one has to use the k3s crictl binary to verify the changes done to the containerd configuration.

Again, big thanks for this useful repository and your excellent quality documentation!
I have stumbled upon this problem when setting up my machine to pull our AWX EE from our private registry (hosted on an Harbor instance) whose TLS cert is signed by our custom CA.
It took me some time to realize I was not using the correct crictl binary to see my configuration changes. Indeed:
vrubiolo@awx:~$ cat /etc/rancher/k3s/registries.yaml
configs:
  registry.internal.domain:
    tls:
      ca_file: "/etc/ssl/our_cert_authority.pem"

vrubiolo@awx:~$ sudo /usr/local/bin/crictl info | jq .config.registry
WARN[0000] runtime connect using default endpoints: [unix:///var/run/dockershim.sock unix:///run/containerd/containerd.sock unix:///run/crio/crio.sock]. As the default settings are now deprecated, you should set the endpoint instead.
ERRO[0002] connect endpoint 'unix:///var/run/dockershim.sock', make sure you are running as root and the endpoint has been started: context deadline exceeded
{
  "configPath": "",
  "mirrors": null,
  "configs": null,
  "auths": null,
  "headers": null
}

(here it's actually unix:///run/containerd/containerd.sock which ends up being picked as the containerd runtime socket)
With the k3s binary however:
vrubiolo@awx:~$ sudo k3s crictl info | jq .config.registry
{
  "mirrors": {
    "docker.io": {
      "endpoint": [
        "https://registry-1.docker.io"
      ],
      "rewrite": null
    }
  },
  "configs": {
    "registry.internal.domain": {
      "auth": null,
      "tls": {
        "insecure_skip_verify": false,
        "caFile": "/etc/ssl/our_cert_authority.pem",
        "certFile": "",
        "keyFile": ""
      }
    }
  },
  "auths": null,
  "headers": null
}

This matches what can be found under /var/lib/rancher/k3s/agent/etc/containerd/config.toml too.
Maybe you had a particular containerd configuration on your machine that matched that of the embedded k3s one which allowed your command to succeed?

@vrubiolo
Thanks for improving the guide!
I've used containerd completely default and never faced that error message about socket. But yes the k3s crictl is quite simple than /usr/local/bin/crictl.
Let me check if it is reproducible on my side. Thanks!

@vrubiolo
Ah one thing, could you privide the OS and its version which you are using?

@vrubiolo Ah one thing, could you privide the OS and its version, and k3s version which you are using?

Of course:
vrubiolo@awx:~$ k3s --version
k3s version v1.19.15+k3s1 (e698d6d8)

vrubiolo@awx:~$ cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.4 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.4 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

@vrubiolo
Hmm, this cannot be reproduced with:

Ubuntu 20.04  w/ K3s v1.19.15+k3s1
Ubuntu 20.04  w/ K3s v1.22.7+k3s1
CentOS Stream 8 w/ K3s v1.22.7+k3s1

I guess your /usr/local/bin/crictl is not the one which came with K3s...? Ensure your /usr/local/bin/crictl is the symbolic link to k3s.
$ ls -l /usr/local/bin/crictl
lrwxrwxrwx 1 root root 3 Apr 17 04:33 /usr/local/bin/crictl -> k3s

This symbolic link was created via K3s installer: https://github.com/k3s-io/k3s/blob/3e3549e45cb98c100f040ed915ce01b2997eeb4a/install.sh#L586-L598
And just F.Y.I., the allowed path for sudo is a bit different between CentOS and Ubuntu, so for CentOS, the crictl and k3s have to be specified with absolute path if they are used with sudo. This is why my guide uses absolute path since my guide is based on CentOS.

Ubuntu# /usr/local/bin is allowed for sudoers
$ sudo grep secure_path /etc/sudoers
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

# crictl and k3s can be used with command name only with sudo
$ sudo crictl version
Version:  0.1.0
RuntimeName:  containerd
RuntimeVersion:  v1.4.9-k3s1
RuntimeApiVersion:  v1alpha2
$ sudo k3s --version
k3s version v1.19.15+k3s1 (e698d6d8)

CentOS# /usr/local/bin is NOT allowed
$ sudo grep secure_path /etc/sudoers
Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin

# So the command can NOT be used with command name only with sudo
$ sudo crictl version
sudo: crictl: command not found
$ sudo k3s --version
sudo: k3s: command not found

# Absolute path is required for sudo
$ sudo /usr/local/bin/crictl version
Version:  0.1.0
RuntimeName:  containerd
RuntimeVersion:  v1.5.9-k3s1
RuntimeApiVersion:  v1alpha2
$ sudo /usr/local/bin/k3s --version
k3s version v1.22.7+k3s1 (8432d7f2)
go version go1.16.10

@kurokobo
Thanks for your time taken doing this analysis!
Indeed in my case crictl is not a symlink to k3s:
vrubiolo@awx:~$ /usr/local/bin/crictl --version
crictl version v1.22.0
vrubiolo@awx:~$ ls -al /usr/local/bin/crictl
-rwxr-xr-x 1 vrubiolo users 45611187 Aug  5  2021 /usr/local/bin/crictl

This is surely where the issue was coming from. Also, the fact that the machine is running k3s 1.19 and that crictl is 1.22 (whereas it moves in lockstep with Kubernetes) shows that the binary actually came from somewhere else.
With the symlink in place, this now works correctly:
vrubiolo@awx:~$ ls -al /usr/local/bin/crictl
lrwxrwxrwx 1 root root 18 Apr 20 12:12 /usr/local/bin/crictl -> /usr/local/bin/k3s

vrubiolo@awx:~$ sudo /usr/local/bin/crictl info | jq .config.registry
{
  "mirrors": {
    "docker.io": {
      "endpoint": [
        "https://registry-1.docker.io"
      ],
      "rewrite": null
    }
  },
  "configs": {
    "registry.internal.domain": {
      "auth": null,
      "tls": {
        "insecure_skip_verify": false,
        "caFile": "/etc/ssl/our_cert_authority.pem",
        "certFile": "",
        "keyFile": ""
      }
    }
  },
  "auths": null,

Let me know how you want to proceed, I can close this PR otherwise since the change is no more necessary.

@vrubiolo
Thanks for your contribution! If you have a time to spare, I would be very grateful if you could fix it by referring my comments.
I can modify it here after the merge, please let me know if it is hard for you.

@vrubiolo
Thanks for your contribution! If you have a time to spare, I would be very grateful if you could fix it by referring my comments.
I can modify it here after the merge, please let me know if it is hard for you.

@vrubiolo Added some trivial fixes and merged! Thanks for heads-up on this smiley

Thank you for doing this. Sorry I had meant to do it too and this slipped :pray: . At least it's in the tree now for others to use :+1:


Exend list formats to include json

Previously, though a --json flag existed for the list command, it would output YAML. This change adds a separate --yaml flag as well as corrects the behavior of --json. I have had to mix in the builder pattern with the derive pattern as I was unable to figure out how to do it otherwise.

I just realized that this behavior isn't quite correct. Specifically, defaulting to simple means that an Option isn't required.


Not able to log into mock with new account

Created a new account on mock via authenticator, set the secret and password.
Logged out.
Tried to log back in again and it tells me account does not exist. Tried twice with different passwords and still no success.

mock vault was corrupt. removing this fixed it


[Japscan.to] Captcha error

Hello,
great piece of code you have there.
When trying to download a random manga from Japscan, i'm faced with with a captcha error. Is it just me or is it a global issue ?
ERROR:root:"https://www.japscan.to/manga/perfect-world/" returned an error. Could not collect tokens.
CF error! Captcha

Looks like it's related to CloudFlare :(
It's CloudFlare issue, They update JS Challenges again.

Everything with CF can cause a 503 error.```

I've checked on Tachiyomi app (basically an android app that scraps from various websites), as they manage japscan also and it works like a charm (on github it looks like they updated their code for this https://github.com/inorichi/tachiyomi/commit/7551941ef22b6dda64f532e89ade19a8148cad13)

Any help ?
Thank you

Hello! A third-party library is used to solve the CloudFlare problem.
Please wait while they release the update.
Thanks for the insight.

I've updated the cloudscraper version to 1.1.39, now the command line returnes .... nothing :D
Anyway i'll wait for your update, thanks for your help !

returns .... nothing

In the near future I will update the provider.
(there have been changes on the site)
Now it is already working and ready for release, but I need to fix some more things in other places.
Thank you for your patience.

hi @sam5558
Tell me, is there a problem now?

Hello @1271 ,
After updating to the latest version of manga-py (<IP_ADDRESS>), it's now working again.
Thank you so much :+1:

Thanks for your support.


[CLI] wallet key generation

Implements #207
generates key pair with:
const keyPair = bls.generateKeyPair();

Converts to hex string with:
export function blsPrivateKeyToHex(privateKey: PrivateKey): string {
  const byteBuffer = Buffer.alloc(48, 0);
  privateKey.getValue().tobytearray(byteBuffer, 0);
  const pkBytes = byteBuffer.slice(16, 48);

  return "0x".concat(pkBytes.toString('hex'));
}

and then saves object with private key to file:
    const object = {
      privateKey: blsPrivateKeyToHex(keyPair.privateKey),
      // publicKey: keyPair.publicKey.toHexString()
    }

    try {
      fs.writeFileSync(options.outputFile, JSON.stringify(object, null, 2));
    } catch (err) {
      throw new CliError(`Failed to write to ${options.outputFile}: ${err}`);
    }

Testing includes basic registration of CLI command, testing to make sure writing cannot happen to existing file, and testing temporary bls key to hex conversion function as follows:
describe("BLSPrivateKeyToHex conversion", () => {
  it(" generated private key should equal original", () => {
    const keyPair = bls.generateKeyPair();
    const hexString = blsPrivateKeyToHex(keyPair.privateKey);
    const remadeKey = PrivateKey.fromHexString(hexString);
    assert(hexString === blsPrivateKeyToHex(remadeKey));
  });
});

That test is inefficient because it converts the privateKey to hex one extra time than necessary for comparison, but this was because I didn't know a good way to compare the two BIG variables together reliably.
Ignores publicKey for now, but I commented out the line that can be added in very easily to give a hex of the public key stored in the JSON file as well.

codeclimate issues are the same as previously marked as wont fix :)

Whats the status?

Sorry for the delay guys, got busy with another project. Here is the WIP for the class, let me know if you want me to move in a different direction with the class or have it have a different function than it currently has.
I was running into issues doing a readline password prompt using typescript which I will work on to finish this issue off, and complete any changes to the structure of this Keystore class you would like.

build failing because of e2e failing test, is there a way for me to rerun without pushing new commit?


[SPARK-5440][pyspark] Add toLocalIterator to pyspark rdd

Since Java and Scala both have access to iterate over partitions via the "toLocalIterator" function, python should also have that same ability.

Can one of the admins verify this patch?

Jenkins, this is ok to test.

Test build #26203 has started for   PR 4237 at commit 0cdc8f8.

This patch merges cleanly.

Test build #26203 has finished for   PR 4237 at commit 0cdc8f8.

This patch fails PySpark unit tests.
This patch merges cleanly.
This patch adds no public classes.

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

Test build #26240 has started for   PR 4237 at commit 1c58526.

This patch merges cleanly.

Test build #26240 has finished for   PR 4237 at commit 1c58526.

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

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

LGTM, so I'm merging this into master (1.3.0).  Thanks!


Add syntax highlight for other languages

People use several kinds of files in a project, e.g. Java, Markdown, HTML, CSS, JavaScript etc. It would be good to have syntax highlight feature for various file types.

Yeah this should be fairly easy to do. All non-clojure files are opened with CodeMirror, which has support for syntax highlighting in most langs, I just haven't looked into enabling it yet.

Added support for CSS, JS, markdown, sass, shell, sql, and xml/html in f0a5c89b00cd25b698751115e762e1462fe0e663. The codemirror CLJSJS library doesn't provide the java mode so I couldn't add it.


[porter/ghost] template deploy fails with InvalidTemplate error

Expected Behavior
Template deploys
Actual Behavior
{
  "telemetryId": "e7330939-30e7-4b66-a65b-0c4fb42ccfcd",
  "bladeInstanceId": "Blade_6d540c15b64b4b05b0e8897170c712c1_0_0",
  "galleryItemId": "Microsoft.Template",
  "createBlade": "DeployToAzure",
  "code": "InvalidTemplate",
  "message": "Deployment template language expression evaluation failed: 'Unable to parse language expression '': expected token 'Identifier' and actual 'EndOfData'.'. Please see https://aka.ms/arm-template-expressions for usage details.",
  "additionalInfo": [
    {
      "type": "TemplateViolation",
      "info": {
        "lineNumber": 0,
        "linePosition": 0,
        "path": ""
      }
    }
  ]
}

Steps to Reproduce the Problem

Go to https://github.com/Azure/azure-cnab-quickstarts/tree/master/porter/ghost
Click the Simple Deploy button
leave all options empty, but I typed cat ~/.kube/config | base64 --wrap=0 | pbcopy on my own machine to capture the required base64-encoded string without any returns and paste into the kubecon field
Profit

This was due to the fact that we had string parameters in the ARM template with value [], which ARM was trying to interpret as an empty expression.
I've updated the converter tool to handle the case for new quickstarts (it adds an extra [ to escape the open square bracket), and updated the existing quickstarts' ARM templates to comply.


Grid - Status Bar - Information of fetched rows

Hello,
in the Status Bar it is possible to get the following information since Version 21.3.3:
1 row(s) fetched - 9ms, on 2022-02-12 at 11:25:07
With Version 21.3.4 the format has changed to a not persistent storable format (Year is missing, Date is not sortable):
1 row(s) fetched - 9ms, on Feb 02 at 11:25:07
I hope you change the date format again to YYYY-MM-DD, or it is possible to set it in the preferences. I use this in my analyse code.
Furthermore, in the dialog "Status details" there should be a button with "Copy" like in the "Persist Changes" dialog.
And it would be very helpful, if there exists a shortcut to insert this information as comment in the "SQL editor".
(Alternatively, there exists a shortcut to copy this information to the clipboard - but the solution above is more helpful).
Thanks to implement this important feature.
BR
Günter

Is it possible to change the date format already in one of the next milestones? Would be very nice!

Hello @GuenterSch,
Currently, it's not possible.
We'll add a new preference to change the date format used in the status bar.

Let's write more verbose info in tooltip. In status bar we need in a short form

The date format 2022-07-25 12:48:56 (YYYY-MM-DD) has near the same size like Jul 25, 12:48:56.
But we have also the year and we have a standard output format (sortable).
In version 21.3.3 this format was already available.
Bug:
Since Version 22.1.1 it is not possible to open the Status Details. Therefore, I cannot copy this information any longer!


Customizing the legend manually.

At the moment, the legends are based on mappngs/scales. Beyond that, however, it would be nice to be able to create a legend completely manually, without being tied to other elements of the plot.
For example, I can build the next plot:

And I would like to add to it a legend like
<blue line> "A"
<red point> "B"

I can trick lets-plot the following way:

However it doesn't work well for other aesthetic attributes, so I would like to have a complete customization of the legend, regardless of data/layers/mapping/scales, etc.

@alshan we recognized that we really need this feature to implement series feature, we added a few weeks ago candlestick chart, and in some cases it looks sad without series support.
Could you please make the priority higher?

Available in v4.4.0.


Hook / Event System

Would provide an ample and powerful solution to many outstanding issues including #682 and #338 by having hooks / events that plugins can register functions on for listening or actionable purposes.
Hook Examples

PLUGIN_ENABLED
PLUGIN_DISABLED
PLUGIN_DELETED
API_CREATED
API_DELETED
API_UPDATED
CONSUMER_...
PROVISION
etc...

Effectively allowing plugins to do actions throughout kong, without kong being aware of the plugins existence or calling the plugin directly.
Some Use Cases

#338 (audit plugin) would just attach to all events and register the information as a log. done.
#682 (provisioning endpoint) each authentication plugin registers a provision function and handles the data passed accordingly to provision credentials.

These are just two, but there are countless more, even the #640 (slack integration) would benefit from hooks.

this might help; https://github.com/Olivine-Labs/mediator_lua

I'd say it looks overcomplicated for the very simple goal we are trying to achieve here. We simply want a hash table with keys being the event ids, and values being arrays containing functions to execute on a given key.
I can see a simple Lua module doing the job here.

I see what you mean. But in my experience, the simple module will quickly get a few feature requests and then ends up being a copy of an existing, fancier, module. It all depends on how confident you are that it stays "simple".
Also; this module is only 160 lines (126 sloc),

Yes you're right. We should consider it as an implementation. We would need some sort of wrapper around it though.

I think this needs some clarification that isn't introduced, this is not actually an event bus pattern.
It's more along the lines of a middleware pattern from node (for the lack of a better term, should anyone have one, I was looking into command pattern / etc).
Essentially to satisfy this ticket, you must be able to hook into a location in the code via a passed method, that method will be invoked when the block of code arrives at its execution point, and it will invoke (in order) each method which can then do its necessary actions, modify the result, and the chain continues to the next method in the hook chain.

There are many ways to do roughly the same thing. I think an important distinction here is whether the event handler (or hook) is trusted or not. If it's trusted, pass the full set of data along and let the handler decide whether or not to modify it (usually it will be tables, which are passed by reference anyway).
But if the code is not trusted, only a minimum set of data should be passed (by value, not by reference), and any results should be validated and copied back. Performance wise this is a tough one, considering deep copying of tables etc.
The first approach is far simpler of course... but because it is security related it is a rather fundamental choice.

I assume that plugins would be trusted or at least go through some form of audit (community, or developer).
I don't think we should waste our time with the copying mechanism, since the administrator of Kong would most likely only add trusted or self-created plugins.
I think this was a discussion previously brought up on plugins when separating them out and it is not really our concern.

It comes down to what your security philosophy is. So I guess it comes down to making a choice (Kong wide), document it, stick with it.
Anyway, my personal opinion is that I would leave it to the admin as to which plugins he/she wants to install. The complexity and performance hit will probably not be worth it.

So far for off-topic. On the event bus itself; the picture just registers callbacks for kong events (single producer, multiple consumer, hardly a bus).
Could it be useful to have any component register its own events (multi producer, multi consumer)? for example; a logger that subscribes to authentication events.

Anyway, my personal opinion is that I would leave it to the admin as to which plugins he/she wants to install. The complexity and performance hit will probably not be worth it.

:+1:

Could it be useful to have any component register its own events (multi producer, multi consumer)? for example; a logger that subscribes to authentication events.

If you pass along the hook mechanisms in the new ngx.ctx and kong.core (#736) (attach / create) then I wouldn't see why a plugin couldn't have them (in fact I would expect some to create their own so other plugins could also hook into them -- auditing plugin, etc)

Couldn't the event/hook system also resolve #267? (provided the hook mechanism is passed along to enable multi-producer/multi-consumer setups)

In 0.6.0 too.


add import/export price #1050

closes #1050

I think, we also need some axioms here. Unfortunately, import and export are not implemented yet, see #998.


exception-transformers <IP_ADDRESS> works with Stackage.

Checklist:

[X] Meaningful commit message - please not Update build-constraints.yml

[X] At least 30 minutes have passed since Hackage upload

[X] On your own machine, in a new directory, you have successfully run the following set of commands (replace $package with the name of the package that is submitted, $version is the version of the package you want to get into Stackage):
stack unpack $package-$version
cd $package-$version
stack init --resolver nightly
stack build --resolver nightly --haddock --test --bench --no-run-benchmarks

I'm not very familiar with Stackage, and I found the documentation confusing.  What else is required for bringing exception-transformers back to Stackage (or specifically, the packages that depend on it)?

@Athas just send more PRs uncommenting or removing the < 0 from any package that can be restored to Stackage. This PR is sufficient for restoring exception-transformers.


Bluetooth: host: Add ISO disconnect reason

Adds a disconnect reason in the ISO disconnect callback.
Signed-off-by: Emil Gydesen<EMAIL_ADDRESS>Fixes https://github.com/zephyrproject-rtos/zephyr/issues/33203

Was this API already part of Zephyr 2.5? If so it might be good to add a note of the API break into the release notes of 2.6 (this is not yet a stable API so I don't think any further actions are needed)

Was this API already part of Zephyr 2.5? If so it might be good to add a note of the API break into the release notes of 2.6 (this is not yet a stable API so I don't think any further actions are needed)

It was. I added a line in the release notes; please let me know if it was done correctly @jhedberg .


Angular-cli 6 and base-href no longer supported?

Versions
Angular CLI: 6.0.0-rc.5
Node: 9.11.1
OS: win32 x64
Angular: 6.0.0-rc.5
... animations, cli, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.5.7
@angular-devkit/build-angular     0.5.7
@angular-devkit/build-optimizer   0.5.7
@angular-devkit/core              0.5.7
@angular-devkit/schematics        0.5.7
@ngtools/json-schema              1.1.0
@ngtools/webpack                  6.0.0-rc.5
@schematics/angular               0.5.7
@schematics/update                0.5.7
rxjs                              6.0.0-uncanny-rc.7
typescript                        2.7.2
webpack                           4.5.0

Repro steps

change index.html e.g. to base href="/v2"
ng serve -bh /v2/ or ng serve --base-href /v2/
in angular.json: "styles": ["node_modules/[at]fortawesome/fontawesome-free-webfonts/scss/fontawesome.scss",....

Observed behavior
option -bh or --base-href is no longer supported
without this option e.g. fonts will not be loaded correctly if a link including the base-href is loaded in the browser:
GET http://localhost:4200/v2/fa-solid-900.woff net::ERR_ABORTED
if i type just "http://localhost:4200" without any base-href it will redirect to /v2 but the ressources will be loaded.

Desired behavior
What is the alternative implementation in angular6?

As far as I know, the number of options has been reduced. You should pass a configuration (e.g. --configuration v2) and add this configuration with its options to your angular.json:
{
  "serve": {
    "configurations": {
      "v2": {
        "servePath": "/v2"
      }
    }
  }
}

The schemas can be found in the @angular/devkit repo, e.g. https://github.com/angular/devkit/tree/master/packages/angular_devkit/build_angular/src/dev-server for ng serve.

hi thanks for you hint. the servepath doesn't helped here but i found now a way to fix the problem by adding this to angular.json:
      "architect": {
        "build": {
          "builder": "@angular-devkit/build-angular:browser",
          "options": {
            "baseHref" : "/v2/",
            "deployUrl": "/v2/",

i had to add baseHref and deployUrl instead of just bh in angular5

Note that you have to escape the path if you want to set this options programatically:
 ng config projects.demo.architect.build.options.baseHref "'/base/'"

@DaveXCS
Is this angular.json the one in the angular cli folder?
Changing the option would affect all projects when we use angular cli?

@DaveXCS it's not work for me
this is angular.json

and this is bundle index.html file

Is anyone checking this ticket? I'm having the same issues as @yangxiaolin

@yangxiaolin The angular.json file code section shows the e2e target not the build target.  Those settings shown have no effect on an ng build

@clydin thank you

Please provide the contents of the project's index.html file.

This is a quite complicated situation at least I see it like that. Just a small intro.
I have a MVC 5 appliaction with Areas. In all Areas that we have now we have Angular 1.x. Now we want to implement in the new area Angular 2+ with the help of Angular CLi as this is a prefered tool by angular, at least this is what is written there. Although it's inconsistent because they are saying let's say in VS configuration to use quickstart with system.js but on the page of quicstart they say it's depricated. ANYWAY, back to the subject. We focused on an idea to create an sepearte application per area. The general concept is in this stackoverflow threar: https://stackoverflow.com/questions/52519187/cannot-match-any-routes-url-segmentangular-main
Now I've managed to fix the problem with the error. I've added an empty index.html file to the application and then the error disapeared. I've tired to change the base href but still this does not help with loading fonts. In this case I'm using prime ng. Refering to your question my index file of the app is actually (at least I think so) is the Index.cshtml (razor view)  file not the index.html file. I've only added this to not have the error. Anyway the problem with not loading the fonts still exists. If this what I have written is understandable, then I would be more then happy to get any help :)

Someone can tell the real solution ?

APP_BASE_HREF with some "environment" variable

ng build --prod --base-href /my/app/

angular.json with baseHref and deployUrl

Wich is it ?

I'm sorry, but we can't reproduce the problem following the instructions you provided.
Remember that we have a large number of issues to resolve, and have only a limited amount of time to reproduce your issue.
Short, explicit instructions make it much more likely we'll be able to reproduce the problem so we can fix it.
If the problem persists, please open a new issue following our submission guidelines.
A good way to make a minimal repro is to create a new app via ng new repro-app and adding the minimum possible code to show the problem. Then you can push this repository to github and link it here.

Can you  respond to questions at least...

@alan-agius4 The issue is obviously not understood properly. Please provide clear guidance on how to utilize configuration options and/or cli arguments for base/baseHref. If this is no longer supported, the answer to this issue would be very simple. There is no need to reproduce anything.
Thanks!

I use ng build --prod --base-href=/administration/ command but it doesn't work correctly.
When I try with ng build --base-href=/administration/, it works well.
I am not sure why the production version doesn't work.
Thanks.

@nicky-lenaers and @WizardPC, let me start by making this clear baseHref/ base-href is still supported, both from configuration and from the CLI command as per documentation https://angular.io/cli/serve.
We are unable to reproduce the issue reported here. However, let's not forget that the issue reported here was for an early RC release on version 6, so bugs might have got solved in the meantime.
@WizardP, I am sorry, but how can I provide a solution for something that we cannot reproduce.
@BearandYoon, if you are experiencing an issue kindly open a new issue with a minimal reproduction.
You can read here why this is needed. A good way to make a minimal repro is to create a new app via ng new repro-app and adding the minimum possible code to show the problem. Then you can push this repository to github and link it here.


cd: create a gha that generate an index for each query in the src/sql folder

This PR aims to address part of #2.

[x] Manual trigger only for now

has additional triggers but no cron jobs

[x] Take all of the queries in the queries folder and run them

[x] create artifacts containing the result for each query saved as CSV and Parquet, files should be named consistently with the query file name and include IDC version in the file name by figuring out what idc_current maps to at the time the query is executed

[x] to get the number of the latest version of IDC, list all of the dataset in bigquery-public-data project and get latest idc_v*

leverages more efficient way by querying the table bigquery-public-data.idc_current.version_metadata to get the latest idc release

[x] create an issue that will include links to the artifacts generated by the GHA, title "[github-action] Index updates IDC v..." (something like that)

creates a pull request to update queries if they are outdated

[x] replace idc_current with the actual version in the query and save each of the queries as GHA artifact

queries will now have version explicity mentioned in them. I had to go this route as there is no otherway to know what we would be referring to. Previously idc-version in index.py was used as the baseline. However, in this repo, there is no such baseline. So I figured this may be the best way possible.

@jcfr I'm still figuring out how cmake works and am not completely sure if this is the best way to package the indices. As we are not uploading the indices as gh release attachments, I removed the download by urls and instead tried to package the generated indices as part of the  cd. I'm working on ci.yml too, but unable to figure out how to package the indices. Any guidance is much appreciated. https://github.com/vkt1414/idc-index-data/actions/runs/8288398907
@fedorov we may need to decide whether to keep both csv and parquet or choose one. In my opinion we should keep both and slowly phase out csv. Also, please let me know if this PR is satisfactory to the goals mentioned in #2
we will need to create a couple of secrets for this gha. A sample successful run is available here: https://github.com/vkt1414/idc-index-data/actions/runs/8289604309/job/22686311347

Well done moving forward,  I will review and help out tmrw.

I will spend more time reviewing, but few comments for now:

v18 CSV index is ~75MB compressed; I wonder if we should discuss what it would take to switch to Parquet only for v18? What are the challenges/downsides?
I noticed you have idc_v17 in the query - should that point to idc_current instead? I do not think the GHA should be updating the version in the query. The comment in the earlier discussion was to replace idc_currentwith the specific version and save the result as an artifact, so that the versioned queries could be included in the release for provenance of the packaged indices.

In light of the reogranization of the repositories by @jcfr, I think we should revisit the original plan outlined in https://github.com/ImagingDataCommons/idc-index-data/issues/2#issuecomment-1989574256.
In particular, as I understand it, there is no need anymore to attach index files as release artifacts. They can be uploaded directly to PyPI as part of the package.  This would also make it unnecessary to create an issue
Maybe we should have one workflow with manual trigger to generate results of running the query, as you did it - this will be useful to verify everything works as expected before preparing the package - and then another one that would be triggered on the creation of the release (as done in idc-index) that will upload the package to PyPI?

Suggestions:

Add scripts directory
Move src/sql/idc_index.sql to scripts/sql/idc_index.sql
Move and rename from .github/get_latest_index.py to scripts/idc_index_data_manager.py
Add code currently associated with initialize_idc_manager_class step of cd.yml as a function to idc_index_builder.py
Update CMakeLists with code similar to the following:find_package(
  Python
  COMPONENTS Interpreter
  REQUIRED)

set(IDC_INDEX_DATA_VERSION "17")

if(NOT DEFINED ENV{GCP_PROJECT_ID})
  message(FATAL_ERROR "GCP_PROJECT_ID env. variable is not set")
endif()

option(IDC_INDEX_DATA_GENERATE_PARQUET "Generate idc_index.parquet file" OFF)

set(download_dir "${PROJECT_BINARY_DIR}")

add_custom_command(
   OUTPUT
     ${download_dir}/idc_index.csv.zip
     $<$<BOOL:IDC_INDEX_DATA_GENERATE_PARQUET>:${download_dir}/idc_index.parquet> \
   COMMAND Python::Interpreter -m idc_index_data_manager \
     --generate-csv-archive \
     $<$<BOOL:IDC_INDEX_DATA_GENERATE_PARQUET>:--generate-parquet> \
     --version ${IDC_INDEX_DATA_VERSION}
   ...

Revert back change from cd.yml
Add dedicated workflow (e.g called bump-version.yml) that will get latest version, get current version from CMakeLists.txt (by parsing it using a regex), and if it applies, update CMakeLists.txt and create a pull request

After that, we will add the bump-version.yml workflow to effectively detect that a new version if available and release it as well.

Can you clarify what you mean by this? Effectively detect new version of what and in which package?

Can you clarify what you mean by this? Effectively detect new version of what and in which package?

The bump-idc-data-index-version.yml workflow would be scheduled to run at given frequency (daily, weekly or monthly), it would then do the following:

call retrieve_latest_idc_release_version^1
extract version from CMakeLists.txt
if version are different, create a pull request with the update.

The bump-idc-data-index-version.yml workflow would be scheduled to run at given frequency (daily, weekly or monthly), it would then do the following:

I see. We considered this approach before, but at this point I do not believe this is a good approach. First, IDC releases do not happen frequently - once every 1-3 months. So there is no significant burden to respond to IDC version updates manually. Second, new IDC releases will have new data or schema updates, that may break assumptions, or produce index that is too large, or I do not know what else that we can't anticipate. Because of this, it is safer to manually test the queries, and consider the result of the query before publishing.
I would prefer to have:

a manually-triggered workflow that would run the queries and generate artifacts for examination and release preparation
automatic workflow that would be triggered on creation of a release that would generate the index based on the current content of the queries and publish the package on PyPI

@jcfr I was finally able to call the python script directly from cmake, cleaned up data manager.py and cd heavily. I realized I was very far your vision about using cmake to handle index generation but am also slowly understanding how pyproject.toml, cmake, and hynek/build-and-inspect-python-package gha combination are working. Thanks for your patience. The latest iteration addresses most of the things Andrey would like. I hardcoded to generate both CSV and parquet as I realized we will be hardcoded even in cmake lists.

One more update: After including the GCP authentication step, CI is also working on all combinations from python 3.8-.12 on latest mac, ubuntu, and windows. However pypi 3.10 on latest ubuntu did not work and logs did help to troubleshoot, so I disabled pypi-3.10 for now.
latest CI run: https://github.com/vkt1414/idc-index-data/actions/runs/8376050860

For the reference, this PR was needed to fix the CI failure due to inability to access GHA secrets from the PR submitted from a fork of the repo: https://github.com/ImagingDataCommons/idc-index-data/pull/7.

The issue with the current approach is that wheels are not reproducible and the content of the index file being generated depend on time at which they are generated.

@jcfr this is a very good point. I did not consider that it is important for the wheel packaging process to be reproducible.

revisit the versioning from being "number" based to be date based (e.g YYYY.MM.DD.N)

The current approach of using IDC data release version as the major version of the package is exactly the purpose of enabling reproducibility. I would argue that mapping the date to the IDC release version is not trivial. But if the user knows the IDC data version, this is all that is needed to make queries reproducible.
Thinking about this a bit more, we could modify the queries to have, for example {idc_versioned_dataset} in place of idc_current, and replace that placeholder with the IDC version based on the idc-index-data major release number. So, for example, if the user generates release tag 17.2.10, GHA workflow would pick 17, replace the dataset name in each of the queries with idc_v17, run queries, and package+publish the result into idc-index-data v17.2.10.

for example {idc_versioned_dataset} in place of

Indeed, that would be similar to the use of @IDC_TABLENAME@ discussed in https://github.com/ImagingDataCommons/idc-index-data/pull/5#discussion_r1527111484
For convenience, supporting --output-sql-query would also be nice to have.

version

Extracting the major version and map it to the name of the table is an option. For this to work, we would need to also customize the versioning with the following settings:
[tool.setuptools_scm]
version_scheme = "no-guess-dev"

The "challenge" with relying only on the tag is that we would have no way of testing the generation of a wheel associated with a new version of the index by simply creating a pull request, indeed a new tag and release would have to be created first without if it actually work.
To address this I would instead suggest to hard-code the major version in the CMakeLists.txt as we originally discussed.

The "challenge" with relying only on the tag is that we would have no way of testing the generation of a wheel associated with a new version of the index by simply creating a pull request, indeed a new tag and release would have to be created first without if it actually work.
To address this I would instead suggest to hard-code the major version in the CMakeLists.txt as we originally discussed.

If all of the solutions we discussed involve manually updating the version, can't we simply hardcode the idc version in the sql query itself?

If all of the solutions we discussed involve manually updating the version, can't we simply hardcode the idc version in the sql query itself?

I have a draft of bump function for addressing this and allow updating files using nox -s bump (query the latest) or nox -s bump -- <version>
Before moving forward, we really need @fedorov to integrate https://github.com/ImagingDataCommons/idc-index-data/pull/8 as none of the code in this pull request is being tested.

@jcfr that PR is integrated now, please go ahead or let us know what we should do to fix this.

@jcfr I recall when we met last time you mentioned that one could handle packaging with just python, and CMake is not critical. Maybe you can comment on that a bit. I do not want to derail the current development, but also I do not know if learning CMake is a worthwhile investment of effort for Vamsi. Just wanted to raise the idea if he could understand the alternatives better.

re: CMake vs Python

Ditto. A pure python plugin can be written to implement similar behavior, there is some hints in the "Discussions" section of one of our recent scikit-build meeting^1
Given my limited experience with such hatch plugin, I suggest we move forward with CMakeLists.txt and consider revisiting afterward. Revisiting later will be much easier as we will have a working system.
Also worth noting that I expect the CMakeLists.txt to remain small and be straightforward to maintain.

re: permission error

For now, it suggest we create the branch feat-cd-2 directly into the repo and not from a fork.

Closing. This pull request is superseded by https://github.com/ImagingDataCommons/idc-index-data/pull/9


Update create config map with rancher fields and update for details

https://xd.adobe.com/view/5bfd9046-4985-4203-68ec-57f7f0a7eae2-2dcc/

Closing in favor of https://github.com/rancher/dashboard/issues/265#issuecomment-618162746 which contains feedback on create/edit and details.


(chores) camel-core: tests cleanups

remove unnecessary override
simplify list creation
use try-with-resources

Also, @essobedo and everyone else: please do continue reviewing. Just keep in mind that sometimes I may need to merge ealier (to ensure it gets into the next CI build - where we have most of the instability) and save fixes for later.
On these tests alone there are more than 11.000 items to review. So, simple ones or more likely to cause instability goes first, and more elaborate and not-so-easy to automate go later, as I need to balance getting the cleanup done with my availability to backtrace and bisect the changes in case of problems in the future.


pvf function call issue

Trying to compile the attached jsfx plugin with pvf, I encounter the following error:
Compiling Plugin...

""""" Plugin Compilation Success """""

Compiling...

""""" Compilation Success """""

Compiling DLL file... vocalrediso ...

vocalrediso.cpp: In member function 'virtual void pvf_EffectClass::processDoubleReplacing(double**, double**, VstInt32)':
vocalrediso.cpp:1744:84: error: no matching function for call to 'pvf_EffectClass::pvf_ProcessAudio(double [2], double* [2], VstInt32&, VstInt32&)'
   SamplePos += pvf_ProcessAudio(pvf_SamplesIn,pvf_SamplesOut,SamplePos,sampleFrames)+1;
                                                                                ^
vocalrediso.cpp:1334:10: note: candidate: 'VstInt32 pvf_EffectClass::pvf_ProcessAudio(double**, VstInt32, VstInt32)'
 VstInt32 pvf_EffectClass::pvf_ProcessAudio (double** outputs,VstInt32 SamplePos,VstInt32 sampleFrames)
          ^~~~~~~~~~~~~~~
vocalrediso.cpp:1334:10: note:   candidate expects 3 arguments, 4 provided

***** Error *****

vocalrediso.zip

I think that the following:
#IfDef pvf_USE_SPL_IN Then
Public FUNCTION pvf_ProcessAudio (outputs As Double Ptr Ptr, SamplePos As VstInt32, sampleFrames As VstInt32) As VstInt32
#Else
Public FUNCTION pvf_ProcessAudio (inputs As Double Ptr, outputs As Double Ptr Ptr, SamplePos As VstInt32, sampleFrames As VstInt32) As VstInt32
#End If

should instead be
#Ifdef pvf_USE_SPL_IN
Public FUNCTION pvf_ProcessAudio (inputs As Double Ptr, outputs As Double Ptr Ptr, SamplePos As VstInt32, sampleFrames As VstInt32) As VstInt32
#Else
Public FUNCTION pvf_ProcessAudio (outputs As Double Ptr Ptr, SamplePos As VstInt32, sampleFrames As VstInt32) As VstInt32
#EndIf

coming soon fixed 64 version


fix: 🐛 Setting query as changed on funnel step title change

Codecov Report

Merging #211 (92ea9fc) into develop (97d26ea) will decrease coverage by 0.01%.
The diff coverage is 33.33%.

@@             Coverage Diff             @@
##           develop     #211      +/-   ##
===========================================
- Coverage    86.53%   86.51%   -0.02%
===========================================
  Files          492      492
  Lines         6223     6224       +1
  Branches       588      588
===========================================
  Hits          5385     5385
- Misses         768      769       +1
  Partials        70       70

Impacted Files
Coverage Δ

...idgetEditor/components/QueryEditor/QueryEditor.tsx
78.57% <33.33%> (-2.92%)
:arrow_down:

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 97d26ea...92ea9fc. Read the comment docs.


Custom achievements aren't written to chat or discord

I am using the Create mod which has custom achievements. When I unlock one it shows me the popup window but nothing gets logged to chat or discord.

Wrong repo, sorry!


remove the base64 encoding of fileIDs

Description
Backport of #2542

@labkode @ishank011 I think this is an important backport from the edge branch.

I guess those changes in edge branch are not relevant here in master?

Yes, correct.

@ishank011 @labkode This could break your bookmarked URLs of the bookmarks and the ID lookup of the app provider.
You decide, if you need this in master. Reva edge has it already.


Integrating ESLint and prettier for code quality and consistency

Resolves: #91
This PR integrates ESLint and prettier to our workflow for code quality, consistency and formatting.
This is a common practice in TypeScript projects and it will also ensure the maintainability, readability and cleanliness of the code.
run npm run format for formatting and npm run lint for linting
I have added basic settings for now that can be changed as per preference and I didn't run the commands before this PR as it would make the diff very large and make the PR harder to review

Thanks so much this idea is great to have well-formatted code 🎉

Glad to be able to contribute!


Revert "lemmy: Support secret options"

Description of changes
Revert "lemmy: Support secret options"
This reverts commit ee5cc38432031b66e7fe395b14235eeb4b2b0d6e (https://github.com/NixOS/nixpkgs/pull/239713).
Merging declarative NixOS configuration with out of store files is something that, afaik, we don't do anywhere else.
This breaks normal purity/reproducibility guarantees offered by the NixOS module system.
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Merging declarative NixOS configuration with out of store files is something that, afaik, we don't do anywhere else.

The first 9 results of my search for jq in NixOS modules yield two modules which does this: transmission and invidious.

This breaks normal purity/reproducibility guarantees offered by the NixOS module system.

Currently, secrets has to be out of store.  Many modules provide a path option to let users specify a secret which will not be put into the store.
I am not sure what your point is.

Are you against merging two json files and preferring to use utils.genJqSecretsReplacementSnippet which I mentioned in https://github.com/NixOS/nixpkgs/pull/239713#discussion_r1243502258 ?
Are you against managing secrets out of store?

I think we all agree that the ideal solution should be that upstream reads secrets from files, the question is what do we do before that happens ?

we do this a whole lot, so much so that there's a utils.genJqSecretsReplacementSnippet helper for exactly this kind of thing. the alternative is to pretty much not have secrets support, which is a lot worse than even a one-off solution like this.

I proofread every single module I use and have never encountered this pattern before.
Regardless of previous usage this is bad as it's not a granular secrets injection feature but overrides the whole darn config.
Despite the option naming implying this is a secrets feature, it's not, it's an impure configuration feature.

After some discussion in the NixOS Dev matrix channel I've come up with a succinct problem description:
It's a problem of an unbounded impurity vs a bounded one.
The current semantics are "merge declarative NixOS configuration with yeet config" which is too much.
If this was a granularly scoped option only allowing you to point to an impure secret, not an entire config it would be much better.

I understand your concerns, I threw inspiration from services.nextcloud.secretFile which does something similar.
For lemmy it should be possible to limit the secret configuration to the following secrets:

database.uri (maybe just database.password?)
pictrs.api_key
email.smtp_password
setup.admin_password

Would it be ok if each secret gets its own option?
I would be willing to work on a new PR.

FYI, https://github.com/NixOS/nixpkgs/pull/241562