Consider disabling auto-commit by default

Using this issue as a forum for discussion.
IMHO there are a couple of points of concern WRT auto commit by default:
Test All the Things! (Again)
Once approval has been granted, the bots kick off a full retest. If the tests all passed previously from the last commit, this seems unnecessary and time consuming. Github's merge will handle merge conflicts for us ... as long as  merge works, that should be sufficient.
Too Soon?
As we all know, there are a lot of cooks in the kitchen (at the time of this writing, there are 36 open PRs). Because we're still pre-1.0, many things are still in flux and as a result, many PRs touch multiple components.  If PR 2 doesn't disable auto-commit manually, it could accidentally slip in first.  Switching to manual commit by default would resolve the general problem of PRs getting in before the author is ready to commit.
I'm sure there are other reasons for switching to manual commit by default, but these are the ones that immediately spring to mind.

/cc @geeknoid @kyessenov @ZackButcher @rshriram @hklai

@rshriram

/cc @yutongz

/cc @louiscryan
On Thu, Dec 21, 2017 at 10:45 AM Andy Lai<EMAIL_ADDRESS>wrote:

/cc @yutongz https://github.com/yutongz
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/2308#issuecomment-353426758, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJGIxts2NNuLf_5lVNPwjaLm7zW6D0sFks5tCqdYgaJpZM4RKHoe
.

Once approval has been granted, the bots kick off a full retest. If the tests all passed previously from the last commit, this seems unnecessary and time consuming. Github's merge will handle merge conflicts for us ... as long as merge works, that should be sufficient.
you should test against latest master, which is what's going on, tide is marginally more efficient
As we all know, there are a lot of cooks in the kitchen (at the time of this writing, there are 36 open PRs). Because we're still pre-1.0, many things are still in flux and as a result, many PRs touch multiple components.  If PR 2 doesn't disable auto-merge manually, it could accidentally slip in first. Switching to manual merge by default would resolve the general problem of PRs getting in before the author is ready to merge.
/hold covers this
you can /hold a PR and then /hold cancel when you're ready, but it will still make sure tests are ready before merge
if you have dependent commits you should DEFINITELY actually test the dependent PR again after the first PR is merged
.. that way you can make sure they actually work together
Github's merge will handle merge conflicts for us ... as long as merge works, that should be sufficient.
it often isn't
sure the code merged cleanly, but that doesn't mean it behaves properly. that's the whole point of testing PRs
if you're going to trust "clean merge and tested at some point in time" == green then you should just skip testing to begin with because you're not actually gating on green tests anyhow
if you don't want a PR to merge add [WIP] in the title or put a /hold comment (with the prow hold plugin enabled) and just have tide block on do-not-merge labels
that's not a suitable reason to get rid of the merge robot

For more information:
http://prow.k8s.io/plugin-help.html
https://github.com/istio/test-infra/tree/master/mungegithub#do-not-merge-1

To sum up:

you do want to retest against latest commit pairs before merge ideally
tide is smarter about this
you can hold a PR using a label, and prow has a command to apply / remove this label
which tide / submit-queue can be made to block on

The key point of auto-merge is to save people's time from "manually update branch with master" and run tests again since there is a chance when you rerun the tests, some other commits may merged into master and you need to do the process all over again.

We sent out survey in Sept to all istio-developers (not just google), and here is the responses about auto-merge system.

yutongz@ TBH, re-running the tests isn't as big of a deal for me. Nothing is perfect, however, and I'd argue that even with re-running all the tests you're still not completely safe from other commits creeping in. Manually clicking the merge button only differs in that the time since the last test execution (and therefore the number of possible commits since then) may be greater. Many reasonably large open source projects live with this and do fine.
More to the root of my concern ... I'd be happy if our default behavior was /hold and that /hold cancel be a manual action taken by someone to actually commit the PR.  As it stands now, someone doing /approvemight trigger the merge without the PR author having a chance to weigh in.  Basically, I just want committing to be an active (rather than a passive) action.

@yutongz also it is worth nothing that your survey in Sept involved 9 people total.  We currently have over 100 contributors.  I suspect your results would be different if taken today.

/cc @andraxylia @douglas-reid @ldemailly @jmuk @vickyxu

The bot is needed with mono repo so PRs can scale and be fire and forget once accepted and we don't need people to keep rebasing manually to get their PR in.
I don't think it's valuable use of human's time of people to manually merge PRs when a bot can do it properly/better.
Let's improve the bot/make it smarter as needed rather than drop it.

Looks like the point of discussion is who triggers the merge rather than manual vs auto merging.
I hate manual merging, in a sense, I want enforcement of checking, since human makes mistakes. In other words, this simply means merge should be disabled if some test (or some checking) fails. But when all tests are green, and lgtm and approval are given, should it be automatically merged, or is it up to the PR author?
I honestly don't care, and I'm personally happy with current auto merging, but I understand that sometimes PR author wants to control the timing. That is also common among Google's internal tools or some other public code reviews (gerrit / rietveld) IIRC.

Auto merging was one of the requirements for the mono repo, otherwise there will be a need to constantly rebase.

@andraxylia

Auto merging was one of the requirements for the mono repo, otherwise there will be a need to constantly rebase.

Again, (as @jmuk pointed out) this discussion is not about whether the author has to manually rebase ... it's about whether the PR is automatically submitted or not.

All, semantics seem to have caused some issue here.  I've reworded the PR to replace "merge" with "commit" in the hopes of clarifying that I'm not talking about manually rebasing, etc.

Does the retest do it from a clean cache-free state?
I certainly hope so -- I've seen several examples of unexpected results from stale cached state in PR pre-submits (most recently: copying outdated, no longer generated files from bazel-genfiles over top of updated files in the current PR). That alone would be worth re-testing for me (once everything is good to go).
Auto-merging and auto-submission generally seem useful to me. There are very few times that I haven't wanted a PR in once I've received an /lgtm. If I could add /hold in the PR description itself (can I do this today? i've never tried), that'd be gravy to me (similar to having a gate around seeing "DO NOT SUBMIT" in the description). I've never quite adjusted to using github labels when creating PRs (and I don't think I'm alone here).
That being said, if it defaulted to /hold or /do-not-merge and I had to explicitly opt-in to auto-submission for PRs (maybe through a - [x] EnableAutoSubmit or /autosubmit line in the PR description), I'd be fine with that approach too. Just please don't make me constantly rebase manually.
The one thing we don't really have in Github is some coherent way of marking comments as "resolved", which I think would generally be a nice gate for PR submission (auto or otherwise). But that's a story for another time.
In addition to surveying developers, it might be revealing to track how many PRs are created with /holds over a quarter and see if there is a more preferred default behavior. I imagine that there'd be other considerations, but it'd be nice to know what the actual behavior is, as well as to point to tangible issues caused by our default behavior (are there any auto-submit postmortems, if you will, for past failings?).

Does the retest do it from a clean cache-free state?

Good question ... @yutongz do you know the answer?

Just please don't make me constantly rebase manually.

Yeah, I don't think anybody wants that :).  FYI Github does support the following merge types:

Merge: Add all commits from the head branch to the base branch with a merge commit.
Squash and Merge:  Combine all commits from the head branch into a single commit in the base branch.
Rebase and Merge:  Add all commits from the head branch onto the base branch individually.

It would be good to know what our bots are doing here.  Are they squashing and merging? Squashing, rebasing, and merging? Just curious if they're doing something for us that we can't get from plain vanilla Github.
@yutongz any thoughts here?

The one thing we don't really have in Github is some coherent way of marking comments as "resolved", which I think would generally be a nice gate for PR submission (auto or otherwise). But that's a story for another time.

Agreed - that would be nice. Seems like a missing GitHub feature in general, really.  Maybe worth having someone from dev infra look into this, if they haven't already?

In addition to surveying developers, it might be revealing to track how many PRs are created with /holds over a quarter and see if there is a more preferred default behavior.

I'm not sure that such metrics would be all that useful, since they will rely on developers to:

remember what the command is (is it /hold?), and ...
remember to add /hold to every PR that they wish to manually submit.

My reason for this issue, ultimately, is that requiring developers to remember something like this is inherently doomed to failure, because we'll all forget and it will eventually lead to issues as the project continues to grow. Auto submission within Google is not something we enable by default, and I suspect for good reason.  I'm merely suggesting that we follow suit.

Does the retest do it from a clean cache-free state?

No

Just please don't make me constantly rebase manually.

It's not about the final "merge method" (we always use "Squash and Merge" in istio). It's about update branch with latest master:

Idealy, you don't need to update branch (also called rebase/merge from master) before running tests because prow will merge your branch into master locally and run tests against this code. You will not see any changes happens on your branch but you can find some clue when you go to prow log.

From https://github.com/istio/test-infra/tree/master/mungegithub#stage-two
@nmittler  I believe your issue is mainly a behavior preference. Some people like default merging and others don't. And different kind of contributors(core like google/IBM/Cisco or other random external contributors) will have different opinions.
TBH I don't care about which one we are using. Either way, some part of people need to be educated and required to do a tiny extra step. Yes, you are right, google 3 don't auto-merge by default and yes you are right, we are open source not google 3. So as long as we make a decision and educate people to do the right thing, I think we are good to keep going.

Either way, some part of people need to be educated and required to do a tiny extra step

@yutongz good point.  I think the problem (at least for me) has been lack of documentation for the PR workflow and all of the machinery that we've built in (e.g. prow). Let me take an action to add some docs in that regard.
For now I think we can close this issue.  Thanks for the discussion.

Given the new CI proposal by @hklai and the testing team, I think we can close this.


Layout issue, minimize icon is not centered

Description
The minimize icon of the window of the entire software is centered up and down, aligned with the maximize icon, while the minimize icon of the lower subwindow is not centered up and down, which looks very awkward, please optimize and improve

DBeaver Version
22.3.0
Operating System
No response
Database and driver
No response
Steps to reproduce
No response
Additional context
No response

DBeaver is built on Eclipse platform and these parts of ui are not managed by DBeaver. So, we can't do something with it.
The main window's minimize icon depends on your OS. Eclipse uses such icon for minimize action everywhere, so, maybe it's even stated in https://github.com/eclipse-platform/ui-best-practices. If you wonder about the reasons for that or want to propose suggestion, I suppose you could open an issue or ask in the discussions here https://github.com/eclipse-platform/.github.


feat: ros include guard

Check include guard.

Added a test. It can be checked with the pytest command at the repository root.

Great, thank you!
And is it possible to add a workflow of GitHub Actions as well?

@isamu-takagi Could you create a draft PR to autoware.universe or some other places and test this hook?

I created it here.


[BUG] Medusa Server not starting after adding medusa-extender to existing project

Describe the bug
I was following this medusa-extender docs: run npm install medusa-extender and ./node_modules/.bin/medex init. Then, I launched npm run start, but the terminal showed an error:
$ npm run start

><EMAIL_ADDRESS>start
> npm run build && NODE_ENV=development node ./dist/main.js

><EMAIL_ADDRESS>build
> rm -rf dist && ./node_modules/.bin/tsc -p tsconfig.json

'.' is not recognized as an internal or external command,
operable program or batch file.

This is happening even after uninstalling medusa-exntender
To Reproduce
Steps to reproduce the behavior:

Setup Medusa Server (with Postgres)
Add medusa-extender to an existing Medusa project by running npm install medusa-extender and ./node_modules/.bin/medex init
Run npm run start
See error in the terminal

Expected behavior
Medusa Server should run as extender docs said
Package version:
    "dependencies": {
        "@medusajs/medusa": "^1.6.0",
        "@medusajs/medusa-cli": "^1.3.3",
        "medusa-extender": "^1.8.8",
        "medusa-file-cloudinary": "^1.0.1",
        "medusa-fulfillment-manual": "^1.1.31",
        "medusa-interfaces": "^1.3.3",
        "medusa-payment-manual": "^1.0.16",
        "medusa-payment-stripe": "^1.1.45",
        "typeorm": "^0.2.36"
    },

Upd: I managed to run the script by appending "node" into "build" script, like "build": "rm -rf dist && node ./node_modules/.bin/tsc -p tsconfig.json", but now terminal says:
$ npm run start

><EMAIL_ADDRESS>start
> npm run build && NODE_ENV=development node ./dist/main.js

><EMAIL_ADDRESS>build
> rm -rf dist && node ./node_modules/.bin/tsc -p tsconfig.json

C:\Users\Alex\Desktop\medusa\backend\node_modules\.bin\tsc:2
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
          ^^^^^^^

SyntaxError: missing ) after argument list
    at Object.compileFunction (node:vm:352:18)
    at wrapSafe (node:internal/modules/cjs/loader:1031:15)
    at Module._compile (node:internal/modules/cjs/loader:1065:27)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:17:47

Tsc should not be run using node in front of it. Are you on windows by any chance?

Yes, I'm on Windows. Thanks for the tip!


Blake scheduler

This change is

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#770  👈
#767
#765
#764
#761
#712
#711
#710
#708
#707
#715
#714
#713
#706
#705
#704
#702
#701
dev

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @spapinistarkware and the rest of your teammates on  Graphite

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 93.28%. Comparing base (1ba9ec1) to head (987d545).

Additional details and impacted files
@@                    Coverage Diff                     @@
##           spapini/07-29-blake_round     #770   +/-   ##
==========================================================
  Coverage                      93.28%   93.28%
==========================================================
  Files                             90       90
  Lines                          11912    11912
  Branches                       11912    11912
==========================================================
  Hits                           11112    11112
  Misses                           699      699
  Partials                         101      101

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


Expose secret eviction duration as environment var

Please provide a description for what this PR is for.

Expose SecretEvictionDuration as env variable like other nodeagent params
Ensure EvictionDuration > TTL - GraceRotationDuration otherwise
secrets are removed before they are refreshed

And to help us figure out who should review this PR, please
put an X in all the areas that this PR affects.
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[x] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure

Hi @pbohman. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@googlebot I fixed it.


🐛 Bug Report(kubernetes-plugin):  Unable to fetch native k8s resources which doesn't have group

📜 Description
Unable to fetch native k8s resources which don't have a group like ReplicationController
  customResources:
    - group: ''
      apiVersion: 'v1'
      plural: 'replicationcontrollers'

ReplicationController is not in the default object types https://backstage.io/docs/features/kubernetes/configuration/#objecttypes-optional and in customResources group is required field so can't pass empty strip or skip it.
👍 Expected behavior
Should be able to fetch native k8s resources which don't have group
👎 Actual Behavior with Screenshots
on yarn dev it shows error

👟 Reproduction steps

Setup backstage k8s plugin (install and configure)
in app-config.yaml provide ReplicationController in customResources as below

  customResources:
    - group: ''
      apiVersion: 'v1'
      plural: 'replicationcontrollers'

yarn dev

📃 Provide the context for the Bug.
I want to show additional resources on Kubernetes page.
🖥 Your Environment

NodeJS Version (v14): v16
Operating System and Version (e.g. Ubuntu 14.04): macos Ventura

👀 Have you spent some time to check if this bug has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
Yes I am willing to submit a PR!

Maybe this makes more sense as a feature request for objectTypes to allow specifying additional types beyond the default? In #15761 this note in the docs was added:

it's currently not supported to fetch object types other than the ones specified in the default types.

So we've got some evidence that @namco1992 at least was thinking about this capability too. @mclarke47 wdyt?

SGTM


When case of the value of an existing host label is changed , label is lost.

Rancher Versions: Build from master
Steps to reproduce the problem:
Edit host and set label  as YELLO=VALUE
Edit host and  edit the existing value of the label  YELLO to lower case  as YELLO=value
After this label "YELLO" is lost in  host_label_map.
mysql> select label.key, label.value from label where id in (select label_id from host_label_map where host_id=3 and removed is null);
+--------------------------------------+----------------------+
| key                                  | value                |
+--------------------------------------+----------------------+
| io.rancher.host.agent_image          | rancher/agent:v1.2.0 |
| io.rancher.host.docker_version       | 1.13                 |
| io.rancher.host.linux_kernel_version | 4.4                  |
| io.rancher.scheduler.require_any     | test1=value3         |
| YELLO                                | VALUE                |
+--------------------------------------+----------------------+
5 rows in set (0.00 sec)

mysql> select label.key, label.value from label where id in (select label_id from host_label_map where host_id=3 and removed is null);
+--------------------------------------+----------------------+
| key                                  | value                |
+--------------------------------------+----------------------+
| io.rancher.host.agent_image          | rancher/agent:v1.2.0 |
| io.rancher.host.docker_version       | 1.13                 |
| io.rancher.host.linux_kernel_version | 4.4                  |
| io.rancher.scheduler.require_any     | test1=value3         |
+--------------------------------------+----------------------+
4 rows in set (0.00 sec)

Tested with build from master.
When case of the value of an existing host label is changed , labels are not lost.


Error after adding the gradle dependancy

After adding the dependancy into gradle file:
commonMain.dependencies {
implementation("network.chaintech:compose-multiplatform-media-player:1.0.11")
}
the sync works fine, but when I try to run the app I get this error with all the resources already used in the project:
/composeapp/generated/resources/Drawable0.kt:14:67 No value passed for parameter 'offset'
/composeapp/generated/resources/Drawable0.kt:14:67 No value passed for parameter 'size'
I'm using the resources library: implementation(compose.components.resources)

After updating to kotlin 2.0.0 and adding the new required compose-compiler library its working properly.


Update battle_status on spectatorCount changes

send UPDATEBATTLEINFO to all server users, added condition: changed_spectator_count
avoid duplicate sending of UPDATEBATTLEINFO to battle users

@Teifion I rolled back the 2nd change, since this is just luxus.
Can we merge it like this first and look for optimizations later ?

@FIr3baL sorry for the lag there, I basically had a day of no coding so didn't look at this. It's merged and I'll do a release with it on Monday.


Does the user need to eat all keep alive messages?

When user keep alive a lease, the function KeepAlive returns a channel of keep alive messages. From the code in Session, it creates a net go-routine and eats all messages.
Is it necessary for the lease keep alive to work properly?
I am under impression that it does not have to
according to the code here, since the implementation just discard the message if the channel is full.
Just want to confirm if I need to add extra code to eat all the messages every time I create a lease and keep alive it.

AFIK, you virtually must drain messages from the channel returned by KeepAlive if the code has been not changed since #7446. Otherwise, keep alive messages are sent every 500ms to the server, as I reported in the issue.

@yudai Thanks for the response! Your issue is very informative!
A side question, do your application actually care the result coming from the keep alive response channel? I am curious about the use case, maybe I could learn something to improve the program that I am currently working.
Thanks!
Helin

In my code, there some code like for range keepAliveCh {}.
I actually don't have any use case that requires to check the content of messages to this channel so far.

i think the question is well answered. thanks @yudai. closing.


Some suggestions from Chrome Lighthouse

Full report.pdf
Auditing reports generated by Chrome Lighthouse.

IMO, since this is a dashboard, rendering time is relatively not so important. So is a11y.

TiDB Dashboard is now also served directly to Internet end users in TiDB Cloud. Maybe Lighthouse advices can be considered. For example, it would be very bad if our asset size grows very large, which will lead to an uncomfortable experience in cloud.


cannot link Java class com .zaxxer.hikari.HikariDataSource

Hi,

Version of Logstash used:  5.3.2
Database engine & version you're connecting to: oracle 11g
Recieved the below error while starting logstash eventhough ojdbc6.jar,HikariCP 2.6.1 & sl4j-impl 2.6.2
@output_class=LogStash::Outputs::Jdbc>", :error=>"cannot link Java class com
.zaxxer.hikari.HikariDataSource, probable missing dependency: org/slf4j/LoggerFa
ctory"}
09:52:23.281 [[main]-pipeline-manager] ERROR logstash.agent - Pipeline aborted d
ue to error {:exception=>#<NameError: cannot link Java class com.zaxxer.hikari.H
ikariDataSource, probable missing dependency: org/slf4j/LoggerFactory>, :backtra

Thanks

Expected & Actual Behavior

Your Environment

Version of plugin used:
Version of Logstash used:
Database engine & version you're connecting to:
Have you checked you've met the Logstash requirements for Java versions?:

What version of the plugin are you using please? Latest? Or something older? Did you install it via the logstash-plugin command (please tell me you didn't just clone the repo/download it as a zip).
I've not yet had the time to test Logstsh 5.3 myself, but

We downloaded the master version as a zip,edited gem file as gem "logstash-output-jdbc", :Path => "./logstash-output-jdbc" and installed logstash-plugin install --no-verify
Can you please give the log-stash version in which you have tested?
And can you give the list of jars to be placed in vendor/jdbc/jar?

We downloaded the master version as a zip

I would not suggest doing that, since you're just creating more work for yourself and me. Just use the logstash-plugin command.
If there is some reason you can't use the logstash-plugin command, then you need the jars and their dependencies listed in https://github.com/theangryangel/logstash-output-jdbc/blob/master/logstash-output-jdbc.gemspec#L29
You can either install them by hand, or use rake install_jars task from the Rakefile.


Meta tags added

Pull Request Template
Description
Added important meta tags like description, keywords, open graph, etc to increase the SEO of the website.
Fixes #157
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] My changes generate no new warnings
[x] I have checked my code and corrected any misspellings

@Arnabdaz Done adding the image url


fix(controller): only load latest config

Adapts deis/deis#5028 to Deis Workflow controller v2. All credit goes to @jgmize.

Current coverage is 85.46% (diff: 100%)

Merging #936 into master will increase coverage by 0.08%

@@             master       #936   diff @@
==========================================
  Files            30         30
  Lines          3050       3062    +12
  Methods           0          0
  Messages          0          0
  Branches        512        513     +1
==========================================
+ Hits           2604       2617    +13
  Misses          295        295
+ Partials        151        150     -1

Powered by Codecov. Last update 6d6a10e...1c7b09f


API link doesn't go anywhere

The API link on https://www.metaculus.com/notebooks/28734/ doesn't go anywhere:

Also on that page, there's an issue with this link:

Thanks! fixed.


Added member page

Fixes #

Fined member page
Added photos
Added SIG sections
Fixed SIG page path

Proposed Changes

Team members

@PriyaaIyer @Subaharish  Pull and fix the duplication

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 1

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 1

See the complete overview on Codacy


documentation should be explicit about the custom exception constructor contract

Documentation about custom exception de-serialization - using deserialized error response bodies - does not state anything about its contract:
class ComplexPojoException extends Exception {

    @FeignExceptionConstructor
    public ComplexPojoException(GithubExceptionResponse body) {

    }
}

it should be documented that at setup-time, feign will test the exception generators using a null body and that such a test should appear in the constructor:
class ComplexPojoException extends Exception {

    @FeignExceptionConstructor
    public ComplexPojoException(GithubExceptionResponse body) {
        if (body != null) {
            // extract data
        } else {
            // fallback code
        }
    }
}

done :)

in which cases I can get null in body?
if (body != null) {
            // extract data

@hellboy81 in 2 cases:

If there is actually no body in the response (even with an error code). This can (and in many different API's, has) happened
on startup, the exception generators try to test out that it can actually create exceptions. For those Exceptions that have a body, it basically sends null (since this is meant to be a valid value) to validate the constructor works. This was thought of in terms of fail-fast.


starts_at doesn't behave as expected

I'm using ex_cycle and when checking the occurrences of  a rule with a start date, the starts_at doesn't look like it's being included in the calculations. Am I using this wrong, or is this a bug?
Repo:
    test "occurrences begin after starts_at date" do
      datetimes =
        ExCycle.new()
        |> ExCycle.add_rule(:daily, excluded_dates: [~D[2024-01-03]], starts_at: ~D[2024-01-02])
        |> ExCycle.occurrences(~D[2024-01-01])
        |> Enum.take(2)

      assert datetimes == [~N[2024-01-02 00:00:00], ~N[2024-01-04 00:00:00]]
    end

Results in the following failure:
     Assertion with == failed
     code:  assert datetimes == [~N"2024-01-02 00:00:00", ~N"2024-01-04 00:00:00"]
     left:  [~N[2024-01-01 00:00:00], ~N[2024-01-02 00:00:00]]
     right: [~N[2024-01-02 00:00:00], ~N[2024-01-04 00:00:00]]

Hello, yeah I think the rule's starts_at must be used instead of the cycle's starts_at

BTW, thanks for the given test. Really appreciated.
I'm fixing it right now, you can expect a new version today

Fixed in 0.5.8 thanks for your contribution ;)

No problem, thank you for the fix and release! It's working great.


set text on editor

Hello Everyone
I am unable to set text on the editor , i saved some description and i wanted t edit that so i have to set text n editor then e can edit that text ,, could anyone help me

I also got this problem.

there's setHtml() function where you can set that html code inside editor!


Anime Extentions & Anime Backup

I created backup right before uninstalling previous update(I had to for some reason)..... then I installed the latest update, I imported the backup file.....except anime almost every thing was restored.....and then I was about to install the anime extentions...but there was nothing to install.....even refreshing did not helped.....there's just a blank page....😔

hello, im facing the same issue. the manga extensions are working fine but the anime extensions seems to be stopped working and there are no extension available to be installed.

Hello for a certain anime like the master of ragnarok and blesser of einherjar the 1st episode doesn't load can you take a look at it plz and some extensions a re loading up.

Same issue. It seems like only the anime section of the app particularly the 'anime sources & anime extensions' vanished from the app. Despite of that every other parts of the app is working well.


A bug in shushing emoji while digging through Android P's Emojis. (2018 emojis)

While i was deleting the yellow circle of emoji, i found out that i discovered the secret.

Did you know?

The eyebrows... Where did it come from???

The eyebrows... Where did it come from???

why are you using scratch to make the emojis 💀
just use corelvector or any other free svg app

The eyebrows... Where did it come from???

why are you using scratch to make the emojis 💀 just use corelvector or any other free svg app

cuz scratch is my programming language and im editing the emoji on it too easy for website


Request to add an additional DNS provider - https://securedns.eu/

It would be absolutely cool if SecureDNS could be included as an additional selectable DNS provider. SecureDNS could also be used directly as an adblocker, by using a corresponding tls-hostname - see here: https://securedns.eu/
Sorry if I post wrong here, but I'm new here and have not found another way ... and I´am just a enduser.
Thank you!

Hi there,
It's added, simply set -e PROVIDER=securedns  😉
On a side note, I am working on a related project updated which updates periodically a list of IP addresses and hostnames from various lists and builds separate block lists (Ads, Malicious, NSA, etc.). This Docker image bundles lists built from this updated repository, so you might be able to complement securedns with additional block lists and Unbound.
But this updated currently runs with shell scripting which is terrible for advanced stuff, but I should release a Go program replacing it soon. For example, the new version now collects malicious hostnames (about 27000) and look them all up (in parallel 😎) to get their IP addresses and block these too.
So it's gonna rock security wise 💯  I will post back once it's done 👍

Thank you for your support and your ideas! Great job, keep it up 👍🏻👏🏻


Support create from template Schema

First, thanks for nice works. 🙏
I found out we do not have support templates route at the moment, it would be great if easypanel.js also support it:
api/trpc/templates.createFromSchema

Hi!
Thank you for your feedback this function has been added to ServiceManager and named createFromSchema
you can install and use new version


kprove: no int_max in Z3

I tried to run kprove on the following:
module LEFTPAD-SPEC
    imports LAMBDA

    rule
        (leftpad (< N:Int , < C:String , Str:String > >))
        =>
        ?NewStr:String
    requires lengthString(C) ==Int 1
    ensures lengthString(?NewStr) ==Int maxInt(N, lengthString(Str))
endmodule

LAMBDA is the tutorial langauge with a couple of minor extensions (strings, pairs). I put it on pastebin here, but I don't think it's actually relevant to the error.
K gives me the following error:
[Error] Critical: Z3 crashed on input query:
(declare-fun andInt (Int Int) Int)
(declare-fun shlInt (Int Int) Int)
(declare-fun shrInt (Int Int) Int)
(declare-fun xorInt (Int Int) Int)
(declare-fun orInt (Int Int) Int)
(declare-fun notInt (Int) Int)
(declare-fun |N_131| () Int)
(declare-fun |_257| () Int)
(declare-fun |_258| () Int)
(assert (and
  (and
	(= (<= |N_131| _257) true)
	(= _258 1))
  (not (and
	(= _257 (int_max |N_131| _257))))
))
result:
(error "line 17 column 30: unknown function/constant int_max")

I assume this is because of the definition of maxInt in domains.k. I resolved my problem by using the #if_#then_#else_#fi, not sure if there's a better way.
Also, there's another issue with lengthString not having an SMT translation at all, not sure if that's a limitation or just something that just never got defined.

Add option --smt-prelude evm.smt2 where evm.smt2 is this: https://github.com/runtimeverification/verified-smart-contracts/blob/master/resources/evm.smt2
By the way you are running Java backend, not Haskell.

It's true you can add an smt prelude (although I would recommend the one in include/z3/basic.smt2 in the k repo instead), but we will also have a better fix than that shortly that will make such a command line flag not required.


Invert dependency from business logic to DB

Some thoughts:

use sqlalchemy imperative mapping
use registry pattern

Why? Because I want to be able to switch database with minimum changes. For example, I want to build similar template for MongoDB

I decided that it's not worth it to invert dependency, because it requires a lot of efforts, more than rewriting a service with another database


Mm/nth dow

This addresses the issues raised by @tfoertsch in his review of the branch pull request.  It also has a bug fix (we could not previously get the "nth Sunday" because it was false as "day 0") and some test formatting changes for the object methods test file.
Note that this is a potentially breaking change, since it uses gmtime over the old gmtime_nocheck.  Frankly, I think it's better to break on bad dates (and take the minor time penalty associated with checking) than to assume they are correct.

Thank you Matt!