updates fail because of dependencies

MailChimp is the only add-on added to Statamic. Every update fails because of an error relating to dependencies. My best guess is it has something to do with this add-on.
Latest update to Statamic v2.8.11 renders this error:
"Couldn't install dependencies.
The process has been signaled with signal "9"." When I temporarily delete the add-on upgrade goes fine.

If you update from the command line, do you get more detailed errors?

It's only on the server and unfortunately I can't get there using command line. So then I'll have to update Statamic via the CP. This throws that error. Only way to circumvent this is to remove the add-on, update Statamic, and put the add-on back.
Local everything just runs fine.

You shouldn't be updating on the server, you should be updating on local and pushing everything to the server.
Without additional errors, this is extremely difficult to troubleshoot. It's likely the server is missing some packages that are required. I had the same issue on Dreamhost.
Going to close this, unfortunately, if you can get some more details please re-open and I'll look at it.


Support for Kubernetes v1.29

How to categorize this PR?

/area open-source
/kind enhancement
What this PR does / why we need it:
Support for Kubernetes v1.29.
Which issue(s) this PR fixes:
Part of https://github.com/gardener/gardener/issues/8871
Special notes for your reviewer:

Code changes have been tested in the following scenarios:

Create/Delete a new (normal/workerless) Shoot cluster with 1.29.0
Upgrade an existing (normal/workerless) Shoot cluster to 1.29.0

Release note:

Gardener can now support clusters with Kubernetes version 1.29. To allow creation/update of 1.29 clusters you will have to update the version of your provider extension(s) to a version that supports 1.29 as well. Please consult the respective releases and notes in the provider extension's repository.

Gardener can now support clusters with Kubernetes version 1.29. Extension developers have to prepare individual extensions as well to work with 1.29.

Thanks!
/approve

/lgtm
/approve

/retest


Quest 007 Submission: Taipy-Chess

Quine Quest Link
Description
Taipy-Chess, is a chess visualization tool, based on 20,000 games. You can see all the games, the openings they played, opponents, top played openings and most successful openings. You can see heatmaps and charts on the data. This app was built using the taipy framework for easy data analysis and visualization.
Demo
https://github.com/KorieDrakeChaney/taipy-chess/assets/92071726/c25fb773-124c-4836-bf0a-8bd80b2d5d14

Hi @KorieDrakeChaney, looks like the PR got reverted as your submission was directly under the Quine Package Quests directory. Could you create a new PR with your project under a subfolder? :pray:


Support for xcworkspace

Are there any plans to support xcworkspace? i have project that uses cocoapods so for it to compile it needs to compile from xcworkspace

Also it works projects using CocoaPods. Just you can change the subsequent commands to use the workspace after swiftcov commands. Like this:
$ swiftcov generate --output coverage_ios \
  xcodebuild test \
  -workspace ExampleFramework.xcworkspace \
  -scheme ExampleFramework-iOS \
  -sdk iphonesimulator \
  -configuration Release

If you have any error, please make sure the test executed normally without swiftcov commands.

Hi there,
I am trying to run swiftcov against an xcworkspace file containing three projects.
Each project has tests and the tests are building and executing fine when run from the command line.
If you use swiftcov generate, only for one project the gcov files are produced. For the rest of the projects no coverage data is produced.
Clear question: does swiftcov support xcworkspaces, yes or no?
If yes, any ideas what the issue could be?
Thanks!


Customize readthedocs builder to use apidoc and auto-generate Sphinx sources

Closes #36
Sphinx & other documentation changes

[x] Update 'Development Status' section in docs with more info
[x] Fill in some missing docstrings for API functions
[x] Set up sphinxcontrib-apidoc to generate module sources, and include in toctree
[x] Translate additional custom steps from Makefile to conf.py
[ ] Verify that docs built by readthedocs are correct
[x] Ensure that local behavior (with tox -e docs) is consistent with the readthedocs build
[x] Remove make.bat and most of the contents of Makefile
[x] Remove sphinx_autodoc_typehints to address deprecation warnings, and require Sphinx >= 3.0 (which now has autodoc type hints built in)
[x] Fix 'Title level inconsistent' issue in long_description (README + HISTORY) that was making PyPi complain
[x] Fix rST syntax/formatting issues in docstrings

Other build-related changes

[x] Remove usage of semantic-version package. On second thought, our versioning is simple enough that it's probably safe enough to go without it. It may be useful again in the future, though, if we do anything fancier with versioning.
[x] Run test builds for package distributions without uploading (using twine check) in Travis, to catch any build issues earlier on

Note: This has already been useful! It caught some issues with PyPi rejecting a build because the README had directives that render in Sphinx but not in plain rST.

[x] Also run test builds for Sphinx docs in Travis

Just about done. I can't confirm the readthedocs behavior just yet because it's only set up to build off of master, but plain make html now does everything listed above (and I've used close to the same setup in another project), so I'm pretty confident this will work.

Fixed and confirmed working with PR #39.


add project-definable TAPi18n.afterUILanguageChange hook

I needed a way of hooking into tap-i18n-ui initialed language changes. Thoughts?

Wouldn't adding an event to tap:i18n: on("language-change") be a better approach?
If TAPi18n.setLanguage is called outside tap:i18n-ui, the ui will still react to it but TAPi18n.afterUILanguageChange won't call

How would I go about hooking into the on('language-change') within my project -- is there an existing API? I made this PR because I assumed there wasn't a way to do this in tap:i18n main right now.
Still, there are some use-cases for this. If you'd like to hook into the tap-i18n-ui events only, but not for all language-change events (perhaps for UI fluff that only reacts to user input). The reason I used always instead of done was so that people could use custom logic to check the textStatus parameter (assuming it has the same api as jquery deferred), and then handle fails themselves if they want to.


Release Google.Cloud.PrivateCatalog.V1Beta1 version 1.0.0-beta02

Changes in this release:

Commit ac367e2: feat: Regenerate all APIs to support self-signed JWTs

Created release for Google.Cloud.PrivateCatalog.V1Beta1-1.0.0-beta02


How to make go mod exclude a list of directories from scanning for dependencies

I was wondering that how to use go mod if I want to ignore the directories that are demos or examples when I use go mod to download the useless dependencies which not require in my project.
Perhaps go mod should implement the feature just like in glide.yaml

package: github.com/Masterminds/glide
homepage: https://masterminds.github.io/glide
excludeDirs:
- node_modules
...

The Go project doesn't use the issue tracker for questions. See https://golang.org/wiki/Questions.

@mvdan This is not question. I think this should be a proposal.
Add new proposal for go mod to support excluding directories in project.

See the previous proposals like https://github.com/golang/go/issues/30058 and https://github.com/golang/go/issues/37724. You phrased this issue as a question, not as a proposal.


min, max operators not yet implemented

Syntax support is there, but:
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.5/bin/cozy", line 11, in <module>
    load_entry_point('Cozy', 'console_scripts', 'cozy')()
  File "/Users/dgrant/Dev/cozy/cozy/cozy/main.py", line 49, in run
    errors = typecheck.typecheck(ast)
  File "/Users/dgrant/Dev/cozy/cozy/cozy/typecheck.py", line 13, in typecheck
    typechecker.visit(ast)
  File "/Users/dgrant/Dev/cozy/cozy/cozy/typecheck.py", line 590, in visit
    res = super().visit(x)
  File "/Users/dgrant/Dev/cozy/cozy/cozy/common.py", line 141, in visit
    return getattr(self, visit_func)(x, *args, **kwargs)
  File "/Users/dgrant/Dev/cozy/cozy/cozy/typecheck.py", line 84, in visit_Spec
    self.visit(op)
  File "/Users/dgrant/Dev/cozy/cozy/cozy/typecheck.py", line 590, in visit
    res = super().visit(x)
  File "/Users/dgrant/Dev/cozy/cozy/cozy/common.py", line 141, in visit
    return getattr(self, visit_func)(x, *args, **kwargs)
  File "/Users/dgrant/Dev/cozy/cozy/cozy/typecheck.py", line 528, in visit_Query
    self.visit(q.ret)
  File "/Users/dgrant/Dev/cozy/cozy/cozy/typecheck.py", line 590, in visit
    res = super().visit(x)
  File "/Users/dgrant/Dev/cozy/cozy/cozy/common.py", line 141, in visit
    return getattr(self, visit_func)(x, *args, **kwargs)
  File "/Users/dgrant/Dev/cozy/cozy/cozy/typecheck.py", line 243, in visit_EUnaryOp
    raise NotImplementedError(e.op)
NotImplementedError: max

Min and max are now supported for bags of ints (b71ca206b3463c3a40bba8733ac2570f7451aac1).
The synthesizer doesn't do a great job with specifications involving these primitives, but they at least work.


sparkle: Fix popup

relative was not visible in storybook but did have an effect in production

cc @Duncid


Error from server (NotFound): mutatingwebhookconfigurations.admissionregistration.k8s.io "katib-mutating-webhook-config" not found

Hi Team,
Im facing issues when i enable kubeflow like below attaching inspect logs as well.
@microk8s:~$ microk8s enable kubeflow
Enabling dns...
Enabling storage...
Enabling dashboard...
Enabling ingress...
Enabling metallb:<IP_ADDRESS>-<IP_ADDRESS>...
Waiting for DNS and storage plugins to finish setting up
Deploying Kubeflow...
Kubeflow deployed.
Waiting for operator pods to become ready.
Waited 0s for operator pods to come up, 30 remaining.
Waited 15s for operator pods to come up, 30 remaining.
Waited 30s for operator pods to come up, 29 remaining.
Waited 45s for operator pods to come up, 29 remaining.
Waited 60s for operator pods to come up, 28 remaining.
Waited 75s for operator pods to come up, 28 remaining.
Waited 90s for operator pods to come up, 28 remaining.
Waited 105s for operator pods to come up, 26 remaining.
Waited 120s for operator pods to come up, 24 remaining.
Waited 135s for operator pods to come up, 21 remaining.
Waited 150s for operator pods to come up, 20 remaining.
Waited 165s for operator pods to come up, 20 remaining.
Waited 180s for operator pods to come up, 20 remaining.
Waited 195s for operator pods to come up, 20 remaining.
Waited 210s for operator pods to come up, 20 remaining.
Waited 225s for operator pods to come up, 19 remaining.
Waited 240s for operator pods to come up, 18 remaining.
Waited 255s for operator pods to come up, 16 remaining.
Waited 270s for operator pods to come up, 13 remaining.
Waited 285s for operator pods to come up, 7 remaining.
Waited 300s for operator pods to come up, 4 remaining.
Waited 315s for operator pods to come up, 4 remaining.
Waited 330s for operator pods to come up, 4 remaining.
Waited 345s for operator pods to come up, 3 remaining.
Waited 360s for operator pods to come up, 2 remaining.
Operator pods ready.
Waiting for service pods to become ready.
Kubeflow could not be enabled:
Error from server (NotFound): mutatingwebhookconfigurations.admissionregistration.k8s.io "katib-mutating-webhook-config" not found
Error from server (NotFound): validatingwebhookconfigurations.admissionregistration.k8s.io "katib-validating-webhook-config" not found
Command '('microk8s-kubectl.wrapper', 'delete', 'mutatingwebhookconfigurations/katib-mutating-webhook-config', 'validatingwebhookconfigurations/katib-validating-webhook-config')' returned non-zero exit status 1
Failed to enable kubeflow
Thanks
inspection-report-20201109_062622.tar.gz
Shrinidhi

According to this comment on #1698, a fix for this issue is included in microk8s 1.20/stable.
sudo snap install microk8s --classic --channel=1.20/edge


[feat]: Radio Button Tile Variant

Does your feature request relate to a specific USWDS component?
Radio Button
What USWDS Version is this feature present in?
2.10.0
Describe the solution you'd like
Add a tile variant to the radio button component (accomplished via addition of the uswds class usa-radio__input--tile)
The solution should be unified in terms of implementation and interface to https://github.com/trussworks/react-uswds/issues/790

just wanted to mention i have an issue on my project where I'd need this if it helps at all with prioritization!

@Shkeating this will be in the next release!


[core modules] Add ToLBRExchangeRateUpdateEvent to the Libra module

Adds an event for when the to_lbr_exchange_rate for a currency is updated.

That looks great!

:umbrella: The latest upstream changes (presumably d6aadde4f39182afece4fa29e3f76d8844f7f934) made this pull request unmergeable. Please resolve the merge conflicts.

@bors-libra r=sblackshear

:pushpin: Commit 3cb2ffe has been approved by sblackshear

:hourglass: Testing commit 3cb2ffe93b44338d106992799a82afbf03f8bc71 with merge b1908a3585e2124be5ddfc88e0e3716199a5e217...

:broken_heart: Test failed - checks-circle_commit_workflow

@bors-libra r=sblackshear

:pushpin: Commit daac1aa has been approved by sblackshear

:hourglass: Testing commit daac1aa64d6f7d86a0dc888e51895b63700fad9b with merge cfa60beceefe7dc4c0f6c22c81a14cb76787e0ad...

:sunny: Test successful - checks-actions_land_blocking_test, checks-circle_commit_workflow
Approved by: sblackshear
Pushing cfa60beceefe7dc4c0f6c22c81a14cb76787e0ad to master...


iframe and gifs not working on rtfd as expected

we need a different solution as copying to gifs to the _build dir for rtfd

fix also Title level inconsistent:

development.rst:198:
development.rst:271
development.rst:278
development.rst:297
gentutorials.rst:147
gentutorials.rst:164
mscolab.rst:77
mscolab.rst:102
mscolab.rst:129


Clicking on pictures in repos does nothing, it should oen in picture viewer thing

Has been fixed, will be deployed over the next few days


Feature request: Require explanations on rule overrides

Similar to this ESLint rule, I don't want any Ruff rules to be overridden without an explanation of why.

Is this the same as https://github.com/astral-sh/ruff/issues/5182 ?

Yes, looks like it, sorry for the duplicate!


Replace CUDA_VERSION with cudaRuntimeGetVersion() for if/IF conditionals

This is needed to support CUDA Python as CUDA_VERSION in CUDA Python does not mean the current CUDA version.

CUDA_VERSION in Cython files?

$ find . -name '*.pyx' -or -name '*.px[id]' | xargs grep CUDA_VERSION
./cupy/cuda/memory.pyx:    if CUDA_VERSION < 11020:
./cupy/fft/_callback.pyx:                        '-E', 'CUDA_VERSION=' + _build_ver,
./cupy_backends/cuda/api/_driver_extern.pxi:    int CUDA_VERSION
./cupy_backends/cuda/api/_runtime_typedef.pxi:    IF CUDA_VERSION > 0:
./cupy_backends/cuda/api/_runtime_typedef.pxi:    IF CUDA_VERSION >= 11000:
./cupy_backends/cuda/api/_runtime_typedef.pxi:    ELIF CUDA_VERSION >= 10000:
./cupy_backends/cuda/api/_runtime_typedef.pxi:    ELIF CUDA_VERSION == 9020:
./cupy_backends/cuda/api/runtime.pyx:    IF CUDA_VERSION > 0 or HIP_VERSION > 0:
./cupy_backends/cuda/api/runtime.pyx:    IF CUDA_VERSION >= 9020:
./cupy_backends/cuda/api/runtime.pyx:    IF CUDA_VERSION >= 10000:
./cupy_backends/cuda/api/runtime.pyx:    IF CUDA_VERSION >= 11000:
./cupy_backends/cuda/api/runtime.pyx:    if CUDA_VERSION < 11020:
./cupy_backends/cuda/api/runtime.pyx:    if CUDA_VERSION < 11020:
./cupy_backends/cuda/api/runtime.pyx:    IF CUDA_VERSION > 0:
./cupy_backends/cuda/api/runtime.pyx:    if CUDA_VERSION < 11020:
./cupy_backends/cuda/api/runtime.pyx:    if CUDA_VERSION < 11020:
./cupy_backends/cuda/api/runtime.pyx:    if CUDA_VERSION < 11020:
./cupy_backends/cuda/api/runtime.pyx:    if CUDA_VERSION < 11020:
./cupy_backends/cuda/api/runtime.pyx:    if CUDA_VERSION < 11020:
./cupy_backends/cuda/api/runtime.pyx:    if CUDA_VERSION < 11020:
./cupy_backends/cuda/api/runtime.pyx:IF CUDA_VERSION >= 10000:
./cupy_backends/cuda/api/runtime.pyx:    if CUDA_VERSION < 10000:
./cupy_backends/cuda/api/driver.pyx:    # Note: CUDA_VERSION is defined either in CUDA Python or _driver_extern.pxi
./cupy_backends/cuda/api/driver.pyx:    if CUDA_VERSION > 0:
./cupy_backends/cuda/api/driver.pyx:        return CUDA_VERSION
./cupy_backends/cuda/api/driver.pyx:    if CUDA_VERSION < 9000:
./cupy_backends/cuda/libs/nvrtc.pyx:    if CUDA_VERSION < 11020 or runtime._is_hip_environment:
./cupy_backends/cuda/libs/nvrtc.pyx:    if CUDA_VERSION < 11010 or runtime._is_hip_environment:

Yes, but _runtime_typedef.pxi can be kept as-is as IF CUDA_VERSION condition cannot be removed and it is not used by CUDA Python.

Seems some codes depend on Cython's dead code elimination:
https://github.com/cupy/cupy/blob/f81c85f1239d1b3da3fb3d7be3dd701b988526da/cupy_backends/cuda/api/driver.pyx#L278-L286
https://github.com/cupy/cupy/blob/f81c85f1239d1b3da3fb3d7be3dd701b988526da/cupy_backends/cuda/api/runtime.pyx#L771-L777
As only a few modules, driver, runtme and nvrtc, import CUDA Python, giving an alias to CUDA_VERSION in a C header and importing it may be a handy way.

You can remove these conditionals as we no longer support CUDA 9.x 😄
Besides that, in general, build-time conditionals (IF) must be replaced with if, as the CuPy built with CUDA Python will not depend on a specific CUDA version.

As only a few modules, driver, runtme and nvrtc, import CUDA Python, giving an alias to CUDA_VERSION in a C header and importing it may be a handy way.

We are going to use CUDA Python in other modules e.g. cublas once CUDA Python support is available

get_build_version wants CUDA_VERSION at the build time. How about this?
https://github.com/cupy/cupy/blob/f81c85f1239d1b3da3fb3d7be3dd701b988526da/cupy_backends/cuda/api/driver.pyx#L78-L79

I think it's ok to leave it as-is. show_config() uses it like this:
https://github.com/cupy/cupy/blob/f81c85f1239d1b3da3fb3d7be3dd701b988526da/cupyx/_runtime.py#L152-L159
Other use of get_build_version() may need to be rewritten.

Okay, we still have the build-time CUDA version so we need to see and bake CUDA_VERSION in cuda.h there instad of CUDA Python's somehow, right? Also, I'll check where get_build_version() is used.

Yes. Currently only {driver,runtime,nvrtc}.pyx uses CUDA Python, whereas other modules still directly link to CUDA Toolkit libraries. So we still need to burn-in build-time CUDA_VERSION from the cuda.h (not CUDA Python). However CUDA Python also exports CUDA_VERSION, now we have to do this bunr-in somewhere else than driver.pyx.

My idea is to do that in every module using driver.get_build_version(). For example, burn-in CUDA_VERSION in cupy_backends.cuda.libs.cusolver, then use it in
https://github.com/cupy/cupy/blob/f81c85f1239d1b3da3fb3d7be3dd701b988526da/cupy/cusolver.pyx#L109

Let me clarify that driver.get_build_version() returns CUDA Python's CUDA_VERSION if it is left as it-is (when CUDA Python is enabled). So I think we need to change driver.get_build_version() somehow to see cuda.h's CUDA_VERSION.
Also, I think making each module have the burn-in CUDA_VERSION is reasonable, though I'm not sure driver.get_build_version() is expanded to CUDA_VERSION at build-time and it may be left as a runtime call. How about directly declaring extern CUDA_VERSION from cupy_backend.h to make it burned-in at each module?

Ah, let me make myself understand the case further...

Let me clarify that driver.get_build_version() returns CUDA Python's CUDA_VERSION if it is left as it-is (when CUDA Python is enabled). So I think we need to change driver.get_build_version() somehow to see cuda.h's CUDA_VERSION.

Also, I agree that making each module have the burn-in CUDA_VERSION is reasonable, though I'm not sure driver.get_build_version() is expanded to CUDA_VERSION at build-time and it may be left as a runtime call. How about directly declaring extern CUDA_VERSION from cupy_backend.h to make it burned-in at each module?

Let me clarify that driver.get_build_version() returns CUDA Python's CUDA_VERSION if it is left as it-is (when CUDA Python is enabled).

Yes.

So I think we need to change driver.get_build_version() somehow to see cuda.h's CUDA_VERSION.

I think it's better to expose CUDA_VERSION as cupy_backends.cuda.libs.cusolver._get_cuda_build_version() etc.

Phew, now I got your point about how driver.get_build_version should work. I misunderstood that.

In an offline talk, we found that Cython looks up and finds cuda.h's CUDA_VERSION first even when cuda.ccuda.* is cimported.

Let's prefix all compile_time_envs with CUPY_ to avoid confusion and conflict like this 😅
https://github.com/cupy/cupy/blob/master/cupy_setup_build.py#L947-L957


Added Orchestration LLM Config Convenience

Context
AI/ai-sdk-java-backlog#105.
As an orchestration user, I want to have a convenient way of configuring which LLM to use, and with which hyper parameters.
Feature scope:

[x] Added OrchestrationAiModel extends LLMModuleConfig

Definition of Done

[x] Functionality scope stated & covered
[x] Tests cover the scope above
[x] Error handling created / updated & covered by the tests above
[ ] ~Aligned changes with the JavaScript SDK~
[x] Documentation updated
[ ] ~Release notes updated~

Also, I think its a bit weird that we don't use our own, central interface for this. Any reason not to?

The AiModel interface is only there to cache deployments and Orchestration does not use deployments, so it is unrelated.

The AiModel interface is only there to cache deployments and Orchestration does not use deployments, so it is unrelated.

But this is implemented by OpenAiModel, i.e. we use this for our other model constants, so how is it unrelated?

The AiModel interface is only there to cache deployments and Orchestration does not use deployments, so it is unrelated.

But this is implemented by OpenAiModel, i.e. we use this for our other model constants, so how is it unrelated?

The cache is the only user of this AiModel interface, I don't need to cache GPT 35 Turbo to use it in orchestration.


Not working anymore

/home/unknown/Schreibtisch/STEAMBOT/node_modules/steam/node_modules/steam-resources/index.js:39
var builder = ProtoBuf.newBuilder();
^
TypeError: ProtoBuf.newBuilder is not a function
at loadProtoFiles (/home/unknown/Schreibtisch/STEAMBOT/node_modules/steam/node_modules/steam-resources/index.js:39:26)
at Object. (/home/unknown/Schreibtisch/STEAMBOT/node_modules/steam/node_modules/steam-resources/index.js:14:13)
at Module._compile (internal/modules/cjs/loader.js:1015:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1035:10)
at Module.load (internal/modules/cjs/loader.js:879:32)
at Function.Module._load (internal/modules/cjs/loader.js:724:14)
at Module.require (internal/modules/cjs/loader.js:903:19)
at require (internal/modules/cjs/helpers.js:74:18)
at Object. (/home/unknown/Schreibtisch/STEAMBOT/node_modules/steam/lib/steam_client.js:3:30)
at Module._compile (internal/modules/cjs/loader.js:1015:30)

It works for me. Please provide steps to reproduce.

before a few days it works perfect now it doesnt work i tried to update it
thx for your fast response

You haven't provided steps to reproduce so I can't help you. Try reinstalling or something.


New task window scales with current tasks window size

The new task window gets taller as you add more tasks. This can create visual issues as more tasks are added. This can be fixed by making the new task window static. Even better would be a window that starts at a certain size but can grow as text is added.

Your point is valid, it can create a very bad user experience if there are a lot of tasks!
Would you like to work on this?

Sure. I'll get right to work.


[Submit Template] Azure SQL + Prisma

New azd-template Submission
Fill in the sections below to populate a new Gallery carry for your template. An example of a valid template object is given at the end for reference. All fields are mandatory unless explicitly identified as optional
1. Title
Full Stack Application with Azure SQL & Prisma
2. Description
A real study case application how to apply Node.Js with:

Azure SQL
Prisma
Vue.Js
Azure Functions
Azure Static Web Apps
Azure Dev CLI

3. Author Profile
GitHub Repository Link
Author - Glaucia Lemos
4. Author Name
Glaucia Lemos
5. Template Repo
The GitHub repo containing the template being contributed - must be a valid, complete template
6. Standard Tags
vuejs, azure-functions, azure-static-web-apps, azure-sql, nodejs, javascript, azure, prisma, github-actions, dev-container
7. Additional Tags (optional)
Don't see a relevant standard tag for your template? Request these tags be added, and then used for your template. These could be new languages, services, or application domains.
8. Architecture Diagram or Application Screenshot
HERE

Example Of Valid Template
  {
    title: 'Full Stack Application with Azure SQL & Prisma',
    description: 'A Full Stack Application how you can build a CRUD application using Azure SQL, Prisma, Azure Functions and with a deployment of this application with Azure Static Web Apps integrated with GitHub Actions. ',
      preview: ``,
    website: 'https://github.com/glaucia86',
    author: 'Glaucia Lemos',
    source: 'https://github.com/glaucia86/azure-sql-prisma-vue',
    tags: ['vuejs','azure-functions','javascript','nodejs','azure-sql','azure-static-web-apps','prisma','dev-container'],
  },

Next Steps
Once submitted the issue will be reviewed - we plan to do reviews on a rolling basis at regular intervals. The process will involve checking that template information is complete, and the template is valid.

If we have questions or enhancements, we will add comments in issue thread (issue stays open)
If the contribution is approved, we'll update the gallery directly (issue will then be closed)

Please have a look at the all new bicep module structure and get the /core modules in the project and then follow that same structure as much as possible.
In azure.yaml, provider section is optional. You can remove it.
Please update azure.yaml to include the full app.

I think it will be best if you open a PR against your repo so I can provide feedback in the form of PR comments.

Since you are using SQL server, you may want to reach out to @madebygps who is wrapping up a similar template.  You'll want to follow that same pattern for getting and setting passwords (if you can).
https://github.com/Azure/azure-dev/pull/551

Please have a look at the all new bicep module structure and get the /core modules in the project and then follow that same structure as much as possible.
In azure.yaml, provider section is optional. You can remove it.
Please update azure.yaml to include the full app.

I think it will be best if you open a PR against your repo so I can provide feedback in the form of PR comments.

Hi, @jongio. I confess that I have some difficult to create these files. Once I'm still learning it and I think so difficult to create. Who created for me these infra was @manekinekko. If you could update it, I really appreciated it.

I am working on this issue @glaucia86 👍

@jongio while working on updating the PR for Glaucia, I had a few comments and questions:

Please have a look at the all new bicep module structure and get the /core modules in the project and then follow that same structure as much as possible.

Are all those core modules required for this template? The template doesn't need all of those services. Is azd parsing this exact folder structure? Or can it be flexible?

In azure.yaml, provider section is optional. You can remove it.

Done.

You'll want to follow that same pattern for getting and setting passwords (if you can).

The app in this template is not using KeyVault. This is why we haven't provisioned that resource. Also, I was checking PR #551 and noted this function secretOrRandomPassword. Where is this function defined?

Add azd to the devcontainer - see https://github.com/Azure/azure-dev/tree/main/templates/common/.devcontainer for a bunch of examples

Done.

Please update azure.yaml to include the full app.

The template is meant to be deployed to SWA. Both client and API. This is currently not possible using azd deploy (see https://github.com/Azure/azure-dev/issues/837 )

Add azd up and azd install steps to the readme.

It's already there (at the bottom under > Project: db). Do you need to be moved elsewhere?

Okay, I didn't see that as it is a collapsed section.

Please move to using azd env set commands for setting env vars instead of asking them to create a .env in the api folder.
You don't need all of what is in /core.  But the structure should be adopted in templates coming from MS.  You can remove what you don't need.
secretOrRandomPassword https://github.com/Azure/azure-dev/blob/8bb8e2d992b7fb2878d2be489adaedac5d567e93/cli/azd/pkg/cmdsubst/secretOrRandomPassword.go
Are you using the SWA config file in this app to deploy the API?

Please move to using azd env set commands for setting env vars instead of asking them to create a .env in the api folder.

@glaucia86 are you OK with this change? Would this affect the structure of your videos?

You don't need all of what is in /core. But the structure should be adopted in templates coming from MS. You can remove what you don't need.

Gotcha!

Are you using the SWA config file in this app to deploy the API?

Yes. Because of this https://github.com/Azure/azure-dev/issues/837

Please move to using azd env set commands for setting env vars instead of asking them to create a .env in the api folder.

@glaucia86 are you OK with this change? Would this affect the structure of your videos?

You don't need all of what is in /core. But the structure should be adopted in templates coming from MS. You can remove what you don't need.

Gotcha!

Are you using the SWA config file in this app to deploy the API?

Yes. Because of this Azure/azure-dev#837

Sorry for my delay here. No problem @manekinekko. Later I can create a article or another video with these new changes.

/core has been updated. please have a look at what is in main
Also LMK if you want to work together on this.

@glaucia86 - Would you like to work on getting this updated/added?

@glaucia86 - Would you like to work on getting this updated/added?
Hi, @jongio! If you could help me, I will really appreciate it!

@jongio can you help @glaucia86 in moving to core bicep modules?

@rajeshkamal5050 @jongio fwiw, I've started doing some migration work in my PR here for @glaucia86. Feel free to grab that PR so that you don't have to start from scratch.

Thank you, @manekinekko. I really appreciate that.

@glaucia86 any updates on the template?


Use Flutter compute for parsing models

Following #164, I suggest a solution for using Flutter's compute function. It requires users to define a top-level function (like for any Isolate, basically).
I'll probably need some help with this solution, and it depends on #407 being passed first, since it needs a new Parser enum value to be defined.
We should also pass #406 first too, since it will remove a lot of noise for code formatting.

Once #412 is merged and retrofit 3.0.0 is released, the tests should be able to run and pass.

@trevorwang ok, I think I'm finally ready for review. I had to make a change to handle Lists as spawning an isolate per element was a crazy bad idea, but it makes the usage a bit more bulky. There's probably a way to automate the list functions, but I'd rather save that for a future improvement.
From testing with my app, even just spawning 1 isolate is soooo slow. I can't believe how poorly Flutter/Dart handles this :(

I was wrong. I broke something.

Everything looks well, can you update
https://github.com/trevorwang/retrofit.dart/blob/cbfef434de1a0d94f5c79e0b770dcf1b3f0feb1b/generator/CHANGELOG.md?plain=1#L1
accordingly?


Clean step should clean submodules too

Otherwise the call to arc patch fails with "A submodule has uncommitted or untracked changes"

I believe you need to configure Jenkins to "Clean after checkout" under additional behaviors -- I don't think this is something we can do from within the Phabricator plugin.

But the phabricator plugin forces a git clean already.  Surely you can add an option to also clean submodules using 'git submodule foreach git clean -fd'

Sure, but why add a flag to this plugin that's not specific to Phabricator and already available with another option?

Because it's Phabricator that prompts and subsequently causes an error when it tries to apply a patch and there are un-clean submodules that Phabricator complains about.  Because phabricator is doing the complaining, it should take some responsibility in giving the option to clean up the submodule before it complains about it.


Houdini: Implement review family with opengl node

Brief description
Implements a bare minimum viable product for #2720
Description
Uses the opengl ROP node to produce PNG images.
Additional info
Required:

[x] Working with Extract Review
[x] Working with Extract burnins
[x] Might need refactoring after #3046
[x] Support (animated) focal length burnin like maya does since #4531

Nice-to-haves (these are best as separate PRs maybe?)

[ ] Expose some crucial default settings?
[ ] Allow resolution of 0, 0 to represent "take resolution from asset data"?
[ ] Add Attach To functionality (also see discussion)
[ ] Maya has a "delete images" option.
[ ] Potentially might need default settings in OpenPype settings for specific Display Options on the ROP node, etc. (Probably not needed for minimum viable product of the feature)
[ ] Might need a validator for the file extension - it's assuming it remains set to .png currently.
[ ] Selected nodes should be filtered to 'cameras' and '/obj' level paths to go into camera and scenepath parm.
[ ] The Houdini logic for "Collect Frames" currently requires a period (.) before the frame numbers - something to keep an eye out for. (Probably best as separate issue/PR)
[ ] Add documentation! :)

Testing notes:

Launch Houdini
Create review instance
Set the "object path" and "camera" to something correct (needs to be done manually for now)

Might need refactoring after https://github.com/pypeclub/OpenPype/pull/3046

As I am looking at the code, only minimal.
What are your thoughts about dealing with the resolution? In Maya, it is rather complex thing - getting resolution from asset but allowing you to override it through OP Settings and even Maya viewport settings.

What are your thoughts about dealing with the resolution? In Maya, it is rather complex thing - getting resolution from asset but allowing you to override it through OP Settings and even Maya viewport settings.

@antirotor With this commit I've made it so that the resolution by default is set on the OpenGL rop and does not just inherit it from the camera it's rendering so it's more explicit.
Other than that I was thinking of potentially having it similar to maya. The integer fields that allow to override resolution on the OpenGL node actually allow negative values (go figure!). So I was thinking to do similar to maya that if -1 was found as value that it'd fall back to use asset resolution. So basically match the Maya behavior.
Would you prefer different?

About a feature like "attachTo" in maya. What would integrators and publish plug-ins need for me to be able to do the same in Houdini?

About a feature like "attachTo" in maya. What would integrators and publish plug-ins need with regards to instance.data (or context.data?) for me to be able to do the same in Houdini?

With the old publisher it takes just a subset name since there is no way to attach reviews to already published subsets. With the new one, we could maybe do something similar, but there are now ids there that are more robust and in the future we could extend it - find if the connected node to review node is publish instance or loaded instance and either add review to existing version or add to the new one.
Another question is how to deal with 'isolate' feature to create review just for the connected data or for the whole scene. But that's maybe something for the future PRs.

With the old publisher it takes just a subset name since there is no way to attach reviews to already published subsets. With the new one, we could maybe do something similar, but there are now ids there that are more robust and in the future we could extend it - find if the connected node to review node is publish instance or loaded instance and either add review to existing version or add to the new one.

For now:
instance.data["attachTo"] = "other_subset_name"
Check, thanks!
Not sure how attach to technically works down the line - but somehow I'd have expected to also be able to attach a review to multiple subsets. But probably since I haven't used the feature yet I might just be overthinking things.

Another question is how to deal with 'isolate' feature to create review just for the connected data or for the whole scene. But that's maybe something for the future PRs.

OpenGL can specify what "objects" to render - so isolating certain parts of your scene is totally doable. You can also explicitly exclude certain objects, etc. Would leave that up to the artist to set up for now if they'd like to tweak it. That would be ok?

I've made this work as barebones as it was but now with the new publisher.
I tried implementing this on the creator:
    def get_instance_attr_defs(self):

        return [
            BoolDef("override_resolution",
                    label="Override resolution",
                    tooltip="When disabled the resolution set on the camera "
                            "is used instead.",
                    default=True),
            NumberDef("resx",
                      label="Resolution Width",
                      default=1280,
                      minimum=2,
                      decimals=0),
            NumberDef("resy",
                      label="Resolution Height",
                      default=720,
                      minimum=2,
                      decimals=0),
            NumberDef("aspect",
                      label="Aspect Ratio",
                      default=1.0,
                      minimum=0.0001,
                      decimals=3)
        ]

But as I've mentioned on discord a few times it just doesn't seem like the Houdini integration works in that regard. I started getting errors on refresh/reset and gave up again.
Additionally I would've liked it the HoudiniCreator plug-in allowed me to "intercept" certain attribute definitions on how they'd be read and imprinted into the scene easily. We might want to add a dedicated method to allow interception certain variables too. So that e.g. these attributes shown here could be actually stored and set using the dedicated attributes that the Houdini node itself already has for it. That would make much more sense.
@antirotor Any idea how we could go about making this production-ready and workable?

@fabiaserra You mentioned you were interested in generating "reviews" from Houdini. This was a prototype that I believe worked. I've pulled in latest develop branch so I'd say give it a test run for some feedback.
@antirotor I'm not sure how valid these notes addressed to you still are but if there's also someone on OP team able to give this a test run that'd be welcome!

@fabiaserra You mentioned you were interested in generating "reviews" from Houdini. This was a prototype that I believe worked. I've pulled in latest develop branch so I'd say give it a test run for some feedback.
@antirotor I'm not sure how valid these notes addressed to you still are but if there's also someone on OP team able to give this a test run that'd be welcome!

Amazing, thank you @BigRoy !

We might solve it by slightly changing what imprint accepts and use ch() to link "native" parameters to ours. That would be probably the easiest way to implement it.

It would be for both imprint and loading the data.

So I've updated it again and done some test runs with fixes. I've also added focal length burnin support like @tokejepsen dit with #4531 for Maya.
This PR should put it in a first rough usable state. However do still take a look at the Nice-to-haves list on the initial post and let me know if there's anything there that should be crucial to getting this PR merged.
@antirotor @fabiaserra it would be gold if any of you could test this out.

The last three commits accidentally implemented the fix of PR #4739 as well - it shouldn't be a problem, but just so you know. My software apparently didn't switch branches quickly enough while I was already committing the fixes. 🐌

@tokejepsen What do you think? Should I update the maya_burnin default preset to also operate on Houdini host and call it the focallength_burnin instead since this PR now also supports the animated focal length?

Works as expected after cleaning up of the enum in the creator's settings. The updated PR can export image sequences with different image formats. Also it has a similar option of deleting images as if maya.
Basically the user can choose whether they want to keep image sequences or not. By default, the sequences are removed after publishing and only the video is in the related publish folder.

Not sure if it is a good idea(it's just personal opinion) - I think the selected node option should mainly allow user selecting the camera for the playblast, as it seems the camera is mandatory for opengl, while the scene path is always left as /obj/ by default , When you hit render, it will yell at you if there is no existing camera while it won't yell if the scene path is left as  /obj/ , there should be always validation for the scene path to make sure the user won't keep it empty or set a wrong path.

Not sure if it is a good idea(it's just personal opinion) - I think the selected node option should mainly allow user selecting the camera for the playblast, as it seems the camera is mandatory for opengl, while the scene path is always left as /obj/ by default , When you hit render, it will yell at you if there is no existing camera while it won't yell if the scene path is left as /obj/ , there should be always validation for the scene path to make sure the user won't keep it empty or set a wrong path.

Yes, agree that workflow could be better.
Our houdini artist actually mentioned he'd prefer the default scenepath to always be /obj and then Candidate Objects which defaults to * in houdini to be cleared (so it doesn't show anything by default) but then in Force Objects it'd add your selection (whatever in your selection is not a camera) so that what you had selected will always be rendered even if at some point in time the user turns off the display flag.
That'd make the rop node way more explicit and not dependent on display flags of your scene at any point in time. Thoughts?

Not sure if it is a good idea(it's just personal opinion) - I think the selected node option should mainly allow user selecting the camera for the playblast, as it seems the camera is mandatory for opengl, while the scene path is always left as /obj/ by default , When you hit render, it will yell at you if there is no existing camera while it won't yell if the scene path is left as /obj/ , there should be always validation for the scene path to make sure the user won't keep it empty or set a wrong path.

Yes, agree that workflow could be better.
Our houdini artist actually mentioned he'd prefer the default scenepath to always be /obj and then Candidate Objects which defaults to * in houdini to be cleared (so it doesn't show anything by default) but then in Force Objects it'd add your selection (whatever in your selection is not a camera) so that what you had selected will always be rendered even if at some point in time the user turns off the display flag.
That'd make the rop node way more explicit and not dependent on display flags of your scene at any point in time. Thoughts?
Yes, I agree that we should make sure the rop node is independent on display flags.

Test it just now. Nice, the camera params of the opengl nodes would be set to the path of the selected camera, while the force objects params would be set to the paths of the selected nodes.
I just checked again on the nice-to-have in this PR, and find out you want to use 0, 0 to represent resolution taken from asset data...And somehow the validator does not allow this happened. I double check the opengl node in Houdini and find out it actually works if the user playblast in 0, 0 resolution.  Maybe it is good for testing if the playblast works before the full review playblast as I know some scene can still be huge even there is a cache.
I am not quite sure about the image format validator though.

And somehow the validator does not allow this happened. I double check the opengl node in Houdini and find out it actually works if the user playblast in 0, 0 resolution. Maybe it is good for testing if the playblast works before the full review playblast as I know some scene can still be huge even there is a cache.

I can't really see a production case where you'd want to actually end up playblasting a 0x0 resolution. I think with the validator for now is fine. Just need to add documentation I think.

@antirotor this should be ready. Could you take a look?
@tokejepsen any chance you could take a peek too and maybe check the documentation?

Yeah, good point. Should be moved to here; https://openpype.io/docs/project_settings/settings_project_global#publish-plugins

@tokejepsen I'll be moving that in a separate PR. There is no Extract Burnin documentation for the OP v3 it seems but only pype v2. Adding that here would make this PR more bloated than needed and I expect that the documentation might get some more feedback going and I'd rather get this PR in separately from that. Does that mean you could approve this PR?

This PR should be usable and pretty much ready to merge. ❤

I created issue [focalLenght](https://github.com/ynput/OpenPype/issues/4789) for Toke's comment.
Looking into code, I don't think it should be applicable for Houdini, imho

This should be ready to merge @antirotor

Works fine! The only problem (not related to this PR and probably partially solved by https://github.com/ynput/OpenPype/pull/4700) is that the ROP node is not handling gamma correction very nice - I had to manually set gamma to 2.2 when rendering to pngs otherwise the resulting video would be dark. This would be handled by OCIO better, so I suppose it isn't of much concern

Thanks, that does sounds like something we can track in a separate dedicated issue to resolve. 👍


Easier build

#35 , but with pins instead of a custom repo.

@yomimono I'm adding warnings and I can't compile the project locally easily, so I'll try to continue that PR if it's fine with you.

@samoht Be my guest!

See #42


[msal-extensions] Extensions #3

Add persistence on Linux, Windows, and Mac
Add persistence plugin, which can be set on MSAL

Same comment about unit tests


Add menu and keyboard shortcut

Add the ability to see the file favorites like this and open this menu with a command

Just to make sure I understand your request :
Goal is to have a global shortcut which would open a searchbar allowing you to search/filter your favorites and open them.
Like the CTRL+P shortcut somehow.

Closing as no feedback provided

Closing as no feedback provided


chore: Update getHookMultiPlexer.mdx

quick fixes to make the doc better!
(was duplicate

looks good thanks!


Rename "arg" in definitions to "param"

This makes naming of these concepts more consistent with other languages, makes it easier to distinguish between the definition site and the call site, and frees up names like FunctionArg for other usages.

Fine by me


[BUG] Error failed to create fleet-default/rke2-machineconfig-cleanup-sa is found on Rancher POD

Describe the bug

A v132 cluster is upgrade to v140-rc1 with Rancher v2.9.2, such loop error logs are observed on Rancher POD.
note: will also check if a freshly installed v140-rc1 cluster also has such logs.
2024/10/02 07:53:06 [INFO] Rancher version v2.9.2 (3da2ae0cabd11aa3af8bc463f5e5e74a3f156c71) is starting
...

2024/10/02 09:26:41 [ERROR] error syncing 'local/default-token': handler cluster-registration-token: failed to create fleet-default/rke2-machineconfig-cleanup-sa /v1, Kind=ServiceAccount for rke2-machine-config-cleanup: namespaces "fleet-default" not found, failed to create fleet-default/rke2-machineconfig-cleanup-script /v1, Kind=ConfigMap for rke2-machine-config-cleanup: namespaces "fleet-default" not found, failed to create fleet-default/rke2-machineconfig-cleanup-cronjob batch/v1, Kind=CronJob for rke2-machine-config-cleanup: namespaces "fleet-default" not found, requeuing
2024/10/02 09:28:41 [ERROR] error syncing 'local/default-token': handler cluster-registration-token: failed to create fleet-default/rke2-machineconfig-cleanup-sa /v1, Kind=ServiceAccount for rke2-machine-config-cleanup: namespaces "fleet-default" not found, failed to create fleet-default/rke2-machineconfig-cleanup-script /v1, Kind=ConfigMap for rke2-machine-config-cleanup: namespaces "fleet-default" not found, failed to create fleet-default/rke2-machineconfig-cleanup-cronjob batch/v1, Kind=CronJob for rke2-machine-config-cleanup: namespaces "fleet-default" not found, requeuing
2024/10/02 09:30:41 [ERROR] error syncing 'local/default-token': handler cluster-registration-token: failed to create fleet-default/rke2-machineconfig-cleanup-sa /v1, Kind=ServiceAccount for rke2-machine-config-cleanup: namespaces "fleet-default" not found, failed to create fleet-default/rke2-machineconfig-cleanup-script /v1, Kind=ConfigMap for rke2-machine-config-cleanup: namespaces "fleet-default" not found, failed to create fleet-default/rke2-machineconfig-cleanup-cronjob batch/v1, Kind=CronJob for rke2-machine-config-cleanup: namespaces "fleet-default" not found, requeuing
W1002 09:31:49.278732      39 warnings.go:70] kubevirt.io/v1 VirtualMachineInstancePresets is now deprecated and will be removed in v2.
2024/10/02 09:32:42 [ERROR] error syncing 'local/default-token': handler cluster-registration-token: failed to create fleet-default/rke2-machineconfig-cleanup-sa /v1, Kind=ServiceAccount for rke2-machine-config-cleanup: namespaces "fleet-default" not found, failed to create fleet-default/rke2-machineconfig-cleanup-script /v1, Kind=ConfigMap for rke2-machine-config-cleanup: namespaces "fleet-default" not found, failed to create fleet-default/rke2-machineconfig-cleanup-cronjob batch/v1, Kind=CronJob for rke2-machine-config-cleanup: namespaces "fleet-default" not found, requeuing

2024/10/02 09:33:54 [ERROR] rkecluster fleet-local/local: error while retrieving management cluster from cache: management cluster cache was nil
2024/10/02 09:34:42 [ERROR] error syncing 'local/default-token': handler cluster-registration-token: failed to create fleet-default/rke2-machineconfig-cleanup-sa /v1, Kind=ServiceAccount for rke2-machine-config-cleanup: namespaces "fleet-default" not found, failed to create fleet-default/rke2-machineconfig-cleanup-script /v1, Kind=ConfigMap for rke2-machine-config-cleanup: namespaces "fleet-default" not found, failed to create fleet-default/rke2-machineconfig-cleanup-cronjob batch/v1, Kind=CronJob for rke2-machine-config-cleanup: namespaces "fleet-default" not found, requeuing
2024/10/02 09:36:42 [ERROR] error syncing 'local/default-token': handler cluster-registration-token: failed to create fleet-default/rke2-machineconfig-cleanup-sa /v1, Kind=ServiceAccount for rke2-machine-config-cleanup: namespaces "fleet-default" not found, failed to create fleet-default/rke2-machineconfig-cleanup-script /v1, Kind=ConfigMap for rke2-machine-config-cleanup: namespaces "fleet-default" not found, failed to create fleet-default/rke2-machineconfig-cleanup-cronjob batch/v1, Kind=CronJob for rke2-machine-config-cleanup: namespaces "fleet-default" not found, requeuing
2024/10/02 09:38:42 [ERROR] error syncing 'local/default-token': handler cluster-registration-token: failed to create fleet-default/rke2-machineconfig-cleanup-sa /v1, Kind=ServiceAccount for rke2-machine-config-cleanup: namespaces "fleet-default" not found, failed to create fleet-default/rke2-machineconfig-cleanup-script /v1, Kind=ConfigMap for rke2-machine-config-cleanup: namespaces "fleet-default" not found, failed to create fleet-default/rke2-machineconfig-cleanup-cronjob batch/v1, Kind=CronJob for rke2-machine-config-cleanup: namespaces "fleet-default" not found, requeuing
W1002 09:40:05.279596      39 warnings.go:70] kubevirt.io/v1 VirtualMachineInstancePresets is now deprecated and will be removed in v2.
2024/10/02 09:40:42 [ERROR] error syncing 'local/default-token': handler cluster-registration-token: failed to create fleet-default/rke2-machineconfig-cleanup-sa /v1, Kind=ServiceAccount for rke2-machine-config-cleanup: namespaces "fleet-default" not found, failed to create fleet-default/rke2-machineconfig-cleanup-script /v1, Kind=ConfigMap for rke2-machine-config-cleanup: namespaces "fleet-default" not found, failed to create fleet-default/rke2-machineconfig-cleanup-cronjob batch/v1, Kind=CronJob for rke2-machine-config-cleanup: namespaces "fleet-default" not found, requeuing

To Reproduce
Steps to reproduce the behavior:

Install v132 single-node cluster; everything is default, no VMs, no StorageClass, no VM-Network...
Upgrade to v140-rc1
Check the Rancher pod log.

Expected behavior

There is no such error log.
Support bundle

Environment

Harvester ISO version:
Underlying Infrastructure (e.g. Baremetal with Dell PowerEdge R630):

Additional context

Related SB file:
supportbundle_20433824-4817-433e-8f50-3f2e4e9c0903_2024-10-02T09-54-39Z.zip

@w13915984028 Is the error in the log eventually gone? and has the upgrade succeeded?

@bk201 The upgrade itself was succesful. When I observed the Rancher POD, the error logs were there, did not check if they were gone after hours/days.

This issue can be fixed by adding namespace fleet-default. However, I'm not sure whether we need to fix this, because it just tries to run a job to cleanup all resources (rke-machine-config.cattle.io CRD). I think we don't use these resources in harvester.
https://github.com/rancher/rancher/blob/8b50f8332866224f855d0d5daa535c98bc9a2f6d/pkg/controllers/provisioningv2/machineconfigcleanup/controller.go#L129-L161

Test OK on v1.4.0-rc3, will close the issue
Environment

Harvester

Version: v1.4.0-rc3
Profile: QEMU/KVM, 1 node (16C/32G/500G)
ui-source: Auto

Steps
Upgrade path

Upgrade from v1.3.2 to v1.4.0-rc3
Wait over 10mins
Make sure there is no failed to create fleet-default/rke2-machineconfig-cleanup-sa error message in rancher pod log

Fresh install

Install v1.4.0-rc3
Wait over 10mins
Make sure there is no failed to create fleet-default/rke2-machineconfig-cleanup-sa error message in rancher pod log


Routes that share parts of the path are not matched

Describe the bug
When creating multiple routes that have some part of the path in common and have the same parent, some routes are not matched
Example:
const indexRoute = new Route({
  getParentRoute: () => rootRoute,
  path: '/',
  component: () =>
Home Page
,
});

const blogRoute = new Route({
  getParentRoute: () => rootRoute,
  path: 'blog',
  component: () =>
Blog Page
,
});

const postsRoute = new Route({
  getParentRoute: () => rootRoute,
  path: 'blog/posts',
  component: () =>
Posts Page
,
});

const authorsPage = new Route({
  getParentRoute: () => rootRoute,
  path: 'blog/posts/authors',
  component: () =>
Authors Page
,
});

const routeTree = rootRoute.addChildren([
  indexRoute,
  blogRoute,
  postsRoute,
  authorsPage,
]);

In this example the path the following matches happen:
:white_check_mark: / matches the indexRoute
:white_check_mark: /blog matches the blogRoute
:x: /blog/posts matches the blogRoute
:x: /blog/posts/authors matches the blogRoute
Your Example Website or App
https://stackblitz.com/edit/tanstack-router-inner-path-slashes-bug?file=src/main.tsx
Steps to Reproduce the Bug or Issue

create a vite app with the react-ts starter template
add @tanstack/react-router v0.0.1-beta.82
create multipe routes on the root level that have some parts of the path in common

See the reproduction stackblitz link.
Expected behavior
Every route should match its path and only the route with the matching path should be displayed (if they all have the rootRoute as parent):
:white_check_mark: / matches the indexRoute
:white_check_mark: /blog matches the blogRoute
:white_check_mark: /blog/posts matches the postsRoute
:white_check_mark: /blog/posts/authors matches the authorsRoute
Screenshots or Videos
https://user-images.githubusercontent.com/96687967/218681088-9f445181-17ff-4933-bbe0-238d2ec242fb.mov
Platform

OS: macOS
Browser: chrome
Version: 0.0.1-beta.82

Additional context
No response

This bug also appears if you chain the routes together with addChildren: https://stackblitz.com/edit/tanstack-router-inner-path-slashes-bug-arspz1?file=src%2Fmain.tsx

This bug also appears if you chain the routes together with addChildren: https://stackblitz.com/edit/tanstack-router-inner-path-slashes-bug-arspz1?file=src%2Fmain.tsx

I have the same issue when the routes with the shared path are added in parallel instead of as children, so I doesn't really seem to matter.

I’ll get this fixed ASAP

This bug makes the library pretty much unusable for a lot of use cases

Again, I realize this is a blocker for many and it's at the top of my list to fix. Hang in there.

Fixed!

Sadly the fix does not seem to work for me with 0.0.1-beta.97, neither for static nor dynamic paths. (It's also completely possible that's user error, I tried to follow the getting started example as close as I could).

Static paths: https://stackblitz.com/edit/tanstack-router-inner-path-slashes-bug-6eaeuj
Dynamic paths: https://stackblitz.com/edit/tanstack-router-inner-path-slashes-bug-naif4i
Minimal: https://stackblitz.com/edit/tanstack-router-inner-path-slashes-bug-mtidnv

I'm afraid you have forgotten to add <Outlet /> to a few of your routes. Here's a fixed example: https://stackblitz.com/edit/tanstack-router-inner-path-slashes-bug-djujqy?file=package.json,src%2Fmain.tsx

I'm afraid you have forgotten to add <Outlet /> to a few of your routes. Here's a fixed example: https://stackblitz.com/edit/tanstack-router-inner-path-slashes-bug-djujqy?file=package.json,src%2Fmain.tsx

🤦♂ Thank you, I was so used to Next's routing that I completely forgot about the nesting behaviour. What I wanted to do boiled down to this:
const indexRoute = new Route({ getParentRoute: () => rootRoute, path: '/', component: Index });
const blogRoute = new Route({ getParentRoute: () => rootRoute, path: 'blog', component: Blog });
const blogPostRoute = new Route({ getParentRoute: () => rootRoute, path: 'blog/$postId', component: BlogPost });

const routeTree = rootRoute.addChildren([
  indexRoute,
  blogRoute,
  blogPostRoute,
]);

Issue seems to pop up in this repo
Repro Steps

Clone, npm install
npm run dev
Go to /games/pong, will render the empty /games route instead.

What it should do in step 3 is render the /games/$game route, and have a Play Now button on the page. Can test routing by clicking on the pong game image on the home page. (Am using window.location for imperative routing as useNavigate throws an exception for some reason).

@mjh316  you are missing the <Outlet> in the games component.
see the docs https://tanstack.com/router/latest/docs/framework/react/guide/outlets

Oh, I had assumed that the parent route was the root route - thank you!


Improve split robustness to handle Kakoune master

Hello,
I propose here a solution to the Issue #21
After the commit 0a66eb9c47ba9a7d3b90286d66a70b5bd7eee15a in kakoune,
the descs variable in the python context contains '\x0' characters
instead of spaces. Using a regex to split everything expect numbers and
punctuation solve this problem.
This change should also be compatible with versions before the given commit.
This PR fixed #21
Best,
Charles

Thanks for investigating and fixing this :+1:


Best way to get previous values?

Suppose I had a long chain of result calls, like the example below. What would be the best way to go about getting the previous values later in the chain?
const doSomething = (): ResultAsync<T, E> => {
  return ResultAsync.fromPromise(...)
    .map((a) => aToB(a))
    .andThen((b) => useB(b))
    .map((c) => cToD(c))
    .andThen((d) => {
      // How can I get a, b, and c here nicely?
      console.log(`Did something with a (${a}), b (${b}), and c (${c}) to make d ${d}.`);
      return d;
    })
}

I was thinking I might be able to do something like the snippet below, but this is problematic because the code is asynchronous. Even if it wasn't, the type inference wouldn't recognize the results as being Ok afaik.
const doSomething = (): ResultAsync<T, E> => {
  const aResult = ResultAsync.fromPromise(...);
  const bResult = aResult.map((a) => aToB(a));
  const cResult = bResult.andThen((b) => useB(b));

  return cResult
    .map((c) => cToD(c))
    .andThen((d) => {
      console.log(`Did something with a (${a}), b (${b}), and c (${c}) to make d ${d}.`);
      return d;
    })
}

Another option would be to combine the new result with the previous in an array, like in the snippet below.
const doSomething = (): ResultAsync<T, E> => {
  return ResultAsync.fromPromise(...)
    .andThen((a) => combine([okAsync(a), aToB(a)]))
    .andThen(([a, b]) => combine([okAsync(a), okAsync(b), useB(b)]))
    .map(([a, b, c]) => combine([okAsync(a), okAsync(b), okAsync(c), cToD(c)]))
    .map(([a, b, c, d]) => {
      console.log(`Did something with a (${a}), b (${b}), and c (${c}) to make d ${d}.`);
      return d;
    })
}

But this creates a lot of boilerplate, especially since the type inference (of ExtractOkTypes maybe?) isn't actually smart enough to work without explicitly specifying the generic type of combine. I left this out of the snippet, but suffice to say that it's quite cumbersome.
So, what would you recommend? This is trivial with normal async/await code, but I would rather not lose the type security from neverthrow.

Linking https://github.com/supermacro/neverthrow/issues/186 to be organized. I'd say check that issue out, but there's not much new in there.
It's late right now where I'm at. So I'll put a bit more thought into this in the coming days.

Here's how I do it (using what's available):
const doSomething = (): ResultAsync<T, E> => {
  return ResultAsync.fromPromise(...)
    .map((a) => ({ b: aToB(a), a }))
    .andThen(({a, b}) => useB(b).map((c) => ({ a, b, c }))
    .map(({ a, b, c }) => ({ a, b, c, d: cToD(c)}))
    .andThen(({a, b, c, d}) => {
      console.log(`Did something with a (${a}), b (${b}), and c (${c}) to make d ${d}.`);
      return d;
    })
}

Closing this issue as it seems to me like @paduc's suggestiong is a good solution


Maybe resurrecting an object should remove the "#" property

Roundtripping objects through resurrect adds a "#" key to them:
function TestObject(){
  this.cats = [];
  this.dogs = [];
}

t = new TestObject();
Object.keys(t);
// => ["cats", "dogs"]

r = new Resurrect();

Object.keys(r.resurrect(r.stringify(t)));
// => ["#", "cats", "dogs"]

I had a function that iterated through object keys in order to do some processing I wanted to do on all of the object's properties. It works with never-resurrected objects but not with those stringified and then resurrect because of this introduced "#" key. So I had to add an extra check to my code that specifically looks for the "#" key and handles it in a special case.
Maybe resurrect should strip out those "#" properties when resurrecting objects? There's probably an argument to be made that I shouldn't be writing code that does stuff like that iteration through properties, but I'm not sure resurrect should enforce that idea.

Or maybe I'm fundamentally misunderstanding how this library works and somehow the objects permanently use that property to look up their functions instead of actually having their original type after being resurrected?

If that extra property is causing problems, just configure Resurrect for
cleanup.
new Resurrect({cleanup: true})

This will remove Resurrect's extra properties using the delete keyword.
The reason this might not be desirable (and why it's left off by
default) is because it wreaks havoc on the JavaScript engine's optimizer
(hidden classes, etc.). Using delete communicates "this is a hash table,
not a struct." If you're iterating over properties then you're probably
using it like a hash table anyway -- or you're writing another
reflective library like ResurrectJS.
Someday when ES6 is practical without compiling to ES5 (still some years
away), I'll rewrite ResurrectJS to take advantage of it so that this
issue becomes irrelevant: private symbol properties, sets, hash tables,
etc.

@skeeto That totally makes sense. Thanks for explaining it. In my case most of my objects are actually structs with behavior, this just happened to be a case where some data doesn't have any behavior associated with it so ended up as basically a hash. But I think overall I'm much better off without cleanup.
Anyway, thanks for this great library. I'm using it in a game I'm making about being a Showrunner on a TV show. I wrote up a (kind of long) post about implementing game saving with resurrect.js (and trying to design against save scumming) here on my dev blog: http://showrunnergame.tumblr.com/post/135697213479/implementing-game-saving-and-discouraging-save


pep517 has been replaced by pyproject-hooks

Just an FYI:

Note: The pep517 project has been replaced by this project (low level) and the build project (high level).

-- https://github.com/pypa/pyproject-hooks#readme

Thanks, the pep517 is required by pip, which is an indirect dependency of pigar.
pip has vendored the code of pep517 to avoid cyclic dependency, and pigar is vendoring pip to avoid conflicts and incompatibility changes. Maybe pigar should vendor all the dependencies..

I didn't see a new release of pip with the commit included, and I think there is no significant problem if we don't replace pep517 right now, so let's wait.


Defining a CustomType for KeyReference in CompositeId()

Hey Guys,
I opened this topic within stackoverflow already, but until now there is no answer. Maybe you can have a look:
http://stackoverflow.com/questions/6827154/mapping-compositeid-keyreference-on-interface
Thanks.

You're right, there is currently no support. To make matters worse, Fluent NHibernate does set the class attribute in the mapping, causing NHibernate to ignore entity-name. This causes mapping to any interface to fail.
My current workaround was to export the mapping to XML (using ExportTo), then using the XML mappings from the classes I couldn't properly map in code.
In short:

Fluent NHibernate should not set the class attribute unless specifically asked by the user. This is not something that could be done in a minor release as it can break working code.
Allow specifying the class of a KeyReference (key-many-to-one in XML).


Update crypto_options.cc

removed redundant and never called CryptoOptions function

For type of change, we recommend submitting it to the upstream repository. Thank you.


Question: how to speed compiling when using go build -mod=vendor

What version of Go are you using (go version)?

$ go version
[cloud-user@preserve-olm-env ~]$ go version
go version go1.16.5 linux/amd64

Does this issue reproduce with the latest release?

I want to use the dependency packages with specific versions, and don't want to depend on the Network. So, we use go build -mod=vendor  for compiling. To save building time, we want to cache the binary so that it only rebuilds when the source is newer.
What did you expect to see?
When using go build for building, it saves the mod cache ( *.a files) to the $GOPATH/pkg/mod. We can reuse this cache and rebuilding the binary faster.
But, when using go build -mod=vendor, it works/saves the cache( *.a files) to a random temporary(such as /tmp/go-build1307922253/) WORK folder, and remove it once compiling done. So, that means, it will never reuse the mod cache when running go build -mod=vendor for compiling. Is it right?
So, how to utilize the mod cache to speed the compiling when using the go build -mod=vendor? Much appreciate!
What did you see instead?

Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.
For questions please refer to https://github.com/golang/go/wiki/Questions

Thanks for your info, ask it in Slack: https://gophers.slack.com/archives/C029RQSEE/p1624784324040700

Asked it again here: https://gophers.slack.com/archives/C9BMAAFFB/p1624841383206400

Reopen it, since I thought this is a prroblem we should fix, at least a feature request.

/reopen

I don't think you are correctly describing how the system works.  Please use a forum, as suggested above, to see how the system works, and then file an issue describing specific changes to make.
In particular the module cache, the build cache, and the temporary work directory are all different things.


Fix issue #86

Fixes issue #86 - app require parameter to require the exec creating the application pool.

we should do the version bumping in a separate commit / pr

ok, apologies for that. How should I proceed then? Revert version to previous values & submit new pr?

@drmarconi yes.

Thanks, changes made.

@drmarconi would you mind doing a squash?

Done :)

Merging, because this failure isn't due to you.

@jyaworski thanks, any change the Puppet Forge could be updated as well please? Just so I can pull down with r10k etc.

@drmarconi we do forge releases somewhat ad-hoc. I believe we're going to cut a forge release just before we merge the giant PR, but until then I would recommend referencing this commit in your Puppetfile.


feat: Adding classes for raw geometric shapes

Description
Added classes for the following shapes:

[Circle]
[LineSegment]
[Rectangle]
[RoundedRectangle]
[Polygon]

Checklist

[x] The title of my PR starts with a Conventional Commit prefix (fix:, feat:, docs: etc).
[x] I have read the Contributor Guide and followed the process outlined for submitting PRs.
[ ] I have updated/added tests for ALL new/updated/fixed functionality.
[ ] I have updated/added relevant documentation in docs and added dartdoc comments with ///.
[ ] I have updated/added relevant examples in examples.

Breaking Change

[-] Yes, this is a breaking change.
[x] No, this is not a breaking change.

Related Issues
Closes #1521

The main idea is that a geometric Shape is an object that could be used in a variety of applications:

hitboxes for collision detection;
gesture hitboxes ("tapboxes") for tap detection;
clip mask for a ClipComponent (cf #1274);
custom-shaped viewport;
world bound for camera;
ShapeComponents, i.e. components made of simple geometric shapes;
etc.

Regarding Hitbox components, the biggest challenge is figuring out the intersection API. The fact that Rectangle is not rotatable, however, is not a problem -- we can simply make it that Hitbox.rectangle(angle=...) would produce a hitbox whose internal shape is a Polygon instead of a Rectangle. We would have to do for Circles too: any non-uniform scaling turns it into an ellipse, and rotation/shearing would either require a special RotatedEllipse shape, or a more generic Polycurve.

When it comes to Hitboxes, I think the following design considerations apply:

Hitboxes are based on shapes, in the sense that a Hitbox requires a Shape to support its functionality.
In the majority of cases, a hitbox is static within its component.
When a component moves around the world, the projection of that component's shape onto the world coordinate plane is moving.
More often than not, the projection is a simple translation. That is, simple movement of a component is more common than rotations, scalings, and skews.
For all shapes, a translation is a very simple operation that can be done in-place.
More generic transforms are trickier, for some shapes they even result in a different shape being produced. For example, a circle may turn into a rotated ellipse, a rectangle into a parallelogram. Clearly, such transforms cannot be done in-place.

Given these considerations, I think we should aim for the following architecture for the collision system:

Collision system is attached to the world;
For every hitbox mounted to that world, it is possible to construct the Transform2D matrix that projects the hitbox onto the world plane;
Collision system maintains the list of projections from every hitbox shape onto the world plane. Here "maintains" means it keeps track of which components have moved during each tick, and either moves the corresponding projection (if it was a simple translation), or re-projects the hitbox if it was a more complicated movement.
The collision detection algorithm runs on the set of projected shapes.

In view of this design, the Shape class has to support the following operations:

projection(Transform2D);
move(Vector2) -- in-place translation;
intersection(Shape).

The intersection functionality deserves more discussion. Clearly, an intersection between two shapes is again a shape. However, computing that shape may not be always practical (for example, a circle intersecting a circle is a lune). On the other hand, often we don't want to know the exact shape of an intersection. For example, just knowing that the shapes did intersect might be sufficient. In other applications you might want just a single representative point of an intersection, or projection of that point onto the shape's boundary. In the current implementation we return the set of extreme points of the intersection shape.

Given these considerations, I think we should aim for the following architecture for the collision system:
* Collision system is attached to the world;

It kind of is already, currently the world is the FlameGame, since the world concept is still in experimental.

* For every hitbox mounted to that world, it is possible to construct the `Transform2D` matrix that projects the hitbox onto the world plane;

Agree that this would be a much better solution than the current one that takes the absolute* fields from the parent, since that doesn't work for all cases as discussed previously.

* Collision system maintains the list of projections from every hitbox shape onto the world plane. Here "maintains" means it keeps track of which components have moved during each tick, and either moves the corresponding projection (if it was a simple translation), or re-projects the hitbox if it was a more complicated movement.

Why couldn't the hitbox itself take care of that, like it does today?

* The collision detection algorithm runs on the set of projected shapes.

When using projection, instead of mutability, we'd create one new temporary object per hitbox per tick (possibly only the transformed ones, but could still be very many).

In the current implementation we return the set of extreme points of the intersection shape.

I think that should be enough, anything more advanced will lead to heavier computation without much practical gain (might even make the API more complex).

Collision system is attached to the world;

It kind of is already, currently the world is the FlameGame, since the world concept is still in experimental.

I use the "world" here in a loose sense: a FlameGame is a world, a World is a world, any other component can be the world too, it just needs to declare itself an owner of a CollisionSystem (which itself is either a mixin or a component). The only requirement for this "world" is that component tree mounted to it would have a way to propagate the transform matrices. So that if the "world" contains component A which contains B, then there should be a way for a hitbox attached to B to find its projection matrix onto the root world. Basically, the only requirement is that A and B implement the extended Projector interface.

Why couldn't the hitbox itself take care of that, like it does today?

The Shape class knows how to project itself, using the provided Transform2D object. The Hitbox then can be responsible for finding that transform matrix. As mentioned above, this can be done by traversing up the tree until you reach the CollisionSystem root. However, it's possible that traversing down the tree will be more efficient.
For example, suppose you have tree A -> B -> [C, D, E]. Traversing down from A, you compute transform matrix AB once, and pass it to each C, D, and E. Traversing up from C, D, E, you need to recompute the entire transform ABC, ABD, ABE.
Also, it would be good if we only recomputed those transforms that actually need recomputing. So, having some kind of central authority to keep track of which component moved would be beneficial here.

When using projection, instead of mutability, we'd create one new temporary object per hitbox per tick

We could have an API where project() takes an optional target parameter, and will attempt to modify that target in-place when it is given, and assuming the target has a suitable type. So, something like this:
Shape project(Transform2D transform, [Shape? target]);

In the current implementation we return the set of extreme points of the intersection shape.

I think that should be enough, anything more advanced will lead to heavier computation without much practical gain (might even make the API more complex).

I'm not suggesting that we perform more advanced calculations here, if anything, I'd rather we did less.
But we could always return a special Intersection object that knows how to perform these advanced calculations if the user needs them. Similarly, the extreme points are also non-trivial to compute, so they can be calculated by the Intersection object by user request.
The question only what is the minimum amount of calculation that we need to perform in order to know that two shapes did in fact intersect. AFAIU, there are algorithms that can tell that without computing the intersection points.
So what I'm suggesting here is that:

Shape's intersection() method returned an Intersection? object;
the Intersection object is able to calculate extremes() on request;
the collision callback system for now returns Intersection.extremes(), but we slowly transition towards returning the Intersection object itself.

We could have an API where project() takes an optional target parameter, and will attempt to modify that target in-place when it is given, and assuming the target has a suitable type. So, something like this:
Shape project(Transform2D transform, [Shape? target]);

Sounds good.

I'm not suggesting that we perform more advanced calculations here, if anything, I'd rather we did less.
But we could always return a special Intersection object that knows how to perform these advanced calculations if the user needs them. Similarly, the extreme points are also non-trivial to compute, so they can be calculated by the Intersection object by user request.

Gotcha, that makes sense.

* the collision callback system for now returns `Intersection.extremes()`, but we slowly transition towards returning the `Intersection` object itself.

As long as that isn't too near in the future so that we don't have a breaking change again on this API already.


Doesn't work with ruby2.4 on linux

Trying to install rainbow with rubocop and ruby2.4. Here is what i get in the end:
Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

    can't modify frozen String

Gem files will remain installed in
/home/ubuntu/inboundsms/vendor/bundle/ruby/2.4.0/gems/rainbow-2.2.1 for
inspection.
Results logged to
/home/ubuntu/inboundsms/vendor/bundle/ruby/2.4.0/extensions/x86_64-linux/2.4.0-static/rainbow-2.2.1/gem_make.out

An error occurred while installing rainbow (2.2.1), and Bundler cannot
continue.
Make sure that `gem install rainbow -v '2.2.1'` succeeds before bundling.

After some digging, this is not related to linux and this gem.
I changed to stable version of bundler and everything works!

@skatkov What version of bundler did you use, and what version did you update to? Getting the same error.

@Nowaker
current version that works:
Bundler version 1.13.7
I'm not sure which version i've used before, but i've used pre-release version with
gem install bundler --pre
probably bundler-1.14.3


underscore as throwaway var

_ is used to denote an unused var, ideally doesn't even get stack allocated
_ = 100       // is valid
x = _ + 100   // invalid

Suneido uses the prefix _ for dynamic variables it might cause confusion when someone names variable _temp thinking it's unused or a throwaway.


Does this method still work?

I can't find any post requests for thread_info.php

I can still see POST request being issued to _https://www.facebook.com/ajax/mercury/thread_info.php?dpr=1_
I am not sure what that dpr is used for, I will have to check it out and try it further, but please close the issue if you managed to make everything work by simply getting the necessary parameters from this POST request.

Checked. Method still works.


Access pointers to arrays

Wondering what is the best way of dealing with a c_ptr that points to an array. in general we don't know the size of the array.
I'm looking at an example in the string_data here: https://github.com/freevryheid/duckdb/blob/appender/test/test_data_chunk.f90#L420
where the cpp code casts the the data as a pointer to an array of strings: https://github.com/duckdb/duckdb/blob/master/test/api/capi/test_capi_data_chunk.cpp#L235-L267
while I have been able to only get the data as a string but not as an array of strings.

I've looked further into this and realised that there is a new data type a duckdb_string_t additional to duckdb_string which has been added in 0.8.0. I'm making a separate issue for updating the dev version of duckdb to the latest release (0.8.1)


the bounding box isn't sufficiently large to cover poses!

Dear author! When I try to debug such problem,it seems that the problem comes from the pytorch dataloader! How to solve such problem?

Actually, this printed message about the bounding box doesn't suggest the occurrence of errors. It's simply a warning that the tight bounding box isn't large enough to cover poses in a few cases. You can increase the size of the bounding box. However, the growing size of voxels will introduce larger quantization errors. It's a trade-off between dealing with some corner cases and maintaining accuracy.

All right, thanks for your answer, my machine seems to operate slowly, maybe my machine's congures is too old（RTX2060 6G and i7 8700）.

All right, thanks for your answer sincerely, my machine seems to operate slowly, maybe my machine is too old（RTX2060 6G and i7 8700）.

Hello. Can this problem be solved by upgrading the hardware device?


Sunrise time difference

version: 1.0.0
I compare a time in sunrise-sunset API with your package.
In sunset in the same time in my location (39.4699014, -0.3759513) and day 2020-03-03.
But in sunrise, have a litle difference of 56 seconds . This is a screenshots and values
API - Sunrise 07:29:48:

Package - Sunrise 07:30:44:

OBS: This is a minor issue and I'll use this package because is awesome :)

What zenith are you using?

I update the issue @renancaraujo

WE probably have an issue due to math approximations (and the algorithm itself). I don't think we have to expect absolute precision here.


Enrich the logs streamed in tests with useful information.

Level is very useful to spot errors at a glance.
Time is very helpful to be able to order the statements and notice time gaps.
Key helps identifying which ressource is being reconciled (could be a child resource).

/assign @mattmoor
Let's discuss here if this is what we want/need for now. Just printing time without ordering things is not ideal, but maybe a good first step?

/test pull-knative-pkg-unit-tests

/test pull-knative-pkg-unit-tests

/test pull-knative-pkg-unit-tests

/retest

/test pull-knative-pkg-unit-tests
/lgtm

/test pull-knative-pkg-unit-tests

/test pull-knative-pkg-unit-tests

/test pull-knative-pkg-unit-tests


Don't add commit number indicator to version when building a tag

This allows building tags that are on a branch other than master.

@elibarzilay,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot


Update developer's guide

The developer's guide must be updated with information on the develop branch:
. pull requests
. item branches
. other upstream repositories (?)
To close this task the develop branch must become the main project branch. This is subject to approval by the PSC.
The PyWPS development method is inspired on this branching model:
http://nvie.com/posts/a-successful-git-branching-model/

Works for me. Let's start the proposed approach.
One note: do we than need to distinguish between odd and even numbers in our versions? With proposed approach, we can nicely continue with 4.1 as next stable release number (?)

1 for me as PSC member

The develop branch must be referred in the following files:
https://github.com/geopython/pywps/blob/master/CONTRIBUTING.rst
https://github.com/geopython/pywps/blob/master/RELEASE-howto.md
https://github.com/geopython/pywps/blob/master/docs/development.rst

@jachym I'd prefer even/odd strategy as this clearly indicates a stable/unstable version.


Liceul Teoretic "Octavian Goga" Huedin

The domain ogoga.ro it's used only by this high school.
Also please provide us with:
https://ogoga.ro/
Piața Victoriei nr. 11, Huedin 405400, România
Proof: attachment
Document.pdf


test_api_gpu FAIL every time. Build seems alright (compiles and runs)

The whole build seems to be working for me, but the simple test results for gpu output FAIL at every time. No clue on why this happens (I guess it shouldn't?)

System setup:
Ubuntu LTS 16.04
NVidia drivers, 384.81
CUDA Toolkit, v9.0
Tesla V100-SXM2 (Compute Capability 7.0)

Output of every test:
------ Key Generation ------
------ Test Encryption/Decryption ------
Number of tests:        2560
PASS
------ Initilizating Data on GPU(s) ------
------ Test NAND Gate ------
Number of tests:        2560
0.178565 ms / gate
FAIL
------ Cleaning Data on GPU(s) ------

I just noticed the same issue last night. My GPU has only 30 SMs and gives an roughly 1 failure every 2000~3000 tests. There might be a read-write race caused by concurrently executed kernels or memory accesses somewhere in the code. I am working on this.
Meanwhile, do you have ECC switched on? If it wasn't, could you please switch it on and run the test again? I would like to exclude the affect of ECC. I do not have access to such a GPU. Much appreciated.

ECC seems to be switched on. When I run nvidia-smi -e 1 I get the message "ECC support is already Enabled for GPU ..."

@ibarrond
Could you please verify this fix? It works on my device.

I recompiled the library and the tests, rerun test_api_gpu and still obtained the same output:
------ Key Generation ------
------ Test Encryption/Decryption ------
Number of tests:        2560
PASS
------ Initilizating Data on GPU(s) ------
------ Test NAND Gate ------
Number of tests:        2560
0.172046 ms / gate
FAIL
------ Cleaning Data on GPU(s) ------

Hi @ibarrond, I launched 7000+ gates per test and tested multiple times. They all passed. I now added a counter for the failures. Could you please download the new commit and send me the output? Make sure that you executed make clean before make. Thanks a ton.

Perhaps that second synchronize in the end of NTT/NTTInv functions was necessary, after all. Whoever still sees the fails, could you check?

@ibarrond I think that 1/200 error rate may be caused by hidden memory copies before and after each kernel. I now have some changes at this branch. It runs the same number of tests but executes 8 sequential Nand gates in each test. And now the code relies on memory copies between host and device rather that previously unified memory. Please again test it on your mighty V100. I wish I had a capability 7.0 device so that I don't have to bother you for testing. Much appreciated.

@fjarri I will try that later. But a race of shared memory accesses should be detected on my GPU as well and with a error rate much lower than 9/2560. I suspect that there is some issue with unified memory and streams on devices with compute capability 7.0+. If my current fix still fails, I will thoroughly check the data path inside kernels. Thanks again.

I tried again with the changes from branch fix-old-gpu, but I stull get errors. Just to be sure, I supressed other outputs and run the tests 30 times. All of them failed:
FAIL:   11/2560 FAIL:   8/2560 FAIL:   15/2560 FAIL:   7/2560 FAIL:   4/2560 FAIL:   10/2560 FAIL:   8/2560 FAIL:   16/2560 FAIL:   15/2560 FAIL:   17/2560 FAIL:   2/2560 FAIL:   8/2560 FAIL:   14/2560 FAIL:   4/2560 FAIL:   7/2560 FAIL:   7/2560 FAIL:   6/2560 FAIL:   7/2560 FAIL:   6/2560 FAIL:   2/2560 FAIL:   11/2560 FAIL:   2/2560 FAIL:   11/2560 FAIL:   11/2560 FAIL:   5/2560 FAIL:   12/2560 FAIL:   1/2560 FAIL:   9/2560 FAIL:   5/2560 FAIL:   12/2560

I have just examined potential race-conditions in CUDA device code again. I added another synchronization. Please again recompile and test the same branch. If this still fails, I believe the error is then caused by the synchronization between host and device. Thanks a lot.

With the latest changes applied I get an even worse error rate: FAIL:   519/20480 FAIL:   479/20480 FAIL:   484/20480 FAIL:   494/20480 FAIL:   428/20480 FAIL:   502/20480 FAIL:   486/20480 FAIL:   534/20480 FAIL:   470/20480 FAIL:   557/20480 FAIL:   517/20480 FAIL:   498/20480 FAIL:   527/20480 FAIL:   445/20480 FAIL:   447/20480 FAIL:   500/20480 FAIL:   475/20480 FAIL:   648/20480 FAIL:   493/20480 FAIL:   555/20480 FAIL:   521/20480 FAIL:   541/20480 FAIL:   566/20480 FAIL:   494/20480 FAIL:   498/20480 FAIL:   454/20480 FAIL:   392/20480 FAIL:   493/20480 FAIL:   432/20480 FAIL:   573/20480

@ibarrond Sorry for this delayed reply. I was taken away from this project for a while. We have tested on a V100 recently and couldn't see the same error here. Do you still see this now?

Not anymore! Closing the issue.

I now have some changes at this branch.

@WeiDaiWD I have some questions about the great work you've done here. I'm confused about the intended behavior of that branch, and in particular the lines:
https://github.com/vernamlab/cuFHE/blob/2f9b0b1661ec14cb8d0e5f7078e7dcbf4b6f15cd/cufhe/test/test_api_gpu.cu#L109-L113
Since the Synchronize() call resides outside of the outer loop, how exactly do we still guarantee the expected semantics, namely that the kNumLevels Nand gates be applied in succession?
what is the definition of Synchronize(), anyway? In my own code, I am getting certain nondeterministic errors which are resolved by adding certain Synchronize() calls even between GPU operations which do not access the same memory. I'm in the process of working up a MWE.


IOS13 version uses shareAPI to have an error

IOS13 version uses shareAPI to have an error.
The sharing dialog pops up and selects Finish, but the sharing dialog does not close automatically. Click it again to report the error.
React Native version:
System:
OS: Windows 10
Binaries:
Node: 10.16.0 - C:\Program Files\nodejs\node.EXE
npm: 6.9.0 - C:\Program Files\nodejs\npm.CMD
npmPackages:
react: 16.8.6 => 16.8.6
react-native: 0.60.4 => 0.60.4

Upgrade to 0.61, solve the problem


[improvement]Randomly get a new BE address when writing one batch at a time

Proposed changes
reduce the Coordinator BE load pressure

The BE address remains the same until the write fails. Improve cluster load balancing.
The Coordinator BE receiving data and distributing data to other data nodes. It receives more network traffic than other nodes.

Problem Summary:
Describe the overview of changes.

The BE nodes collection is cached and refresh periodically.
Randomly get a new BE address from cache when writing one batch at a time.

Checklist(Required)

Does it affect the original behavior: (Yes/No/I Don't know)
Has unit tests been added: (Yes/No/No Need)
Has document been added or modified: (Yes/No/No Need)
Does it need to update dependencies: (Yes/No)
Are there any changes that cannot be rolled back: (Yes/No)

Further comments

@hf200012 would you mind take a look?


NM/device: Fix AttributeError

DEVICE_DISCONNECTED is a attribute of ActiveConnectionStateReason (not
ActiveConnectionState).
Signed-off-by: Till Maas<EMAIL_ADDRESS>

Coverage decreased (-0.04%) to 69.245% when pulling 4e37fdb1a29c9e420b3ec37b027116f46c8361af on tyll:attributeerror into 39784d2e4593fc685f9d7752d3a92cc2aeeb307f on nmstate:master.

ci test please


Remove Deprecation Statement for aws/linked-accounts

Clarifies that Linked Accounts onboarding is still useful and aws-centralized-monitoring is not a full replacement for it.

Works for me; can we further clarify what a full featured AWS deployment looks like in terms of usage of these modules? e.g. (not sure if correct)

Integrate payer-account once, with your payer account
Integrate linked-account N times, for all linked accounts where (condition / thing enabled by doing so)
Integrate aws-centralized-monitoring once, (with what parameters?)

cc also @GCelichowski who wrote aws-centralized-monitoring

Makes sense to me. Sorry for any confusion!


Use explicit jersey package versions instead of dependency management

Current coverage is 57.41% (diff: 100%)

No coverage report found for master at d0b7cd2.

Powered by Codecov. Last update d0b7cd2...89cc0d1


Remove a couple unused import

Fixes lint

Codecov Report

Merging #2777 into canary will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           canary    #2777      +/-   ##
==========================================
- Coverage   13.87%   13.86%   -0.02%
==========================================
  Files         264      264
  Lines       10581    10569      -12
  Branches     1367     1366       -1
==========================================
- Hits         1468     1465       -3
+ Misses       8964     8955       -9
  Partials      149      149

Impacted Files
Coverage Δ

src/util/handle-error.ts
26.92% <ø> (ø)
:arrow_up:

src/util/dev/builder-cache.ts
74.86% <0%> (+1.5%)
:arrow_up:

src/util/dev/router.ts
83.33% <0%> (+4.76%)
:arrow_up:

Continue to review full report at Codecov.

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


Refactor web::latest_version, move logic into CrateDetails

I noticed web/mod.rs contained a really complicated latest_version function: https://github.com/rust-lang/docs.rs/blob/master/src/web/mod.rs#L316
The bulk of the work was spent in converting the version strings into semver::Version, to sort the array. Something that is already done in CrateDetails...
The original latest_version would return:

None if req_version was an invalid function or if req_version is the latest version
Some(version) if this crate has a more recent version

I have split what this function does in two functions:

CrateDetails::is_latest_version --> check if this is the most recent release
CrateDetails::latest_version --> grab the most recent release

I like how it is much easier to reason about now 😊
These changes should be easy to follow commit-by-commit. The real changes happen in the second commit: 309ea7a

@jyn514 I have simplified the code a bit, avoiding the need to call latest_version() twice. Can you take a look again? :)

Overall I like this :) It will make https://github.com/rust-lang/docs.rs/issues/396, https://github.com/rust-lang/docs.rs/issues/312, https://github.com/rust-lang/docs.rs/issues/223, and https://github.com/rust-lang/docs.rs/issues/395 easier to fix now that everything's in one place.
#395 would be a good test case for this actually, let me run that locally.

395 was a separate issue in match_version, it won't be affected.

Overall I like this :) It will make #396, #312, #223, and #395 easier to fix now that everything's in one place.
#395 would be a good test case for this actually, let me run that locally.

About those issues mentioning yanked crates, I have another small-ish refactor coming up which would add a yanked bool to Release. This should make it fairly easy to improve latest_version() and ignore yanked crates.


No error if address already in use

Reproduce: listen on port 8000 with something, then start Laika on port 8000.
Expected: Laika fails to start and says something like address is already in use.
Actual: Laika claims to be running on port 8000 as usual but in fact is not running because it couldn't allocate the port.

This is a perfect candidate to tag it Hacktoberfest
[https://hacktoberfest.digitalocean.com/](Here you can find more info)

@eggman64 @dmigo  I would like to work on this issue, Can I pick this up?


Add GitVersion to Cake Build Process

This still needs some work, but the basics are there.
Thoughts?

@gep13 What I understand of it, it looks good to me code wise, but left a couple of questions just to make sure I understood it correctly :smile:
GitVersion is not working on Mono yet?

@patriksvensson said...
GitVersion is not working on Mono yet?

Yes, this is correct.  I should probably add a WithCriteria to the GitVersion Tasks.
There are plans to make it xplat, but that won't be until the next major release, at the earliest.

@patriksvensson this one is now ready for final review.  I kicked the Travis build, which seemed to have stalled.

Merged :+1:

Relates to #567


#remove unused searching for doc_id

Execuse me, I found the code snipped is unuseful and it will cause problem, child id type is diffirent from parent node id.
we using fields which is child value to search parent table, the logic is wrong.
 for doc_id in self.es._search(
                        self.index,
                        node.parent.table,
                        fields,
                    ):

fix https://github.com/toluaina/pgsync/issues/352

Execuse me, I found the code snipped is unuseful and it will cause problem, child id type is diffirent from parent node id. we using fields which is child value to search parent table, the logic is wrong.
 for doc_id in self.es._search(
                        self.index,
                        node.parent.table,
                        fields,
                    ):

fix #352

I think removing this will lead to other problems. I have somewhat addressed this in this commit . So this should be fixed in the main branch

Can you please confirm if this is resolved now please. I strongly feel this has been fixed in the master. Apologies for the delay


Does it support causal mask?

The effect is the same as the argument "use_casual_mask" in keras official layer class Attention.
https://www.tensorflow.org/api_docs/python/tf/keras/layers/Attention
Thanks for your useful module and expect your reply.

I don't think there is at the moment.

got it, thanks!