[BUG] citrix_adc_servicegroup fails create with Autoscale DNS

Describe the bug
ansible fails on adding servicegroup with Autoscale DNS:
result of post {'http_response_data': {'url': 'https://<IP_ADDRESS>/nitro/v1/config/servicegroup?action=enable', 'status': 599, 'date': 'Fri, 13 Jan 2023 10:06:28 GMT', 'server': 'Apache', 'x-frame-options': 'SAMEORIGIN', 'expires': 'Thu, 19 Nov 1981 08:52:00 GMT', 'cache-control': 'no-store, no-cache, must-revalidate, post-check=0, pre-check=0', 'pragma': 'no-cache', 'feature-policy': "camera 'none'; microphone 'none'; geolocation 'none'", 'referrer-policy': 'no-referrer', 'x-xss-protection': '1; mode=block', 'x-content-type-options': 'nosniff', 'content-length': '184', 'content-type': 'application/json; charset=utf-8', 'connection': 'close', 'msg': 'HTTP Error 599: Netscaler specific error'}, 'nitro_errorcode': 257, 'nitro_message': 'Operation not permitted [Enabling / Disabling is not permitted as it has auto scale members. Try unbinding auto scale members.]', 'nitro_severity': 'ERROR', 'data': {'errorcode': 257, 'message': 'Operation not permitted [Enabling / Disabling is not permitted as it has auto scale members. Try unbinding auto scale members
After commenting this code in citrix_adc_servicegroup.py, it lets create all as expected. it seems like this part should not be called when building new servicegroup:
    #log('disable/enable post data %s' % post_data)
    #result = self.fetcher.post(post_data=post_data, resource='servicegroup', action=action)
    #log('result of post %s' % result)

    #if result['http_response_data']['status'] != 200:
    #    msg = 'Disable/Enable operation failed'
    #    self.module.fail_json(msg=msg, **self.module_result)

Environment (please complete the following information):
$ python3 --version
Python 3.8.10
$ ansible --version
ansible [core 2.12.10]
config file = None
ansible python module location = /usr/local/lib/python3.8/dist-packages/ansible
ansible collection location = /home/pkodzis/.ansible/collections:/usr/share/ansible/collections
executable location = /usr/local/bin/ansible
python version = 3.8.10 (default, Nov 14 2022, 12:59:47) [GCC 9.4.0]
jinja version = 2.10.1
libyaml = True
Nitro SDK installed from copy donwloaded fron NetScaler running:
:Primary> sh ver
NetScaler NS13.0: Build 85.15.nc, Date: Mar 10 2022, 07:24:58   (64-bit)

To narrow down, for me the error appears when creating "autoscale: DNS" servicegroup with members that are FQDN based.
If create "autoscale: DNS" servicegroup with members that are IP based, disable/enable passes.
Disable/enable also passes when "autoscale: DNS" servicegroup members are mix of FQDN and IP based.

@pkodzis, if you are able to get this done with netscaler.adc collection, can I request you to close this issue?

ack - this works as expected in 2.1.0 - thank you so much! :)


ci(commitlint): add husky and commitizen

also create pre-commit and commit-msg scripts and
restore commitlint config

closes #10


SLA Industries 2ed character sheet

Changes / Comments
-Rate of fire damage increase
-Ammo damage increase
-Ammo misc info appearing in the roll template
-fix on initiative
Roll20 Requests
Comments are very helpful for reviewing the code changes. Please answer the relevant questions below in your comment.

[Yes] Does the pull request title have the sheet name(s)? Include each sheet name.
[Yes and improvements] Is this a bug fix?
[Yes] Does this add functional enhancements (new features or extending existing features) ?
[No] Does this add or change functional aesthetics (such as layout or color scheme) ?
[No changes to data] If changing or removing attributes, what steps have you taken, if any, to preserve player data ?
[Not a new sheet] If this is a new sheet, did you follow Building Character Sheets standards ?

If you do not know English. Please leave a comment in your native language.

Character Sheet Info Roll20 Internal Use only.


How to work on these docs

The target audience for these docs is anyone on the team, they should be accessible and clear to everyone (but probably currently aren't - that's what this review is for!).
You can see the page as it will be published here: https://30-how-to-docs.kiara-website.pages.dev/internal/how-to-write-these-docs
I'd appreciate review from anyone/everyone, specifically about these points below, but also any other thoughts you have.

topics covered - is everything you need to know there? Is is clear to you when there's a section you don't need to care about?
structure - does the information come at you in the right order? can you easily find what you need to know?
clarity of writing - is everything clearly explained? is the tone of voice ok? Have I used jargon/weird phrasing that doesn't make sense? Are the sentences too long/full of punctuation? Did I spell something wrong?

If there's specific comments about particular words/sentences/sections, it's easiest for me if you can put them on the relevant line(s) in the markdown file if possible.
I've requested review from @CBurge95 initially (as a representative target user), as I can't add Cosimo or Petros. This might mean they don't have full write access/permissions on this repo? Review/opinions/thoughts from anyone/everyone on the team would be much appreciated if you have time!

Dear Caro, first of all thank you very much for your effort. The website looks very tidy and beautiful. I checked the document for which you asked for a request, and from my side is a full pass on all the above mentioned test-points.
If I am obliged to give some hints, then I would say that I would put the section "Running this site on your computer" at the very end, because is also something one would do "if things go wrong". I like the fact that you write as you speak, it makes everything more real, therefore easier to fathom. However, be careful to always keep it synthetic, even if it is good to make it more colorful.  For instance this "Also use this process if you want to add a new page, when you’ve already drafted the content elsewhere and it’s mostly text." is important info, and you deliver it periferically. Maybe this could inserted in the title, with a slash.
Afterwards you use the expression "complicated text", and I could infer "complicated" means "not simple", and "simple" "with mostly text" from what you wrote before. Maybe there is a more straightforward way to express it.
Even if this is only for internal use, and we are all mature adults, I would put a warning in "I just want to fix a typo", to explain bad consequences of using that updating-mode for less basic changes.
I am brainstorming... you assume we have git basics, which is barely true for myself, so I can imagine that someone among us can be a bit overwhelmed with using git commands. Therefore as soon as there is time, I would extend that part, just including the git commands needed for pulling, committing and so on (I can do it after the 5th of March).  If I can spot something else I will write you, and please let me know if there is some action I can take from my side, to solve this issue of tagging me here on git. Thank you for your work Caro, as a wannabe-module-writer, I feel already relieved

Hi Caro, this all looks great to me, thanks so much for doing this!!
I have a couple of questions / suggestions that may just be me (some of which I might have solutions for anyway but don't want to just make edits!!)

I think re the git commands / instructions we can just link out to helpful guides - we shouldn't be expected to hold all the information for these, either for internal or external users - I can find something that we can link in there that's 'researcher' (aka baby coder) accessible!!

Is it worth mentioning that part of the plugin docs (aka specific operation docs) are only editable in kiara itself? (If I've understood that correctly!)

Just a quick question on some of success / failure results and running things to check - is that done in the CMS / GitHub or in terminal? Sorry if that's obvious or if I've not read it clearly enough!

Lastly I think we can add some really clear instructions about what can be automatically pushed to main and what has to be a request for review - I'm happy to write this up & I think it might be a conversation to be had in a dev meeting about oversight vs independence, but just wanted to make a note of it here while I thought of it!

But all in all super fab, I would feel confident doing this now!! (Even if I am probably a classic case of 'when things go wrong'!)

I don't have any comments apart from what others have said, just also wanted to say thanks for doing this, it looks great, and it makes my life a lot easier just being able to dump information in this repo and not have to worry about structure. That, plus not having a commonly agreed upon place always made me more hesitant to write up stuff than should have been the case, so I'm super happy we finally have that. Thanks again, this is brilliant!

@Glottocrisio do the above changes address your comments? Thanks @CBurge95 for finding that great git article, apologies to the team for assuming that git/github process would be familiar and comfortable for you.

@CBurge95

Lastly I think we can add some really clear instructions about what can be automatically pushed to main and what has to be a request for review - I'm happy to write this up & I think it might be a conversation to be had in a dev meeting about oversight vs independence, but just wanted to make a note of it here while I thought of it!

Let's discuss this in the dev meeting? In this case, I trust the team to mostly just push to main, and would prefer the risk of a slightly imperfect article being live than adding a load of git-related overhead to you, but we should decide together whether that's appropriate.
May be worth generally discussing how we issue/git/hub/review in the dev meeting too, but I don't really want to address that can of worms here.

@Glottocrisio do the above changes address your comments? Thanks @CBurge95 for finding that great git article, apologies to the team for assuming that git/github process would be familiar and comfortable for you.

Thank you Caro, yes perfectly. Nevertheless, I am yet not entirely sure on moving the paragraph, it might be a matter of personal taste.

I'm going to merge this for now, so there's something published in the live site. Any more questions/ideas/requests for clarification, please make a new issue labelled docs-platform


Update HitchhikerUserAPI with Netlify Changes

- Summary
Rebasing off of Netlify Gotrue's master to include new changes to fix HitchhikerUserApi restart issue
The stack thread points to DB connection call. The 25 new commits has some changes for newer Go version that are SQL related. netlify@195495c

- Test plan
Will deploy to Dev HitchhikerUserApi and verify that endpoints work.

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

Can you add to the Test plan section in the commit message about dev hitchhikeruserapi if that comes up after this change and some basic endpoints work?

You can start this locally using Makefile (https://github.com/yext/gotrue/blob/master/Makefile#L7) or even using go run.


Social Media timeline planning

Invite and social media posts to be send out by hosts, the following list are just ideas. Please correct, add or remove as needed

[x] Call for speakers
[ ] Call for speakers closing
[ ] Reminder: Early Bird Reg ending
[ ] Confirmation of speakers
[ ] Early Bird Reg to End
[ ] IN-PERSON:Email speaker information including close by hotel, connection information A/V, speaker dinner confirmation + details (if applicable), +1 allowed for the event, speaker discount codes, deadlines
[ ] VIRTUAL:Email speaker information including connection information A/V, speaker discount codes, deadlines.
[ ] Last chance for hotel room rate (in-person)
[ ] Don't miss out
[ ] Looking forward to seeing you
[ ] Last chance to attend
[ ] See you soon
[ ] Post conference survey

@KatharinaSick already has collected a list of all necessary and possible social media posts (see above) - no further planning needed.


Add a test for CaptureStateBeforeExecutionStep

Fixes https://github.com/gradle/gradle/issues/9027 (at least partially)

@lptr Can you check out if this goes in the right direction? Should I add even more unit test coverage for CaptureStateBeforeExecutionStep?


[test] Add changeset checker workflow

Purpose

Describe the problem, feature, improvement or the change introduces by the PR briefly. Add screenshots/GIFs if UI/UX changes are introduced. Remove this placeholder when you're editing.

Related Issues

Issue #1 or (None)

Related PRs

Related PR #1 or (None)

Checklist

[ ] e2e cypress tests locally verified.
[ ] Manual test round performed and verified.
[ ] UX/UI review done on the final implementation.
[ ] Documentation provided. (Add links if there are any)
[ ] Unit tests provided. (Add links if there are any)
[ ] Integration tests provided. (Add links if there are any)

Security checks

[ ] Followed secure coding standards in http://wso2.com/technical-reports/wso2-secure-engineering-guidelines?
[ ] Ran FindSecurityBugs plugin and verified report?
[ ] Confirmed that this PR doesn't commit any keys, passwords, tokens, usernames, or other secrets?

Everything is OK. Thank you for the PR!

Everything is OK. Thank you for the PR!

Everything is OK. Thank you for the PR! 7


custom app Dockerfile - frikky/shuffle:app_sdk still current WALKOFF image?

Working on creating a custom app for an on-prem Shuffle installation and was looking through the required files, including the Dockerfile. In it, I noticed that the app_sdk image used is frikky/shuffle:app_sdk, which seemed like maybe it was outdated, considering the move of most other things to be owned by the Shuffle org. In addition, it seems potentially outdated.
I poked around at the packages under frikky's account and compared them to what was under the Shuffle org.

frikky

shuffle-app_sdk - Last published 3 months ago
app_sdk - Last published over 2 years ago

Shuffle

shuffle-app_sdk - Last published 9 days ago

If I'm understanding correctly the app_sdk image used for this hasn't be updated in over 2 years. Is that correct? What about the other images? I looked at a sampling of other apps in the shuffle_apps repo and noticed they largely all still use that app_sdk image.

Working on creating a custom app for an on-prem Shuffle installation and was looking through the required files, including the Dockerfile. In it, I noticed that the app_sdk image used is frikky/shuffle:app_sdk, which seemed like maybe it was outdated, considering the move of most other things to be owned by the Shuffle org. In addition, it seems potentially outdated.
I poked around at the packages under frikky's account and compared them to what was under the Shuffle org.

frikky

shuffle-app_sdk - Last published 3 months ago
app_sdk - Last published over 2 years ago

Shuffle

shuffle-app_sdk - Last published 9 days ago

If I'm understanding correctly the app_sdk image used for this hasn't be updated in over 2 years. Is that correct? What about the other images? I looked at a sampling of other apps in the shuffle_apps repo and noticed they largely all still use that app_sdk image.

Hey! The naming and walkoff references are all due to backwards compatibility. Below is the default one, but you may choose to use the latest one from ghcr.io/shuffle/shuffle:app_sdk as well - it's up to you. We're moving away from frikky/* as you mentioned, so it may be better to start from shuffle/shuffle going forward for you.
Original: https://hub.docker.com/layers/frikky/shuffle/app_sdk/images/sha256-74f412dac17ea1273dfc3d46b5afb0311b427a9e47f11981804d6adca70fc496?context=repo

Oh! I think my mistake was going by the Github packages, not Docker hub. That makes sense. Thanks!


There's no documentation for how to call a VM service extension method

dart:developer supports a means for developers to register extensions to the VM service, but there's no documentation in the service protocol for how those extension handlers should be invoked. The registerExtension documentation says "users of extensions must always specify a target isolate", but there's no information about how to specify that or what RPC call to use.

You invoke an extension in the same way you invoke any other service protocol RPC.
You target a specific isolate by specifying an 'isolateId' as a parameter, like any other service protocol RPC.

Does this mean extension RPCs can shadow built-in RPCs?

@nex3 No, extensions have lowest priority and cannot replace existing RPCs. In other words, you can register a 'getObject' extension but it will never be called.

Doesn't that mean that any new built-in RPC is now a breaking change, since it might step on an extension that worked in previous SDK versions?

@nex3 We haven't gotten to the point where this is a practical problem. Perhaps we will require extensions to be namespaced or start with a specific prefix.

@nex3 There is also the problem of two Dart libraries that register the same extension method name.

Unfortuantely, changing the registerExtension() method call itself is also a breaking change at this point. But it would probably be good to add a note to its documentation saying something like "For compatibility across packages and future versions of the VM service protocol, extensions should begin with the name of the registering package followed by a period."


Add option to redeploy all workflows in a single place

Is your feature request related to a problem? Please describe.
After updating the ingestion-bot credentials we have to redeploy all the workflows.
Describe the solution you'd like
Option to redeploy all the workflows from UI or using the CLI.
Describe alternatives you've considered
Manually do it.
Additional context
N/A

we can add this after migrations

this is also needed for argo upgrades


wasmd instalation error

have cloned & take a checkout to v0.30.0
when i try to run make install command shows below error:
$ make install
go install -mod=readonly -tags "netgo,ledger" -ldflags '-X github.com/cosmos/cosmos-sdk/version.Name=wasm -X github.com/cosmos/cosmos-sdk/version.AppName=wasmd -X github.com/cosmos/cosmos-sdk/version.Version=0.30.0 -X github.com/cosmos/cosmos-sdk/version.Commit=a347ace2ff41539fe06c68168bc6f28d6ca9fa52 -X github.com/CosmWasm/wasmd/app.Bech32Prefix=wasm -X "github.com/cosmos/cosmos-sdk/version.BuildTags=netgo,ledger"' -trimpath ./cmd/wasmd
go: downloading github.com/cosmos/cosmos-sdk v0.45.11
go: downloading github.com/prometheus/client_golang v1.14.0
go: downloading github.com/spf13/cobra v1.6.0
go: downloading github.com/tendermint/tendermint v0.34.23
go: downloading github.com/spf13/cast v1.5.0
go: downloading github.com/cosmos/ibc-go/v4 v4.2.0
go: downloading github.com/cosmos/interchain-accounts v0.2.4
go: downloading github.com/stretchr/testify v1.8.1
go: downloading github.com/CosmWasm/wasmvm v1.1.1
go: downloading github.com/docker/distribution v2.8.1+incompatible
go: downloading github.com/cosmos/cosmos-proto v1.0.0-alpha8
go: downloading github.com/cosmos/gogoproto v1.4.3
go: downloading google.golang.org/genproto v0.0.0-20221024183307-1bc688fe9f3e
go: downloading github.com/rs/zerolog v1.27.0
go: downloading github.com/spf13/viper v1.14.0
go: downloading golang.org/x/exp v0.0.0-20220722155223-a9213eeb770e
go: downloading github.com/99designs/keyring v1.2.1
go: downloading google.golang.org/protobuf v1.28.2-0.20220831092852-f930b1dc76e8
go: downloading github.com/google/btree v1.1.2
go: downloading github.com/syndtr/goleveldb v1.0.1-0.20210819022825-2ae1ddf74ef7
go: downloading github.com/armon/go-metrics v0.4.0
go: downloading github.com/inconshreveable/mousetrap v1.0.1
go: downloading github.com/prometheus/client_model v0.3.0
go: downloading github.com/prometheus/common v0.37.0
go: downloading golang.org/x/sys v0.1.0
go: downloading github.com/cosmos/cosmos-sdk/ics23/go v0.8.0
go: downloading github.com/opencontainers/go-digest v1.0.0
go: downloading golang.org/x/net v0.1.0
go: downloading github.com/go-kit/log v0.2.1
go: downloading github.com/cosmos/iavl v0.19.4
go: downloading golang.org/x/crypto v0.1.0
go: downloading github.com/mattn/go-isatty v0.0.16
go: downloading github.com/btcsuite/btcd v0.22.1
go: downloading github.com/lib/pq v1.10.6
go: downloading github.com/mattn/go-colorable v0.1.13
go: downloading github.com/danieljoos/wincred v1.1.2
go: downloading github.com/dvsekhvalnov/jose2go v1.5.0
go: downloading golang.org/x/term v0.1.0
go: downloading github.com/fsnotify/fsnotify v1.6.0
go: downloading github.com/mitchellh/mapstructure v1.5.0
go: downloading github.com/spf13/afero v1.9.2
go: downloading gopkg.in/yaml.v3 v3.0.1
go: downloading github.com/matttproud/golang_protobuf_extensions v1.0.2-0.20181231171920-c182affec369
go: downloading github.com/rcrowley/go-metrics v0.0.0-20201227073835-cf1acfcdf475
go: downloading github.com/libp2p/go-buffer-pool v0.1.0
go: downloading github.com/creachadair/taskgroup v0.3.2
go: downloading github.com/subosito/gotenv v1.4.1
go: downloading github.com/golang/snappy v0.0.4
go: downloading gopkg.in/ini.v1 v1.67.0
go: downloading github.com/pelletier/go-toml/v2 v2.0.5
go: downloading github.com/mimoo/StrobeGo v0.0.0-20210601165009-122bf33a46e0
go: downloading github.com/klauspost/compress v1.15.11
go: downloading golang.org/x/text v0.4.0
go: downloading github.com/pelletier/go-toml v1.9.5
github.com/CosmWasm/wasmd/cmd/wasmd
C:\Program Files\Go\pkg\tool\windows_amd64\link.exe: running gcc failed: exit status 1
C:/Program Files/CodeBlocks/MinGW/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lwasmvm
collect2.exe: error: ld returned 1 exit status
make: *** [Makefile:96: install] Error 1
Can anyone help me to understand why this error raise and how to solve it?

Heyhey! Running wasmd nodes on Windows cannot work as this has never been fully implemented in wasmvm. What should work is building a wasmd CLI client to the blockchain without executing smart contracts. For this you have to disable cgo in the build. Would that solve your problem or do you try to run a node on Windows?


Notifications - Tag and Category subscriptions

Please Review:
@J-Fid
@seenusuvarna
@skhtet
@lsemesky

https://github.com/aml-development/ozp-backend/pull/275


Error when using common and macos

I'm playing with a multiplatform project for native (macos for now and linux later) so I can create CLI utilities.
The code is pretty straightforward, there are only 3 files. build.gradle.kts, SampleCommon and system.
Build.gradle is pretty similar to the gist in #2
import org.jetbrains.kotlin.gradle.plugin.mpp.KotlinNativeTargetWithTests

plugins {
    id("org.jetbrains.kotlin.multiplatform") version "1.3.61"
    id("org.jetbrains.kotlin.plugin.serialization") version "1.3.61"
}

repositories {
    mavenCentral()
    jcenter()
    maven { url = uri("https://dl.bintray.com/kotlin/kotlin-dev") }
}

fun KotlinNativeTargetWithTests.nativeConfig() {
    binaries {
        executable {
            entryPoint = "sample.main"
        }
    }
}

kotlin {

    macosX64("macos") {
        compilations["main"].enableEndorsedLibs = true
        nativeConfig()
    }

    sourceSets {
        val commonMain by getting {
            dependencies {
                implementation(kotlin("stdlib-common", "1.3.61"))
                implementation("org.jetbrains.kotlinx:kotlinx-serialization-runtime-common:0.14.0")
                implementation("org.jetbrains.kotlinx:kotlinx-cli:0.2.0-dev-6")
            }
        }

        val commonTest by getting {
            dependencies {
                implementation(kotlin("test-common"))
                implementation(kotlin("test-annotations-common"))
            }
        }

        val macosMain by getting {
            dependsOn(commonMain)
            dependencies {
                implementation("org.jetbrains.kotlinx:kotlinx-serialization-runtime-native:0.14.0")
            }
        }
    }
}

Then the main file, SampleCommon:
package sample

import kotlinx.cli.ArgParser
import kotlinx.cli.ArgType
import kotlinx.cli.default
import kotlinx.serialization.Serializable
import kotlinx.serialization.json.Json
import kotlinx.serialization.json.JsonConfiguration

fun main(args: Array<String>) {
    val parser = ArgParser("cdp")
    val option by parser.argument(ArgType.String).default("buildsrc")
    parser.parse(args)
    println(option)
    val json = Json(JsonConfiguration.Stable)
    val workspace = json.parse(Project.serializer(), config)
    val repository = workspace.repositories.first { it.alias == option }
    println(repository)
    system("echo \"cd \$WORKSPACE_ROOT/${repository.folder}\"")
}

expect fun system(command: String): Int

@Serializable
data class Project(
    val name: String,
    val folder: String,
    val repositories: List<Repository>
)

@Serializable
data class Repository(
    val name: String,
    val alias: String,
    val url: String,
    val folder: String
)

@Serializable
data class UserConfiguration(
    val projects: List<Project>
)

And system is just the implementation for native (and probably other implementations like java or js)
But when I try to compile, it fails on the kotlin compiler. With the following exception seen in this gist: https://gist.github.com/jdiazcano/3ffc909ec711710c352fb8a77154844f
Everything worked fine when I used it directly from the macosMain, but then I converted it to the common module and started failing.

Please, don't use  compilations["main"].enableEndorsedLibs = true and exact dependency at the same time. K/N compiler in this case added klib, and it is in dependency of gradle build, you so get 2 conflicting entities. If you remove this line compilations["main"].enableEndorsedLibs = true, everything will work properly.

Or if you plan to write only for native targets, you can  create some extra sourceSet which would be common for native targets and then remove implementation("org.jetbrains.kotlinx:kotlinx-cli:0.2.0-dev-6")

plugins {
    id("org.jetbrains.kotlin.multiplatform") version "1.3.61"
    id("org.jetbrains.kotlin.plugin.serialization") version "1.3.61"
}

repositories {
    mavenCentral()
    jcenter()
    maven { url = uri("https://dl.bintray.com/kotlin/kotlin-dev") }
}

fun KotlinNativeTargetWithTests.nativeConfig() {
    binaries {
        executable {
            entryPoint = "sample.main"
        }
    }
}

kotlin {

    macosX64("macos") {
        compilations["main"].enableEndorsedLibs = true
        nativeConfig()
    }

    sourceSets {
        val commonMain by getting {
            dependencies {
                implementation(kotlin("stdlib-common", "1.3.61"))
                implementation("org.jetbrains.kotlinx:kotlinx-serialization-runtime-common:0.14.0")
            }
        }

       val nativeMain by sourceSets.creating {
            sourceSets["macosMain"].dependsOn(this)
            dependsOn(sourceSets["commonMain"])
        }

      .....
    }
}```

If i remove the explicit dependency from the commonMain neither IntelliJ or gradle will recognize the cli classes. As the endorsed libs is only done at macos level. If I add the same file in the macosMain everything works fine there.
If I add the explicit dependency and remove the endorsed lib, Gradle doesn't recognize the dependencies:
12:16:22: Executing tasks 'clean build --stacktrace'...

> Configure project :
Kotlin Multiplatform Projects are an experimental feature.

> Task :clean

> Task :compileKotlinMacos
e: /Users/javier/workspace/github/nativeworkspace/src/commonMain/kotlin/sample/SampleCommon.kt: (6, 16): Unresolved reference: serialization
e: /Users/javier/workspace/github/nativeworkspace/src/commonMain/kotlin/sample/SampleCommon.kt: (7, 16): Unresolved reference: serialization
e: /Users/javier/workspace/github/nativeworkspace/src/commonMain/kotlin/sample/SampleCommon.kt: (8, 16): Unresolved reference: serialization
e: /Users/javier/workspace/github/nativeworkspace/src/commonMain/kotlin/sample/SampleCommon.kt: (15, 16): Unresolved reference: Json
e: /Users/javier/workspace/github/nativeworkspace/src/commonMain/kotlin/sample/SampleCommon.kt: (15, 21): Unresolved reference: JsonConfiguration
e: /Users/javier/workspace/github/nativeworkspace/src/commonMain/kotlin/sample/SampleCommon.kt: (16, 40): Unresolved reference: serializer
e: /Users/javier/workspace/github/nativeworkspace/src/commonMain/kotlin/sample/SampleCommon.kt: (17, 53): Unresolved reference: it
e: /Users/javier/workspace/github/nativeworkspace/src/commonMain/kotlin/sample/SampleCommon.kt: (24, 2): Cannot access 'Serializable': it is internal in 'kotlin.io'
e: /Users/javier/workspace/github/nativeworkspace/src/commonMain/kotlin/sample/SampleCommon.kt: (24, 2): This class does not have a constructor
e: /Users/javier/workspace/github/nativeworkspace/src/commonMain/kotlin/sample/SampleCommon.kt: (31, 2): Cannot access 'Serializable': it is internal in 'kotlin.io'
e: /Users/javier/workspace/github/nativeworkspace/src/commonMain/kotlin/sample/SampleCommon.kt: (31, 2): This class does not have a constructor
e: /Users/javier/workspace/github/nativeworkspace/src/commonMain/kotlin/sample/SampleCommon.kt: (39, 2): Cannot access 'Serializable': it is internal in 'kotlin.io'
e: /Users/javier/workspace/github/nativeworkspace/src/commonMain/kotlin/sample/SampleCommon.kt: (39, 2): This class does not have a constructor

> Task :compileKotlinMacos FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':compileKotlinMacos'.
> Process 'command '/Users/javier/.sdkman/candidates/java/11.0.4-amzn/bin/java'' finished with non-zero exit value 1

* Try:
Run with --info or --debug option to get more log output. Run with --scan to get full insights.

Caused by: org.gradle.process.internal.ExecException: Process 'command '/Users/javier/.sdkman/candidates/java/11.0.4-amzn/bin/java'' finished with non-zero exit value 1
	at org.gradle.process.internal.DefaultExecHandle$ExecResultImpl.assertNormalExitValue(DefaultExecHandle.java:396)
	at org.gradle.process.internal.DefaultJavaExecAction.execute(DefaultJavaExecAction.java:38)
	at org.gradle.process.internal.DefaultExecActionFactory.javaexec(DefaultExecActionFactory.java:129)
	at org.gradle.api.internal.project.DefaultProject.javaexec(DefaultProject.java:1103)
	at org.jetbrains.kotlin.compilerRunner.KonanCliRunner.run(KotlinNativeToolRunner.kt:126)
	at org.jetbrains.kotlin.gradle.tasks.AbstractKotlinNativeCompile.compile(KotlinNativeTasks.kt:245)

* Get more help at https://help.gradle.org

BUILD FAILED in 5s
2 actionable tasks: 2 executed
12:16:27: Tasks execution finished 'clean build --stacktrace'.

If you remove dependency, you have to add NativeMain preset and source code with parser should be there.

Please, don't use compilations["main"].enableEndorsedLibs = true and exact dependency at the same time. K/N compiler in this case added klib, and it is in dependency of gradle build, you so get 2 conflicting entities. If you remove this line compilations["main"].enableEndorsedLibs = true, everything will work properly.

This definitely worked! Thanks!


Issue with GPX Export

Nothing happens when you click on "GPX" button.
Error in console:
TypeError: e is undefined

Just tried, works fine for me... do you have an active route?

Perhaps changes this into:
'Disable or remove GPX export until active route?'

You're right !
It works when there is an active route but returns an error when there is no active route.
Don't know what I was expecting to export without any active route to be honest 😂
Shouldn't return an error in the console though.

I originally placed the download-GPX button in the sidebar, in the instruction pane that only appears when a route has been planned for exactly this reason.


Migrate bevy_sprite to required components

Objective
Continue migration of bevy APIs to required components, following guidance of https://hackmd.io/@bevy/required_components/
Solution

Make Sprite require Transform and Visibility and SyncToRenderWorld
move image and texture atlas handles into Sprite
deprecate SpriteBundle
remove engine uses of SpriteBundle

Testing
ran cargo tests on bevy_sprite and tested several sprite examples.

Migration Guide
Replace all uses of SpriteBundle with Sprite. There are several new convenience constructors: Sprite::from_image, Sprite::from_atlas_image, Sprite::from_color.
WARNING: use of Handle<Image> and TextureAtlas as components on sprite entities will NO LONGER WORK. Use the fields on Sprite instead. I would have removed the Component impls from TextureAtlas and Image except it is still used within ui. We should fix this moving forward with the migration.

With my alternative approach I noticed that asset_decompression is broken. I assume the same is true here.

When reviewing this PR, compare the design to #15562 and see which one you prefer!

@ecoskey
Have you emptied the branch by accident?

Files changed 0

Yes. I'll fix it this afternoon, I'm at a river

Looks like there is now easing_function as well, but ci caught it.
Also as per my last comment the asset_decompressing example is still broken.

Hmm, the animation isn't working in the sprite_animation and sprite_sheet examples. They work on current main.

Hmm, the animation isn't working in the sprite_animation and sprite_sheet examples. They work on current main.

should be fixed, as well as asset_decompression


C# RGB image processing - object detection in RGB image and pixel position mapping back to point cloud vertex

Required Info

Camera Model
{D415 }

Firmware Version
(Open RealSense Viewer --> Click info)

Operating System & Version
{Win (8.1/10)

Kernel Version (Linux Only)

Platform
PC

SDK Version
{ legacy / 2.22 }

Language
{C# }

Segment
others }

Issue Description
I'd like to get the color frame from the D415 camera in a form of some basic datatype to e.g. detect circles in c# and then map those detected positions to 3D (to a point cloud vertex).
Could you please point me in the right direction with some sample code?
I'm missing documentation for the c# wrapper.
Thank you.

Probably c# example 3 - processing is a good start, as far as camera management is concerned.
C# wrapper is less comprehensive than its C++ and python counterparts, but the API is mostly the same across languages so it may be useful to look at other C++ examples

I tried running the example3, but I keep getting System.BadImageFormatException.
(when calling "Context" constructor). Everything seems to be compiled for x86... (only cs-tutorial-3-processing, realsense2 and intel.RealSensed are of importance, right?)
Would  you please have some suggestions?

@AOndracek Are you running the example on x86 platform?

No, Windows 10, 64 bit...

This question may be related to the following thread:
https://github.com/IntelRealSense/librealsense/issues/2125
Generate the solution and set the target platform to x64.
** Please be informed that this ticket will be closed if there we have not heard from you in 7 days. Thank you for your understanding.


Added support of OpenVINO export

PR content:

OpenVINO export (through ONNX)
Test
Notebook that demonstrates export and inference

@AlexKoff88
#156 just got merged regarding ONNX exporting. It may allow this PR to be simplified due to the large overlap in changes. Furthermore, there was discussion regarding moving all code for exporting into a new exporters submodule: https://github.com/huggingface/setfit/pull/156#discussion_r1042164429. This PR should follow suit, i.e. rebase/merge main and move the functionality and tests to the exporters folders, respectively.

Tom Aarsen

@AlexKoff88 #156 just got merged regarding ONNX exporting. It may allow this PR to be simplified due to the large overlap in changes. Furthermore, there was discussion regarding moving all code for exporting into a new exporters submodule: #156 (comment). This PR should follow suit, i.e. rebase/merge main and move the functionality and tests to the exporters folders, respectively.
* Tom Aarsen

Hi Tom,
I've revised the code according to the recent changes and your suggestions. Please check again.

Hi,
I cleaned up the style.
OpenVINO 2022.3 is essential. I am ok to postpone the merge 1-2 weeks before it is available on PyPI.

@tomaarsen, OpenVINO 2022.3 is available and OpenVINO export should work now. Please merge.

I still have some tiny nits on the notebook that you've provided. Thanks a lot for it, by the way, it helps users out a lot.
As for the actual code, it looks good. I'll merge this when the notebook is updated!

@AlexKoff88 I still have some tiny nits on the notebook that you've provided. Thanks a lot for it, by the way, it helps users out a lot. As for the actual code, it looks good. I'll merge this when the notebook is updated!

Thanks, @tomaarsen. I've updated the notebook according to your comments.

Looks great! Thanks for this PR and for following up on our requests. Happy new year!

Thanks for accepting the contribution! And Happy New Year!


What's the style idea?
Here if we are changing the styles in position, and background, the page will look more responsive. Now when I am scrolling down, the whole page is moving, which depicts that the page is not responsive as much. If we are changing the styles in CSS, it will clear the issue
Add screenshots
Add screenshots
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Assign me this task in the gssoc'23 tag


Correct html PropTypes

Correct html PropTypes
It's string, not bool

@f-garofalo Look at what you're doing... This repo is sweetalert-react, not sweetalert2-react...

@f-garofalo And I don't see any commits either (1) by you, or (2) correcting prop types


Migrate to using tags to specify releases of ATM instead of branches

Merge / deployment checklist

[ ] Confirm this change is backwards compatible with existing workflows.
[ ] Confirm the readme has been updated if necessary.
[ ] Confirm the changelog has been updated if necessary.

Test


ENHANCEMENT

The config.time_zone parameter is not documented; it would be helpful if it was.
The parameter takes a float with unit hours which is fine, but the official Arduino libraries take a quantity in seconds, so my suggestion is for the Firebase-ESP-Client and Firebase-ESP8266 libraries to also use the unit of seconds:
https://github.com/arduino-libraries/NTPClient

// You can specify the time server pool and the offset, (in seconds)
// additionally you can specify the update interval (in milliseconds).
// NTPClient timeClient(ntpUDP, "europe.pool.ntp.org", 3600, 60000);

As I said time zone is hour in the standard terminology.
The example and its comment are enough for how to use this config.

ok, sure leave it in hours if that is your view.
the problem is still that there is no documentation about the config.time_zone parameter unless I'm missing it?

So, no documentation is fine?


Do not show welcome experience in no folder workspace

open command prompt code-insiders
No folder workspace is opened and there is the welcome experience

In this case we should not show the welcome experience, we are an editor the user just wanted to edit a new untitiled file, welcome experience is not needed in this case.
Another strange scenario

Open new window
An no folder workspace is opened and there is the welcome experience

We should only show the welcome experience for the folder workspace
fyi @bpasero

The first time the workbench opens is without a folder and we want to show the Welcome experience specifically there.
The current logic is to show it if the setting (and the experiment) is enabled unless there is a file (other than the untitled one) open.


Build doesn't work anymore

@norosa the build doesn't work anymore, not sure if it's on my end, gonna check tomorrow:
ubuntu@dev:~/Documents/GitHub/crate-docs-theme/docs$ make SPHINX_OPTS='-W -n --host <IP_ADDRESS>' dev
make[1]: Entering directory '/home/ubuntu/Documents/GitHub/crate-docs-theme/docs'
make[1]: Leaving directory '/home/ubuntu/Documents/GitHub/crate-docs-theme/docs'
make[1]: Entering directory '/home/ubuntu/Documents/GitHub/crate-docs-theme/docs'
Creating a Python virtual environment...
Traceback (most recent call last):
  File "<string>", line 1, in <module>
AssertionError
ERROR: Python>=3.7 is required.
.crate-docs/src/rules.mk:134: recipe for target '.crate-docs/.venv/bin/activate' failed
make[1]: *** [.crate-docs/.venv/bin/activate] Error 1
make[1]: Leaving directory '/home/ubuntu/Documents/GitHub/crate-docs-theme/docs'
Makefile:152: recipe for target 'dev' failed
make: *** [dev] Error 2

python --version gives Python 3.7.9
Originally posted by @msbt in https://github.com/crate/crate-docs-theme/issues/245#issuecomment-801257429

@norosa asked at https://github.com/crate/crate-docs-theme/pull/245#issuecomment-801475370:

@amotl you added this check. do you know what's up here? :)

Thanks for reporting. I will take a look.


More complex example?

Sorry to use an issue tracker for a question...
While I've seen several examples of simple apps using this library, I have not seen a more realistic real-world example which has multiple deeper components, where if the database is changed, all updates are propagated properly.
In my case, I'm trying to do something like the following.  Note that I have worked with Meteor a very long time ago, but not recently, and never Svelte, so there could be a learning curve.  I'm also very much a back-end engineer, and yes, I'm making a web app.  Be afraid.
I have a "planet" object which has this general shape:
{
  "system": "Sol",
  "number": 3,
  "resources": [
    { "name": "iron", "quantity": 4.5, "tapped": false },
    { "name": "copper", "quantity": 3.6, "tapped": false}
  ]
}

I have a component which does:
    $: planets = useTracker(() => Planets.find({}).fetch());

and then uses an {#each $planets as planet}<Planet {planet}/>{/each} to render the list.  This works, and adding, removing, etc. make the list update properly.  However, it seems changing the entries inside of the objects does not cause any sub-components of  to re-render.  That is, it seems the change detection works one level down, but anything lower than the first component seems to not work.
In this case,  prints out planet.name, and then calls another component to render the planet.resources, one at a time, with a string provided for the one to render.  This part does not update if the values change.
Do you have an example at hand that will propagate the reactive changes through components without having to re-fetch the item from the database in each component to ensure updates are properly triggered?
The hack is to pass the planet._id, and then fetch it in each component again, which while local is fast enough, this seems wrong.

Hi, sorry to not have noticed this issue earlier.  Before I look closer at your use case, I have just a question, do you have the immutable flag set in svelte:options?

I do not have that flag set.  With Meteor, I'm not even sure how to set it.
That said, I seem to have solved my problems.  Mostly.  Kinda.  :)
The work-around / solution is to make sure that I always refer to $planet in some way.    If I rewrite this to pass in the $planet it works properly.

I think if you were to use destructuring syntax or accessed it via its properties it would work:
{#each $planets as planet}<Planet {...planet}/>{/each}

or
{#each $planets as planet}<Planet name={planet.name}/>{/each}

The way I recommend doing it is to just pass in the identifier:
<script>
$: planets = Planets.find({}, {fields: {_id: 1}});
</script>
{#each $planets as planet (planet._id)}<Planet id={planet._id}/>{/each}

And then in the Planet component, do something like this:
export let id;
$: planet = useTracker(() => Planets.findOne(id));

That makes sure that you have a reactive $planet store available in the Planet component that does update when its properties change.

Sounds good, thanks!


delete objects after test suite

I'm using Dynamoose with factory-girl. In one of my test cases, I'm using the following

factory.createMany('xxxxxxx', 10).then((xxxxx) => {});

which is creating 10 records in my test db, however, what I'm trying to do is, I would like to delete those 10 records after the test suite is done from my local dynamoDB.
I did look at this link https://github.com/aexmachina/factory-girl#objectadapter, but there is no support for DynamoDB. Any suggestions on this?

Have you tried this? Factory#cleanUp
ex.
factory.createMany('xxxxxxx', 10).then((xxxxx) => {})
factory.cleanUp()

I have tried that and it doesn't work?

I read that:
(https://github.com/aexmachina/factory-girl#factorycleanup)
cleanUp() calls destroy() method of an adapter:
  cleanUp() {
    const createdArray = [];
    for (const c of this.created) {
      createdArray.push(c);
    }
    const promise = createdArray.reduce(
      (prev, [adapter, model]) =>
        prev.then(() => adapter.destroy(model, model.constructor)),
      Promise.resolve()
    );
    this.created.clear();
    this.resetSeq();
    return promise;
  }

Briefly looking at Dynamoose's docs I can't see them having destroy() method at all: https://dynamoosejs.com/api/model/
Maybe that's the case.


bcbioRNASeq invocation is wrong (hardcoded GRCh38)

As the title says, bcbioRNASeq is invoked with:
bcb <- bcbioRNASeq(uploadDir="/path/to/final",interestingGroups=c("batch","group","timepoint"),level="gene",organism="homo sapiens");

Note that it does not specify the genome build (in fact, whatever is set in the YAML file is ignored). As such, it defaults to GRCh38, which can be wrong, for example, when using hg19.
Ideally it should use whatever it is set in the configuration file.

Hi @lbeltrame , I just saw this post regarding the bcbioRNASeq() function call in R. You can set this genome build for hg19/GRCh37 like this:
bcb <- bcbioRNASeq(
    uploadDir = "/path/to/final",
    level = "genes",
    organism = "Homo sapiens",
    genomeBuild = "GRCh37",  # "hg19" works here too
)

To fix this in the bcbio_nextgen.py call, we need to pass the genomeBuild argument to the bcbioRNASeq() function.

Thanks @mjsteinbaugh !
In many cases users run bcbio to get counts and a simple QC report, and then load counts in some other powerful packages like (https://www.onramp.bio/rna-seq-data-analysis) or in R using bioRNASeq or directly Deseq2, edgeR .
We are heading towards running a simple one page QC Rmd as a part of bcbio run.
Downstream users still will be able to create a bcb object using the upload dir and the instruction mentioned above. Thanks @mjsteinbaugh  for maintaing the package!


Interrupt command doesn't work in command palette when running a cell

Open a python file
Send a cell to the interactive widnow
Select the command to Interrupt the terminal
This doesn't work, as focus is NOT on the interactive window
Solution

Identify the corresponding interactive active window

Closing as a dup of https://github.com/microsoft/vscode-jupyter/issues/1076


fix(TDI-39944): when tSalesforceOutput write dynamic field didn't pass value to component behind it

What is the current behavior? (You can also link to an open issue here)
For JIRA: https://jira.talendforge.org/browse/TDI-39944
when tSalesforceOutput write dynamic field didn't pass value to component behind it
What is the new behavior?
set the value of dynamic field
Please check if the PR fulfills these requirements

[x] The commit message follows Talend standard
[x] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features) ?
[x] The code coverage on new code >75%
[x] The new code does not introduce new technical issues (sonar / eslint)

What kind of change does this PR introduce?

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

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Pull request test result: success :star:
Sonar results


RTE SINGULARITY: Use the SINGULARITY_OPTIONS input parameter instead of the environment variable if defined

In the documentation of the Singularity RTE, 2 parameters are defined: SINGULARITY_IMAGE and SINGULARITY_OPTIONS.
Defining  SINGULARITY_IMAGE in the submission script seems to have an effect on the execution and effectively uses the given singularity image. See in the source code: $2 is used here
Unfortunately, this does not seem to be the case for the SINGULARITY_OPTIONS. Using this variable in the submission script does not change anything during the execution: options are not used.
This PR aims to support the use of the  SINGULARITY_OPTIONS parameter from the submission script.

If not defined in the submission script, then the RTE Singularity script tries to use the environment variable
If not defined, then no singularity option is defined

This is not about singlarity itself, it is about user origins and trust boundaries.
Local users indeed has access to the filesystem with or without singularity based on they permissions and this is defined by organization policies. However hear we are talking about grid users who are external to the resource and have nothing to do with organization policy, they just mapped to some accounts and should be handled in a more restricted way generally.
Using singularity with proper option allows to enforce better isolation (e.g. mounting only the job scratch area).
But making such an options configurable by external users themselves allows them to bypass isolation.
What is you use-case?
Why external user should be able to override the CE-admin defined way of singularity callout?

Note @manfuin that the SINGULARITY_OPTIONS parameter is already defined in the RTE, but not used.

There is a big different between parameter defined by system owner vs defined in job xRSL by end-user

Local users indeed has access to the filesystem with or without singularity based on they permissions and this is defined by organization policies. However hear we are talking about grid users who are external to the resource and have nothing to do with organization policy, they just mapped to some accounts and should be handled in a more restricted way generally.
Using singularity with proper option allows to enforce better isolation (e.g. mounting only the job scratch area).
But making such an options configurable by external users themselves allows them to bypass isolation.

Alright, I understand your concern, and indeed users could potentially exploit the SINGULARITY_OPTIONS parameter to bypass isolation.
But in the same way, they could also exploit the SINGULARITY_IMAGE parameter to bypass isolation, couldn't they?

What is your use-case?
Why external user should be able to override the CE-admin defined way of singularity callout?

We share an ARC instance connected to a supercomputer - with no external connectivity at all - with other VOs.
Our jobs need to interact with distinct singularity containers, and distinct directories to get their software dependencies.
For instance:

VO1 will need: singularity exec --bind /path/to/dir1:/cvmfs image1.sif <command>
VO2 will need: singularity exec --bind /path/to/dir2:/cvmfs image2.sif <command>

There is probably a workaround: I guess we could embed a given directory within our container to just have to call:
singularity exec image1.sif


KNOX-2638 - Shiro propererties are missing after topology deployment

What changes were proposed in this pull request?
STR:

Have an existing topology (test.xml), see if blockSemicolon/blockBackslash/blockNonAscii are in the get topology output:

$ curl -u admin:admin-password -k -X GET https://localhost:8443/gateway/admin/api/v1/topologies/test | grep blockSemicolon
<name>main.invalidRequest.blockSemicolon</name>

Deploy a new topology file (test2.xml)

cp ./conf/topologies/test.xml ./conf/topologies/test2.xml

blockSemicolon/blockBackslash/blockNonAscii are no longer in the orignial test.xml output:

$ curl -u admin:admin-password  -k -X GET https://localhost:8443/gateway/admin/api/v1/topologies/test | grep  blockSemicolon

The reason why these shiro properties are missing is because we only add these after a topology deployment to the in memory representation of a topology. When we deploy a new topology we also reload all the existing topologies but only redeploy the newly added one.
@Override
public void reloadTopologies() {
  try {
    synchronized (this) {
      Map<File, Topology> oldTopologies = topologies;
      Map<File, Topology> newTopologies = loadTopologies(topologiesDirectory); // <= parse everything from disk
      List<TopologyEvent> events = createChangeEvents(oldTopologies, newTopologies);
      topologies = newTopologies;
      notifyChangeListeners(events); // <= this will redeploy the new topology and add the shiro properties, but those will be missing from all other existing topologies
    }
  } catch (Exception e) {
    // Maybe it makes sense to throw exception
    log.failedToReloadTopologies(e);
  }
}

One open question is whether we wan't to write out these properties to the disk or not.
How was this patch tested?
This was discovered while investigating the flakiness of an existing test: GatewayAdminTopologyFuncTest.
After the fixed I verified that GatewayAdminTopologyFuncTest is no longer flaky.

cc: @smolnar82 @moresandeep @pzampino @lmccay4


Precision adjustment of the coordinates puts some holes outside of their shell in ContourBuilder

Describe the bug
An exception is thrown when trying to find shells containing holes in ContourBuilder.
Introduced in: 0e9461e6de94d491f2118fca20ca903f631e7288
To Reproduce
Steps to reproduce the behavior:

checkout master
download new-york-latest.osm.pbf
Use any GTFS file, as long a PT isochronecan be generated without PT data interfering.
Query: curl --location --request GET 'http://localhost:8989/isochrone-pt?point=40.744823,-73.991453&time_limit=4000&pt.earliest_departure_time=2000-11-01T08:00:00Z'
See error (Found a hole without a shell.)

Here's a smaller polygon with the same issue: http://localhost:8989/isochrone-pt?point=40.705805,-74.017997&time_limit=200&pt.earliest_departure_time=2000-11-01T08:00:00Z
Screenshots & Logs
The Exception:
java.lang.RuntimeException: Found a hole without a shell.
	at com.graphhopper.isochrone.algorithm.ContourBuilder.punchHoles(ContourBuilder.java:148)
	at com.graphhopper.isochrone.algorithm.ContourBuilder.computeIsoline(ContourBuilder.java:104)
	at com.graphhopper.resources.PtIsochroneResource.doGet(PtIsochroneResource.java:166)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory.lambda$static$0(ResourceMethodInvocationHandlerFactory.java:52)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:124)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:167)
	at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$TypeOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:219)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:79)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:469)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:391)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:80)
	at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:253)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:244)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:292)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:274)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:244)
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:265)
	at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:232)
	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:680)
	at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:394)
	at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:346)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:366)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:319)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:205)
	at io.dropwizard.jetty.NonblockingServletHolder.handle(NonblockingServletHolder.java:50)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1631)
	at io.dropwizard.servlets.ThreadNameFilter.doFilter(ThreadNameFilter.java:35)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1618)
	at io.dropwizard.jersey.filter.AllowedMethodsFilter.handle(AllowedMethodsFilter.java:47)
	at io.dropwizard.jersey.filter.AllowedMethodsFilter.doFilter(AllowedMethodsFilter.java:41)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1618)
	at com.graphhopper.http.CORSFilter.doFilter(CORSFilter.java:36)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1618)
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:549)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1363)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:489)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1278)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
	at com.codahale.metrics.jetty9.InstrumentedHandler.handle(InstrumentedHandler.java:249)
	at io.dropwizard.jetty.RoutingHandler.handle(RoutingHandler.java:52)
	at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:767)
	at org.eclipse.jetty.server.handler.StatisticsHandler.handle(StatisticsHandler.java:173)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
	at org.eclipse.jetty.server.Server.handle(Server.java:500)
	at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
	at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
	at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
	at java.lang.Thread.run(Thread.java:748)

I created a Multipolygon containing the hole (the first polygon) and its shell
The Wicket screenshots:

The multipolygon:
MULTIPOLYGON(((-74.0189079 40.70492627,-74.01887623 40.70493074,-74.01887623 40.70493074,-74.01879688 40.70499835,-74.01871046 40.70491509,-74.01869146 40.70487598,-74.01869146 40.70487598,-74.01864955 40.70473311,-74.01866818 40.70470964,-74.0189079 40.70492627)),((-74.03213269 40.71381573,-74.01923239 40.70572142,-74.01890792 40.70492626,-74.0189079 40.70492627,-74.01866817 40.70470964,-74.01829434 40.70442428,-74.01829434 40.70442428,-74.01784023 40.70425069,-74.01764428 40.70389082,-74.01765359 40.7038016,-74.01765434 40.70373399,-74.01764502 40.70363527,-74.01763981 40.70358591,-74.01763981 40.70358591,-74.01762193 40.70349892,-74.01758337 40.70337748,-74.01754072 40.7032674,-74.01746435 40.70311298,-74.01746437 40.70311298,-74.01746435 40.70311297,-74.01723114 40.70283935,-74.01690742 40.70246868,-74.01686849 40.70242715,-74.01652501 40.70207082,-74.01648497 40.70202929,-74.01614075 40.70168172,-74.01607556 40.70162956,-74.0157062 40.70132204,-74.0157062 40.70132205,-74.01567453 40.70134477,-74.01567453 40.70134477,-74.01560003 40.70133974,-74.01555067 40.7013254,-74.01538582 40.70124848,-74.01538582 40.70124848,-74.01514666 40.70088787,-74.01514666 40.70088786,-74.01405478 40.70085061,-74.01302585 40.70054904,-74.01161043 40.70080348,-74.00935905 40.70161001,-74.00935904 40.70161001,-74.0055002 40.70243013,-74.0055002 40.70243013,-74.00220052 40.70564413,-74.00220052 40.70564413,-74.00143759 40.70605279,-73.99824203 40.70718379,-73.99824203 40.70718379,-73.99824203 40.70718379,-73.9944849 40.70420915,-73.99448489 40.70420915,-73.99424294 40.70402214,-73.99424294 40.70402214,-73.99424294 40.70402214,-73.99424294 40.70402214,-73.99448489 40.70420915,-73.99448489 40.70420915,-73.9941282 40.70929156,-73.99400023 40.70929938,-73.99385178 40.70930963,-73.99182019 40.70958288,-73.99182019 40.70958288,-73.9897331 40.70988258,-73.9897331 40.70988258,-73.98818133 40.70919936,-73.98818133 40.70919936,-73.98818133 40.70919936,-73.98818133 40.70919936,-73.98665675 40.7098822,-73.98646956 40.70990176,-73.98421464 40.70958753,-73.98421464 40.70958753,-73.98363797 40.70962013,-73.98363796 40.70962013,-73.98363796 40.70962013,-73.98363796 40.70962014,-73.98246599 40.71080291,-73.98234659 40.71087649,-73.98200443 40.71142764,-73.98185299 40.71143808,-73.98144992 40.7114662,-73.98056348 40.71106573,-73.98056348 40.71106573,-73.98039976 40.71071109,-73.98039976 40.71071109,-73.98039976 40.71071108,-73.97924287 40.71014465,-73.97924287 40.71014465,-73.97865204 40.71051402,-73.97772518 40.71077553,-73.97732714 40.71106853,-73.97685403 40.71146378,-73.97685402 40.71146378,-73.97637495 40.71274211,-73.97219574 40.71354025,-73.97219573 40.71354025,-73.97219573 40.71354025,-73.97219573 40.71354026,-73.97213706 40.7136509,-73.97213706 40.7136509,-73.97213706 40.7136509,-73.97213706 40.7136509,-73.97422471 40.71714429,-73.97422471 40.71714429,-73.97422471 40.71714429,-73.97317809 40.72007963,-73.97315835 40.72015935,-73.97296463 40.72094166,-73.97294247 40.72103144,-73.97294246 40.72103144,-73.97233673 40.72364026,-73.97233673 40.72364026,-73.97233673 40.72364026,-73.97224099 40.72407109,-73.97208118 40.72591846,-73.97160285 40.72823186,-73.96250738 40.72975588,-73.96250737 40.72975588,-73.96250737 40.72975588,-73.96250737 40.72975589,-73.96250737 40.72975589,-73.96250737 40.72975589,-73.9612974 40.73096884,-73.96118918 40.73026979,-73.96117763 40.73015617,-73.96117763 40.73015617,-73.96116906 40.73009358,-73.9610981 40.72991309,-73.9610981 40.72991309,-73.96100441 40.72966294,-73.96100441 40.72966294,-73.96099155 40.7295441,-73.96099062 40.7294899,-73.96099062 40.7294899,-73.96082913 40.72899276,-73.96078182 40.72861055,-73.96078182 40.72861055,-73.96075388 40.72814917,-73.96054098 40.72779657,-73.96054098 40.72779657,-73.95915052 40.72778912,-73.95877687 40.72689095,-73.95877687 40.72689095,-73.95877687 40.72689095,-73.95877687 40.72689095,-73.958672 40.72785413,-73.95724298 40.72775392,-73.95724298 40.72775392,-73.95724298 40.72775392,-73.95724298 40.72775392,-73.95735995 40.72845799,-73.95735995 40.728458,-73.95720088 40.72983896,-73.95720088 40.72983896,-73.95468296 40.73020087,-73.954574 40.730088,-73.954159 40.72983188,-73.9539569 40.72950294,-73.9539569 40.72950294,-73.953066 40.73024893,-73.953066 40.73024893,-73.95250683 40.73035994,-73.95156694 40.72869772,-73.95156694 40.72869772,-73.95156694 40.72869772,-73.95072223 40.72897637,-73.95072223 40.72897637,-73.95059296 40.72901902,-73.95059296 40.72901902,-73.95043371 40.72916058,-73.94991086 40.72924384,-73.94991086 40.72924385,-73.94991086 40.72924385,-73.94991086 40.72924385,-73.94932171 40.72990881,-73.94932171 40.72990881,-73.94876999 40.73072185,-73.94835388 40.73068386,-73.94835388 40.73068386,-73.94789492 40.7308839,-73.94789492 40.73088391,-73.94789492 40.73088391,-73.94789492 40.73088391,-73.94789492 40.73088391,-73.94789492 40.73088391,-73.94789492 40.73088391,-73.94933791 40.73138682,-73.94945097 40.73209388,-73.94945098 40.73209388,-73.94945098 40.73209388,-73.94957298 40.73280094,-73.94957298 40.73280094,-73.94968399 40.73350893,-73.94968399 40.73350893,-73.94980283 40.73422381,-73.94992483 40.7349359,-73.94864967 40.73609577,-73.94788785 40.73592385,-73.94788784 40.73592385,-73.94718954 40.73544683,-73.94718954 40.73544683,-73.94650855 40.73674025,-73.94650855 40.73674025,-73.94650855 40.73674025,-73.94598645 40.73910394,-73.94529225 40.73955526,-73.94299747 40.73911232,-73.94248785 40.73856527,-73.94183052 40.73757937,-73.94168319 40.73735082,-73.94168319 40.73735082,-73.94168319 40.73735082,-73.94168318 40.73735082,-73.94137864 40.73747078,-73.94019009 40.73751753,-73.93895404 40.73559807,-73.93876666 40.73528589,-73.93876666 40.73528589,-73.93855413 40.73494633,-73.93855413 40.73494633,-73.93855413 40.73494633,-73.93855413 40.73494633,-73.93828349 40.73534252,-73.93824139 40.73560143,-73.93824139 40.73560143,-73.93824139 40.73560143,-73.93836563 40.73580725,-73.93770998 40.73722323,-73.93751999 40.73692297,-73.93750658 40.73613675,-73.93750658 40.73613675,-73.93750658 40.73613675,-73.93730839 40.73621405,-73.93721079 40.73624627,-73.93711114 40.73628129,-73.93711114 40.73628129,-73.93711114 40.73628129,-73.93711114 40.73628129,-73.93603285 40.73748586,-73.93603285 40.73748586,-73.93542135 40.73754938,-73.93542135 40.73754938,-73.93542135 40.73754938,-73.93542135 40.73754938,-73.93582815 40.73792619,-73.93582815 40.73792619,-73.93664603 40.73862264,-73.93664603 40.73862264,-73.93664604 40.73862264,-73.93688334 40.73877444,-73.93688334 40.73877444,-73.93690737 40.73865039,-73.93773047 40.73818752,-73.93863012 40.73837975,-73.93874822 40.73869193,-73.93853103 40.74041059,-73.93819427 40.74054228,-73.93726946 40.74046405,-73.93726946 40.74046405,-73.93631206 40.74033739,-73.93631206 40.74033739,-73.93631206 40.74033739,-73.93613697 40.74123518,-73.93577711 40.74308274,-73.93486889 40.74297806,-73.93486888 40.74297806,-73.93486888 40.74297806,-73.93394334 40.74287152,-73.93394334 40.74287152,-73.93394334 40.74287152,-73.9337703 40.74370356,-73.93284847 40.74359758,-73.93284847 40.74359758,-73.93171599 40.74451139,-73.93171599 40.74451139,-73.93078932 40.74440019,-73.93078932 40.74440019,-73.93078932 40.74440019,-73.93078932 40.74440019,-73.93078932 40.74440019,-73.93159845 40.74466785,-73.93158038 40.74475633,-73.93158038 40.74475633,-73.93164688 40.74483549,-73.93133209 40.74641706,-73.93133209 40.74641706,-73.93128869 40.74668584,-73.93128869 40.74668584,-73.93128869 40.74668584,-73.9312887 40.74668584,-73.9312887 40.74668584,-73.93206002 40.74662698,-73.93227292 40.74648337,-73.93326738 40.74627848,-73.9343859 40.74618814,-73.9343859 40.74618814,-73.93454497 40.74615108,-73.93638023 40.74545855,-73.93679225 40.74833242,-73.93665851 40.74841587,-73.935388 40.74940996,-73.935388 40.74940996,-73.935388 40.74940996,-73.93474297 40.75097887,-73.93286356 40.75076634,-73.93286356 40.75076634,-73.93251078 40.7510692,-73.93251078 40.75106921,-73.93284736 40.75110068,-73.93283134 40.75121654,-73.93287958 40.75132513,-73.93264191 40.75190888,-73.93264191 40.75190889,-73.93264191 40.75190889,-73.93264191 40.75190889,-73.93275273 40.75188765,-73.93275273 40.75188765,-73.93342012 40.75171182,-73.93351865 40.75192397,-73.93351865 40.75192397,-73.93475675 40.75196532,-73.93475675 40.75196532,-73.93475675 40.75196533,-73.93561394 40.75228197,-73.93561394 40.75228197,-73.93640184 40.75267183,-73.93600882 40.75434094,-73.93600882 40.75434094,-73.93600882 40.75434094,-73.93600883 40.75434094,-73.93721377 40.75379463,-73.9375185 40.75395575,-73.93754886 40.75515995,-73.93754886 40.75515995,-73.93754886 40.75515995,-73.93829392 40.75555688,-73.93848074 40.75663796,-73.93811883 40.75703097,-73.93811883 40.75703097,-73.93811883 40.75703097,-73.93811883 40.75703097,-73.93859995 40.75800644,-73.93859995 40.75800644,-73.93854016 40.75824505,-73.93854016 40.75824505,-73.93854016 40.75824505,-73.93854016 40.75824505,-73.93854016 40.75824505,-73.93854016 40.75824505,-73.93854016 40.75824505,-73.93854016 40.75824505,-73.93854016 40.75824505,-73.93854016 40.75824505,-73.93863106 40.75814893,-73.93870519 40.75808318,-73.93991256 40.75786022,-73.93991256 40.75786022,-73.93991256 40.75786022,-73.93991256 40.75786022,-73.93991256 40.75786022,-73.93993398 40.75786954,-73.93998352 40.75789096,-73.94003288 40.75790567,-73.94003288 40.75790567,-73.94003288 40.75790567,-73.94003288 40.75790567,-73.94086195 40.75811094,-73.94086195 40.75811094,-73.94086195 40.75811094,-73.94086195 40.75811094,-73.94166195 40.75839797,-73.94166195 40.75839797,-73.94166195 40.75839797,-73.94166195 40.75839797,-73.94166195 40.75839797,-73.94159564 40.75997023,-73.94156156 40.76003244,-73.94151927 40.76010937,-73.94151927 40.76010937,-73.94151927 40.76010937,-73.94151927 40.76010937,-73.94151927 40.76010937,-73.94151927 40.76010937,-73.94151927 40.76010937,-73.94151927 40.76010937,-73.94157906 40.76013284,-73.94165879 40.76016413,-73.94165879 40.76016413,-73.94233604 40.76040087,-73.94233604 40.76040087,-73.94233604 40.76040087,-73.94239732 40.76042583,-73.94245805 40.7604506,-73.94242452 40.76188782,-73.94241651 40.76190086,-73.94237833 40.7619627,-73.94233772 40.76202845,-73.94232934 40.76204223,-73.94232934 40.76204223,-73.94232934 40.76204223,-73.94232934 40.76204224,-73.94232934 40.76204223,-73.94241539 40.76208955,-73.94241539 40.76208955,-73.94251039 40.76209048,-73.94252715 40.76212847,-73.94252715 40.76212847,-73.94253516 40.76211674,-73.94254652 40.76210016,-73.942559 40.76208154,-73.94260184 40.76201709,-73.94264208 40.76195506,-73.94265269 40.76193886,-73.94266163 40.76191874,-73.94267095 40.76189918,-73.94267095 40.76189918,-73.94268343 40.76187273,-73.94313475 40.76180512,-73.94348958 40.76177532,-73.94348958 40.76177532,-73.94348958 40.76177532,-73.94354583 40.76159054,-73.94388297 40.76114593,-73.94454421 40.76138155,-73.94454421 40.76138155,-73.94454421 40.76138155,-73.94518868 40.76135864,-73.94518869 40.76135864,-73.94548503 40.76077489,-73.94582031 40.76060018,-73.94631111 40.76067841,-73.94798079 40.76243711,-73.94725808 40.76329058,-73.94725808 40.76329058,-73.94725808 40.76329058,-73.94725808 40.76329058,-73.9470761 40.76376444,-73.9470761 40.76376444,-73.94683787 40.76414497,-73.94671717 40.76416323,-73.94666725 40.76397789,-73.94675759 40.76385328,-73.94675759 40.76385328,-73.94675759 40.76385328,-73.94665477 40.76397138,-73.94645193 40.76386465,-73.94645193 40.76386465,-73.94645193 40.76386465,-73.94635712 40.76432602,-73.94583353 40.76494498,-73.94579889 40.76498614,-73.94579889 40.76498614,-73.94579888 40.76498615,-73.94579889 40.76498615,-73.94579889 40.76498615,-73.94579889 40.76498615,-73.94595367 40.76608622,-73.94595367 40.76608622,-73.94595367 40.76608622,-73.94610194 40.76591691,-73.94669594 40.76537767,-73.94671717 40.76538848,-73.94676374 40.76541176,-73.94700365 40.76553339,-73.94712043 40.76559262,-73.94714018 40.76560175,-73.94714018 40.76560175,-73.94818345 40.7652648,-73.94818345 40.7652648,-73.94818345 40.7652648,-73.94831607 40.76509418,-73.94831607 40.76509418,-73.94856101 40.7648023,-73.94873181 40.76455904,-73.94919375 40.76405091,-73.95156582 40.7654749,-73.9510318 40.76651128,-73.9510318 40.76651128,-73.9510318 40.76651128,-73.95140247 40.76674504,-73.95153788 40.76680353,-73.95153788 40.76680353,-73.95223134 40.76870454,-73.95218683 40.76876638,-73.95214995 40.76881742,-73.95214995 40.76881742,-73.95214995 40.76881742,-73.95190613 40.76940024,-73.95190613 40.76940024,-73.95190613 40.76940024,-73.95202199 40.76944904,-73.95354581 40.77091271,-73.95354581 40.77091271,-73.95351154 40.77095927,-73.95346069 40.77102838,-73.95346069 40.77102838,-73.95307959 40.77154545,-73.95307959 40.77154545,-73.95307959 40.77154545,-73.95304532 40.77159555,-73.95299969 40.77166224,-73.95299969 40.77166224,-73.95299969 40.77166224,-73.95299969 40.77166224,-73.95303135 40.77167509,-73.95313939 40.77171905,-73.953245 40.77176133,-73.95327908 40.77177493,-73.95327908 40.77177493,-73.95327908 40.77177493,-73.95496571 40.77330528,-73.95447416 40.77397955,-73.95447416 40.77397956,-73.95413925 40.77460969,-73.95413925 40.77460969,-73.95409939 40.77466594,-73.95409939 40.77466594,-73.95421823 40.774714,-73.95421823 40.774714,-73.95586946 40.77623484,-73.95540641 40.77686945,-73.95540641 40.77686945,-73.95540641 40.77686945,-73.95540641 40.77686945,-73.95654505 40.77818112,-73.9560833 40.77881219,-73.9560833 40.77881219,-73.9560833 40.77881219,-73.9560833 40.77881219,-73.95707553 40.78000204,-73.95700307 40.78010076,-73.95693266 40.78019669,-73.95693266 40.78019669,-73.95693266 40.78019669,-73.95655194 40.78071655,-73.95655194 40.78071656,-73.95651115 40.78077243,-73.95651115 40.78077244,-73.95656013 40.7808719,-73.95656013 40.7808719,-73.95656013 40.7808719,-73.95663892 40.78090506,-73.95663892 40.78090506,-73.95670449 40.78093262,-73.95670449 40.78093262,-73.95677359 40.78096094,-73.95687008 40.78100229,-73.95779302 40.78206139,-73.95775111 40.78211969,-73.95770752 40.78217929,-73.95770752 40.78217929,-73.95770752 40.78217929,-73.95733741 40.7826904,-73.95733741 40.7826904,-73.957297 40.78274647,-73.9572536 40.78280644,-73.9572536 40.78280644,-73.9572536 40.78280644,-73.95736033 40.78285152,-73.95747469 40.78289995,-73.95747469 40.78289995,-73.9584971 40.78399705,-73.95845575 40.78405479,-73.95841458 40.78411197,-73.95841458 40.78411197,-73.95804205 40.78463053,-73.95800238 40.78467915,-73.95800238 40.78467915,-73.95805118 40.7847788,-73.95805118 40.7847788,-73.95805118 40.7847788,-73.9580957 40.78471789,-73.95825086 40.78471417,-73.95825086 40.78471417,-73.95891806 40.78457372,-73.95902702 40.78442639,-73.95917622 40.78422299,-73.95972179 40.78380296,-73.95972179 40.78380296,-73.96508769 40.78414196,-73.9650877 40.78414196,-73.96567331 40.78809207,-73.96567331 40.78809207,-73.96521063 40.78901017,-73.96521063 40.78901017,-73.96521063 40.78901017,-73.96589273 40.78949744,-73.96593967 40.78973399,-73.96593967 40.78973399,-73.96593967 40.78973399,-73.96605739 40.78978969,-73.96605739 40.78978969,-73.96618293 40.78984948,-73.96618293 40.78984948,-73.96618293 40.78984948,-73.96622335 40.78979435,-73.96626452 40.78973791,-73.96626452 40.78973791,-73.96664003 40.78922475,-73.96668007 40.78917017,-73.96671975 40.78911597,-73.96671975 40.78911597,-73.96709805 40.7885989,-73.96709805 40.7885989,-73.9671489 40.78852905,-73.96718206 40.78848379,-73.96987469 40.78968463,-73.9698747 40.78968464,-73.97015074 40.78930149,-73.97268617 40.79086835,-73.97268617 40.79086835,-73.97278526 40.79091007,-73.97278526 40.79091007,-73.97278526 40.79091007,-73.97324236 40.79028366,-73.97449629 40.79080595,-73.97449629 40.79080595,-73.97467957 40.79087412,-73.97467958 40.79087412,-73.97513182 40.79025516,-73.97645635 40.79081731,-73.97645635 40.79081731,-73.97668974 40.79049563,-73.97692313 40.79017414,-73.97692313 40.79017414,-73.97737426 40.78956263,-73.97737426 40.78956263,-73.97961931 40.79098308,-73.97961931 40.79098308,-73.97961931 40.79098308,-73.97987319 40.79061726,-73.98059999 40.79074243,-73.98075049 40.79078657,-73.98075049 40.79078657,-73.98075049 40.79078658,-73.98075049 40.79078657,-73.98114835 40.79000501,-73.98194855 40.78866428,-73.98306501 40.7887779,-73.98590927 40.78647567,-74.01045574 40.7765597,-74.01045574 40.77655971,-74.01045408 40.77661043,-74.01045578 40.77655968,-74.01045577 40.77655968,-74.01045576 40.77655968,-74.01045576 40.77655968,-74.01045576 40.77655969,-74.01045576 40.77655969,-73.99057446 40.77969526,-73.99202285 40.77605286,-73.99233839 40.77559074,-73.99279883 40.77461509,-73.99291618 40.77444112,-73.99302719 40.77427683,-73.99328964 40.77389667,-73.99368321 40.77343436,-73.99392964 40.77305494,-73.99426175 40.77234527,-73.99477212 40.7717116,-73.99477211 40.7717116,-73.99490194 40.77151434,-73.99497552 40.77142084,-73.99533724 40.7710742,-73.99536891 40.77103006,-73.99574013 40.7711867,-73.99574013 40.77118671,-73.99600574 40.77046996,-73.99603015 40.77014903,-73.99603015 40.77014902,-73.99663588 40.76828098,-73.99728222 40.76695925,-73.99728222 40.76695924,-73.99734629 40.76620692,-73.99751039 40.76598191,-73.99780543 40.76557772,-73.99796692 40.76564105,-73.99808874 40.76572729,-73.99818318 40.76572561,-73.99818318 40.76572562,-73.99818318 40.76572561,-73.99847114 40.76527262,-73.99847114 40.76527262,-73.99852236 40.76500607,-73.99830853 40.76488854,-73.99871608 40.76433031,-73.99889918 40.76449292,-73.99900516 40.76433534,-73.99900516 40.76433534,-73.99900516 40.76433534,-73.99878258 40.76423904,-73.9987036 40.76394753,-73.9987036 40.76394753,-73.99896884 40.76361766,-73.9997912 40.76315144,-73.99991916 40.7632293,-73.99991916 40.7632293,-74.00010543 40.76321384,-74.00114776 40.7629933,-74.00351593 40.76361096,-74.00351593 40.76361096,-74.00351594 40.76361095,-74.00425298 40.76247511,-74.00425298 40.76247511,-74.00442136 40.76034592,-74.00442136 40.76034592,-74.00416189 40.76023044,-74.0040859 40.76019933,-74.00375751 40.76005274,-74.00375751 40.76005274,-74.003751 40.75923001,-74.00404716 40.75901879,-74.00404716 40.75901879,-74.00432395 40.758479,-74.00530574 40.75702706,-74.00530575 40.75702707,-74.007152 40.75469839,-74.007152 40.75469838,-74.00742208 40.75401162,-74.00742208 40.75401162,-74.00750628 40.753795,-74.00750628 40.753795,-74.00780355 40.75234754,-74.00855383 40.75199326,-74.00859965 40.75195582,-74.00859965 40.75195582,-74.00855494 40.75174628,-74.00874568 40.75124914,-74.00965279 40.75090473,-74.00965279 40.75090474,-74.0107741 40.74863846,-74.02252533 40.75290019,-74.02281832 40.75879228,-74.02281832 40.75879229,-74.02281833 40.7587923,-74.02281839 40.75879222,-74.02281835 40.75879226,-74.02252535 40.75290016,-74.02655909 40.73503667,-74.02655909 40.73503666,-74.02655908 40.73503667,-74.02655908 40.73503667,-74.01389907 40.72899388,-74.01389906 40.72899388,-74.01389906 40.72899388,-74.01299493 40.72861669,-74.01299493 40.72861669,-74.01299493 40.72861669,-74.01203269 40.72883406,-74.01203269 40.72883406,-74.0113247 40.72877334,-74.01134109 40.72822926,-74.01132358 40.72810018,-74.01135226 40.72790107,-74.01139883 40.72770083,-74.01139883 40.72770083,-74.01139883 40.72770083,-74.01108684 40.7264726,-74.01108684 40.7264726,-74.01120139 40.72572233,-74.01170598 40.72545374,-74.01170598 40.72545374,-74.01170598 40.72545374,-74.01172964 40.72533919,-74.0117492 40.72524475,-74.01176894 40.72514882,-74.01189262 40.72445182,-74.01190119 40.72439892,-74.01190119 40.72439892,-74.01205988 40.72359854,-74.01218785 40.72295202,-74.01226347 40.72261413,-74.01229253 40.72248691,-74.01329538 40.72151871,-74.01329538 40.72151871,-74.01310445 40.72149655,-74.01313835 40.72105193,-74.01313835 40.72105193,-74.01313836 40.72105193,-74.0136612 40.72037579,-74.01399666 40.72013663,-74.01454987 40.72020219,-74.01449697 40.72047824,-74.01449697 40.72047824,-74.01512281 40.72055517,-74.01512282 40.72055516,-74.01512282 40.72055516,-74.01570657 40.72033947,-74.01606587 40.71857443,-74.01606587 40.71857443,-74.01675673 40.71817508,-74.01675673 40.71817509,-74.01802389 40.71525763,-74.03213267 40.71381576,-74.03213268 40.71381575,-74.03213269 40.71381574,-74.03213269 40.71381573)))

When I remove the precision modification to the coordinates, the hole is contained in the shell:

Potential PR: 2161

Fixed by #2161


Add 'Manual' value to the Visibility enum

Added a 'Manual' value to Visibility Enum that when used will prevent NetworkIdentity#OnSetHostVisibility() from modifying renderers.

I like it. Gives more power to the user to implement their own logic while keeping original behaviours.

Has this been tested and working?
About to give it to a random discord user.

Has this been tested and working?
About to give it to a random discord user.

I'm currently using that in my local project without issue, so yes.

visibility enum is for a different logic. it's about spawning / not spawning depending on the setting.
for sethostvisibility we need another solution to make it optional.
but keeping this open so we think about it

I changed the script to use a boolean value to set in the editor whether or not the renderers under the NetworkIdentity should be updated by OnSetHostVisibility().

Super, hope something along these lines gets added, for now i'l direct people to here for this option.

closing this PR because it's not the solution.
opened an issue for you here instead: https://github.com/vis2k/Mirror/issues/2793
we'll need another solution


feat: update helm chart with new services

This PR includes the deployment of latest services like janitor and metastore
It also contains other changes:

Remove required behavior for AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY. This variables don't need to be set when using AssumeRoleWithWebIdentity (doc )
move postgres envs to dedicated metastore values
Add config maps for index.yaml and kafka_source.yaml (maybe other config file like this ones could be added)
Add metastore_uri in config, won't be needed anymore once this issue is solved.
Move configurations like tolerations, nodeSelector etc to per service values.
Change urls in index.yaml, now targeting https://helm.quickwit.io/ which is exposed by gh-pages.

@clemcvlcs, sorry, I finally merged Mike's PR. So you'll have to rebase, solve some conflicts, and bump the chart version again.
The PR looks good to me, except for, as François mentioned, including the index and source configs. However, I do see the issue you're trying to solve. So let me get back to you with a workaround for bootstrapping some indexes and sources on startup.


ETA does not honor empty format_finished

Description
progressbar.ETA does not honor the argument format_finished="".
https://asciinema.org/a/bZdEriaO3amm4NItGPJ8svFPt
Code
import progressbar
for value in progressbar.progressbar(
    [1],
    widgets=[
        progressbar.ETA(
            format_finished="",
        ),
    ],
):
    pass

Actual (final) output:
ETA:      None
Expected (final) output:
`` (0 characters)
Versions

Python version: 3.11.0 (main, Dec 10 2022, 23:05:43) [GCC 9.4.0]
Python distribution/environment: CPython
Operating System: Linux Mint
Package version: 4.3b.0

Workaround
The expected behaviour can be accomplished by using format_finished="%(eta).0s" instead of format_finished="" .

That is intended behaviour to be honest :)
The reason for always requiring a formatstring is consistency in spacing. With an empty formatstring it would move the other stuff in the progressbar around.
You can work around it by using a space ' ' or an invisible character such as '\uFEFF'

@wolph I'm not sure I understand. Could you give an example where an empty-string result of ETA would "move the other stuff in the progress bar around"?

Just take a look at this code:
import time
import progressbar

bar = progressbar.ProgressBar(widgets=[
    progressbar.ETA(format_finished=' '),
    ' Some text here ',
    progressbar.Bar(),
])

for i in bar(range(5)):
    bar.update(i)
    time.sleep(0.1)

time.sleep(1.00)

The output looks something like this:
ETA:   0:00:00 Some text here |#########                                      |
ETA:   0:00:00 Some text here |##################                             |
ETA:   0:00:00 Some text here |############################                   |
ETA:   0:00:00 Some text here |#####################################          |
  Some text here |############################################################|

As you can see, the text moves and the bar becomes much wider suddenly. That can be a bit confusing :)

I see.
However, this also happens when setting format_finished-' ' which you suggested previously.
import progressbar
for value in progressbar.progressbar(
    [1],
    widgets=[
        "Foo",
        progressbar.ETA(
            format_finished=" ",
        ),
        "Bar",
    ],
):
    print()

FooETA:  --:--:--Bar
Foo Bar

Similarly, the invisible character you suggested also does not preserve ETA's output length (format_finished="\x00"):
FooETA:  --:--:--Bar
FooBar

This behaviour may look subpar, but that's a subjective notion. Some users may want to have it that way, some may not.
If those two options you suggested don't preserve the output length of ETA, why should explicitly setting format_string=""?

Oops... didn't notice your reply.
It actually does work in your example, in both cases :)
The reason that it doesn't appear to work is because you're not seeing the format_finished here but the format_not_started. The progressbar overwrites the current line and with the print() statement you're creating a new line so the old line won't be overwritten.
If you want to use print statements in your code I would suggest enabling output redirection: https://github.com/wolph/python-progressbar#combining-progressbars-with-print-output


makefile - specify SHELL=/bin/bash

Summary:
Our makefiles use bash syntax for string comparison, therefore set makefile var SHELL accordingly.
Description:
problem:  https://github.com/stan-dev/cmdstan/issues/852#issuecomment-613713061
solution: https://github.com/stan-dev/cmdstan/issues/852#issuecomment-613717625
Reproducible Steps:
Reproduce on Ubuntu - run make build
Current Output:
see linked comments
Expected Output:
make should build without errors or warnings.
Additional Information:
Provide any additional information here.
Current Version:
v2.22

tested this - rule needs to go into math lib make file libraries
moving issue to Stan math


Transdigiware patch 1

Developer's Certificate of Origin 1.1
   By making a contribution to this project, I certify that:

   (a) The contribution was created in whole or in part by me and I
       have the right to submit it under the Apache License 2.0; or

   (b) The contribution is based upon previous work that, to the best
       of my knowledge, is covered under an appropriate open source
       license and I have the right under that license to submit that
       work with modifications, whether created in whole or in part
       by me, under the same open source license (unless I am
       permitted to submit under a different license), as indicated
       in the file; or

   (c) The contribution was provided directly to me by some other
       person who certified (a), (b) or (c) and I have not modified
       it.

   (d) I understand and agree that this project and the contribution
       are public and that a record of the contribution (including all
       personal information I submit with it, including my sign-off) is
       maintained indefinitely and may be redistributed consistent with
       this project or the open source license(s) involved.

@sboagibm  saya belum mengetahui cara untuk menyelesaikan konflik pada cabang tersebut diatas !
apakah ada yang punya solusi baik untuk masalah seperti ini yang ada pada data file :1234:
travis.yml

@sboagibm saya belum mengetahui cara untuk menyelesaikan konflik pada cabang tersebut diatas !
apakah ada yang punya solusi baik untuk masalah seperti ini yang ada pada data file 🔢
travis.yml

@transdigiware we arent sure about the language used.... any help would be great


Payload capacity of Open Manipulator

May I know the payload which an Open Manipulator made of XL430 servos is capable of carrying?
Thank you,
Monica, P.

Hi, @MONICA-PALLA
We do not officially support the OpenManipulator with XL430 because of the low payload.
We assume that its payload will be less than 50g.
Thanks

Thank you for your reply.
Regards,
Monica, P.

What about a combination of XM430 and XL430. Is it okay to replace XM430 with XL430 for the gripper or the waist?

Hi, @zlatinovStefan
We haven't measured the payload with that system, but that might be possible. I think you can replace first and fourth XM430 to XL430.
The gripper dynamixel have to use current based position control mode but XL430s are not provided that mode, so that you need to use XM430 for the gripper dynamixel.


add e2e tests (close #28)

The project owner should setup Travis for this repository as described in this article
Tests will run in the latest Google Chrome version.
Changes:

added a test user in db/matterwiki.sqlite
added the first test set that covers creating an article

I've fixed tests.

Great! Thanks a lot of this :smile:
We could only run away from writing tests for so long.
Questions:
The test user is persistent in the database, right?
The test user has the ID of 1, which as of now, is the how we identify the admin. The admin has the ID 1.
I don't want all installations to have the test user by default.
Instead of adding the test user by default to the database. Can we add that in the documentation, that is you want to run tests you will have to create a test user first. How would such a system work with Travis?
To be honest, it's the first time I'm integrating tests with a project. I could use all the help I could get.

@nshntarora we are ready to provide any help with TestCafe =)
I believe that the best way is to use a separate db for tests. Take a look at my PR to @miherlosev 's branch: https://github.com/miherlosev/Matterwiki/pull/1/files
I've added TESTING env variable. If it is set the application uses tests/e2e/db/matterwiki.sqlite.
So, in this case it's possible that there are no a registered user when tests are started, so I've added some additional logic to the login function: https://github.com/miherlosev/Matterwiki/pull/1/files#diff-1219fe7385f85e76c06112d5bafc6594R69
If you like this approach, @miherlosev can add this changes to his pull request.
Also, I've created a screencast to show how you can run the tests during development: https://www.screencast.com/t/Cv7q37DSN7. I've shown two ways: via CLI and via Visual Studio Code TestCafe plugin

Thankyou @AlexanderMoskovkin :smile: this works great!
@miherlosev could you please make the required changes?

Hi! The test is failing because there is no db folder inside tests/e2e
Can you please add that, and also an empty .gitignore inside the db folder to prevent tracking issues :smile:

Done. You can review this

Merged. Thanks a lot :smile:
Also tried writing a basic test of my own. Great library! Good Job :+1:

🎉🎉🎉 You have e2e tests now :smile:
If you need any assistance feel free to contact us via issues, forum or on stackoverflow


backport: Merge bitcoin#18726,(partial)18628,18544,18672, (partial) 18764

just a note: bitcoin#18628 indeed fails in p2p_invalid_tx.py, I can't find a reason why at the moment: https://github.com/dashpay/dash/pull/5541/commits/05802174ab64493f630f74cf13ce5832868d3595#diff-df1d8c6f908e37a0ea01379f94855afcff3448005677c4795b74558c4d277fb6R206
@vijaydasmp maybe you can mark this backport "partial" and exclude p2p_invalid_tx.py  changes; or just skip this backport?

mark this backport "partial" and exclude p2p_invalid_tx.py

Hello @knst,  Thanks for checking on this PR , I will mark this backport "partial" and exclude p2p_invalid_tx.py

Hello @knst @UdjinM6 , please review

Check Merge Fast-Forward Only / check_merge (pull_request) Failing after 21s

needs rebase


Extension displays a "no new-line at end of file" warning for C++

It happens here on the last file at the bottom:
https://github.com/jcelerier/libremidi/pull/47/files
Except that since C++ 11 it is valid to not have a new line at end of file, is there a way to not have this show up as an error so that I do not get bogus pull requests ? :p
Thanks

I don't know what you're referring to, please include a screenshot.
If it's what I'm guessing, that's not a Refined GitHub feature, but I don't see it anywhere anyway

Ah it was force-pushed. Indeed it's what I thought.
That's a GitHub feature and language support is irrelevant. It's not an error but just a visual clue that the file does not end with a line break as expected.


[admin] Publish

Docs Build status updates of commit c7641e7:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/develop/script-buttons.md
:white_check_mark:Succeeded
View

docs/includes/rollout-note.md
:white_check_mark:Succeeded

docs/includes/run-from-button-desktop-support.md
:white_check_mark:Succeeded
View

docs/overview/excel.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


wd_xxx_init2_  support Parsing Environment Variables

Currently, environment variables are bound to algorithms (such as comp, cipher, and diggest), in the instruction scenario, CTX is not required.
If drivers are bound to environment variables, each driver should have it's environment variable, or drivers of the same type should use same environment variable.
If this parameter is set to wd_alg_driver.env_name="WD_COMP_CTX_NUM",wd_ctx_params_init's env_name parameter can be deleted, but the driver code needs to be modified.
This may need further discussion. Thanks.

@gaozhangfei
Currently, environment variables are bound to algorithms (such as comp, cipher, and diggest), in the instruction scenario, CTX is not required.
If drivers are bound to environment variables, each driver should have it's environment variable, or drivers of the same type should use same environment variable.
If this parameter is set to wd_alg_driver.env_name="WD_COMP_CTX_NUM",wd_ctx_params_init's env_name parameter can be deleted, but the driver code needs to be modified.
This may need further discussion. Thanks.

Thanks Wenkai

+1

Could you update these policies to docs/wd_environment_variable  as well.
By the way, all nodes have same number of queues, right?

close for

Could you update these policies to docs/wd_environment_variable as well. By the way, all nodes have same number of queues, right?

add policies to docs now. Yes, all enabled node shared same queue number.

+1
one warning though,  how about using two tabs instead of blank?
WARNING: suspect code indent for conditional statements (8, 0)
#26: FILE: include/wd_util.h:23:
for ((i) = 0, (config_numa) = (config)->config_per_numa;
[...]
By the way, one question.
is the ctx configured either sync or async in the beginning,
Is it changeable in using time? a bit wasty.


[0.5.0 misuse] Only exclude 'class .+(BaseModel):' is not enough for pydantic proj.

The "bug" reproducting branch:
https://github.com/boholder/puntgun/commits/test-fix-tool
Env( https://github.com/boholder/puntgun/commit/7ba97382a7fa43755710c1a5bfb6667c7f3d26ba ):
pyproject.toml:
[tool.fix_future_annotations]
exclude_lines = [
    'class .+\(BaseModel\):'
]

Run the tool (with pre-commit) with the configuration above, then revert the data.py file, unit tests can pass as usual.
Ok, I then tried one by one against the changes (made to the data.py file by this tool) and found that only the insert of from __future__ import annotations statement will actually triggered the error.
Without this line (tests pass):
https://github.com/boholder/puntgun/commit/1e85bb9256bfd061f43fcfca4056a9d690202f8f
With this line (tests fail):
https://github.com/boholder/puntgun/commit/005e1804160e65546388652145e6b9c3ae8bfe90
(puntgun-3.10) \code\python\puntgun>pdm test
ImportError while loading conftest 'E:\code\python\puntgun\tests\conftest.py'.
tests\conftest.py:9: in <module>
    from puntgun.rules.config_parser import ConfigParser
puntgun\rules\config_parser.py:93: in <module>
    import_rule_classes()
puntgun\rules\config_parser.py:32: in import_rule_classes
    importlib.import_module(f"{base_module_name}.{module_name}")
puntgun\rules\user\action_rules.py:3: in <module>
    from puntgun.client import NeedClientMixin
puntgun\client.py:15: in <module>
    from puntgun.rules.data import Media, Place, Poll, Tweet, User
puntgun\rules\data.py:217: in <module>
    class Tweet(BaseModel):
puntgun\rules\data.py:228: in Tweet
    author: User | None = User()
pydantic\main.py:342: in pydantic.main.BaseModel.__init__
    ???
E   pydantic.error_wrappers.ValidationError: 1 validation error for User
E   pinned_tweet
E     field required (type=value_error.missing)

I think it would be better to change the logic of exclude class configuration to "exclude the file where the class is located"? Although there is already a configuration to exclude files, but the configuration to exclude special classes is more flexible than to exclude files?
It up to you, dear maintainer, thank you very much for your work and quick response to the needs. ♥

Since we have exclude_files config, you can add the file pattern(s) to the list.

FYI, the pydantic doc says postponed annotation evaluation is supported: https://docs.pydantic.dev/usage/postponed_annotations/

It error seems correct to me, since you didn't provide a default to pinned_tweet:
https://github.com/boholder/puntgun/commit/005e1804160e65546388652145e6b9c3ae8bfe90#diff-0a9b69acda9a48c2e7fcb336cb26214000a21b4fea91548cc4dac47de0418f6fR60


Cannot access my notebooks

Opening Onenote I get the following error message:
Sorry, we can't get your notebooks right now. Please try again later.
Reference number: 1cf98d50-5ce8-4d71-a292-23634bb5d0e7
Any ideas how to fix this issue?

Hi Anuj,
thanks for responding so fast. Actually the problem did not resolve itself. But I realized, that this is rather a Microsoft issue than a problem with your fine app.
Best
Konrad

Oh, okay. Got it.


Added instructions how to make the rule work

Based on issue #196

Thanks @mbarzda this helps a lot!


false positive: Lint/ReturnInVoidContext

It should be possible to do return super to save some lines. Super should also not have a return value, so return super and return have the same return value.
def snippets=(snippets)
      snippets = snippets.reject(&:blank?)
      return super if snippets.first.is_a? Snippet
      snippets = snippets.map do |snippet_id|
        Snippet.find snippet_id if snippet_id.to_i > 0
      end
      super
    end

version:
rubocop -v
0.52.0

Unexpectedly, super in that subclass's method does provide whatever the superclass's method returns (whether the superclass return value is explicit or implicit).
I agree that is would be nice if this claim were true: "Super should also not have a return", I don't believe that Ruby behaves like we prefer.
I tested Ruby 2.2.8.

Since Rubocop should already check the method called by super if it is in my project, it should not return a value.

Unfortunately we can not do cross-references in RuboCop. We look at the files one by one, and don't have any notion of whether the parent class method will return something or not.


Add shields

I've added npm related shields. You can see them working here.
In the future, when we get some tests running, we can add some more, like Travis and coverage.
When merged, we can close #30

Looks awesome: