Blazor: ArgumentOutOfRangeException when opening big razor file

This issue has been moved from a ticket on Developer Community.

[regression] [worked-in:16.3.0 Preview 1]
Application: devenv.exe
Framework version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Information: System.ArgumentOutOfRangeException
at Microsoft.AspNetCore.Razor.Language.Intermediate.IntermediateNodeCollection.get_Item(Int32)
at Microsoft.AspNetCore.Razor.Language.Components.ComponentReferenceCaptureLoweringPass.ExecuteCore(Microsoft.AspNetCore.Razor.Language.RazorCodeDocument, Microsoft.AspNetCore.Razor.Language.Intermediate.DocumentIntermediateNode)
at Microsoft.AspNetCore.Razor.Language.IntermediateNodePassBase.Execute(Microsoft.AspNetCore.Razor.Language.RazorCodeDocument, Microsoft.AspNetCore.Razor.Language.Intermediate.DocumentIntermediateNode)
at Microsoft.AspNetCore.Razor.Language.DefaultRazorOptimizationPhase.ExecuteCore(Microsoft.AspNetCore.Razor.Language.RazorCodeDocument)
at Microsoft.AspNetCore.Razor.Language.RazorEnginePhaseBase.Execute(Microsoft.AspNetCore.Razor.Language.RazorCodeDocument)
at Microsoft.AspNetCore.Razor.Language.DefaultRazorEngine.Process(Microsoft.AspNetCore.Razor.Language.RazorCodeDocument)
at Microsoft.AspNetCore.Razor.Language.DefaultRazorProjectEngine.ProcessCore(Microsoft.AspNetCore.Razor.Language.RazorCodeDocument)
at Microsoft.AspNetCore.Razor.Language.RazorProjectEngine.ProcessDesignTime(Microsoft.AspNetCore.Razor.Language.RazorProjectItem)
at Microsoft.VisualStudio.Editor.Razor.BackgroundParser+BackgroundThread.WorkerLoop()
at System.Threading.ThreadHelper.ThreadStart_Context(System.Object)
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
at System.Threading.ThreadHelper.ThreadStart()

Original Comments
Sven Glöckner on 8/14/2019, 01:48 AM:
Visual Studio is crashing immediately after opening the file.
Visual Studio Feedback System on 8/14/2019, 03:23 AM:
We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.
Visual Studio Feedback System on 8/15/2019, 11:06 PM:
Thank you for sharing your feedback! Our teams prioritize action on product issues with broad customer impact. See details at: https://docs.microsoft.com/en-us/visualstudio/ide/report-a-problem?view=vs-2017#faq. In case you need answers to common questions or need assisted support, be sure to use https://visualstudio.microsoft.com/vs/support/. We’ll keep you posted on any updates to this feedback.

Original Solutions
(no solutions)

Thanks for contacting us.
@rynowak do we have enough information from the stack trace here, or do we need a repro for this?

There was a bug like this in preview 8 that we fixed. So I expect this was already fixed.


controller-manager: Configurable image repos

Add config option for kube-rbac-proxy image instead of a hard
coded name, so that the controller-manager can be depoloyed
from a 3rd party registry (e.g. air gapped cluster, caching proxy).
Add image.repo config options to allow specifying a different
repository without changing name or version, for convenience.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Can you run this from the repo root dir?
helm unittest --helm3 --output-type JUnit helm-charts/verticadb-operator

I just noticed we no longer run this in our CI.  I'll fix this separately, but it should be clean for you.

$ helm unittest --helm3 --output-type JUnit helm-charts/verticadb-operator

### Chart [ verticadb-operator ] helm-charts/verticadb-operator

 PASS  CA bundle tests  helm-charts/verticadb-operator/tests/caBundle_test.yaml
 PASS  test image:tag creation  helm-charts/verticadb-operator/tests/image-name-and-tag_test.yaml
 PASS  test namespace selector in the webhook configuration     helm-charts/verticadb-operator/tests/namespace-selector_test.yaml
 PASS  test that resources can be specified for the operator    helm-charts/verticadb-operator/tests/resources_test.yaml
 PASS  skip-cert-manager-CRs    helm-charts/verticadb-operator/tests/skip-cert-manager_test.yaml

Charts:      1 passed, 1 total
Test Suites: 5 passed, 5 total
Tests:       6 passed, 6 total
Snapshot:    0 passed, 0 total
Time:        10.113183ms


Allow project owners to set status markers ("deprecated", "archived", etc) to their PyPI projects

What's the problem this feature will solve?

Currently, PyPI does not have a standard way of indicating that a project has been deprecated, archived, etc by the maintainers.
This information is (sometimes) included in the project's description, but there's no standard way of setting (or getting) it, other than manually checking.
If owners can mark a project as deprecated, archived, etc. on PyPI and this information is exposed through the web UI and the index APIs, downstream consumers can monitor this information to make better decisions about their supply chain.
Describe the solution you'd like
Recently warehouse added support for marking a project as quarantined: https://github.com/pypi/warehouse/pull/16179.
This involved adding a new field to the Project model:
class LifecycleStatus(enum.StrEnum):
    QuarantineEnter = "quarantine-enter"
    QuarantineExit = "quarantine-exit"

We could model the new project statuses as lifecycle statuses. For example:
class LifecycleStatus(enum.StrEnum):
    QuarantineEnter = "quarantine-enter"
    QuarantineExit = "quarantine-exit"
    Deprecated = "deprecated"
    Archived = "archived"
    Finished = "finished"

The project owner should only be able to set the new statuses (not the quarantine related ones), and only if the project is not quarantined. Something like:
stateDiagram-v2
    direction LR
    [*] --> UserStates
    state UserStates {
        None
        Archived
        Deprecated
        Finished
    }
    UserStates --> UserStates
    UserStates --> QuarantineEnter :
    QuarantineEnter --> QuarantineExit
    QuarantineExit --> QuarantineEnter
    QuarantineExit --> UserStates

The UI for setting the status can be a simple drop down:

And the UI for the project's main page can be similar to the quarantined one:

Additional context

There have been previous requests for adding an "archived" status: https://github.com/pypi/warehouse/issues/4021, https://github.com/pypi/warehouse/pull/15950. Also for unsupported/deprecated: https://github.com/pypi/warehouse/issues/345.
In this issue I suggested 3 new statuses, here's a more complete description of each:

“Finished”: the project is “complete” and not receiving active feature development;
“Archived”: the project is inactive and not receiving further updates of any kind;
“Deprecated”: the project has been obsoleted or replaced in functionality by another project.

Initially, we can make the project status only affect the web UI and the metadata included in the index APIs. We could later add restrictions to the project actions depending on the status (e.g.: disallowing uploads for deprecated projects), but this is optional and will probably need more discussion.
The changes required in the backend for this feature are pretty simple since the LifecycleStatus field already exists. Most of the work should be UI-related.

cc @miketheman @woodruffw

Here's an even older issue for context: https://github.com/pypi/warehouse/issues/345
There's also conversations like https://discuss.python.org/t/reporting-outdated-unmaintained-projects-on-pypi/2264 and https://discuss.python.org/t/marking-packages-on-pypi-as-unmaintained-or-obsolete/37742
You may wish to explore those topics and links for historical context - I'll admit I'm not fresh on these myself, only the ones I was able to find with a quick search that appeared relevant.
Adding LifecycleStatus was intended to be extended exactly as you're describing - so yay!
I think there's a lot ideas out there on what these mean, how they are used, and what behaviors they would perform - especially when it comes to client-side warnings/errors, so this is probably a bit of a larger conversation around what these lifecycle statuses mean to the wider ecosystem. See https://peps.python.org/pep-0592/ for an example of how yank was adopted into the ecosystem.
And naming things is hard - so I'd encourage some deeper thought into what these names mean, and whether or not they convey the appropriate meaning.
See https://github.com/pypa/trove-classifiers/blob/4e5d35f7a09b57f0a2b65a3dd471c001e5bc7478/src/trove_classifiers/init.py#L9-L11 for trove classifiers folks use today.
Another consideration is whether these state changes change anything in Journals (I don't think they should, but quarantine explicitly does to help inform mirrors of the removal/addition) and Project Events (probably should add some history to record who and when these changes were made).

so I'd encourage some deeper thought into what these names mean, and whether or not they convey the appropriate meaning.

Yeah, it'd be good to sample the community a bit and see if they find these names intuitive/understandable. My thinking is that we'd include documentation on docs.pypi as well for these, and link to those docs from the respective project headers.
To whit: calling @sethmlarson, @webknjaz, and @ofek to the opinions phone 🙂

Another consideration is whether these state changes change anything in Journals (I don't think they should, but quarantine explicitly does to help inform mirrors of the removal/addition) and Project Events (probably should add some history to record who and when these changes were made).

Yep, big +1 to recording these state changes in the project events, and I'm a slight -1 on including them in the journal (for the reasons you've said 🙂)

Here's some unstructured brain dump from me..
Should this include/inherit things that trove classifiers already expose? There are 7 development statuses already. My understanding is that the difference is in the classifiers being dist metadata while the suggested metadata bit is project-global and is not bound to a specific version, right? Wouldn't it be useful to mark a subset of old versions as deprecated, as opposed to an entire project? I think Tidelift values such metadata, among other things. Perhaps, it's reasonable to ask them to share their experience? By the way, if this new metadata is different/conflicting compared to the trove classifiers — which one is supposed to be the source of truth? Should using the trove classifiers be deprecated in favor of the new statuses (if yes, all of the old statuses need to be represented too).
Also, how would the dependency resolvers be expected to take this metadata into account? I think that the deprecation status might need to be coupled with some redirect when a maintainer knows which project/fork is going to keep being maintained. And the successor project might need to expose a backreference similar to Obsoletes-Dist in dist metadata.

Should this include/inherit things that trove classifiers already expose? There are 7 development statuses already. My understanding is that the difference is in the classifiers being dist metadata while the suggested metadata bit is project-global and is not bound to a specific version, right? Wouldn't it be useful to mark a subset of old versions as deprecated, as opposed to an entire project?

Yes, the trove classifiers are metadata for a specific version of a package, whereas the suggested statuses are project-global. With regards to marking a subset of old versions as deprecated: I'm not sure this would be a good fit for anything other than the "deprecated" status. That is, other statuses like "archived" or "finished/done" usually refer to an entire project, and the main goal of this feature is to give maintainers an easy way of communicating this to downstream users.

By the way, if this new metadata is different/conflicting compared to the trove classifiers — which one is supposed to be the source of truth? Should using the trove classifiers be deprecated in favor of the new statuses (if yes, all of the old statuses need to be represented too).

The way I understand it, there's no conflict: a trove classifier of Development Status :: 3 - Alpha for pkg==0.0.5 communicates that version 0.0.5 of pkg is an alpha version. If that was the last version the maintainer released, and they come back years later and mark the project as "Archived", then both pieces of information are correct: the project has been archived, and the last released version was an alpha.
Given that, it wouldn't make sense to deprecate trove classifiers in favor of the new statuses. The new statuses are only meant to describe an (unlikely to change) end status for a project (deprecation/archival/etc), whereas trove classifiers are still needed for release-specific information of the entire project lifecycle.

Also, how would the dependency resolvers be expected to take this metadata into account? I think that the deprecation status might need to be coupled with some redirect when a maintainer knows which project/fork is going to keep being maintained. And the successor project might need to expose a backreference similar to Obsoletes-Dist in dist metadata

I think this feature can be useful without prescribing how dependency resolvers use this information (if they do at all). The fact that the information can be queried by API already makes it useful for users monitoring this kind of information for their supply chain security, and showing it in the web UI helps users that visit the project's PyPI page.
I'm unsure about adding an extra field for specifying a replacement package. I think that type of information is prone to decay, and in any case it could be included in the README or project description. I don't think dependency resolvers would be able to use the information about a replacement package anyway, since there would have to be a guarantee of being a 1:1 drop-in replacement.

Thanks for opening this issue, here are some thoughts:

@miketheman: Adding LifecycleStatus was intended to be extended exactly as you're describing - so yay!

Should whether a project is quarantined or not be separate from a user-defined lifecycle status? Quarantining is a process outside of anything user-controlled and in my mind should be reversible without disturbing the project.

Trove classifiers

IMO, trove classifiers were not the right mechanism for capturing the information about project lifecycle, requiring publishing a new version to update the information means it's either out-of-date or tedious to maintain.
Better mechanisms: Pre-releases are captured using the version number, "mature" from the age and amount of users. Something akin to "archived" or "deprecated" outside of packaging metadata makes sense to me, so this feels like the right layer to host this information.
I don't think this system should try to capture everything that trove classifiers do, if only because the information doesn't evenly apply to a project (instead to releases).

Yanking, client-side warnings/errors

The yanking PEP doesn't mention anything about project lifecycle, instead focusing on "stopping the bleeding" for broken versions.
Similar to yanking, I could definitely see an installer warning about a deprecated project. Deprecation brings to mind that the project is intending for its audience to take action (either adopting another project or removing it).
Archived is the language that GitHub uses, I think we should pick one state between archived/completed/finished so we don't confuse users or maintainers about what it means. I think it makes sense to also warn users in this case? I'm not quite sure why mentally I am more hung up on warnings users for this case than deprecation.
I think archiving implies that there will be no more security fixes from upstream, which is relevant for users of open source trying to comply with regulations, so this information is helpful if a medium/large project were to be marked as archived.

Resolving

I don't think any of these statuses should have an effect on resolvers.

Another link: https://github.com/pypi/warehouse/issues/1506

And naming things is hard - so I'd encourage some deeper thought into what these names mean, and whether or not they convey the appropriate meaning.

After thinking a bit, I think the most important thing is to add a mechanism for mantainers to signal their users that they should re-evaluate their use of a project
The names suggested are different "flavors" of the above to give the user more context. But maybe we should start with their definition, rather than with their name.
I propose the following two categories to start the discussion:

Category 1: Users are strongly encouraged to stop using the project. Users should not expect any further updates, not even security or bug fixes.

Category 2: Users should evaluate if they want to stop using the project. Users should not expect any new features, but bug fixes might be addressed, and security issues will be addressed.

Using the original names, Deprecated and Archived would fit into Category 1 (strong suggestion to stop using), and Finished would fit into Category 2 (suggestion to evaluate use).
Is that a fair summary? What things should be added or removed?

I like those categories!
As a related thought: something PyPI could do is email a project's owners after a designated period of inactivity (2-3 years?) and nudge them to consider adding a status label. That would have to be carefully balanced to avoid annoying users/spamming people, however.


[bug] Android dev fail in Windows

Describe the bug
tauri android dev throw an error:
error Command failed with exit code<PHONE_NUMBER>.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
       Error Failed to assemble APK: command ["D:\\workspace\\rust\\tauri\\examples\\api\\src-tauri/gen/android\\api\\gradlew.bat", "--stacktrace", "--project-dir", "D:\\workspace\\rust\\tauri\\examples\\api\\src-tauri/gen/android\\api"] exited with code 1
error Command failed with exit code 1.

Gradle output:
FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:rustBuildX86_64Debug'.
> A problem occurred starting process 'command 'yarn''

...

Caused by: java.io.IOException: Cannot run program "yarn" (in directory "D:\workspace\rust\tauri\examples\api\src-tauri"): CreateProcess error=2, 系统找不到指定的文件 (translated: 'The system cannot find the file specified')。
        at net.rubygrapefruit.platform.internal.DefaultProcessLauncher.start(DefaultProcessLauncher.java:25)
        ... 7 more
Caused by: java.io.IOException: CreateProcess error=2, 系统找不到指定的文件 (translated: 'The system cannot find the file specified')。

It means that the gradle process can not find the npm or yarn command, but why?
This did not happen in<EMAIL_ADDRESS>Reproduction

Development in Windows with Node installed.
Clone tauri repo and checkout next branch.
Build CLI + API.
Run yarn tauri android init + yarn tauri android dev at examples/api.

Expected behavior
Android apk should be compiled successfully.
Platform and versions
Environment
  › OS: Windows 10.0.22624 X64
  › Webview2: 111.0.1661.44
  › MSVC:
      - Visual Studio Community 2022
  › Node.js: 16.19.1
  › npm: 8.19.3
  › pnpm: 7.29.0
  › yarn: 1.22.19
  › rustup: 1.25.2
  › rustc: 1.67.1
  › cargo: 1.67.1
  › Rust toolchain: stable-x86_64-pc-windows-msvc

Packages
  › @tauri-apps/cli [NPM]: 2.0.0-alpha.3
  › @tauri-apps/api [NPM]: 2.0.0-alpha.1
  › tauri [RUST]: 2.0.0-alpha.4,
  › tauri-build [RUST]: 2.0.0-alpha.2,
  › tao [RUST]: 0.18.0,
  › wry [RUST]: 0.27.0,

App
  › build-type: bundle
  › CSP: style-src 'unsafe-inline' 'self' https://fonts.googleapis.com; default-src 'self' customprotocol: asset:; font-src https://fonts.gstatic.com; img-src 'self' asset: https://asset.localhost blob: data:
  › distDir: ../dist
  › devPath: http://localhost:5173/
  › framework: Svelte
  › bundler: Vite

App directory structure
  ├─ dist
  ├─ isolation-dist
  ├─ node_modules
  ├─ public
  ├─ src
  └─ src-tauri

Stack trace
No response
Additional context
No response

<EMAIL_ADDRESS>used the absolute path to npm or yarn and now we're trying to do things using the PATH instead. But some PATH additions might not be available in the gradlew runner. Can you tell more about your setup? How are you adding yarn to the PATH?

@lucasfernog
My Node is installed by https://github.com/coreybutler/nvm-windows and seems that duct can not find it:
A tiny example:
fn main() {
  let env_path = std::env::var("Path").unwrap();
  println!("env Path: {:?}", &env_path);
  duct::cmd("npm", ["-v"]).env("Path", env_path).run().unwrap();
}

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { kind: NotFound, message: "program not found" }'

PATH is like this:
blabla;C:\\Users\\berto\\AppData\\Roaming\\nvm;C:\\Program Files\\nodejs;blabla

C:\\Program Files\\nodejs was linked to C:\Users\berto\AppData\Roaming\nvm\v16.19.1

I use fnm and it works well. Maybe you need to configure something so npm is in the PATH?

What's the contents of C:\Program Files\nodejs btw? Maybe you need to append /bin to it or something like that.

@lucasfernog I tried with fnm but still failed, here are my steps:

reinstall node.js
install fnm using choco install fnm
setup powershell by adding fnm env --use-on-cd | Out-String | Invoke-Expression to $PROFILE
restart Windows

Now npm and the environment variables are correct, I think
PS C:\Users\berto> npm -v
9.5.0

Get-Command npm
CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Application     npm.cmd                                            <IP_ADDRESS>    C:\Users\xxx\AppData\Local\fnm_multishells\xxx\npm.cmd

Gradle still does not find npm.
But I found THE workaround: change npm to npm.cmd. It works.

But I runed into a new problem:
The dev command started without any error, but nothing appears in my Android simulator - No app launched.
<-------------> 0% EXECUTING [8s]
> :app:rustBuildX86_64Debug                   Compiling wry v0.27.0TING [10s]
   Compiling tauri-runtime-wry v0.13.0-alpha.2 (D:\workspace\rust\tauri\core\tauri-runtime-wry)
   Compiling tauri v2.0.0-alpha.4 (D:\workspace\rust\tauri\core\tauri)
   Compiling tauri-plugin-log v0.1.0 (https://github.com/tauri-apps/plugins-workspace?branch=next#39b144df)
   Compiling tauri-plugin-sample v0.1.0 (D:\workspace\rust\tauri\examples\api\src-tauri\tauri-plugin-sample)
   Compiling api v0.1.0 (D:\workspace\rust\tauri\examples\api\src-tauri)
    Finished dev [unoptimized + debuginfo] target(s) in 7.65s
        Info symlinking lib "D:\\workspace\\rust\\tauri\\examples\\api\\src-tauri\\target\\x86_64-linux-android\\debug\\libapi.so" in jniLibs dir "D:\\workspace\\rust\\tauri\\examples\\api\\src-tauri/gen/android\\api\\app/src/main/jniLibs/x86_64"
        Info "D:\\workspace\\rust\\tauri\\examples\\api\\src-tauri\\target\\x86_64-linux-android\\debug\\libapi.so" requires shared lib "liblog.so"
        Info "D:\\workspace\\rust\\tauri\\examples\\api\\src-tauri\\target\\x86_64-linux-android\\debug\\libapi.so" requires shared lib "libandroid.so"
        Info "D:\\workspace\\rust\\tauri\\examples\\api\\src-tauri\\target\\x86_64-linux-android\\debug\\libapi.so" requires shared lib "libdl.so"
        Info "D:\\workspace\\rust\\tauri\\examples\\api\\src-tauri\\target\\x86_64-linux-android\\debug\\libapi.so" requires shared lib "libm.so"
        Info "D:\\workspace\\rust\\tauri\\examples\\api\\src-tauri\\target\\x86_64-linux-android\\debug\\libapi.so" requires shared lib "libc.so"
<-------------> 0% EXECUTING [1m 23s]
> :app:rustBuildX86_64Debug

My Windows VM is broken but I'm opening a PR to fix the .cmd thing, can you help test it?
@amrbashir can you see if there's something wrong with the emulator on Windows?

worked fine for me, can you try recreating the android project, clearing the target folder and potentially any old apks on the emulator with the same bundler identifier?
I did encounter another bug but that bug will crash the CLI and it is with pnpm, so I am gonna assume it is not related to this, but here is the error in case you run into it:

><EMAIL_ADDRESS>tauri D:\dev\tauri-app
> tauri "--" "android" "android-studio-script" "--target" "x86_64"

error: unexpected argument 'android' found

  note: subcommand 'android' exists; to use it, remove the '--' before it

Usage: pnpm run tauri [OPTIONS] <COMMAND>

For more information, try '--help'.
?ELIFECYCLE? Command failed with exit code 2.

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:rustBuildX86_64Debug'.
> Process 'command 'pnpm'' finished with non-zero exit value 1

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

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

BUILD FAILED in 2s
 ELIFECYCLE  Command failed with exit code<PHONE_NUMBER>.
       Error Failed to assemble APK: command ["D:\\dev\\tauri-app\\src-tauri/gen/android\\tauri_app\\gradlew.bat", "--project-dir", "D:\\dev\\tauri-app\\src-tauri/gen/android\\tauri_app"] exited with code 1

After fixing the above pnpm error I quickly ran into the same issue. I think the CLI when invoked from pnpm, yarn or npm, it never exists and instead it hangs up indefinitely. I encountered the same issue with pnpm tauri android init.

I have no idea why it hangs but the commands are executed and resolved back to the JS cli, yet the process doesn't exit. Exiting the process manually on successful commands fixes it. I opened https://github.com/tauri-apps/tauri/pull/6510 for this.

I have no idea why it hangs but the commands are executed and resolved back to the JS cli, yet the process doesn't exit. Exiting the process manually on successful commands fixes it. I opened #6510 for this.

The process doesn't exit because of a bug from napi. I have fixed but the author have not released a new version for it.

Ah nice, looks like it got released today.

this should be fixed now in the latest tauri-cli 2.0.0-alpha.5


Detect Infinity increasing height

I understand that the current start of the web maybe is impossible to determine the iframe size if the iframe contents is cyclic dependent on the frame size. E.g. height:100vh;
But there's any way to programmatically detect and prevent such content from breaking the host page? The iframe content is user generated.

I don't see why that would not work

I have also been able to reproduce this with using min-height: 100vh and % on the child page. The iframeresizer gets stuck in a loop because view height is dependent on the size of the frame which is dependent on the content (due to iframeresizer).
You could do the height calculation via JS on page load (based on the height of the parent - you could use the iframeresizer calls for this) albeit a messy solution, whatever way you try work around it the easiest method is to just not use % or vh for heights but that limits what you can do with the iframe.
Another solution is to just not use the iframe resizing capabilities, have a fixed size iframe.

Oh I see, I don't think their is an easy code fix for that. I can only suggest using taggedElement or you can create your own custom method to calculate the height inside the iframe.
https://github.com/davidjbradshaw/iframe-resizer/blob/master/docs/iframed_page/options.md#heightcalculationmethod--widthcalculationmethod


Trip to Portlandia!

So, we are (finally!) putting on the schedule some dates for our {Mesh, Hack}/{RoadTrip, Train} to Portlandia, OR :)
We have two options currently and would love to know how would it work best for you, options are

Sun 19th to Tue 21th or Wed 22th
Sun 26th to Tue 28th

How does these dates sound, @kyledrake btw, @maxogden, @bcomnes @caseorganic ?

The 19th to the 22nd are during OSCON, so there's a bunch of tech people in town during that block. Probably your best days for networking.
Both date ranges work fine for me!

I'll probably be at this on Tuesday https://www.eventbrite.com/e/kubernetes-10-launch-after-hours-party-tickets-16980424908

I'm hosting a JS BBQ on the 23rd: https://ti.to/maxogden/jsbbq-pdx-2
On Friday, July 17, 2015, Kyle Drake<EMAIL_ADDRESS>wrote:

I'll probably be at this on Tuesday
https://www.eventbrite.com/e/kubernetes-10-launch-after-hours-party-tickets-16980424908
—
Reply to this email directly or view it on GitHub
https://github.com/ipfs/community/issues/38#issuecomment-122465519.

--
Sent from my phone

I'm out of town 26-28, but am around the rest of the time!  Would be great to kick it while your here :)

It's happening, tomorrow we'll drive down :)

Cool, let me know when you're getting here and where you are.

@krl @jbenet @heems @mappum and me (@diasdavid) all aboard the meshtrain!
@whyrusleeping fancy joining us?
I found this on the Amtrak website: 501 Amtrak Cascades 7:25am - 11:05am

@diasdavid How long are you in PDX? I might be able throw an impromptu IPFS meetup here, but it needs to happen like fast (I usually need a little more advance notice).

woo! :tada: :balloon: :beers:

thanks to @diasdavid and @kyledrake for organizing all the things.

Here we go:
http://attending.io/events/ipfs-portland-meetup-the-permanent-distributed-web
http://calagator.org/events/1250468792

Distribute these links on your respective social network things :)

Other things:
Puppet Labs open house, @diasdavid is handling tix for the IPFS crew https://www.eventbrite.com/e/puppet-labs-oscon-2015-open-house-tickets-17371853682
I'm going to the Kubernetes launch, if anyone is interested feel free. Not sure how long I'll be there but I'm going to check it out: http://kuberneteslaunch.com/

@feross keeping you posted of the events schedule ^^ :) Good time to book that flight

Hey @maxogden and @jbenet  I'm not in Portland today - but would love to see some progress getting Fedwiki running on IPFS. Will be having our weekly Hangout with Ward in a couple of hours - I'll bring it up. Good chance to meet? Would be great to get this sorted before Chaos Communication Camp in August?


Reflexion: target "npm" as server by default

In QuantumOptions.ts, the function isTargetServer reads like this:
    public isTargetServer() {
        return this.optsTarget === "server" || this.optsTarget === "electron" || this.optsTarget === "npm";
    }

This means that, if the quantum target is set to npm, the code will be considered server-side; while an npm package can definitely be made for the browser-side.
As universal (of which npm is quite similar) is nor letting true isTargetServer nor isTargetBrowser, the npm target should perhaps do the same.

@eddow I think you misunderstood target npm. Any package on npm is kind of server side. FuseBox transforms into a corresponding target upon bundling.
Target npm just preserves require statements which is essential when bundled with FuseBox or any other bundler. That's why we need to let it be

Okay, the problem then is when I try to make an npm package that is intended to be used browser-side.
When using the target "browser", requiring an external libraries does not generate a require('external') but just check out a cache ... that is empty.

Up - Do you plan to make it possible to bundle a client-side library or should I make a fork to publish on npm?
For now, you have 'end-product:server/client/universal' and 'library:server'
As I am developing some 'library:universal', if you refuse to bundle such, I will have to find another way to have my things bundled.
Could we have the team have a look onto that problem? I feel we are stuck here just the two of us.

@eddow please read this one https://fuse-box.org/page/publishing-to-npm#publish-raw-typescript-package-recommended
You can also set target npm when publishing. It will be converted either to server/browser/universal upon bundling. To be clear if it's target npm on the actual npm, it doesn't mean that the result will be target server
Alternatively, publish typescrpit source or ts:main property in package.json like it's described in the guide. All your problems will be solved

Well, ts:main is a work around to avoid going through the bundling of the library - it is a way to bypass fuse-box.
I wish to use fuse-box to bundle the library - this is what I speak about, not bypassing it.
(beside,  containedAPI and bakeApiIntoBundle links are obsolete, as these options seem to no more exist on the Quantum page)
I didn't understand what you mean by " if it's target npm on the actual npm"
The function isTargetServer will return true if this.optsTarget === "npm" - this means what it means!
This will lead to the fact that, in the bundle, isServer and isBrowser will be replaced respectively by true and false instead of checking whether the window object exists or not => technically, npm => server and all the client-side functionalities (like using the CSS) are disabled.
As I make a library that uses CSS, using target: 'npm' removes the cSS and for now, I have to hack by having my users adding the CSS on my library in their programs.

@eddow Ok, how about adding target npm-server npm-browser targets and avoid breaking changes. I will be happy to accept the PR if it doesn't break anything.

That would definitively be great, I'll do that


Handle warning when libusb is not available

If libusb is not available on the operating system, etcher doesn't show any warning regarding this issue.
Etcher: 1.4.4
OS: 4.4.0-127-generic Ubuntu 16.04

@horia-delicoti did you see any error ?


Add support for Travis CI builds

This code change adds support (a config file) for Travis CI builds. It also adds a build badge to the README. Example of it building my fork.
To get this to work you will also need to:

Head over to Travis CI and sign-in with your GitHub account
Once signed in you should get a list of your repos. Locate go-alexa and select it.
Locate the blue green "Activate repository" button. Press it and follow any additional steps to get it setup.
Travis CI will automatically start building new pull requests and commits (this can be customized). Once this PR is merged all new code will be built (using go test) against go 1.8, 1.9, 1.10, 1.x, and "tip". The build badge on the README will reflect the current state of building master.

This is awesome. I fixed the conflict in the README and setup the account, so I'm merging this in.
(The go tip job is taking a while to complete, but for this PR I think it's OK to merge without it!)


user changes their own password

Search before asking

[X] I had searched in the issues and found no similar feature requirement.

Description
users can change their own passwords
Use case
No response
Related issues
no
Are you willing to submit a PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

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

Hi. At present, user password is managed by administrator.
Welcome to contribute code to realize users' own password management.

@aiwenmo I am willing to submit a PR!

我愿意来完成这个问题 @aiwenmo


Testcase for Pidora is missing

Pidora (ID: pidora) is one of the distros with a reliable ID. A testcase should be added.
If you want to help, it is sufficient to post to this issue:

The content of the /etc/os-release file, if any.
The file names and content of the /etc/*release and /etc/*version files, if any.
The output of the command: lsb_release -a, if available.

Pidora (the OS) is discontinued
nobody responded to this in five yeears

hence i propose to close the issue and accept test cases in a pull request.


The first time a list appears can render the elements twice

When we show this list:
GtPhlowProtoView new columnedList
        column: 'Text' text: [:x| StringSignal emit: 'Text ', x asString. x ];
		items: (1 to:100).

We expect to see 7 signals showing up in Beacon. Instead, we see this:

works now


Terminal showCommandGuide is quite slow for really large outputs

Repro:
Run ls -Recurse in a large repo with a high terminal.integrated.scrollback set, hover and leave the terminal. This example was with ~38k lines of output:

I have the same issue, it is slowing down the compilation heavily and it sticks.


（spark4j-spark）ExecutorLostFailure (executor 1827 exited caused by one of the running tasks) Reason: Container:container_**: on host: ****.bj marked as failed. Exit status: 255. Diagnostics: [2021-11-22 20:58:26.551]container-launch with exit code: 255

detail：
ExecutorLostFailure (executor 1827 exited caused by one of the running tasks) Reason: Container:container_**: on host: .bj marked as failed. Exit status: 255. Diagnostics: [2021-11-22 20:58:26.551]container-launch with exit code: 255
[2021-11-22 20:58:26.553]Container exited with a non-zero exit code 255. Error file: prelaunch.err.
Last 4096 bytes of prelaunch.err :
Last 4096 bytes of stderr :
log4j:WARN Continuable parsing error 45 and column 23
log4j:WARN The content of element type "log4j:configuration" must match "(renderer,throwableRenderer?,appender,plugin*,(category|logger)*,root?,(categoryFactory|loggerFactory)?)".
AssertError:maxdf must be smaller than FDSETSIZE
[2021-11-22 20:58:26.559]Container exited with a non-zero exit code 255. Error file: prelaunch.err.
Last 4096 bytes of prelaunch.err :
Last 4096 bytes of stderr :
log4j:WARN Continuable parsing error 45 and column 23
log4j:WARN The content of element type "log4j:configuration" must match "(renderer*,throwableRenderer?,appender*,plugin*,(category|logger)*,root?,(categoryFactory|loggerFactory)?)".
AssertError:maxdf must be smaller than FDSETSIZE
backround：
xgboost version 0.82
spark version 2.3.4
Driver Memory:
13g
Num Executors:
1000
Executor Memory:
14g
Executor Cores:
4
param：
spark.hadoop.parquet.enable.summary-metadata=false
spark.executor.extraJavaOptions="-XX:MaxDirectMemorySize=2048m"
spark.yarn.executor.memoryOverhead=2048
spark.driver.maxResultSize=2048
spark.dynamicAllocation.enabled=true
spark.shuffle.service.enabled=true
spark.dynamicAllocation.minExecutors=16
spark.dynamicAllocation.maxExecutors=1024
spark.dynamicAllocation.initialExecutors=16
If you need additional information, I will be more than happy to provide

xgboost version 0.82

Unfortunately, it has been deprecated for a long time now, please upgrade XGBoost.  Also, please provide a reproducible example similar to the one described in https://stackoverflow.com/help/minimal-reproducible-example .
Feel free to reopen if there's a reproducible example or any further questions.


Cache PropertyInfos in .ToTableEntityList and .ToTableEntity

fixes #12204

Are we fixing allocations or CPU time? Do we have rough numbers? Is it time to add a benchmarking project?

Are we fixing allocations or CPU time? Do we have rough numbers? Is it time to add a benchmarking project?

Added a perf benchmark. Although the savings are less than I expected, we save both allocations and CPU.


Fix 3 ITs that now expect "text" as type for all columns, tables etc.

What this PR does:
Changes mapping from gRPC internal column type of VARCHAR (used internally by persistence) into TEXT which is the expected external type (see #1499).
Which issue(s) this PR fixes:
No separate PR filed.
Checklist

[ ] Changes manually tested
[x] Automated Tests added/updated -- passes 3 regressed tests for StargateV2
[ ] Documentation added/updated

@olim7t does this make sense?


openidc.lua:819: authenticate(): id_token 'HS256' signature verification failed, client: 10...

Ran into this error today, saw similar comments on https://github.com/SkyLothar/lua-resty-jwt/issues/72 as well as a release to fix this for RS256 here
My fix for this was to switch to RS and that worked just fine.  I'm not that familiar with the guts on this repo, but figured I'd report this in the case it might be affecting others.

@pamiel the bug seems to still be there in lua-resty-openidc (1.5.4 which includes our pr) or lua-resty-jwt wherever this is:
openidc.lua:898: authenticate(): id_token 'HS256' signature verification failed,

lua-resty-openidc 1.5.4
lua-resty-jwt 0.1.11
logs:
From ngx.log(ngx.ERR, "jwt: ", cjson.encode(jwt_obj), " ,valid: ", jwt_obj.valid, ", verified: ", jwt_obj.verified)
2018/05/22 19:22:00 [debug] 10168#10168: *1 [lua] openidc.lua:821: openidc_load_jwt_and_verify_crypto(): jwt: {"signature":"EHPFUStF8SYfAF6MKPDsc9oseopTgP-4WNJlha6P_4Q","reason":"internal error","valid":true,"raw_header":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9","payload"..."header":{"alg":"HS256","typ":"JWT"},"verified":false,"...

after futher investigation it comes from how luarocks compiles the libraries. using opm will fix this.
i didnt look at the exact problem though, but same versions, same files, no problem

For the record, the lua-resty-jwt README.md says:

Attention ❗ the hmac lib used here is lua-resty-hmac, not the one in luarocks.

so it seems logical that it is related to the hmac.lua dependency.

yep that seems right. @zandbelt I guess the readme in the lua-resty-openidc repos should swap luarocks instructions to use opm. I'm not really aware of the lua community discussions around this, but did notice that the openresty website mentions you should always use opm instead of luarocks now due to "issues in how luarocks packages modules", or something similar:
https://openresty.org/en/using-luarocks.html
"WARNING! This page is deprecated. Use of LuaRocks with OpenResty is strongly discouraged since OpenResty provides its own package manager, OPM."
and: https://github.com/3scale/apicast/issues/104

lua-resty-jwt addresses this by including its own version of lua-rest-hmac:
https://github.com/SkyLothar/lua-resty-jwt/blob/master/vendor/resty/hmac.lua
in the rockspec:
https://github.com/SkyLothar/lua-resty-jwt/blob/master/lua-resty-jwt-dev-0.rockspec#L26
but I have also experienced myself that this can be overwritten by an explicit separate manual install of lua-resty-hmac from luarocks (or perhaps it was already installed). Perhaps it is worth looking into that.
Other than that I'll swap instructions but I think usage of luarocks still exceeds opm by far.


fix(Jinja): Extra cache keys for calculated columns and metrics using Jinja

SUMMARY
This is a follow up to https://github.com/apache/superset/pull/30715. It adds logic to check Jinja in calculated columns and also metrics (both ad-hoc and from the dataset level).
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
No UI changes.
TESTING INSTRUCTIONS
Added testing to this flow.
ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Required feature flags:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

@villebro thanks for initial pass 🙏 I addressed your feedback + removed a redundant import. Let me know if you have any questions!


Topic Services not working on ROS2 (foxy)

The swri-roscpp support for topic services under ROS2 (at least for foxy, but I'm pretty sure dashing as well) isn't working because of a change in message name generation.  The current python splitter expects Request.h and Response.h, but with ROS2, the IDL generator forces names into snake_case. The splitter needs to be updated accordingly.

@matt-attack, do you have time to look at this?  If not, this might be a good issue for @danthony06.

I can look at it.
On Mon, Sep 14, 2020, 9:22 AM P. J. Reed<EMAIL_ADDRESS>wrote:

@matt-attack https://github.com/matt-attack, do you have time to look
at this? If not, this might be a good issue for @danthony06
https://github.com/danthony06.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/swri-robotics/marti_common/issues/601#issuecomment-692085591,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABBZWHH3LZZEJEUVV2K2QQTSFYRJXANCNFSM4RKAUE5Q
.

@danthony06 I've got a fix I'm working with now, should be a couple days before I can verify.  I'm happy to provide as-is, or push when it's ready.  Just let me know how you want to proceed.

If you have a fix, I can work on verifying it.

Can you add me as a contributor, then I can just push my branch.  Or would you prefer I send by email?

Do you have the repo forked somewhere that I could branch off of?

Ok - forked, pushed my changes to the fork, and PRed into your dashing branch.  Let me know if you have any questions or prefer a different workflow.

Fixed by #604.


Fuzz suite

@fb-alexcq  here's the fuzzing suite I created during the Sherlock competition, feel free to DM over Discord for any questions.

Cool, i'm looking into this later tonight!  :-D

seems the checkin 45e73e9, removed the git submodule files, this caused new cloned project cannot get submodule correctly, please check if this the problem.

patch.diff.zip
Attach is a patch, I can run the test.
Currently 1 test failed, 1 passed.
[FAIL. Reason: failed to set up invariant testing environment: No contracts to fuzz.] invariant_liquidityDoesntChangePrice() (runs: 0, calls: 0, reverts: 0)
Please help check it, thx!

Hey!
Sorry about the issue with dependencies, I tried using a workaround because I couldn't find a way to handle the specific version of solidity-examples with foundry but wasn't too familiar with how to do this in a foundry + hardhat project, your implementation makes much more sense.
The patch resolves the hardhat compilation issue, I just had to change some import statements in the files in the recon directory to get it to compile in foundry/echidna/medusa (with crytic-compile).
Regarding running the tests I forgot to mention that these tests are meant to be run with the echidna and medusa fuzzers. Getting them to run as foundry invariant tests should just be a matter of changing some configurations which I'll look into.
To work with the changes from the patch I had to modify the medusa.json in commit 6a8b285 so you'll need to pull these to your local branch to run medusa.
To run the fuzzers you can use the commands in the CryticTester contract:
Echidna
echidna . --contract CryticTester --config echidna.yaml

Medusa
medusa fuzz

Results (echidna left, medusa right):

This made me realize I should've included this information in a README so I'll add that now!

please help verify checkin 9e813a3
Ln84-96
Since swap without transfer will lead to fail, so the check logic should in the catch block.

That's a good catch, makes sense to include it in the catch block.
Regarding the other catch blocks I'd recommend leaving the assertions commented out or else they'd end up causing multiple false positives for property breaks when running the fuzzer, I had mostly included those for debugging coverage when initially testing to see where certain calls might have always been reverting.


Added preprocessor directives for specific compilers

Added individual preprocessor macros for 4 msvc compiler, Clang, GCC and MinGw.
I also added a test function, TestPrepoc to the Process tests. This emits all the compiler macros and requests the user/tester visually inspect the result.
This is still from the same fork I made earlier. I think it ought to work seamlessly, but I have not attempted two requests from a single fork before.

I am using @Sqeaky fork for creation of conan.io package (https://github.com/memsharded/conan-robot, https://www.conan.io/source/Robot/2.0/memsharded/testing), because it is more convenient having a CMakeLists.txt. So far, only tested VS14 and VS12, both static and shared linking, works great.


can you explain pls [not an game issue]

look roblox played my game

When someone has Roblox Premium and plays your game. You will get pay by Roblox for the time that person had spent in your game.

oh

i was like when i see 1 robux "its a glitch ill refresh the page"

lol yessss

hey, can you review me game?
https://web.roblox.com/games/4901926257/hard-obby


HBASE-27809 Attach move replication queue storage from zookeeper to a separated HBase table design doc to git repo

https://issues.apache.org/jira/browse/HBASE-27809

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 10s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ HBASE-27109/table_based_rqs Compile Tests _

_ Patch Compile Tests _

_ Other Tests _

2m 24s

Subsystem
Report/Notes

Docker
ClientAPI=1.42 ServerAPI=1.42 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5197/1/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5197

Optional Tests

uname
Linux dc16cb916458 5.4.0-144-generic #161-Ubuntu SMP Fri Feb 3 14:49:04 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
HBASE-27109/table_based_rqs / 3193cffc9a

Max. process+thread count
34 (vs. ulimit of 30000)

modules
C: . U: .

 U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5197/1/console

versions
git=2.34.1 maven=3.8.6

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 56s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+0 :ok:
shelldocs
0m  0s
Shelldocs was not available.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ HBASE-27109/table_based_rqs Compile Tests _

+1 :green_heart:
spotless
0m 45s
branch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
shellcheck
0m  0s
There were no new shellcheck issues.

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
spotless
0m 37s
patch has no errors when running spotless:check.

_ Other Tests _

+1 :green_heart:
asflicense
0m 12s
The patch does not generate ASF License warnings.

3m 36s

Subsystem
Report/Notes

Docker
ClientAPI=1.42 ServerAPI=1.42 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5197/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5197

Optional Tests
dupname asflicense spotless shellcheck shelldocs

uname
Linux f35cdf83f7a0 5.4.0-137-generic #154-Ubuntu SMP Thu Jan 5 17:03:22 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
HBASE-27109/table_based_rqs / 3193cffc9a

Max. process+thread count
44 (vs. ulimit of 30000)

modules
C: . U: .

 U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5197/2/console

versions
git=2.34.1 maven=3.8.6

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 11s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ HBASE-27109/table_based_rqs Compile Tests _

_ Patch Compile Tests _

_ Other Tests _

2m 18s

Subsystem
Report/Notes

Docker
ClientAPI=1.42 ServerAPI=1.42 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5197/2/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5197

Optional Tests

uname
Linux e464fe19a274 5.4.0-144-generic #161-Ubuntu SMP Fri Feb 3 14:49:04 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
HBASE-27109/table_based_rqs / 3193cffc9a

Max. process+thread count
29 (vs. ulimit of 30000)

modules
C: . U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5197/2/console

versions
git=2.34.1 maven=3.8.6

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 57s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+0 :ok:
shelldocs
0m  0s
Shelldocs was not available.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ HBASE-27109/table_based_rqs Compile Tests _

+1 :green_heart:
spotless
0m 37s
branch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
shellcheck
0m  0s
There were no new shellcheck issues.

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
spotless
0m 38s
patch has no errors when running spotless:check.

_ Other Tests _

+1 :green_heart:
asflicense
0m  8s
The patch does not generate ASF License warnings.

3m 36s

Subsystem
Report/Notes

Docker
ClientAPI=1.42 ServerAPI=1.42 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5197/2/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5197

Optional Tests
dupname asflicense spotless shellcheck shelldocs

uname
Linux 21b09a6041e2 5.4.0-137-generic #154-Ubuntu SMP Thu Jan 5 17:03:22 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
HBASE-27109/table_based_rqs / 3193cffc9a

Max. process+thread count
44 (vs. ulimit of 30000)

modules
C: . U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5197/2/console

versions
git=2.34.1 maven=3.8.6 shellcheck=0.8.0

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.


Add support for routes with interfaces

Plugin version
master
NetBox version
V4.1.5
Feature type
Data model extension
Proposed functionality
Add the ability to configure routes with interfaces and/or too select a VDC instead of the device.
Use case
Some Vendors support VDCs, eg. Fortinet or CheckPoint
Some routes can only be specified by the interface, eg. PPP(oE) is just a route over an interfaces.
Where as some Vendors require the configuration of an interface with the gateway,
Database changes
Not sure
External dependencies
None

config router static
    edit 1
        set status disable
        set dst <IP_ADDRESS> <IP_ADDRESS>
        set gateway <IP_ADDRESS>
        set distance 200
        set device "internal1.997"
    next
end


Renaming the CRD's name to KamajiControlPlaneProvider

Kamaji Control Plane is just for linking with CAPI. So, we need to check TCP(tenant Control Plane) if we want to check the status of control plane.
That's why this repo's name is cluster-api-control-plane-provider-kamaji, not cluster-api-control-plane-kamaji.
I suggest renaming the CRD's name to KamajiControlPlaneProvider.
$: kubectl get kamajicontrolplaneprovider
NAME                       VERSION   INITIALIZED   READY   AGE
capi-quickstart   1.23.10   true          true    60d

Related to #66

I'm up for a discussion about this, although the renaming would be hard to tackle.

You would need to create all the new resources with the new name.
After that, all the TenantControlPlane instances must be patched with the right OwnerReference to the new resource
Finally, the old resources can be deleted, as well as the old CRD

I'm keeping the issue open to collect feedback from other users.

I'm up for a discussion about this, although the renaming would be hard to tackle.

You would need to create all the new resources with the new name.
After that, all the TenantControlPlane instances must be patched with the right OwnerReference to the new resource
Finally, the old resources can be deleted, as well as the old CRD

I'm keeping the issue open to collect feedback from other users.

Thank you for your consideration :)


feat: add support for config values in package.json

@digitalsadhu Is this covered in https://github.com/eik-lib/import-map-rollup-plugin/pull/34?

Ah yea, this can be closed I think.


Add onnx convert script

This PR added experimental onnx conversion support. Only CPU operators are supported for now.

It may be better to create a new directory under configs named onnx since the original config uses a different setting by default.

We may also update the configs online.


One-to-many relation is mapped to null, if "many" side is empty

Problem demo
If you add the test below in_ReadMeTests.cs_, that will fail.
[Test]
public void This_will_fail()
{
    // Arrange
    dynamic customer1 = new ExpandoObject();
    customer1.CustomerId = 1;
    customer1.FirstName = "Bob";
    customer1.LastName = "Smith";

    var customerList = new List<dynamic> { customer1 };

    // Act
    var customers = Slapper.AutoMapper.MapDynamic<Customer>( customerList );

    // Assert

    // There should only be a single customer
    Assert.That( customers.Count() == 1 );

    // There should only be a single Order
    Assert.That( customers.FirstOrDefault().Orders != null );
}

Expected
Collections should get a not null default value, like an empty array, list, or Enumerable.Empty<T>(),
or there should be an option to configure the behavior how one-to-many relations are mapped.
Motivation
See #42

Fixed. Pull request #41 merged in master


Checking sharing with for loops

If we have the following program:
A := new Add[32];
for #i in 0..#W {
  a := A<G+#i>(10, 20); // Uses the adder #W times
}

We need some way to check that the various shared uses of a are safe. The naive encoding is of course just unrolling the loop and adding constraints between each use. However, we can use the fact that the shared uses come from a structured loop to generate more efficient constraints. Namely:

To check that two invocations do not conflict, we need to enforce that #i >= delay of A. This is sufficient because each use of A is guaranteed to be #i cycles after the previous one.
To check that the parent component's delay is long enough, we can require that max(#i)  + delay of A - min(#i) <= delay. This is again sufficient because all uses of A are going to be contained within the range of #i.

The bigger challenge is what do when we have uses of A instead multiple contexts? I think the above can serve as a guideline for generating efficient constraints instead of the normal thing of O(n^2) constraints for each reuse.

@rachitnigam question about (1): I don't think the loop guarantees that each use of A is separated from other uses by i cycles; the way this loop is written, each use of A is separated only by 1 cycle. So if A has a delay of 2, we would want to throw an error here because we can only use it every 2 cycles, but we would have a bunch of uses like A<G>, A<G+1>, A<G+2>, and so on. A correct program should have uses A<G>, A<G+2>, A<G+4>, and so on. In the above example, if we check i >= delay, we would only catch this because the loop starts at 0, which doesn't seem rigorous enough because if the loop were to start at 3 (for example), we would generate uses A<G+3>, A<G+4>, .... These uses conflict with each other but would pass the i >= delay constraint.
A bit lower level, but for (1) I figure that we want to add constraints saying i >= delay of A - but doesn't this run into the problem we talked about earlier about how Facts get hoisted? I'm not familiar with the specifics of the discharge pass, but if we generate a bunch of constraints saying i >= some d, I have a feeling they won't ever get meaningfully discharged (with i having the right binding) with the current setup

Yup! You’re absolutely right about this! Some sort of structured “step” syntax seems useful because it keeps the constraints simple/tractable. I think I have an idea on how we can generalize this a bit more. Let’s schedule some time to talk?

Cool! When would be a good time to talk?


Color method

Create a method to create a color easily.

I added a color method and moved the XColor and GC creation.


test: Add additional unit tests for resolver scenarios [DEV-2360]

Divided unit tests to different folder that allows us to run a specific unit tests or all unit tests;
Moved unit tests from did_doc_service and resource_dereferencing_service to particular handlers;
Add more unit tests in:

Add integration tests for testing other ledger services:

QueryAllDidDocVersionsMetadata
QueryCollectionResources

request_service_dereference_collection_resources_test.go

invalid DID;
not supported resolutionType;
redirect an old Indy style DID.

request_service_dereference_resource_data_test.go

valid DID, but invalid resourceId;
invalid DID;
existent DID, but not existent resourceId;
redirect an old Indy style DID.

request_service_dereference_resource_metadata_test.go

valid DID, but invalid resourceId;
invalid DID;
existent DID, but not existent resourceId;
redirect an old Indy style DID.

request_service_resolve_did_doc_test.go

invalid DID;
not supported resolution type;
redirect an old Indy style DID.

Task linked: DEV-2360 Add additional unit tests for resolver scenarios

Task linked: DEV-2311 Update resolver integration tests


OpenShift 3.6

moves to openshift 3.6, however currently facing an issue with the vpc seemingly clashing with the SDN

I'm working on the following issue to try and fix this:
https://github.com/openshift/openshift-ansible-contrib/issues/767


build(deps): replace pillow-heif with pi-heif

Summary
Closes #2664 and replaces pillow-heif with pi-heif due to more permissive licensing on the binary wheel for pi-heif.

@MthwRobinson, I'm getting dependency conflicts on my PR from this: https://github.com/Unstructured-IO/unstructured/actions/runs/10585107965/job/29330948732?pr=3562


Read Timeout with stream_context before 4

as above， read timeout (default: 30s) by virctorialogs web console
@hagen1778 @dmitryk-dk @Loori-R I am developing show context of logs pannel  https://github.com/VictoriaMetrics/victorialogs-datasource/issues/41
Cloud you see it ?

Hi @worker24h ! Need to check your question and why it happens. I suppose this is VMLogs limitation

Hi @worker24h ! Need to check your question and why it happens. I suppose this is VMLogs limitation

I think syntax is  correct，as follow, it's timeout too.

Hi @worker24h ! Need to check your question and why it happens. I suppose this is VMLogs limitation

I think syntax is correct，as follow, it's timeout too. The may be a bug?
@dmitryk-dk @hagen1778

I think there can be solutions.

Could you check the query in the developer mode network tab.? Is there timoute query param present?

The maximum query execution time is limited by -search.maxQueryDuration command-line flag value. This limit can be overridden to smaller values on a per-query basis by passing the needed timeout via timeout query arg. For example, the following command limits query execution time to 4.2 seconds:

Could you increase the -search.maxQueryDuration flag to 90s and check if it helps?

Hi @worker24h ! Need to check your question and why it happens. I suppose this is VMLogs limitation

I think syntax is correct，as follow, it's timeout too. The may be a bug?

@dmitryk-dk @hagen1778

I think there can be solutions.

Could you check the query in the developer mode network tab.? Is there timeout query param present?

The maximum query execution time is limited by -search.maxQueryDuration command-line flag value. This limit can be overridden to smaller values on a per-query basis by passing the needed timeout via timeout query arg. For example, the following command limits query execution time to 4.2 seconds:

Could you increase the -search.maxQueryDuration flag to 90s and check if it helps?

I know it cloud be changed for timeout period.
But I search data in latest 5min and limit 50 , it should response quickly.

Hi @worker24h ! Need to check your question and why it happens. I suppose this is VMLogs limitation

I think syntax is correct，as follow, it's timeout too. The may be a bug?

@dmitryk-dk @hagen1778

I think there can be solutions.

Could you check the query in the developer mode network tab.? Is there timeout query param present?

The maximum query execution time is limited by -search.maxQueryDuration command-line flag value. This limit can be overridden to smaller values on a per-query basis by passing the needed timeout via timeout query arg. For example, the following command limits query execution time to 4.2 seconds:

Could you increase the -search.maxQueryDuration flag to 90s and check if it helps?

I know it cloud be changed for timeout period. But I search data in latest 5min and limit 50 , it should response quickly. Do you think it doesn't timeout , too?

It looks like a bug in the VMLogs. If you can develop the feature while the bug will be fixed it would be cool.
Also you can create the ticket in the https://github.com/VictoriaMetrics/VictoriaMetrics repository with a description

Hey @worker24h! This seems suspicious. Are you sure VictoriaLogs is up&running and isn't overwhelmed with other service that is making requests?

Hey @worker24h! This seems suspicious. Are you sure VictoriaLogs is up&running and isn't overwhelmed with other service that is making requests?

Yes If I remove stream_context before 4, then get response quickly. So I think this is a bug with stream_context

I see. Please, open a bug report then.

I see. Please, open a bug report then.

I want try to fixed it and interest it, but I doesn't read source code never, so do you offer some articles or debugger method? Thanks

https://github.com/VictoriaMetrics/VictoriaMetrics/issues/7637
I create a new issue for this BUG.
Is the VictoriaLogs not open source? I can't find the source code for it
@hagen1778 @dmitryk-dk

I see. Please, open a bug report then.

I want try to fixed it and interest it, but I doesn't read source code never, so do you offer some articles or debugger method? Thanks

Hi! You can check the source code starts from the ProcessQueryRequest
https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/app/vlselect/main.go#L194
https://github.com/VictoriaMetrics/VictoriaMetrics/blob/6c6e469bfb8ad84f4d72412a015f7b7292cd713f/lib/logstorage/pipe_stream_context.go#L669
and you can go up from this function.


A transaction that will normally fail to execute due to a uniqueness violation, if submitted as a deferred transaction will partially execute instead of failing entirely as expected

When submitting a transaction that will cause a uniqueness constraint violation, it will fail immediately when submitting the transaction through cleos as expected. But submitting the exact same transaction as a deferred transaction causes some of the actions to succeed according to the history plugin and signals from the chain plugin while throwing the uniqueness constraint violation in nodeos:
#   19   2018-11-01T19:47:06.000     chintailease::prepare => chintailease  cc941cbb... {"memo":"useraccount2|1|30|0.1000|0|0.5000|cqfcymm6p2"}...
#   20   2018-11-01T19:47:06.000     eosio.token::transfer => chintailease  cc941cbb... {"from":"useraccount2","to":"chintailease","quantity":"3.000...
#   21   2018-11-01T19:47:06.000    chintailease::activate => chintailease  cc941cbb... {"memo":"useraccount2|1|30|0.1000|0|0.5000|cqfcymm6p2"}...
#   22   2018-11-01T19:47:42.000  chintailease::processpool => chintailease  555148f7... "00"...
#   23   2018-11-01T19:48:57.000  chintailease::processpool => chintailease  9828235f... "00"...
#   24   2018-11-01T19:50:12.000  chintailease::processpool => chintailease  d4e08b44... "00"...
#   25   2018-11-01T19:51:27.000  chintailease::processpool => chintailease  1467e696... "00"...
#   26   2018-11-01T19:52:42.000  chintailease::processpool => chintailease  1c51d943... "00"...
#   27   2018-11-01T19:53:25.000     chintailease::prepare => chintailease  606788ba... {"memo":"useraccount2|1|30|0.1000|0|0.5000|cqfcymm6p2"}...
#   28   2018-11-01T19:53:57.000  chintailease::processpool => chintailease  0c79cf6a... "00"...

Line 27 is an attempt to submit a duplicate transaction already done in line 19.
I haven't confirmed yet if any contract tables were actually changed or if it's just a bug in the history API where it shouldn't have recorded the second transaction attempt at line 27 due to it failing for uniqueness constraint violation.
Here is the nodeos output including some tags from the different signals in the chain plugin showing that the action trace was visible in accepted/applied transaction even though the transaction should have failed:
info  2018-11-01T19:53:24.503 thread-0  watcher_plugin.cpp:336        on_accepted_transact ] [on_accepted_transaction] meta: {"expiration":"2018-11-01T19:53:24","ref_block_num":1975,"ref_block_prefix":1084638139,"max_net_usage_words":0,"max_cpu_usage_ms":0,"delay_sec":30,"context_free_actions":[],"actions":[{"account":"chintailease","name":"prepare","authorization":[{"actor":"useraccount2","permission":"active"}],"data":"2c757365726163636f756e74327c317c33307c302e313030307c307c302e353030307c63716663796d6d367032"},{"account":"eosio.token","name":"transfer","authorization":[{"actor":"useraccount2","permission":"active"}],"data":"20f2d414217315d6a0b051d1993c5d43307500000000000004454f53000000002c757365726163636f756e74327c317c33307c302e313030307c307c302e353030307c63716663796d6d367032"},{"account":"chintailease","name":"activate","authorization":[{"actor":"useraccount2","permission":"active"}],"data":"2c757365726163636f756e74327c317c33307c302e313030307c307c302e353030307c63716663796d6d367032"}],"transaction_extensions":[],"signatures":[],"context_free_data":[]}
info  2018-11-01T19:53:24.503 thread-0  watcher_plugin.cpp:178        on_applied_tx        ] [on_applied_transaction] trace: {"id":"606788ba6d9d55233fbec6f9d1d69fe5d8bf1d5d2f0cf2dc1f052200389dab58","block_num":2037,"block_time":"2018-11-01T19:53:25.000","receipt":{"status":"hard_fail","cpu_usage_us":564,"net_usage_words":0},"elapsed":565,"net_usage":0,"scheduled":true,"action_traces":[{"receipt":{"receiver":"chintailease","act_digest":"88794f3bda96de6b13dee7f3d4bf7f1517239045856efb52bbc6ae7f46311646","global_sequence":0,"recv_sequence":0,"auth_sequence":[],"code_sequence":0,"abi_sequence":0},"act":{"account":"chintailease","name":"prepare","authorization":[{"actor":"useraccount2","permission":"active"}],"data":"2c757365726163636f756e74327c317c33307c302e313030307c307c302e353030307c63716663796d6d367032"},"context_free":false,"elapsed":526,"console":"","trx_id":"606788ba6d9d55233fbec6f9d1d69fe5d8bf1d5d2f0cf2dc1f052200389dab58","block_num":2037,"block_time":"2018-11-01T19:53:25.000","account_ram_deltas":[],"except":{"code":13,"name":"St9exception","message":"could not insert object, most likely a uniqueness constraint was violated","stack":[{"context":{"level":"warn","file":"wavm.cpp","line":73,"method":"call","hostname":"","thread_name":"thread-0","timestamp":"2018-11-01T19:53:24.503"},"format":"${what}: ","data":{"what":"could not insert object, most likely a uniqueness constraint was violated"}},{"context":{"level":"warn","file":"apply_context.cpp","line":72,"method":"exec_one","hostname":"","thread_name":"thread-0","timestamp":"2018-11-01T19:53:24.503"},"format":"pending console output: ${console}","data":{"console":""}}]},"inline_traces":[]}],"failed_dtrx_trace":null,"except":{"code":13,"name":"St9exception","message":"could not insert object, most likely a uniqueness constraint was violated","stack":[{"context":{"level":"warn","file":"wavm.cpp","line":73,"method":"call","hostname":"","thread_name":"thread-0","timestamp":"2018-11-01T19:53:24.503"},"format":"${what}: ","data":{"what":"could not insert object, most likely a uniqueness constraint was violated"}},{"context":{"level":"warn","file":"apply_context.cpp","line":72,"method":"exec_one","hostname":"","thread_name":"thread-0","timestamp":"2018-11-01T19:53:24.503"},"format":"pending console output: ${console}","data":{"console":""}}]}}
info  2018-11-01T19:53:24.503 thread-0  watcher_plugin.cpp:169        on_action_trace      ] [on_action_trace] [606788ba6d9d55233fbec6f9d1d69fe5d8bf1d5d2f0cf2dc1f052200389dab58] Added trace to queue: prepare | To: chintailease | From: useraccount2 | Data: {"memo":"useraccount2|1|30|0.1000|0|0.5000|cqfcymm6p2"}
info  2018-11-01T19:53:25.000 thread-0  watcher_plugin.cpp:328        on_accepted_block_he ] [on_accepted_block_header] block_num: 2037
info  2018-11-01T19:53:25.000 thread-0  watcher_plugin.cpp:256        on_accepted_block    ] [on_accepted_block] block_num: 2037
info  2018-11-01T19:53:25.000 thread-0  watcher_plugin.cpp:280        on_accepted_block    ] [on_accepted_block] block_num: 2037
info  2018-11-01T19:53:25.001 thread-0  watcher_plugin.cpp:281        on_accepted_block    ] [on_accepted_block] Matched TX in accepted block: 606788ba6d9d55233fbec6f9d1d69fe5d8bf1d5d2f0cf2dc1f052200389dab58
info  2018-11-01T19:53:25.001 thread-0  watcher_plugin.cpp:287        on_accepted_block    ] [on_accepted_block] Action queue size after removing item: 0

Those look like log entries. Are you getting those results out of the history plugin’s json rpc api?

The history plugin relies on chainbase’s undo to clean up garbage results as a side effect of controller’s use of undo.

The first snippet is output from cleos get actions, the second is log output in nodeos.

What do you mean by "partially execute"?

The transaction that was broadcasted had 3 actions in it as shown above (prepare, transfer, activate).
The transaction is designed such that if it would be submitted again as a duplicate then the activate action would try to insert a duplicate row and cause the entire transaction to fail. In the action log above i submitted the same transaction twice - it succeeded the first time as expected but the second time should have failed completely but actually one of the actions were applied according to anything listening on the applied transaction signal such as the history api and my plugin.
The transaction fails as expected when submitted as a normal transaction with nothing applied.
If it’s executed as a deferred transaction then the first action (prepare) emits an applied transaction signal and is saved in the history plugin while the other 2 actions are not applied as expected.

I see what happened. The signaling is correct. The way the history plugin relies on undo backfired.

Signaling: it’s marked as a hard_fail, something plugins should either filter on or record. Recoding it allows you to see why deferred transactions fail. state_history_plugin records deferred failures.

On the postgresql side of things: clients which only care about executed actions will include “where transaction_status=‘executed’”

Analysis: the history plugin has a core assumption that it can blindly store traces without any status checking. The idea is that anything it stores will be rolled back by undo when there's a problem.
Problem: controller sometimes does the undo before sending applied_transaction.
Potential fix: the history plugin will have to check for the existence of a transaction receipt. If it's absent or indicates failure then it shouldn't store the trace.
Caution for history plugin users: the history plugin is deprecated. Its approach may have additional unnoticed border cases.
Caution for other plugin authors: even after this fix, the history plugin will still rely on undo, which greatly simplifies its logic. Plugins which store data outside of chainbase have a much higher burden. The history plugin is not suitable as a reference.

Isn't it interesting to have the hard_fail transaction stored somewhere? Otherwise, how can you know some transactions failed? It's the only way a user can grab that info an debug its contract.
Perhaps the user should check for the status?

@acoutts is that on mainnet? if so, would you share the transaction ID?

Isn't it interesting to have the hard_fail transaction stored somewhere? Otherwise, how can you know some transactions failed? It's the only way a user can grab that info an debug its contract.

Absolutely. That's what the mongodb and state history plugins do, but only for deferred since those are part of consensus.
The deprecated history plugin won't after this fix.

@abourget this was just on my local testnet.

Resolved by #6220.


[Fix] Fix the jmod issues, support 11 and later versions  #10232

Purpose of the pull request
The official website document only indicates that developers use the 1.8+ version for development, but it does not point out that the version after 1.9+ should be incompatible with jmod, so I fixed this problem and support the 11+ version. The reason why version 1.9 is not supported is because it will require developers to modify the --release parameter of IDEA configuration. I think this is not friendly to developers. It is better to suggest that they upgrade to 11 for development.
Brief change log
Added a profile configuration to the root POM file
Verify this pull request
This change added tests and can be verified as follows:
mvn test -Pjmod
(or)
run the application in IDEA

I think we should open a discussion before adding this.

You are right, because it is better to eliminate the dependency of the code in the program on the modules that are not open inside java, but the problem now is that there is such a dependency in the code, and it will cause the program to fail to compile. I think you guys can remove my pr after refactoring the code improvement, but for now I think this pr is necessary

@kezhenxu94 PTAL

Codecov Report

Merging #10239 (5892fc9) into dev (d7d6699) will increase coverage by 0.02%.
The diff coverage is 63.63%.

:exclamation: Current head 5892fc9 differs from pull request most recent head 61ccbc9. Consider uploading reports for the commit 61ccbc9 to get more accurate results

@@             Coverage Diff              @@
##                dev   #10239      +/-   ##
============================================
+ Coverage     40.93%   40.95%   +0.02%
- Complexity     4729     4734       +5
============================================
  Files           854      854
  Lines         34553    34565      +12
  Branches       3818     3819       +1
============================================
+ Hits          14144    14156      +12
  Misses        19056    19056
  Partials       1353     1353

Impacted Files
Coverage Δ

...er/api/controller/ProcessDefinitionController.java
45.34% <0.00%> (ø)

...che/dolphinscheduler/api/python/PythonGateway.java
9.23% <0.00%> (ø)

...nscheduler/plugin/task/mlflow/MlflowConstants.java
0.00% <ø> (ø)

...olphinscheduler/plugin/task/mlflow/MlflowTask.java
68.05% <60.00%> (+1.87%)
:arrow_up:

.../org/apache/dolphinscheduler/api/enums/Status.java
100.00% <100.00%> (ø)

...duler/api/interceptor/LoginHandlerInterceptor.java
82.60% <100.00%> (ø)

...api/service/impl/ProcessDefinitionServiceImpl.java
31.07% <100.00%> (ø)

...scheduler/plugin/task/mlflow/MlflowParameters.java
66.30% <100.00%> (+3.20%)
: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 d7d6699...61ccbc9. Read the comment docs.

@kezhenxu94
I have no problem running the StandaloneServer, but I haven't done CI. I'm not very clear about the CI process of the project. I don't know where to start. Can you guide the following?

Please associate the corresponding issue. @106umao

@kezhenxu94
PTAL.

Hi @106umao , please make the CI passed

@kezhenxu94
I'm sorry, I haven't found how to fix the problem on CI for now. I'm preparing for DolphinScheduler's summer of programming project, so I can't concentrate on fixing bugs these days. Please let me keep this PR for a few days. Fix it after the project proposal is submitted.

@kezhenxu94
I'm sorry, I haven't found how to fix the problem on CI for now. I'm preparing for DolphinScheduler's summer of programming project, so I can't concentrate on fixing bugs these days. Please let me keep this PR for a few days. Fix it after the project proposal is submitted.

sure

The CI still failed

The CI still failed

Sorry, I'm still testing, hope you don't mind

The errors seem to be getting worse, I think I should stop this pr for a while and go to the documentation to write how to develop code on jmod first...

you should add the doc in this PR, and they will be merge together with your code

I can build successfully with opeanjdk 11, but in IDEA need to remove --release config :).

Hi @ruanwenjun
The first time I found this problem was when I started StandaloneServer with IDEA, you can try to start it, and if you don't have any problems try to use mvn clean test instead of mvn clean compile, because there are still many problems with unit tests. For details, see this pr-related issues

Hi, any progress?


Add serviceType to our "dummy" service in empty servers

@fandrei in the changes you made against issue #126
We added dummy data for service, serviceName, serviceDescription
Could we include serviceType in to this and the value for the field should be "NoService"
When making changes to the diagram I realised there is some logic that requires this. @mrdavidlaing said it might be possible to add this to the release you are going to deploy this week ?

@ryanholder, why not


Using %e, %E, %x, or %X to format a floating-point value that ends up with an exponent between 0 and 9.
https://go.dev/play/p/oaSxLmPizik
fmt.Printf("%e, %E, %x, %X, %b\n", 1e0, 1e0, 1e0, 1e0, 5e+15)
fmt.Printf("%e, %E, %x, %X, %b\n", 1e1, 1e1, 1e1, 1e1, 1e+16)
fmt.Printf("%e, %E, %x, %X, %b\n", 1e10, 1e10, 1e10, 1e10, 1e20)
fmt.Printf("%e, %E, %x, %X, %b\n", 1e100, 1e100, 1e100, 1e100, 1e100)

What did you see happen?
The exponent value is zero-padded to two digits. Interestingly, %b does not exhibit this behavior.
1.000000e+00, 1.000000E+00, 0x1p+00, 0X1P+00,<PHONE_NUMBER>000000p+0
1.000000e+01, 1.000000E+01, 0x1.4p+03, 0X1.4P+03,<PHONE_NUMBER>000000p+1
1.000000e+10, 1.000000E+10, 0x1.2a05f2p+33, 0X1.2A05F2P+33,<PHONE_NUMBER>000000p+14
1.000000e+100, 1.000000E+100, 0x1.249ad2594c37dp+332, 0X1.249AD2594C37DP+332,<PHONE_NUMBER>468029p+280

What did you expect to see?
The exponent value is not zero-padded.
I realize it may be a bit cheeky to file this as a bug, given that the behavior seems deliberately coded. But, I couldn't find any documentation saying that it is correct behavior, and it doesn't seem to make much sense given that it does not result in a uniform length for exponents since they can also be three digits long.
I am also genuinely curious if it is intentional that %b behaves differently in this respect.

Related Issues

fmt: %#g behavior not consistent #36562 (closed)
cmd/gofmt: change in exponent literal notation from 1.12 to 1.13 #32580 (closed)
fmt: the "alternate form" (the # flag) for floating point is not supported #18857 (closed)
fmt: %#v of integer value in float64 (fraction = 0) incorrectly has ".0" suffix #27598 (closed)
fmt: get wrong result when using "%.30f" in fmt.Sprintf #47931 (closed)
x/text/number, x/text/message: number formatting order of magnitude error #31254
strconv: ParseFloat seems not working correctly with a large exponent #42436
fmt: padding flag is not accepted with minus flag #51419 (closed)

Related Code Changes

fmt: do not remove trailing zeros for %g and %G with #(sharp) flag

Related Discussions

behavior of %f

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

It's what C does for the %e and %E formats:
% cat x.c
#include <stdio.h>

int main(void) {
   printf("%e\n", 13.0);
   return 0;
}
% gcc x.c
% a.out
1.300000e+01
%

I suspect the behavior in Go for %b is more an accident then anything deliberate but probably won't change.

FWIW, the C behavior (which does seem bizarre) is documented in the standard describing %e and %E (emphasis added):

A double argument representing a floating-point number is converted in the
style [−]d.ddd e±dd, where there is one digit (which is nonzero if the
argument is nonzero) before the decimal-point character and the number of
digits after it is equal to the precision; if the precision is missing, it is taken as
6; if the precision is zero and the # flag is not specified, no decimal-point
character appears. The value is rounded to the appropriate number of digits.
The E conversion specifier produces a number with E instead of e
introducing the exponent. The exponent always contains at least two digits,
and only as many more digits as necessary to represent the exponent. If the
value is zero, the exponent is zero.

@robpike

It's because that's what C does for the %e and %E formats

I was holding out some hope this could be fixed since it's previously been stated that fmt is not beholden to C compatibility. But I assume at this point that changing this would run afoul of Hyrum's Law, and this should be considered a documentation bug?
@meem

FWIW, the C behavior (which does seem bizarre) is documented in the standard

I sort of have to imagine that this traces its lineage to a float formatter that didn't consider doubles? But ostensibly that would have been pre-C.

No, it's not beholden but it's also designed to be like it, especially when dealing with the same things. And because of the compatibility promise, the behavior is very unlikely to change.

Thank you @ianlancetaylor!


Config / runtime option for SerializeAsAny

Initial Checks

[X] I have searched Google & GitHub for similar requests and couldn't find anything
[X] I have read and followed the docs and still think this feature is missing

Description
(Inspired by the problem in #6403.)
The idea is to add serialize_as_any as a config (or runtime) option.
As a config option, the model would be serialized in a duck-typed fashion (as V1 would behave), but this would not apply to fields of the model:
class GenericBase(BaseModel):
    model_config = ConfigDict(serialize_as_any=True)

As a runtime option, all fields of the model would be serialized in a duck-typed fashion, recursively:
GenericBase().model_dump_json(serialize_as_any=True)

The name serialize_as_any is open to bikeshedding - I've suggested it to match the SerializeAsAny type annotation. One possibly compelling alternative name is strict (maybe ser_strict as the config option to separate from strict validation).

Context
In Pydantic V2 we changed the serialization from duck-typed to serialize exactly the model specified. That is to say, in the following model:
class GenericBase(BaseModel):
    pass

class ListType(GenericBase):
    type: str = "list"
    element_type: GenericBase = Field()

class StringType(RootModel, GenericBase):
    root: str = "string"

Then in V2 the ListType.element_type field will always serialize as {} (as that's the contents of GenericBase), but the equivalent in V1 would serialize as the concrete subclass.
Concretely:
# V2 behaviour
ListType(element_type=StringType()).model_dump_json()
'{"type":"list","element_type":{}}'

# V1 behaviour
ListType(element_type=StringType()).json()
'{"type":"list","element_type":"string"}'

The way to get the V1 behaviour back in V2 (duck-typed serialization) is by wrapping the annotation in SerializeAsAny.
class ListType(GenericBase):
    type: str = "list"
    element_type: SerializeAsAny[GenericBase] = Field()

This will now fix serialization for ListType, but other uses of GenericBase will all need to similarly be wrapped in SerializeAsAny.

Alternatives
Some possible alternatives to the model config:
class MyBase(BaseModel):
    pass

MyBase = Annotated[MyBase, SerializeAsAny]

@serialize_as_any
class MyBase(BaseModel):
    pass

class MyBase(BaseModel, serialize_as_any=True):
    pass

I'm unaware of an alternative strategy for the runtime option at this time.
Affected Components

[ ] Compatibility between releases
[ ] Data validation/parsing
[X] Data serialization - .model_dump() and .model_dump_json()
[ ] JSON Schema
[ ] Dataclasses
[X] Model Config
[ ] Field Types - adding or changing a particular data type
[ ] Function validation decorator
[ ] Generic Models
[ ] Other Model behaviour - model_construct(), pickling, private attributes, ORM mode
[ ] Plugins and integration with other tools - mypy, FastAPI, python-devtools, Hypothesis, VS Code, PyCharm, etc.

Selected Assignee: @adriangb

Related: https://github.com/pydantic/pydantic-core/pull/740

@adriangb where do things stand with the more global ways of enabling duck-typing serialization? Not sure if that was abandoned or paused or what. Seems like it might be worth a config setting unless I'm misremembering challenges with that

I think I ran into technical limitations getting it working, but I don’t fully remember. We can try again.

Thanks, that would be appreciated! We can probably workaround this by own schema generation but it is not nice.

Is this still something planned for release? If there are specific tasks remaining I would be happy to help. This change has proven to be quite annoying compared to more typical ways to deal with this issue like annotating fields as sensitive/hidden.

We have code that uses pydantic and have been unable to upgrade due to the serialization change as we'd need to make changes in many places in the code. We wanted to share that this config option would be a very helpful feature for us.

I still think this is a good idea and would be preferred/helpful for a lot of people. @sydney-runkle I think this is worth adding to the priorities list. I also personally think we should prioritize getting something out to address well before any kind of v3 push (just don't want this to get lumped into the "we'll do it in v3" pile).

I think we should call this "seared duck" as it's duck typing serialisation.

FWIW this is also a blocker for upgrading our large pydantic-based project to v2. We have a custom BaseModel subclass used throughout, with lots of nested models inheriting from it. Not keen on adding SerializeAsAny everywhere.
This new serialization behavior default in v2 is also a bit surprising. We use SecretStr to prevent secrets from being leaked in serialization/dumps.

Is there any reasonable workaround for this, perhaps by overwriting __get_pydantic_core_schema__? I naively attempted copying what SerializeAsAny does:
class MyModel(BaseModel):

    @classmethod
    def __get_pydantic_core_schema__(cls, source: type[Any], handler: GetCoreSchemaHandler) -> core_schema.CoreSchema:
        schema = handler(source)
        schema["serialization"] = core_schema.wrap_serializer_function_ser_schema(
            lambda x, h: h(x),
            schema=core_schema.any_schema(),
        )
        return schema

But this results in pydantic_core._pydantic_core.PydanticSerializationError: Error calling function : ValueError: Circular reference detected (id repeated)

Is there any reasonable workaround for this, perhaps by overwriting __get_pydantic_core_schema__? I made a naive attempt to copy what SerializeAsAny does:
class MyModel(BaseModel):
    @classmethod
    def __get_pydantic_core_schema__(cls, source: type[Any], handler: GetCoreSchemaHandler) -> core_schema.CoreSchema:
        return SerializeAsAny(). __get_pydantic_core_schema__(source, handler)

But this results in pydantic_core._pydantic_core.PydanticSerializationError: Error calling function <lambda>: ValueError: Circular reference detected (id repeated)
I'm building tools used by scientists who are unlikely to understand or remember that they need to use the SerializeAsAny type annotation.

@rmorshea This is how I have worked around it for now (though excited for a better solution). Many thanks to #6381 for inspiration
from pydantic import BaseModel, SerializeAsAny
from pydantic._internal._model_construction import ModelMetaclass
from typing import Any, Dict, Tuple

# See https://github.com/pydantic/pydantic/issues/6381
class _SerializeAsAnyMeta(ModelMetaclass):
    def __new__(self, name: str, bases: Tuple[type], namespaces: Dict[str, Any], **kwargs):
        annotations: dict = namespaces.get("__annotations__", {})

        for base in bases:
            for base_ in base.__mro__:
                if base_ is BaseModel:
                    annotations.update(base_.__annotations__)

        for field, annotation in annotations.items():
            if not field.startswith("__"):
                annotations[field] = SerializeAsAny[annotation]

        namespaces["__annotations__"] = annotations

        return super().__new__(self, name, bases, namespaces, **kwargs)

class MyBaseModel(BaseModel, metaclass=_SerializeAsAnyMeta):
    pass

class A(BaseModel):
    x: int = 0

class B_old(BaseModel):
    a: BaseModel

class B_new(MyBaseModel):
    a: BaseModel

print(B_old(a=A()).model_dump())
print(B_new(a=A()).model_dump())

You can probably do something like this, even though I think its a bit slow:
# Force SerializeAsAny to all fields of the model
@classmethod
def __get_pydantic_core_schema__(cls, source_type: Any, handler: GetCoreSchemaHandler) -> CoreSchema:
    schema = handler(source_type)
    schema_to_update = schema

    while "schema" in schema_to_update and schema_to_update["type"] != "model-fields":
        schema_to_update = schema_to_update["schema"]

    fields_to_update = schema_to_update["fields"]
    for field, field_schema in fields_to_update.items():
        while field_schema["type"] in ["definitions", "function-before", "default", "model-field"]:
            field_schema = field_schema["schema"]
        field_schema["serialization"] = core_schema.wrap_serializer_function_ser_schema(
            lambda x, h: h(x), schema=core_schema.any_schema()
        )
    return schema

Unfortunately both solutions appear to break if you use any custom types with specialized serialization logic. For example, I have a custom type annotation that serializes Pandas DataFrames into the Apache Parquet file format. Adding SerializeAsAny causes Pydantic to complain Unable to serialize unknown type: <class 'pandas.core.frame.DataFrame'> because the Any annotation from SerializeAsAny is taking precedence over my custom type.
Put another way, the workarounds above are not synonymous with SerializeAsAny[MyModel] rather, they implicitly wrapping every field of MyModel with SerializeAsAny which, as in my case, isn't always desirable.
If there is no other option but to modify the fields of MyModel (rather than wrapping MyModel itself) the only real solution seems to be recursively drilling down into each annotation to wrap only subclasses of BaseModel in SerializeAsAny.