Use road class to determine if a fork should have an instruction

This PR solves #990 and #1047.
Essentially, this will remove many unnecessary instructions on main roads, including the annoying continue instructions on motorways. For minor roads the difference should be rather small.
Something I am not sure about is how we should handle the tagged maxspeed. Often no maxspeed is tagged. Currently I decided to fallback to the average speed.
Let me know how this works out in your tests and if there are any cases we need to improve.
Here is a brief comparison of GH maps route vs. the improved version, I think the difference is quite visible :)):

BTW: I stumbled over #1843 while creating this PR

Due to the recent fix in #1845 this is working fine now. WDYT? Do we need to add anything here?

In the following situation the second continue instruction is removed (see MapMatchingTest.testDoWork):
http://localhost:8989/maps/?point=51.331131%2C12.379956&point=51.330293%2C12.38149
So, before there were 2 instructions: "continue onto Windmühlenstraße" and "continue onto Bayrischer Platz" and now there is just the first instruction. This is an improvement IMO as the road name changes on a non-junction node and so the instruction is unnecessary.
But could there be instructions removed due to this PR although the road name changes directly on a junctions? Personally I would prefer to keep these instructions to make navigation clear in a dense area.

In my opinion, we should only provide an instruction if the user has to change something, like turning, switching lanes,

Yes, in theory I agree. The problem in practice is that often junctions are not perfectly mapped and so omitting continue instructions for the inner-city case could be problematic if the road name changes. But we'll see what feedback we'll get. Just wanted to understand the now failing map matching test and will now just adapt to the new instructions.

Yes that makes perfect sense :). Let's see what people think. Unfortunately in the real world there are so many different scenarios and you cannot easily test them without knowing the actual situation.


Fix unexpected null flag for nil JSONDocument

I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en

Pull request type

Please check the type of change your PR introduces:

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[ ] Other (please describe):

What is the current behavior?
Issue Number: https://github.com/ydb-platform/ydb-go-sdk/issues/229
Error if try scan nil JSONDocument value.
What is the new behavior?
Call json.Unmarshaler with nil value

Codecov Report

Merging #235 (66066f3) into master (f66079b) will increase coverage by 0.19%.
The diff coverage is 40.00%.

@@            Coverage Diff             @@
##           master     #235      +/-   ##
==========================================
+ Coverage   54.34%   54.54%   +0.19%
==========================================
  Files         136      136
  Lines       15417    15425       +8
==========================================
+ Hits         8379     8414      +35
+ Misses       6490     6465      -25
+ Partials      548      546       -2

Flag
Coverage Δ

1.14.x
26.67% <40.00%> (-0.01%)
:arrow_down:

1.15.x
26.67% <40.00%> (-0.01%)
:arrow_down:

1.16.x
26.67% <40.00%> (-0.01%)
:arrow_down:

1.17.x
54.48% <40.00%> (+0.14%)
:arrow_up:

1.18.x
26.75% <40.00%> (+0.07%)
:arrow_up:

connection
13.32% <0.00%> (-0.01%)
:arrow_down:

discovery
12.19% <0.00%> (-0.01%)
:arrow_down:

e2e
44.45% <0.00%> (+0.11%)
:arrow_up:

integration
44.45% <0.00%> (+0.11%)
:arrow_up:

macOS-latest
26.67% <40.00%> (-0.01%)
:arrow_down:

ratelimiter
15.54% <0.00%> (-0.01%)
:arrow_down:

scripting
15.86% <0.00%> (-0.01%)
:arrow_down:

table
39.35% <0.00%> (+0.11%)
:arrow_up:

ubuntu-latest
54.48% <40.00%> (+0.14%)
:arrow_up:

unit
26.75% <40.00%> (+0.07%)
:arrow_up:

windows-latest
26.75% <40.00%> (+0.07%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

internal/table/scanner/scanner.go
38.16% <40.00%> (-0.12%)
:arrow_down:

internal/table/session.go
75.51% <0.00%> (+0.80%)
:arrow_up:

internal/table/client.go
89.36% <0.00%> (+1.36%)
:arrow_up:

log/driver.go
42.88% <0.00%> (+1.42%)
:arrow_up:

internal/database/database.go
68.75% <0.00%> (+2.08%)
:arrow_up:

internal/conn/grpc_client_stream.go
62.02% <0.00%> (+2.53%)
:arrow_up:

internal/cluster/cluster.go
65.68% <0.00%> (+4.90%)
:arrow_up:

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 f66079b...66066f3. Read the comment docs.


WIP: Add JDK 21

Summary
Add support for JDK 21
Closes https://github.com/paketo-buildpacks/graalvm/issues/344
Use Cases
Enables people to use GraalVM with JDK21
Checklist

[x] I have viewed, signed, and submitted the Contributor License Agreement.
[x] I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
[x] I have added an integration test, if necessary.
[x] I have reviewed the styleguide for guidance on my code quality.
[x] I'm happy with the commit history on this PR (I have rebased/squashed as needed).

I signed the CLA

This looks good. Thanks for the contribution.
Would you be able to also remove the Java 20 stuff? We need to pull that because it's a short-term support version and it won't get upstream updates anymore. Thanks.

/easycla

I tried refreshing EasyCLA. Give it a couple minutes. If that doesn't take, you'll need to click the second link and check with the LF on why it's not authorizing you. That or try going through the signing process again. I apologize for the trouble here, generally EasyCLA works and we have to strictly follow the CLA requirements.

This looks good. Thanks for the contribution.
Would you be able to also remove the Java 20 stuff? We need to pull that because it's a short-term support version and it won't get upstream updates anymore. Thanks.

Will do!

Resolved by #348.


Added gameidea.org under blogs

Why do you think the link is worth adding on this list?
I added my own blog, which is dedicated to teaching video game development. It has tons of tutorials for  making different mechanics and complete games.
Does this project has any License?
Its free.

thanks!


Example code for ASP.NET?

Would it be possible to add example code for ASP.NET on this page. It would make it much more helpful for all use cases. Thanks.

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

ID: 19609d01-2128-d7ec-6ee1-7c9b3e86cb35
Version Independent ID: 0a5ce83e-b17f-9d1c-786e-50ef3958c203
Content: Get a token in a web app that calls web APIs - Microsoft identity platform
Content Source: articles/active-directory/develop/scenario-web-app-call-api-acquire-token.md
Service: active-directory
Sub-service: develop
GitHub Login: @jmprieur
Microsoft Alias: jmprieur

@stevenhayes97
Thanks for your feedback! We will investigate and update as appropriate.

Fixed by PR https://github.com/MicrosoftDocs/azure-docs-pr/pull/122288

#please-close as this is fixed by MicrosoftDocs/azure-docs-pr#122288


Multiprocessing script for reconstructing multiple positions and times

Fixes #299.
This example script downloads the recOrder test dataset (if it hasn't already been downloaded), converts the MM dataset to zarr, then uses multiprocessing to read and write each position and time point into a new zarr store in parallel.
I have confirmed a ~5.5-fold speedup processing this 6-volume (T=2, P=3) test dataset on the HPC login node. I was not able to get the same speedup on my local machine (weird macOS behavior with core handling?).
Thanks @ziw-liu and @edyoshikun for your suggestions. I found that converting to zarr helped (as expected), and I found that using the HPC was essential...multiprocessing isn't working well locally.
@ziw-liu I'm happy to take suggestions for cleaning up this script. I'm still not sure how we can best deploy multiprocessing and slurm since in my experience they are so resource dependent and have so many moving parts.
@ieivanov this addresses the issue you opened. You're more than welcome to test and comment, but it's not strictly necessary since we can iterate on this script fairly quickly.

I'm still not sure how we can best deploy multiprocessing and slurm since in my experience they are so resource dependent and have so many moving parts.

Let's consider this an internal deployment for now, i.e., meant for our internal collaborators. We can assume that these scripts will run on bruno with all its peculiarities.

This code LGTM! I have a similar implementation that works on single node with 64 cores. I agree with @mattersoflight. I do think we should have a common place for our internal users to do the reconstructions via just multiprocessing in local machine or with slurm. I'm not sure where they should live, but for example I currently have these in the sandbox. It's not the cleanest slurm implementation but it works for reconstructions.

Sorry for chiming in late on this.
From reading this script, I think it will work well and it's very powerful in that you can do parallel processing along time, position, or both, but I think it's overall a little complicated for an example script. Typically, large acquisitions would tend to be many time points over a few positions or many positions over a few time points such that doing parallel processing over one of these dimensions would use up your computational resources. We could provide an example script for both of these use cases, or maybe even just one as it would be easy to extend to the other. Again, this will not be as universal, but it will provide for a simple example.
Rather than Process.join I also prefer to use the map or starmap functions of multiprocessing.Pool along with functools.partial to quickly dispatch processors that apply a function over an iterable such as the T dimension of data.
I plan to implement multiprocessing of the mantis deskew in this way, if that approach seems nicer we can also transfer it here.

a little complicated for an example script

I agree!
One of the challenges I've faced is having to choose/change between parallelizing over time, positions, or both. I'm betting this will be a increasingly common problem for us, so I'm all ears for simpler solutions.

I also prefer to use the map or starmap functions of multiprocessing.Pool along with functools.partial

Do you prefer these for syntax reasons (very valuable) or deeper reasons?
Another (related?) challenge I've faced is the situation where you have more positions x times than cores, so you need to split them up. At one point I convinced myself with some off-the-cuff tests that throwing 1000 tasks at 10 cores via Pool was slower than divvying up the 1000 tasks into 100-task chunks that go to each core, but I'm not sure if I reached the right conclusion.
If map (or alternatives) behave appropriately if you have more tasks than cores, then I can imagine a much simpler solution that switches between iterables: range(T), range(P), or itertools.product(range(T), range(P)). Definitely let me know what you come up with on mantis.

One of the challenges I've faced is having to choose/change between parallelizing over time, positions, or both. I'm betting this will be a increasingly common problem for us, so I'm all ears for simpler solutions.

I hear you.

Do you prefer these for syntax reasons (very valuable) or deeper reasons?

Largely for syntax reasons.
It's possible that there are intricacies with using Pool. It does have imap, map_async, and imap_unordered which are supposed to help with things like that. imap in particular can do the chunking you're describing for you.
I didn't know about itertools.product. That along with starmap will make for pretty elegant-looking code, I think. Hopefully it will be performant too, let's test.


Add job token support

This pull request adds job token as an authentication method.
Some of the Gitlab APIs can be accessed with a job token, such as create releases:
route_setting :authentication, job_token_allowed: true
post ':id/releases' do

And here is the corresponding function in go-gitlab:
https://github.com/xanzy/go-gitlab/blob/ea8a48513e1b409b760ebf3cfcbffb765ae2d40b/releases.go#L132-L143
I think it would be very nice to call allowed functions like this one with a job token provided by Gitlab CI, so that we don't need to pass an additional private token into a CI job.

Thinking a bit more about this, maybe we can make it a bit more DRY... So let me have another look before you put in effort to update this PR.

Thinking a bit more about this, maybe we can make it a bit more DRY... So let me have another look before you put in effort to update this PR.


UI does not accept the serverless v1alpha2 version

See...
https://github.com/sap-tutorials/Tutorials/issues/18869
https://github.com/SAP-samples/kyma-runtime-extension-samples/issues/261

We replaced the old serverless views with the new ones. The version should match the examples currently.


GC76EBRROA6DWMCCVPZZYHU3HHNOBHHTGFQYEOEVQLWHVDCDC5YJZ5QK

If that was the case then how come another account I hold has transactions from that address as shown ? Also seem to have 6,000 Mobi missing without any apparent withdrawal
!

Previous response :
'The account you mentioned never existed on the ledger. It means it didn't have any funds on it, nor the transactions history. Maybe you generated new keypair a while ago, but forgot to fund it (which is required to create the account on the Stellar network).'

Another transaction from my Bittrex account to this address ... now I feel sure the account has been deleted along with the Mobi that was stored in there.

Another transaction from my Bittrex account to this address ... now I feel sure the account has been deleted along with the Mobi that was stored in there.


[BUG] Resolve dynamic imports

Bug Report Quick Checklist

snowpack: 3.1.2
npm: 6.14.11
OS: macOS Catalina 10.15.7
node: 14.14.0

Describe the bug
Snowpack doesn't resolve dynamic imports:
import { library, icon } from '@fortawesome/fontawesome-svg-core';

const getIcon = async ( { icon: iconToFetch } ) => {

    const { [ iconToFetch ]: importedIcon } = await import( `@fortawesome/free-brands-svg-icons/${ iconToFetch }.js` );

    library.add( importedIcon );

    return icon( importedIcon, { classes } ).html

}

( async () => {

    const html = await getIcon( { icon: 'faFacebook' } );

    document.body.innerHTML = html;

} )();

Throws Uncaught (in promise) TypeError: Failed to resolve module specifier<EMAIL_ADDRESS>To Reproduce
Reproducible example: https://gist.github.com/jaschaio/321e794e7f8fb15d4bf9dfa0da46656c
Expected behavior
I would expect snowpack to notice the dynamic import, and replace the module identifier with the build output directory.

This is more likely to be related to esbuild rather than snowpack. Here is some discussion is going on https://github.com/evanw/esbuild/issues/700
TL;DR dynamic imports is not something esbuild is going to support out of the box

This does seem to be a bug; thanks for filing! Will investigate.

It seems that snowpack won't resolve the path when dynamic import has a variable in it.
Any update?

This seems related to https://github.com/snowpackjs/snowpack/issues/2861, right?

This seems related to #2861, right?

Ah, right! This feature will solve the problem.

@drwpow I think this can be closed as a duplicate.

I'm expiriencing exactly the same thing. Any progress on this issue?