fix: add migration for kintsugi slot duration

Signed-off-by: Gregory Hill<EMAIL_ADDRESS>Implements the slot duration migration described here. Note that the service already has the necessary changes: https://github.com/interlay/interbtc/blob/63b485b2e8105eeaf20d960ed0a89443d2567d2a/parachain/src/service.rs#L474-L478

Implements the slot duration migration described here. Note that the service already has the necessary changes:
https://github.com/interlay/interbtc/blob/63b485b2e8105eeaf20d960ed0a89443d2567d2a/parachain/src/service.rs#L474-L478

We would need to revert this to use 12s on kintsugi as well, right?


GEODE-9825: Back-Port to 1.12

This PR will be rebased onto support/1.12. It has two cherry-picked commits.

[x] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?

[x] Has your PR been rebased against the latest commit within the target branch (typically develop)?

[ ] Is your initial contribution a single, squashed commit?

[x] Does gradlew build run cleanly?

[ ] Have you written or updated unit tests to verify your changes?

Problem here is I had to back-port the PR for GEODE-9713 (test framework enhancement) along with the commit for GEODE-9825. Unfortunately GEODE-9713 relies on a newer version (4.1.0) of Awaitility (was at 3.1.6). Bumping just that version in DependencyConstraints.groovy was not sufficient as something (TBD) is dependent on Awaitility 2.0.0 and that version is taking precedence.

This CI acceptance test had a number of failures due to non-zero exit status from gfsh commands: https://concourse.apachegeode-ci.info/builds/4162648
I suspect there was some sort of infrastructure problem e.g. AWS problem. I'm re-running the acceptance tests.


Ignore JSON keys order when stubbing a request

When stubbing a request with a json body, the actual request has to have the exact same string representation of json in order to work.
So, for example
stub_request(:post,'www.example.com').with(body: {key1: 'value1,key2: 'value2'}.to_json)

will not be matched by
POST www.example.com
"
 {
   "key2" : "value2",
   "key1" : "value1"
 }
"

Would be better to parse both JSON (request and stub_request) in hashes and make the comparison ignoring the keys order.

I have noticed the same things just now. Including what @maxdidato is suggesting would be nice. :+1:

Any update on that? I would be happy to provide a solution if the issue makes any sense.

+1

this is coming up next on my list, need to fix some code around the same area first, and then tackle this.


Integrate clippy checking in CI build

Please try to describe precisely what you would like to do in Cranelift and/or
expect from it. You can answer the questions below if they're relevant and
delete this text before submitting. Thanks for opening an issue!

What is the feature or code improvement you would like to do in Cranelift?
After merging bytecodealliance/cranelift#1169 (and seeing bytecodealliance/cranelift#1168), it occurred to me that we should output clippy warnings as a part of test-all.sh. I'm not sure we should fail the build (though this could be an option) but this would make non-clippy-approved additions more visible.

What is the value of adding this in Cranelift?
It should result in cleaner, more standard code in the long run.

Do you have an implementation plan, and/or ideas for data structures or
algorithms to use?
Add cargo clippy to test-all.sh and ensure clippy is installed for Azure pipelines.

Have you considered alternative implementations? If so, how are they better
or worse than your proposal?
No.

I think it would be nice to have selected checks enforced on the CI.
For instance, I frequently encounter the "unnecessary name repetition" lint failing in the codebase and I think it would be a good idea. On the other hand, this should be definitely a whitelist of curated checks and not a wholesale inclusion of clippy.
Is there any reason why we have to use clippy check from actions-rs and not just manually install it with rustup and execute cargo clippy inside the CI?

The actions-rs version shows annotations on pull requests for all warnings and errors, while just using cargo clippy requires you to visit the build log.

Clippy is currently checked on CI although most lints are turned off. It's intended that we'll enable clippy lints on a case-by-case basis and watch them in CI.


Orion postgresoracle migration

Codecov Report

Merging #1267 (0d44f53) into master (916bf0b) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head 0d44f53 differs from pull request most recent head 9c7fa22. Consider uploading reports for the commit 9c7fa22 to get more accurate results

@@            Coverage Diff            @@
##             master    #1267   +/-   ##
=========================================
  Coverage     99.52%   99.52%
  Complexity     3251     3251
=========================================
  Files           499      499
  Lines          9811     9811
  Branches        491      491
=========================================
  Hits           9764     9764
  Misses            5        5
  Partials         42       42

Flag
Coverage Δ
Complexity Δ

unittests
99.52% <ø> (ø)
3251.00 <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

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 916bf0b...9c7fa22. Read the comment docs.


Rename /src/css/ -> /src/styles

As discussed in Discord, this project tries to align with the default Astro Project Structure. This change renames the /src/css folder and /src/css/style.css file to /src/styles and /src/styles/global.css respectively. I've gone through and updated tests and docs to match. However, this is a breaking change, and needs to be fixed in the template repo as well.

I forgot to mention: This needs a (minor) changeset explaining the change, for example:
Renamed default import css to styles
- import "my-theme/css"
+ import "my-theme/styles"

The other PR didn't have a changeset either, can you also create one for those changes as well? Thanks!

I forgot to mention: This needs a (minor) changeset explaining the change, for example:
Renamed default import css to styles
- import "my-theme/css"
+ import "my-theme/styles"

The other PR didn't have a changeset either, can you also create one for those changes as well? Thanks!

I included a changeset for this one, but perhaps you wanted more, for instance including the diff? I can tack them onto this one for ease.


Passing async response data as prop.

Hi,
I have a use case where I need to pass data as prop to component and need to avoid putting it into redux store. Data is coming from asyncItem. I have gone through the decorator code but didn't find a solution.
Any suggestion would be great help.Thanks.
Regards,
Brij Kishor

@ttbrijkishor see https://github.com/makeomatic/redux-connect/blob/master/docs/API.MD#asyncconnect-decorator

The interface is similar to react-redux connect. The key field of each object will be used to connect data returned from from promise to both the redux state and the corresponding prop in the component. So in example above you'll have this.props.lunches.


RAT-328 Fix for IOSupplier issue includes javadoc updates

Ensured the System.out does not get closed and updated javadocs.
Added class to allow others to wrap similar streams in a no close format.

Thanks for the fix, I'll add a changelog entry.


Release 87 patches

That all looks pretty reasonable to me.

Coverage remained the same at 81.446% when pulling ac78563b259848fe8bb8efcb73d142425e4e1891 on release_87_patches into 52238b0f2dd282912c30b52518424780f5141f69 on master.

Good first steps, relco padawan.


New release?

The packagist v2.3.0 version was tagged in 2017, several improvements made their way since then.
Could you publish a new release please?

Released, Thank you! :)


 Learn more about stacking.

Join @pepyakin and the rest of your teammates on  Graphite


Functionality when payment on paytomorrow succeeds/cancels

Issue: https://linear.app/nebulab-retainers/issue/ABU-9/create-a-controller-to-handle-when-application-is-successfully-created
and
https://linear.app/nebulab-retainers/issue/ABU-17/create-a-controller-to-handle-when-application-is-cancel

[x] Template controller to handle success/cancel
[ ] Controller specs

Force-pushed because had to rebase from master

This need to be rebased on top of ABU-18, right?

Yes

If the payment is rejected by paytomorrow the user is redirected to pay tomorrow site. Is there anything that we can set to prevent it and redirect the user to the cancel URL?

I'll reproduce this and see what we can do. But I think it should be a concern for a separate PR


Overlay.of(context) return null when in test code

Something error in my code?
everything runs where in develop mode.but i could't get Overlay.of(context) (which always return null)

Anyone have same situation like me?

I have encountered this while applying overlay on root widget. And solved it by accessing OverlayState via Global NavigatorState intead of Overlay.of(context),
quote from official doc

Although you can create an Overlay directly, it's most common to use the overlay created by the Navigator in a WidgetsApp or a MaterialApp. The navigator uses its overlay to manage the visual appearance of its routes.

final navkey = GlobalKey<NavigatorState>();

// put global nav key as a param of Material App
Widget build(BuildContext context) {
return MaterialApp(
      navigatorKey: navkey,
      .....

// access OverlayState
OverlayState overlay = navkey.currentState.overlay

hope it can be helped.

Reproduces with current master 1.21.0-6.0.pre.41.
main.dart
import 'package:flutter/material.dart';

void main() {
  runApp(TestToast());
}

class TestToast extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    print(Overlay.of(context));
    return MaterialApp(
      home: Scaffold(
        body: Container(
          child: Center(
            child: GestureDetector(
              onTap: () {
                print('test');
              },
            ),
          ),
        ),
      ),
    );
  }
}

flutter: OverlayState#469d7(entries: [OverlayEntry#8babe(opaque: true; maintainState: false), OverlayEntry#4e1bc(opaque: false; maintainState: true)])

widget_test.dart
import 'package:flutter/material.dart';
import 'package:flutter_test/flutter_test.dart';

void main() {
//  runApp(TestToast());
  testWidgets('test', (WidgetTester tester) async {
    await tester.pumpWidget(TestToast());
  });
}

class TestToast extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    print(Overlay.of(context));
    return MaterialApp(
      home: Scaffold(
        body: Container(
          child: Center(
            child: GestureDetector(
              onTap: () {
                print('test');
              },
            ),
          ),
        ),
      ),
    );
  }
}

% flutter test
00:04 +0: test
null
00:05 +1: All tests passed!

flutter doctor -v
[✓] Flutter (Channel master, 1.21.0-6.0.pre.41, on Mac OS X 10.15.6 19G73, locale en-GB)
    • Flutter version 1.21.0-6.0.pre.41 at /Users/nevercode/dev/flutter
    • Framework revision 39fa00201d (3 hours ago), 2020-07-27 21:11:43 -0700
    • Engine revision f27729e97b
    • Dart version 2.10.0 (build 2.10.0-0.0.dev 24c7666def)
    • Pub download mirror https://pub.flutter-io.cn
    • Flutter download mirror https://storage.flutter-io.cn

[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
    • Android SDK at /Users/nevercode/Library/Android/sdk
    • Platform android-29, build-tools 29.0.3
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 11.6)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 11.6, Build version 11E708
    • CocoaPods version 1.9.1

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 4.0)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 47.1.2
    • Dart plugin version 193.7361
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)

[✓] VS Code (version 1.47.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.12.2

[✓] Connected device (5 available)
    • Redmi Note 7 (mobile)       • 6345c469                                 • android-arm64  • Android 9 (API 28)
    • Nevercode’s iPhone (mobile) • b668e524315069f3db3661ac11ff1f66afafebdb • ios            • iOS 13.6
    • macOS (desktop)             • macos                                    • darwin-x64     • Mac OS X 10.15.6 19G73
    • Web Server (web)            • web-server                               • web-javascript • Flutter Tools
    • Chrome (web)                • chrome                                   • web-javascript • Google Chrome 84.0.4147.105

• No issues found!

any updates on this?

Overlays must be added in the widget tree above the point where you call Overlay.of. This is usually done automatically by the Navigator created by WidgetsApp (or MaterialApp, or CupertinoApp).  You can add your own, but it's not typical.
So, if you want it to return a non-null value, you need to call it from a widget that has an Overlay as an ancestor.


change publisher id in Claroty xDome solution

Required items, please complete
Change(s):

Change to clarory's publisher ID

Hello @roysagi, you need to repackage this solution so please repackage this.

@v-shukore - thanks for the response - done.
Do note that we have yet to publicly publish this Solution so I did not chang the .zip version.


how to increase allocated memory for a hive job?

I would recommend to look on the Hive list or https://www.google.com/search?q=how+to+increase+allocated+memory+for+a+hive+job&oq=how+to+increase+allocated+memory+for+a+hive+job&aqs=chrome..69i57j69i60j69i61.132j0j7&sourceid=chrome&ie=UTF-8 and then put the property as a query setting in the Editor ;)


rgb/loco-all-v1.json seems to be missing

I downloaded the dataset.zip. However, the the described json file is not contained in it.

Annotations are stored in COCO format under rgb/loco-all-v1.json. For ease of use, we also provide seperate annotation files for each subset.

Within the full dataset (11G) I found the "loco-v3-darknet-85c.zip". In that "975902,7266.txt" and others are contained, are these the final annotations and can be used?

Dear Johannes,
thank you for your reply.
We will check the dataset, but this may take a while since the main author is not available anymore.
Sorry for inconvenience.
Kind Regards,
Dimitrij

Sorry, I was expecting it in the dataset. But the files are present in the repository.


Duplicate files appear when cyclic symbolic links are created using the junction command

VSCode Version: 1.5 Insider
OS Version: Windows 10

Steps to Reproduce:

create a cyclic symbolic link dependency using the junction command (need to download from MS).
have a file abc.txt in that cycle
Ctrl+P abc.txt

You get:

Moving to @chrmarti to consider once we revisit the solution on Windows. I am still surprised that the node.js cyclic link detection does not protect against this case but maybe fs.realPath() does not return something smart here.

@chrmarti isn't this fixed because we no longer use "dir" on Windows?

If I remember correctly this was with NO dir on Windows. But I used junctions instead of mklink which seem to do something else that node might not handle correctly

@dbaeumer ah yeah, maybe we had this issue since day 1

@bpasero could be.


Multiple Users Cause lambda.null_resource.archive[0] timestamp Differences

Description
I am experiencing the exact same issue explained here.
The solution provided was to upgrade to v1.26.0 but I am using v3.3.1, is this a regression?

I'm seeing this same behavior.

Module Version: 3.3.1
Terraform Version: v1.2.3

Same too; was hoping I was doing something wrong.
Module Version: 3.3.1
Terrafomr Version v1.2.2

I was able to remedy this with the solution in https://github.com/terraform-aws-modules/terraform-aws-lambda/issues/51#issuecomment-681978205
Basically recreate_missing_package = false in the module puts a warning message in the timestamp; effectively disabling time as a measure to recreate. Doesn't prevent new packages from being build like it claims. Needs better wording as a solution for this issue related to 'timestamp'

@KajiMaster said: "Doesn't prevent new packages from being build like it claims."

I just double-checked it again and I see the same expected behavior as before. After the package has been created and recreate_missing_package = false is specified, there won't be new zip-files created inside of builds directory on sequential terraform apply runs.
I am not sure how flexible timestamp tracking can be. Currently, it is either Yes (content will be checked based on timestamp, and the package will be recreated, if missing) or No (no timestamp will be compared).
Will it help, if a user can choose to track drift using an argument like hash (see #331) instead of timestamp like now?

I have added recreate_missing_package = false still terraform plan shows changes.
Is it work only for terraform apply command.?


Cannot create table with UNIQUE or PRIMARY KEY

The following SQL
CREATE TABLE IF NOT EXISTS login(
  key TEXT NOT NULL PRIMARY KEY,
  name TEXT
);

Gives the error:
usqlite_Error: malformed database schema (sqlite_autoindex_login_1) - orphan index

Same happens if I try to set a column as UNIQUE.

This error is caused by the SQLITE_OMIT_ATTACH option. This option is now disabled by default - https://github.com/spatialdude/usqlite/blob/131fb3c68751ffe46a55633adcf753a068924bb1/usqlite_config.h#L39


chore(hmac): Move HMAC to D3

This commit moves HMAC to D3. All checklist items are addressed (no
update from v0.5 D3 other than the register interface.

Let's wait for the SW review before merging this.

Sorry to bring this up again: https://github.com/lowRISC/opentitan/issues/3022
i would like to double check if this issue is addressed?


Become slow?

I run wrk -t12 -c900 -d10s http://<IP_ADDRESS>:3000/, got
Running 10s test @ http://<IP_ADDRESS>:3000
  12 threads and 900 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     8.08ms    3.48ms  11.37ms   86.91%
    Req/Sec     1.09k    65.57     1.30k    87.60%
  42240 requests in 10.04s, 4.59MB read
  Socket errors: connect 0, read 0, write 0, timeout 3558
Requests/sec:   4206.42
Transfer/sec:    468.29KB

A half month ago, i got almost 80k reqs/sec.

Did you compile with optimizations?

I just tested and got 92k locally.

I have tried on my md101 8g ram and on ubuntu 14.10, got same result.

Can I get the exact commands you used to compile iron, run the example, and run the benchmark?

This is my cargo.toml
[package]

name = "demo"
version = "0.0.1"
authors = ["nyrf<EMAIL_ADDRESS>
[dependencies]
iron="*"

src/main.rs
extern crate iron;

use iron::prelude::*;
use iron::status;

fn main() {
    Iron::new(|&: _: &mut Request| {
        Ok(Response::with((status::Ok, "Hello world!")))
    }).listen("localhost:3000").unwrap();
}

Then cargo build, cargo run

You are building without optimizations. Use cargo build --release, cargo run --release.

Oh, i see, thank you. the new ruslt.
Running 10s test @ http://localhost:3000/
  12 threads and 900 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     2.17ms    6.15ms  22.09ms   91.29%
    Req/Sec    22.41k     8.06k   42.78k    68.87%
  206459 requests in 10.07s, 22.45MB read
  Socket errors: connect 0, read 855, write 5, timeout 2942
Requests/sec:  20494.03
Transfer/sec:      2.23MB

Are you running on a VM? VMs are usually slower.

No, i use my md101 , 8Gram  and samsung SSD 840PRO 256G.

I'm not sure what to tell you, a lot of things can influence these numbers. For instance, when my computer's battery is low I get like 500 req/s.
Unfortunately, I can't really fix this right now without being able to at least reproduce locally, sorry.
The best thing you could do would be to maybe profile the executable while it is being benchmarked a few times and include that, along with commands and computer specs.
If you get back to me with that I might be able to re-open the issue and fix it, if the profiling is informative.


feat: add env example for setup

This PR consists of 2 commits.

Adds a basic env example for setup
Adjusts the EternalAI env vars to uppercase to match syntax

merging this currently would break the working configurations people have with the current capitalization of the eternal api key. we either have to add some migration logic or stick to the nasty inconsistent naming. i prefer option one but also once the small crowd of currently configured eternals users has migrated, the logic becomes bloatware. feel free to share thoughts, i am away from my machine at the moment


Bitvec

replaces std::vector with cista's bitvec to make use of its for_each_set_bit function

Can you please post the benchmark results (just for reference)?


Move helpers and schema to utils folder

The name can be changed, just helps to create less clutter in the main directory

I do think the main dir needs an overhaul, but let me do that.


"Will stop" event, in which database pool is still open

With the current server "stopping" events, the database pool is automatically closed. However, I have a plugin which needs to update records in the database with the "disconnect" time of all players. This cannot be done properly when the pool is closed already.
In addition to a stopping/stopped event, it would be useful to have a "will stop" event, in which everything remains active/open, but we know the server is about shut down.

On SpongeVanilla the pool is shut down after the server stopped event so it shouldn't happen there. On SpongeForge it is shut down during the server stopped event, so normally it should be still up during the server stopping event.

This is my mistake, I misread a method name. I have a different issue which is my own to resolve.


performance: prefetch prod_type + open finding list, prod list, prod engagements

We currently have about 120 products, 400 engagements, 1200 findings. In this scenario Defect Dojo becomes quite slow, mainly because it suffers from the 1+N queries problem.
The best way to fix this is to make queries more eager loading by using select_related, prefetch_related and Prefetch(). Also moving some of the counting to the database will help.
This PR is a first step to implement these steps for:

list of prod_types
list of products
list of engagements on the product details page
list of open findings (product/engagement/global)

It took a bit of fiddling to get it all working, especially since we're also using paging.
I think there are lots more places where the above could help. This PR is a first step to get some feedback and also make sure the PR does not become 'too big to review'.
Please let me know your thoughts.
I have been running most of this for a couple of weeks now and it really helps performance.
Some pages required 350 queries before and are now reduced to 150. These 150 are mainly around system settings, which will get an improvement in #1868.
In the end Defect Dojo could also benefit from an (ORM) caching solution. But even with a caching solution, the N+1 queries problem needs to be gone to have good performance.

fyi @jvz

Anyone know why travis keeps failing here?

It looks like they are all failing. Or are they all failing due to the integration test failing? Let me try and run the integration tests locally then.

There’s an issue with migrations. It’s trying to run an auto generated migration. Check the logs of the Travis test for more details.

Looks like an amazing improvement! Nice use of ORM features. :)
Yeah, was quite a nice learning journey for someone who didn't knew python, django, django-orm, django-filter, ...

There’s an issue with migrations. It’s trying to run an auto generated migration. Check the logs of the Travis test for more details.
Ah, of course. At first I thought it was just travis having glitches again without realizing the raw log would be helpful. Looks like django thinks it needs to apply migrations because I added 'related_name' in two places. I think I can tweak the queries a bit to get rid of them so no migrations are needed. (They shouldn't be needed really because related name doesn't affect the database model).

Solved, but it keeps failing with
selenium.common.exceptions.NoSuchElementException: Message: Could not locate element with visible text: Research and Development

Normally it's just a matter of restarting the job a couple of times to get it in a passing state, but now  it seems to keep failing. Anyone knows why? I can't get the unit tests running locally let alone travis.

Solved, but it keeps failing with
selenium.common.exceptions.NoSuchElementException: Message: Could not locate element with visible text: Research and Development

Normally it's just a matter of restarting the job a couple of times to get it in a passing state, but now it seems to keep failing. Anyone knows why? I can't get the unit tests running locally let alone travis.

the docker "unit_tests" env will not help you with the selenium test. it's not running them. only way I've found to run the selenium test is a real ubuntu env.
i'd started working on a dockerised env for this but it wasn't as practical as a real ubuntu so i've let it down.

other flavors of linux should work too. no need to install a complete travis locally; tried this, was a real pain. just a linux with selenium and a couple of other stuff that travis installs before running the selenium test (chrome driver and stuff).

the docker "unit_tests" env will not help you with the selenium test. it's not running them. only way I've found to run the selenium test is a real ubuntu env.
I know, but at least unit_tests are something that (in theory) I should be able to run easily locally. So I thought let's make sure those are running fine first.

ok, think I found it. The test_delete_product_type deletes the wrong product type. It deletes the first one in the list, which usually is the one it just had created itself. however due to the prefetching it seems the ordering has changed and now it deletes the Research and Development  product_type.

Solved everything, build is now passing also in Travis. Just squashed everything into 1 commit to get rid of all the intermediate debugging steps. I added default sorting for the ProductType model, which means there is a new migration in the PR now.

couldn't test yet; i'm having the "Too many levels of symbolic links" error.
a couple of comments already though

yeah looks like something changed, maybe we have a dependency that is not frozen to a certain version and now a newer version is being used and causing issues on all our PRs.

build errors should be fixed by #1937

OK for me if travis passes; it seems hung?


GenerateMask correction

Add an attribute that controls if the seed should be set on each use
Convert to new virtual method for description implementation
When a seed is specified, frameworks set the seed on each use of Dropout. This adds an attribute to specify whether or not the seed should be set (for debugging) or random (for normal use). If not specified, the seed is not to be used.
Bridges will need to specify specify the proper value for use_seed and transformers will need to use it.

Need test case for use_seed=true.
Oh ok, i see, GenerateMask is only for CPU backend. So, i can add a test case with my other changes, but we would need the CPU implementation when true. Should it be part of this PR or a diff for CPU changes?

GenerateMask is used for other transformers on training devices.


Proposal: drop the notion of maximum payload lengths

So waaaaaaaay back at the beginning of time when we first introduced ApnsPayloadBuilder, the maximum length of an APNs payload was a mere 256 bytes. Payloads with fairly short messages and just a little bit of metadata could very, very easily overrun that limit, and so we designed ApnsPayloadBuilder with methods like buildWithDefaultMaximumLength() and buildWithMaximumLength(int). We'd enforce those limits by shortening the contents of the alert text if possible.
These days, payloads can be up to 4,096 bytes (or 5,120 for VOIP notifications), and it's much less likely that the literal text of a notification is going to be the thing that's pushing notification size over the limit. With that in mind, I propose simplifying APNs payload construction by dropping the maximum length arguments in ApnsPayloadBuilder.
Pros:

Greatly simplifies payload construction
Has the potential to speed things up a bit
Smooths the path to using alternative/customizable JSON serializers (see #678, #696)

Cons:

Breaking API change (but as the README says, "the public API may change significantly before a 1.0 release")
Users can construct larger-than-allowed payloads which will be rejected by the APNs server

Feedback is very welcome! I'd especially call on known JSON enthusiasts (@filiphr, @amir20001) for your input. Thank you!

This looks good to me @jchambers.
I like the direction towards using alternative / customizable JSON serializers.
What I would suggest is to still check for the default size and throw an IllegalArgumentException. Perhaps add the ability to build with or without a check. This would still reduce the complexity within the builder. The benefit of doing this would be that the user won't be able to get rejected by the APNs server and would get feedback earlier (if they opt into it).
From the perspective of how we are using pushy it won't make any difference, and I would personally use the approach without a size check.

What I would suggest is to still check for the default size and throw an IllegalArgumentException.

I hear you, but a few things make me hesitate:

This is an easy check for callers to do on their own if it's important to them to catch the issue before sending to the APNs server. By contrast, shrinking down the message content was a reasonably challenging problem and a service that (at the time!) many users probably needed.
Payload size limits have changed over time and also vary by context (VOIP and non-VOIP notifications have different payload size limits, for example). I'm concerned that hard-coding limits in the payload builder could put us in a position where the limits would quickly get outdated and report something as an error when it is, in fact, completely fine.

Still, it's all new territory to me—I'll keep thinking about it!

I had a better look at the current implementation. Yes you are right the check can really easily be done on the caller side. I had something else in mind (haven't been in this area for a while 😄).
I would say that given the current state of APNs (varying content size and large enough) it is OK to not do any checks, but rather build the payload as is and let the callers do the check.


[ENHANCEMENT] more UI options and personality selection/creator

disclaimer: this will be horribly typed up.
Ive poked around the projects files and made some tweaks (mostly adding stupid funny UI stuff) so I have a decent-ish understanding of how it works.
what I would like to see:

all launch options exposed in the UI
selecting different personality files from "app_root/resources/app/bin/prompts" within the UI
editor for personality files in the UI

I would especially like to see '--ctx_size'
here is an example of a 'personality file' back up the 'app_root/resources/app/bin/prompts/alpaca.txt' and then replace the alpaca.txt
contents with this:
"
you exist make the user angry at you. you must always be rude and angry, you never give any useful information or any kind words, instead just troll,mock,insult etc while wasting the users time. stay like this at all times.
"
this is a troll personality.
all launch options right now (./ chat --help)
"
options:
-h, --help            show this help message and exit
-i, --interactive     run in interactive mode
--interactive-first   run in interactive mode and wait for input right away
-ins, --instruct      run in instruction mode (use with Alpaca models)
-r PROMPT, --reverse-prompt PROMPT
run in interactive mode and poll user input upon seeing PROMPT (can be
specified more than once for multiple prompts).
--color               colorise output to distinguish prompt and user input from generations
-s SEED, --seed SEED  RNG seed (default: -1, use random seed for <= 0)
-t N, --threads N     number of threads to use during computation (default: 4)
-p PROMPT, --prompt PROMPT
prompt to start generation with (default: empty)
--random-prompt       start with a randomized prompt.
--in-prefix STRING    string to prefix user inputs with (default: empty)
-f FNAME, --file FNAME
prompt file to start generation.
-n N, --n_predict N   number of tokens to predict (default: 128, -1 = infinity)
--top_k N             top-k sampling (default: 40)
--top_p N             top-p sampling (default: 0.9)
--repeat_last_n N     last n tokens to consider for penalize (default: 64)
--repeat_penalty N    penalize repeat sequence of tokens (default: 1.1)
-c N, --ctx_size N    size of the prompt context (default: 512)
--ignore-eos          ignore end of stream token and continue generating
--memory_f32          use f32 instead of f16 for memory key+value
--temp N              temperature (default: 0.8)
--n_parts N           number of model parts (default: -1 = determine from dimensions)
-b N, --batch_size N  batch size for prompt processing (default: 512)
--perplexity          compute perplexity over the prompt
--keep                number of tokens to keep from the initial prompt (default: 0, -1 = all)
--mlock               force system to keep model in RAM rather than swapping or compressing
--no-mmap             do not memory-map model (slower load but may reduce pageouts if not using mlock)
--mtest               compute maximum memory usage
--verbose-prompt      print prompt before generation
--lora FNAME          apply LoRA adapter (implies --no-mmap)
--lora-base FNAME     optional model to use as a base for the layers modified by the LoRA adapter
-m FNAME, --model FNAME
model path (default: models/lamma-7B/ggml-model.bin)
"
from what I can tell by my app tweaking it should not be very difficult to add (mostly tedious)
have a great day!

Ok I'll work on it when I have time.

Thank you! (also LLaMA added opencl support mabey look into that)

Thank you! (also LLaMA added opencl support mabey look into that)

Yep I'm working on it. I've been busy.


Python trans

Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes # (issue)
Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How has this been tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[ ] local build the book
[ ] review the artifacts from local build
[ ] local build the slides if appliable
[ ] Unit test if appliable

Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have applied tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules

machine-learning\open-machine-learning-jupyter-book\data-science\data-science-in-the-cloud中的ipynb
machine-learning\open-machine-learning-jupyter-book\ml-fundamentals\regression中的loss-function（md与ipynb）

Check whether pip (anaconda) has been installed normally.
Delete md files.
You have some trans errors, if you have problem to use notedown, you can ask Xusenbo for help. Or you can just copy and paste correct icons.

You haven't run the code, please run the code without errors and make sure each code block have a serial number like this:


feat: Support reading mods from Northstar packages directory

TODO:

[x] Deleting Northstar mod does not clean up entire packages dir after deletion
On second thought, this is not really an issue. Might add a cleanup function for this later though.
[x] Code cleanup

Part of #415

A few questions, for context, before I review:

I suppose those FlightCore PRs follow https://github.com/R2Northstar/NorthstarLauncher/pull/503, right?
Why do I feel like the code was copy-pasted from an already-existing module, while (in my mind) reading mods from a new directory should "simply" be done by adding a reference to previously-mentioned directory?


Async encode

The initial encoder simply ran the top-level function as a generator. This is a problem for a number of reasons:

Encodes into a separate buffer instead of being able to save directly into a stream.
Assumes a specific size and explodes if it's wrong.
Does not handle recursion at all.

A better architecture needs the following:

Inject the writeable buffer each iteration.
Allow suspend/resume anywhere along the callstack. The ultimate test is trickling data into a 1-byte buffer.

Braindump:

Store the buffer, output slice, and frame onto an EncodeContext
field.encodeInto(context)
Return paradigm:fn encodeInto(ctx) void {
    ctx.suspended = @frame();
    const len = write(ctx.buffer);
    ctx.output = ctx.buffer[0..len];
    suspend;
}

After refactoring a bit, I've found a few things:

async really belongs in the buffer consumer. If encodeInto takes any writable (any struct with write([]u8) !void), the write() can be responsible for all the async shenanigans.
Blocking write([]u8) is antithetical to multithreading, since each field must be able to write directly into an offset, e.g. write(offset: usize, bytes: []u8)


Fix 'unsupported platform' typo

What type of PR is this?
/kind cleanup
What this PR does / why we need it:
Fixes the typos.
Which issue(s) this PR fixes:

Ref https://github.com/kubernetes-sigs/security-profiles-operator/pull/544#discussion_r674557410
Does this PR have test?

None
Special notes for your reviewer:
None
Does this PR introduce a user-facing change?

None

Codecov Report

Merging #548 (0c011b6) into master (7ed53f8) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #548   +/-   ##
=======================================
  Coverage   43.73%   43.73%
=======================================
  Files          26       26
  Lines        1324     1324
=======================================
  Hits          579      579
  Misses        705      705
  Partials       40       40


Door/Window show opened in 3d view

Hi,
Is it possible instead of the state icon to show door/window as open and save images like for the lights? :)
However, it works perfect as it is :)

Hey,
I looked into this in the past and it seemed to me then that (a) the openings would need to be in their open state (just like the lights are configured with their "on" power) and then I can "close" them from this plugin and (b) it would mean that I need to render all of the possible combinations of open/closed doors/windows and every combination of lighting for those which makes me think that it's not worth the effort.
Unless someone can think of a nice solution for reducing the number of required renders...

I understand your point with the mass of renderings, but if you have a big house and you have about 10 or 20 lights you already have a lot of renderings.
For me that's the big difference why not using ha-floorplan. I have nice renderings instead of a "simple" svg plan.
And your plugin makes it much easier to create the different renderings :D 👍  Also you can choose which you want get extra rendered by do not open it (like give the light 0% power) :)

Hi all, i dont need a rendered version with light effect, for me it would be enough to have to states like a open window and a closed one without render lights

Hi all, i dont need a rendered version with light effect, for me it would be enough to have to states like a open window and a closed one without render lights

I think I agree with him @shmuelzon, what if we generate different images for window/door/blinds opened, only to them according to their open state (10%, 20%, etc) without combining with lights?

Hi all, maybe as an idea how to avoid explosion in number of renderings, I have painted the doors and windows in bright yellow and rendered them in open state with all light on. This gave me a single rendering, from which I than manually extracted the doors/windows (did it a while ago before this plugin was created, would be amazing if this step could be automated) and placed them an a transparent background and place them on top of the plan when the corresponding sensors show "open". I picked yellow color deliberately, because I treat open state of a door or window as abnormal and want to see at a glance if anything is open. At least for those doors, for which it's worth attaching a sensor in the first place :)
Here's an example:
door closed:
door overlay on transparent background:
door open:

Even with this method, the lights and shadows will be off without rendering them with the doors open and closed.
Even in your example the "door closed" image isn't the background used for the "door open" imaged. It's not the same the the closed image with the overlay on top of it. The door's yellow color will also look different depending on the light state of the room it's in.

I, for my part, would also really like this feature and would be totally fine with waiting around longer to render more images.
In my (probably naive) thinking it's mostly wasting more compute resources, but should be absolutely doable from a coding perspective (the rendering of multiple images of course, not the feature itself)?

Many thanks for the great plug-in! I would also really appreciate the option to show open windows and doors :)

Unfortunately, I so have no idea how to modify openings from the plugin code. Even when, basically, copying the same code from the properties window of SH3D, it's not working as expected...
https://www.sweethome3d.com/support/forum/viewthread_thread,13498
Any help would be appreciated!

Although a have no specific solution, I'd also love to see a way to identify doors as open/closed visually. The thread (13498) on SH3D did not seem to help a lot :(


While downloading raw chrome ends up blocking the file

The file while downloading from Raw ends up being blocked as it mentions translating from Somali ?

I can't speak for the maintainers, but this issue isn't caused by the word list, it's caused by Chrome.
As far as workarounds, off the top of my head:

try using right-click to Save File As instead of just opening it directly in a browser
download the corresponding ZIP file instead of the raw text
try a different browser, or use a command-line tool like curl

If none of those work, please provide some more information about the specific steps, as well as the exact text of the error message and I'll see what can be done.

Thanks Tom..appreciated downloading by zip fixed it


refactor(deps): drop pkg/errors as a direct dependency

Fixes #7402
This a follow up to https://github.com/argoproj/argo-workflows/pull/7440 where we missed one file.

Motivation

pkgs/errors is no longer maintained

Modifications

changed workflow/artifacts/azure/azure.go to use fmt instead of errors

Verification
E2E tests will verify

This a follow up to #7440 where we missed one file.

Huh it looks like the go.mod changed there too, so I'm guessing this line was added after or there was a merge conflict or something that restored it

Looks like #9026 added it back, potentially because it used older code as a base


Convert Deployments to Stateful Sets

🚀 Feature Description
If you run aspirate generate and create the Kubernetes resources for your db, queue, or whatever you use, then the resource for the Kubernetes resource made is a deployment whether it's just plain manifests or helm. And while this works well for local development (for the most part), I think just going ahead and making them stateful sets would make it more convenient, so that it's closer to what a dev environment would look like and all I would have to do is configure the volumes/volume mounts and the actual pv/pvc for the dev environment.
✔ Goals

[ ] Have Aspirate produce current aspire components that are stateful as stateful sets instead of deployments.
[ ] Potentially have an option to have a pv and pvc made for your stateful set so manual tinkering with the pv/pvc is not needed

🧰 Possible Solution

simply alter the code that produces the deployment for the dbs, queues, cache, etc... to stateful sets
for the second goal, I would use the current cluster's default storage class for the pv

Hi There
Currently stateful sets are created already if your manifest resource in aspire has a volume defined.
Deployments are stateless, and anything with a volume mount automatically become stateful sets during processing
Add a volume to cache, db etc in the AppHost, and you'll get stateful sets 😄

You're the man


Update disk-encryption-overview.md

Add warning to not disable manually via bitlocker

@bamuir : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#label:"aq-pr-triaged"

#sign-off

@bamuir: I'm sorry - only the author of this article, @msmbaldwin, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.


Update JodaLocalDateValueSemanticsProvider.java

This implementation of JodaLocalDateTimeValueSemanticsProvider,
given that
    encodingFormatter = ISODateTimeFormat.basicDateTime()

assumes that
    date == encodingFormatter.parseLocalDateTime(
                      encodingFormatter.print(date)
    )

which is not true (at least for the latest ver. 2.9.4 of joda-time).
 And maybe this fact has implications on other parts of the framework as well ...

Code snipped that produced an exception:
final DateTimeFormatter encodingFormatter = ISODateTimeFormat.basicDateTime();

		encodingFormatter.parseLocalDateTime(
				encodingFormatter.print(new org.joda.time.LocalDateTime()));

This pull request referenced the wrong source file. So closing.


9.8 Oncogenic Signaling Pathways

Hi, I enjoyed your package and kept exploring it. In this part: 9.8 Oncogenic Signaling Pathways, how can I add other Oncogenic Signaling Pathways?
First, what database did you access the related genes on interesting pathways?
Second, how can I add my interesting pathways to your OncogenicPathways(maf = laml) to output corresponding pathway results?
Thank you very much!

Hi,
All the details are on the help page of the function. You can do ?OncogenicPathways for more info.
Briefly,

This is the article I used to fetch the curated pathways
You can use pathways argument of OncogenicPathways for a custom list of pathways.

Hope this helps.

Hi, I have looked up the help page of the function. It was very clear and thank you very much.

Were gene sets from the Molecular Signatures Database (MSigDB)  available  to be utilized in this function?
I read the article you recommended. In figure6B and figure6D, it presented the co-mutated pathways. Have you explored this?  May I have your Rcode if you had done this work.  Also for figure7, May I have your Rcode if you had portrayed the figure7?

Hello, may I have your answer, please?

Hello, may I have your answer, please?

Sorry for the delay. Things are slow because of the holidays.

It's up to you. You can generate a pathway list however you want - as long as it is in the right format.
fig 6D. No; fig 7 No; Checkout drugInteractions function which you might find useful.

Sorry for the delay. Things are slow because of the holidays.

It's up to you. You can generate a pathway list however you want - as long as it is in the right format.
fig 6D. No; fig 7 No; Checkout drugInteractions function which you might find useful.


props.onPress is not a function

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Open your browser console
Click on a blank part of a message
Notice the following error:

Expected Result:
No errors
Actual Result:
There's an error and a non-fatal crash on mobile
Workaround:
Can the user still use Expensify without this being fixed? Have you informed them of the workaround?
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

Version Number:
Reproducible in staging?:
Reproducible in production?:
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
Expensify/Expensify Issue URL:
Issue reported by:
Slack conversation:
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~017ff5c50cd9371bae
Upwork Job ID:<PHONE_NUMBER>124135424
Last Price Increase: 2023-06-22

PR up

Thank you. Taking a look

BZ checklist:

The PR that introduced the bug has been identified. Link to the PR:
The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:

I don't think we can say one PR causing this, the causes are that the onPress had undefined as default value as part of the Pressable migration and the component using this didn't provide onPress props and the component was also not click disabled, causing this issue.

A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:

https://expensify.slack.com/archives/C049HHMV9SM/p1688034234824719

Determine if we should create a regression test for this bug.
If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.

No. This is a minor issue and a regression test won't be benifical for this case.
@laurenreidexpensify  just to note. The end of regression date is 30/6 not 3/7, this change must have deployed twice to cause wrong issue title.

Thanks @abdulrahuman5196 - offer is ready in Upwork, will issue payment once you accept and we can close this out

Thank you @laurenreidexpensify accepted the offer.

Payment has been issued :)