Can we add "readEntityDetails" to approved function calls.

There is some new functionality that list available entities. Any way we can get this added to the list?
readEntityDetails
https://developer.intacct.com/api/company-console/entities/

@drc37 thanks for reaching out!
I don't have any current, personal need for it, but I'm certainly happy to look at a PR.
Should be as easy as adding here:
https://github.com/privateprep/intacct-ruby/blob/master/lib/intacct_ruby/function.rb#L9-L15
https://github.com/privateprep/intacct-ruby/blob/master/README.md

Sounds good. I will create one tomorrow.
David Cook
269-370-4760
On May 20, 2019 at 5:23:33 PM, Daniel Powell<EMAIL_ADDRESS>wrote:
@drc37 https://github.com/drc37 thanks for reaching out!
I don't have any current, personal need for it, but I'm certainly happy to
look at a PR.
Should be as easy as adding here:
https://github.com/privateprep/intacct-ruby/blob/master/lib/intacct_ruby/function.rb#L9-L15
https://github.com/privateprep/intacct-ruby/blob/master/README.md
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/privateprep/intacct-ruby/issues/27?email_source=notifications&email_token=AABHV3KLPC53IFAZBIVZNULPWMXHHA5CNFSM4HOGEN52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODV2KMXY#issuecomment-494184031,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABHV3ONCHZD4RKF7HP2IL3PWMXHHANCNFSM4HOGEN5Q
.

We are no longer maintaining this project, and we will be archiving the repo. As such we are closing all issues, and will update the readme accordingly.
Apologies for any inconvenience this may cause!


Onboarding WPF's Grid control

What does the pull request do?

Ports the Grid control from dotnet/wpf repository.
What is the updated/expected behavior with this PR?

Grid's behavior should now be inline with WPF's, hence fixing some long-running issues with our own Grid control.
Checklist

[x] Added unit tests (if possible)?

Fixed issues
Fixes #2138 (i tested the described scenarios by @donandren but this needs another pair of eyes).

WPF's Grid running on ControlCatalog (still broken though)

Getting there! (calendar broke for some reason)

I don't think we should add class handlers for column, row attached to each visual. Instead do this when the property is attached to a visual.

@Gillibald Yes, thats the right way. There's still some temporary hacks and that is one of 'em so thanks for the reminder :smile:

ShowGridLines now working

Almost all features but SharedSizeScopes is working now :smile:

Grid is now fully-functional :label:

Great job! I hope all of those small bugs of the old Grid implementation will be gone now.

@AvaloniaUI/core please don't update this branch to master until this second phase is done.

Ah, seems there's a failing test?


[bug] Application Updater Process Can't Restart - Tauri API error: Cross-device link (os error 18)

Describe the bug
I'm using the application updater with a static JSON file.
{
  "version": "v0.4.0",
  "platforms": {
    "darwin-x86_64": {
      "signature": "something",
      "url": "https://something.com/macos/AppName.app.tar.gz"
    },
    "darwin-aarch64": {
      "signature": "something",
      "url": "https://something.com/macos/AppName.app.tar.gz"
    }
  }
}

The app uses the built in dialog to prompt to install and restart the application. The updater status reaches "DONE" in dev mode:
Downloaded 16384 of Some(7682688)
Downloaded 16384 of Some(7682688)
Downloaded 14469 of Some(7682688)
Update has been downloaded!
App has been updated

After this, if I confirm that I would like to restart the application, I get the following error in the terminal, and the update is never applied:
thread ‘tokio-runtime-worker’ panicked at ‘application failed to start: Os { code: 2, kind: NotFound, message: “No such file or directory” }

Which points to this function in the tauri api/process.rs:
pub fn restart(env: &Env) {
  use std::process::{exit, Command};

  if let Ok(path) = current_binary(env) {
    Command::new(path)
      .args(&env.args)
      .spawn()
      .expect("application failed to start");
  }

  exit(0);
}

I tried to offload the updater functionality to the JavaScript side to see if I could get more information and built the app. Logging errors to the console, I also saw this error when built with an updater status of "DOWNLOADED" and then "ERROR":
Tauri API error: Cross-device link (os error 18)

How do I get the restart and update functionality to be applied?
Reproduction

Set tauri.conf.json to have an active updater with appropriate endpoints; Build the app with appropriate environment variables as noted in the documentation.
Run the application locally and it will get the static JSON file containing version and platform information for the update (at this point the app prompts to update).
Confirm you would like to update.
Confirm to restart the application (this triggers the error).

Expected behavior
I expect the application to restart successfully and apply the update.
Platform and versions

MacOS Monterey
version 12.3

> tauri info

Environment
  › OS: Mac OS 12.3.0 X64
  › Node.js: 18.12.1
  › npm: 8.19.2
  › pnpm: Not installed!
  › yarn: 1.22.19
  › rustup: 1.25.1
  › rustc: 1.65.0
  › cargo: 1.65.0
  › Rust toolchain: stable-aarch64-apple-darwin

Packages
  › @tauri-apps/cli [NPM]: 1.2.3
  › @tauri-apps/api [NPM]: 1.2.0
  › tauri [RUST]: 1.2.1,
  › tauri-build [RUST]: 1.2.1,
  › tao [RUST]: 0.15.6,
  › wry [RUST]: 0.22.5,

App
  › framework: React
  › bundler: Vite

App directory structure
  ├─ ui
  ├─ tauri
  ├─ node_modules
  ├─ tests
  ├─ .github
  ├─ .git

Stack trace
__pthread_deallocate
thread 'tokio-runtime-worker' panicked at 'application failed to start: Os { code: 2, kind: NotFound, message: "No such file or directory" }'

Additional context
I saw this issue here regarding setting a tmp dir for Linux, so maybe it's related. However, I'm using Mac for now.
Also, the build process generates a tar.gz called <app_name>.app.tar.gz, detailed here
However this line of code in the core.rs indicates that the tar.gz MUST have the arch, even though tauri only generates the .dmg with the version and the arch, and not the tar.gz:
https://github.com/tauri-apps/tauri/blob/076e1a81a50468e3dfb34ae9ca7e77c5e1758daa/core/tauri/src/updater/core.rs#L832
// MacOS
// ### Expected structure:
// ├── [AppName]_[version]_x64.app.tar.gz       # GZ generated by tauri-bundler
// │   └──[AppName].app                         # Main application
// │      └── Contents                          # Application contents...

Could this be related to by it's giving a Not Found error?
The logs show that it successfully got the tar.gz:
[2023-06-08][20:59:16][attohttpc][DEBUG] GET /<updater>.json HTTP/1.1
[2023-06-08][20:59:16][attohttpc][DEBUG] creating a length body reader
[2023-06-08][20:59:16][attohttpc][DEBUG] creating plain reader
[2023-06-08][20:59:16][attohttpc][DEBUG] status code 200
[2023-06-08][20:59:16][attohttpc][DEBUG] trying to connect to
[2023-06-08][20:59:16][attohttpc][DEBUG] trying to connect to
[2023-06-08][20:59:16][attohttpc][DEBUG] successfully connected to , took 17ms
[2023-06-08][20:59:16][attohttpc][DEBUG] GET /macos/AppName.app.tar.gz HTTP/1.1
[2023-06-08][20:59:16][attohttpc][DEBUG] creating a length body reader
[2023-06-08][20:59:16][attohttpc][DEBUG] creating plain reader
[2023-06-08][20:59:16][attohttpc][DEBUG] status code 200

I THINK I found the cause. It looks like the macos bundler doesn't include the version and arch in the tar.gz on build:
https://github.com/tauri-apps/tauri/blob/076e1a81a50468e3dfb34ae9ca7e77c5e1758daa/tooling/bundler/src/bundle/updater_bundle.rs#L89
but the updater expects the version and arch with the named tar.gz file:
https://github.com/tauri-apps/tauri/blob/076e1a81a50468e3dfb34ae9ca7e77c5e1758daa/core/tauri/src/updater/core.rs#L832

Thanks for looking into it! I highly doubt that the name is the issue though, the updater shouldn't actually care/know about it. Also tauri-action which is pretty widely used, changes the default name and no issues were reported about it yet.
No idea about the cross-device link error, but the No such file or directory error most often means you're not running an installed app (like just the binary in target/ or tauri dev), could that be the case here too?

@FabianLars Thank you for getting back to me! I realized I get NotFound when it's in dev, but I still get the cross link error with the installed app. Manually changing the tar.gz name to have the version and arch did fix the problem, but I'm not sure the best solution for an installed / prod application.

Do you have an example of the tauri-action updating the updater name?

It automatically adds the arch here so that the x64 and arm artifacts don't overwrite each other. -> If you use the action for your own project and need it to rename the assets to include the version then you'll have to use a custom upload action until https://github.com/tauri-apps/tauri-action/issues/215 lands.
Also i just checked again, and i've seen both, the .gz without arch/version and the one with just the app name, working fine so i'm really confused what's going on here 😅
P.S. Did you ever try updating the Tauri packages to the latest versions? (though i'm fairly sure there are no relevant changes but who knows)

@FabianLars If you don't use a tauri-action and just use the tauri build, I think that's where we might see the discrepancy?
I did not update the packages, but I'm thinking it might have breaking changes if it's on v2 right now.

If you don't use a tauri-action and just use the tauri build, I think that's where we might see the discrepancy?

Like i said, i saw both working somewhat recently. And the action didn't include the arch until fairly recently (v0.4) too. I just checked again and the updater indeed doesn't actually see the name of the tar, afaik it extracts it directly from the download without saving it to disk. That said, i wonder if this somehow could be a similar problem to 4500 since its fix was only applied to Linux (though i don't see how a different package name would affect that)
-> On that note, do you use multiple disks or something?

I did not update the packages, but I'm thinking it might have breaking changes if it's on v2 right now.

I'm only talking about 1.3, there shouldn't be breaking changes between 1.2 and 1.3. v2 is still highly unstable (alpha name checks out)

Good/Bad news. I'm also seeing this error in a similar situation. Just sorted out how to get files served to my updater (dev code), it downloads fine and then can't restart. Same exact err
thread 'tokio-runtime-worker' panicked at 'application failed to start: Os { code: 2, kind: NotFound, message: "No such file or directory" }', /Users/ultamatt/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tauri-1.5.1/src/api/process.rs:88:8

Sooo I'm gonna sleep on it and try again tomorrow.


[Android Studio support] Gradle build issue after creating.

After creating new native android module, I opened android folder using Android Studio. It added missing gradle files and started the sync process and below error occurs.
INFO: API 'variant.getJavaCompile()' is obsolete and has been replaced with 'variant.getJavaCompileProvider()'.
It will be removed at the end of 2019.

After editing android/build.gradle to below it get fixed.
  android.libraryVariants.all { variant ->
        def name = variant.name.capitalize()
        task "jar${name}"(type: Jar, dependsOn: variant.javaCompileProvider) {
            from variant.javaCompileProvider.get().destinationDir
        }
    }

Does this mean that you tried to open a generated module with Android Studio?

@brodybits yes. I created Android only native module and open android folder from Android Studio and it added a gradle scripts and started to sync.

Thanks. Marked as an enhancement as I am not yet motivated to support this case.

The recommended approach is to generate the module with the example, then open the example project with Android Studio. You would likely have to copy artifacts between example/node_modules and android source tree if you develop in this manner.
Using Yarn workspaces (#128) may help us out.
Priority feature development with high-priority private support is available for commercial users, please contact<EMAIL_ADDRESS>for more details.

This may be resolved by PR #135 in the 0.11.0 release.

@brodybits Any plans to make old version build projects to upgrade to new versions?

Any plans to make old version build projects to upgrade to new versions?

See #19, with workaround upgrade procedure now documented. I would appreciate if you would report whether or not this build issue is resolved by the upgrade.
I hope to make the upgrade more automatic, no promise of timeline. Priority is given to commercial customers, please contact<EMAIL_ADDRESS>for more information.

This is unrelated to Android Studio.
I see the same warning as @iamchathu and I don't use Android Studio.
I upgraded my module to RN 0.61 by creating a new module with this tool, then merging with the previous code. When I use my module in an app and compile with
-Pandroid.debug.obsoleteApi=true I get this warning:
> Configure project :react-native-palette
WARNING: API 'variant.getJavaCompile()' is obsolete and has been replaced with 'variant.getJavaCompileProvider()'.
It will be removed at the end of 2019.
For more information, see https://d.android.com/r/tools/task-configuration-avoidance.
REASON: Called from: /Users/maint/prj/malas/upgrade/node_modules/react-native-palette/android/build.gradle:121
WARNING: Debugging obsolete API calls can take time during configuration. It's recommended to not keep it on at all times.

The offending line 121 is here. It is an exact copy of the line from the new library created with create-react-native-module

Should be fixed now, I just merged PR #194 and published a new release.
In case of any further issues I would really appreciate a new issue with the standard minimal, reproducible example ([1]).
[1] https://stackoverflow.com/help/minimal-reproducible-example


TensorCPU planar or interleaved?

Hi,
I'm trying to map boost::gil views pointers into TensorCPU. So let's take an example of an RGB image.
I just wanted to know: are caffe2 tensors defined as planar:
RRRR
RRRR
RRRR
GGGG
GGGG
BBBB
BBBB
BBBB
Or interleaved:
RGBRGBRGBRGB
RGBRGBRGBRGB
RGBRGBRGBRGB
?
I guess it's planar, but just want to be sure.
This is important to know especially for the convolutions.

Caffe2 supports both, we call "planar" format NCHW and "interleaved" format - NHWC. By default, all CNN operators (convolution, deconvolution, pooling, etc) expect NCHW. If you want to work with NHWC, add order: NHWC argument to CNN operators.

Ok, thanks.
I see in this file +226:
https://github.com/caffe2/caffe2/blob/master/caffe2/python/operator_test/conv_test.py
a check + transpose:
        if order == "NCHW":
            X = X.transpose((0, 3, 1, 2))
            w = w.transpose((0, 3, 1, 2))

Does that means that planar is slower?
Thanks.


Added docs for bevy_transform

Objective
bevy_transform needed documentation and warn(missing_docs) as requested by #3492
Solution
warn(missing_docs) was activated and documentation was added to cover the crate

The doc comments could use a few more links, and some of the changes here would break with https://github.com/bevyengine/bevy/pull/3457 without backquotes

The documentation looks great. I only found some smaller things that need to be fixed.
One thing I noticed is that you didn't highlight/link to the documented types using [``]. I added this in two suggestions I made, but it would be great to have them used as much as possible in my opinion. It just helps the user navigate on docs.rs.

The doc comments could use a few more links, and some of the changes here would break with #3457 without backquotes

I updated linking in the docs, I might have missed some places

Does the following command run through fine? I know that you don't like that we are adding the clippy::doc_markdownlint (see #3492), but it would be nice if we don't create any issues when we activate it later on:
cargo clippy -p bevy_transform --no-deps --all-targets --all-features -- -D warnings -A clippy::type_complexity -W clippy::doc_markdown

I did check it against that yes

Why does one of the commands have pub fields and the others don't?

AddChild was added recently, with the goal of being able to be executed without going through a Commands buffer. Fields needed to be pub as it was to run it from another Bevy crate. I asked if there was a reason to keep the fields not pub but no answer 🙂
I think most commands should have pub fields, as it's possible to add commands directly but most are not possible to build... but that's for another PR

bors r+


Support indent with 2 spaces

It might be helpful if bake understands Bakefiles indented with 2 spaces.
Fixes #19

I think I want to standardize on four spaces.

I think I want to standardize on four spaces.

I was just hit by this when testing bake for the first time. Standardizing on a fixed number of spaces is fine, but then bake should issue an error when it sees lines that are not. The current behavior, where it just executes all tasks is extremely confusing and very surprising.


Fix path for namespaced translation overrides

This change fixes #8302

Changing the behaviour on a patch release should be avoided.

Please send to master.


Fix wrong argument supplied to _identity_op()

Summary
This fixes a typo in the CommutationChecker where 2**num_qubits was passed to _identity_op instead of num_qubits.
Details and comments
Fixes #9197.

 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.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
4 unchanged lines in 2 files lost coverage.
Overall coverage increased (+0.04%) to 84.548%

Files with Coverage Reduction
New Missed Lines
%

qiskit/extensions/quantum_initializer/squ.py
2
79.78%

src/sabre_swap/layer.rs
2
98.95%

Totals

Change from base Build<PHONE_NUMBER>:
0.04%

Covered Lines:
62785

Relevant Lines:
74260

💛  - Coveralls

Okay, is there any naming convention for these test cases? And I guess all the methods in the QiskitTestCase are called automatically so I can simply add a new method?

Sorry for the delay in responding here.  As long as the method name starts with test_ (and doesn't clash with another), yeah, it gets called automatically - QiskitTestCase is a subclass of Python's built-in unittest.TestCase, so all the assertion methods on those classes should work as well.

Hi, I didn't get to work on this any sooner. I now added a simple unit test and release note. I wanted to merge the upstream changes to my repo to be able to push my changes. Apparently I pressed the wrong button now, sorry for that.
I messed something up on my local repo, trying to get that fixed.

A "detached HEAD" state in git means you've just got a commit checked out that isn't the end point of any branch.  If you've not got any changes in your working directory, you can just git checkout <branch> where <branch> is wherever you want to get back to.
If you've got the changes you want to push in your local copy right now, but git is saying weird things, then you might want to try copying the files with changes in to somewhere safe, then running
git fetch origin
git checkout bug-9197-fix
git merge origin/bug-9197-fix

Ideally this will just update your local branch with the changes that have happened to the remote on GitHub, and then you'll just be able to run git push to update GitHub with the changes you've made locally.  The point of copying the files is just so you don't lose your changes if something goes wrong.
Don't worry - there's nothing you can do that can break our side of things, and the worst that can possibly happen is that your branch gets too messed up, and then we can close this and you can just make a new pull request.

To unblock this since the same bug being fixed by this was reported again in #9693 I pushed up the test proposed by @jakelishman  and also added a release note.


New Device: Contact Sensor (window/door)

Describe your device
Contact Sensor (window/door) able to notify when the door is open or closed as to show the battery level

+1

How to do? Nothing find in Wiki.
Thanks
Mark

+1

Just to clarify, are we wanting a battery meter or a sensor that shows open/close?


using dbflow to access content provider from other app that using  dbflow

Hi
i want to know how to access content provider from one app to other app,in 2 app i use dbflow and i should access from app 1 to 2 database and from app 2 to 1 database , if just one app installed no access for others

this is not a dbflow question but a general ContentProvider question, which can go on stackoverflow.


Stopping random values generation has a UI mismatch with the displayed values

When clicking "stop generating" in the top left menu, if "display connectivity values" is checked it will continue to display values (not always, it's not too straightforward to replicate).
My assumption is that a thread might not be properly closed and keeps working in the background.

I am not able to replicate this. There is a delay between when samples are no longer generated and when the analysis is finished outputting RValues. This is due (I believe) to the fact that the analysis Window is quite long (3 seconds) so it takes a while for the analysis code to 'finish up' with what was already queued up from several seconds ago. Maybe this has nothing to do with your bug, but this is what I see.
I also see (if I start the sample generation again) that the first few values in the display window are all 1s. I think this is because the buffers don't get recreated when the data transmission breaks off. This is actually correct. Since the random sample generation is independent of the analysis process, the analysis process should not react to a scenario where the data input disappears. If there is some cruff in the output when the connection comes back, that is the best we can do.


refactor(pose_initializer): fix some items related to parameters

Description
Please see https://github.com/autowarefoundation/autoware.universe/pull/6342

Tests performed

Please see https://github.com/autowarefoundation/autoware.universe/pull/6342
Effects on system behavior

Please see https://github.com/autowarefoundation/autoware.universe/pull/6342
Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[x] I've confirmed the contribution guidelines.
[x] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.

After all checkboxes are checked, anyone who has write access can merge the PR.

This PR is obsolete & not necessary.


Support of IE11

Currently, the build contains some "eval" which prevent it from working with ie11.
Do you have a solution for it?
Or maybe we could change the build a bit. I'm willing to make a pull request if you have some suggestions.

Hey @arnaudlewis, thanks for bringing it up.
I've got it working in IE11 (https://pegjs.org/development/try), and the Benchmark Suite is also running in IE11 but I can't get the Spec Suite running because the dependencies don't support IE11 🤣

Thanks for the quick response @futagoza, can you just tell me when it's gonna be released on npm?

Any news on that?


Issue #151 No service is created for acceptor when "expose:false"

The bug is true for connectors too.
(ENTMQBR-6083)

@gtully thanks. I'm a bit confused too. :) particularly what's the use-case for connectors, I'm thinking connectors imply some sort of ports that user can connect to. so we also expose them.


[Action] Add actions to replace TAOS-CI

Add actions to replace TAOS-CI
*Commit are splitted to avoid git push error due to large size of commit.
Signed-off-by: Gichan Jang<EMAIL_ADDRESS>**Self evaluation:**1. Build test: [ ]Passed [ ]Failed []Skipped
2. Run test: [ ]Passed [ ]Failed []Skipped

:memo: TAOS-CI Version: 1.5.20200925. Thank you for submitting PR #226. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://ci.nnstreamer.ai/.

:octocat: cibot: @gichan-jang, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://ci.nnstreamer.ai/nnstreamer-edge/ci/repo-workers/pr-checker/226-202412201100050.67789506912231-db07983b65cc3a0e1bfe2cc85887e293eb7b1d93/.


Allow prepended zeroes in toInt()

I updated the isInt() method so it treats numeric strings with prepended zeroes as valid integers. Since the parseInt() function in JavaScript properly parses zero-prepended strings, it would make sense that the isInt() function would support it as well.
I'm curious if it might be better for the isInt() function to check for integer values by using parseInt() and checking whether it returns NaN. That way it's ensured that the isInt() method will always validate integers that can properly be parsed by toInt() (or rather, by parseInt() by proxy).

FYI, I tried running the tests and there are failing tests that are unrelated to this PR. They mostly have to do with the no-control-regex lint validation in isAscii(), isEmail(), and isMultibyte().
I can fix those in this pull request as well if you want, or I could create a new pull request for those.

This is a breaking change, so probably worth controlling it with an option and leaving the default behavior as-is, e.g.
> validator.isInt('01');
false
> validator.isInt('01', {allow_leading_zeroes: true});
true

I can fix those in this pull request as well if you want, or I could create a new pull request for those.

Either would be great, thanks!

I'm fine with controlling this with an option if you'd rather not have to bump the major version just to account for the breaking change, but just to throw out my 2 cents on why I would dissent to that:
I feel that the default behavior of not accepting leading zeroes is a bug, not a feature that should be favored as the default. Because a value with leading zeroes is a valid integer, the default behavior should be to allow them, with the option to disallow them.
One argument against allowing leading zeroes is that in some cases they are used to denote octal values (e.g. 010 when parsed as an octal is 8 in decimal). However, I feel this is not a compelling argument since that use-case doesn't apply here as the user is explicitly passing the value to functions that deal with integers and wouldn't expect to need to disambiguate it from an octal value.
Also, just so I understand the historical reasons for this, what was the initial justification for not accepting leading zeroes?

Coverage remained the same at 99.087% when pulling f624d4641198af87e5d5bba12eca0f2bdac6a8f4 on theartoflogic:master into 0882fa4694db91d914e05ccf93f8c42d1a4212f7 on chriso:master.

To fix the broken pre-tests I disabled some no-control-regex eslint checks. I think that is valid for the isAscii() and isMultibyte() functions, but I'm not so sure about the isEmail() function. I don't have time right now to dissect the complex regex statements for the isEmail() function, but if you think a better route would be to update the regex statements to remove control characters from the hex ranges there then I could look into doing that too.
Although, I'm not up to speed on the evolution of those particular regex statements to validate emails, so there might be a valid reason control characters are allowed there.

Coverage increased (+0.003%) to 99.09% when pulling a3e3880203ec17f65488dfdc500db3d85d5d0975 on theartoflogic:master into 0882fa4694db91d914e05ccf93f8c42d1a4212f7 on chriso:master.

The regular expression in the very first commit of the library was /^(?:0|[1-9][0-9]*)$/. It was 5+ years ago so I can't recall exactly, but I don't think I made a conscious decision to reject leading zeroes, it was probably just an oversight.
I think you're right that we should accept leading zeroes by default, but since this is the first time the issue has come up in that entire time I don't think it's worth bumping a major for immediately. I've created a wiki page to collect breaking changes between v5 and v6: https://github.com/chriso/validator.js/wiki/Proposed-breaking-changes-for-v6
Also FYI parseInt is too lenient to be used in validation:
> parseInt('10.0')
10
> parseInt('10foo')
10

Although it might be useful to check whether the input string is a canonical int, e.g. input_str === parseInt(input_str).toString(), which I guess is close to what isInt() is doing now.

Disabling the no-control-regex is fine for now, thanks.

One more thing: can you update the README to show the allow_leading_zeroes option?

Coverage increased (+0.003%) to 99.09% when pulling 4923be5f650ecd94907259425d468c869dd77122 on theartoflogic:master into 0882fa4694db91d914e05ccf93f8c42d1a4212f7 on chriso:master.

Great, thanks.


Rewrite the stackle_app with Angular 4

Current front-end is written with AnguarJS. It is better to use Angular 4 fot the front end because then it will allow us to use Angular CLI which makes most of the work easy when deploying and building the app

@agentmilindu @psnmissaka I'm interested in this, can I start working here?

@agentmilindu @psnmissaka I'm interested in this, can I start working here?


WikiPage methods: visibility should be declared

Per coding guidelines. Same for the Wikimate constructor (all its other methods already have declarations).
Also, class & method opening braces could go on separate lines.

Oh interesting. I wonder if the auto-closing trick only works if the message is in the actual commit messages, not the PR title? Something to investigate further :)

Wondered about this too, that might well be the requirement.


Adding optional action button to the screens

Collating all the commits from Eyez-io, and getting it to compile with swift 3, version bump to 2.1.0

It's a collation of all the commits by @pleasantlight into one commit and can compile against swift 3.0 and latest xcode

@hari-tw thank you for contributing, but I think this action not generic enough to include it here.


Undulator Gaussian widget problem with monochromatic beam

When delta energy set to 0, the ray energy will be automatically set to 12.3984 keV (0.1 nm)

Fixed.


Update document site

This is a work in progress, but wanted to give folks a heads up!

Branding is NextAuth.js to reduce confusion with other software.
NB: Similar to Next.js, it remains NextAuth in React (and next-auth in URLs/file systems.

Have started to update docs, but still in progress!

Have updated project example, is much simpler now we have a documentation site. :D

Will start smashing bugs this weekend, after have worked on the docs for a bit more!

Oh man this looks so much better! I love the npm / github icons in the menu bar as well. I looked into doing this but couldnt find an easy way to do it. Great job ;)

Oh man this looks so much better! I love the npm / github icons in the menu bar as well. I looked into doing this but couldnt find an easy way to do it. Great job ;)

Thanks for creating the site! This is really great and so much easier to update!
I go the icons from looking round other Docusaurus sites!

Looks great! Nice work! But the authentications page are we keeping that one? I thought you wanted to avoid having to add configurations for all social providers?

Oh totally, I really like the way you did it! I should remove that page.
Thank you both for taking a look! Will follow up with smaller updates.


The Criterion project is broken after nanopb upgrade to 0.4.7

https://github.com/Snaipe/Criterion
===>  Building for criterion-2.4.1
[  1% 1/51] /usr/ports/devel/criterion/work/Criterion-2.4.1/src/protocol/gen-pb.py /usr/local/bin/protoc /usr/local/bin/protoc-gen-nanopb ../src/protocol/criterion.proto ../src/protocol/criterion.options /usr/ports/devel/criterion/work/Criterion-2.4.1/_build/src
FAILED: src/criterion.pb.c src/criterion.pb.h
/usr/ports/devel/criterion/work/Criterion-2.4.1/src/protocol/gen-pb.py /usr/local/bin/protoc /usr/local/bin/protoc-gen-nanopb ../src/protocol/criterion.proto ../src/protocol/criterion.options /usr/ports/devel/criterion/work/Criterion-2.4.1/_build/src
/usr/local/bin/protoc --plugin=protoc-gen-nanopb=/usr/local/bin/protoc-gen-nanopb -I../src/protocol --nanopb_out=-f ../src/protocol/criterion.options:/usr/ports/devel/criterion/work/Criterion-2.4.1/_build/src ../src/protocol/criterion.proto
Traceback (most recent call last):
  File "/usr/local/bin/protoc-gen-nanopb", line 7, in <module>
    from nanopb_generator import *
  File "/usr/local/bin/nanopb_generator.py", line 55, in <module>
    from proto import TemporaryDirectory
ImportError: cannot import name 'TemporaryDirectory' from 'proto' (unknown location)
--nanopb_out: protoc-gen-nanopb: Plugin failed with status code 1.
ninja: build stopped: subcommand failed.

Seems like duplicate of #841. I'll release 0.4.8 in a few weeks to fix that, once any other breakages have been discovered.

Hello!
The fix for #841 helps only a bit. Now we get:
[    9s] Traceback (most recent call last):
[    9s]   File "/usr/bin/protoc-gen-nanopb", line 7, in <module>
[    9s]     from nanopb_generator import *
[    9s]   File "/usr/bin/nanopb_generator.py", line 53, in <module>
[    9s]     import proto
[    9s]   File "/usr/lib/python3.10/site-packages/proto/__init__.py", line 10, in <module>
[    9s]     import pkg_resources
[    9s] ModuleNotFoundError: No module named 'pkg_resources'

The issue with the fix from #841, is that there's now a conflict with https://github.com/googleapis/proto-plus-python , because both package will install */site-packages/proto/__init__.py

Ok, I agree that the current CMake install of proto is pretty dirty. Some discussion is in #848 also.
I think the CMake script should be modified to install in a similar way as pip install nanopb does.

The issue with the fix from #841, is that there's now a conflict with https://github.com/googleapis/proto-plus-python , because both package will install */site-packages/proto/__init__.py

@PetteriAimonen Hello! Recently, I try to make the packaging of nanopb into Fedora repository, the reviewer pointed out the nanopb package has the issue of the same install directory with the python-proto-plus package. see: https://bugzilla.redhat.com/show_bug.cgi?id=2216595#c4
[!]: Package does not own files or directories owned by other packages.
     Note: Dirs in package are owned also by: /usr/lib/python3.11/site-
     packages/proto(python3-proto-plus), /usr/lib/python3.11/site-
     packages/proto/__pycache__(python3-proto-plus)

Any suggestion or progress with this?

Suggestion would be to fix the CMake rules so that they install properly in a package called "nanopb" instead of "proto". E.g. imitate what pip install nanopb does currently.
The CMake rules have been contributed by users over the years and there is not really anyone actively maintaining them. I don't use CMake myself.

@PetteriAimonen Maybe we can add the setup.py and pyproject.toml files (which exist in the uploaded source tarball of nanopb pypi project) into the proper location of the git repository, and use them for the python-nanopb package installation?

Maybe. Currently they somehow come from extra/poetry/poetry_build.sh, but I don't know the details on how that works either.

@PetteriAimonen I will use the source tarball of nanopb pypi project to make python-nanopb package. I am not clear with python-nanopb package that includes files in /usr/lib/python3.11/site-packages/nanopb/ directory. What is the relation of python-nanopb package with nanopb library package? So I can write the summary and description of the python-nanopb RPM package correctly.

The python part includes only the protoc-based generator, which converts .proto files to .pb.h files for inclusion in a project. It doesn't include the actual C source code for nanopb library.
The python part will depend on having either protoc (package "protobuf-compiler" or similar) or pip package grpcio-tools installed, in addition to python-protobuf library.

@PetteriAimonen Thanks for the explanation of nanopb. I created the nanopb packages (nanopb, nanopb-devel, nanopb-python3) on Fedora repository, and will be available in a few days later.
Ref: https://src.fedoraproject.org/rpms/nanopb
https://packages.fedoraproject.org/pkgs/nanopb/

I think this should be fixed in 0.4.8.


Load config file after startup

Suggestion
I was trying to make yabai register every window by running this command in my yabairc. This fails, because the query system is initialised after the configuration file is loaded.
I think the only feature that needs to be initialised after loading the config file is the status bar, as its config options cannot be set during runtime.
# visit all spaces once, then return to visible and focused spaces like before
yabai -m query --spaces \
    | jq "sort_by(.focused, .visible) | .[].index" \
    | xargs -I{} yabai -m space --focus {}

There is one slight problem with doing this - window border changes don't affect already created windows. I don't remember any other reasons at the moment for why initialization happens in this order.

This brings back something I've thought about a while ago:
Support the XDG base directory spec: Check for the configuration file in the following places (in order):

${XDG_CONFIG_HOME}/yabai/config
${HOME}/.config/yabai/config
${HOME}/.yabairc

This could then be extended to search for another optional file in the yabai config directory (if it is used over a .yabairc file) that is executed after yabai finished initialising.
.config/yabai/
├── config        # loaded during init
└── autoload      # loaded after init

This could then be extended to search for another optional file in the yabai config directory (if it is used over a .yabairc file) that is executed after yabai finished initialising.

I think the correct solution for this issue is to make the remaining config settings able to run without having to care which init state yabai is currently in, and then make execution of the config file happen at the end when all other things that need to happen have finished.
Created issue https://github.com/koekeishiya/yabai/issues/125 for XDG_CONFIG_HOME.

Fixed on master. The config is now ran asynchronusly by yabai after all initialization and whatever has finished. Because of this every single command can now be used at runtime with immediate effect.


Field "cassini_target_name" has null label for display_results

Cassini Mission Constraints
**None: None**
Saturn Orbit Number: C25
Observation Name: VIMS_C25AR_SLITDITHER_2PIX_PRI
Activity Name: None
Spacecraft Clock Start Count:<PHONE_NUMBER>.12
Spacecraft Clock Stop Count:<PHONE_NUMBER>.12
Is Prime: N
Primary Instrument: COVIMS
Earth Received Time (Min): 38916666.342
Earth Received Time (Max): 38916694.477

Fixed in new import pipeline


Custom routes: in manifest not honoured

I'm trying to push an app with the following manifest:
---
applications:
  - name: foo
    memory: 64M
    buildpack: staticfile_buildpack
    routes:
    - route: myplace.cfapps.io/v1_2_3
    - route: myother.place.com/v1_2_3

When pushing manually from my local machine, the output includes e.g.:
Creating route myother.place.com/v1_2_3...
OK

Binding myother.place.com/v1_2_3 to foo...
OK

Creating route myplace.cfapps.io/v1_2_3...
OK

Binding myplace.cfapps.io/v1_2_3 to foo...
OK

But the cf-resource only does this:
Creating route foo.cfapps.io...
OK

Names changed to protect the innocent.

Is this still a thing? Do you know if it could be a cf CLI version discrepancy?


Clean up the "Introduction to writing skills" document

It's full of outdated stuff. See https://github.com/MycroftAI/documentation/pull/121#issuecomment-508706385 and the ensuing conversation.

Hi AJ,
Thanks for the updates! There are many parts of the docs in need of updating. Mycroft moves quickly and it's hard to keep up. It's also one of those things that are constantly added to, however we also need to take the time to step back, rethink the structure and consider what should be removed as well.
I saw you mention that you are just getting started, but I think this is a really valuable perspective to bring as well. At times it can be harder for those very familiar with Mycroft to see what's missing or doesn't make sense to newcomers.
I'd love to hear any suggestions you have on a new structure for this section, and we can work from there on fleshing out and updating the content.

Hey, the Skill dev docs have received a fair bit of attention over the last year, so I'm going to close this for now.
If there are new issues spotted please open a new issue and we can handle those.


Phoebemirman/ch17657/arrow indicators off for categorical on mobiles

https://app.clubhouse.io/augur/story/17657/arrow-indicators-off-for-categorical-on-mobiles-and-small-laptop-screens

Coverage remained the same at 56.26% when pulling aaca4e780c88a01060b9b7e013b31bf1177d1e0a on phoebemirman/ch17657/arrow-indicators-off-for-categorical-on-mobiles into b4538ff009db2935005d4203cca2b9c214766107 on master.


RNFS.hash is not a function

Somehow i cant get it to work to hash the contents of a file.
I am using it like this
            import fs from 'react-native-fs';

            fs.hash(localPath, 'md5').then((hash) => {
                console.log(hash);
            });

I am getting
fs.hash is not a function
TypeError: fs.hash is not a function

Any tips?
All other are working (like mkdir, readFile, ...)

okay, the latest changes are not yet reflected in the public npm package. using git now and it works fine


feat: remove verbose limit restriction

Issue being fixed or feature implemented

Allow verbose proof generation to work on path queries with limits.
What was done?

Just removed the constraint checking code
How Has This Been Tested?

Breaking Changes

Checklist:

[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have added or updated relevant unit/integration/functional/e2e tests
[ ] I have made corresponding changes to the documentation

For repository code-owners and collaborators only

[ ] I have assigned this pull request to a milestone

This indeed solved the issue, and everything worked.

#251


[WIP] Strict dtype check

This PR aims to fix dtype.char inconsistency between numpy and cupy filed in issue #1646.
Currently some tests will fail.
(for example: tests/cupy_tests/math_tests/test_misc.py)

Closing the PR for now, because the issue is not that urgent and I don't have much time for this.


ClickOnce C/SIDE Deployment: Default options for ZUP-File

When deploying C/SIDE environment via ClickOnce it would be nice if the database server and database name would be predefined to quickly open the database without manually specifing these settings (just like with the ClientUserSettings for the windows client).
As running the default setup to create the ZUP file while build is no option and opening the C/SIDE environment with parameters and closing it again to save the ZUP while building the image is not possible in the container, is there any other way to achieve this? I also tried using URL parameters with ClickOnce deployment without success.

I am wondering if we could use lnk (shortcut) file as an entry point. We could pass the parameters easily as well as id to avoid problems of the overwriting zup files.
I haven`t tried it yet with ClickOnce but I am sending an example of lnk file. Of course, this should be created dynamically via PowerShell. This is one possibility:
$WshShell = New-Object -comObject WScript.Shell

$Shortcut = $WshShell.CreateShortcut("FinSql.lnk")
$Shortcut.TargetPath = "%COMSPEC% /C .\finsql.exe servername=MYSQLSERVER, database=MYDB, ntauthentication=yes, id=testshortcut"
$Shortcut.RelativePath = '%CD%'
$Shortcut.Save()

And this is the result of the previous script (a bit different as the script being included is slightly different but you can run the script and create your own link):
finsql.lnk.zip

My previous post is pointless as the ClickOnce`s entrypoint must be a valid and managed code-based EXE. Sorry, don`t know ClickOnce so...
But I have another option and looks promising (I am going to test it but mage.exe accept the output of the following):
https://gallery.technet.microsoft.com/PS2EXE-Convert-PowerShell-9e4e07f1
This tool allows you to convert a ps1 file into an exe file. So you can have a simple PowerShell script that will launch finsql.exe with requiered parameters. This file can be converted into the exe file using the script so you can simply convert it using required parameters during the startup process.
Maybe this form wont work or wont fit your ideas but I will test it.

@freddydk The approach mentioned before work fine but not from ClickOnce. It works only in the case you copy the content of the ClickOnce folder out of the container and you run it from your environment directly.
There are two problems I can see right now:

The manifest file has different entrypoint than expected (remains finsql.exe but I want to be included my runfinsql.exe which all parameters already included and internally runs finsql.exe). I don`t know how to change the entrypoint.
I suppose there will also be a problem with the signatures of the exe file etc. Some identity problems in general. Am I right?

Are we able to overcome the issues somehow? My conversion process works fine, I use a temp folder, create ps1 file that internally runs
Set-Content "$buildFolder\$fileName.ps1" "Start-Process 'finsql.exe' -ArgumentList ""servername=$SqlServerName, database=$DbName, ntauthentication=$useNtAuth, id=$Id""" -Force

This ps1 file is converted into the exe file, this is copied into the ClickOnce folder and the temporary outputs are deleted.

using navcontainerhelper with -includecside will give you shortcuts which works fluently - especially when running windows authentication.
No plans of adding more to clickonce.


feat: support subfolder index

Uses systemjs-plugin-domture to do the translation work.

Coverage remained the same at 100.0% when pulling ed7219b06c669bb00150aa59cdf66b5901a45964 on sub-folder-index into 1b3d42cb12b62e79e586cc284511c01e3df0d403 on master.

Coverage remained the same at 100.0% when pulling ed7219b06c669bb00150aa59cdf66b5901a45964 on sub-folder-index into 1b3d42cb12b62e79e586cc284511c01e3df0d403 on master.

Coverage remained the same at 100.0% when pulling ed7219b06c669bb00150aa59cdf66b5901a45964 on sub-folder-index into 1b3d42cb12b62e79e586cc284511c01e3df0d403 on master.


Add support for multiple modules

This enables a modules option to be provided in the webpack config file, allowing the elm-make output to consist of multiple elm modules.

@eeue56 this should be good to go now. I wasn't sure if you were avoiding ES6, if so let me know and I'll swap in ES5.

@opsb Yeah, definitely avoiding ES6. Trying to keep it as compatiable as possible for as long as possible.

@eeue56 I've swapped out the ES6 syntax

@opsb Can you add it to the readme, with an example?

@eeue56 docs added

think I'm seeing some caching issues, digging in

I'm now adding the modules do the list of dependencies as well which seems to have resolved the issue. I'll be using it all day so it's probably best to wait until tomorrow to merge when I've given it a good testing.

@eeue56 I've been making a few tweaks as I've hit things. I'm on hols for a week now and there doesn't seem to be any rush to merge this in so it might as well stay open until I've tested it a little when I get back.

I couldn't get it to work with webpack 3.4.0.
For every imported elm main module webpack reports
WARNING in ./elm/page/ModuleName.elm (Emitted value instead of an instance of Error) Unknown Elm compiler option: files
I also have to import all elm mains in my js because importing as
import Elm from './path/Main'
causes only the Main module to be imported and exposed as a property on Elm.
Moreover, the bundle grows with every import by 400kB just like when not using this patch.

@lukaszsamson I've only tried on webpack 2 so far, will take a look but it may not be for a week or two I'm afraid.

@opsb, any update on this?

@justgage I'e been using it in production for a while now, with webpack 3. From my point of view it's ready to merge.

@eeue56 When you have some time it would be awesome to get this through so we can Use Webpack 3

Published as 4.4.0! Thanks!

👏👏👏👏
On Sun, Oct 29, 2017, 6:34 AM Noah<EMAIL_ADDRESS>wrote:

Published as 4.4.0! Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/elm-community/elm-webpack-loader/pull/119#issuecomment-340259190,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKAwXwd4ms2n6RpPXl-GiDuxnlWefW7ks5sxHDKgaJpZM4N98Km
.


Fix: Consistently indent Dockerfiles with 2 spaces

This PR

[x] consistently indents Dockerfiles with 2 spaces
[x] sorts list of directories

💁♂ There currently is no specific rule for Dockerfiles to be indented with anything other than 2 spaces, see editorconfig.

@feelepxyz
Rebased!

Thank you, @feelepxyz!


feat: Introduce file system catalog

Close #177 .
In this we introduced FileSystemCatalog and delegate all operations to catalog.

cc @Xuanwo Any other comments?


Number of output buildings differs with every call

Hi,
when I execute the Module for the same CityGML file multiple times, it always puts out a different number of files (and fewer than the number of buildings in the GML file in total)!
Sometimes obj files are left out and sometimes others are added.
When I load the obj files in a 3D Editor, some Buildings are missing (as to be expected).
Greets,
Marius

Is it possible you have the overwrite: false option set (which it is by default)? This would only add models that failed to convert the previous time (for whatever reason). If you set it to true then it would overwrite all the existing files and add any new ones each time you run the module.
If you're deleting the files or exporting into a new directory and you see a big difference in the output count then this points towards something odd happening.
Another thing that will cause some buildings not to output is if they fail some of the basic geometry validation checks, so that will explain why you may never get all the buildings as OBJ files. However, this number shouldn't change if you ran the module multiple times.
What version of the module are you using? I can run some tests.
Are there any messages of significance in terminal when running the module?

overwrite: true

also i delete the files before running it again,
the terminal just sais "Saved: ..."  which should be normal and as i mentioned in Issue #11 it sais finished before all files are saved
I am using v0.1.24

Ok thanks for the update, and sorry for the delay. I'm looking into this now – it could be that the something like the callback issue in #11 is causing the final building output to differ each time because not all files get written before the app quits. I'll look at fixing that aspect first (so keep an eye on #11) and we can see how that affects things.

I found the issue – there's a queuing system that ensures the workers aren't overloaded and this wasn't being handled correctly on shutdown. I've pushed 0.1.26 which fixes this and from the tests I've run locally this spits out a consistent number of files each time.
Let me know how you get on and we can reopen it if the inconsistencies are still occurring.


Add possibility to shutdown

When our app quits, we have following thing in VisualVM:

I searched for ways to shutdown the task runner.
There seem to be discussions in OKHttp for shutdown "support" (https://github.com/square/okhttp/issues/6702, https://github.com/square/okhttp/issues/6173). When checking the code, there is something like shutdown() already existing: dev.ai4j.openai4j.DefaultOpenAiClient#shutdown
The client is generated in dev.langchain4j.model.openai.OpenAiChatModel#OpenAiChatModel "automagically". On the one hand, this is cool, because a user does not need to take care about the client. On the other hand, the client's shtudown() method cannot be called.
I needed to decied between:

Change the constructor to accept an ´OpenAiClient` so that the caller has full control on the client.
Add a shutdown to the model to enable the model to shutdown all used services.

I opted for the latter to have more "lightweight" interface.
I additionally needed to decide to switch to AutoClosable, because close() is IMHO the "modern" Java way for shutting down things. -- However, I kept shutdown  to focus at one issue at a time.
Curious, what you think.

Try locally. Does not help to solve our issue. Therefore closing. Will reopen if I know more.

Hi @koppor this is a known issue, should be fixed once we migrate away from okhttp

Although we can have a temporary solution as you suggested. Did you manage to find out what is wrong with these changes?

Although we can have a temporary solution as you suggested. Did you manage to find out what is wrong with these changes?

I'm on it. Currently, this change seems to help to reduce shutdown time. We still have one thread opened. I am investigating.
In general, I tend to like this connection pooling concept. Useful for long running apps and servers only.

Regarding HTTP clients, I got following options:

Use JDKs (because 1 less dependency)
Use feign: One can select the HTTP Client implementation (see https://github.com/OpenFeign/feign?tab=readme-ov-file#client)
Use Apache HTTTP Client: https://hc.apache.org/httpcomponents-client-5.3.x/index.html (Based on the evaluation matrix: https://github.com/docker-java/docker-java/blob/main/docs/transports.md)
Use Riptide if one needs asynchronous handling (which I think, isn't needed, is it?). However, one would need to contribute to https://github.com/zalando/riptide/issues/837 (otherwise, a Spring dependency is added)

IMHO, the Apache HTTP Client is the most stable.
(I can post this to the issue where you discuss clients. I just did not see it)

@koppor do you see the problem when using OpenAiChatModel or OpenAiStreamingChatModel?
I see it when using OpenAiStreamingChatModel, the app hangs for 1 minute after main thread is done.
I've added OpenAiStreamingChatModel.shutdown() locally that calls client.shutdown() and it works ok.

@koppor do you see the problem when using OpenAiChatModel or OpenAiStreamingChatModel?

OpenAiChatModel. Same code as at https://github.com/langchain4j/langchain4j/issues/1454#issuecomment-2230953662.
(@InAnYan and me are working together in the context of Google Summer of Code)


feat(jest-core): allow using Summary Reporter as stand-alone reporter

Inspired by https://github.com/rickhanlonii/jest-silent-reporter/pull/29
Summary
Currently there is no way to use only Summary Reporter. For instance, it might be useful together with Silent Reporter or simply as stand-alone reporter (that’s even more silent, why not?).
This idea came to my mind, while refactoring setupReporters() logic. Hence, this PR simplifies logic, adds more tests and one nice feature.
Test plan
More tests added. All should pass.

Before this change, all the custom reporters were being added after the built-in ones like CoverageReporter: https://github.com/facebook/jest/pull/12687/files#diff-18559c2ed95cf75fe249b47a0c70cf994dc0fa2a2f34727df4e6eb2f0e683cc5L370
This way it was possible to use coverageMap in a custom reporter. Now they are added before. I think this should be marked as a breaking change in the changelog

Ah.. Right, did not realise there could be such use case. Easy to move coverage reporter before custom. It felt like it makes sense to keep summary as the last one. Or?


Render Asset Image

Is there a way to reference an image that is stored as an asset in the project rather than a URL that would require an internet connection?
I am working on an offline first app but have used HTML to style large amounts of text that needs to be displayed but I need to add photos into the text.
Anyway, this shouldn't be a problem with the module itself.
If you feel like there is indeed a bug, please re-open.

@ethanbrown3 can you share the method that worked for you?

@themakerman You could create a custom renderer that does a require() of your asset path instead of using an url that is used as such : source={{ uri: 'http://...' }}.
This should work.

@Exilz How do i refer the path then inside renderer? Can you write example code?


Warning: title_format is deprecated

ORIGINALLY POSTED HERE https://github.com/holoviz/holoviz/issues/257
SIMILAR PROBLEM POSTED HERE https://github.com/holoviz/panel/issues/1184

HoloViz:  0.11.3
hvplot: 0.5.2
HoloViews:  1.13.2
My Pain
Trying to use the HoloViz tutorial for a course. There is a lot of new things to learn for my users so I would like to make the learning experience as smooth as possible.
One area of friction is this deprecation warning in the 05_Composing_Plots.ipynb notebook
WARNING:param.CurvePlot03050: title_format is deprecated. Please use title instead

I already posted this in the hvplot repo: holoviz/hvplot#426
As you can see I got an answer and the fix should be out with the next update from what I understood


Get devices

Coverage decreased (-0.4%) to 93.391% when pulling 4b6606d7ce72fa8ac784fb8ccda44be28a919455 on get-devices into 53240bd33cbb501e57a22ead6c45b3676ed1e6e0 on master.

Coverage increased (+0.2%) to 93.966% when pulling d345ab81e7a7f08696543e68f7493e9abf21baea on get-devices into 53240bd33cbb501e57a22ead6c45b3676ed1e6e0 on master.

Coverage increased (+0.5%) to 94.253% when pulling f04b7e076eb1635d8f1dc4e5a1f4042a51af0058 on get-devices into 53240bd33cbb501e57a22ead6c45b3676ed1e6e0 on master.


avoid repeating getCause calls

calling getCause() 3 times resulted in unnecessary synchronization since
getCause() is synchronized.

ack


Unable to find installation candidates for agent-protocol

I am getting the following error while testing out beebot. I have run the ./setup.sh script after getting into venv and got this:
(beebot) unitythemaker@blazingfast ~/TMP/beebot (main) [1]
❯ poetry install
Installing dependencies from lock file

Package operations: 19 installs, 0 updates, 0 removals

  • Installing agent-protocol (0.2.4): Failed

  RuntimeError

  Unable to find installation candidates for agent-protocol (0.2.4)

  at lib/python3.11/site-packages/poetry/installation/chooser.py:73 in choose_for
       69│
       70│             links.append(link)
       71│
       72│         if not links:
    →  73│             raise RuntimeError(f"Unable to find installation candidates for {package}")
       74│
       75│         # Get the best link
       76│         chosen = max(links, key=lambda link: self._sort_key(package, link))
       77│

  • Installing agent-protocol-client (0.2.2): Failed

  RuntimeError

  Unable to find installation candidates for agent-protocol-client (0.2.2)

  at lib/python3.11/site-packages/poetry/installation/chooser.py:73 in choose_for
       69│
       70│             links.append(link)
       71│
       72│         if not links:
    →  73│             raise RuntimeError(f"Unable to find installation candidates for {package}")
       74│
       75│         # Get the best link
       76│         chosen = max(links, key=lambda link: self._sort_key(package, link))
       77│

@unitythemaker
I had the same issue and removed the agbenchmark dependency from pyproject.toml to resolve it

@unitythemaker I had the same issue and removed the agbenchmark dependency from pyproject.toml to resolve it

Thank you, it's resolved.


[#noissue] Fix some NPE of apache dubbo plugin

Null pointer dereference of 'localHost' where null is returned from a method

Codecov Report

Merging #5854 into master will increase coverage by 0.01%.
The diff coverage is 40%.

@@            Coverage Diff             @@
##           master    #5854      +/-   ##
==========================================
+ Coverage   40.76%   40.77%   +0.01%
==========================================
  Files        2949     2949
  Lines       88634    88638       +4
  Branches    11652    11655       +3
==========================================
+ Hits        36129    36144      +15
+ Misses      49375    49361      -14
- Partials     3130     3133       +3

Impacted Files
Coverage Δ

...bo/interceptor/ApacheDubboProviderInterceptor.java
62.16% <40%> (-3.56%)
:arrow_down:

...collector/receiver/grpc/ShutdownEventListener.java
0% <0%> (-25%)
:arrow_down:

...rc/main/java/com/navercorp/pinpoint/test/Item.java
70% <0%> (-3.34%)
:arrow_down:

...navercorp/pinpoint/rpc/common/SocketStateCode.java
82.92% <0%> (-2.44%)
:arrow_down:

...ofiler/sender/StandbySpanStreamDataSendWorker.java
83.58% <0%> (+2.98%)
:arrow_up:

.../pinpoint/rpc/client/PinpointClientHandshaker.java
66.42% <0%> (+6.42%)
:arrow_up:

...pc/server/LoggingServerMessageListenerFactory.java
100% <0%> (+10%)
:arrow_up:

...rp/pinpoint/rpc/control/ControlMessageDecoder.java
78.57% <0%> (+14.28%)
: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 f9e593a...0addcd9. Read the comment docs.


CLI documentation for spark coverage collection is too sparse.

There is not enough information to use the tool.  The description of binsize needs more expansion as does the tool summary.

This is for SparkGenomeReadCounts


adds eventstream to domain, inmemory implementation

Codecov Report

Merging #12 into master will not change coverage.
The diff coverage is 0%.

@@         Coverage Diff          @@
##           master   #12   +/-   ##
====================================
  Coverage       0%    0%
====================================
  Files          12    15    +3
  Lines         241   272   +31
  Branches        6     9    +3
====================================
- Misses        241   272   +31

Impacted Files
Coverage Δ

...kka/contrib/d3/LocalAggregateManagerProvider.scala
0% <ø> (ø)
:white_check_mark:

...b/d3/cluster/ClusterAggregateManagerProvider.scala
0% <ø> (ø)
:white_check_mark:

...la/akka/contrib/d3/query/ReadJournalProvider.scala
0% <0%> (ø)

...contrib/d3/query/InMemoryReadJournalProvider.scala
0% <0%> (ø)

...re/src/main/scala/akka/contrib/d3/DomainLike.scala
0% <0%> (ø)
:white_check_mark:

...main/scala/akka/contrib/d3/AggregateSettings.scala
0% <0%> (ø)
:white_check_mark:

...ka/contrib/d3/query/EmptyReadJournalProvider.scala
0% <0%> (ø)

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 806fd52...7610623. Read the comment docs.


fix: lowercase image name for signing

#118

Wanted to quickly reach out and thank you for the bug fix. While it hasn't been merged into main yet, I was able to copy it over to my fork and it allowed me to get it working for the first time! Cheers!


[Feature]: Add CLI options help to DefaultOptions and InitialOptions type definitions

🚀 Feature Proposal
The help here:
https://jestjs.io/docs/cli
Should be included in the Config.d.ts definition so they can be viewed inline when writing a jest.config.ts for a project.
Motivation
Less likely to make mistakes going back and forth to the web docs and back, if the user even knows they exist
Example

Pitch
More help is always better.

Wanna send a PR for it?


feat: allow deep reexports

fixes #54

 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.


Support for tvOS12's new videos

This is based on @esetnik fork, modified to download the new tar file : https://sylvan.apple.com/Aerials/resources.tar
It downloads and untar the tar file to the cache directory. Json format slightly changed so accounted for that.

Would any of the changes from his 4k branch be useful?

Looks like I forked the wrong branch of his... my bad. I'll check his other changes and see what I can do, thanks for the heads up !

@glouel @kjg here's a list of improvements I made
https://github.com/JohnCoates/Aerial/pull/422

I'll apply my changes to your correct branch and resubmit, sorry about that.


KafkaJS crashes with typescript due to missing offset

I tried to use KafkaJS but it crashed immediately using these dependencies: "@types/node": "^11.10.5", and "kafkajs": "^1.5.0",
I'm using it in a Typescript environment though, might be the issue.
producer/partitioners/default.js line 22
let counter = crypto.randomBytes(32).readUInt32BE()
According to @types/node/globals.d.ts readUInt32BE(offset: number): number;.
I don't know what the offset should be, if it should be zero or something, but leaving out an offset will have the application crash for me.

Hi @jdfindwise, we noticed that. PR #300 should fix this issue, can you work around the issue? We have some team using KafkaJS with typescript, and it is working fine, we should release a version soon fixing this problem.

You can try out the code in master:
yarn add https://github.com/tulios/kafkajs.git#5f152019b47e3ea5e912e48134204385b3350e91

@tulios thank you for that link.
It did indeed fix the compile issue, I can now start the application.
I do get another issue
{"level":"ERROR","timestamp":"2019-03-08T14:43:22.423Z","logger":"kafkajs","message":"[BrokerPool] KafkaJSConnectionError: Failed to connect: net.connect is not a function","retryCount":0,"retryTime":243}
{"level":"ERROR","timestamp":"2019-03-08T14:43:22.425Z","logger":"kafkajs","message":"[BrokerPool] Failed to connect to seed broker, trying another broker from the list: Failed to connect: net.connect is not a function","retryCount":0,"retryTime":243}

Not sure if you have seen this issue before?

This error is weird, net is part of the node.js standard library. Are you running using something else?

Nevermind, was totally my fault that one.
Tried to run it in a browser, which obviously won't work, works fine from a node.js console :)

That's awesome. I'm actually working on browser compatibility at the moment, but it's unfortunately not quite ready yet. In some weeks, I hope to have something available for you. 😃

The error thrown if the offset is not provided is most likely related to feross/buffer#237


Allow the proposer to select a prover

Describe the feature request
Currently the proposer and the prover are completely separated. In practice however it's extremely likely block builders already know provers. It's also possible to allow these two to communicate with each other (PBS style).
This allows the proposer and the prover to decide on a fair price per proof on a block per block basis. It also allows the prover to only prove blocks for which it has the capacity to do so.
Conceptually the idea is the same as when a block would be proposed directly with its proof. But because that is currently not possible (proof generation takes too long), instead a bonded promise is attached from the prover.
Onchain things are very simply:

When the block is proposed, a signature is provided from the prover that will prove the block. This is done by the prover signing the hash of all the block data (so that the block data itself can remain hidden if necessary) and specifying the expected fee payment.
The protocol checks this signature and checks if the prover is bonded.
If all those checks pass than the proposed block is accepted.
When the block gets proven, the prover gets his expected fee payment.

When the block isn't proven in time, the bond of the prover gets slashed and those funds are used to pay for all the blocks the prover failed to prove.
Blocks could still be proposed without a specified prover, that will use the default proving path instead.
Benefits:

Very easy and gas efficient
Automatically as efficient as possible: the proposer will select the prover willing to prove the block for the lowest price to maximize its own profit. Or not and use the default path.
Permissionless because any prover can become a prover by just posting the required bond. No limits.
Censorship resistant because the proposer can pick any prover willing to pay the block and can prove the block themself if necessary. Some provers may not want to prove a block and they can just avoid proving those specific blocks without ever being forced to prove any other blocks.

And the default path is still there as well when necessary which can be counted on.
Combating centralization
The approach above is great for efficiency, but will also be centralizing, So we now try to ensure prover redundancy while sacrificing efficiency as little as possible.
Sub-groups
Each block will have some randomness (the block number for example) which will select a random sub-group in the provers. The goal is to have random sub-groups that still have to compete against each other on price to make sure the proving cost is still low, while preventing a single most efficient prover to prove all the blocks. For example if there are 4 provers A, B, C, and D, the following sub-groups of 2 provers could be selected:

A, B
A, C
A, D
B, C
B, D
C, D

For a specific block, the proposer can only use one of the provers in the selected sub-group, using any other prover will be rejected.
However, this would be artificially limiting the pool of selected provers. We can still allow the proposer to use another prover, as long as some protocol defined GROUP_BYPASS_FEE is payed to the provers in the current sub-group. This ensures that the cost in the subgroup isn't higher than lowest_prover_fee_all_provers + GROUP_BYPASS_FEE and ensures the offchain system can still be used when none of the provers in the sub-group are able to prove the block (the GROUP_BYPASS_FEE could also be waived if signatures of all provers in the subgroup can be shown that they don't want to prove the block). 50% of the  GROUP_BYPASS_FEE is burned so it cannot be abused.
PoG
Provers could be whitelisted using some sort of governance mechanism (the easiest being some sort of token voting). These whitelisted provers can add themselves to a smart contract and post a bond, which will allow them to sign blocks to prove. Giving a prover more weight to have them have a bigger chance to prove a block can simply be done by allowing the prover to be in the prover list multiple times.
Not sure if this will be necessary, but for now I think it is to ensure the quality of service that each prover can provide.
Open proving system
Because we want to keep things as simple, the proving system when the offchain method isn't used should be disincentivized (because would give the opportunity to prove a block away to another prover) and be as simple as possible. An OPEN_FEE is charged to the proposer (that needs to be larger than GROUP_BYPASS_FEE) and is sufficient to prove the block at all times. This will be completely open and whoever proofs the block first could get the reward. 50% of the OPEN_FEE is burned to prevent abuse.
Describe alternatives you've considered
Description of the alternatives you've considered here.
Additional context
Additional context here.

You mentioned block per block basis, is there an existing solution for low latency communication (not-centralized or among whitelisted-only participants) so that a block proposer has time to query and validate all the offers he/she has per every block ?

I think this is pretty standard peer discovery which is done in nodes and things like bittorent, but I don't really know much about it. Provers will make it so that their information is as widely available as possible, so proposers shouldn't have much trouble finding out how to connect with them. When using PoG, this will be whitelisted so will definitely not be a problem

We likely still need something like a simplified prover staking pool for wannabe provers, so that we can secure the slashing (but obv. assigning blocks would not depend on the staked amount) ?

Depends a bit on how often we still think the open mode will be used. If we think normally it won't be used, than simplifying as much as possible makes sense (which could mean a separate path that is as simple as possible or reuse the normal system as much as possible somehow).
The staking amount could still be important for the sub-group selection (bigger chance to be selected to the sub-group), though PoG may be a better way to assign weights. (I added some new sections to the original post that builds the system out with some more details).

I like the idea that each proposer can choose a prover for each of his blocks, as long as the per-block bond is good enough for the core protocol. Our current Prover Pool can serve a s special Prover impl that can also be chosen by proposers. There can also be other implementations of Prover contracts that proposers can choose, as long as the Prover contract must guarantee a bond per block. I think this will be a nice abstraction on top of the current implementation.
We can define a virtual prover as:
interface Prover {
    function onSelected(address proposer, uint blockId, uint bond) external returns (address proofSubmitter);
    function onReleased(address proposer, uint blockId, uint bond, uint reward) external;
}

When a Prover is selected,  the core protocol first burn X token from it as a bond, then call the onSelected function to ensure it did not revert. Then when the block is finalized using a proof provided by the given prover, mint X + Y token as reward back to the Prover and call its onReleased function.
If the selected prover is an EOA,  we check there is an authentication signature (do not call these two functions).

Thank @Brechtpd  for introducing this proposal. After a simple review, I find it to be quite meaningful. And, I have a few comments that I would like to share.
Firstly, I am concerned about the potential for proposers to submit redundant blocks for the purpose of winning provers' profits. While combining proposers and provers could have some benefits, the current design on the testnet separates these roles to mitigate this risk.
Secondly, eliminating redundant proposed blocks is a separate issue that we wish to address. I suggest a solution of exploring the possibility of combining Ethereum's POS with the current staking-based prover solution. The rough idea is to select a super-prover (a proposer and prover role) through a consensus mechanism, who would then propose block, generate proof (or delegate the prover role via a second layer) and submit it. This approach would avoid the need for extra POS incentives as we already have them in A4 and resolve the issue of redundant proposed blocks.
The implementation of POS and the PBS design of flashbot is not very simple. It would need some additional time to develop a more detailed proposal, but I would like to throw out a nugget for pearls of wisdom.

Thank @Brechtpd for introducing this proposal. After a simple review, I find it to be quite meaningful. And, I have a few comments that I would like to share.
Firstly, I am concerned about the potential for proposers to submit redundant blocks for the purpose of winning provers' profits. While combining proposers and provers could have some benefits, the current design on the testnet separates these roles to mitigate this risk.
Secondly, eliminating redundant proposed blocks is a separate issue that we wish to address. I suggest a solution of exploring the possibility of combining Ethereum's POS with the current staking-based prover solution. The rough idea is to select a super-prover (a proposer and prover role) through a consensus mechanism, who would then propose block, generate proof (or delegate the prover role via a second layer) and submit it. This approach would avoid the need for extra POS incentives as we already have them in A4 and resolve the issue of redundant proposed blocks.
The implementation of POS and the PBS design of flashbot is not very simple. It would need some additional time to develop a more detailed proposal, but I would like to throw out a nugget for pearls of wisdom.

There can also be other implementations of Prover contracts that proposers can choose

Depends a bit I think on the implementation, because if the proposer can choose freely without any additional cost for a specific implementation things may centralize again to a single solution. I think If there are multiple possible implementations, each of them need to mitigate centralization on their own as well. You could do the random burn solution on the prover system as well, but assuming there is only one that is actually used almost at all times, that seems to just increase overheads most of the time.

as long as the Prover contract must guarantee a bond per block. I think this will be a nice abstraction on top of the current implementation

If the bond is per block, won't it be either too expensive to prove a lot of blocks in parallel for provers, or the bond will be so low that slashing isn't really something to be afraid of? A single bond per prover seems to make more sense to me, higher slash risk per block, but shared between multiple blocks. I think this also makes sense because for the network stability it doesn't really matter that much if just 1 proof is missing or 1000 proofs are missing. A single missing proof stops the chain from being able to reach verification status.

Firstly, I am concerned about the potential for proposers to submit redundant blocks for the purpose of winning provers' profits. While combining proposers and provers could have some benefits, the current design on the testnet separates these roles to mitigate this risk.

Could you explain a bit more? Not sure I understand the problem you're addressing. Proposers could propose redundant blocks, but they would have to pay the prover for all of those, so doesn't seem like something that can be exploited.

Secondly, eliminating redundant proposed blocks is a separate issue that we wish to address. I suggest a solution of exploring the possibility of combining Ethereum's POS with the current staking-based prover solution. The rough idea is to select a super-prover (a proposer and prover role) through a consensus mechanism, who would then propose block, generate proof (or delegate the prover role via a second layer) and submit it. This approach would avoid the need for extra POS incentives as we already have them in A4 and resolve the issue of redundant proposed blocks.

Could you describe what redundant proposed blocks are for you? In the proposed solution, the proposer + prover can be seen as a single entity, but because we're a based rollup they have to go through the Ethereum validator. So using the PBS model you can see the proposer + prover as the block builder, and the Ethereum validator as the proposer.
The prover centrist model is indeed also an interesting one, but not one that is compatible with based rollups, which is still our current goal.

The implementation of POS and the PBS design of flashbot is not very simple. It would need some additional time to develop a more detailed proposal, but I would like to throw out a nugget for pearls of wisdom.

A full PBS design for the prover market will be a bit of work though other parties should be interested in making that. It also depends a bit how that will play out. Provers will want to broadcast their address where proposer can request proofs as far and wide as possible. We can even allow provers to post their API URL on the pool smart contract so that all proposers can simply contact and get a quote of them directly on that URL.

Firstly, I am concerned about the potential for proposers to submit redundant blocks for the purpose of winning provers' profits. While combining proposers and provers could have some benefits, the current design on the testnet separates these roles to mitigate this risk.

When a proposer and prover can earn a small profit from a single block, they have the motivation to produce more blocks for greater earnings. Since the proposer+prover is permissionless, they may generate numerous duplicated or similar blocks and still earn some profit. Therefore, it is likely that the proposer and prover will engage in this behavior.

Could you explain a bit more? Not sure I understand the problem you're addressing. Proposers could propose redundant blocks, but they would have to pay the prover for all of those, so doesn't seem like something that can be exploited.

Secondly, eliminating redundant proposed blocks is a separate issue that we wish to address. I suggest a solution of exploring the possibility of combining Ethereum's POS with the current staking-based prover solution. The rough idea is to select a super-prover (a proposer and prover role) through a consensus mechanism, who would then propose block, generate proof (or delegate the prover role via a second layer) and submit it. This approach would avoid the need for extra POS incentives as we already have them in A4 and resolve the issue of redundant proposed blocks.

Could you describe what redundant proposed blocks are for you? In the proposed solution, the proposer + prover can be seen as a single entity, but because we're a based rollup they have to go through the Ethereum validator. So using the PBS model you can see the proposer + prover as the block builder, and the Ethereum validator as the proposer.
The prover centrist model is indeed also an interesting one, but not one that is compatible with based rollups, which is still our current goal.

The implementation of POS and the PBS design of flashbot is not very simple. It would need some additional time to develop a more detailed proposal, but I would like to throw out a nugget for pearls of wisdom.

A full PBS design for the prover market will be a bit of work though other parties should be interested in making that. It also depends a bit how that will play out. Provers will want to broadcast their address where proposer can request proofs as far and wide as possible. We can even allow provers to post their API URL on the pool smart contract so that all proposers can simply contact and get a quote of them directly on that URL.

In this PR, I'm trying to further separate the current prover pool from the core protocol. This detachment facilitates flexibility, allowing the core protocol to easily adapt to alternative or superior prover pool designs without alterations. We're handing the task of finding the best prover pool design to third parties, and our role is to create the glue that connects the core protocol to multiple prover pools. This glue is embodied by our tokenomics, not by any particular pool.
The concept stems from Brecht's feature request, but this PR concentrates solely on the glue aspect and does not incorporate any advanced features. Specifically, it permits a block proposer to select a prover when proposing a block. If the prover's address is 0, the block is immediately open; otherwise, the selected prover must validate the block within a defined time window.
The functional details are as follows:

If the assigned prover's address is non-zero and an EOA, the system verifies a signature to confirm the prover's agreement to validate the block at a capped fee-per-gas.
If the prover is a contract (assumed to be an IProver contract), the method prover.onBlockAssigned is invoked. This method may include authorization and other logics. If it does not revert, the block can be proposed; otherwise, the proposal is rejected.

In all cases, the protocol enforce the burn of a bond of a minimal value, 32 x block_deposit, in the implementation.
To avert unnecessary gas consumption, there are no notification calls to the prover contract when a block is proven or verified. This design prevents a malicious prover contract from exploiting callbacks like onBlockProven or onBlockVerified to exhaust gas.
Instead, the prover contract's deployer or owner manages off-chain authentication of block proposers and updates the prover contract's state. All prover contracts must have owners, as they cannot automatically modify their contract state or the behavior of the onBlockAssigned function on-chain without core protocol knowledge.
This approach may initially appear undesirable, but it corresponds with the fact that a prover's ability is based on off-chain information.
In this PR, it is also delineated that, generally, the proposer burns a block_deposit to cover the proving fee (block fee) using the block's gasLimit. If the gasUsed is less, a portion is refunded, making the proposer's payment equal to what the prover receives. The exception occurs when a block is not initially open and is verified by a prover other than the assigned one outside the proof window. In this case, we mint avgFeePerGas * 1.5 * gasUsed to the actual prover, but the proposer pays his expected amount, i.e., feePerGas * gasUsed. The prover's bond is not returned and will cover the additional cost. This almost guarantees the total supply of Taiko token decreases over time.
Tests are not updated and not runnable. I'd like to get your initial feedback first.

RE: Method A. Random (per block) burn per prover

This will force the owner of the same set of hardware to use as many addresses as they can afford, so for every block, this pool of provers always have an address that will burn a really small amount of tokens. But it is still the very same prover off chain.

RE: Method A. Random (per block) burn per prover

This will force the owner of the same set of hardware to use as many addresses as they can afford, so for every block, this pool of provers always have an address that will burn a really small amount of tokens. But it is still the very same prover off chain.

Yep, that's why it also requires a sybil resistance detection mechanism. The designs above assumes staking, but proposes governance  (PoG (or dPoS) as an alternative (or an additional mechanism on top of staking).

In this PR, I'm trying to further separate the current prover pool from the core protocol. This detachment facilitates flexibility, allowing the core protocol to easily adapt to alternative or superior prover pool designs without alterations. We're handing the task of finding the best prover pool design to third parties, and our role is to create the glue that connects the core protocol to multiple prover pools. This glue is embodied by our tokenomics, not by any particular pool.
The concept stems from Brecht's feature request above, but this PR concentrates solely on the glue aspect and does not incorporate any advanced features. Specifically, it permits a block proposer to select a prover when proposing a block. If the prover's address is 0, the block is immediately open; otherwise, the selected prover must validate the block within a defined time window.
The functional details are as follows:

If the assigned prover's address is non-zero and an EOA, the system verifies a signature to confirm the prover's agreement to validate the block at a capped fee-per-gas.
If the prover is a contract (assumed to be an IProver contract), the method prover.onBlockAssigned is invoked. This method may include authorization and other logics. If it does not revert, the block can be proposed; otherwise, the proposal is rejected.

In all cases, the protocol enforce the burn of a bond of a minimal value, 32 x block_deposit, in the implementation.
To avert unnecessary gas consumption, there are no notification calls to the prover contract when a block is proven or verified. This design prevents a malicious prover contract from exploiting callbacks like onBlockProven or onBlockVerified to exhaust gas.
Instead, the prover contract's deployer or owner manages off-chain authentication of block proposers and updates the prover contract's state. All prover contracts must have owners, as they cannot automatically modify their contract state or the behavior of the onBlockAssigned function on-chain without core protocol knowledge.
This approach may initially appear undesirable, but it corresponds with the fact that a prover's ability is based on off-chain information.
In this PR, it is also delineated that, generally, the proposer burns a block_deposit to cover the proving fee (block fee) using the block's gasLimit. If the gasUsed is less, a portion is refunded, making the proposer's payment equal to what the prover receives. The exception occurs when a block is not initially open and is verified by a prover other than the assigned one outside the proof window. In this case, we mint avgFeePerGas * 1.5 * gasUsed to the actual prover, but the proposer pays his expected amount, i.e., feePerGas * gasUsed. The prover's bond is not returned and will cover the additional cost. This almost guarantees the total supply of Taiko token decreases over time.
Tests are not updated and not runnable. I'd like to get your initial feedback first.

I've got some concerns about a few things:

It seems that right now, provers only get incentivized by the native tokens from the proposer. How do we ensure a direct value relationship between the prover's collateral and the proposer's native tokens? Is there a risk of malicious attacks between provers? For instance, if a timeout occurs, one-fourth of the collateral can be taken by other provers. This could lead to attacks if the value of that collateral is greater than the proposer's native tokens.

It looks like the proposer's token rewards are received right when they propose. If the reward is worth more than what is sent to the prover, could the proposer spam a bunch of blocks just to profit?

Proofs take time, but the prover's native token reward is fixed when the proposer proposes a block. What if the base gas price spikes during that time, making the gas fee greater than the reward? Would provers hold off on submitting proof transactions? This could slow down the network's block production speed, even without considering the 90-minute collateral penalty.

For the situation with other provers who aren't chosen by the proposer, I didn't see a clear handling of this in the code. From what understand, if you've submitted a proof within 90 minutes, the collateral tokens are returned to the prover selected by the proposer. However, provers who were not selected but have still provided a proof don't seem to receive any rewards.

John, thank you for your questions. Let me to answer the question based on the latest protocol code (alpha-5), which is quite different from alpha-3 and alpha-4.

It seems that right now, provers only get incentivized by the native tokens from the proposer. How do we ensure a direct value relationship between the prover's collateral and the proposer's native tokens? Is there a risk of malicious attacks between provers? For instance, if a timeout occurs, one-fourth of the collateral can be taken by other provers. This could lead to attacks if the value of that collateral is greater than the proposer's native tokens.

Provers are actually paid with ETH directly by the block proposers. But it is also possible for the proposer to pay any ERC20 token to the prover if the prover is a IProver contract (using transferFrom(proposer, address(this), amount)  inside the contract). A block can only be proven by the assigned prover within a proof window, other provers will have to wait for 1) the first proof from the assigned prover to be submitted or 2) the the proof window ends.

It looks like the proposer's token rewards are received right when they propose. If the reward is worth more than what is sent to the prover, could the proposer spam a bunch of blocks just to profit?

This is to guarantee the liveness of the blockchain, making sure there will be at least one block after a certain seconds even if there are not many transaction on L2.

Proofs take time, but the prover's native token reward is fixed when the proposer proposes a block. What if the base gas price spikes during that time, making the gas fee greater than the reward? Would provers hold off on submitting proof transactions? This could slow down the network's block production speed, even without considering the 90-minute collateral penalty.

Provers no longer receive native token reward, going forward, proving fees are negotiated off-chain per block (not per gas used) and paid by block proposers.

For the situation with other provers who aren't chosen by the proposer, I didn't see a clear handling of this in the code. From what understand, if you've submitted a proof within 90 minutes, the collateral tokens are returned to the prover selected by the proposer. However, provers who were not selected but have still provided a proof don't seem to receive any rewards.

The idea is not to ask more than one prover (the assigned one) to start proving the same block at all to avoid unnecessary waste of resources. Taiko tries to lower user transaction fees which requires us to lower the cost per block proving.

Hey @dantaik . Thank you for the insightful explanation. The 'negotiated off-chain' mechanism indirectly answers many questions.

The idea is not to ask more than one prover (the assigned one) to start proving the same block at all to avoid unnecessary waste of resources. Taiko tries to lower user transaction fees which requires us to lower the cost per block proving. ZK-proving a block is not a PoW game.

Regarding the fourth question, could the fixed 90-minute period be adjusted? For example, if the average time for generating a proof is x minutes, could we reduce the 90-minute window to x and implement a gradient reduction in collateral after x minutes? This could ensure that provers can't submit proofs anytime within 90 minutes without any constraints and also make block-proving times more consistent.

I also have an additional question: Will the 'negotiated off-chain' mechanism introduce a reputation system for provers, or any other mechanisms to encourage stable operation?

After reviewing the codes, I have a couple of comments to make:

If multiple proposers propose blocks in the same L1 block, only the first proposer can get ttko. This may lead to a gas war in sepolia, as the transaction with more gas fee will become the first one and get the ttko, when sepolia ETH is cheap.
What if we transfer the ETH to the prover after the block is verified? It can encourage the prover to submit the proof honestly.

In my opinion, it would be beneficial to reduce or eliminate the bond or penalty for zkp provers. As explained in my article found at https://mirror.xyz/aoraki-labs.eth/5RoLVYZo5T2Lj4xLO5AB0uzVEaKKegGLlbUcdGQQTCg, zkp provers face a greater risk compared to ETH validators. Despite receiving fewer rewards, they must still pay for high computation cost, gas and assume penalty risks. In cases where network issues arise, the prover may fail to submit the proof and suffer significant losses. This creates added pressure for those running the zkp prover.

Is it still in the loop?

In the latest protocol code, for each block, a prover is required to put 2 bonds: a liveness bond and a validity bond. The liveness bond is to guarantee the prover is online to provide the proof in time, the validity bond is to make sure the proof shall be a valid one.
The liveness bond should be small and the liveness bond shall be much larger. When a prove is offline, he only lose his liveness bond.


Enhancement: Update and Beautify the Healthcare Login Page

Description:
The current Healthcare login page needs an update to improve its visual appeal and user experience.
Some specific elements that could be enhanced include:

Update the fonts and typography for the labels and headings to make them more modern and elegant.
Consider redesigning the section with icons to improve readability and engagement.
The logo "Bharat सेवा+" and its surrounding text ("Health Care Login, Serving Country with Love and Dedication") could be centered and aligned properly for a more cohesive design.

Expected Outcome:

Introduce modern and visually appealing color schemes.
Use better typography for enhanced readability.
Improve alignment of text and images across the entire page.
Ensure that the webpage remains responsive and visually appealing across different screen sizes.

Screenshot:

I would like to contribute for this issue

Great @SGI-CAPP-AT2 can you share your thought on how you are planning to execute it. let's align before you proceed!

I will remove all these 3 boxes and create boxes without borders or shadow.
Align all of them center
Create a Parent for these 3 which is vertical flexbox
Changes in font

I would like to work on this issue please assign it to me

@A-nirvana can you share you idea what will you change in this page.

I would make the signup div smaller by just using only the placeholder for the inputs, maybe make them underline inputs instead of boxed, center all that properly, use a font like OutFit and also a suitable color pallete of maybe teal like colors with proper contrast and I will also try using glassmorphism to give it a very modern look. Also about the points of note, I'll make its div in a different shade than the other section. The Bharat सेवा+ logo will be centered. In total I'd make this a very classy modern looking page.

@A-nirvana @SGI-CAPP-AT2 can you make UI like this
NOTE THIS IS AI GENERATED IMAGE

@vaibhavyadav-dev  sure I can start working right away

@vaibhavyadav-dev sure I can create a dynamic UI just like you provided above.So, please assign this issue to me.

@vaibhavyadav-dev I can create an interactive UI just as the image or better !! Can you assign this to me ?

ok @Arsomuu you can take this

any update @Arsomuu

working on it @vaibhavyadav-dev
got busy with college internals