Support for {patch} level version digit to make possible YYYY-MM-DD version formats

Hi -
I'd like to discuss support for the third SEMVER digit in the version format
If we make the patch level digit possible it is then possible to use versioning schemes that use the date in the same way that Amazon, Stripe and others do.
For example /2023-01-12/users/awesome where the instantiation of that might look something like
versions = versionize(
    app=app,
    prefix_format='/{major}-{minor:02}-{patch:02}',
    enable_latest=True,
    latest_prefix='/latest'
)

The goal is to create a pathway to adopt Stripe style versioning for users -
https://stripe.com/blog/api-versioning
Happy to write this as supply a PR, but wanted to ask first to make sure there are not other approaches or limitations that others might see beforehand

Hmm, in my opinion, you shouldn't ever have 2 accessible versions of a route, where they only differ in patch version. When the patch version is incremented, the change should be backwards compatible. So I can't really think of a reason why you'd want versioning to that level. Major version changes should be backwards compatible as well, but there is probably a stronger argument for wanting versioning at that level, since there is new functionality being added.
While the "YYYY-MM-DD" date format does conveniently fit the semantic versioning format, I feel like Stripe's intention is that the date is more of a single major version. They specifically say: "Although backwards-incompatible, each one contains a small set of changes that make incremental upgrades relatively easy so that integrations can stay current.". To me, this means it's a major version.

Yes, I can agree with your position.
Do we have any other pathway that would open up the ability to use three levels of versions that in-turn makes date style versioning possible?
It's less about being strictly "right" than making a common API versioning format possible

How about this?
@api_version('2023-01-12')
@app.get('/something')
def get_something():
   ...

To me, it feels like they're just using a date as a major version, instead of a single number.

Perhaps the answer is to simply hardcode the a date with an internal version
versions = versionize(
    app=app,
    prefix_format='/2023-01-12',
    enable_latest=True,
    latest_prefix='/latest'
)

Ha - same thought, reckon that probably works nicely

Oh shoot, I just realized I have major/minor typed as ints in the decorator. Didn't realize that. I suppose I can make them be int | str.

Okay, I just went to implement this but then realized it's more complicated than originally thought.
When the versionize function runs, it sorts the versions in ascending order. By doing that, it's able to determine which endpoints stay and which get overridden for each version.
If I allow for arbitrary strings, then that sort won't always do as expected. There is no easy way to distinguish which versions are older or newer, like you can with ints. In your case of dates, the sorting should work as expected (as long as you always follow "YYYY-MM-DD" format). You will just get type-checker warnings, if you even use one. You will also probably need to set the default_version param of versionize to be a tuple of strings.
Here is a potential solution:
You must always give major/minor versions as ints. But you can also give a string alias for each version.
So in you're case, you'd have something like:
@api_version(1, alias='2023-01-12')
@app.get('/something')
def get_something():
   ...

@api_version(2, alias='2023-02-05')
@app.get('/something')
def get_something_2():
   ...

which produces the following routes...
GET /2023-01-12/something
GET /2023-02-05/something

However, then there is a bit of a conflict because as versionize now has 2 ways of generating a route name, alias or prefix_format. Would it generate both or would alias always have priority?
Another possible option is to just allow date objects to be major/minor versions, in addition to ints. This is probably the simpler solution.

If you take the date-object approach, you might want to prevent timezone-aware date objects else you'd end up in a painful world of timezone confusion.
Perhaps the even easier middle ground is to use major versions in the format YYYYMMDD and then express the prefix format as
prefix_format = "/{major[0:4]}-{major[4:6]}-{major[6:8]}"

This would almost get us there; I suspect the "problem" then is with some of the generated documentation and /versions route?

I don't really see a benefit in that approach vs. just using "YYYY-MM-DD" as your major version and using prefix_format as "{major}". Both "YYYY-MM-DD" and "YYYYMMDD" should sort just fine, so I don't see it being a problem. However, that prefix format would not work in the current implementation, which just uses simple string.format(...) to generate the prefixes.
My real concern is just allowing any arbitrary string, since the user must ensure that their version format will sort properly.
For example, if someone had versions like "2022-10-10" and "2022-7-10", versionize would incorrectly think "2022-10-10" came before "2022-7-10", which is not what the user intended. That will cause problems.

Yes, breaking the strictness of the int irks me too.
How about a versionize() flag that allows the developer-user to optionally enable "dangerous" string versions.
This way the default good behavior of versionize does not change, while it still gives the developer a way to accept and acknowledge they know what they are stepping into if they do.  Perhaps an attribute versions_as_strings: bool
An alternative approach might be to introduce a new versionize_by_string() method that would allow versionize() to keep it's strict int args and again open up the possibility for the above.
Anyway, I'm sure there are other oddball situations where non-integer based versions probably make sense (although less common) so it's a feature/extension that is more than just accommodating a couple of silly dash characters in a date-looking-format string.

I think, that is should be theoretically possible to use any hashable object as a version, if version_format and prefix_format could be functions.
That will also add support for more complex prefixes and versions. For example, I always want last version to have "/dev" prefix, and I have to hack that right now.
The sorting problem could be resolved by forcing developer to provide function that will be used as a key in sorted(), if they want to use "unsafe" versions (not int).

Ok so maybe something like this:

Change api_version and api_version_remove to allow for major/minor to be anything hashable
Add a new param to versionize called version_sort. version_sort would be a function used to sort the versions however you want (passed as key to sorted). If not provided, the default sort order of sorted is used.
Perhaps you could also provide a list of optional aliases for each version, too. So like api_version(1, 3, aliases=['alias1', alias2']).

Does this all sound about right?
@kunesj Does the enable_latest and latest_prefix params not work for you regarding wanting the "last version to have "/dev" prefix"?

@kunesj @ndejong How does this look for a solution: https://github.com/alexschimpf/fastapi-versionizer/compare/alex/non-integer-versions?expand=1 ?

@kunesj @ndejong I've created a new PR for this btw: https://github.com/alexschimpf/fastapi-versionizer/pull/18


Add workspace ignore list

Fixes #56

Could you take a look when you have time @bnjbvr ? :)

Yep, sorry for the slow response time! Last week was a bit hectic. I will try to take a look this week.

Hmm one issue I now encounter is that if I list a package to be ignore in the workspace, if in some crate it is indeed detected as used I have a warning. So maybe it would be better to store the workspace list separately so that no warnings are generated from them?

Made the change I commented about above :)


Post season data retrieval.

Trying to get the first week of the playoffs of the 2015 season by using the following:
import nflgame as nf
games = nf.games(2015, week = 1, kind = 'POST')

and I get the following error message:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "nflgame\__init__.py", line 228, in games
    return list(games_gen(year, week, home, away, kind, started))
TypeError: 'NoneType' object is not iterable

Any help on this would be greatly appreciated!

If you are running an old version of 'nflgame' your schedule URL is
probably not pointed to the correct nfl.com URL. Try updating to the latest
'nflgame'.
On Jan 11, 2016 6:20 PM, "Michael"<EMAIL_ADDRESS>wrote:

Trying to get the first week of the playoffs of the 2015 season by using
the following:
import nflgame as nf
games = nfgames(2015, week = 1, kind = 'POST')
and I get the following error message:
Traceback (most recent call last):
File "", line 1, in
File "nflgame__init__py", line 228, in games
return list(games_gen(year, week, home, away, kind, started))
TypeError: 'NoneType' object is not iterable
Any help on this would be greatly appreciated!
—
Reply to this email directly or view it on GitHub
https://github.com/BurntSushi/nflgame/issues/191.

Was this resolved? I am having a similar problem, I am unable to retrieve week 2 data for the 2015 post season. I tried updating
import nflgame
games = nflgame.games(2015, week=2, kind='POST')
plays = nflgame.combine_plays(games)

The code above results in an error: TypeError: 'NoneType' object is not iterable
However, when the week is set to either 1 or 3 I can retrieve the game.
I must add that a double checked nflgame.VERSION and I see '1.2.19'


Refactorings

Reference Issues/PRs
What does this implement/fix? Explain your changes.
Any other comments?

I will update CHANGELOG.md soon, review the rest.
@sadrasabouri


Remove spurious dependency

ase requirement has been dropped in f2f3d46e5985a22f833fc04badba53d272682d9a

Gonna approve when Travis CI is done!

Not sure why Travis-CI never completed. Restarting the build now.


Screen setting - Log out and then back in, the resolution will be reset

PC-2-screen0.webm
build : 0H249
machine : virtual and physical

start-hello sets the screen to the native panel resolution on each start.
Or is it being reset to a wrong resolution?

start-hello sets the screen to the native panel resolution on each start.

I think it should be this, it is also available on the physical machine, but it is based on the resolution of the screen.


=str code clean up in Sliding.

Can we get a description on the PR? What is intends to do, etc.?
Sometimes, PRs are self-evident but with edits to existing runtime code, I think they need to be justified.

@mdedetrich @pjfanning see line at 901,it checks step ＜= n


add SeqWait

SeqWait adds a way to .await the arrival of some sequence number.
It provides wait_for(num) which is an async fn, and advance(num) which
is synchronous.
This should be useful in solving the page cache deadlocks, and may be
useful in other areas too.
This implementation still uses a mutex internally, but only for a brief
critical section. If we find this code broadly useful and start to care
more about executor stalls due to unfair thread scheduling, there might
be ways to make it lock-free.

BTW, there's a similar facility built into PostgreSQL's so-called "lightweight locks", also used with LSNs: see functions LWLockWaitForVar() and LWLockUpdateVar() in src/backend/storage/lmgr/lwlock.c. Doesn't affect or help with this rust version in any way, but I thought I'd mention it.

But wouldn't it be more Rusty to make it a generic that work with any PartialOrd type?

Absolutely. We could plug in an Lsn parameter and all the type signatures would be correct.
Sometimes I fear that code with generic parameters can be a bit hard to read, so I like to build prototypes without them, and then bring them in once everything seems to be working.

I attached the page cache changes to this PR as well, since they're the whole reason for writing this.
They're suprisingly small! I hope they're correct-- I'm not sure how to exhaustively test this part.

Sometimes I fear that code with generic parameters can be a bit hard to read, so I like to build prototypes without them, and then bring them in once everything seems to be working.

Makes sense


Add support for OpenTelemetry 0.16 and tracing-opentelemetry 0.15

One last issue - can you update the README to include the newer feature flag?

One last issue - can you update the README to include the newer feature flag?

Of course! I added it where the other features are mentioned. I did not reformat the line because I'm not sure if there's a specific formatting style for Markdown you'd prefer.


colon/semi-color expected error

When I import a literal string from one of my npm libraries it gives an error
semi-color expected and colon-excpected
I tried the same object structure but without module and it works fine.

(As referenced from https://github.com/styled-components/vscode-styled-components/issues/67)

I believe this is fixed in 0.6.2: https://github.com/styled-components/vscode-styled-components/pull/80

Nice!
But I guess the updated package hasn't been published?

It is published. Styled components just needs to pick it up too


Where has cw_multi_test::addons::MockAddressGenerator gone?

Power users are asking where cw_multi_test::addons::MockAddressGenerator has gone from version 0.x.x to 1.x.x of MultiTest?

As a maintainer of the MultiTest library, I would like to sincerely apologize for any shortcomings in my communication on this topic, especially not informing about this change directly in the CHANGELOG.
Since version 1.0.0 of MultiTest the cw_multi_test::addons::MockAddressGenerator was removed permanently and new convenient options for creating addresses were shipped with this version.
All of them work the same way since version 1.0.0 of MultiTest and are described in this article in section Summary of address generation options in tests.
For your convenience, all these options are presented below as short test cases.
Thanks for using MultiTest!
cosmwasm_std::testing::MockApi
#[test]
fn creating_address_with_default_prefix_should_work() {
    use cosmwasm_std::testing::MockApi;

    let addr = MockApi::default().addr_make("owner");
    assert_eq!(
        "cosmwasm1fsgzj6t7udv8zhf6zj32mkqhcjcpv52yph5qsdcl0qt94jgdckqs2g053y",
        addr.as_str()
    );
}

#[test]
fn creating_address_with_custom_prefix_should_work() {
    use cosmwasm_std::testing::MockApi;

    let addr = MockApi::default().with_prefix("juno").addr_make("owner");
    assert_eq!(
        "juno1fsgzj6t7udv8zhf6zj32mkqhcjcpv52yph5qsdcl0qt94jgdckqsmg2ndy",
        addr.as_str()
    );
}

cw_multi_test::MockApiBech32
#[test]
fn creating_address_with_prefix_should_work() {
    use cw_multi_test::MockApiBech32;

    let addr = MockApiBech32::new("cosmwasm").addr_make("owner");
    assert_eq!(
        "cosmwasm1fsgzj6t7udv8zhf6zj32mkqhcjcpv52yph5qsdcl0qt94jgdckqs2g053y",
        addr.as_str()
    );
}

cw_multi_test::MockApiBech32m
#[test]
fn creating_address_with_prefix_should_work() {
    use cw_multi_test::MockApiBech32m;

    let addr = MockApiBech32m::new("cosmwasm").addr_make("owner");
    assert_eq!(
        "cosmwasm1fsgzj6t7udv8zhf6zj32mkqhcjcpv52yph5qsdcl0qt94jgdckqsl5lc5x",
        addr.as_str()
    );
}

cw_multi_test::IntoAddr
#[test]
fn creating_address_with_default_prefix_should_work() {
    use cw_multi_test::IntoAddr;

    let addr = "owner".into_addr();
    assert_eq!(
        "cosmwasm1fsgzj6t7udv8zhf6zj32mkqhcjcpv52yph5qsdcl0qt94jgdckqs2g053y",
        addr.as_str()
    );
}

#[test]
fn creating_address_with_custom_prefix_should_work() {
    use cw_multi_test::IntoAddr;

    let addr = "owner".into_addr_with_prefix("juno");
    assert_eq!(
        "juno1fsgzj6t7udv8zhf6zj32mkqhcjcpv52yph5qsdcl0qt94jgdckqsmg2ndy",
        addr.as_str()
    );
}

cw_multi_test::IntoBech32
#[test]
fn creating_address_with_default_prefix_should_work() {
    use cw_multi_test::IntoBech32;

    let addr = "owner".into_bech32();
    assert_eq!(
        "cosmwasm1fsgzj6t7udv8zhf6zj32mkqhcjcpv52yph5qsdcl0qt94jgdckqs2g053y",
        addr.as_str()
    );
}

#[test]
fn creating_address_with_custom_prefix_should_work() {
    use cw_multi_test::IntoBech32;

    let addr = "owner".into_bech32_with_prefix("juno");
    assert_eq!(
        "juno1fsgzj6t7udv8zhf6zj32mkqhcjcpv52yph5qsdcl0qt94jgdckqsmg2ndy",
        addr.as_str()
    );
}

cw_multi_test::IntoBech32m
#[test]
fn creating_address_with_default_prefix_should_work() {
    use cw_multi_test::IntoBech32m;

    let addr = "owner".into_bech32m();
    assert_eq!(
        "cosmwasm1fsgzj6t7udv8zhf6zj32mkqhcjcpv52yph5qsdcl0qt94jgdckqsl5lc5x",
        addr.as_str()
    );
}

#[test]
fn creating_address_with_custom_prefix_should_work() {
    use cw_multi_test::IntoBech32m;

    let addr = "owner".into_bech32m_with_prefix("juno");
    assert_eq!(
        "juno1fsgzj6t7udv8zhf6zj32mkqhcjcpv52yph5qsdcl0qt94jgdckqsw56lgx",
        addr.as_str()
    );
}

cw_multi_test::App
#[test]
fn creating_address_with_default_prefix_should_work() {
    use cw_multi_test::App;

    let app = App::default();

    let addr = app.api().addr_make("owner");
    assert_eq!(
        "cosmwasm1fsgzj6t7udv8zhf6zj32mkqhcjcpv52yph5qsdcl0qt94jgdckqs2g053y",
        addr.as_str()
    );
}

#[test]
fn creating_bech32_address_with_custom_prefix_should_work() {
    use cw_multi_test::{no_init, AppBuilder, MockApiBech32};

    let app = AppBuilder::default()
        .with_api(MockApiBech32::new("juno"))
        .build(no_init);

    let addr = app.api().addr_make("owner");
    assert_eq!(
        "juno1fsgzj6t7udv8zhf6zj32mkqhcjcpv52yph5qsdcl0qt94jgdckqsmg2ndy",
        addr.as_str()
    );
}

#[test]
fn creating_bech32m_address_with_custom_prefix_should_work() {
    use cw_multi_test::{no_init, AppBuilder, MockApiBech32m};

    let app = AppBuilder::default()
        .with_api(MockApiBech32m::new("juno"))
        .build(no_init);

    let addr = app.api().addr_make("owner");
    assert_eq!(
        "juno1fsgzj6t7udv8zhf6zj32mkqhcjcpv52yph5qsdcl0qt94jgdckqsw56lgx",
        addr.as_str()
    );
}

I hope this helps.


fix(frontend): loading banner images layout shift

Motivation
This PR addresses a glitch when loading "banner images" on mainnet, where loading assets takes some time, causing a layout shift if no minimal height is set.
Notes
I don't like adding unnecessary elements to the DOM. This issue might have been resolved by simply applying some styling to the Img component. However, since the glitch primarily affects banners, I felt this solution was less likely to introduce unexpected errors, especially as the application does not yet have sufficient E2E snapshot testing coverage.
Changes

Create new ImgBanner component that contains a component with a min-height and includes the img
Use component in "What can I do with my tokens" and "How Oisy Wallet works"
Use component in loader modal. Note that here there used to be a minimal height but I think it become broken with last changes

some screenshots in the description?

I did not provided screenshots because, it still look the same. I would rather need to record GIFs on mainnet and deploy a version on mainnet to show the difference. Or faking the loading with some timeout locally. Just felt like it was quite some efforts that I could spare. Hope it makes sense.


fix: remove updatedTime footer & make frequent refreshes

High Level Overview of Change
Remove last updated time from tokens page. Make refreshes every 5 minutes to keep the data as updated as possible.

Context of Change
Change the refresh time to 5 minutes to let users see updated information. Delete the display footer to get rid of the time inconsistencies between the 3 pods.

Type of Change

[X] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Refactor (non-breaking change that only restructures code)
[ ] Tests (You added tests for code that already exists, or your new feature included in this PR)
[ ] Documentation Updates
[ ] Release

Before / After
Before:

After:

Test Plan
Ran npm test and verified that nothing is breaking.

Close this because of incorrect base.


ci: Remove libtool from macOS

On macOS with brew installing libtool installs glibtool which isn't
ever referenced. Whatever this is for must work fine with the default
libtool vendored with Xcode.
Upstream PR: https://github.com/envoyproxy/envoy/pull/7499
Signed-off-by: Keith Smiley<EMAIL_ADDRESS>

It looks like autoreconf really does expect glibtool, we're not hitting the codepath that needs this right now, but I guess we should leave it


short learning background first, without updating that

Hi, thank for your amazing lib first
I have a factory rail that at first moments (first 10 second) i want to learn background and then extract objects on it,
for my video multicue was good but i found that it is updating background model in each frame
is there any other algorithm that just build bkg model base on first seconds?
I'm using c++,
this is process method of multicue, i have commented UpdateModel_Par(); but it made no difference
void MultiCue::process(const cv::Mat &img_input, cv::Mat &img_output, cv::Mat &img_bgmodel)
{
  init(img_input, img_output, img_bgmodel);

  //--STep1: Background Modeling--//
  //IplImage* frame = &IplImage(img_input);
  IplImage* frame = new IplImage(img_input);
  IplImage* result_image = cvCreateImage(cvGetSize(frame), IPL_DEPTH_8U, 3);
  cvSetZero(result_image);
  if (g_iFrameCount <= g_iTrainingPeriod) {
    BackgroundModeling_Par(frame);
    g_iFrameCount++;
  }
  //--Step2: Background Subtraction--//
  else {
    g_bForegroundMapEnable = FALSE;

    ForegroundExtraction(frame);
    UpdateModel_Par();

    //Get BGS Results
    GetForegroundMap(result_image, NULL);
  }
  delete frame;

  img_background = cv::Mat::zeros(img_input.size(), img_input.type());
  img_foreground = cv::cvarrToMat(result_image, TRUE);
  cvReleaseImage(&result_image);

#ifndef MEX_COMPILE_FLAG
  if (showOutput)
    cv::imshow(algorithmName + "_FG", img_foreground);
#endif

  img_foreground.copyTo(img_output);
  img_background.copyTo(img_bgmodel);

  firstTime = false;
}

Hi @sabrabano0 sorry for my delayed feedback to you.
Yes, as you cited in https://github.com/andrewssobral/bgslibrary/issues/186 , the MultiLayerBGS algorithm is the best choice for you because it generates and saves a background model file during the learning step. Unfortunately, the others one produce an in-memory model with no option to save it as file.

yes multicue had problem in free memory and takes o long time
but multilayer FPS is 2 :(
how should i detect objects on convey belt? @andrewssobral andrewssobral


Live search slow in IE

Hi.
I'm populating the select with about 3000 entries and when using live search in IE11, the experience is quite bad. When writing e.g. 3 characters it takes literally seconds for the select to do the search.
Doing the same thing in Firefox shows acceptable performance.
Bootstrap-select 1.9.4, Windows 7, jQuery 2.14, Bootstrap 3.3.5

I also am experiencing the same difficulty with a little over 4000 records. Chrome is really slow at live search, taking 6 seconds or more when fully typing a name. In firefox it is still slow, but remarkably better.
Using Bootstrap-select 1.10.0, mac el captan, jquery 1.11.3, bootstrap 3.3.2

In fact, all browser I tested is so slow when the records are over 2 thousands... Big problem for my system...
Using Bootstrap-select 1.10.0, jquery 1.12.2, bootstrap 3.3.6

Check function with delegating on "input propertychange" event.
There are lots of work with DOM: filtering (2 times), escape function, replacing and html inserting and other. If you have more than 1000 entries and some optgroups, it works very slow in all browsers.
The only way i see now is to set throttling and increasing live-search keyword length from zero to 3 or more. Thats not removing the problem, but resolving some user UI lag questions.

Are there any updates on the performance issues?
I opened issue https://github.com/silviomoreto/bootstrap-select/issues/1229, suggesting virtualization when scrolling on large lists (ag-grid does this very well). Perhaps ambitious, but having the ability to load from JSON (issue https://github.com/silviomoreto/bootstrap-select/issues/1151), live search against the JSON, and have virtual scrolling would solve all the performance issues and allow for very large lists. Perhaps some of that is covered by the Ajax Bootstrap Select clone, referenced in issue https://github.com/silviomoreto/bootstrap-select/issues/953, but I don't need ajax search. It would be great to not even have to have the SELECT in the DOM.
Again, this might be too ambitious, but would enable people to have as many bootstrap selects as they want with as many options as they want without any issues.

Help me
https://github.com/silviomoreto/bootstrap-select/issues/1650

I just added a virtual scrolling feature (which results in instant searching) in the virtual-scrolling branch. It's still a WIP, and there are a few features missing, some I'm aware of (the startsWith feature for example), and some I'm sure I'm not. Try it out - I'm looking for feedback. Please post all findings in #1229.

Released in v1.13.0!


Integrate with template

I cann't do this step "Add libAviasalesSDKTemplateLibrary.a to "Target Dependencies""
A have all files but i haven't possibility to do this because there no this file. Can you help me with this problem?

Please checkout new SDK and new integration steps


fixed accessing salesforce version

When I tried to use the library (in Python 3), I've got the following error:
  File "/usr/local/lib/python3.5/site-packages/salesforce_bulk_api.py", line 58, in __init__
    .replace('v' + salesforce.version,
TypeError: Can't convert 'SFType' object to str implicitly

Looks like string representation of the version is written into sf_version of Salesforce object.
Tried this fix locally and it works.

Thanks @bratchenko!  I will merge this and release a new package as 1.1.1


[8.x] Added prohibited_with validation

I've encountered a requirement in a few systems where two potential fields could be passed, but if one exists the other cannot exist. The prohibited_if validation allows you to counter this only if you know the potential values of the second field, so I've added prohibited_with as a way to create a simple NAND between fields.
The most recent example was working with the Facebook Business SDK, where a customer record could accept email or emails, but passing both fields causes an error (because it can't be resolved into a correct single value). With this validation, I could catch that earlier in the application and ensure that I'm not having to deal with API/SDK errors. For this example:
Validator::validate([
    'email' =><EMAIL_ADDRESS>
    'emails' =><EMAIL_ADDRESS><EMAIL_ADDRESS>], [
    'email' => 'prohibited_with:emails'
]);

You can also pass multiple fields for a situation where you have one field or multiple fields (e.g. passing a model ID as well as fields that can only be set on creation). In this case, if any of the listed prohibited_with fields exist, it will trigger a validation failure.
Validator::validate([
    'post_id' => 1,
    'created_by' => 2,
    'created_at' => '2020-07-16 20:54:22'
], [
    'post_id' => 'prohibited_with:created_by,created_at'
]);

Finally, this can be used with required_without to create a XOR, where one property must be passed, but never both.
Validator::validate([
    'email' =><EMAIL_ADDRESS>
    'emails' =><EMAIL_ADDRESS><EMAIL_ADDRESS>], [
    'email' => ['prohibited_with:emails', 'required_without:emails']
]);

If you choose to merge, I will send PRs to laravel/docs and laravel/laravel.

Are we sure that this Arr::has behavior exhibits the same behavior as if a rule was required using the required rule?

I don't think that it has to. prohibited_with isn't a required type rule, so much as "these other properties can not exist".
An empty-ish value could still be "valid". e.g. setting emails to null or [] might be a valid request, but if you're also passing email then the users intention is still potentially unclear. The behaviour that I expect from prohibited_with is not just "the other parameters are empty", but "the other parameters do not exist"

Well, I'm mainly interested in consistency between required_with and prohibited_with in terms of how they behave. Do you think they should have different definitions of "with"?

I see your point. There are a couple of resolutions that I can see, neither of them great.

Changing Arr::has to validateRequired would create consistency of "with", but would (in my opinion) harm the utility due to allowing both fields to be present.
Change this to prohibited_if_present or prohibited_when_present, or something equally unwieldy.

I think I'll just table this for now because I don't have a great solution.

@taylorotwell if I changed it to prohibits: it would be functionally identical, but without the confusion over with.
e.g. 'email' => 'prohibits:emails' would be functionally equivalent (i.e. if email is defined, emails must not be defined), but wouldn't cause the with confusion.


Update classify_prs notebook

Minor updates/fixes to the release notebook

Closed by https://github.com/pytorch/vision/pull/8383


Store files in '.azurite/' subdirectory of cwd by default, and ensure location exists

This is a change to the default directory used to store Azurite files to utilize an '.azurite' folder in the current working directory. This allows for consolidation of files without polluting the working directory, and makes it easier to .gitignore the files.
Additionally, this change now ensures the directory exists on startup, creating it if it does not.
Partially Fixes https://github.com/Azure/Azurite/issues/391 -- I was not able to add the ability to use relative paths nor workspace variables as requested, but the main requests in the issue are addressed with this PR.
I am not sure how you'd like to manage this change as it is potentially breaking. I'm also not sure how/where to build appropriate tests for this.

Thanks @dpolivy! It helps a lot!
As you mentioned, it's a breaking change. How about split into 2 separate PRs:

[Non-Breaking ] Support creating unexisted path, and support relative path in VSC by location parameter. This allows us specifying a directory in the configuration.
[Breaking] Change the default location value for azurite. I'd like leave this breaking change in next major release.

@XiaoningLiu Thanks for taking a look. I didn't really resolve the relative/absolute path in the location setting issue, though I suppose that could be done with path.isAbsolutePath.
I don't have a ton of time to devote to this but could probably do one more pass to add the above and split this into 2 PRs. Before I do that, it'd be great if you could review and advise if there's any other changes or additions you'd like to see.
I also didn't see any easy way to resolve VSCode variables in the settings; if you know of a way to do this easily, let me know and I can look at including it too.

@XiaoningLiu Now that the other PR was merged, I cleaned up this one which sets the default directory to .azurite. I know you wanted to save this for a breaking change release, but let me know if there's anything else that needs to be done now. Or, I can just hand this over to you to manage going forward as you see fit.

@XiaoningLiu - Any update on this review?  I know quite a few users who would really appreciate the default setting of azurite to be consolidating it's files into a ./azurite subfolder.

Come on now maintainers, this PR has been open since September last year, it's a small simple change that addresses a real issue faced by users (our team included). It's frustrating to see people donate their time and effort to fix a real issue, only to have their contribution completely ignored. Not good open source culture IMO - you can do better MS. Ping @XiaoningLiu since you're the current assignee.

For any PRs including breaking changes, we will wait for next major release by default, i.e Azurite v4.
For example, following scenario should work under same major version releases:

User lunches Azurite v3.18.0 in VSC under project1. Azurite creates database files under directory c:/project1
User upgrades Azurite to v3.19.0 in VSC under same project1.
User lunches Azurite 3.19.0. We will expect Azurite 3.19.0 loads databases from 3.18.0 by default.

Obviously, the PR is still breaking. In step#3, Azurite 3.19.0 will try to load and create databases from c:/project1/.azurite and ignore files under c:/project1. We will treat it as a breaking change. It breakes the user experiences and brings additional manual changes for someone upgrades Azurite version.
For quick merge, please consider making it non-breaking. For example, by adding a new parameter as flag to turn on the behavior. The default value of the parameter should be false in current major version, and in next major version, we can enable the parameter to true be default.
By the way, the PR should create .azurite folder if it doesn't exist.

So if this PR is updated to do the following:

Check if default azurite files exist and use those if present
If not, default to .azurite folder (or whatever is in settings)

You will accept the PR?

@JustinGrote IMO a better order would be:

If a location is set in settings, always use that
Otherwise if files exist in legacy default location, use that
Otherwise use new .azurite dir

Well yes, I meant to imply #1

Ah, is this happening?   Yes!  🎉

@TroyWitthoeft  if @dpolivy doesn't pick it up, I might give it a go.

@JustinGrote Would be awesome if you did! 🍻
One slight drawback of this approach though is that it would not be possible to use any other directory relative to the workspace than the default .azurite - any explicitly specified location would still be absolute.
The best non-breaking way I see to rectify that, would be to also add support for VS Code variables so that one could use ${workspaceFolder} in the setting.
As @edwin-huber mentions above however, generically supporting resolution of all VS Code variables may not be possible in this context. But I don't see why we could not just add code to replace the tokens ${workspaceFolder} and ${workspaceFolder:name} with the corresponding workspace path provided to us by the API:
https://code.visualstudio.com/api/references/vscode-api#workspace
To support multi-root workspaces, we should use the workspaceFolders property and support named workspace folders as described here:
https://code.visualstudio.com/docs/editor/variables-reference#_variables-scoped-per-workspace-folder
And mention in docs, settings hint etc. that this particular variable token is supported.
Another big bonus, at least from my point of view, would be also supporting environment variables in the path, which I think would also definitely qualify as non-breaking.

Thanks for pushing on this, everyone. It's been a while since I worked on this. While I like the approach of trying to make this not a breaking change, from what I recall that's going to be much easier said than done due to the separation between the configuration/environment which defines the location path and the code that actually tries to load the database files to see if they exist.
I don't know that I'll have the ability to revisit this right away, so if someone is motivated to dig in, I'm happy to provide write access to my fork so you can update this PR.

One slight drawback of this approach though is that it would not be possible to use any other directory relative to the workspace than the default .azurite - any explicitly specified location would still be absolute.

A prior PR (#1153) I submitted added support for relative paths to the location setting; this has been merged and should be in the code today.

@dpolivy Dude.. 😅 I had no idea relative folder support had already been merged. That actually fixes our issues, for all intents and purposes. Thank you!
OOC though, do you know if there is any way to configure this ⬇ in workspace settings?

We have a multi-root workspace, and having to select one of them every time Azurite starts is a bit of a pain... any way around it? Like an azurite.workspaceName setting or similar?

OOC though, do you know if there is any way to configure this ⬇ in workspace settings?

It doesn't look like there's any way to avoid that currently. If there are multiple roots, it looks like it always pops that dialog: https://github.com/Azure/Azurite/blob/main/src/common/VSCEnvironment.ts#L51

Any chance we can get some movement on this? 🙏🏼

This is a breaking change.
Breaking is only allowed in major release.
So we will not take it until the next major release.
Xiaoning has given some suggestion to convert it to a none breaking change.
If it's not breaking, we can take it when pass review.


Lazy Loading Components get an "Cannot read property 'querySelectorAll' of null" error

Examples bug report
Example name
Lazy Loading Components
Describe the bug
After following all the steps and running the app, visiting http://localhost:3000/p/hello-nextjs will output the error Cannot read property 'querySelectorAll' of null with a stack trace.
To Reproduce
Steps to reproduce the behavior, please provide code snippets or a repository:

Go to https://nextjs.org/learn/excel/lazy-loading-components/setup
Follow the steps
Visit http://localhost:3000/p/hello-nextjs
See error

Expected behavior
It is expected to not have an error.
Screenshots

System information

OS: Windows 10 Pro
Version of Next.js: 6.1.1
Node: v10.8.0
npm: 6.1.0

Please move the issue to https://github.com/zeit/next-site/issues


JDK 22 support

Hi
Do you have any plans supporting JDK 22 as base image?
I looked at the repository tags here: https://hub.docker.com/_/tomcat and saw only JDK 21 or JRE 21 as base image (for both 10.1.x and 11.x versions) ?
It doesn't allow us to fully migrate our projects to JDK 22.

Unfortunately, we currently only support LTS Java versions; see https://github.com/docker-library/tomcat/pull/299 for more details/discussion.


Update reference-remote-network-configurations.md

Add 65486 as another reserved ASN that customers should not use

#sign-off

@shlipsey3

Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team


Setup a CI pipeline

We have PRs setup to test in travis. Should we switch to using CircleCI?

Do we need that for simpl? Does CircleCI have a free tier?

They do, We could switch to that if needed. Since it is already up and working in Travis I think thats fine. Travis plays just as well with coveralls so I don't see a specific reason to move to circle at the moment. The only case I could make would be to have a parallel with with some of our other projects in terms of pipeline.


add-migration not working with iot core background task project

Hi,
I have an iot core background task project, which seems to be of the type "windows runtime component".
Because of the limitations of such a project type (for example inheritance) i added a second c# class library project which contains my model and entity framework core and it's database context.
Because of the documented problems of running add-migration with class libraries as a startup project I set the iot core project as my startup project, the database class library is referenced, the Microsoft.EntityFrameworkCore.Tools is installed in the startup project and the app.config fix is applied.
In this case add-migration fails with the wonderfully helpful error message (full exception below):
Could not load assembly 'iot Project'. Ensure it is referenced by the startup project 'iot Project'.
Microsoft.EntityFrameworkCore.Design.OperationException: Could not load assembly '<iot Project>'. Ensure it is referenced by the startup project '<iot Project>'. ---> System.IO.FileNotFoundException: Could not load file or assembly '<iot Project>' or one of its dependencies. The system cannot find the file specified.
   at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.Assembly.Load(AssemblyName assemblyRef)
   at Microsoft.EntityFrameworkCore.Design.AssemblyLoader.Load(String assemblyName)
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.<>c__DisplayClass5_0.<.ctor>b__2()
   --- End of inner exception stack trace ---
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.<>c__DisplayClass5_0.<.ctor>b__2()
   at Microsoft.EntityFrameworkCore.Internal.LazyRef`1.get_Value()
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.<>c__DisplayClass5_0.<.ctor>b__5()
   at Microsoft.EntityFrameworkCore.Internal.LazyRef`1.get_Value()
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.AddMigrationImpl(String name, String outputDir, String contextType)
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.AddMigration.<>c__DisplayClass0_1.<.ctor>b__0()
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.OperationBase.<>c__DisplayClass3_0`1.<Execute>b__0()
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.OperationBase.Execute(Action action)

The workaround I had to resort to, was to add an empty dummy UWP application project to my solution that references the class library , install the tools, select it as a startup project and then run add-migrations (which finally worked)
Further technical details
EF Core version:
"Microsoft.EntityFrameworkCore.Sqlite": "1.0.0",
"Microsoft.EntityFrameworkCore.Tools": "1.0.0-preview2-final"
Operating system:  Windows 10 10586.494
Visual Studio version: VS2015 Update 3

In the past, we have not supported using Windows Runtime Components (WinMD). @rowanmiller do we want to revisit this?
Cref https://github.com/aspnet/EntityFramework/issues/4684#issuecomment-193903540
Backlog item: https://github.com/aspnet/EntityFramework/issues/1058

@natemcmaster good point, clearing the milestone to rediscuss in triage

Agreed that this can stay on backlog. The real solution for the scenario described in the initial report of this issue is to support class libraries, which we are already working on.


AVDL Linter

Adding lint checks for avdl.
Ignores existing lint errors. New lint errors will cause make to fail.
Current lint errors:

Method name case
Method arg case
Record field case
Record case
Typedef usage for number types JS can't fully represent (since it only has double). No warnings for long though, but we'll want to use a long package in these cases (https://www.npmjs.com/package/long)?
Protocol name case is not linted (half our protocols error here so too many to fix?)
Use of bool instead of boolean

I incorporated it into flow.js and the checks are very basic. I just wanted to spend an hour doing this so we can prevent future weirdness!
Current run outputs this:
node --harmony ./bin/flow.js
Ignoring lint error: MessageID: uint cannot be fully represented as a Javascript number (double)
Ignoring lint error: InboxVers: uint64 cannot be fully represented as a Javascript number (double)
Ignoring lint error: Record variable names should not be capitalized: GenericPayload.Action
Ignoring lint error: Record variable names should not be capitalized: NewConversationPayload.Action
Ignoring lint error: Record variable names should not be capitalized: NewMessagePayload.Action
Ignoring lint error: Record variable names should not be capitalized: ReadMessagePayload.Action
Ignoring lint error: Record variable names should not be capitalized: SetStatusPayload.Action
Ignoring lint error: Record variable names should not be capitalized: UnreadUpdate.UnreadMessages
Ignoring lint error: Record variable names should not be capitalized: OutboxRecord.Msg
Ignoring lint error: Record variable names should not be capitalized: UnreadFirstNumLimit.NumRead
Ignoring lint error: Record variable names should not be capitalized: UnreadFirstNumLimit.AtLeast
Ignoring lint error: Record variable names should not be capitalized: UnreadFirstNumLimit.AtMost
Ignoring lint error: Record variable names should not be capitalized: GetConversationForCLILocalQuery.MessageTypes
Ignoring lint error: Record variable names should not be capitalized: GetConversationForCLILocalQuery.Since
Ignoring lint error: Method names should not be capitalized: SetConversationStatusLocal
Ignoring lint error: Method names should not be capitalized: GetMessagesLocal
Ignoring lint error: Method names should not be capitalized: DownloadAttachmentLocal
Ignoring lint error: Method names should not be capitalized: DownloadFileAttachmentLocal
Ignoring lint error: Method names should not be capitalized: CancelPost
Ignoring lint error: Method names should not be capitalized: RetryPost
Ignoring lint error: Method names should not be capitalized: NewChatActivity
Ignoring lint error: Method names should not be capitalized: SetConversationStatus
Ignoring lint error: Method names should not be capitalized: GetUnreadUpdateFull
Ignoring lint error: Method names should not be capitalized: Get
Ignoring lint error: Method names should not be capitalized: Post
Ignoring lint error: Method names should not be capitalized: PostJSON
Ignoring lint error: Record variable names should not be capitalized: PublicKey.KID
Ignoring lint error: Record variable names should not be capitalized: PublicKey.PGPFingerprint
Ignoring lint error: Record variable names should not be capitalized: PublicKey.PGPIdentities
Ignoring lint error: Record variable names should not be capitalized: SessionStatus.SessionFor
Ignoring lint error: Record variable names should not be capitalized: SessionStatus.Loaded
Ignoring lint error: Record variable names should not be capitalized: SessionStatus.Cleared
Ignoring lint error: Record variable names should not be capitalized: SessionStatus.SaltOnly
Ignoring lint error: Record variable names should not be capitalized: SessionStatus.Expired
Ignoring lint error: Record variable names should not be capitalized: ExtendedStatus.Clients
Ignoring lint error: Method names should not be capitalized: List
Ignoring lint error: Method names should not be capitalized: Resolve
Ignoring lint error: Method names should not be capitalized: Resolve2
Ignoring lint error: Record variable names should not be capitalized: IdentifyKey.KID
Ignoring lint error: Method names should not be capitalized: FSEvent
Ignoring lint error: Method names should not be capitalized: FSEditList
Ignoring lint error: Method names should not be capitalized: FSSyncStatus
Ignoring lint error: Method names should not be capitalized: FSSyncEvent
Ignoring lint error: Method names should not be capitalized: GetCurrentMountDir
Ignoring lint error: Method names should not be capitalized: GetAllAvailableMountDirs
Ignoring lint error: Method names should not be capitalized: SetCurrentMountDir
Ignoring lint error: Record variable names should not be capitalized: KeyBundleResponse.WriterBundle
Ignoring lint error: Record variable names should not be capitalized: KeyBundleResponse.ReaderBundle
Ignoring lint error: Record variable names should not be capitalized: BadgeConversationInfo.UnreadMessages
Ignoring lint error: Method names should not be capitalized: FSActivity
Ignoring lint error: Method names should not be capitalized: FSSyncActivity
Ignoring lint error: Method names should not be capitalized: FSEditListResponse
Ignoring lint error: Method names should not be capitalized: FSSyncStatusResponse
Ignoring lint error: Method names should not be capitalized: FSEditListRequest
Ignoring lint error: Method names should not be capitalized: FSSyncStatusRequest
Ignoring lint error: Method names should not be capitalized: DisplayAndPromptSecret
Ignoring lint error: Method names should not be capitalized: DisplaySecretExchanged
Ignoring lint error: Method names should not be capitalized: PromptNewDeviceName
Ignoring lint error: Method names should not be capitalized: ProvisioneeSuccess
Ignoring lint error: Method names should not be capitalized: ProvisionerSuccess
Ignoring lint error: Method names should not be capitalized: CryptKeys
Ignoring lint error: Record variable names should not be capitalized: CryptKey.KeyGeneration
Ignoring lint error: Record variable names should not be capitalized: CryptKey.Key
Ignoring lint error: Record variable names should not be capitalized: GetTLFCryptKeysRes.CryptKeys
Ignoring lint error: Record variable names should not be capitalized: CanonicalTLFNameAndIDWithBreaks.CanonicalName
Ignoring lint error: DurationMsec: int64 cannot be fully represented as a Javascript number (double)

@maxtaco @strib @keybase/react-hackers @mmaxim @songgao

@gabriel / @songgao, holy shit, look at that commit ID ^ !!!!

The commits 46c73e86b64c...8ba13972bbea introduce visual changes on linux. :mag_right: 1 changed

Changed: Paper_Key-Normal (before) (after)


Bump travis ruby, SSL error

I keep getting this, but can't reproduce it in my container locally:
Ran on 81 files!
- ./_site/blog/2010/08/30/extracting-information-from-xml-with-csharp.html
  *  External link http://msdn.microsoft.com/en-us/library/system.xml.xmldocument.aspx failed: 301 SSL connect error
- ./_site/blog/2010/09/09/inking-in-silverlight.html
  *  External link https://msdn.microsoft.com/en-us/library/cc903958%28VS.95%29.aspx failed: response code 0 means something's wrong.
             It's possible libcurl couldn't connect to the server or perhaps the request timed out.
             Sometimes, making too many requests at once also breaks things.
             Either way, the return message (if any) from the server is: SSL connect error
- ./_site/blog/2010/09/27/specialized-csharp-operators.html
  *  External link https://msdn.microsoft.com/en-us/library/6a71f45d%28VS.71%29.aspx failed: response code 0 means something's wrong.
             It's possible libcurl couldn't connect to the server or perhaps the request timed out.
             Sometimes, making too many requests at once also breaks things.
             Either way, the return message (if any) from the server is: SSL connect error
  *  External link https://msdn.microsoft.com/en-us/library/d2bd4x66%28v=VS.71%29.aspx failed: response code 0 means something's wrong.
             It's possible libcurl couldn't connect to the server or perhaps the request timed out.
             Sometimes, making too many requests at once also breaks things.
             Either way, the return message (if any) from the server is: SSL connect error
- ./_site/blog/2010/09/30/follow-up-iis-services-504s-and-fiddler.html
  *  External link http://msdn.microsoft.com/en-us/library/system.diagnostics%28VS.71%29.aspx failed: 301 SSL connect error
  *  External link http://msdn.microsoft.com/en-us/library/system.diagnostics.trace.autoflush.aspx failed: 301 SSL connect error
- ./_site/blog/2010/10/13/how-to-create-a-visual-studio-2010-code-snippet.html
  *  External link https://msdn.microsoft.com/en-us/library/ms171442%28v=vs.110%29.aspx failed: response code 0 means something's wrong.
             It's possible libcurl couldn't connect to the server or perhaps the request timed out.
             Sometimes, making too many requests at once also breaks things.
             Either way, the return message (if any) from the server is: SSL connect error
- ./_site/blog/2010/11/08/csharp-classes-versus-structures.html
  *  External link https://msdn.microsoft.com/en-us/library/ms229017.aspx failed: response code 0 means something's wrong.
             It's possible libcurl couldn't connect to the server or perhaps the request timed out.
             Sometimes, making too many requests at once also breaks things.
             Either way, the return message (if any) from the server is: SSL connect error
htmlproofer 3.7.6 | Error:  HTML-Proofer found 8 failures!
make: *** [htmlproof] Error 1

Still unable to reproduce this, ran make travis with reported ruby of ruby 2.4.4p296 (2018-03-28 revision 63013) [x86_64-linux-musl]


fix(DagreGroupLayout): Keep node order when groups are collapsed

What
Closes #230
Description
On layout, add the nodes to the Dagre layout in the same order given to the graph. This maintains the ordering in the graph when groups are collapsed/expanded.
Type of change

[x ] Bugfix

/cc @lordrip

Preview: https://react-topology-pr-topology-231.surge.sh


Log socket protocol types when sweeping ghost connections

I don't think Monitor.debug is logged anywhere in PS...

Yeah, Main's loglevel is like 3

Not like the console's output is logged anywhere, either.


CocoaPods integration question

Description
Hello,
We use Firebase for a long time and at the moment we integrate Firebase products in a following way:
pod 'Firebase/Analytics'
pod 'Firebase/Crashlytics'
and etc...

As we see the current documentation shows Firebase installation with pod names without slash (/), like:
pod 'FirebaseAnalytics'
pod 'FirebaseCrashlytics'
and etc...

Could you please tell what is the difference and what should we use? We missed that moment when this names change has been made.
Thank you.
Reproducing the issue
No response
Firebase SDK Version
10.9
Xcode Version
14.3
Installation Method
CocoaPods
Firebase Product(s)
All
Targeted Platforms
iOS
Relevant Log Output
No response
If using Swift Package Manager, the project's Package.resolved

Expand Package.resolved snippet

Replace this line with the contents of your Package.resolved.

If using CocoaPods, the project's Podfile.lock

Expand Podfile.lock snippet

Replace this line with the contents of your Podfile.lock!

In CocoaPods, the / syntax denotes a subspec - so Firebase/Analytics means use the Analytics subspec in the Firebase pod.  It has been functionally very similar to the FirebaseAnalytics pod since the FirebaseAnalytics pod is a dependency of the Firebase/Analytics subspec. See https://github.com/firebase/firebase-ios-sdk/blob/master/Firebase.podspec for implementation details.
Using the Firebase pod historically provided additional capability for Objective C-only apps, including access to importing Firebase.h -  that is less relevant as the world is moving to Swift.
There are no immediate plans to discontinue the Firebase pod support, but the long-term supported path is to recommend choosing the requested Firebase pods directly.
I'll close, but feel free to continue the conversation here.

Hi @paulb777
Thank you very much for a great explanation! Appreciate it!
Could you please tell what about FirebaseCore? As I see Firebase/Analytics and other Firebase/ pods(subspecs) have and install Firebase Core dependency. When using this new FirebaseAnalytics, FirebaseFirestore etc approach, do we need to add this pod 'FirebaseCore' as a separator line to Podfile? Or is it no longer needed at all?
Thanks.

All of the other Firebase pods have an explicit dependency on FirebaseCore which tells CocoaPods to install it.
It's needed, but is optional to be specified in the Podfile.


"Revision.documentId cannot be null",

Having this issue with the sequelize 5.21.2 and latest stable  "sequelize-paper-trail": "^3.0.1",
tried few rc-6 and rc-8 versions with no luck

Same issue. any solutions

I had NO_AUTO_VALUE_ON_ZERO sql_mode set on my DB. After removing that, no more errors


Wurm's Molt Leech and Tree values Leech - weird behavior

https://pastebin.com/8Mpv9Vi7
Build is 100% cold conversion, so Wurm's Molt belt should not grant any mana or life leech, but removing belt drops the life leech rate shown in PoB.  Does the leech from the belt apply before elemental conversion?
Conversely, there does not appear to be any mana leech applied by the belt.  Only be enabling the Life and Mana Leech node in the passive tree can I see mana leech in PoB - the pop up on the calc's page for mana leech shows both sources (tree and belt), but removing belt doesn't affect it.

Leech always applies after conversion, so Physical Attack Damage Leech modifiers will never apply if there isn't any such damage being dealt.
Your Life Leech rate drops when unequipping the belt because the belt has Strength, which affects your Damage dealt, and therefore your Leech rate since you aren't at the Leech cap.

Ah yes, you are right, of course.  Sorry!
Thanks for the quick response.  Cheers, and great program :).


help understanding log file

Hi, I have a quick question about the log output. The end of my output looks something like this.
[0m[32m	Up to record 26700000...
[0m[32m	Up to record 26800000...
[0m[32m	Up to record 26900000...
[0m[32m	Up to record 27000000...
[0m[32mFinished restranding!

Does this mean that restrander has processed up to 27M reads of the input file? And this would mean the first 27M reads in the input file, correct? (i.e. in case the process gets killed abruptly, does the log mean that the first 27M reads of the input file have been processed?
Or does the output mean that up to 27000000 reads have been added to the output file? i.e. if the input  fastq file was bigger (say ~34M reads overall), and suppose the file has been fully processed, then can we interpret it as 27M reads have been filtered out of the 35M reads.
Thanks!
Sowmya

The Up to record x... message means that restrander has processed x reads (and printed them to the output). Since it processes the file linearly, those would be the first x reads in the input. The Finished restranding! message means that the program reached the end of the input file (the message won't appear if the process gets killed, only if there's no more reads).
If your input file had ~34M reads, I'm not sure how restrander could decide to finish before reaching the end of the input - something is likely going wrong. Can you check the health of the input file? Maybe some weird read is breaking restrander. How long is the longest read in your input? (reads >500K bases can cause issues)

Thanks for the clarification. The error was on my end. I forgot to uncompress my .fastq.gz input file before reading the number of lines in it. So, it does have only 27M reads.


Add LSTNet

Description of changes:
An implemetation of LSTNet.

[x] Initial implementations in gluonts/model/lstnet/
[x] Add unit tests
[x] Usage and verify some of the paper's results use the gist lstnet.py
[x] Cleanup and add docs

Note that I haven't replicated all of the paper's results as there is quite a big range of hyper-parameters that paper used for tuning and no final hyper-parameters were given!
TODO: Temporal Attention layer.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Codecov Report

Merging #596 into master will increase coverage by 0.17%.
The diff coverage is 99.13%.

@@            Coverage Diff             @@
##           master     #596      +/-   ##
==========================================
+ Coverage   83.72%   83.89%   +0.17%
==========================================
  Files         181      184       +3
  Lines       10326    10442     +116
==========================================
+ Hits         8645     8760     +115
- Misses       1681     1682       +1

Impacted Files
Coverage Δ

src/gluonts/model/lstnet/_estimator.py
100% <100%> (ø)

src/gluonts/model/lstnet/_network.py
100% <100%> (ø)

src/gluonts/model/lstnet/__init__.py
80% <80%> (ø)

Codecov Report

Merging #596 into master will increase coverage by 0.17%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #596      +/-   ##
==========================================
+ Coverage   83.72%   83.89%   +0.17%
==========================================
  Files         181      184       +3
  Lines       10326    10442     +116
==========================================
+ Hits         8645     8760     +115
- Misses       1681     1682       +1

Impacted Files
Coverage Δ

src/gluonts/model/lstnet/_estimator.py
100.00% <0.00%> (ø)

src/gluonts/model/lstnet/__init__.py
80.00% <0.00%> (ø)

src/gluonts/model/lstnet/_network.py
100.00% <0.00%> (ø)

Codecov Report

Merging #596 into master will increase coverage by 0.16%.
The diff coverage is 97.61%.

@@            Coverage Diff             @@
##           master     #596      +/-   ##
==========================================
+ Coverage   83.73%   83.89%   +0.16%
==========================================
  Files         181      184       +3
  Lines       10327    10453     +126
==========================================
+ Hits         8647     8770     +123
- Misses       1680     1683       +3

Impacted Files
Coverage Δ

src/gluonts/model/lstnet/_estimator.py
100% <100%> (ø)

src/gluonts/model/lstnet/__init__.py
80% <80%> (ø)

src/gluonts/model/lstnet/_network.py
97.59% <97.59%> (ø)

Codecov Report

Merging #596 into master will increase coverage by 0.17%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #596      +/-   ##
==========================================
+ Coverage   83.73%   83.91%   +0.17%
==========================================
  Files         180      183       +3
  Lines       10281    10412     +131
==========================================
+ Hits         8609     8737     +128
- Misses       1672     1675       +3

Impacted Files
Coverage Δ

src/gluonts/model/lstnet/_network.py
97.72% <0.00%> (ø)

src/gluonts/model/lstnet/__init__.py
80.00% <0.00%> (ø)

src/gluonts/model/lstnet/_estimator.py
100.00% <0.00%> (ø)

Codecov Report

Merging #596 into master will increase coverage by 0.18%.
The diff coverage is 97.7%.

@@            Coverage Diff             @@
##           master     #596      +/-   ##
==========================================
+ Coverage   83.72%   83.91%   +0.18%
==========================================
  Files         178      183       +5
  Lines       10279    10412     +133
==========================================
+ Hits         8606     8737     +131
- Misses       1673     1675       +2

Impacted Files
Coverage Δ

src/gluonts/model/lstnet/_estimator.py
100% <100%> (ø)

src/gluonts/model/lstnet/__init__.py
80% <80%> (ø)

src/gluonts/model/lstnet/_network.py
97.72% <97.72%> (ø)

...gemaker_sdk/entry_point_scripts/run_entry_point.py
43.75% <0%> (-3.31%)
:arrow_down:

src/gluonts/transform/sampler.py
91.8% <0%> (-2.75%)
:arrow_down:

...maker_sdk/entry_point_scripts/train_entry_point.py
25% <0%> (-1.54%)
:arrow_down:

src/gluonts/nursery/sagemaker_sdk/model.py
53.33% <0%> (-1.51%)
:arrow_down:

src/gluonts/model/forecast.py
71.92% <0%> (-0.61%)
:arrow_down:

src/gluonts/nursery/sagemaker_sdk/estimator.py
42.98% <0%> (-0.5%)
:arrow_down:

src/gluonts/distribution/bijection.py
81.35% <0%> (-0.47%)
:arrow_down:

... and 10 more

Codecov Report

Merging #596 into master will decrease coverage by 1.32%.
The diff coverage is n/a.

The diff coverage is 97.16%.

@@            Coverage Diff            @@
##           master    #596      +/-   ##
=========================================
+ Coverage   83.72%   83.9%   +0.18%
=========================================
  Files         178     181       +3
  Lines       10279   10420     +141
=========================================
+ Hits         8606    8743     +137
- Misses       1673    1677       +4

Impacted Files
Coverage Δ

src/gluonts/model/lstnet/_estimator.py
100% <100%> (ø)

src/gluonts/model/lstnet/__init__.py
80% <80%> (ø)

src/gluonts/model/lstnet/_network.py
96.9% <96.9%> (ø)

Codecov Report

Merging #596 into master will increase coverage by 0.18%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #596      +/-   ##
==========================================
+ Coverage   83.72%   83.90%   +0.18%
==========================================
  Files         178      181       +3
  Lines       10279    10420     +141
==========================================
+ Hits         8606     8743     +137
- Misses       1673     1677       +4

Impacted Files
Coverage Δ

src/gluonts/model/lstnet/__init__.py
80.00% <0.00%> (ø)

src/gluonts/model/lstnet/_network.py
96.90% <0.00%> (ø)

src/gluonts/model/lstnet/_estimator.py
100.00% <0.00%> (ø)

Codecov Report

Merging #596 into master will increase coverage by 0.17%.
The diff coverage is 97.16%.

@@            Coverage Diff             @@
##           master     #596      +/-   ##
==========================================
+ Coverage   83.94%   84.11%   +0.17%
==========================================
  Files         178      181       +3
  Lines       10337    10478     +141
==========================================
+ Hits         8677     8814     +137
- Misses       1660     1664       +4

Impacted Files
Coverage Δ

src/gluonts/model/lstnet/_estimator.py
100% <100%> (ø)

src/gluonts/model/lstnet/__init__.py
80% <80%> (ø)

src/gluonts/model/lstnet/_network.py
96.9% <96.9%> (ø)

Codecov Report

Merging #596 into master will increase coverage by 0.17%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #596      +/-   ##
==========================================
+ Coverage   83.94%   84.11%   +0.17%
==========================================
  Files         178      181       +3
  Lines       10337    10478     +141
==========================================
+ Hits         8677     8814     +137
- Misses       1660     1664       +4

Impacted Files
Coverage Δ

src/gluonts/model/lstnet/_network.py
96.90% <0.00%> (ø)

src/gluonts/model/lstnet/__init__.py
80.00% <0.00%> (ø)

src/gluonts/model/lstnet/_estimator.py
100.00% <0.00%> (ø)

@lostella thanks! all the comments have been addressed.

@lostella thanks for bringing up the difference! yes, I was thinking to add two modes basically, one with horizon (as introduced in the paper) predicting y_{t+h} only and the other with prediction_length to predict y_t, ..., y_{t+h} which is the repeated application of the first mode (plus some required changes) to make it consistent with the library API. I think it shouldn't incur many changes for this PR. Main thing is either ar_fc with 1 output or num_series outputs for horizon and prediction_length modes resp.

Codecov Report

Merging #596 into master will increase coverage by 0.19%.
The diff coverage is 96.87%.

@@            Coverage Diff             @@
##           master     #596      +/-   ##
==========================================
+ Coverage   83.94%   84.13%   +0.19%
==========================================
  Files         178      181       +3
  Lines       10337    10497     +160
==========================================
+ Hits         8677     8832     +155
- Misses       1660     1665       +5

Impacted Files
Coverage Δ

src/gluonts/model/lstnet/_estimator.py
100% <100%> (ø)

src/gluonts/model/lstnet/__init__.py
80% <80%> (ø)

src/gluonts/model/lstnet/_network.py
96.49% <96.49%> (ø)

Codecov Report

Merging #596 into master will increase coverage by 0.20%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #596      +/-   ##
==========================================
+ Coverage   84.63%   84.83%   +0.20%
==========================================
  Files         178      181       +3
  Lines       10401    10565     +164
==========================================
+ Hits         8803     8963     +160
- Misses       1598     1602       +4

Impacted Files
Coverage Δ

src/gluonts/model/lstnet/__init__.py
80.00% <0.00%> (ø)

src/gluonts/model/lstnet/_estimator.py
100.00% <0.00%> (ø)

src/gluonts/model/lstnet/_network.py
97.45% <0.00%> (ø)

Codecov Report

Merging #596 into master will increase coverage by 0.19%.
The diff coverage is 97.5%.

@@            Coverage Diff             @@
##           master     #596      +/-   ##
==========================================
+ Coverage   84.63%   84.83%   +0.19%
==========================================
  Files         178      181       +3
  Lines       10401    10561     +160
==========================================
+ Hits         8803     8959     +156
- Misses       1598     1602       +4

Impacted Files
Coverage Δ

src/gluonts/model/lstnet/_estimator.py
100% <100%> (ø)

src/gluonts/model/lstnet/__init__.py
80% <80%> (ø)

src/gluonts/model/lstnet/_network.py
97.36% <97.36%> (ø)

Codecov Report

Merging #596 into master will increase coverage by 0.19%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #596      +/-   ##
==========================================
+ Coverage   84.63%   84.83%   +0.19%
==========================================
  Files         178      181       +3
  Lines       10401    10561     +160
==========================================
+ Hits         8803     8959     +156
- Misses       1598     1602       +4

Impacted Files
Coverage Δ

src/gluonts/model/lstnet/__init__.py
80.00% <0.00%> (ø)

src/gluonts/model/lstnet/_estimator.py
100.00% <0.00%> (ø)

src/gluonts/model/lstnet/_network.py
97.36% <0.00%> (ø)

@lostella checkout some of the results for exchange_rate data here.


Attribute mclimit

Hello.
How can I use attribute mclimit for dot graph https://www.graphviz.org/docs/attrs/mclimit/ ?
Didn't find any references :(
Thank you!

Hello!
It seems I didn't expose this attribute as a property, but I'll do that when I find some time soon and will let you know. Thanks for reporting this!
For now, you can just do it this way:
graph.Attributes.Collection.SetCustom(DotAttributeKeys.McLimit, "1.0");
By the way, I'm very curious of an example how this setting impacts the output graph. Could you share your example graph with this attribute set so that I can see how the visualization differs with and without it? I haven't used it so far. Will be grateful.
Cheers!

I have one more question about TBbalance attribute https://www.graphviz.org/docs/attrs/TBbalance/ but I couldn't use this like mclimit, can you help with this point?

@Scandinav21, the attribute might have been added after I released the library, so it's not included in the consts yet. But since the consts are just strings, you can pass TBbalance to the metod directly:
graph.Attributes.Collection.SetCustom("TBbalance", "max");

@mariusz-schimke Thanks a lot and thank you for quick reply!
Cheers!

@Scandinav21, I just released a new version updated to the new attributes that appeared in Graphviz documentation since the last time I made a similar sync a longer while ago. Now you can access the attributes, that you referred to, by properties:

mclimit: graph.Layout.EdgeCrossingMinimizationScale = 1.0;
TBbalance: graph.Layout.FloatingNodeRank = DotRank.Max;


Numerics comparison generating wrong results

Hi, I was trying to run an operator test through the SHARK-Testsuite and I found that the test result generated through the test suite does not match the golden result. While the same test, when compiled through IREE, and executed manually gives the results matching the golden results. I think there's some issue with the way test results are generated. I'm sharing the test script and the steps to repro the issue.
Script to run the test:
# Copyright 2024 Advanced Micro Devices, Inc.
#
# Licensed under the Apache License v2.0 with LLVM Exceptions.
# See https://llvm.org/LICENSE.txt for license information.
# SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception

from ..helper_classes import AzureDownloadableModel, BuildAModel
from onnx.helper import make_tensor, make_tensor_value_info
from onnx import TensorProto
from e2e_testing.registry import register_test

import numpy
from onnx import TensorProto
import onnx
from onnx.helper import make_tensor_value_info

# data = [
#     [1, 2, 3, 4],
#     [5, 6, 7, 8],
# ]
# starts = [0, 1]
# ends = [-1, 1000]
# result = [
#     [2, 3, 4],
# ]

class INModel(BuildAModel):

    def construct_initializers(self):
        # Input 1
        # self.initializers = [ make_tensor("i1", TensorProto.INT64, [2, 4], [1, 2, 3, 4, 5, 6, 7, 8])] #data
        # self.initializers += [ make_tensor("i2", TensorProto.INT64, [2], [1, 0])] #starts
        # self.initializers += [ make_tensor("i3", TensorProto.INT64, [2], [2, 3])] #ends
        # self.initializers += [ make_tensor("i4", TensorProto.INT64, [2], [0, 1])] #axes
        # self.initializers += [ make_tensor("i5", TensorProto.INT64, [2], [1, 2])] #steps

        # Input 2
        self.initializers = [ make_tensor("i1", TensorProto.INT64, [2, 4], [1, 2, 3, 4, 5, 6, 7, 8])] #data
        self.initializers += [ make_tensor("i2", TensorProto.INT64, [2], [0, 1])] #starts
        self.initializers += [ make_tensor("i3", TensorProto.INT64, [2], [-1, 1000])] #ends
        self.initializers += [ make_tensor("i4", TensorProto.INT64, [2], [0, 1])] #axes
        self.initializers += [ make_tensor("i5", TensorProto.INT64, [2], [1, 1])] #steps

    def construct_nodes(self):
        app_node = self.get_app_node()
        app_node("Slice", ["i1", "i2", "i3", "i4", "i5"], ["o1"]) # Order of args: data, starts, ends, axes, steps

    def construct_i_o_value_info(self):
        arg1 =  make_tensor_value_info("arg1", TensorProto.INT64,[2, 4])
        o1 =  make_tensor_value_info("o1", TensorProto.INT64,[1, 3])
        self.input_vi = [arg1]
        self.output_vi = [o1]

register_test(INModel, "slice_test")

Add this script in the /SHARK-TestSuite/alt_e2eshark/onnx_tests/operators/ directory with a name let's say slice.py and then add from .slice import * in /SHARK-TestSuite/alt_e2eshark/onnx_tests/operators/model.py. Since the test is registered now, you can run the test using python ./run.py -t slice_test -v , now it will generate the numerics failed issue with the values present in /SHARK-TestSuite/alt_e2eshark/test-run/slice_test/inference_comparison.log.
If you run this test manually, using the torch onnx IR present in the test-run/slice_test directory, you will find out that the results generated are same as the golden results.
To compile and run this manually, run the following:
1.) iree-compile --iree-hal-target-backends=llvm-cpu test-run/gather_test/model.torch_onnx.mlir -o slice_test.vmfb
2.) iree-run-module --module=slice_test.vmfb --device=local-task --input=1xi64=4

As mentioned in the sync earlier, I think that the issue is because of the flag "iree-input-demote-i64-to-i32", which is turned on by default. Try running with iree compile args as -ica="" or with mode -m cl-onnx-iree and see if the issue persists.
We should figure out why the numerics are incorrect specifically when i64 inputs are used.

Yeah, I just checked that this gives correct numerics without --iree-input-demote-i64-to-i32.
We can remove this flag from the default.


Id 37 reset password openapi

Added open api annotations to the three controllers, and also copied the code from mailer to output a copy of the swagger UI as a CircleCI artifeact so we can view the API docs.

Updated docs can be viewed at https://output.circle-artifacts.com/output/job/80754e78-f2b0-4289-afc2-eba9c935eed1/artifacts/0/docs/api-docs.html#/default

Codecov Report
Base: 73.50% // Head: 73.50% // No change to project coverage :thumbsup:

Coverage data is based on head (739bfde) compared to base (b0a303b).
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff             @@
##             develop      #55   +/-   ##
==========================================
  Coverage      73.50%   73.50%
  Complexity       194      194
==========================================
  Files             33       33
  Lines            585      585
==========================================
  Hits             430      430
  Misses           155      155

Impacted Files
Coverage Δ

...c/Application/Actions/ChangePasswordUsingToken.php
100.00% <ø> (ø)

...c/Application/Actions/CreatePasswordResetToken.php
87.50% <ø> (ø)

src/Application/Actions/GetPasswordResetToken.php
100.00% <ø> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

@NoelLH Thanks. I've added docs for the 400 response. Just need to work out why the checkout step is failing now.

Updated docs: https://output.circle-artifacts.com/output/job/a45aeba8-68a5-4490-b761-cfbe0e8c2689/artifacts/0/docs/api-docs.html


Is it possible to add a custom form component value?[Question]

I want to add a custom property to the form component object that will be a database Id and then that custom property be sent back to my web service
For example, here is a shortened component object:
{
    "label": "What is your name?",
    "tooltip": "Full name",
    "spellcheck": true,
    "tableView": true,
    "calculateServer": false,
    "key": "whatIsYourName",
    "type": "textfield",
    "input": true,
    "placeholder": "",
    "databaseId": 12
}

Notice the databaseId field that I have manually added.
The setup I have is that I run angular-formio and when a user submits the form, I build a custom JSON object from the submission and then send that to my own web service via a HTTP call
Now... I need a better method of relating the questions passed from the HTTP call, to a database entity entry. I have been doing this so far via the label but that is not ideal
For this to work, I can update my web service to assign the databaseId but my question is whether it's possible for angular-formio rendered to parse that databaseId and then have access to that ID when running formio-utils.getComponent() and seeing the databaseId in the object that is returned from that
Any suggestions welcome!

After further investigation I have found that I can manually add custom fields to the formio JSON and that data stays against the form in form renderer
This is a very welcome surprise and completely solves what I am trying to achieve


PLT-108: Script for downloading Plutus script dump from S3

Based on comment https://github.com/input-output-hk/plutus/pull/4692/files#r896901361, separating the downloader out.
This downloads s3 objects with the given prefix and suffix to a local dir (skipping objects that exist locally), and unzips all bz2 files in the local dir.

Also can you add awscli and bunzip to the nix-shell in this PR, since you need them for the script?

I added them at first, but removed them because I can run nix-shell -p awscli2 bzip2 --run ... in CI, so no need to make every shell environment install it.

if you're in the normal nix-shell you should be able to do everything in the project without needing more stuff.

Sure, no objection.


Gazelle extension for TypeScript

Replaces https://github.com/aspect-build/rules_js/issues/20

I've been trying my hand at this, but it's fraught with speedbumps.

Gazelle requires extensions to be built in Go.  There was talk about a plugin to support other languages, but it seems to have stalled.
Since esbuild doesn't expose its parser and I can't seem to find any other parser in Go-space, I've been statically linking a Rust binary that uses swc.  Since swc has a library to grab dependencies, this part is surprisingly straightforward.
rules_go has issues with IDE support for cgo, so errors around the bindings on the Go side just have to be ignored.
The ecosystem does not have go-to rules for certain tasks like linting or formatting like other languages.  I've mostly had to resolve to some internal macros for those, but they are not portable.
Right now, I've got it far enough that it can spit out something like

load("@aspect_rules_js//npm:defs.bzl", "npm_package")
load("@aspect_rules_ts//ts:defs.bzl", "ts_config")
load("@npm_dependencies//:defs.bzl", "npm_link_all_packages")
load("//macros/eslint-test:eslint_test.bzl", "eslint_test")
load("//macros/transpile-typescript:transpile_typescript.bzl", "transpile_typescript")

npm_link_all_packages(name = "node_modules")

ts_config(
    name = "tsconfig",
    src = "tsconfig.json",
)

transpile_typescript(
    name = "typescript",
    srcs = ["source/render-package-json.ts"],
    package_json = "package.json",
    tsconfig = ":tsconfig",
    deps = [":node_modules/sort-keys"],
)

npm_package(
    name = "render-package-json",
    srcs = [":typescript"],
    visibility = ["//visibility:public"],
)

eslint_test(
    name = "eslint_test",
    srcs = ["source/render-package-json.ts"],
    eslintrc = ".eslintrc.cjs",
    package_json = "package.json",
    tsconfig = ":tsconfig",
    deps = [":node_modules/sort-keys"],
)

but it's hacky and nowhere near close enough for a PR.  If the trade-offs above are acceptable for now, is there a design document I can conform to while cleaning it up and submit a proof of concept?

Hi @wtgtybhertgeghgtwtg you made some good progress there!
I'm sorry we didn't update this issue sooner - right now we are planning to make the gazelle extension licensed differently from rules_ts so that we have some way to pay our engineers.
It does use esbuild's parser, with a little trick to get at the needed API.
We have that in a private repo, are you interested in collaborating on it despite that?

Most of the work I have has been with swc and linking side of things, so I doubt I'd be of much use if you've found an esbuild setup.  Thank you for the offer, however.

We are close to releasing this feature with the Aspect CLI. Closing this issue as we are developing it closed source in our monorepo.


Target Cake CoreCLR

So that Cake.Recipe can load all addins from Cake CoreCLR runner.

@RLittlesII I don't think that would be possible right now.
From what I gather, not every addin that Cake.Recipe uses supports .NET Core yet, and some of them (if I remember correctly), is somewhat of a core feature of the Recipe.

@AdmiringWorm It isn't possible right now.  I have been working on an initiative to port all the dependencies to netstandard1.6.  This issue is part of that project.  I am close now, I just need to kick the tires on a few addins to make sure the conversion didn't break anything.

@RLittlesII @AdmiringWorm if we go ahead with this, guidance would likely be to use Cake.Tool, rather than CoreCLR, but I think we should still try to be able to do this.

@gep13 Correct me if I am wrong.  The difference between CoreCLR and Cake.Tool is just the mechanism by which is packaged and delivered?  It's still technically the dotnet version of Cake not the .NET Framework version.  Correct?
So we are saying that we would only be able to access this through dotnet cake ?

@RLittlesII  Essentially yes, also Cake.CoreCLR is .NET Core 2, Cake.Tool is  NET Core 2.1 (soon also 3.0).
If it works with Cake.Tool then it should work with Cake and Cake.CoreCLR too.
But recommendation would be Cake.Tool.

Before we are going to be able to do this, we need to figure out how to fix this:
https://github.com/cake-contrib/Cake.Issues.Reporting.Generic/issues/3

@gep13
Before we are going to be able to do this, we need to figure out how to fix this:

or conditionally disable the reporting functionality (of course this means not loading Cake.Issues recipe as well).

Yes, that would be an option if we could conditionally load adding into the running process, but as it stands, that still isn’t possible.  We could try to do something “clever” by making the addin directive itself conditional, but I really don’t like that approach.  The contributor who was working on getting RazorLight working has at least responded, so it isn’t a complete dead end, so hopefully that addin will be updated soon.

Yeah, did some experiments with conditionally loading Cake.Issues.Recipe by trying to use pre-processor if/else statements that I assumed would have been available with Cake 0.35.0.
Unfortunately, this was not honored, and it would still load Cake.Issues.Recipe.

I believe I am right in saying that those if/else statements are outside of the pre-processor logic within Cake, but @patriksvensson @devlead @mholo65  might be able to confirm this.  So although a good idea, I don't think that is a route that we can go down 😢

If else statements are processed in Roslyn after preprocessor statements are processed. They work on a C# level.
Something you could utilize is environment variables which are expanded before directive is processed. So you could switch which version is loaded, even which addin is executed, etc.
https://github.com/cake-build/cake/blob/daa3c4f26a5d54cbb8c0b65301eca098d2703f01/tests/integration/Cake.Core/Scripting/LoadDirective.cake#L2

Yes, that's correct. Preprocessor logic is not aware of defines. See issue https://github.com/cake-build/cake/issues/1860

@devlead @mholo65 thank you both for the confirmation, this is what I thought.

@gep13
Before we are going to be able to do this, we need to figure out how to fix this:

or conditionally disable the reporting functionality (of course this means not loading Cake.Issues recipe as well).

If someone get conditional loading to work, we should not implement it here, but upstream in Cake.Issues.Recipe.
Beside having the option to toggle individual features, it would also make sense to only load build server integration if running under the specific build server or only loading issue providers which actually are an input file passed.
This is https://github.com/cake-contrib/Cake.Issues.Recipe/issues/17.

@pascalberger thats a fair point!

I am going to go ahead and close this issue out, as I believe we have got most of this figured out.  There might be some additional points that come up related to this, but the guts of the work has been completed, and tested and known to work.


Validation for struct nesting depth.

According to sectin 2.17 in SPIR-V Spec, the structure nesting depth may
not be larger than 255. This is interpreted as structures nested in
structures. The code does not look into arrays or follow pointers to see
if it reaches a structure downstream.

Rebased, squashed and pushed into master as 4fb79b54f28


Comments appear on the wrong lines

Whenever I call GHCreateThread on a particular line, comment appears in a different line.
It happens mostly after GHStartReview. If I add comment w/o starting a review, comments appear on the right positions.
I saw this thread https://github.com/ldelossa/gh.nvim/pull/66. It looks similar but I didn't get what was the solution for the issue.
How to reproduce:

git worktree add ../review_dir
cd ../review_dir
nvim
GHOpenPR. PR contains several commits.
GHStartReview
Go to any commit (the last one, for instance) and try to add a comment. GHCreateThread

Expected result:

Comment appears on the right position

Actual result:

Comment appears on a completely different line

Note: if I don't start review, comment most likely appears on the right position.
Env:
nvim v0.8.0
gh.nvim latest
macos latest
iterm2 latest

Adding some debug info.
Adding comment for the same code, same PR, same line (18th line) but after GHStartReview and w.o GHStartReview

Debug info for the case after GHStartReview

[info] [gh] cmd: "gh api graphql -F pull=\"PR_kwDOIkxU8c5LxKOy\" -F review=\"PRR_kwDOIkxU8c5PmQ9h\" -F body='Comment on 18th line after StartReview' -F path=\"pkg/checks/test.go\" -F pos=18 -F sha=\"2168d255022aba12890a9a96bd8a0a0e21554f9f\" -f query='mutation ($pull: ID!, $review: ID!, $body: String!, $path: String!, $pos: Int!, $sha: GitObjectID!) {\n  addPullRequestReviewComment(\n    input: {pullRequestId: $pull, pullRequestReviewId: $review, body: $body, path: $path, position: $pos, commitOID: $sha}\n  ) {\n    clientMutationId\n  }\n}\n'" out:
'{"data":{"addPullRequestReviewComment":{"clientMutationId":null}}}'

As the result comment appears on line 26 but should be on line 18th
 out:
{
  data = {
    repository = {
      pullRequest = {
        reviewThreads = {
          edges = { {
              node = {
                comments = {
                  edges = { {
                      node = {
                        author = {
...
                        },
                        body = "Comment on 18th line after StartReview",
                        commit = {
                          oid = "05c0258f3bf3e50b5a3bf19d240197bf6b216fdd",
                          parents = {
                            edges = { {
                                node = {
                                  id = "C_kwDOIkxU8doAKDdhNzExMjlmOTljY2VmZjYwODZmYzFkNmYwNzMwZjY4NDQ5YjJjNjM",
                                  oid = "7a71129f99cceff6086fc1d6f0730f68449b2c63"
                                }
                              } }
                          }
                        },
                        createdAt = "2023-03-10T18:46:40Z",
                        diffHunk = "...",
                        id = "PRRC_kwDOIkxU8c5DhHXQ",
                        originalCommit = {
                          oid = "2168d255022aba12890a9a96bd8a0a0e21554f9f",
                          parents = {
                            edges = { {
                                node = {
                                  id = "C_kwDOIkxU8doAKDE3ZjRlNDBhMzI0MTNhZDgzNzE1ZDU0ZWQ4MjUyZDI3NzdhNjA1NTg",
                                  oid = "17f4e40a32413ad83715d54ed8252d2777a60558"
                                }
                              } }
                          }
                        },
                        originalPosition = 18,
                        path = "pkg/checks/test.go",
                        position = 24,
                        publishedAt = vim.NIL,
                        pullRequestReview = {
                          id = "PRR_kwDOIkxU8c5PmQ9h"
                        },
                        reactions = {
                          edges = {}
                        },
                        replyTo = vim.NIL,
                        state = "PENDING",
                        updatedAt = "2023-03-10T18:46:40Z",
                        url = "...",
                        viewerCanDelete = true,
                        viewerCanMinimize = false,
                        viewerCanReact = true,
                        viewerCanUpdate = true,
                        viewerCannotUpdateReasons = {},
                        viewerDidAuthor = true
                      }
                    } }
                },
                diffSide = "RIGHT",
                id = "PRRT_kwDOIkxU8c4rLLvq",
                isOutdated = false,
                isResolved = false,
                line = 26,
                originalLine = 26,
                originalStartLine = vim.NIL,
                path = "pkg/checks/test.go",
                resolvedBy = vim.NIL,
                startDiffSide = vim.NIL,
                startLine = 26,
                viewerCanReply = true,
                viewerCanResolve = false,
                viewerCanUnresolve = false
              }
            } },
          pageInfo = {
            endCursor = "...",
            hasNextPage = false
          }
        }
      }
    }
  }
}

Debug info w/o GHStartReview

[info] [gh] cmd: "gh api --method POST -H \"Accept: application/vnd.github.v3+json\" /repos/{owner}/{repo}/pulls/21/comments -f commit_id=2168d255022aba12890a9a96bd8a0a0e21554f9f -f path=pkg/checks/test.go -f side=RIGHT -F position=10 -F line=18 -f body='Comment on 18th line w/o starting review'" out:
'{"url":"...","pull_request_review_id":1335466576,"id":1132775409,"node_id":"PRRC_kwDOIkxU8c5DhMfx","diff_hunk":"...","path":"pkg/checks/test.go","position":13,"original_position":12,"commit_id":"05c0258f3bf3e50b5a3bf19d240197bf6b216fdd","original_commit_id":"2168d255022aba12890a9a96bd8a0a0e21554f9f","user":{...},"body":"Comment on 18th line w/o starting review","created_at":"2023-03-10T19:06:10Z","updated_at":"2023-03-10T19:06:10Z","html_url":"...","pull_request_url":"...","author_association":"CONTRIBUTOR","_links":{...},"reactions":{"url":"...","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0},"start_line":null,"original_start_line":null,"start_side":null,"line":18,"original_line":18,"side":"RIGHT"}'

As the result comment appears on the right line - 18th line.
[info] [gh] cmd: gh api graphql -F owner={owner} -F name={repo} -F pull_number=21 -f query=query ($name: String!, $owner: String!, $pull_number: Int!) {
  repository(name: $name, owner: $owner) {
    pullRequest(number: $pull_number) {
      reviewThreads(first: 50) {
        pageInfo {
          endCursor
          hasNextPage
        }
        edges {
          node {
            id
            diffSide
            isOutdated
            isResolved
            line
            originalLine
            originalStartLine
            path
            startDiffSide
            startLine
            viewerCanReply
            viewerCanResolve
            viewerCanUnresolve
            resolvedBy {
              login
            }
            comments(first: 100) {
              edges {
                node {
                  id
                  author {
                    login
                    avatarUrl
                    resourcePath
                    url
                  }
                  body
                  createdAt
                  path
                  position
                  originalPosition
                  publishedAt
                  replyTo {
                    id
                  }
                  pullRequestReview {
                    id
                  }
                  commit {
                    oid
                    parents(first: 1) {
                      edges {
                        node {
                          id
                          oid
                        }
                      }
                    }
                  }
                  originalCommit {
                    oid
                    parents(first: 1) {
                      edges {
                        node {
                          id
                          oid
                        }
                      }
                    }
                  }
                  reactions(first:20) {
                    edges {
                      node {
                        content
                        id
                        user {
                          login
                        }
                      }
                    }
                  }
                  state
                  updatedAt
                  viewerCanDelete
                  viewerCanMinimize
                  viewerCanReact
                  viewerCanUpdate
                  viewerCannotUpdateReasons
                  viewerDidAuthor
                  url
                  diffHunk
                }
              }
            }
          }
        }
      }
    }
  }
}
 out:
{
  data = {
    repository = {
      pullRequest = {
        reviewThreads = {
          edges = { {
              node = {
                comments = {
                  edges = { {
                      node = {
                        author = {
                         ...
                        },
                        body = "Comment on 18th line w/o starting review",
                        commit = {
                          oid = "05c0258f3bf3e50b5a3bf19d240197bf6b216fdd",
                          parents = {
                            edges = { {
                                node = {
                                  id = "C_kwDOIkxU8doAKDdhNzExMjlmOTljY2VmZjYwODZmYzFkNmYwNzMwZjY4NDQ5YjJjNjM",
                                  oid = "7a71129f99cceff6086fc1d6f0730f68449b2c63"
                                }
                              } }
                          }
                        },
                        createdAt = "2023-03-10T19:06:10Z",
                        diffHunk = '...',
                        id = "PRRC_kwDOIkxU8c5DhMfx",
                        originalCommit = {
                          oid = "2168d255022aba12890a9a96bd8a0a0e21554f9f",
                          parents = {
                            edges = { {
                                node = {
                                  id = "C_kwDOIkxU8doAKDE3ZjRlNDBhMzI0MTNhZDgzNzE1ZDU0ZWQ4MjUyZDI3NzdhNjA1NTg",
                                  oid = "17f4e40a32413ad83715d54ed8252d2777a60558"
                                }
                              } }
                          }
                        },
                        originalPosition = 12,
                        path = "pkg/checks/test.go",
                        position = 13,
                        publishedAt = "2023-03-10T19:06:11Z",
                        pullRequestReview = {
                          id = "PRR_kwDOIkxU8c5PmZpQ"
                        },
                        reactions = {
                          edges = {}
                        },
                        replyTo = vim.NIL,
                        state = "SUBMITTED",
                        updatedAt = "2023-03-10T19:06:11Z",
                        url = "...",
                        viewerCanDelete = true,
                        viewerCanMinimize = true,
                        viewerCanReact = true,
                        viewerCanUpdate = true,
                        viewerCannotUpdateReasons = {},
                        viewerDidAuthor = true
                      }
                    } }
                },
                diffSide = "RIGHT",
                id = "PRRT_kwDOIkxU8c4rLPFg",
                isOutdated = false,
                isResolved = false,
                line = 18,
                originalLine = 18,
                originalStartLine = vim.NIL,
                path = "pkg/checks/test.go",
                resolvedBy = vim.NIL,
                startDiffSide = vim.NIL,
                startLine = 18,
                viewerCanReply = true,
                viewerCanResolve = true,
                viewerCanUnresolve = false
              }
            } },
          pageInfo = {
            endCursor = "Y3Vyc29yOnYyOpK0MjAyMy0wMy0xMFQxOTowNjoxMFrOKyzxYA==",
            hasNextPage = false
          }
        }
      }
    }
  }
}

Feel free to contact me if you need some live demo or troubleshooting session.