inline several fn

I don't know if it was intentional or not but a lot of very simple fn were not inlined.
This speeds up the benchs:
$ cargo benchcmp old new
 name                                                                      old ns/iter  new ns/iter  diff ns/iter   diff %  speedup
 affine::test::bench_affine_bilinear                                       1,060,086    1,049,122         -10,964   -1.03%   x 1.01
 affine::test::bench_affine_nearest                                        385,276      390,808             5,532    1.44%   x 0.99
 affine::test::bench_rotate_bilinear                                       539,853      516,242           -23,611   -4.37%   x 1.05
 affine::test::bench_rotate_nearest                                        403,994      411,252             7,258    1.80%   x 0.98
 affine::test::bench_translate                                             355,762      348,238            -7,524   -2.11%   x 1.02
 contrast::test::bench_adaptive_threshold                                  481,960      492,839            10,879    2.26%   x 0.98
 contrast::test::bench_equalize_histogram                                  820,474      825,476             5,002    0.61%   x 0.99
 contrast::test::bench_equalize_histogram_mut                              797,083      793,388            -3,695   -0.46%   x 1.00
 contrast::test::bench_match_histogram                                     146,760      143,791            -2,969   -2.02%   x 1.02
 contrast::test::bench_match_histogram_mut                                 190,618      186,186            -4,432   -2.33%   x 1.02
 contrast::test::bench_otsu_level                                          29,091       26,919             -2,172   -7.47%   x 1.08
 contrast::test::bench_stretch_contrast                                    308,122      277,967           -30,155   -9.79%   x 1.11
 contrast::test::bench_stretch_contrast_mut                                262,289      253,075            -9,214   -3.51%   x 1.04
 contrast::test::bench_threshold                                           34,478       32,217             -2,261   -6.56%   x 1.07
 contrast::test::bench_threshold_mut                                       12,970       12,611               -359   -2.77%   x 1.03
 corners::test::bench_is_corner_fast12_12_noncontiguous                    31           31                      0    0.00%   x 1.00
 corners::test::bench_is_corner_fast9_9_contiguous_lighter_pixels          26           27                      1    3.85%   x 0.96
 distance_transform::test::bench_distance_transform_l1_10                  394          442                    48   12.18%   x 0.89
 distance_transform::test::bench_distance_transform_l1_100                 32,025       33,103              1,078    3.37%   x 0.97
 distance_transform::test::bench_distance_transform_l1_200                 126,177      122,459            -3,718   -2.95%   x 1.03
 distance_transform::test::bench_distance_transform_linf_10                531          575                    44    8.29%   x 0.92
 distance_transform::test::bench_distance_transform_linf_100               43,760       45,947              2,187    5.00%   x 0.95
 distance_transform::test::bench_distance_transform_linf_200               181,810      180,838              -972   -0.53%   x 1.01
 distance_transform::test::bench_euclidean_squared_distance_transform_10   2,329        2,256                 -73   -3.13%   x 1.03
 distance_transform::test::bench_euclidean_squared_distance_transform_100  221,064      209,920           -11,144   -5.04%   x 1.05
 distance_transform::test::bench_euclidean_squared_distance_transform_200  1,024,099    879,749          -144,350  -14.10%   x 1.16
 drawing::bezier::test::bench_draw_cubic_bezier_curve_long                 8,691        8,777                  86    0.99%   x 0.99
 drawing::bezier::test::bench_draw_cubic_bezier_curve_short                418          377                   -41   -9.81%   x 1.11
 drawing::conics::test::bench_bench_filled_ellipse_circle                  51,125       44,916             -6,209  -12.14%   x 1.14
 drawing::conics::test::bench_bench_filled_ellipse_horizontal              58,417       47,377            -11,040  -18.90%   x 1.23
 drawing::conics::test::bench_bench_filled_ellipse_vertical                30,618       28,019             -2,599   -8.49%   x 1.09
 drawing::conics::test::bench_bench_hollow_ellipse_circle                  894          793                  -101  -11.30%   x 1.13
 drawing::conics::test::bench_bench_hollow_ellipse_horizontal              1,215        1,244                  29    2.39%   x 0.98
 drawing::conics::test::bench_bench_hollow_ellipse_vertical                1,342        1,311                 -31   -2.31%   x 1.02
 drawing::line::test::bench_draw_antialiased_line_segment_diagonal         4,692        4,226                -466   -9.93%   x 1.11
 drawing::line::test::bench_draw_antialiased_line_segment_horizontal       4,616        4,287                -329   -7.13%   x 1.08
 drawing::line::test::bench_draw_antialiased_line_segment_shallow          4,959        4,581                -378   -7.62%   x 1.08
 drawing::line::test::bench_draw_antialiased_line_segment_vertical         4,011        3,645                -366   -9.12%   x 1.10
 drawing::rect::test::bench_draw_filled_rect_mut_rgb                       6,869        6,414                -455   -6.62%   x 1.07
 edges::test::bench_canny                                                  5,391,393    4,956,584        -434,809   -8.06%   x 1.09
 filter::median::test::bench_median_filter_s100_r1                         190,236      173,910           -16,326   -8.58%   x 1.09
 filter::median::test::bench_median_filter_s100_r4                         424,805      321,859          -102,946  -24.23%   x 1.32
 filter::median::test::bench_median_filter_s100_r8                         534,731      481,710           -53,021   -9.92%   x 1.11
 filter::test::bench_box_filter                                            3,601,140    3,289,749        -311,391   -8.65%   x 1.09
 filter::test::bench_filter3x3_i32_filter                                  3,003,927    2,671,652        -332,275  -11.06%   x 1.12
 filter::test::bench_gaussian_f32_stdev_1                                  566,120      472,646           -93,474  -16.51%   x 1.20
 filter::test::bench_gaussian_f32_stdev_10                                 3,573,414    3,539,462         -33,952   -0.95%   x 1.01
 filter::test::bench_gaussian_f32_stdev_3                                  1,135,811    1,106,210         -29,601   -2.61%   x 1.03
 filter::test::bench_horizontal_filter                                     3,195,697    3,296,411         100,714    3.15%   x 0.97
 filter::test::bench_separable_filter                                      2,351,096    2,306,206         -44,890   -1.91%   x 1.02
 filter::test::bench_vertical_filter                                       3,163,233    3,181,572          18,339    0.58%   x 0.99
 gradients::test::bench_sobel_gradients                                    5,635,648    5,758,177         122,529    2.17%   x 0.98
 haar::test::bench_evaluate_all_features_10x10                             88,541       86,104             -2,437   -2.75%   x 1.03
 hog::test::bench_hog                                                      787,388      778,400            -8,988   -1.14%   x 1.01
 hough::test::bench_detect_lines                                           8,603,345    8,729,713         126,368    1.47%   x 0.99
 integral_image::test::bench_column_running_sum                            1,123        1,106                 -17   -1.51%   x 1.02
 integral_image::test::bench_integral_image_gray                           806,338      816,345            10,007    1.24%   x 0.99
 integral_image::test::bench_integral_image_rgb                            2,243,331    2,202,042         -41,289   -1.84%   x 1.02
 integral_image::test::bench_row_running_sum                               736          707                   -29   -3.94%   x 1.04
 local_binary_patterns::test::bench_local_binary_pattern                   4,026        4,053                  27    0.67%   x 0.99
 morphology::test::bench_dilate_l1_5                                       1,233,154    1,263,939          30,785    2.50%   x 0.98
 morphology::test::bench_dilate_linf_5                                     1,954,790    1,950,987          -3,803   -0.19%   x 1.00
 noise::test::bench_gaussian_noise_mut                                     186,482      184,793            -1,689   -0.91%   x 1.01
 noise::test::bench_salt_and_pepper_noise_mut                              139,768      137,707            -2,061   -1.47%   x 1.01
 pixelops::test::bench_interpolate_gray                                    3            3                       0    0.00%   x 1.00
 pixelops::test::bench_interpolate_rgb                                     9            10                      1   11.11%   x 0.90
 pixelops::test::bench_weighted_sum_gray                                   3            3                       0    0.00%   x 1.00
 pixelops::test::bench_weighted_sum_rgb                                    9            9                       0    0.00%   x 1.00
 region_labelling::test::bench_connected_components_eight_chessboard       1,880,388    1,869,256         -11,132   -0.59%   x 1.01
 region_labelling::test::bench_connected_components_four_chessboard        1,131,488    1,220,058          88,570    7.83%   x 0.93
 seam_carving::test::bench_shrink_width_s100_r1                            262,258      273,173            10,915    4.16%   x 0.96
 seam_carving::test::bench_shrink_width_s100_r4                            1,045,460    1,059,303          13,843    1.32%   x 0.99
 seam_carving::test::bench_shrink_width_s100_r8                            2,053,433    2,062,387           8,954    0.44%   x 1.00
 stats::test::bench_root_mean_squared_error_gray                           9,300        9,365                  65    0.70%   x 0.99
 stats::test::bench_root_mean_squared_error_rgb                            21,048       21,849                801    3.81%   x 0.96
 suppress::test::bench_local_maxima_dense                                  38,865       37,484             -1,381   -3.55%   x 1.04
 suppress::test::bench_local_maxima_sparse                                 52,855       45,420             -7,435  -14.07%   x 1.16
 suppress::test::bench_suppress_non_maximum_decreasing_gradient            1,156        1,226                  70    6.06%   x 0.94
 suppress::test::bench_suppress_non_maximum_increasing_gradient            1,870        1,642                -228  -12.19%   x 1.14
 suppress::test::bench_suppress_non_maximum_noise_1                        5,249        5,174                 -75   -1.43%   x 1.01
 suppress::test::bench_suppress_non_maximum_noise_3                        3,462        3,130                -332   -9.59%   x 1.11
 suppress::test::bench_suppress_non_maximum_noise_7                        2,649        2,389                -260   -9.82%   x 1.11
 template_matching::tests::bench_match_template_s100_t16_sse               3,617,652    3,222,230        -395,422  -10.93%   x 1.12
 template_matching::tests::bench_match_template_s100_t16_sse_norm          3,338,147    3,194,789        -143,358   -4.29%   x 1.04
 template_matching::tests::bench_match_template_s100_t1_sse                58,295       51,316             -6,979  -11.97%   x 1.14
 template_matching::tests::bench_match_template_s100_t1_sse_norm           57,999       53,262             -4,737   -8.17%   x 1.09
 template_matching::tests::bench_match_template_s100_t4_sse                350,150      313,151           -36,999  -10.57%   x 1.12
 template_matching::tests::bench_match_template_s100_t4_sse_norm           320,823      309,388           -11,435   -3.56%   x 1.04
 union_find::test::bench_disjoint_set_forest                               376,851      380,842             3,991    1.06%   x 0.99

Throwing [inline] everywhere seems a bit excessive, for example I am skeptical the affine or rotate methods actually benefit from it. But it definitely sounds good on such simple things such as is_empty, interpolated, etc.

Initially I wanted to inline only a few (but every fn i tried was having a measurable gain.
Anyway I'll make some more tests.

Ok. I agree of course not inlining everything. The right balance is hard to get. I have inlined function that looked small enough (to me). Can definitely be reviewed. I'll provide some binary size figures but it won't be too relevant as most of these functions are public and could bubble up out of the crate.

Sorry, I missed the fact that you’d now removed all but two of the inline annotations. Thanks for the suggestion and speed up.


Better types definitions - pyright

Can ujenkins better support return types(mostly for async staff)? When I use AsyncJenkinsClient and call for example hw_jenkins.builds.get_artifact() the return type is Bytes so when I await for that then pyright will return error: "bytes" is not awaitable (reportGeneralTypeIssues). To resolve these issues it is required to do casting on each function call cast(Awaitable[bytes], hw_jenkins.builds.get_artifact()).

Thanks for bug report. I need time to investigate it.
It's probably because one code base for both sync and async adapters, but function signatures are same.
If you have some good solution or idea your PR is welcome!

I will try to use overloads and approach described below:
https://github.com/microsoft/pyright/discussions/5629#discussioncomment-6621771

Original problem:
import asyncio

from typing import Any

class Builds:
    def __init__(self, jenkins) -> None:
        self.jenkins = jenkins

    def get(self, name: str) -> str:
        return self.jenkins._request(name)

class Jenkins:
    def __init__(self) -> None:
        self.builds = Builds(self)

class AsyncJenkinsClient(Jenkins):
    async def _request(self, name: str) -> Any:
        return name

class JenkinsClient(Jenkins):
    def _request(self, name: str) -> Any:
        return name

async def main():
    client = AsyncJenkinsClient()
    result = await client.builds.get('async')
    print(result)

    client = JenkinsClient()
    result = client.builds.get('sync')
    print(result)

asyncio.run(main())

I suggest to use .pyi files for function signatures with @propery to prevent less code readability.
PoC with correct types:

import asyncio

from typing import Any, Coroutine, overload, TypeVar, Generic, Union

ClientT = TypeVar('ClientT', bound=Union['JenkinsClient', 'AsyncJenkinsClient'])

class Builds(Generic[ClientT]):
    def __init__(self, jenkins: ClientT) -> None:
        self.jenkins = jenkins

    @overload
    def get(self: 'Builds[JenkinsClient]', name: str) -> str:
        ...

    @overload
    def get(self: 'Builds[AsyncJenkinsClient]', name: str) -> Coroutine[Any, Any, str]:
        ...

    def get(self, name: str) -> str | Coroutine[Any, Any, str]:
        return self.jenkins._request(name)

class AsyncJenkinsClient:
    def __init__(self) -> None:
        self.builds = Builds(self)

    async def _request(self, name: str) -> Any:
        return name

class JenkinsClient:
    def __init__(self) -> None:
        self.builds = Builds(self)

    def _request(self, name: str) -> Any:
        return name

async def main() -> None:
    async_client = AsyncJenkinsClient()
    result = await async_client.builds.get('async')
    print(result)

    client = JenkinsClient()
    result = client.builds.get('sync')
    print(result)

asyncio.run(main())

I suggest to use .pyi files for function signatures with @propery to prevent less code readability.
PoC with correct types:

import asyncio

from typing import Any, Coroutine, overload, TypeVar, Generic, Union

ClientT = TypeVar('ClientT', bound=Union['JenkinsClient', 'AsyncJenkinsClient'])

class Builds(Generic[ClientT]):
    def __init__(self, jenkins: ClientT) -> None:
        self.jenkins = jenkins

    @overload
    def get(self: 'Builds[JenkinsClient]', name: str) -> str:
        ...

    @overload
    def get(self: 'Builds[AsyncJenkinsClient]', name: str) -> Coroutine[Any, Any, str]:
        ...

    def get(self, name: str) -> str | Coroutine[Any, Any, str]:
        return self.jenkins._request(name)

class AsyncJenkinsClient:
    def __init__(self) -> None:
        self.builds = Builds(self)

    async def _request(self, name: str) -> Any:
        return name

class JenkinsClient:
    def __init__(self) -> None:
        self.builds = Builds(self)

    def _request(self, name: str) -> Any:
        return name

async def main() -> None:
    async_client = AsyncJenkinsClient()
    result = await async_client.builds.get('async')
    print(result)

    client = JenkinsClient()
    result = client.builds.get('sync')
    print(result)

asyncio.run(main())


[DEV] - Plans for 0.1.0

Sometimes soonish, we can make an initial 0.1.0 release with an initial alpha version of the module. This issue collects things to do for this initial release.
Code updates (functionality):

[x] general plot updates (done in #79)
[x] add the start of the sims sub-module (done in #21)
[x] figure out a plan for the objects (in progress in #19)

Module updates:

[x] finish an initial test suite (done in #34)
[x] add doctests to (some) functions (done in #30)
[x] do a sweep for organization & name consistency

[x] for example, having spiketools/spatial/ and spiketools/plts/space is inconsistent
[x] we mix between the terms "firing rate" and "spike rate"

[x] fix up some module conventions (overview in #13)

[x] standardize units & approaches (in progress in #11 & #12)

Documentation updates:

[x] fix up the glossary page, including a sweep for consistent terminology (#119)
[x] fix up README, including defining scope, etc
[x] draft some initial tutorials (#32)

Calling this done!!


C_CPP: Pre-Defined Manipulators

Description
documentation
Domain
C/CPP
Type of Contribution
Documentation
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of this project.

/assign


Linux AppImage + GH Actions

This PR adds AppImage packaging for Linux.
README
Both the main and builds/linux/ readme updated.
Structure
An FHS-like path is needed, placed in builds/linux/appdir.
fingertip and hnsd binaries must be placed in builds/linux/appdir/usr/bin. Other files like .desktop and icons are in their respective locations.
Desktop integration
Icon loads properly:

Taskbar:

Icons
Desktop files require png only, so extracted from the existing fingertip.ico file.
GH Action
Triggers on push and for pull requests. Builds on Ubuntu 18.04, so usable pretty much everywhere. Tested on Manjaro 21.1.0.
Note: Builds depend on the glibc in your system. This build will only work on systems with glibc >= current version. This is why the CI builds in an old Ubuntu 18.04 container. More info
linuxdeployqt may throw an error if glibc is too new (yes, new). Add -unsupported-allow-new-glibc to bypass it.

I guess the workflow will only work after it is merged. Check out the same run on my fork: https://github.com/rithvikvibhu/fingertip/actions/runs/1089789435
fingertip-appimage is the build result. (github downloads it compressed in a zip file even if it's a single file ¯_(ツ)_/¯

Thanks for the PR! Everything looks good so far can you rebase it?

Hey sorry, missed this email. Came here to check and found your comment.
It was already based on the latest commit, so squashed it and tested the latest build again (https://github.com/rithvikvibhu/fingertip/actions/runs/1151339387) and looks like it works normally.
(no, I didn't generate that vanity commit hash :p)


AVRO-2440: Decode messages by their write schema

This implements AVRO-2440 by allowing a null value for the readSchema
field in the BinaryMessageDecoder. It is interpreted as "no preference",
and makes the decoder use the write schema of an incoming buffer as its
read schema.
Make sure you have checked all steps below.
Jira

[X] My PR addresses the following Avro Jira issues and references them in the PR title:

https://issues.apache.org/jira/browse/AVRO-2440

Tests

[X] My PR adds the following unit test:
org.apache.avro.message.TestBinaryMessageEncoding#testIdenticalReadWithSchemaFromLookup

Commits

[X] My commits all reference Jira issues in their subject lines. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters (not including Jira issue reference)
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

Documentation

[X] In case of new functionality, my PR adds documentation that describes how to use it.

All the public functions and the classes in the PR contain Javadoc that explain what it does

Is it me, or is that build failure complaining that there were less open file descriptors after the test? Seems to me to be the opposite of a leak...
Also, I'm unsure how I could have triggered that. Does anyone know?

I created https://issues.apache.org/jira/browse/AVRO-2448 to tackle the flaky test.


A few suggestions

Cruzix said to post here instead of Elysium forums, so I'll repost here.

Nice addon. A few suggestions:

Make the tiny black border around the bar texture optional (so that we can have a perfect white/red bar)

Customizable Tranq message

Announce Tranq only once (Tank Buddy can do this for Last Stand / Shield Wall, you could refer to its code)

Announce unsuccessful Tranqs (like Tank Buddy's taunt resist) when it misses or when mob is immune

Announce Tranq only once (Tank Buddy can do this for Last Stand / Shield Wall, you could refer to its code)
Announce unsuccessful Tranqs (like Tank Buddy's taunt resist) when it misses or when mob is immune

ZHunterMod already has these features, including localization for english, german and french clients. Could potentially save a lot of work.

Implemented both tranq suggestions. The tiny black border is actually the background which is always a bit bigger than a frame that gets anchored to it. "Fixing" this would be a lot of effort for something i don't see as an issue but rather like.


Handle static files after deployment

Everything works perfectly and deployment the project on heroku is very easy, but static images disappears from the website after few minutes. Any solution to handle those?

Apparently Heroku doesn't persist files: https://help.heroku.com/K1PPS2WM/why-are-my-file-uploads-missing-deleted
I didn't know this until now so Heroku is likely not the best solution for exppressCart.

Will digital ocean manage the static file automatically? With heroku we
need aws S3 bucket or we have to pay to use their ad-on bucketeer.
On Sun, Jun 7, 2020, 6:11 AM Mark Moffat<EMAIL_ADDRESS>wrote:

Apparently Heroku doesn't persist files:
https://help.heroku.com/K1PPS2WM/why-are-my-file-uploads-missing-deleted
I didn't know this until now so Heroku is likely not the best solution for
exppressCart.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mrvautin/expressCart/issues/151#issuecomment-640140832,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AILUBWWDR724IVB2M3W7VZTRVLSNBANCNFSM4NVGXOPA
.

Digital Ocean is just a VPS meaning files will persist as normal. You can setup backups too if required.

I will try it and let you know, i was testing heroku, its very easy to
deploy nodejs there. The only problem that i face was of static files.
Because of which i had to upload my product images in public folder on my
github repo manually and redeploy ever time for the images to stay
permanently.
On Sun, Jun 7, 2020, 6:16 AM Mark Moffat<EMAIL_ADDRESS>wrote:

Digital Ocean is just a VPS meaning files will persist as normal. You can
setup backups too if required.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mrvautin/expressCart/issues/151#issuecomment-640141253,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AILUBWSFESV4DRH3TOBDUXDRVLS7JANCNFSM4NVGXOPA
.


Clarify dbt Mesh docs staging env job requirement

Contributions

[X] I have read the contribution docs, and understand what's expected of me.

Link to the page on docs.getdbt.com requiring updates
@wusanny from the support team internally flagged a couple of questions/feedback wrt the dbt mesh cross-project ref doc staging environment section:

Clarify what ..in a project without "fail-over" to Production means in this section of the doc
Update the doc(s) so users know that they have to run a job in the staging environment of the upstream project in order for the downstream cross-projet ref to resolve. (Maybe as a prereq as user suggested)

What part(s) of the page would you like to see updated?

cross project ref doc: https://docs.getdbt.com/docs/collaborate/govern/project-dependencies#staging-with-downstream-dependencies

possibly also: https://docs.getdbt.com/guides/mesh-qs?step=5

Additional information
No response

@wusanny raised this again as another user was having the same issue.

Add sentence: "Execute a job in the staging environment of the upstream project in order for the downstream cross-project ref to resolve"
Also queried what fail-over to production means here: https://dbt-labs.slack.com/archives/C04MEJT5VPY/p1729159060525869 and https://dbt-labs.slack.com/archives/C017GDLAF7D/p1729159182261669

Fail-over to production =
"This means: dbt Cloud will always use metadata from the Staging environment to resolve references in downstream projects — even if the configured Staging environment does not have any successful runs.
The docs say "fail-over" here because that's what a user might expect — that if there are no successful runs in Staging (= no metadata), dbt Cloud would look for metadata from successful runs in Production instead — but this is NOT what happens. One reason that customers define Staging environments is explicitly to prevent data from Production environments from "leaking" into lower environments, and so we wouldn't want to risk that happening."


Readme changes for current Windows support

Samir, I recycled the README changes from the broken branch into a new pull request. It describes the situation as is.

The current support works fine for non scripts, e.g. executables when doing Assembly katas.

I added a link to the Contributor Covenant to the README. I hope you don't object.

Sure good thing. Thank you for fixing my language.


C# 101 by  Scott Hanselman, Kendra Havens Microsoft.

What does this PR do?
Add Resource(s) | Remove Resource(s) | Add info | Improve Repo
For resources
Description
Why is this valuable (or not)
How do we know it's really free?
For book lists, is it a book?
Checklist:

[x] Not a duplicate
[x] Included author(s) if appropriate
[x] Lists are in alphabetical order
[x] Needed indications added (PDF, access notes, under construction)

thanks, and welcome free-programming-books


"weekly_account_overview" Notification not available

Confirmation

[X] My issue isn't already found on the issue tracker.
[X] I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version
Terraform v1.4.6
on darwin_amd64
+ provider registry.terraform.io/cloudflare/cloudflare v4.7.1

Affected resource(s)
cloudflare_notification_policy
Terraform configuration files
resource "cloudflare_notification_policy" "notifications_to_email" {
  account_id  = var.cloudflare_account_id
  name        = "${element(var.my_alerts, count.index)} notification"
  description = "Notification policy for ${element(var.my_alerts, count.index)}"
  enabled     = true
  alert_type  = element(var.my_alerts, count.index)
  count = length(var.my_alerts)

  email_integration {
    id = var.su_email_for_notifications
  }
}

variable "my_alerts" {
  type    = list(string)
  default = ["weekly_account_overview"]
}

Link to debug output
https://gist.github.com/rustymagnet3000/6f4099c6f97dd6b9f6db7485530db53e
Panic output
No response
Expected output
Expected it to apply without issue as per the docs.
But I am using a FREE ( non enterprise ) Cloudflare account.
Actual output
terraform apply --auto-approve
module.access_rules.cloudflare_access_rule.challenge_anzac[1]: Refreshing state... [id=df6a8ff58eb241da83b834d55d9f0a26]
module.access_rules.cloudflare_access_rule.challenge_anzac[0]: Refreshing state... [id=72627a29db1441b1b5627c11366ba1eb]
module.notifications.cloudflare_notification_policy.notifications_to_email[0]: Refreshing state... [id=c540e8909a0847028d7544c9dbe24181]

Terraform used the selected providers to generate the following execution plan.
Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # module.notifications.cloudflare_notification_policy.notifications_to_email[0] will be updated in-place
  ~ resource "cloudflare_notification_policy" "notifications_to_email" {
      ~ alert_type  = "dos_attack_l7" -> "weekly_account_overview"
      ~ description = "Notification policy for dos_attack_l7" -> "Notification policy for weekly_account_overview"
        id          = "c540e8909a0847028d7544c9dbe24181"
      ~ name        = "dos_attack_l7 notification" -> "weekly_account_overview notification"
        # (4 unchanged attributes hidden)

        # (1 unchanged block hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.
module.notifications.cloudflare_notification_policy.notifications_to_email[0]: Modifying... [id=c540e8909a0847028d7544c9dbe24181]
╷
│ Error: error updating notification policy c540e8909a0847028d7544c9dbe24181: Invalid alert type. (17004)
│
│   with module.notifications.cloudflare_notification_policy.notifications_to_email[0],
│   on modules/notifications/ddos.tf line 1, in resource "cloudflare_notification_policy" "notifications_to_email":
│    1: resource "cloudflare_notification_policy" "notifications_to_email" {

Steps to reproduce
With the provider v4.7.1 or even earlier ( I tried 3.19, 3.34 and 4.7.1)
resource "cloudflare_notification_policy" "notifications_to_email" {
  account_id  = var.cloudflare_account_id
  name        = "foo"
  description = "bar description"
  enabled     = true
  alert_type  ="weekly_account_overview"

  email_integration {
    id =<EMAIL_ADDRESS>  }
}

Additional factoids
Most other Alerts work ( apart from some that signal they are only available with an enterprise license ).  The linked issue suggests some internal renaming happening at Cloudflare.
References
https://github.com/cloudflare/terraform-provider-cloudflare/issues/2117

ok, I am closing this.
This doesn't look an issue for this repo.  It looks like a documentation issue:
If I list all the available alerts with this api the weekly_account_overview is not available. 18 other types of alerts are available.


Fix legacy MySQL and PostgreSQL drivers

At some moment we loose legacy (Generic) drivers for MySQL and PostgreSQL.
Their definition was moved to corresponding mysql and postgresql plugins thus extended driver provider was used instead of Generic.
We need to revert this move.

Also Generic driver will probably fix problems in #6010 (for MySQL)


Add an arity to close which includes a status code and reason

For one of my applications using gniazdo I need to be able to send a close code other than 1000 to the other side of the websocket connection. This PR adds that ability as an additional arity of the close function.

Thanks for the patch, this looks like a useful addition to have! Would you be so kind to add a test case that asserts that the server receives the set status code and reason? for this, you would probably have to add a configurable on-close handler fn (analogous to *recv*).

@mknoszlig I've looked into the http-kit API in detail, and it appears to provide no way to determine the actual close code sent to its server, only providing an abstraction of the connection :going-away.
Do you have a recommendation for an alternative websocket server library that I could use that would resolve this issue? I've not had a lot of luck finding Clojure libraries for websockets that provide a lot of fine-grained control or information.
I can confirm from testing with my own application that it does in fact work as functionality that I am using downline relies on the non-1000 close code sent in order to alter the user-facing behavior of the program.

@mknoszlig I've looked into the http-kit API in detail, and it appears to provide no way to determine the actual close code sent to its server, only providing an abstraction of the connection :going-away.
Do you have a recommendation for an alternative websocket server library that I could use that would resolve this issue? I've not had a lot of luck finding Clojure libraries for websockets that provide a lot of fine-grained control or information.
I can confirm from testing with my own application that it does in fact work as functionality that I am using downline relies on the non-1000 close code sent in order to alter the user-facing behavior of the program.

@IGJoshua : thanks for giving this a try and sorry to hear this causing you trouble.
I've given the http-kit code a quick glance and it appears that the channel implementation is supposed to return a precise status (:going-away being one of the options).
The channel implementation appears to map this correctly, and :going-away appears to not be the default.
Can you maybe provide a minimal example of what gives you the unexpected :going-away result regardless of actual client disconnect status code?

I've adjusted the following in the tests in order to permit testing the value, but it always returns going-away, regardless of code sent, regardless of which method to close used.
;; Added to be used to store the test values
(def close-code (atom nil))

;; Updated to set it to the value provided on close
(defn- ws-srv
  [req]
  (with-channel req conn
    (on-receive conn (partial *recv* req conn))
    (on-close conn #(reset! close-code %))))

;; Updated to set the close-code to nil in preparation for the test
(use-fixtures
  :each
  (fn [f]
    (reset! close-code nil)
    (let [srv (run-server ws-srv {:port 65432})]
      (try
        (f)
        (finally
          (srv))))))

;; new test
(deftest close-with-code-test
  (let [sem (java.util.concurrent.Semaphore. 0)
        conn (connect
              uri
              :on-close (fn [& _]
                          (.release sem)))]
    (is (= @close-code nil))
    (close conn)
    (with-timeout (.acquire sem))
    (is (= @close-code :going-away))))

Thanks for sharing your test case - I've poked around a bit and it seems the problem lies with the call of the cleanup function before closing the connection: the default cleanup function stops the websocket client (which also closes the connection) which is why you're seeing :going-away as a result. If you change the implementation of close to
(close [_ status-code reason]
          (.close session status-code reason)
          (when cleanup
            (cleanup)))

and run your test case again you will find that the result still isn't the expected :invalid-payload-data but :unknown instead. for some reason, 1007 isn't mapped correctly by http kit - if you use eg 1003 instead, you'll receive the expected reason kw status of :unsupported - so your hunch of something strange going on with the httpkit ws server was correct as well. But for our purposes i think it'll be enough to fix the bug in close and use a custom status that is supported. Would you be so kind to update your PR accordingly?
@jstepien @xsc : technically, the same bug exists in the vanilla close function - do you recall a specific reason why it was implemented in that order back in the day?

That explains why it worked in my downline application but not in the tests. I use a custom client, so the cleanup function doesn't exist.
In any case, I've made the update and included the test.

Thank you for your contribution!

Thank you for taking the time to prepare those patches. We've released them in 1.2.0.


Problem setting up Nushell on Windows

Using the alacritty v0.13.2 terminal, I'm trying to write Nushell v0.93.0 specific commands in my justfile on Windows 11 23H2.
My justfile looks like:
for:
  for file in `ls .`; do echo $file; done

for2:
  for direc in `ls -s . | where type == dir | get name`; do \
    echo $direc; \
  done

$ just for

runs fine

$ just for2

/usr/bin/bash: line 1: get: command not found
INFO: Could not find "type".
INFO: Could not find "==".

It seems that justfile is interpreting ls -s . | where type == dir | get name as a bash command when I want it to be interpreted as Nushell command. If I start my justfile with
set shell := ["nu", "-c"]
OR
set shell := ["nu", "--env-config", "~\\.config\\nushell\\env.nu", "--config", "~\\.config\\nushell\\config.nu", "-c"]
OR
I change the recipe to:
for2:
  #!nu
  for dir in `ls -s . | where type == dir | get name`; do \
    echo $dir; \
  done

then it reports the following error:

Error: nu::parser::keyword_missing_arg
× Missing argument to in.
╭─[C:\Users\myusername\AppData\Local\Temp\just-UQzDXm\for2:13:13]
12 │
13 │ for direc in ls -s . | where type == dir | get name; do
·             ▲
·             ╰── missing any value that follows in
14 │   echo $direc;
╰────
error: Recipe for2 failed with exit code 1

Any suggestions on setting up windows and Nushell cross-platform justfile scripting?

Hi @sim4life ,
Although I am not very familiar with Nushell, I just tried executing the command you provided directly in Nushell
~> for dir in "ls -s . | where type == dir | get name"; do echo $dir; done                      1 06/07/2024 06:00:29 PM
Error: nu::parser::keyword_missing_arg

  × Missing argument to `in`.
   ╭─[entry #21:1:11]
 1 │ for dir in "ls -s . | where type == dir | get name"; do echo $dir; done
   ·           ▲
   ·           ╰── missing any value that follows in
   ╰────

I don't think it is a valid nushell script

Check https://www.nushell.sh/book/control_flow.html#for for a valid for loop sytax in nushell
for file in (ls .) {
  print $file
}

for direc in (ls -s . | where type == dir | get name) {
  print $direc
}

set shell applies to the shell used for linewise recipes as well as backticks.
So when you set the shell to Nushell, you should write recipe lines in Nushell as well.
If you want to mix Bash and Nushell recipes, set shell to one and use shebang recipes for the other.
If you want to mix Bash and Nushell in the same recipe, you need to call out explicitly from one to the other. You could do this indirectly through just:
set shell := ['nu', '-c']

# Nu script
list-dir-names:
    ls -s . | where type == dir | get name

# Bash script
for:
    #!/usr/bin/env bash
    set -euxo pipefail
    for direc in $(just list-dir-names); do echo $direc; done

I don't see a reason to ever do this, but it is possible.

Thanks for the replies:
The syntax
for3:
  for direc in (ls -s . | where type == dir | get name) { echo $direc }

was giving me an error:

for3: -c: line 1: syntax error near unexpected token `('

I did NOT intend to mix n match nushell and bash syntax but it seems that the backticks shell command syntax ignores rest of the global shell settings in justfile and chooses bash in Windows. So I ended up completely replacing justfile for-loop syntax with nushell for-loop syntax like:
for2:
  #!nu
  ls -s . | where ($it | $it.type == dir) | get name

Can you post a complete justfile, along with the error message you're getting? I want to make sure I understand the problem.

One clarification to my previous comment: backticks within a recipe line are not preprocessed by just in any way. They are interpreted by the shell normally. So backticks in bash will execute the enclosed command in a subshell, while backticks in Nu just indicate a string.
The only syntax that causes just to change the text of a recipe is {{ }}. After those substitutions are made, the resulting script is interpreted by the shell directly.

@sim4life
Are you referencing the for loop section in the readme and you think you are using a  justfile for loop sytax?
set shell := ['nu', '-c']
for2:
  for direc in `ls -s . | where type == dir | get name`; do \
    echo $direc; \
  done

with your above justfile, you are expecting that

the for is a justfile loop

the backticks will be executed in nushell

right?
but the for loop section in the readme is actually describing how to write a multi-line constructs in the justfile, and it is taking bash as an example. (which means there is no justfile-syntax for loop, the example is bash for loop)
so, you are trying use so-called "justfile-syntax" for loop and nu command in backticks. However, it is actually mixing the bash and nushell
@casey  @starthal Please correct me if I am wrong


Mpi/crocoddyl topic/cpp unittests - [merged]

In GitLab by @MaximilienNaveau on Jun 19, 2019, 19:10
Merges mpi/crocoddyl-topic/cpp_unittests -> cpp_devel
This contains:

The packaging of the cpp unit tests
The test_state.cpp
The correction of the memory allocation of the Euclidean state.

In GitLab by @MaximilienNaveau on Jun 19, 2019, 19:11
I wanted to have a first merge even without the state num diff in order to have the proper cpp unittest packaging pushed.
Another merge request will follow up with the state num diff implementation.

In GitLab by @MaximilienNaveau on Jun 19, 2019, 19:46
added 1 commit
d918bb36 - Add the test_actions.cpp and update the packaging
Compare with previous version

In GitLab by @cmastalli on Jun 19, 2019, 21:38
I would be great to add the message when it fails, do you think it's possible?

In GitLab by @cmastalli on Jun 19, 2019, 21:38
same here

In GitLab by @cmastalli on Jun 19, 2019, 21:40
you can avoid copy by doing for example
const Eigen::VectorXd& x1 = state.rand();

Of course this isn't very important but it's nice to have it :)
I'm OK if you don't want to waste time on it.
I won't mark other places where this is needed since you can easily check those places.

In GitLab by @cmastalli on Jun 19, 2019, 21:43
same here

In GitLab by @cmastalli on Jun 19, 2019, 21:43
and here

In GitLab by @cmastalli on Jun 19, 2019, 21:43
and here

In GitLab by @cmastalli on Jun 19, 2019, 21:46
I think @nim65s it's working on solving this issue.
do @nim65s should remove this?

In GitLab by @cmastalli on Jun 19, 2019, 21:49
It's nice that you improve the documentation. This time wasn't so much changes and it's OK for me.
However, it would better for me, in order to ensure quality code review, to make these kind of modifications in another PR :)

In GitLab by @cmastalli on Jun 19, 2019, 21:51
All the global variables don't follow this standard (i.e. name + _), the idea was to match Python code.
Would you like to force this standard? If so, I would make the respective changes before asking my PR.

In GitLab by @ostasse on Jun 19, 2019, 22:17
Please follow the C++ style defined by the group. We are following the Google C++ guide line. More specifically for the variables names:
https://google.github.io/styleguide/cppguide.html#General_Naming_Rules

In GitLab by @MaximilienNaveau on Jun 20, 2019, 13:44
@ostasse if I am correct the attribute of a class must/should be written like
class A{
private:
  int a_;
}

According to the google c++ guide line. @cmastalli this is why I changed it.

In GitLab by @nim65s on Jun 20, 2019, 13:54
Once again, it is impossible to follow standard c++ style AND follow standard python style AND match python and c++ styles in your codebase.
Please, drop one of those 3.
Please, the third.

In GitLab by @nim65s on Jun 20, 2019, 14:22
I'm not clear, sorry.
Let's say that we have :

standard style for c++ code: SC
standard style for python code: SP
the style we use for our c++ code: OC
the style we use for our python code: OP

Now, as SC != SP, we can not have OC == SC && OP == SP && OC == OP.
I suggest to define OC == SC && OP == SP.

In GitLab by @MaximilienNaveau on Jun 20, 2019, 14:28
Concerning this point it is not easy to add a message with the BOOST API, I tried to find something...
The other thing is that the message displayed by the ctest-V is rather explicit... I am not sure if we need more.
2: Test command: /home/mnaveau/devel/workspace/src/not_catkin/third_party/laas/crocoddyl/build-vscode-debug/unittest/test_actions
2: Test timeout computed to be: 9.99988e+06
2: Running 4 test cases...
2: /home/mnaveau/devel/workspace/src/not_catkin/third_party/laas/crocoddyl/unittest/test_actions.cpp(37): error in "boost::bind( &test_calc_returns_state, crocoddyl::ActionModelLQR(nx, nu, driftfree) )": check nx - model.get_nx() failed
2:
2: *** 1 failure detected in test suite "Master Test Suite"

What do you think? if we name the variable correctly we should have not trouble to identify the trouble.

In GitLab by @MaximilienNaveau on Jun 20, 2019, 16:07
added 2 commits
c15affc2 - ignore .clang_formata0e087d2 - add unnittest to the action model lqr, waiting for the action num diff to finish
Compare with previous version

In GitLab by @MaximilienNaveau on Jun 20, 2019, 19:56
added 1 commit
92926ac0 - implement the state num diff
Compare with previous version

In GitLab by @MaximilienNaveau on Jun 20, 2019, 19:58
I am not sure you are allowed to do this anyway... because state.rand() returns a temporary object. Your reference would point on nothing afterwards. To be checked...

In GitLab by @MaximilienNaveau on Jun 20, 2019, 20:06
Cf discussion about the C++ guideline. And therefore yes I want to enforce this standard.
This + all method should be: a.MyMethod
all getter: get_my_attribute()

In GitLab by @cmastalli on Jun 20, 2019, 20:53
Yes, it's good for me :)
I noticed that this is different from struct (according to Google standards)

In GitLab by @cmastalli on Jun 20, 2019, 20:55
It's good for me :)

In GitLab by @cmastalli on Jun 20, 2019, 20:57
The error message is quite descriptive, I guess we can do it in this way too.

In GitLab by @cmastalli on Jun 20, 2019, 20:58
Sorry you're right! I was thinking in state.zero()

In GitLab by @cmastalli on Jun 20, 2019, 20:59
Everything else is OK for me. We need to check if it's required to revert this change. Please let me know if it's needed @nim65s

In GitLab by @MaximilienNaveau on Jun 21, 2019, 10:52
That would be the same issue I think

In GitLab by @MaximilienNaveau on Jun 21, 2019, 11:16
Should we keep it like this? And then solve it in another pull request?

In GitLab by @MaximilienNaveau on Jun 21, 2019, 11:38
changed the description

In GitLab by @cmastalli on Jun 21, 2019, 22:30
This is taking so much time, I agree. I will merge this and later we'll figure out.
Thank you for the nice contribution! :)

In GitLab by @cmastalli on Jun 21, 2019, 22:30
resolved all discussions

In GitLab by @cmastalli on Jun 21, 2019, 22:30
merged

In GitLab by @cmastalli on Jun 21, 2019, 22:30
mentioned in commit 9d658c906ce9bcde20f7ecdb3412a45d82d1a1eb


[New API] : Aylien API

Brief Description 🤓
Text analysis, including entity recognition, sentiment analysis, and language detection.
How will you develop it?🤩
react,js
Deployment
None
Select the open source program you are contributing to
Other
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINES of this project.

Greetings @AmruthaPariprolu🎀 ! , We are excited to have you dive into another issue with us!🚀
Your involvement in our project has been invaluable, and we're confident that your skills and insights will help us conquer this challenge😇.  Use command /gssoc24 to self assign the issue.  This issue represents an exciting opportunity for us to improve and enhance our project, and we are thrilled to have you on board.
We request you to follow CONTRIBUTING GUIDELINES.
Looking for your PR soon!
In case of any issues, you can contact us on Discord.❣


Bug Fixes

Create Ceph cluster fix
Create Gluster cluster fix
Create Brick fix
Import Cluster "back button" enabled

@r0h4n Please review the patch.

Verified?

@r0h4n I have verified it on my end.


Sphinx documentation build always failing on Windows

I was able to get, build and launch readthedocs code successfully on Windows 7 Professional with Python2.7 .
I am hosting the web site with the command 'python .\manage.py runserver' as per the installation guide.
I am able to launch the website at localhost:8000 and was able to configure new project and configure documentation build successfully through the UI.
HOWEVER when documentation build actually launches it always. The log details are at the bottom of this. From what little i can tell it seems to be in readthedocs.org/readthedocs/doc_builder/python_environments.py the lines like this:
self.venv_bin(version=self.version.slug, filename='pip')
is returning a path like {install dir}\user_builds{project}\envs\latest\bin\pip , which doesn't exist. It seems like the path {install dir}\user_builds{project}\envs\latest\Scripts\pip.exe does exists. I am guessing this is related to virtualenv.
Logs:
[13/Jan/2016 11:15:46] ERROR [readthedocs.doc_builder.environments:299] (Build) [compass-documentation:stable] Command python C:\rtd\checkouts\readthedocs.org\user_builds\compass-documentation\envs\stable\bin\pip install --use-wheel -U --cache-dir C:\rtd\checkouts\readthedocs.org\user_builds\compass-documentation.cache\pip sphinx==1.3.1 Pygments==2.0.2 setuptools==18.6.1 docutils==0.11 mkdocs==0.14.0 mock==1.0.1 pillow==2.6.1 readthedocs-sphinx-ext==0.5.4 sphinx-rtd-theme==0.1.9 alabaster>=0.7,<0.8,!=0.7.5 commonmark==0.5.4 recommonmark==0.1.1 failed:
python: can't open file 'C:\rtd\checkouts\readthedocs.org\user_builds\compass-documentation\envs\stable\bin\pip': [Errno 2] No such file or directory
Traceback (most recent call last):
File "C:\rtd\checkouts\readthedocs.org\readthedocs\projects\tasks.py", line 143, in run
self.setup_environment()
File "C:\rtd\checkouts\readthedocs.org\readthedocs\projects\tasks.py", line 244, in setup_environment
self.python_env.install_core_requirements()
File "C:\rtd\checkouts\readthedocs.org\readthedocs\doc_builder\python_environments.py", line 133, in install_core_requirements
bin_path=self.venv_bin(version=self.version.slug)
File "C:\rtd\checkouts\readthedocs.org\readthedocs\doc_builder\environments.py", line 310, in run
return self.run_command_class(cls=self.command_class, cmd=cmd, **kwargs)
File "C:\rtd\checkouts\readthedocs.org\readthedocs\doc_builder\environments.py", line 341, in run_command_class
raise BuildEnvironmentWarning(msg)
BuildEnvironmentWarning: Command python C:\rtd\checkouts\readthedocs.org\user_builds\compass-documentation\envs\stable\bin\pip install --use-wheel -U --cache-dir C:\rtd\checkouts\readthedocs.org\user_builds\compass-documentation.cache\pip sphinx==1.3.1 Pygments==2.0.2 setuptools==18.6.1 docutils==0.11 mkdocs==0.14.0 mock==1.0.1 pillow==2.6.1 readthedocs-sphinx-ext==0.5.4 sphinx-rtd-theme==0.1.9 alabaster>=0.7,<0.8,!=0.7.5 commonmark==0.5.4 recommonmark==0.1.1 failed:
python: can't open file 'C:\rtd\checkouts\readthedocs.org\user_builds\compass-documentation\envs\stable\bin\pip': [Errno 2] No such file or directory
[13/Jan/2016 11:15:48] INFO [readthedocs.doc_builder.environments:280] (Build) [compass-documentation:stable] Build finished

We don't support Read the Docs on Windows via our open source project. We do provide commercial support, if you're interested more information is here: http://docs.readthedocs.org/en/latest/support.html#commercial-support


V1.2b support search model

Support search by adding predicate and use filteredEntryList in modelManger class, please check and update logic

Codecov Report

Merging #97 into master will decrease coverage by 0.02%.
The diff coverage is 60.00%.

@@             Coverage Diff              @@
##             master      #97      +/-   ##
============================================
- Coverage     65.10%   65.08%   -0.03%
- Complexity      492      493       +1
============================================
  Files            94       95       +1
  Lines          1751     1767      +16
  Branches        171      172       +1
============================================
+ Hits           1140     1150      +10
- Misses          573      577       +4
- Partials         38       40       +2

Impacted Files
Coverage Δ
Complexity Δ

.../model/journal/TitleContainsKeywordsPredicate.java
0.00% <0.00%> (ø)
0.00 <0.00> (?)

src/main/java/seedu/address/model/Journal.java
96.55% <90.00%> (+12.34%)
11.00 <3.00> (+4.00)

...rc/main/java/seedu/address/model/ModelManager.java
86.15% <100.00%> (+0.21%)
26.00 <0.00> (ø)

...c/main/java/seedu/address/model/journal/Entry.java
90.00% <100.00%> (+2.50%)
13.00 <1.00> (-1.00)
:arrow_up:

.../java/seedu/address/model/journal/Description.java
75.00% <0.00%> (-12.50%)
5.00% <0.00%> (-1.00%)

...rc/main/java/seedu/address/model/journal/Date.java
90.00% <0.00%> (-5.00%)
7.00% <0.00%> (-1.00%)

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 97c6bf2...4f629b4. Read the comment docs.


Improve layout of snapshot container for super wide views

We currently show a single column legend for wide views. When a view gets wide enough (as seen in this snapshot) we could split the legend into multiple columns, to avoid having so much empty space in the snapshot image.
This could potentially cause some issues with wrapping, resulting in messy diffs, but I think the benefits in reduced snapshot size might be worth it. Curious if anyone has thoughts on this.

This has been open for over a year and in practice hasn't been a significant issue. I'm going to close this out as a won't-fix for now, but happy to reopen if this becomes more of an issue in the future.


Support for Amazon.de

I've added the URL for amazon.de for both Chrome and Firefox manifest.json. Result is as expected. 👍🏻
Thanks, for this awesome extension.
Unfortunately, I cannot test it with any other Amazon website, I only have recent orders with Amazon.de

Glad to hear it helps for amazon.de as well! I didn't want to be presumptuous about it working in other countries. I'll add it soon

Chrome and firefox extensions have been submitted, it should be live within a few hours


Combine Google Font challenges into one

Pre-Submission Checklist

[x] Your pull request targets the staging branch of freeCodeCamp.
[x] Branch starts with either fix/, feature/, or translate/ (e.g. fix/signin-issue)
[x] You have only one commit (if not, squash them into one commit).
[x] All new and existing tests pass the command npm test. Use git commit --amend to amend any fixes.

Type of Change

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

Checklist:

[x] Tested changes locally.
[x] Closes currently open issue (replace XXXX with an issue no): Closes #13471

Description

The curriculum expansion added a challenge (in the Applied Visual Design section) about importing a Google Font. It covered the same concept as the existing "Use a Google Font" challenge in the Basic CSS section. This PR layers some additional information from the new challenge into the original Google Font challenge (and slightly tweaks the "How Fonts Degrade" challenge), and removes the new one.

@HKuz should've named your branch oneGoogleFontToRuleThemAll #missedopportunity 😆

@dhcodes - I was thisclose to naming my branch that, then reconsidered because it seemed long. Haha - a missed opportunity indeed. 😞
These comments are all good - I'm turning them now, and will update 👍

Tested and LGTM! Thanks for putting up with my suggestions :) 🌮 💎 :octocat:

Thanks @dhcodes 🍻 🍀 :1st_place_medal: !!

@HKuz @dhcodes thanks for making this improvement. I agree - this is more streamline 😄


docs: fix doc-gen

Automated doc-gen has been broken since the TS re-write, so the current /docs page cannot leverage the improved type annotations.
Additionally, the current flow requires manual generation and check-in of static html pages. Ideally we can make this all automated.

Enumerating the packages to be updated here to track progress

[ ] @vx/annotation
[ ] @vx/axis #681
[ ] @vx/bounds
[ ] @vx/brush
[ ] @vx/chord
[ ] @vx/clip-path
[ ] @vx/curve
[ ] @vx/drag
[ ] @vx/event
[ ] @vx/geo
[ ] @vx/glyph
[ ] @vx/gradient
[ ] @vx/grid
[ ] @vx/group
[ ] @vx/heatmap
[ ] @vx/hierarchy
[ ] @vx/legend
[ ] @vx/marker
[ ] @vx/mock-data
[ ] @vx/network
[ ] @vx/pattern
[ ] @vx/point
[ ] @vx/responsive
[ ] @vx/scale
[ ] @vx/shape
[ ] @vx/stats
[ ] @vx/text
[ ] @vx/threshold
[ ] @vx/tooltip
[ ] @vx/voronoi
[ ] @vx/zoom

closed by #681 🔥

actually, opening this back up until I also get rid of the legacy scripts / static docgen.


linux-58 is dead.

Type of Request
bug
Infrastructure Environment
LUCI, Github, Cocoon scheduler, Autosubmit, etc...
What is happening?
linux-58 is dead.

Steps to reproduce
Step 1:
Step 2:
..
Step n:
Expected results
I expect to see X when Y is finished.

Ethernet port network connection was disabled by itself, re-seated network cable to restart network service.
flutter@flutter-devicelab-linux-58:~$ uptime
09:17:03 up 1 day, 23:19,  1 user,  load average: 0.52, 0.14, 0.05


add global auto clear option

added global auto clear option. updated readme

One minor comment, then happy to merge :tada:

whoops! fixed


Fixed code style issues in lib/System

Fixed code style issues in lib/System folder.
For more details about code style changes visit issue #67.

NOTE: This PR can be merged once CI builds are green.


[nnstreamer/apptest] Remove unnecessary whitespaces

This patch is trivial, removing unnecessary whitespaces in the script file.
Self evaluation:

Build test: [ ]Passed [ ]Failed [*]Skipped
Run test: [ ]Passed [ ]Failed [* ]Skipped

Signed-off-by: Wook Song<EMAIL_ADDRESS>

:memo: Version: 1.20181123. Thank you for submitting PR #427. 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://nnsuite.mooo.com/TAOS-CI/ci/taos/.


Install and Instantiate Hyperledger Fabric Chaincode

Tutorial URL: https://developers.sap.com/tutorials/blockchain-hlf-install-chaincode.html
Please specify the step you are referring to
Unable to install the chaincode though I have specified correct zip folder with chaincode file in main folder.

error.docx
Please help
Also find the attached zip folder.
com-sap-icn-blockchain-HelloWorld.zip

what happens when you rename your GO and YAML files from 'hello-world' to 'HelloWorld'?

hello_world.zip
Hi Greg,
As per your suggestion, I have changed the file names. Still I get the same error.

it should be either 'hello-world' or 'HelloWorld' in all the files and filenames.
i'm using 'ld6' for my naming convention:

not mixed like this:

Hi Greg,
Request you to please share your .zip folder for the above mentioned files.
Regards,
Ameena

helloWorld4.zip
it's only good for another 5 days or so when my trial account expires.
good luck!

Thanks a lot for the zip file. Issue resolved :)


CSUB-1100: Halve the number of blocks/epoch for fast-runtime feature

this should speed up integration tests in CI b/c we'd have to wait less time for unbonded funds to be unlocked
Description of proposed changes

Practical tips for PR review & merge:

[ ] All GitHub Actions report PASS
[ ] Newly added code/functions have unit tests

[ ] Coverage tools report all newly added lines as covered
[ ] The positive scenario is exercised
[ ] Negative scenarios are exercised, e.g. assert on all possible errors
[ ] Assert on events triggered if applicable
[ ] Assert on changes made to storage if applicable

[ ] Modified behavior/functions - try to make sure above test items are covered
[ ] Integration tests are added if applicable/needed

Self-note: https://github.com/gluwa/creditcoin3/actions/runs/8600510183/job/23566305319?pr=282 before rebasing onto #317.
execution times aren't vastly different from before:

proxy=yes / valid-proxy / type=All - 01:02:39 hrs vs 01:15:58 before - 14 minutes gain; similar for other valid proxy scenarios
no-funds/not-a-proxy: avg 25 min vs avg 30 min before - 5minutes gain
proxy=no - something broke so the job took 6 hrs before being killed by GitHub. Before the change is around 01:20 hrs

Needs https://github.com/gluwa/creditcoin3/pull/319

https://github.com/gluwa/creditcoin3/actions/runs/8631836554/job/23661791382?pr=282 also resulted in

proxy = no job timing out.

Maybe this needs to be retried after all of the rest PRs in this patch series are merged b/c they will also reduce the overall time before attemting to reduce it further.

https://github.com/gluwa/creditcoin3/actions/runs/8657929353/job/23741542858?pr=282 - failed for the 3rd time and execution times for the rest of the test jobs are comparable to what we see in #320. Closing.


misc: update gapbs example to use suites

Change-Id: I2a8f874dd6ec18c27bc7e52dbb75ac0c6aa88c59

I am attaching the workload and suite file for gapbs here:
gapbs_workloads_suite.json
to run the new patch use the  GEM5_RESOURCE_JSON_APPEND flag
GEM5_RESOURCE_JSON_APPEND=[path to gapbs_workloads_suite.json] ./build/X86/gem5.opt configs/example/gem5_library/x86-gapbs-benchmarks.py --benchmark [benchmark]

After #609 gets in I can change the script to initialize suites first and then provide its workloads as options.


Threat investigation - Database name hardcoded

The Hive queries have the database name hardcoded. This value (database name) needs to be obtained from the .conf file

Fixed with  https://github.com/Open-Network-Insight/oni-oa/pull/41


Reactime v7.0.0 (repo) vs v8.0.0 (Chrome web store)?

The latest tag in the repo is 7.0.0 (Oct 30, 2020) but the Chrome web store advertises 8.0.0 (Feb 6, 2021).
Where did the published v8.0.0 come from?
Please and thanks.

Looking at the Chrome web store now, the version published is listed as 9.0.0. Is this just a mistake when pushing to the store?

It's now 11.0.0.  Apparently whoever is doing releases is not creating tags here in GitHub, which is somewhat unfortunate.  Would be great if this was fixed.

Ahah, it was bumped to 11.0.0 in #252. @liuedar Please could you add corresponding tags? Thanks a lot!


Use deepmerge correctly

It only accepts two parameters
If any of them are null/undefined, it crashes

Hey, thanks for the PR.
The order seems wrong. If keys are duplicate when merging, the object on the right will "win". Thus in your current implementation the priority will be: default > options > query
But the priority should be the other way round: query > options > default
Could you verify this and update your PR? After that I will gladly check it out myself and merge it.

You're right. I've also run into a few other issues with deepmerge; namely, the script as added to my output failed to run correctly, throwing an error on every __merge call. Unfortunately I couldn't find the cause of these errors.
I've replaced deepmerge with deep-extends instead, which does the same thing, except it supports multiple arguments, and its code is much clearer. Now it seems to work fine, and I've mostly reverted my original commit.
If you look at the combined changelog, https://github.com/eXaminator/closure-loader/pull/21/files, you'll see that the changes, besides replacing the required library, are extremely minimal.

I'll have a look at it soon. Looks good at first glance, if everything works out I'll take it. :)

I just released 0.2.0 including your changes


Feature Request: Triggering Logic Apps from rule

Currently there is no way (or at least I cannot find how) to add "Automated Response" to an alerting rule.
It would be nice if we could also specify a logic app in the analytics settingsfiles.

Just wanted to let you know that I am still working to implement support for playbook, hopefully finishing up in upcoming days:

@sbroosnokia this feature is now available in version 0.6.2


Fixes #94

You should add tests to verify the produced signatures are valid.
See https://tools.ietf.org/html/rfc7520#section-4.3 for some examples.

see #106


No way to create VALARM, or add a component to a VEVENT

I am looking for a way to add an alarm component to an Event, even by creating a component by hand (which I was able to do through the parser interface) and adding it to the Event.
Is there any support planned for VEVENTs?

I don't see a reason not to add it actually

Just chipping in to say that this would be really useful, and the lack of this might make me have to move to a different calendar creator. Is it a hard task to add the functionality? (I'd be happy to add it and submit the PR)

@hoodie Any chance you could give a high level summary of what would need to be done for you to accept a PR that adds VALARM functionality?

It requires some internal changes I think, since event/todo components need to be able to have associated children. I have parts of the work already done on a local branch and will give it more time this weekend.

Okay thanks. This would be an extremely helpful feature so let me know if you'd like me to take charge and implement it, or otherwise how I can help out

I suppose the weekend was longer than intended

just released 0.14.0. closing this, if you'd like to talk about changes, please open a new issue. Thanks for every bodies input and support.

Thank you so much!

We already started to use this feature in zerocal: https://github.com/mre/zerocal/pull/24


uploading and deleting backend

Added backend code in FastAPI to upload and delete files from /composefiles directory.
/composefiles directory is a bind mount from the host machine in this repository to the FastAPI container, allowing the api to interact with the files and users.
TODO:

[x] Add event listeners to individual compose file card buttons
[x] Update the state of the compose file cards for deleting and adding new ones
[ ] Update UI
[x] Figure out how to run the compose files
[ ] Make compose file location configurable

@AdamSpera UI needs love as usual
@AdamSpera, @Tylermui do we want to make the folder for storing compose files configurable?


Move plugins to use plugin repo

Going to go over this a couple more times but opening for visibility. Pretty sure everything is working well.

Downloads and installs the plugins from the remote repo.
Update all references.
Deletes the plugin source code
Leaves traction inkeeper and existing structure the same.

Tried docker composing things up locally and it seems to be working there.
On the PR deployed from this the plugins might not be loading properly?
When trying tenant operations (logging in with innkeeper, creating a tenant from a reservation etc) I get errors like this on the OCP pod
aries_cloudagent.config.base.InjectionError: Error loading multitenant manager, class 'traction_plugins.multitenant_provider.v1_0.manager.AskarMultitokenMultitenantManager' not found.

@loneil Ok. Strange. I thought I updated all the deploy references. That error makes sense if the plugin config is still referencing that class. I'll try to find time to look.

@loneil I had some permissions problems in my repo and think it caused my to miss the one chart value. Should be fixed.

Ok cool. Yeah I've done regression on that PR going through Tenant/Innkeeper onboard, endorser connect, schema/cred creation, connect to BC Wallet, Issue, Revoke, Pres Req. So that's all working and that would be touching the plugins for sure.
The one weird thing though is that I can Basic Message back and forth from my Traction Tenant to the BC Wallet all good. But it's not fetching the messages from the basic message storage or something...?
So this is the aca-py agent logging out the received message I sent from my wallet

So can see the plugin getting it.
But the GET is empty

Might try locally later on as well once I finish something else up, but not sure if any initial thoughts @jamshale

@loneil That is weird.
Oh. I forgot that @Jsyro had changed it recently to require a config that enables it. That might be the problem. I'll try and look at it on Monday. Thanks for the testing.

Changes look good to me, thanks @jamshale !
@loneil the basicmessage_storage now requires persistence to be enabled, it will by default NOT store messages - this was done to meet potential STRA/PIA requirements about data retention in our production environments.

Ohhh, I'd missed that. Would definitely make sense.

There should be logging that explains when it's being saved or not. but let me know if you need help figuring out the flag.

@loneil I've manually tested this and I'm pretty sure everything is working correctly and this can be merged.

If it is set up as the PR is for the DEV (and other) deployments, which it looks like it should be (?) then it's probably good to merge in to main and trigger the dev deployment.
So given that, I'd still want to record thoughts/questions about how to maintain Traction with this setup here. Some of these might have been previously discussed (maybe need documentation in the Traction repo?). Maybe worth discussion with @esune about if we have operational plans for this stuff, or priority for figuring out (if not already)
Running Traction locally with Docker

Still just docker compose build/up. Pulls from plugin repo for relevant plugins.

Local devcontainer in Traction repo

How does this work/is this needed?
Can we debug into plugins this way (that was possible before. though I never did it)

Local development for Innkeeper plugin

Should proceed the same as before
Innkeeper plugin remains in Traction repo

Local development for other plugins

Will involve changing local dockerfile to import files from local machine?
So you clone the plugin repo and then alter the dockerfile to point at those. Then change the plugins and rebuild local Traction? Then not commit the dockerfile?
This flow, what the best practices for this should be (should plugins be locally developed/debugged against Traction? Just an ACA-Py?) will need documentation

Updating ACA-Py version

Involves updating aca-py image in Traction, and then each plugin potentially needs to have ACA-Py Python package dependencies updated (aries-askar, indy-vdr, etc).
So this would be needing to poetry update the plugin repo and commit it before building Traction?
Would we only do plugins that Traction uses? Or are all plugins to be updated at the same time.
We usually want to test releases on OpenShift before going ahead, so would that involve the plugin repo needing to be moved forward so a PR env can be built on that linked codebase? Is there to be a different flow?

Updating other dependencies

Same sort of concept as ACA-Py version updates.
Security, dependabot, etc updates for poetry imports
Need to push to main before building a Traction?

I won't answer all the questions because there is a lot of them but the flow shouldn't change a lot. The plugin acapy versions are defined as extras so just upgrading the acapy image should be enough. The plugin repo has dev containers so the development env will be the same. You still needed to rebuild the plugin image in traction to get code changes. You can simply change the pip install location to your own fork when developing. The main change is you need to get a PR approved and merged into the plugin repo. This is actually a good thing because plugins need to have unit and integration tests which is lacking currently.
I'll do a development demo at some point, or if anyone starts work on a plugin and wants a run down. Some documentation in traction would probably be helpful in the longterm.

I think we can merge, I agree with the above discussion/thread. If there is need for adjustment, we'll log an issue and tackle it that way - this is already beneficial as it will reduce code duplication.

@esune @loneil Ok I tested the recent config change. Working locally and the PR deploy.
I'll add a ticket for adding some documentation about developing remote plugins but don't have time to do it atm.

Logged https://github.com/bcgov/traction/issues/996 to track that work item, will now merge this.


bug: sidemenu stop appearing on swipe & page not scroll

Type: bug
Platform: all
Menu stop appearing with swipe. And all page stop scrolling.
When I click from one page with side menu to another page - that other page stop scrolling and side menu is not appearing via swipe

Hey @igorizr1, can you put together a codepen related to this bug?

http://codepen.io/anon/pen/rVVEMe

@perrygovier i put it together. It doesn't scroll on one of the screens.
http://codepen.io/anon/pen/rVVEMe

Thanks, It looks like there's some places where you mix different structures and approaches.
First off, the <ion-nav-bar> is meant to be in the parent, abstract, template in side menus. Then you can override what's in it using <ion-nav-buttons>.  You're welcome to use raw <div>s and CSS, but you'll loose pretty page transition animations.
Next up, your default route goes directly to /home. This loads that page directly and not the parent sidemenu architecture, so the side menu wont display because it doesn't exist. The correct default route would be /event/home
On one of your templates, the opening <ion-content> was missing, which is what probably broke scrolling.
For nested states, like in sidemenus and tabs, the child view has to be defined in the $state deffininition to associate the child page with the proper <ion-nav-view>.
I've gone and updated the codepen to what I think you're trying to do and it's working well for me.
http://codepen.io/perrygovier/pen/NqGQax?editors=101


What is transition_type='manual'?

In the README.md file there is an example using transition_type='manual', but I can't find any information telling what this means.
Any explanation?

Yep. It should be removed


provide a devcontainer.json file for use with Codespaces and other VM IDEs

Not everyone is familiar with the local runtime needs of Python. In order to make running this CLI locally easier, provide a devcontainer.json. This file describes a local environment and essentially makes running the code a 1-step process.

ah i see you added #30  for this
can you also add instructions to the readme? thank you!

merged


Pass dns_name to terraform-aws-route53-cluster-hostname instead of name

what

Fixes incorrect DNS records when setting custom records in R53 by passing dns_name rather than name to terraform-aws-route53-cluster-hostname

why

terraform-aws-route53-cluster-hostname changed how to pass the DNS name in between 0.5.0 and 0.7.0+
In 0.5.0 the DNS record was created used var.name (https://github.com/cloudposse/terraform-aws-route53-cluster-hostname/blob/0.5.0/main.tf#L4) - which is what this module passes.
Since 0.7.0 the DNS record created uses var.dns_name if set, defaulting to module.this.id if not (https://github.com/cloudposse/terraform-aws-route53-cluster-hostname/blob/0.7.0/main.tf#L3)
This results in the custom DNS names passed in this module not generating the correct R53 records.

/test all

/rebuild-readme

/test all