Correct RHS by subtracting RHS of a steady state solution

Some simulations (like the baroclinic instability, for which I specifically implemented this feature in #979) rely on a steady state being preserved for a long time, while the solution is only slightly diverging from the steady state.
If these simulations have a source term that causes well-balanced errors, it may be necessary to use a relatively high resolution just to preserve the steady state. This problem can be mitigated by evaluating and saving the RHS of the exact steady-state solution at the beginning of the simulation, and subtracting it in every RHS evaluation. By construction, this steady state will then be preserved exactly (to machine rounding errors, of course).
The baroclinic instability, for example, produces entirely unusable results for a resolution of 8x8x4 cells per cube face with a polydeg of 3. Only with a polydeg of 4 or higher, the results are slowly becoming usable.
This feature makes even the polydeg 3 simulation produce usable (although badly resolved) results, and eliminates most of the grid imprinting in the polydeg 4 simulation.
Here is a comparison of the polydeg 3 simulation with (right) and without (left) this feature.

Here is a picture of how it's supposed to look like (16x16x8 cells per cube face, polydeg 5). Note that this is probably not at the same simulation time (I had these pictures lying around). This picture is just to show that the right picture looks surprisingly good.

Do we want to have this feature in Trixi?
#979 contains a proof-of-concept implementation of this feature.

I'm not sure whether we really need this feature since it's basically a couple of lines like
u0 = compute_coefficients(semi, 0.0)
let du_baseline = similar(u0)
  Trixi.rhs!(du_baseline, u0, semi, 0.0)
  global function corrected_rhs!(du, u, semi, t)
    Trixi.rhs!(du, u, semi, t)
    du .-= du_baseline
  end
end
ode = ODEProblem(new_rhs!, u0, semi, tspan))

From my point of view, this appears to be a very specialized feature that quite easy to implement in an elixir - if somebody knows what they want to have, it's clear what to do.

Wow, this is amazing! I haven't even remotely thought about doing something like this. That's way easier and cleaner than the stuff I did in my PR. Right now, I don't need it to work with AMR. Maybe we can come up with a solution that allows for AMR later.
Why exactly do we need the let block here?

Why exactly do we need the let block here?

We don't need it to make this work, just to make it fast since we would be using a non-constant global variable (du_steady_state) without the let block.

I see, thanks! This one's as fast as my complicated implementation in #979:
u_steady_state = compute_coefficients(steady_state_baroclinic_instability, 0.0, semi)
let du_steady_state = similar(u_steady_state)
  Trixi.rhs!(du_steady_state, u_steady_state, semi, 0.0)

  global function corrected_rhs!(du, u, semi, t)
    Trixi.rhs!(du, u, semi, t)
    Trixi.@trixi_timeit Trixi.timer() "rhs correction" begin
      @batch for i in eachindex(du)
        du[i] -= du_steady_state[i]
      end
    end
  end
end

u0 = compute_coefficients(0.0, semi)
ode = ODEProblem(corrected_rhs!, u0, tspan, semi)


Use i18n with pluralization support

E.g. https://www.i18next.com/
Multiple plugins for vue.js available: https://www.i18next.com/overview/supported-frameworks

Most probably its wise to use https://github.com/panter/vue-i18next


Webpack-based build process

As a typical Vue user, I would like to use the animated-vue plugin directly in the browser, following the spirit of Vue itself.

Need to learn how to use webpack (or maybe borrow build scripts for other vue plugins such as vue-material and create scripts to transform this library into a browser-compatible product.

In v0.5.2 we've enabled umd as the package's output so it can now be loaded in the browser!


Coral-Trino: Add with_timezone wrapper while casting timestamp to decimal

As discussed in https://github.com/trinodb/trino/pull/9530#discussion_r723399144
We need to add a wrapper with_timezone"(..., 'UTC') before calling to_unixtime, so it is timezone agnostic like how #109 did.

@losipiuk ptal


Publish PDS base image for PDS 0.35.0

Situation
PDS 0.35.0 has been  released, but no PDS base image for this version has been pushed to github packages
Wanted
Have a base image available for PDS version 0.35.0

Has been done, release is available at
https://github.com/mercedes-benz/sechub/pkgs/container/sechub%2Fpds-base/71336522?tag=v0.35.0


Document escape method

Documents escape as suggested in https://github.com/domchristie/turndown/pull/244#issuecomment-401743977
/cc @MartinBenninger Let me know if you have any further suggestions.

This looks great to me. I think it does a good job clarifying the escaping behavior. Thanks for adding it. :+1:


[storage-file-datalake] Migrate to core-tracing GA

Packages impacted by this PR
@azure/storage-file-datalake
Issues associated with this PR
Fixes #21315
Describe the problem that is addressed by this PR
This PR migrates to core-tracing GA and updates tests accordingly.
Provide a list of related PRs (if any)
https://github.com/Azure/azure-sdk-for-js/pull/24773
https://github.com/Azure/azure-sdk-for-js/pull/24548
https://github.com/Azure/azure-sdk-for-js/pull/24850

API change check
API changes are not detected in this pull request.


Endpoints?

None of the endpoints in this document seem to match/work.
For retrieving Environments for example, the document states to use:
GET /admin/v2.0/applications/BusinessCentral/environments
Which results in 404 errors
However, the following Endpoint does to generate the expected result:
GET /v1.2/admin/applications/BusinessCentral/environments
Full Uri:
GET https://api.businesscentral.dynamics.com/v1.2/admin/applications/BusinessCentral/environments
What are we missing about the endpoint Urls?

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

ID: 75c4240e-3064-4e29-63cf-202b47e86c96
Version Independent ID: fa3bfa13-4b7b-011c-62a6-1baa9aab4792
Content: Business Central Administration Center API - Business Central
Content Source: dev-itpro/administration/administration-center-api.md
Service: dynamics365-business-central
GitHub Login: @edupont04
Microsoft Alias: solsen

Hello, thanks for your feedback. I believe there is an update on the way for this topic including this: GET GET /admin/v2.0/applications/environments. The topic will be refreshed asap. Thanks.


Better documentation

Now that the library is starting to grow a bit, it needs more in-depth documentation. A couple things to consider;

Extend #2 with more examples in the documentation itself
Potentially generate documentation with GitHub Pages / Jekyll
Include links to official Prismic documentation
Include some best practices with using Prismic with Nuxt
Include some more information about where the project is headed (e.g. roadmap)

Initial set of documentation complete. Should be available on prismic-nuxt.js.org in a couple of days.


Show Python method's API documentation from a URL on hover in VSCode

Allow user to configure VSCode to point toward a URL containing a Python method's online documentation so the online documentation appears on hover.
For example, PyTorch API Docs are hosted online and the method hierarchy is simple to navigate. When I hover of a method from the PyTorch library, I'd like to see the API documentation from that URL, not just the various method signatures.
This feature is available to Java Developer using Eclipse: The user can configure Eclipse to pull API documentation from a URL (e.g., the List API JavaDocs) on a project-by-project basis by configuring the JavaDocs in the project's build path. Here's an example of the popup that shows up in Eclipse for the List.of() method:

Notice that along with the method signature is a short description of the method ("returns an unmodifiable list...") along with additional helpful information (e.g., Type parameters, Parameters, and Returns)
To clarify: I'm not only looking for a popup showing the method signature(s), but also the associated documentation hosted at an online url. For example: VSCode only displays the method signatures for torch.rand(), but the PyTorch API documentation includes the full description.

The standard way for tools to obtain documentation for Python library types/methods/etc is via docstrings. PyTorch does include docstrings for some things. Here's an example:

But they seem inconsistent with their docstrings. Looking at their issue tracker, they have a fair number of bugs on missing docstrings. They also encourage users to submit PRs with docstring fixes. So you could help them there.
I also saw some cases (example) where the TYPE_CHECKING version of a function does not have a docstring whereas the non-TYPE_CHECKING version does. They apparently do not realize that TYPE_CHECKING is used by language servers in addition to command line type checkers.


chore: split Algebra.Bounds and Algebra.Order.Pointwise

Delete Algebra.Bounds and Algebra.Order.Pointwise. Create

Algebra.Order.Field.Pointwise for lemmas about pointwise operations in linear ordered fields
Algebra.Order.Group.CompleteLattice for distributivity of group operations over supremum/infimum
Algebra.Order.Group.Pointwise.Bounds for boundedness of pointwise-defined sets
Algebra.Order.Group.Pointwise.CompleteLattice for lemmas about the supremum/infimum of pointwise-defined sets.

bors merge


HypERC20 & HypErc20Collateral & extensions w/o ERC721s

TODO:

Deal with function overrides
Vault extension
More tests for EnumerableMap
Ensure deployment/initialization patterns provide desired behaviour

Leave the initializers and let's try to have a 1:1 translation Sol -> Cairo.
The overrides as of now will not be applied to TokenRouter


Question: Capture specific logs for a given container?

Hi all,
Following this example:
https://github.com/splunk/splunk-connect-for-kubernetes/blob/develop/helm-chart/splunk-kubernetes-logging/examples/use_logs.yaml
I have some logs (log1 and log2) that live in acontainer at path /opt/containername/.  I've SSH'd into the container and verified the path to these logs.
I want to tail these logs.  In my values.yaml I've defined this snippet:
logs:
  container-name:
    from:
      file:
        path: /opt/containerName/log1.log

Retrieving the logs of the splunk-connect pod that lives on the same node as the container:
2019-12-17 21:35:16 +0000 [warn]: #0 /opt/containername/log1.log not found. Continuing without tailing it.
Any guidance would be appreciated.
Thanks!
AJ

Hello,
the file should be the splunk-connect-logging pod. Not just any container.
do you still see the file in that path of splunk-connect pod?

Thanks for the quick response.  I'm a little new to this.  Is this something I have to configure on fluentd to forward these logs?

Normally, have you application print logs to standard out, then the rest is automatically handled by kubelet and docker.
when application is run inside container by docker, docker will write all printed logs to a file. ie) /var/lib/docker/container//.-json.log
Kubelet also creates symlinks of these files under /var/log/pod/... and /var/log/container/....  when this docker container is created through kubernetes.
Then this connector will read all these container log files and send it to splunk.


fix: placeholder texts being parsed as links

Proposed changes (including videos or screenshots)

This change adds a restriction to the parser grammar in order to prevent placeholder texts (e.g {{visitor.name}}) from being rendered as links.
Before:

After

:

Issue(s)

Further comments

We found this pull request won't be necessary anymore.


feat(test): add compactor to deterministic test

I hereby agree to the terms of the Singularity Data, Inc. Contributor License Agreement.
What's changed and what's your intention?
This PR adds compactor node to deterministic e2e test and makes sure we use the same configuration as the normal e2e test.
This PR also disables moka cache and RwTracingService in simulation test. Because they will internally create system threads that bring potential uncertainties and resource leak thus should not be used in the simulation.
Besides, we will run deterministic tests multiple times on CI, trying to catch those rarely occurring bugs.
Checklist

[x] I have written necessary rustdoc comments
[x] I have added necessary unit tests and integration tests
[x] All checks passed in ./risedev check (or alias, ./risedev c)

Refer to a related PR or issue link (optional)

After you've updated any software in build env, you'll need to bump image version so as to rebuild everything. See https://github.com/singularity-data/risingwave/pull/4478 for example.

Sorry I found that I also gets things wrong in https://github.com/singularity-data/risingwave/pull/4478. Please refer to https://github.com/singularity-data/risingwave/pull/3611/ instead.


Peers disconnected due to network issues will not reconnect

This error was not intentional, it has occurred during normal execution. I suspect that there could be a network issue between two nodes which caused exception to be thrown and peer to get disconnected.
I would expect the connection to be reopened after period of time.
Node folder with logs: https://stratisplatform-my.sharepoint.com/:u:/p/maciej_zaleski/ER9M1-0qK-RGoE4BcIbZSZYB7T6i34eiG6G-PKBp0W74CQ?e=5WmqDx
   --- End of inner exception stack trace ---
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.GetResult(Int16 token)
   at System.Threading.Tasks.ValueTask`1.ValueTaskSourceAsTask.<>c.<.cctor>b__4_0(Object state)
--- End of stack trace from previous location where exception was thrown ---
   at Stratis.Bitcoin.P2P.Peer.NetworkPeerConnection.ReadBytesAsync(Byte[] buffer, Int32 offset, Int32 bytesToRead, CancellationToken cancellation) in C:\Code\InternalTestnet_Data\Sources\StratisBitcoinFullNode\src\Stratis.Bitcoin\P2P\Peer\NetworkPeerConnection.cs:line 404
[2018-11-03 03:14:17.8203 81] TRACE: Stratis.Bitcoin.P2P.Peer.NetworkPeerConnection+<ReadMagicAsync>d__34.MoveNext (-)$exception:System.IO.IOException: Unable to read data from the transport connection: Operation canceled. ---> System.Net.Sockets.SocketException: Operation canceled
   --- End of inner exception stack trace ---
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.GetResult(Int16 token)
   at System.Threading.Tasks.ValueTask`1.ValueTaskSourceAsTask.<>c.<.cctor>b__4_0(Object state)
--- End of stack trace from previous location where exception was thrown ---
   at Stratis.Bitcoin.P2P.Peer.NetworkPeerConnection.ReadBytesAsync(Byte[] buffer, Int32 offset, Int32 bytesToRead, CancellationToken cancellation) in C:\Code\InternalTestnet_Data\Sources\StratisBitcoinFullNode\src\Stratis.Bitcoin\P2P\Peer\NetworkPeerConnection.cs:line 404
   at Stratis.Bitcoin.P2P.Peer.NetworkPeerConnection.ReadMagicAsync(Byte[] magic, CancellationToken cancellation) in C:\Code\InternalTestnet_Data\Sources\StratisBitcoinFullNode\src\Stratis.Bitcoin\P2P\Peer\NetworkPeerConnection.cs:line 374
[2018-11-03 03:14:17.8203 81] TRACE: Stratis.Bitcoin.P2P.Peer.NetworkPeerConnection+<ReadMessageAsync>d__33.MoveNext (-)$exception:System.IO.IOException: Unable to read data from the transport connection: Operation canceled. ---> System.Net.Sockets.SocketException: Operation canceled
   --- End of inner exception stack trace ---
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.GetResult(Int16 token)
   at System.Threading.Tasks.ValueTask`1.ValueTaskSourceAsTask.<>c.<.cctor>b__4_0(Object state)
--- End of stack trace from previous location where exception was thrown ---
   at Stratis.Bitcoin.P2P.Peer.NetworkPeerConnection.ReadBytesAsync(Byte[] buffer, Int32 offset, Int32 bytesToRead, CancellationToken cancellation) in C:\Code\InternalTestnet_Data\Sources\StratisBitcoinFullNode\src\Stratis.Bitcoin\P2P\Peer\NetworkPeerConnection.cs:line 404
   at Stratis.Bitcoin.P2P.Peer.NetworkPeerConnection.ReadMagicAsync(Byte[] magic, CancellationToken cancellation) in C:\Code\InternalTestnet_Data\Sources\StratisBitcoinFullNode\src\Stratis.Bitcoin\P2P\Peer\NetworkPeerConnection.cs:line 374
   at Stratis.Bitcoin.P2P.Peer.NetworkPeerConnection.ReadMessageAsync(ProtocolVersion protocolVersion, CancellationToken cancellation) in C:\Code\InternalTestnet_Data\Sources\StratisBitcoinFullNode\src\Stratis.Bitcoin\P2P\Peer\NetworkPeerConnection.cs:line 325
[2018-11-03 03:14:17.8203 81] TRACE: Stratis.Bitcoin.P2P.Peer.NetworkPeerConnection+<ReadAndParseMessageAsync>d__36.MoveNext (-)$exception:System.IO.IOException: Unable to read data from the transport connection: Operation canceled. ---> System.Net.Sockets.SocketException: Operation canceled
   --- End of inner exception stack trace ---
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.GetResult(Int16 token)
   at System.Threading.Tasks.ValueTask`1.ValueTaskSourceAsTask.<>c.<.cctor>b__4_0(Object state)
--- End of stack trace from previous location where exception was thrown ---
   at Stratis.Bitcoin.P2P.Peer.NetworkPeerConnection.ReadBytesAsync(Byte[] buffer, Int32 offset, Int32 bytesToRead, CancellationToken cancellation) in C:\Code\InternalTestnet_Data\Sources\StratisBitcoinFullNode\src\Stratis.Bitcoin\P2P\Peer\NetworkPeerConnection.cs:line 404
   at Stratis.Bitcoin.P2P.Peer.NetworkPeerConnection.ReadMagicAsync(Byte[] magic, CancellationToken cancellation) in C:\Code\InternalTestnet_Data\Sources\StratisBitcoinFullNode\src\Stratis.Bitcoin\P2P\Peer\NetworkPeerConnection.cs:line 374
   at Stratis.Bitcoin.P2P.Peer.NetworkPeerConnection.ReadMessageAsync(ProtocolVersion protocolVersion, CancellationToken cancellation) in C:\Code\InternalTestnet_Data\Sources\StratisBitcoinFullNode\src\Stratis.Bitcoin\P2P\Peer\NetworkPeerConnection.cs:line 325
   at Stratis.Bitcoin.P2P.Peer.NetworkPeerConnection.ReadAndParseMessageAsync(ProtocolVersion protocolVersion, CancellationToken cancellation) in C:\Code\InternalTestnet_Data\Sources\StratisBitcoinFullNode\src\Stratis.Bitcoin\P2P\Peer\NetworkPeerConnection.cs:line 433
[2018-11-03 03:14:17.8203 81] TRACE: Stratis.Bitcoin.P2P.Peer.NetworkPeerConnection+<ReceiveMessagesAsync>d__29.MoveNext [7-[::ffff:<IP_ADDRESS>]:16178] Exception occurred: 'System.IO.IOException: Unable to read data from the transport connection: Operation canceled. ---> System.Net.Sockets.SocketException: Operation canceled
   --- End of inner exception stack trace ---
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.GetResult(Int16 token)
   at System.Threading.Tasks.ValueTask`1.ValueTaskSourceAsTask.<>c.<.cctor>b__4_0(Object state)
--- End of stack trace from previous location where exception was thrown ---
   at Stratis.Bitcoin.P2P.Peer.NetworkPeerConnection.ReadBytesAsync(Byte[] buffer, Int32 offset, Int32 bytesToRead, CancellationToken cancellation) in C:\Code\InternalTestnet_Data\Sources\StratisBitcoinFullNode\src\Stratis.Bitcoin\P2P\Peer\NetworkPeerConnection.cs:line 404
   at Stratis.Bitcoin.P2P.Peer.NetworkPeerConnection.ReadMagicAsync(Byte[] magic, CancellationToken cancellation) in C:\Code\InternalTestnet_Data\Sources\StratisBitcoinFullNode\src\Stratis.Bitcoin\P2P\Peer\NetworkPeerConnection.cs:line 374
   at Stratis.Bitcoin.P2P.Peer.NetworkPeerConnection.ReadMessageAsync(ProtocolVersion protocolVersion, CancellationToken cancellation) in C:\Code\InternalTestnet_Data\Sources\StratisBitcoinFullNode\src\Stratis.Bitcoin\P2P\Peer\NetworkPeerConnection.cs:line 325
   at Stratis.Bitcoin.P2P.Peer.NetworkPeerConnection.ReadAndParseMessageAsync(ProtocolVersion protocolVersion, CancellationToken cancellation) in C:\Code\InternalTestnet_Data\Sources\StratisBitcoinFullNode\src\Stratis.Bitcoin\P2P\Peer\NetworkPeerConnection.cs:line 433
   at Stratis.Bitcoin.P2P.Peer.NetworkPeerConnection.ReceiveMessagesAsync() in C:\Code\InternalTestnet_Data\Sources\StratisBitcoinFullNode\src\Stratis.Bitcoin\P2P\Peer\NetworkPeerConnection.cs:line 132'
[2018-11-03 03:14:17.8203 81] TRACE: Stratis.Bitcoin.P2P.Peer.NetworkPeer.Disconnect (reason:'Unexpected exception while waiting for a message',exception:System.IO.IOException: Unable to read data from the transport connection: Operation canceled. ---> System.Net.Sockets.SocketException: Operation canceled
   --- End of inner exception stack trace ---
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.GetResult(Int16 token)
   at System.Threading.Tasks.ValueTask`1.ValueTaskSourceAsTask.<>c.<.cctor>b__4_0(Object state)
--- End of stack trace from previous location where exception was thrown ---
   at Stratis.Bitcoin.P2P.Peer.NetworkPeerConnection.ReadBytesAsync(Byte[] buffer, Int32 offset, Int32 bytesToRead, CancellationToken cancellation) in C:\Code\InternalTestnet_Data\Sources\StratisBitcoinFullNode\src\Stratis.Bitcoin\P2P\Peer\NetworkPeerConnection.cs:line 404
   at Stratis.Bitcoin.P2P.Peer.NetworkPeerConnection.ReadMagicAsync(Byte[] magic, CancellationToken cancellation) in C:\Code\InternalTestnet_Data\Sources\StratisBitcoinFullNode\src\Stratis.Bitcoin\P2P\Peer\NetworkPeerConnection.cs:line 374
   at Stratis.Bitcoin.P2P.Peer.NetworkPeerConnection.ReadMessageAsync(ProtocolVersion protocolVersion, CancellationToken cancellation) in C:\Code\InternalTestnet_Data\Sources\StratisBitcoinFullNode\src\Stratis.Bitcoin\P2P\Peer\NetworkPeerConnection.cs:line 325
   at Stratis.Bitcoin.P2P.Peer.NetworkPeerConnection.ReadAndParseMessageAsync(ProtocolVersion protocolVersion, CancellationToken cancellation) in C:\Code\InternalTestnet_Data\Sources\StratisBitcoinFullNode\src\Stratis.Bitcoin\P2P\Peer\NetworkPeerConnection.cs:line 433
   at Stratis.Bitcoin.P2P.Peer.NetworkPeerConnection.ReceiveMessagesAsync() in C:\Code\InternalTestnet_Data\Sources\StratisBitcoinFullNode\src\Stratis.Bitcoin\P2P\Peer\NetworkPeerConnection.cs:line 132)
[2018-11-03 03:14:17.8203 81] TRACE: Stratis.Bitcoin.P2P.Peer.NetworkPeer.Disconnect [7-[::ffff:<IP_ADDRESS>]:16178] (-)[DISCONNECTED]```

@maciejzaleski those exceptions are pretty standard when a peer disconnects from another. Unless the peer got banned OR the selection algorhythm in PeerSelector filters the peer I cant see a reason why it wont connect again.
Can you see in the peers.json file for this peer if it has been banned? Maybe post its json content here.

This seems to be normal behaviour, the peer discovery on node DA is unable to find anything to connect to because it has banned DB for 24 hours:
[2018-11-03 03:14:17.8015 149] TRACE: Stratis.Bitcoin.Connection.PeerBanning.BanAndDisconnectPeer (endpoint:[::ffff:<IP_ADDRESS>]:16178,reason:'Peer violates max reorg rule.')
[2018-11-03 03:14:17.8015 149] TRACE: Stratis.Bitcoin.Connection.PeerBanning.BanAndDisconnectPeer (endpoint:[::ffff:<IP_ADDRESS>]:16178,banTimeSeconds:86400,reason:'Peer violates max reorg rule.')


Create a greetings.yml file

Hello!
I would like to create a yml-file with greetings for new visitors on this repository. I have already used this action in my own projects.

Do you can help me?

We used to have something similar https://github.com/python-discord/bot/pull/1028#issuecomment-653923366, not sure what happened to it though.
If we add this I think it should be to give useful information. It does add some clutter to the issue/PR so i'm not sure it's worth it.
On sir-lancebot we use issue/pr templates instead https://github.com/python-discord/sir-lancebot/tree/main/.github.

Okay.

I don't see much of a reason for adding this at the moment, so i'll close this


Use atom.commands.add to subscribe commands

Fixes #3
Fixes #2
I replaced the deprecated methods Atom::workspaceView and
Workspace::getActiveEditor.  I also added subscribers, so the commands
can be disposed of when closing the editor.

Are you able to work on this package?  If not, I can take over for you.

Thank you !


Screenreader not reading app header*

*This may be app specific and not an issue with the frame?
When using VoiceOver or NVDA, the screenreader is not "seeing" the app header.

I believe with the new material header this is now fixed. Tested in VoiceOver


"AudioDeviceID doesn't exist" error on setting inputs

I'm on Ventura 13.0.1. Listing and setting output seems ok, but with input, I'm seeing errors like:
❯ switch-audio --list-input
[{"id":115,"name":"R-Phonak hearing aid","type":"input","isDefault":false},{"id":104,"name":"MacBook Pro Microphone","type":"input","isDefault":true}]

~
❯ switch-audio --set-input=115
The AudioDeviceID doesn't exist!

~
❯ switch-audio --set-input=104
The AudioDeviceID doesn't exist!

Hello, thanks for the info. Should be fixed now. Please let me know if it works for you.

It works! Thanks for this little tool.
In case you're curious, I use it because my hearing aids can act as both input and output. When I connect them to my laptop, macOS automatically sets them to both.
Unfortunately, hearing aid mics are (deliberately?) not designed for picking up your OWN voice, so I almost never want to use them over the built-in mic for input. So I've been messing with Shortcuts and Shortery to cobble together something that undoes it. I was using Applescript to script System Settings, but that all broke with Ventura, and I couldn't find a good debugger.


Iceberg resource strange behaviour

Parts of the iceberg resource spawn missing when on chunk boundaries (red line is the chunk border):

Using replaceblocks on it causes parts of it to spawn missing (replacing parts of it to blue ice in this screenshot):

Replacedblocks weren't being picked up properly for Iceberg(), should be fixed for 0.0.19.


CUB device_reduce and size_t

cc @leofang @jakirkham
Continuing the discussion in #3117

@kmaehashi This is not a bug in CuPy, but at most a "defect" in CUB. I think it is best to bring this  issue to upstream (now it's thrust/cub) and ask the current maintainers to address it.

Yes and no.
Basically what they have said is they don't want to use a 64-bit type (sticking with a 32-bit type) due to register pressure. So this is something that we would have to workaround or override. This is is the "no" part 😉
That said, they are choosing to use a signed type where an unsigned type seems more appropriate. That sounds like a bug, but IDK what their plans are for addressing that.

Basically what they have said is they don't want to use a 64-bit type (sticking with a 32-bit type) due to register pressure. So this is something that we would have to workaround or override. This is is the "no" part 😉

From what an outsider can tell, I think the "they" has changed, so the new "they" may have different opinions 😉
If they do what I suggested (templated type), it wouldn't affect the normal usage or performance unless downstream consumers (i.e. us) explicitly overwrites it.

That said, they are choosing to use a signed type where an unsigned type seems more appropriate. That sounds like a bug, but IDK what their plans are for addressing that. Though this may be something we can override as well.

This will also be fixable with templated type.

Sorry for the lack of clarity. They means CUB developers.

Yeah I know, and I meant it seems Thrust folks have taken over the development & maintenance work from Duane?

I also discussed this with Bryce offline.

Cool. Keep us posted. If needed I can also raise a counterpart of NVlabs/cub#129 to thrust/cub.

The response was more-or-less the same. So I don't have more to add.
There doesn't appear to be an issue tracker for thrust/cub though.

Ah, they turned it off...Alright. What's their opinion toward a templated type for item size?

I hope I am pinging the right Bryce 😂 @brycelelbach, any comment for my suggestion to fix the issue on the item size type that John raised?

thrust/cub is just a temporary repo until we get a new GitHub org for both. We didn't want to turn issues on there. I hope to have this sorted out soon.

@griwes recently did a bunch of work to fix 32bit indexing issues in Thrust/CUB, I'll ask him to take a look at this.

Thanks, Bryce! Please keep us posted. 🙏

Hi folks,
I appreciate the suggestion mentioned above of "just" adding a template parameter and deducing a possibly larger size type, but not doing that was a conscious decision made by Duane (the original author of CUB), and I fully agree with it. I used to not be sure about it, but I've made a change that made certain Thrust algorithms unconditionally made a call into CUB with a 64-bit size type (I'll explain how in a moment), and benchmarked it against the "default" implementation... aaaaand it was about 10% slower. This may be a source-compatible change, but it's not ABI compatible, and it sure as day isn't performance-compatible ;)
Take the following preexisting (pseudo)code:
std::size_t size = ...;
char * buf = obtain_buffer(size);
cub::DeviceReduce::Reduce(..., buf, ..., size, ...);

This code used to use 32-bit signed integers as the indices; with the change you're suggesting, it now uses 64-bit unsigned integers. This is going to be a performance hit due to register pressure, and potentially a performance hit because the compiler is no longer allowed to assume that wraparound does not happen. Oops.
Now, was this code correct? Who knows. The problem is that a lot of code just indiscriminantly uses std::size_t for sizes, even if their problem sizes never approach the range of values representable by those types. I don't think that problem sizes upwards of 2^31-1 will be the majority of uses for CUB, so I don't believe that making those cases more convenient than the ones that do fit in an int is reasonable.
Now, CUB has two different layers of dispatching. Note how the full implementation of DeviceReduce::Reduce is actually... just a call to DispatchReduce<InputIteratorT, OutputIteratorT, OffsetT, ReductionOpT>::Dispatch. I don't think this layer is documented; we should probably think about doing that in the (near?) future. But it's the key to achieving what you want, and to what I did to make sure the Thrust uses of CUB algorithms don't exhibit weird bugs at 2^31-1 and up.
To dispatch across the different implementations based on the size at runtime, I used this simple dispatching macro (hopefully the comment quality in that file is good enough for you to grok the idea behind them; I tried to leave a trace that details what is going on). The use of it for reduce specifically is here (where Size in this context is actually deduced from the call site). On the path on which we know the size fits into int32_t, we just call the regular form of the CUB DeviceReduce entrypoint. On the path where we detected a size larger than the capacity of int32_t, we invoke the DispatchReduce entrypoint, forcing the size type to be what was deduced.
This may or may not be what you want to do; if you don't care about the absolutely highest performance possible, and do not want to compile all the CUB reduce kernels twice (for two different size types, which is the price we pay for having both correctness for large problem sizes and performance that is consistent with prior releases), you may just want to call into DispatchReduce<..., ..., std::size_t, ...>::Dispatch.
This is very similar for the other CUB algorithms.
Hopefully this helps ;)

Thanks Michał! So one question that comes up is why int32_t is used as opposed to uint32_t? Seems we would get 2x more values without leaving 32-bits. Guessing there is just something I'm not understanding here. Any thoughts you have would be appreciated 🙂

Hi @griwes, thanks a lot for your investigation and reply! In addition to John's nice question stemmed from our previous discussion, I have a few more questions:

I used to not be sure about it, but I've made a change that made certain Thrust algorithms unconditionally made a call into CUB with a 64-bit size type (I'll explain how in a moment), and benchmarked it against the "default" implementation... aaaaand it was about 10% slower.

Yes, we learned this fact from Duane's reply in https://github.com/NVlabs/cub/issues/129#issuecomment-393296009, and I myself also observed this register pressure issue in my CUB-related work.
What I suggested is to add a new template parameter to size type, but default it to int so as to ensure backward compatibility (in terms of both source and performance). So, for what you mentioned next

This may be a source-compatible change, but it's not ABI compatible, and it sure as day isn't performance-compatible ;)

I have trouble to understand it. Could you elaborate everything here (source/ABI/performace)?

Now, was this code correct? Who knows. The problem is that a lot of code just indiscriminantly uses std::size_t for sizes, even if their problem sizes never approach the range of values representable by those types. I don't think that problem sizes upwards of 2^31-1 will be the majority of uses for CUB, so I don't believe that making those cases more convenient than the ones that do fit in an int is reasonable.

To be clear, I am fully aware that using size_t is gonna hurt performance. The problem for library providers like CuPy is that there will always be users (aka John 😂) asking for this capability. Some of NVIDIA GPUs also have large enough memory to actually back arrays of size > 2^32 and small types (ex: half/int/float), so it's not physically impossible. Additional constraint for CuPy is it must be NumPy-complaint whenever possible, and NumPy does allow reductions over 2^31-1 elements. So, we need the freedom (not that we like it or would always use it) to sacrifice a little to some performance in exchange for better compliance and/or extended support, because there are use cases.

Now, CUB has two different layers of dispatching. Note how the full implementation of DeviceReduce::Reduce is actually... just a call to DispatchReduce<InputIteratorT, OutputIteratorT, OffsetT, ReductionOpT>::Dispatch. I don't think this layer is documented; we should probably think about doing that in the (near?) future.

Yes, declaring this layer as a part of stable, public API would make sense if you want advanced users to start from here; working on top of undocumented 3rd party API is not acceptable in production code, after all.
Actually, what you suggested is a variant of my suggestion: the interface is already there, all we need to is to make it public and defaulted to typename OffsetT=int. Of course, it's even better if you expose OffsetT one layer up to DeviceReduce and DeviceSegmentedReduce (and apply the default).

To dispatch across the different implementations based on the size at runtime, I used this simple dispatching macro (hopefully the comment quality in that file is good enough for you to grok the idea behind them; I tried to leave a trace that details what is going on). The use of it for reduce specifically is here (where Size in this context is actually deduced from the call site). On the path on which we know the size fits into int32_t, we just call the regular form of the CUB DeviceReduce entrypoint. On the path where we detected a size larger than the capacity of int32_t, we invoke the DispatchReduce entrypoint, forcing the size type to be what was deduced.

Thanks for the pointers, Michał! It's very useful for me. (I've been fairly familiar with CUB internals but it's less easy for me to dive into Thrust...)
However, for CuPy we have a simpler solution. All of our arrays live in Python and we know their sizes prior to invoking CUDA kernels, so the dispatcher could just live at the Cython level (or C++ as we currently do, it doesn't really matter). But in order to reduce performance hit for smaller arrays, we'll need the path splitting like yours indeed (including the double compilation you mentioned below), and it's actually what's already done in CuPy's internal (not involving CUB).

This may or may not be what you want to do; if you don't care about the absolutely highest performance possible, and do not want to compile all the CUB reduce kernels twice (for two different size types, which is the price we pay for having both correctness for large problem sizes and performance that is consistent with prior releases), you may just want to call into DispatchReduce<..., ..., std::size_t, ...>::Dispatch.

I think I replied to this part earlier. I can try to make it clearer if needed.
Thanks again 🙂

@griwes @brycelelbach Would be great if you folks could follow up this thread 🙂
@jakirkham @emcastillo The oversize reduction issue could be resolved by #3244.

Update: in #3562 we will disable large size (>2^31) CUB device reduction routines (those from cupy.cuda.cub), as they currently don't work anyway. If CUPY_ACCELERATORS="cub" is set, then it will fall back from those routines to the new block reduction implementation #3244, otherwise to CuPy's original reduction implementation. This will be a temporary workaround until CUB makes its internal interface that allows a size_t specialization (https://github.com/cupy/cupy/issues/3309#issuecomment-626073805) documented.

@leofang I'm unsure why you are blocked by the interface not being documented. It's a part of the public API and it's used by Thrust directly, so it's not going to go away or change.
Sorry I missed your question about suggestions earlier, I could swear I replied some time ago... No, we cannot bubble the template parameter up to the primary interface, because it'd then either:

Always be deduced to size_t for most folks because that's what the type they actually pass in is (and template argument deduction is ruthless, default parameters don't matter if they get deduced, or
Make that parameter the first template parameter for the primary interface, which would be a source code break if anyone tries to pass template arguments explicitly right now.

We could try to add some new overloads that require you to pass the offset type explicitly, though we'd need to be rather careful to not break any overload sets in the process. Please file an issue on github.com/thrust/cub if you'd like that, but I'd recommend that you proceed with just using the Dispatch layer directly.

Hi @griwes Thanks for replying!
To the public API thing: I personally would really love to take your words and start working on it 🙂 However, we need a stronger commitment from the Thrust/CUB team, in that it needs to be documented on http://nvlabs.github.io/cub/modules.html, which currently is not the case.
I understand that it being public is the status quo and that Thrust already uses it internally, but still I would like to see a stronger guarantee to downstream libraries, as Thrust/CUB are unified and free to change each other as needed.
Now, to the promotion to a template parameter, I didn't know this when I replied:

template argument deduction is ruthless, default parameters don't matter if they get deduced

I've been bullied by SFINAE lately, so I believe you're right...😂
Another action I'd like to see taken on the CUB side for strengthening the above guarantee is that oversize arrays indexed by size_t need to be tested more extensively. A quick grep does not show me any test case for this capability. Given my recent experience with failing to compile the CUB histogram support for size_t (which I fix in thrust/cub#38), I incline to think CUB does not treat this issue seriously (which was actually understandable given its design trajectory).
Finally, please poke @brycelelbach for me when you get a chance 😅 and ask him to open the issue tracker on https://github.com/thrust/cub, since it's currently disabled. My impression is that the issue tracker on the old repo NVlabs/CUB is almost abandoned and not monitored...I have a few other CUB-related things that I would like to discuss, but I need to know where to go. Don't wanna keep pinging you folks...
Thanks!

Thrust and CUB are addressing this issue on their end: https://github.com/NVIDIA/thrust/issues/1271, https://github.com/NVIDIA/cub/issues/212.


DEBUG windows docker build

Change Summary
Please summarise the changes this pull request is making here.
Checklist

[ ] Unit tests for the changes exist
[ ] Tests pass without significant drop in coverage
[ ] Documentation reflects changes where applicable
[ ] Test snapshots have been updated if applicable

Agreement
By submitting this pull request, I confirm that you can use, modify, copy and redistribute this contribution, under the terms of your choice.

As discussed on Slack offline, the windows issue is somewhat known...
https://github.com/docker-library/python/issues/359
Relevant discussion from the Python email list:
Note that in our first attempt there were only 12 root cacerts in the Windows certstore. Now it's 15. And the only difference is that in between we've made an SCHANNEL-based https connection to the google.de domain. (You can also see the additional root certificates via the certificates mmc consoles certlm.msc and certmgr.msc).

From now on all non-SCHANNEL based HTTPS connections via the Python 2/3 ssl standard lib work, as SCHANNEL has permanently placed the RootCA cert in the windows certstore:

c:\python27\python.exe
Python 2.7.15 (v2.7.15:ca079a3ea3, Apr 30 2018, 16:30:26) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket, ssl
>>> context = ssl.SSLContext(ssl.PROTOCOL_TLS)
>>> context.verify_mode = ssl.CERT_REQUIRED
>>> context.check_hostname = True
>>> context.load_default_certs()
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> ssl_sock = context.wrap_socket(s, server_hostname='www.google.de')
# got a certificate verify failed error here in the first try, this time the verify is successfull
>>> ssl_sock.connect(('www.google.de', 443))
>>> ssl_sock.close()


WIP: enable larger Rmax (up to half the box size)

In looking at the gridlink/cell pair code for #276, I was reminded that we are explicitly computing the offset between pairs of cells e.g. here: https://github.com/manodeep/Corrfunc/blob/c3e260d70888c2cdc9e772b5cd97e59068d2522e/utils/gridlink_impl.c.src#L504
Which made me think: if we know the offset of each cell pair, and that offset is applied in the kernels, then what's the harm in adding duplicate cell pairs? They will not find duplicate particle pairs, because a cell pair can be added at most once with a positive offset, and once with a negative.  So as long as we enforce Rmax < boxsize/2, there ought not to be duplicate counts.
So allowing duplicate cell pairs, the usual tests seem to be passing (but those have small Rmax). I did add a simple large Rmax test with two particles, which seems to work.
This is also related to the old issue #210. I did test that reproducer, which fails with an "Rmax too large" error in master but succeeds with this PR.
@manodeep Am I missing something? Is there a counterexample where this doesn't work?
This is relatively low priority, but it does relate to the question of the conditions to avoid duplicates in https://github.com/manodeep/Corrfunc/pull/276#issuecomment-1189176506 (or rather, removes that question entirely).

I don’t think we can add duplicate cell pairs.
Consider a set of points - one that is close to the left edge and another that is close to the right edge (and where Rmax << Lbox). If we add duplicate cell-pairs (with a positive and a negative offsets), then that particle pair would be counted twice.

But isn't the particle distance with the negative offset very small, and it is thus counted, and the distance with the positive offset very large, and thus not counted?
I implemented it as a test here: https://github.com/manodeep/Corrfunc/pull/277/files#diff-c7d4836bf94aa48cd9d4e4410ddab869be6ec08d83dfc0999ee5eac26cd8d30cR158
and it seems to work correctly. I may have misunderstood you, though. Could you look and see if the test is actually checking the scenario you had in mind?

The distance between the two points would be the same in both the positive and negative offset cases. In one case the particle close to the right edge is shifted by xwrap towards the left edge and therefore ends up to the left of the second particle.
For a more concrete 1D example, say two particles A and B are located at x_A = 0 + alpha, and x_B = Lbox - alpha.

For a positive offset, x_A would be shifted to x_A' = x_A + Lbox == Lbox + alpha => dx^2 = (x_B - x_A')^2 = (-2*alpha)^2
For a negative offset, x_B' = x_B - Lbox == -alpha => dx^2 = (x_A - x_B')^2 = (2*alpha)^2.

This new distance with the negative offset would be the same as computed for the positive offset case. Therefore, for an autocorr with duplicated cell-pairs, particle pairs would get repeated

Sorry, I think I confused the issue by saying "positive offset" and "negative offset". In the case of an autocorrelation, the negative offset is actually "no offset".  Offsets are only applied to achieve periodicity (as all particle positions are global), and one of the cell pairs crosses the wrap (the positive offset) and the other does not (no offset).
So in the two-particle example you gave, we have cell A and cell B.  The cell pair generation goes as:

We look for cell pairs using cell A as the primary, and find none because of the usual autocorrelation optimization to only consider half the cell pairs (icell < icell2 in the gridlink code).
We look for cell pairs with cell B as the primary, and find two:

One at index offset -1, which is not a negative positional offset but is zero offset, because we did not have to cross the wrap
One at index offset +1, which does have a positive offset because it cross the wrap.

Only the second cell pair brings the particles adjacent to each other, so only one particle pair is found, and the count is doubled at the end (the usual doubling since the autocorr considers half the particle pairs).
The cross-correlation case is the same, except we find two cell pairs that generate counts, and the counts are not doubled at the end.
So I think this all works because we know whether we had to cross the wrap to make a cell pair.  Thus "duplicate" cell pairs don't have the same positional offset.
I've stepped through the cell pair generation pretty closely, and I think the min-sep-opt will need to be re-validated for this PR to be production-ready. But the more I look at this, the more I think the basic principle is sound.

Hmm - I may have misunderstood - let me back up. I thought you were saying that adding duplicate cell-pairs was okay (i.e., adding both (cellA, cellB) and (cellB, cellA) as two separate cell-pairs) and would not result in duplicated particle pairs. Is that the case?

Yes, because any time we add a duplicate cell pair, it is with a different offset (xwrap value).

Not following then how you could avoid duplicate pair-counts if you add duplicate cell-pairs. Let's pretend that we manually add a duplicate cell-pair corresponding to a real one for an auto-corr calculation. In the case without any offsets (i.e., cell-pairs where no domain edges are crossed), how could you avoid duplicating the pair-counts that were already counted in the first real cell-pair?
In the extreme case, where there is only one cell in the domain, then duplicating the cell-pair (i.e., the self-cell-pair), would certainly result in duplicate particle pair counts.
I must be missing something :(

Oh, I definitely agree that if you add a truly identical cell pair—same icell & icell2, and same xwrap—you get duplicate particle counts! My point is just that generate_cell_pairs does not produce such truly identical pairs.
In fact, maybe this suggests the most conservative change is to adjust the duplicate detection to take into account the x/y/zwrap values. I've implemented this in the latest commit. I've also added tests for multiple combinations of bin refinement, max_cells_per_dim, min_sep_opt, and autocorr.  What do you think about this approach?

Hey @manodeep, have you had a chance to look at the new approach to this problem?

Thanks for your patience @lgarrison - on parental leave at the moment, so time is extremely limited.
I took another look at the PR - I am not really sure that I understand the improvement. Thus far, Corrfunc has required a minimum of 3 cells for any calculation - otherwise, it fails with "Rmax too large" error.
I am not seeing how a duplicate cell-pair could be added with different offsets. For an autocorr, a cell-pair (icell, icell2) should always be added with the same set of three offsets. The duplicate cell check macro only checks for the same cell-pair with the first cell as the primary cell - so the offsets should always be the same (i.e., there is no need to pass the xwrap into the macro). Now, if we consider the opposite cell-pair, i.e., (icell2, icell) then the relevant offsets would be negated but then would fail the icell2 > icell test. Once again, I feel that I am missing something ...and now I can blame the sleep-deprived brain :)

Thanks for your patience @lgarrison - on parental leave at the moment, so time is extremely limited.

Oh, no worries! There's no rush.

I took another look at the PR - I am not really sure that I understand the improvement. Thus far, Corrfunc has required a minimum of 3 cells for any calculation - otherwise, it fails with "Rmax too large" error.

The improvement is to remove this 3-cell minimum requirement, and thus allow all Rmax < L/2. It also simplifies the Rmax logic  when we have per-axis boxsizes, as in #276, which is why I started thinking about this.

I am not seeing how a duplicate cell-pair could be added with different offsets. For an autocorr, a cell-pair (icell, icell2) should always be added with the same set of three offsets. The duplicate cell check macro only checks for the same cell-pair with the first cell as the primary cell - so the offsets should always be the same (i.e., there is no need to pass the xwrap into the macro). Now, if we consider the opposite cell-pair, i.e., (icell2, icell) then the relevant offsets would be negated but then would fail the icell2 > icell test.

Consider the case of two cells, evenly dividing the box.  A particle pair could (1) straddle the boundary in the middle of the box, or (2) straddle the periodic wrap.  Thus, we want to add the pair (icell2, icell) in duplicate, with two different offsets: zero, and -L.  The zero offset will detect (1); the -L offset will detect (2).
(Recall the gridlink "offset" is the adjustment applied to the particle separations, rather than the distance between cell centers)
So that's why we want to add duplicate cell-pairs with different offsets: to detect both those cases. As you point out, icell2 will be the primary in both (1) and (2) because of the icell2 > icell test.
If you're asking if the duplicate macro check does anything at all, I think the answer is no! But it sounded like in https://github.com/manodeep/Corrfunc/pull/277#issuecomment-1195394749 you were concerned about adversarial examples, hence keeping the check in place.
This same example is stepped through more carefully in https://github.com/manodeep/Corrfunc/pull/277#issuecomment-1192830279. A version of this is also implemented here for concreteness.

Think I have finally understood where the update is relevant - the check for duplicate cells was throwing me off. If I understand correctly, the fix is relevant when the number of bins along any dimension is smaller than the 2*bin_refine_factor + 1 . Specifically, this would be relevant for cases with bin_refs = [1, 1, 1] but rmax such that only two cells are generated. In such a case, you want to add the cell-pair [0, 1] with no positional offset, and then add the (duplicate) cell-pair [0,1] but with a negative positional offset. That's why the duplicate check requires the xwrap/ywrap/zwrap. Have I understood correctly?
If so, then perhaps the check for duplicate cells could be modified to only run when nxbins <= 2*xbinref || nybins <= 2*ybinref || nzbins <= 2*zbinref?

@lgarrison Think I have finally understood where the update is relevant - the check for duplicate cells was throwing me off. If I understand correctly, the fix is relevant when the number of bins along any dimension is smaller than the 2*bin_refine_factor + 1 . Specifically, this would be relevant for cases with bin_refs = [1, 1, 1] but rmax such that only two cells are generated. In such a case, you want to add the cell-pair [0, 1] with no positional offset, and then add the (duplicate) cell-pair [0,1] but with a negative positional offset. That's why the duplicate check requires the xwrap/ywrap/zwrap. Have I understood correctly?

Yes, exactly!

If so, then perhaps the check for duplicate cells could be modified to only run when nxbins <= 2*xbinref || nybins <= 2*ybinref || nzbins <= 2*zbinref?

I think this is already the case. The check_for_duplicate_ngb_cells variable does exactly this test: https://github.com/manodeep/Corrfunc/pull/277/files#diff-96f43764787ed164aaf40bc5cb9f61d347d18e748d51a6b29346f3865392eb94R484-R487
So do you think this means this PR is ready to go? I think we can also close #276 pretty quickly after this is merged.

If so, then perhaps the check for duplicate cells could be modified to only run when nxbins <= 2*xbinref || nybins <= 2*ybinref || nzbins <= 2*zbinref?

I think this is already the case. The check_for_duplicate_ngb_cells variable does exactly this test: https://github.com/manodeep/Corrfunc/pull/277/files#diff-96f43764787ed164aaf40bc5cb9f61d347d18e748d51a6b29346f3865392eb94R484-R487

Can't tell what that code fragment points to and reading the macro definition didn't show any signs of the if condition I mentioned. What am I missing?

Now that I (mostly) understand what's going on, the changes seems good. Perhaps, add one more test with ~100 particle positions, say 50 each around [$0 \pm \delta$, $Lbox/2 \pm \delta$] mod Lbox and check that the pair counts from Corrfunc match those from a brute-force.

Good idea; I've added this test, comparing against brute force, and it passes.

Can't tell what that code fragment points to and reading the macro definition didn't show any signs of the if condition I mentioned. What am I missing?

Hmm, looks like that link is broken. Here is one that should work: https://github.com/manodeep/Corrfunc/blob/e45f5db100dcf4150854834454b9f4a7030e4f1f/utils/gridlink_impl.c.src#L484-L487
The macro is only called if this condition holds.

Thanks for your patience - yup, looks good to me now! Once the CI passes, this can be merged

Great, thanks! I'll revisit #276 next, once I remind myself what I was doing there 😅


Suggestion

In my opinion this app has nothing that can make it Ubuntu. So I am suggesting you Debian noroot  as a model for your future updations plan of this project

now playing ;down lose; is malware fail


ci: fix sonarcloud scan pr source

Sonarcloud thinks that every branch is "main" (see https://sonarcloud.io/project/branches_list?id=ionos-cloud_cluster-api-provider-proxmox)
This is an attempt to fix that

will reopen with direct branch instead of fork to test


How to remove API permissions from App Registration using Microsoft graph ?

az feedback auto-generates most of the information requested below, as of CLI version 2.0.62

az ad app permission delete --id <> --api <>
Azure Ad Graph API is no longer supported ,need the Microsoft graph API equivalent of the command to delete API permissions from App registrations
Run this on Azure powershell az ad app permission delete --id <> --api <>
The requested API permission should had been deleted
Azure powershell , owner of the application
Looking for Azure CLI commands in Microsoft Graph API to delete API permissions from App registration.
Documentation missing this scenario/unclear  - https://docs.microsoft.com/en-us/cli/azure/microsoft-graph-migration
Current error -
This command or command group has been migrated to Microsoft Graph API. Please carefully review all breaking changes introduced during this migration: https://docs.microsoft.com/cli/azure/microsoft-graph-migration
The size of the object has exceeded its limit. Please reduce the number of values and retry your request.

@jiasli for awareness

Regarding error:

The size of the object has exceeded its limit. Please reduce the number of values and retry your request.

Your problem is that the requiredResourceAccess property references permissions from more than 10 "remote" APIs (i.e. API registered in tenants different from the tenant where this app is registered). This limitation is documented here: https://docs.microsoft.com/en-us/azure/active-directory/develop/supported-accounts-validation (which is linked to from https://docs.microsoft.com/en-us/azure/active-directory/enterprise-users/directory-service-limits-restrictions).

no more than 10 APIs from other tenants

Microsoft Graph team has opened a bug to improve the error message: https://identitydivision.visualstudio.com/Engineering/_workitems/edit/1924704
Solution
You may update requiredResourceAccess with following methods:

Update permissions in Azure Portal -> Azure Active Directory -> App registrations > select your app -> API permissions
Use az ad app update --required-resource-accesses
Use az rest with Update application API to change requiredResourceAccess? Examples can be found at https://github.com/Azure/azure-cli/issues/12946.


Pytest fixes

Fixes #71.

Change plugin name to django_assets
Stop print on every test run.

Thanks.


members_passwords table and migrations

Table to store password-credential relation for member users
tablename: members_passwords
Columns:

member_id
credential_id

Moving issue to a note


Remove Trading period from search

Remove trading period from search screen and use lag_return=6 as default

Done. https://github.com/VolumeFi/palomabot/pull/41


IndexError: list out of range

Description
When converting the attached form, the following error is produced:

IndexError: list out of range

Attachments

index error - list out of range.zip

another case:
Joe:Desktop joeflack4$ python3 -m ppp *.xlsx --format html doc --template old --language English Swahili --preset standard --outpath ./out/
Creating files.
./out/KEP1-Female-Questionnaire-v1-jef-English.html
./out/KEP1-Female-Questionnaire-v1-jef-English.doc
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/ppp/__main__.py", line 8, in <module>
    cli()
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/ppp/interfaces/cli.py", line 239, in cli
    outpath=args.outpath)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/ppp/__init__.py", line 158, in run
    convert_file(file, language, outpath=_outpath, **combo)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/ppp/__init__.py", line 62, in convert_file
    output = form.to_html(lang=language, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/ppp/odkform.py", line 369, in to_html
    html_questionnaire += item.to_html(lang=language, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/ppp/odkgroup.py", line 139, in to_html
    html += i.to_html(lang, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/ppp/odktable.py", line 138, in to_html
    self.set_header_and_contents(lang, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/ppp/odktable.py", line 77, in set_header_and_contents
    con.row['label'] = con.row['label'][0]
IndexError: string index out of range

KEP1-Female-Questionnaire-v1-jef.xlsx


Feature request

This is really cool and I would like to request some kind of control for the lip-sync.
For example, the way the lips are moving should be based on some parameters and based on audio frequency (+Increase or -Decrease)
Or something that can help control the amount of movments to the lips.

Hi,
Thanks for your request :-)
I'll try to find a way to control this and i'll add more control on all hidden paramters
i'll close this post because it's not an issue but I will think about it :)
Regards

Yes please do that.
How can I contact you directly?

NumZ#7184 on discord


PyRanges constructor changes input df dtypes

The current behavior of the PyRanges constructor when initialising from a DataFrame is to change the dtypes of the Chromosome, Start and End column of the input dataframe inplace.
For me this behavior has been problematic. Would consider changing it? The culprit is the set_dtypes call at the beginning of PyRanges._init.
Example:
import pyranges as pr
import pandas as pd

df = pd.DataFrame({
    "Chromosome": list("1122"),
    "Start": [1, 2, 3, 4],
    "End": [10, 11, 12, 13]}
)
df.dtypes
# object, i8, i8

gr = pr.PyRanges(df)

df.dtypes
# category, i4, i4

Btw: thanks again for your great work!

Yes, this has been nagging me that it changes stuff inplace, implicitly. I have a flag copy_df, but it is more verbose than just calling copy on the dataframe. I want PyRanges to be able to steal the dataframe to save memory. To avoid this behavior use
gr = pr.PyRanges(df.copy())
There is a second problem here:
I think most people most of the time want automatic detection and setting of appropriate data types, but this behavior could also be annoying. Perhaps I should have a flag dtypes where “auto” auto-detects, False does nothing and a dict does the same as 🐼.

Thanks for creating issues. It helps me understand where the pain points are. I’ve only just started using pyranges myself, so I guess I will find and fix thousands of these small issues myself over the coming months :)

Actually, I think copying the df should be the default behavior, and that there should be a copy_df flag you can set to False if you want to steal it. Will fix within a week.

Great, thanks for taking this into consideration! I think this is indeed more what people expect, also because they are used to it from the the defensive copying in pandas.

Should be fixed in 0.0.38. I am going to be very conservative with changes, but in this case I was just plain wrong (much of my testing/early use was on "too large for GRanges"-data and in that particular instance copying took very much longer).


Spanish Layout Fix

Hi,
I added the correct keys for the Spanish Keyboard Layout so far.
^ and ` still missing.
Best regards,
Borja

#2

Okay, thanks for your help :D I'll reopen a new issue to fix these :)

Closes #2


Disable exception sent to client

Hi, How could I stop the exception being sent and displayed on the client like facebook messenger? Thanks.

Do you mean that standard message like "My bot code is having an issue"?
If so, i'd want to disable it too.

no, it's on the client side, like facebook messenger, the exception string got throw to client, which i want to stop it. do you know how?

I think these are the relevant commits, right?
https://github.com/Microsoft/BotBuilder/commit/bf0d5172bb715b0447aeb580da33b997972a87ff
https://github.com/Microsoft/BotBuilder/commit/278ba9b569bdddc198149528ca7fd6ef3450e003
You could avoid sending the message to the user by just avoiding unhandled exceptions.
As a secondary option, you can remove that IPostToBot middleware from the container.

Thanks @willportnoy for the secondary options, how could I remove that IPostToBot container? How can this be done with AutoFac? Thank you

This is how we normally register the chain of IPostToBot middleware:
https://github.com/Microsoft/BotBuilder/blob/master/CSharp/Library/Dialogs/DialogModule.cs#L171
This is our default container:
https://github.com/Microsoft/BotBuilder/blob/master/CSharp/Library/Dialogs/Conversation.cs#L49
You can update the container using the ContainerBuilder like this:
https://github.com/Microsoft/BotBuilder/blob/44d9667878759f9676c615365a818525ffe00ebd/CSharp/Tests/Microsoft.Bot.Builder.Tests/ExceptionTests.cs#L65
I realize it's cumbersome to duplicate the chain registrations without the PostUnhandledExceptionToUserTask middleware.  If anybody is a DI/Autofac expert, I'd love to hear suggestions for better patterns.

Thanks @willportnoy , it works for me now. I just re-register without PostUnhandledExceptionToUserTask

@kenyeung128 I'm glad it works for you - I'm going to close this issue, but feel free to open a new issue for further discussions.

@kenyeung128 would you be able to explain how you re-registered PostUnhandledExceptionToUserTask? I'm having great difficulty doing this in my project.. :disappointed:

@rposbo https://github.com/Microsoft/BotBuilder/issues/1136#issuecomment-244414222 has an alternate solution you might find easier to implement.

@rposbo, you can do this to re-register (basically excluding PostUnhandledExceptionToUserTask)
var builder = new ContainerBuilder();
        builder.Register(c =>
            {
                var cc = c.Resolve<IComponentContext>();

                Func<IPostToBot> makeInner = () =>
                {
                    var task = cc.Resolve<DialogTask>();
                    IDialogStack stack = task;
                    IPostToBot post = task;
                    post = new ReactiveDialogTask(post, stack, cc.Resolve<IStore<IFiberLoop<DialogTask>>>(), cc.Resolve<Func<IDialog<object>>>());
                    post = new ExceptionTranslationDialogTask(post);
                    post = new LocalizedDialogTask(post);
                    post = new ScoringDialogTask<double>(post, stack, cc.Resolve<IComparer<double>>(), cc.Resolve<ITraits<double>>(), cc.Resolve<IScorable<double>[]>());
                    return post;
                };

                IPostToBot outer = new PersistentDialogTask(makeInner, cc.Resolve<IMessageActivity>(), cc.Resolve<IConnectorClient>(), cc.Resolve<IBotToUser>(), cc.Resolve<IBotData>());
                outer = new SerializingDialogTask(outer, cc.Resolve<ResumptionCookie>(), c.Resolve<IScope<ResumptionCookie>>());

                return outer;
            })
            .As<IPostToBot>()
            .InstancePerLifetimeScope();

@kenyeung128 I am actually trying overriding the PostUnhandledExceptionToUserTask. But end up in error saying Autofac Registration issue. I am actually referring the this post


[Help]: sbas_parallel stalled?

sbas_parallel claims 100% but hasn't concluded for over an hour, and only using 100% of 1 cpu.

Is this normal?
Last files created in processing dir where disp_chunk*.grd

It finally finished and is in the Saving phase. Took almost 2 hours.

I have changed to n_jobs=4 to limit swap usage and it's been stuck for 16 hours.

Hi @SteffanDavies Recently I’ve checked the sbas_parallel() function on 2 stitched scenes using 15m resolution without any issue so it should work well. Please show how do you define the corr_stack variable for your mask?

@SteffanDavies Maybe some updates about the processing? As I mentioned above I can imagine just one case to produce the issue when you use not materialized mask (without .compute() call) for the processing so you ask the sbas_parallel() function to read and aggregate the full correlation grids stack in 16 parallel processes (for 38 interferograms for 2 full scenes the stack size is about 100GB size and 16 stacks are 1.6 TB size). We need to use NumPy array inside Xarray dataarray for the mask but not the lazy Dask array which returns sbas.open_grids() function. All the details available in the example notebooks here: https://github.com/mobigroup/YamchiDam/tree/main/notebooks

@SteffanDavies Do you have some updates maybe?


[Question] PowerupPickup vs PowerupAutoUse

What is the difference between these two, and how do they work exactly? Does the later only apply to Health?

Yes, Health is the only auto-use.  To give you an idea about what I think of them being different log entries, here is my code for auto-use:
    'powerupAutoUse'    => sub {
         $HOOKS{'powerupPickup'}->(@_);
    },

I literally just send the powerupAutoUse event and player to the powerupPickup hook, and deal with both log entries in the same hook.


feat(lane_departure_checker): include neighbor lanelets as optional

Signed-off-by: Berkay Karaman<EMAIL_ADDRESS>Description

In current implementation, lane_departure_checker is only checking the vehicle's current lane. However, in some conditions, vehicle can be driven in other lanes. For example, because bus is large vehicle, it can not fit in lanes especially in sharp turns and lane_departure_checker publishes emergency then make vehicle stop. But, user should define the borders of drivable area for lane_departure_checker. To do this, I added some options about which lanes should be included to drivable area borders.
Related links

Tests performed

Notes for reviewers

cc. @kyoichi-sugahara
It is little urgent change, we need to merge this before BusODD.
Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[x] I've confirmed the contribution guidelines.
[x] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.
[ ] The PR has been properly tested.
[ ] The PR has been reviewed by the code owners.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.
[ ] The PR is ready for merge.

After all checkboxes are checked, anyone who has write access can merge the PR.

@brkay54 please create another PR in autoware_launch repo for the changes you made in lane_departure_checker.param.yaml file

@brkay54
sorry for late check.
Applied the parameters below and checked lane_departure checker doesn't output emergency.
include_right_lanes = true
include_opposite_lanes = true
So could you prepare config file in autoware_launch repo?
Then I will approve this PR.

@kyoichi-sugahara I am appreciated for your review. I created PR for autoware_launch: https://github.com/autowarefoundation/autoware_launch/pull/217

@kosuke55
With this implementation, shoulder lane is not included in the neighbor lanelets. Shoulder lane will be added to routing_graph in near future?


Don't throw RangeError for toExponential(undefined)

RangeError was raised for Number.prototype.toExponential(undefined) unexpectedly after refactoring range check (fraction should be between 1 to 20) out of else statement which converts non-integer and not undefined fractionDigits to integer. The spec also doesn't imply range error for it (see below link).
http://www.ecma-international.org/ecma-262/6.0/#sec-number.prototype.toexponential

:shipit:

fixes #2428


[DOCS]: Add info on how to customize kind CertManager when using OperatorHub method on Openshift

Documentation for using cert-manager via Operatorhub on OKD/OCP clusters is very limited.  There are times when customization of the deployment is needed.
Case in point, one of the clusters I have, requires the use of recursive nameservers as described here - https://cert-manager.io/docs/configuration/acme/dns01/#setting-nameservers-for-dns01-self-check. However, when modifying the deployment to include the arg, the operator will overwrite the deployment yaml file.
The apiresources Schema description does not provide any info, as seen in this screenshot below

Environment details:

OCP 4.3.29
Cloud-provider/provisioner (e.g. GKE, kops AWS, etc): KVM
cert-manager version (e.g. v0.4.0): v0.15.2
Install method (e.g. helm or static manifests): OperatorHub

Would like to see more details https://cert-manager.io/docs/installation/openshift/#installing-with-cert-manager-operator
Also a link to the CRD for kind CertManager would be helpful as well. Apologies if this has been already documented somewhere
/kind feature

Would you mind opening this in https://github.com/cert-manager/website/ as this is where we host the documentation (quite confusing but we're working on that)
You're right the documentation is indeed quite limited related to some technical issues we had at the time, this should be expanded!

@meyskens definitely! Done so now, sorry a little slow on here these days.
https://github.com/cert-manager/website/issues/262

/close
Closing this one since we have the website one now


Adding JEBUS token

[x] I will not ping the Discord about this pull request.

Please provide the following information for your token.
Please include change to the src/lib/.json and in the PR
At minimum each entry should have

Token Address: 5jqTNKonR9ZZvbmX9JHwcPSEg6deTyNKR7PxQ9ZPdd2w
Token Name: JEBUS
Token Symbol: JBUS
Logo
Link to the official homepage of token:
Coingecko ID if available (https://www.coingecko.com/api/documentations/v3#/coins/get_coins__id_):

Please add a website and logo! Thanks.

We are waiting your progress, Please add a website and twitter community.

The team is on it. It will take some time before it happens. Should I close this PR and re open later?

Updated with (a) logo and (b) website


Upgrade AWS SDK to V3

Thanks for your contribution

I have released https://rubygems.org/gems/dynamodb-migration/versions/0.8.0 with your changes

This also resolved https://github.com/henrylawson/dynamodb-migration/issues/6

Perfect, thanks!


python3Packages.requests-pkcs12: 1.12 -> 1.13

Motivation for this change
Update to latest upstream release 1.13
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.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

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 138183 run on x86_64-linux 1

4 packages built:

python38Packages.pytenable
python38Packages.requests-pkcs12
python39Packages.pytenable
python39Packages.requests-pkcs12

Result of nixpkgs-review pr 138183 at 5ea9388a run on aarch64-linux 1

4 packages built successfully:

python38Packages.pytenable
python38Packages.requests-pkcs12
python39Packages.pytenable
python39Packages.requests-pkcs12


Feature request: Customizable document retrieval parameters (k and score threshold) for Index-related chains with VectorStore integration

Is your feature request related to a problem? Please describe.
I am working with Index-related chains, such as loadQAStuffChain, and I want to have more control over the documents retrieved from a VectorStore. Specifically, I want to be able to set the "k" parameter (number of retrieved documents) or even a score threshold for the retrieved documents.
Describe the solution you'd like
I would like to see an option to pass a custom "k" parameter or a score threshold when using Index-related chains, such as loadQAStuffChain, loadQAChain, and loadQAMapReduceChain. This would allow users to have more control over the documents retrieved from the VectorStore and how they interact with the language model.
For example:
const stuffQAChain = loadQAStuffChain(llm, { k: 10, scoreThreshold: 0.5 });

I implemented a similar feature here.
https://github.com/hwchase17/langchainjs/pull/827

Please feel free to close it!


How to  Scale 3D Objects ?

I was working on Face Effects/Mesh on Android but I didn't see how to scale object while rendering happening on screen, I can handle "screen pinch" via android way but "how to set value to object" while it is running ?
For example, let's say I run example face-effect app and I wanna "scale" glasses or any other object on scene

Hello @onuralpszr,
We are upgrading the MediaPipe Legacy Solutions to new MediaPipe solutions However, the libraries, documentation, and source code for all the MediaPipe Legacy Solutions will continue to be available in our GitHub repository and through library distribution services, such as Maven and NPM.
You can continue to use those legacy solutions in your applications if you choose. Though, we would request you to check new MediaPipe solutions which can help you more easily build and customize ML solutions for your applications. These new solutions will provide a superset of capabilities available in the legacy solutions.

@kuaashish hello, I am already aware and reading/following new changes and learning to adapt that as well.
Thank you.

@onuralpszr,
Thank you for looking out for our new upgraded solutions. These solutions will provide a superset of capabilities available in the legacy solutions. which are more helpful to adopt, more easily build and customize ML solutions for your use case. Further, We need your confirmation if this is no longer an issue from your end then we can move ahead and mark the issue status to close.

Sure we can close this issue, and I will raise a new one when it is required. Thank you.


Prevent outright crash when used on a kcauldron server

re #3069

Might as well, even though KCauldron has fixed this on their end.


docs(website): disallow crawlers on next website for now

Signed-off-by: Matt Hippely<EMAIL_ADDRESS>PR Checklist
Please check if your PR fulfills the following requirements:

[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)
[ ] If applicable, have a visual design approval

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[x] clarity.design website / infrastructure changes
[ ] Other... Please describe:

What is the current behavior?

Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

Closing this for now, I don't have a good way to whitelist only the algolia crawler.


Feature request: move ios target platform back to 13.0

Is your feature request related to a problem?
I don't think there's a compelling reason to leave it at 16.0 (was just my arbitrary platform target). Lowering it to 13.0 relieves unnecessary platform version pressure on xmtp-ios and aligns with Expo better. This avoids folks having to bump their default React Native Expo ios target version from 13.0.
Describe the solution to the problem
No response
Describe the uses cases for the feature
No response
Additional details
No response

Actually I think XMTPRust only requires iOS 13.0 looking at the podspec: https://github.com/xmtp/xmtp-rust-swift/blob/eccfc16/XMTPRust.podspec#L11


feat: render dollar values on masp overview

Render dollar values on masp overview
We are using the CoinGecko api for the value converstion.
To enable this api, you'll need to create the .env file on namadillo folder, you can copy the sample from .env.sample.  And fill the environment value of COIN_GECKO_API_KEY.
In case there is a coin that doesn't exist on the CoinGecko (like nam), or it's missing the api key, it'll not be able to calculate the value, and it'll be reflected on the UI
Closes #1171

Due to the recent changes of how we are going to handle the dollar amounts, I'll close this PR and open a new one integrated with the Account Overview


Remove Applicant access from Application form button

Fixes #2584

@sandeepsajan0 We also need to add access checks to the views.

Codecov Report

Merging #2591 (d307805) into main (0d65f73) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main    #2591   +/-   ##
=======================================
  Coverage   81.15%   81.15%
=======================================
  Files         647      647
  Lines       23098    23098
=======================================
  Hits        18745    18745
  Misses       4353     4353

Impacted Files
Coverage Δ

hypha/apply/projects/views/project.py
93.53% <100.00%> (ø)

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 0d65f73...d307805. Read the comment docs.


Custom datatype handling in disk based operations

We don't handle custom data types in disk based operations

https://github.com/DSC-SPIDAL/twister2/pull/326


basilidian, eluvia (logical-conflict)

This pull request was generated by the 'mq' tool

/trunk merge


Fix graphic assets management

Currently, each actor manages its own graphic assets individually. Objects of same class read the same assets multiple times in memory, which is obviously a very bad idea.
To fix this, implement a graphics cache: once a level starts, find all objects that have been used and call a static graphics bootstrapping static method on each. Load one copy of each sprite at most even if it was requested from multiple different objects. Keep the sprites in memory until the end of level or end of game. The object constructors need to be adapted to this.
Also, while changing the way the graphics are loaded, externalize the previously hardcoded values from the code to data files (XML or equivalent).

Other than that level load time resource retrieval, the applicable animation states in the manifests should also be migrated off the arbitrary number values to something more legible. (for example: "states": ["jump shoot", "fall shoot", "jump walk shoot"])

This still seems quite troublesome after putting a lot of thought and trying a failed code experiment. Some pointers:

AnimStateT should be scrapped completely. Anything that uses that type should convert to using identifier QStrings.
AnimationUser already has a function for setting the animation by the string key unique to an animation. This should be changed to accept either those keys or a key from any animation's states.
Instead of AnimationUsers having a currentAnimation and currentTransition with the latter having more options (cancellable, callback once finished), these should be combined instead. Theoretical API could bebool setAnimation(const QString& key, bool repeat = true, bool cancellable = true, AnimationCallbackFunc cb = []() { });
bool setAnimation(std::shared_ptr<GraphicResource> animation, bool repeat = true, bool cancellable = true, AnimationCallbackFunc cb = []() { });

CommonActor's overridden function could probably be simplified and replaced with one that just passes parameters forward to AnimationUser's function and runs updateHitbox() if it returned true. The transition stuff doesn't really have any reason to be there, it's pretty much Player specific.

Note: the last point of the previous comment was mostly dealt with in one of the collision revamp commits.


[DO NOT MERGE] Run CI with no cache

Description
This PR is a test run meant to compare results of running with the no-cache labels on master branch for comparison with #586
Checklist

[ ] Investigated and inspected CI test results
[ ] Updated documentation accordingly

Automated testing

[ ] Added unit tests
[ ] Added integration tests
[ ] Added regression tests

If any of these don't apply, please comment below.
Testing Performed
TODO(replace-me)
Use this space to explain how you tested your PR, or, if you didn't test it, why you did not do so. (Valid reasons include "CI is sufficient" or "No testable changes")
In addition to reviewing your code, reviewers must also review your testing instructions, and make sure they are sufficient.
For more details, ref the Confluence page about this section.

Done testing the master branch


! fixing #2542 missing vec! macro for sandbox when building for SGX

fixes #2542

So, sr-sandbox is compiling locally for me in no-std mode. Does this work for you as well in substrate and just not in your project?
Vec and vec! should already be included by the prelude::*: https://github.com/paritytech/substrate/blob/master/core/sr-std/src/lib.rs#L51
Something seems to be incorrect in your setup.

~/substrate/core/sr-sandbox$ cargo build --no-default-features works for me too.
Our node is very close to the node-template (self-released from 6e67eff0653677d3d01980ca822c4b8a227914a3#6e67eff0)
, not much difference, so I don't see how we could've broken the setup. The difference that causes the issue seems to be including srml-contract module.
May I ask you to reproduce the steps in #2542?

I will close this, as this a error on your side, see the issue for more details.


Create Sitemap for Code Model

Currently, we have sitemap only for Algos. We need Sitemap for Code Model as well. Please look last commits to see how sitemap is implemented.
Convention to follow:
Priority: 1
Url: /code/int:id/<create_slug_from_title>
Updated: daily

@poush what is the status of this issue?


A random issue

Hi, I keep getting the following errors when trying install, it seems like it is coming from sqlite
deb-family@Akashs-iMac XeoBot - MCM  2 % npm install

><EMAIL_ADDRESS>install /Users/deb-family/Desktop/XeoBot - MCM  2/node_modules/better-sqlite3
> prebuild-install || npm run build-release

prebuild-install WARN install No prebuilt binaries found (target=14.4.0 runtime=node arch=x64 libc= platform=darwin)

><EMAIL_ADDRESS>build-release /Users/deb-family/Desktop/XeoBot - MCM  2/node_modules/better-sqlite3
> node-gyp rebuild --release

  TOUCH b857c92884e9598d609f6be182a2595df7a8e00f.intermediate
  ACTION deps_sqlite3_gyp_locate_sqlite3_target_extract_sqlite3 b857c92884e9598d609f6be182a2595df7a8e00f.intermediate
/bin/sh: -: command not found
/Users/deb-family/Desktop/XeoBot - MCM  2/node_modules/better-sqlite3/deps/extract.js:8
process.on('unhandledRejection', (err) => { throw err; });
                                            ^

CwdError: ENOENT: Cannot cd into '/Users/deb-family/Desktop/XeoBot - MCM  2/node_modules/better-sqlite3/build/Release/obj/gen/sqlite3'
    at /Users/deb-family/Desktop/XeoBot - MCM  2/node_modules/better-sqlite3/node_modules/tar/lib/mkdir.js:74:14
    at FSReqCallback.oncomplete (fs.js:175:21) {
  path: '/Users/deb-family/Desktop/XeoBot - MCM  2/node_modules/better-sqlite3/build/Release/obj/gen/sqlite3',
  code: 'ENOENT'
}
make: *** [b857c92884e9598d609f6be182a2595df7a8e00f.intermediate] Error 1
rm b857c92884e9598d609f6be182a2595df7a8e00f.intermediate
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:194:23)
gyp ERR! stack     at ChildProcess.emit (events.js:315:20)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:276:12)
gyp ERR! System Darwin 19.3.0
gyp ERR! command "/Users/deb-family/Desktop/XeoBot - MCM  2/node_modules/node/bin/node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild" "--release"
gyp ERR! cwd /Users/deb-family/Desktop/XeoBot - MCM  2/node_modules/better-sqlite3
gyp ERR! node -v v14.4.0
gyp ERR! node-gyp -v v5.1.0
gyp ERR! not ok
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>build-release: `node-gyp rebuild --release`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>build-release script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR!      /Users/deb-family/.npm/_logs/2020-06-20T02_29_52_274Z-debug.log
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none is installed. You must install peer dependencies yourself.
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none is installed. You must install peer dependencies yourself.
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none is installed. You must install peer dependencies yourself.
npm WARN<EMAIL_ADDRESS>No repository field.

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>install: `prebuild-install || npm run build-release`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR!      /Users/deb-family/.npm/_logs/2020-06-20T02_29_52_490Z-debug.log
deb-family@Akashs-iMac XeoBot - MCM  2 %

This is probably a duplicate of https://github.com/JoshuaWise/better-sqlite3/issues/397


Investigate disk usage with Awake

Description of the new feature / enhancement
Currently, PowerToys Awake starts working on the startup. It would be great to have it started after a set time like 15-20 mins.
Scenario when this would be used?
On my machine which heavily relies on Superfetch to optimize performance, I'm used to having a decent startup time on my machine while it caches my commonly used stuff since my usage is predictable and the same 90% of the time (Visual Studio, Edge (Chromium), Windows Terminal, etc.). However, recently I started noticing that the startup time is increased significantly and the Disk Usage doesn't come down even after almost 30 mins. I looked at the disk usage and it looked like Awake was keeping the disk busy.
I tested my hypothesis by having awake disabled at startup (from the Enable Awake Setting) and manually enabling it after 5 mins. I tested it over multiple restarts to confirm the behavior. This approach didn't have any visible impact on the performance of my machine.
Supporting information
No response

However, recently I started noticing that the startup time is increased significantly and the Disk Usage doesn't come down even after almost 30 mins. I looked at the disk usage and it looked like Awake was keeping the disk busy.

cc: @dend

Interesting - mainly because Awake shouldn't really touch the disk much outside the config part. I will have to diagnose this a bit.

@abhisheksiddhu can you throw me a screenshot of the Task Manager with Awake consuming disk cycles? I can't repro this locally, so want to see to what levels that usage measures up on your end.

I tried enabling Awake today, and it wasn't blocking disk anymore. Tried it over 3 restarts to be sure. Maybe it was something in the version at that point in time.


Tp2000 1070  address negative action edge case

TP2000-1070 Address negative action edge case

Why
There's an edge case condition where a duty should be applied if there is no certificate present. The negative actions in a condition currently block you populating the certificate, price or applicable duty fields. This requires remove from the edit screen to support.
What

removed validation on fields certificate, price or applicable duty on the negative action code conditions in the edit measures screen
removed condition_string as it is redundant and causing display bugs for single duty values (3.5%) and measures without additional codes.
set .current() for conditions_list so it will display changes in the current worbasket when viewing conditions in list displays

Codecov Report
Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (b5e90ef) 92.74% compared to head (7b0cae3) 92.74%.

Additional details and impacted files
@@           Coverage Diff           @@
##           master    #1055   +/-   ##
=======================================
  Coverage   92.74%   92.74%
=======================================
  Files         458      458
  Lines       33746    33742    -4
  Branches     2576     2573    -3
=======================================
- Hits        31298    31295    -3
  Misses       1954     1954
+ Partials      494      493    -1

Files
Coverage Δ

measures/forms.py
95.75% <100.00%> (-0.01%)
:arrow_down:

measures/tests/test_models.py
100.00% <100.00%> (ø)

measures/tests/test_views.py
100.00% <100.00%> (ø)

measures/validators.py
96.66% <100.00%> (ø)

measures/views.py
95.28% <100.00%> (ø)

measures/models.py
98.42% <0.00%> (+0.22%)
:arrow_up:

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


Static files are not loaded

I just ran my newly created project but the default css file is not loading.
I created project like this:
express -e ejs -c stylus --git myApp
and ran it with forever:
forever start ./bin/www
But '/stylesheets/style.css' is not loading. I did nothing to the generated code, only did 'npm install'.
Can anyone tell me why this is happening?

@JinJunho I was unable to reproduce this.

You may get better assistance at https://github.com/expressjs/generator

@jordonias Yes I know this is really weird... maybe I should open this issue at express-generator Thanks!  :-)

Can you post your current server configuration here?

Hello @laoshanlung, what server configuration do you mean?
BTW I moved this issue to here in expressjs/generator#99.

Seems like a nginx issue :+1:

@JinJunho Glad you got to the bottom of this. :smiley:

@laoshanlung @tunniclm  Thanks :-)