Decide on versioning scheme

Decide on the versioning scheme to use for ORT releases
Options:

https://calver.org/ -> YY.MM.MINOR.MICRO (Teradata version)
https://semver.org/

Whatever we pick we should test first whether it works with packing tools - Philippe switched ScanCode to Calver and he wanted YY.minor.micro but had to settle for YY.M.D due to what the Python packaging tools accept as a version number.

We've implemented SemVer by now, see https://github.com/oss-review-toolkit/ort/pull/7455.


[python-package] [docs] Expand class docs for Dataset

Fixes #6511
As discussed with James Lamb in https://github.com/microsoft/LightGBM/issues/6511#issuecomment-2235274432, a bit more documentation about the way the lgb.Dataset is actually constructed, with a particular representation of data, could be interesting for users.

I've also put "fixes #6511" in the description, so that will be automatically closed when we merge this. I believe this answers your final question there.

Thanks again @Plenitude-ai . I've pushed commits updating the formatting and adding the corresponding R changes. Please follow the instructions in https://github.com/microsoft/LightGBM/pull/6558#issuecomment-2237978344 (sorry, it's a Microsoft requirement), and one of the other maintainers here will review when they have time.

Thanks again @jameslamb for your guidance. I realize it's a (very) modest one, but this is my first contribution to an open-source project so it's a great pleasure !
Thanks for your different advices on good practices in this process, i'll definitely follow them in the future.
@microsoft-github-policy-service agree company="Qwant"

@Plenitude-ai wonderful to hear it, thanks for choosing LightGBM for your first contribution! We really appreciate the help, and hope you'll consider contributing more in the future.


SimpleSinglePointerSelector: connect pointer upon OnSourceDetected

Overview
Behaviour of SimpleSinglePointerSelector is now to set an activated pointing controller to be primary controller.
Changes

Addresses: #2066  .

I definitely like this change, and it's something that's been discussed in the past! The reason we hadn't implemented is was to match the behavior of the shell as closely as possible (it requires a button press before your controller gains control of the cursor). I do prefer this behavior though. Would it be possible to implement this with a boolean toggle? That way we offer both behaviors, depending on the dev's preference.

Ah, hence the mention of the getter. Sorry, slow on the uptake today; I'll push a tweak shortly.

@PJBowron, I will merge once the public getter/setters are added.
Thanks!

I think there may still be a potential issue here - maybe I'm overlooking something simple:

if we're to add a property and make SearchForCursorIfUnset private, then the property must take the existing name in order not to break existing code that accesses the field
changing the now-private field name means although we can add a '[FormerlySerializedAs]` attribute to avoid breaking existing scenes and prefabs, we will still change a once-familiar inspector setting into an unfamiliar one that performs the same role

Given the comment from @stephenhodegson that this class won't survive vNext, I wonder if we should just return to the original public access level?

we have successfully updated existing fields using the following pattern:
// Old code
public int FieldName;
// New code
private int fieldName;
public int FieldName { /* get / set logic */ }

Cool I'll implement that.
Just for curiosity, this doesn't break deserialization of existing unity files using the component?

It didn't appear to (I had some old code and prefabs that seemed to work fine)


Update pre-commit hooks

This PR is mostly mechanical, though the last commit was manually performed to address new ruff warnings regarding configuration options that have been moved to tool.ruff.lint, and four new ruff warnings in the code.

Run pre-commit autoupdate
Run pre-commit run -a
Address new ruff config and code warnings

Closing; looks like this change has been submitted twice already in other PRs.


Unable to send voluntary exit message for a full withdrawal post Shapella

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
I would like to stop validating, and according to The Ethereum Launchpad's section on exiting I need to send a voluntary exit message via my validator node. However, there is no command in the CLI, nor can I find anything in the docs, pertaining to voluntary exits.
Describe the solution you'd like
A clear and concise description of what you want to happen.
I would like 2 things to happen, though one of them is optional:

Add a sedge validator-exit command that offers a similar interface as a consensus client's exit command so I can exit my validtor
Documentation on how to do this at https://docs.sedge.nethermind.io/docs/intro.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
I've considered manually exec'ing into my validator node's docker container and entering in the appropriate command to voluntarily exit. But this is error prone because it relies on me copy & pasting CLI arguments from my docker-compose and .env config files. Plus I'm not confident enough with Docker to know if this is how I should do it or if this is actually bad, and I should do it some other way.
Additional context
Add any other context or screenshots about the feature request here.

I like the first solution you described. The feature may not be used very often, but it makes sedge complete.
The second solution is also nice. When the documentation is there I would also suggest to link it in official Launchpad docs, like eth-docker did:
https://launchpad.ethereum.org/en/withdrawals#how-to-exit

I'm reopening this issue because I agree this is something that will make Sedge complete. We should definitely look into it.


Make the keys in palette mappers case insensitive

The utilities depend on the autocomplete feature of code editors to pass in the correct keys for the target hues. This could cause unnecessary nonsensical errors
Working on it...

All functions that take built-in parameters are now case insensitive by default!!


Definition entity and extractor

Implement a new entity definition to store term and definition pairs predicted by NLP+ML backend system. The codes will be stored under entities/. Initial commits will be pushed in dykang/definition_extractor.

[x] initial skeleton following other entities
[ ] featurization for NLP pipeline using spacy and scispacy
[ ] load/inference term/definition prediction using pre-trained transformer models
[ ] additional features related to definitions: colorization, etc (need @andrewhead's help)
[ ] integration with @rayfok's term entity UI code (refer to #123 )
[ ] testing and formatting (black, mypy)

Need README instruction for those who like to contribute to making a new entity type.

Need a batching to process multiple sentences together for increasing speed. Also, the module needs to automatically download the pre-trained model from the server and load it if it doesn't exist.

Sweet! So excited to see this! Regarding this item:

additional features related to definitions: colorization, etc (need @andrewhead's help)

Is there anything that would help to chat through right now?

Please see #125 regarding the code review.


@orta => Reload root webviews

They are now reloaded when you make their tab active, they are the currently visible view controller (so maintain existing deep view hierarchy), and the previous request was unsuccessful or 1 hour has passed since the last load.
I wanted to touch the existing code as little as possible, as to not introduce any regressions, but the reload implementation in ARInternalMobileWebViewController and ARTopMenuInternalMobileWebViewController could most probably be shared.

Fails are all in ARArtworkViewControllerSpec - merging.


Parameter naming for Site

This is to discuss parameter names related to site and suggestions to change. I would like to have explicit and full names to be as clear as possible.
Reference points: I first thought it should be named like center_altitude, center_longitude, .. but it is not always the center of the layouts. I suggest therefore (comment if it is too long):

reference_point_altitude replaces altitude
reference_point_longitude replaces ref_long
reference_point_latitude replaces ref_lat
EPSG_code replaces EPSG

More CORSIKA related:

corsika_observation_level replaces corsika_obs_level (and OBSLEVEL)
corsika_sphere_radius does not change

Structure related:

telescope_axes_height replaces corsika_sphere_center (discussed earlier in the context of the workflows)

Atmosphere related:

atmospheric_transmission does not change (or do we need to add a _file? Don't think so)
atmospheric_profile does not change
magnetic_field is a string of two numbers (e.g. 20.552 -9.367), do we want to keep that?

array_triggers is part of the site parameters. Do we want to keep this? It feels a bit out of place.

Agree with everything you wrote. Two small comments:

magnetic_field is a string of two numbers (e.g. 20.552 -9.367), do we want to keep that?

I think it might be good to split actually. It might be useful to have easy "access" to the float values.

array_triggers is part of the site parameters. Do we want to keep this? It feels a bit out of place.

Honestly I am not sure where to put it. It is more of a "run" parameter because it depends on the exact layout simulated. I do think the "sites" collection is the most appropriate place for now, but in the future it might move to a different collection with other similar parameters.


Unclear which platforms are used to build docs

I got an issue on SNAFU that its docs are not built for *-apple-* unlike some other crates. This made the reporter think that the crate wasn't supported on certain platforms.
I don't actually know which platforms are used to build the docs, so it's difficult to know if my crate is failing to build for some reason on certain platforms. I also couldn't find how to view the build logs when there's not a complete total build failure. Through hunting through other issues, I see that there's a /builds route, which doesn't appear to be linked from anywhere. The build log only shows the output from a single platform, and doesn't specify which it is.
Related:

#343
#141

Hello and sorry for the long wait. The available platforms are unfortunately not currently documented, I've listed them below:

x86_64-unknown-linux-gnu
x86_64-apple-darwin
x86_64-pc-windows-msvc
i686-unknown-linux-gnu
i686-apple-darwin
i686-pc-windows-msvc

The output you're seeing is for the default target, x86_64-unknown-linux-gnu. I am actually not sure how to access build logs from other targets, I'd have to look into that.
I'll leave this open until we properly document all the on the /about page.


[setting menu] [profile] favorited column should be 'created column' under CREATED CONTENT tab

In Profile page,  favorited column should be 'created column' under CREATED CONTENT tab
Expected results
CREATED CONTENT tab should show created charts and dashboard information
Actual results
CREATED CONTENT tab have a column name 'favorited'
Screenshots

How to reproduce the bug

Go to profile page under setting
Click on 'CREATED CONTENT' tab
See error

Environment
(please complete the following information):

browser type and version: Chrome
superset version: superset 1.3 RC2

Checklist
Make sure to follow these steps before submitting your issue - thank you!

[ ] I have checked the superset logs for python stacktraces and included it here as text if there are any.
[x] I have reproduced the issue with at least the latest released version of superset.
[x] I have checked the issue tracker for the same issue and I haven't found one similar.

Additional context
Add any other context about the problem here.

Closing this since it's stale, and we're probably not likely to invest in the current version of this page. We'll be (eventually) moving this into the React Single Page App (SPA) rather than the server generated page. If you want to fix the bug on the current page, we'll happily review a PR. If you want to contribute to the SPA effort, please hit us up on Superset Slack in the #improving-superset channel


Embed Youtube videos

It looks good now and responds to resize. Looks good on iPhone too. I wonder if there should be an option to show/hide the video, either for just the current card, or for all cards.


[Pagination] Migrate the demos to TypeScript

[x] I have followed (at least) the PR section of the contributing guide.

@ankitasingh170190 If you could migrate them all, it would be awesome 🔥. If you don't have the time, it's fine.

@ankitasingh170190 If you could migrate them all, it would be awesome 🔥. If you don't have the time, it's fine.

I would do them all but not today probably. But would get done after weekend for sure. Thank you so much.

Cool, take your time

Cool, take your time

Thanks. Added the typescript demo for Pagination, but I added wrong commit messages. Hope that is alright. Thank you.

Well done, thanks


Ajv validator test in jest

I am trying to test my Ajv schema validator using jest. Let my schema be userSchema, I then have
const UserSchema = ajv.compile(userSchema)

In the application this works fine, if it is passed an invalid schema then UserSchema will throw a ValidationError. This is as expected since I have some validation keywords which are async in userSchema. Now, I want to create a test that checks that valid and invalid data are validated appropriately. I expect to have the data available if the validation succeeds, so to test valid data I use
test('check valid data', async () => {
  expect(await UserSchema(user)).toBeTruthy();
})

and this works. However, for testing invalid data I keep running into issues. I am using
test('check invalid data', async () => {
  expect(async () => {await UserSchema(user);}).toThrow(ValidationError);
})

but this does not work. When I run the test, it gives Received function did not throw and Test suite failed to run as two separate errors. The second is a result of validation failed which comes from running await UserSchema(user) - coincidentally this is the message given when a ValidationError is thrown and also can be seen when testing manually.
I don't understand why this test does not run as it should. The compiled schema definitely throws a ValidationError I have tested this manually in my API by including a console.log(error instanceof ValidationError) as the first statement in the catch block after calling UserSchema. As expected, when testing manually and passing invalid data this logs true.

This was my mistake. I need to use resolves and rejects as noted in the documentation https://jestjs.io/docs/tutorial-async


Add UNEG

University official website: https://www.uneg.edu.ve/
Informatics Engineering Career program: https://uneg.edu.ve/portal/pregrado/carreras/ingenieria-en-informatica (4.5 years)

@philipto hi there. Why did this get closed? Was there something wrong with the info provided?


Skip command does not work correctly

This problem is reproducible only on my server (Ubuntu), on my local machine (Windows 11) everything works fine. I do not know what the problem is...

No after rebooting server,  everything works fine. But for how long? I have an idea that this could be the cause of this problem. #13

idk…..

в коде насрано потому что

в коде насрано потому что


Spring-cloud-contract tests aren't considered in jacoco sonarqube reports.

Dear all,
I'm coming here to find your help, since we're turning around for many days.
Our project si contract first, and we're using gradle. We've two repos :

repo-contract
repo-service

The service is a spring-boot rest service.
In the repo-contract we have ;

Yaml contract
groovy contracts
BaseStubsClassTests.

gradle clean compile is working perfectly.
In the repo-service, we're importing the repo-contract, and making tests with a BaseClassTest and building classes with openapigen.
Tests are correctly generated, and when doing a gradle clean build, contract tests are runs correctly. BUT ! Since there is an issue, the generated tests arn't included in the jacaco reports (I can't out jacoco, it's a company mandatories) and sonarqube.
We tried to include the BaseClassTest package  in jacoco/sonarqube gradle config, and the generated test class package, without any change ...
Our service include :
src/main:

mycompany/myservice/controller/controller.class

src/test:

mycompany/myservice/cloudcontracttests/baseTests.class

Thank you for your return.
Cyril G.

On a Gradle repo I've tested this with, I've got the JaCoCo plugin applied, and have:
plugins {
  id 'java'
  id 'jacoco'
}

jacocoTestReport {
  reports {
    xml.enabled true
  }
}
test.finalizedBy jacocoTestReport

And then running a ./gradlew clean contractTest shows there's a JaCoCo exec file generated:
-rw-r--r--  1 jamie jamie 303711 Jan  6 16:11 contractTest.exec

So I guess we can close this


Dagsterize MCOE output tables

PR Overview
Integrate the MCOE outputs into the PUDL DB at both monthly and yearly frequencies.
PR Checklist

[x] Merge the most recent version of the branch you are merging into (probably dev).
[x] All CI checks are passing. Run tests locally to debug failures
[x] Make sure you've included good docstrings.
[x] For major data coverage & analysis changes, run data validation tests
[ ] Include unit tests for new functions and classes.
[ ] Defensive data quality/sanity checks in analyses & data processing functions.
[x] Update the release notes and reference reference the PR and related issues.
[ ] Do your own explanatory review of the PR to help the reviewer understand what's going on and identify issues preemptively.

Picking up this PR, I think this is what needs to be done (in this order):

[ ] Move all_gens and gens_cols functionality that's necessary for creating the mega gens and PPE downstream into the PPE infrastructure (subtasks are notes from Zane, still relevant?)

[ ] Create a generators datamart table, using the last bits of the MCOE function.
[ ] Redirect PPE / MegaGens to point at the generators datamart table

[ ] Run integration/validation tests on MCOE outputs
[ ] Run through comments in #2438 one more time and make sure everything is addressed in terms of which tables should live in the DB and keeping the MCOE table skinny.
[ ] merge into dagsterize-net-gen-alloc and then address the comments on #2527

If you're planning to tackle the cleanup issues in the gen-fuel dagsterization PR, I think that could be done first (I don't think there's anything in the MCOE PR that needs to happen before the gen-fuel PR is ready to go) and that would bring in new assets more incrementally.
I'm not sure where you saw the reference to the gens datamart table, but I think it's a very wide table of information that @cmgosnell wanted in the context of the PPE / GensMega outputs? Maybe she remembers more specifics.  I think it was a bunch of information that was getting merged into the MCOE outputs, but which I thought was really beyond the scope of those outputs -- but that it needed to be created for other reasons as its own separate thing.

@zaneselvans @cmgosnell  I left some questions and notes in my to do list in this comment but consolidating the lingering questions below:

In the wide MCOE table (mcoe_generators), by default, should only DEFAULT_GENS_COLS be included (the previous default for the MCOE table), or should all generator columns be included since it's a data mart table?
Filtering for valid heat rate, capacity factor, and fuel price is now done at the end of pudl.analysis.mcoe.mcoe(). Would one ever need the MCOE table unfiltered for valid CF, HR, and FP or is it fine to leave this filtering in the analysis function?
Currently the heat rate, capacity factor, and fuel price intermediary tables are loaded into the DB. Wasn't sure where to land on this.
Take out xfail for MCOE in the integration test test_eia_outputs? I think the time coverage issues were addressed in this PR but maybe that message refers to something else?
Merge this branch into dagsterize-net-gen-alloc or merge dagsterize-net-gen-alloc first?

Subbing in the fuel allocations to get new heat rate per generator estimations looks pretty good. Coverage increases and the distribution looks a little better.
Coverage change over report dates with raw heat rates and heat rates filtered from 5.5 to 25 mmbtu/mwh (15% efficiency):

Change in distribution by type of generator:

Would you make all those histograms with at least 100 bins?

@zaneselvans
Heat rate distribution

Fuel cost weighted by the heat content of fuel consumed

Fuel cost per MMBTU

Since fuel consumption doesn't get allocated to the generator level, I merged on fuel consumption at the plant + fuel type level, filtered out null fuel costs, and dropped duplicates to get the fuel consumption for plants with non-null fuel costs. Then summed by report date and divided by the total fuel consumption. Is this along the lines of what you were thinking?
def get_fuel_consumption_coverage(df, frc):
    df = df[df.fuel_cost_per_mmbtu.notnull()]
    df = df.drop_duplicates(subset=["report_date", "plant_id_eia", "fuel_type_code_pudl"], keep="first")
    return (
        df.groupby("report_date")["fuel_consumed_mmbtu"].sum()
        / frc.groupby("report_date")["fuel_consumed_mmbtu"].sum()
    )

fc_cov = get_fuel_consumption_coverage(df=fuel_cost, frc=frc)
fc_alloc_cov = get_fuel_consumption_coverage(df=fuel_cost_alloc, frc=frc)

plt.plot(fc_alloc_cov, label="fuel allocations")
plt.plot(fc_cov, label="old estimation")
plt.title("Fuel consumption coverage")
plt.ylabel("Fraction of fuel consumed covered by fuel costs")
plt.legend()

@katie-lamb Are the heat rate histograms weighted by MMBTU consumed?

On the coverage I was thinking of the heat rate coverage graphs you made -- heat rate coverage raw & heat rate coverage filtered. Like of all the fuel consumed, what fraction of it do we have associated with a heat rate?
Or is the main reason that we have missing heat rates that we having missing fuel consumption?

It's interesting that the fuel cost coverage is trending down over time. Can you separate it out by fuel?  Is it trending down overall because the proportion of fuel that's gas is trending up, and they redact more of the gas prices?

Or is the main reason that we have missing heat rates that we having missing fuel consumption?
Yep, the main reason for missing heat rates I think is missing fuel consumption - does it make sense that pretty much 100% of fuel consumption is covered with unfiltered heat rates?

def get_coverage_of_fuel_consumed(df, filtered=False):
    if filtered:
        hr_col = "heat_rate_mmbtu_mwh_filtered"
    else:
        hr_col = "heat_rate_mmbtu_mwh"
    return (
        df[["report_date"] + ["heat_rate_mmbtu_mwh", "heat_rate_mmbtu_mwh_filtered", "fuel_consumed_fraction"]]
        .groupby("report_date")
        .apply(lambda x: x.dropna(subset=hr_col).sum(numeric_only=True))
    )
fig, axs = plt.subplots(1, 2, sharey=True, sharex=True, figsize=(10, 6), tight_layout=True)

hr_by_gen_cov = get_coverage_of_fuel_consumed(hr_by_gen)
hr_by_gen_alloc_cov = get_coverage_of_fuel_consumed(hr_by_gen_alloc)

axs[0].plot(hr_by_gen_cov["fuel_consumed_fraction"], label="old estimation")
axs[0].plot(hr_by_gen_alloc_cov["fuel_consumed_fraction"], label="fuel allocations", alpha=.5)
axs[0].set_title("Heat rate coverage raw")
axs[0].set_ylabel("Fraction of fuel consumption covered")
axs[0].legend()

hr_by_gen_cov_filtered = get_coverage_of_fuel_consumed(hr_by_gen, filtered=True)
hr_by_gen_alloc_cov_filtered = get_coverage_of_fuel_consumed(hr_by_gen_alloc, filtered=True)
axs[1].plot(hr_by_gen_cov_filtered["fuel_consumed_fraction"], label="old estimation")
axs[1].plot(hr_by_gen_alloc_cov_filtered["fuel_consumed_fraction"], label="fuel allocations", alpha=.5)
axs[1].set_title("Heat rate coverage filtered")
axs[1].set_ylabel("Fraction of fuel consumption covered")
axs[1].legend()

Are the heat rate histograms weighted by MMBTU consumed? I think we're probably only interested in seeing the weighted histograms -- otherwise we're counting records, which means lots of tiny records will overwhelm a few big ones.
Is this what you were thinking?

fig, axs = plt.subplots(2, 2, figsize=(10, 10), tight_layout=True)
codes = iter(thermal_ftcp)
for row in range(2):
    for col in range(2):
        ax = axs[row][col]
        code = next(codes)
        alloc_df = hr_by_gen_alloc.loc[
            hr_by_gen_alloc.fuel_type_code_pudl == code,
            ["heat_rate_mmbtu_mwh", "fuel_consumed_for_electricity_mmbtu"]
        ]
        old_df = hr_by_gen.loc[
            hr_by_gen.fuel_type_code_pudl == code,
            ["heat_rate_mmbtu_mwh", "fuel_consumed_for_electricity_mmbtu"]
        ]
        ax.hist(
            alloc_df["heat_rate_mmbtu_mwh"],
            range=(0, 50),
            bins=150,
            label="fuel allocations",
            weights=alloc_df["fuel_consumed_for_electricity_mmbtu"],
        )
        ax.hist(
            old_df["heat_rate_mmbtu_mwh"],
            range=(0, 50),
            bins=150,
            label="old estimation",
            weights=old_df["fuel_consumed_for_electricity_mmbtu"],
            alpha=0.5,
        )
        ax.set_title(f"{code}")
        ax.set_xlabel("heat_rate_mmbtu_mwh")

It's interesting that the fuel cost coverage is trending down over time. Can you separate it out by fuel? Is it trending down overall because the proportion of fuel that's gas is trending up, and they redact more of the gas prices?

Yes, the heat content weighted histograms are more what I was thinking, but they need to be normalized so we can compare the distributions since the total quantity of fuel reported in the two cases are so different. We particularly care about the coal and gas since they're the overwhelming bulk of the energy / emissions, so it would be nice to see them from like 0-20 mmbtu/MWh.
It looks like there are some weird gaps showing up in the old MCOE distributes for coal and gas and waste.
Generally the new coal heat-rate distribution looks right, but I am suspicious of the new gas heat rate distribution.
It's got 2 peaks at about the right places for combined cycle (~7) and open-cycle gas turbines (~11) but way more heat content in the high peak, which is probably wrong. IIRC a large majority of gas consumed goes to the much higher efficiency CC plants, and the GTs are used infrequently as peakers.
My guess is that the distribution looks like this because the data is bad in earlier years, maybe with only the gas turbine portion of the CC unit reporting generation, and getting ~100% of the fuel consumption attributed to them, which would result in a heat rate that looks like a gas turbine.  If you plot the same histogram for every year of data, I think you'll find that some time around 2015 the distribution shifts radically -- at the point when EIA started collecting generation data for both the gas turbines and the heat recovering steam generators. In the data validations, we only look at gas heat rates for 2015+.
The little lump in the gas heat rate distribution that's close to zero might be associated with the HRSGs, which consume little or no fuel directly, but still generate electricity.  If so, then if you weight by MWh generated rather than fuel heat content consumed, I would expect that lump to get much bigger (i.e. how many MWh were generated at a given heat rate, rather than how much fuel was consumed at a given heat rate).
I wouldn't have guessed that coal fuel price coverage would be dropping over time and gas coverage has been rising! It's also interesting that there's a big drop in coal coverage at about the same time as there's a big jump in gas coverage in like 2014-2015 in the older estimates.

As theorized above, around 2014 is the shift in distribution, when combined cycle plants are reported correctly. Unfortunately, the high peak remains too large.

Well, the new plots are informative at least!
I think my next step would probably be to try and break down the new allocated gen-fuel data somehow, into different allocation cases, and see if some of them get the right answer, and others get the wrong answer, so we can understand which part of the allocation processes might be the source of the problem -- looking just at the 2015+ years where we expect to be able to get a good result based on the available data.
Questions

@cmgosnell do you have any intuition as to what the relevant difference might be between the old and new processes?
Are the heat rates implied by the gen-fuel allocations aware of the generation unit ID level aggregations required to get meaningful heat rates in the case of multi-generator units (like all the combined cycle units)?
Does this affect how we feel about publishing the allocated gen-fuel data? Are there additional caveats that we want to add?
What do we want to do as far as the MCOE outputs go? Try and figure out what the issue is and fix it in pursuit of new and better MCOE estimates / coverage? Or just keep using the older lower coverage outputs?
Is it possible / would it be informative to merge in Prime Mover information in association with the generator IDs in the gen-fuel allocated data, and look just at the heat rate distribution for the combined cycle vs. open cycle prime movers? (CC+CT vs. GT+ST)

@zaneselvans @cmgosnell I couldn't figure out how to best aggregate the gen-fuel allocated generator level heat rates up to the unit level (the old estimations use hr by unit as an intermediary step to get to hr by gen). So breaking it down by prime mover instead:

Are the heat rates implied by the gen-fuel allocations aware of the generation unit ID level aggregations required to get meaningful heat rates in the case of multi-generator units (like all the combined cycle units)?

The gen-fuel allocations result in CA generators being allocated very little fuel while the CT generator gets all the fuel for the combined cycle unit, which makes sense at a generator level but makes for incorrect heat rates when considering the unit as a whole. In the old estimations, every generator in the unit is given the same heat rate as the entire unit (so ~7 for the CA and CT gen in CC units).
The open cycle ST generators look okay. Note that there were only a handful of GT generators with valid net generation and heat rates, so I didn't include that distribution.

Does this affect how we feel about publishing the allocated gen-fuel data? Are there additional caveats that we want to add?

I feel as if the fuel allocation is theoretically correct right now, but the docs should probably say that the steam turbine part of CC units aren't allocated fuel. Or maybe I'm wrong in thinking that's what's intuitive.

What do we want to do as far as the MCOE outputs go? Try and figure out what the issue is and fix it in pursuit of new and better MCOE estimates / coverage? Or just keep using the older lower coverage outputs?

I think if it's easy to re-allocate the combined cycle fuel allocations (maybe in the MCOE analysis itself and keeping the fuel allocations as is) so that the heat rate by unit makes more sense then it's worth fixing so that we can boost the coverage of the MCOE table. This would be helpful for me in the FERC to EIA match context. That being said, I'm not sure how difficult this will be and don't feel that familiar with how this process might go down.

The heat rates are only really meaningful at the generation unit level, since that's the aggregation of infrastructure that bundles together fuel inputs and their corresponding electricity outputs.  The combined cycle units are the main place that this makes a mess of things.
If we merge in unit_id_pudl from boiler_generator_assn_eia860 (the unit IDs should probably be in all of the denormalized generator tables and maybe built into the gen-fuel tables for just this purpose) we should be able to calculate the overall heat-rate by unit, and see if it looks reasonable at all:
gen_fuel = pd.read_sql("generation_fuel_by_generator_energy_source_monthly_eia923", pudl_engine)
bga = pd.read_sql("boiler_generator_assn_eia860", pudl_engine)

gen_fuel_by_unit = pudl.helpers.date_merge(
    left=gen_fuel,
    right=bga[["report_date", "plant_id_eia", "generator_id", "unit_id_pudl"]],
    on=["plant_id_eia", "generator_id"],
    how="left",
)

heat_rate_by_unit = (
    gen_fuel_by_unit.dropna(subset="unit_id_pudl")
    .groupby(["report_date", "plant_id_eia", "unit_id_pudl"], as_index=False)[
        ["net_generation_mwh", "fuel_consumed_for_electricity_mmbtu"]
    ].sum()
    .convert_dtypes()
    .assign(hr_by_unit=lambda x: x.fuel_consumed_for_electricity_mmbtu / x.net_generation_mwh)
)

hr_recent = heat_rate_by_unit[heat_rate_by_unit.report_date >= "2015-01-01"]
plt.hist(hr_recent.hr_by_unit, weights=hr_recent.fuel_consumed_for_electricity_mmbtu, range=(1,20), bins=100)
plt.xlabel("Heat Rate [MMBTU/MWh]")
plt.ylabel("Total Heat Content [MMBTU]")
plt.title("Generation Unit Heat Rates Weighted by MMBTU Consumed.");

This distribution looks really good!
Unfortunately, it has also aggregated away all of the information about the prime movers involved and the primary fuel being consumed, but it suggests that -- at least for for the generators where we've inferred unit_id_pudl -- the distribution of heat rates that are implied by the new fuel allocation is very good.
I think this table of generation unit level heat rates (the only level that makes physical sense) can be merged back onto the allocated generation-fuel table, as we did in the old MCOE process, to end up with a heat rate that's associated with all the more specific generator-level information like prime mover and the energy source code, so that we can look at the heat rate distributions associated with coal fired steam turbines, gas fired combined cycle units, or stand-alone gas turbines, and we have a good idea of what each of those curves should look like.
I don't know how much better the overall coverage will be -- but you could look at the proportion of allocated fuel consumed that ends up in the aggregated unit_id_pudl level dataframe above and comapre it to the existing MCOE outputs, which would give us some idea.
There's also a much more involved (and unvalidated) set of heuristics for assigning unit_id_pudl values to many more boilers and generators laying around, which would improve the overall coverage.

Using the allocated generation-fuel table should improve coverage because it includes data from boilers and generators that only appear in the original generation_fuel_eia923 table.
Increasing the number of boilers & generators that have unit_id_pudl values will increase overall coverage since we'll be able to associate more boilers and generators into generation units, which is necessary for calculating real heat rates.
Increasing the number of fuel delivery records that have (estimated) fuel prices associated with them will then allow us to use these heat rates to estimate the fuel cost per MWh for more units.

I used @zaneselvans unit_id_pudl aggregated heat rates from above and then merged them onto the allocated generation fuel table (generation_fuel_by_generator_monthly_eia923). The distribution of heat rates by prime mover now looks pretty good (weighting by fuel consumed) when looking at the 2015 and later data:

However, as expected, we get barely any increase in coverage. Here's the fraction of generation covered by the unit_id_pudl aggregated heat rates compared to the old process:

So where does this leave us?

We could plug in the fuel allocations aggregated to the unit_id_pudl level into the MCOE process
We could leave the MCOE process as is
Make an issue to try to improve the coverage by assigning more unit_id_pudl to boilers and generators. Are there any other ideas for improving coverage?

hey @katie-lamb ! I'm vv glad the unit aggregations look reasonable!
I certainly agree that heat rates in particular are only informative at the unit level. We do have an open issue about the unit id expansion #2535. @zaneselvans  did a ton of work a while ago to try to get complete unit coverage that a) was never tested in an ongoing way or deeply validated and b) is no longer working bc we've changed some of the expectations of the inputs.
In terms of moving forward I could see a few modes:

Use what we've got way: We could incorporate the allocated fuel consumption into the mcoe tables & only calculate heat rates for records when we have a unit_id_pudl. If we wanted to enable the ability to turn the allocation on or off i think we'd need to make a new asset or table which is the fuel consumption at the unit level: which could be either made from the boiler_fuel_eia923 table or the allocated generator level fuel table.
Longer/complete way: make the unit_id_pud expansion work with current data. Validate the new unit ids somehow/someway. Then do everything above.

Updating/integrating the more-complete unit_id_pudl would be helpful for other things! The subplant_id uses unit_id_pudl.
But/and i don't think theses two ways forward are conflicting at all. I assume there would still be unique instances of null unit_id_pudl no matter what. To me, the main risk of integrating what we currently have is that users could easily calculate heat rates for everything that would be... wrong/unhelpful. If we do this we should at a minimum add a little warning into the user-facing docs.

In the interest of dagsterizing the PPL so that the FERC to EIA modeling effort can be continued, I think we should do the "use what we've got" route while perhaps working in parallel on the "longer more complete" route of filling in unit_id_pudl.

If we wanted to enable the ability to turn the allocation on or off i think we'd need to make a new asset or table which is the fuel consumption at the unit level: which could be either made from the boiler_fuel_eia923 table or the allocated generator level fuel table. This would give us barely more heat rates, but we'd get the complete coverage of fuel consumption!

@cmgosnell I feel a little confused about the need for this additional table of fuel consumption at the unit level. What contexts would we want the ability to turn the allocation off? Is it useful/necessary to be able to go back to the old estimates? Is this unit level fuel consumption just necessary so that, as you say, users can't calculate heat rates that are wrong/bad, or is that a separate issue?

I compared the old MCOE to the new MCOE with fuel allocations aggregated at the unit level. Breaking total_mmbtu per generator out by fuel type and report year, the comparison is looking pretty good. Seems like it makes sense to proceed with both generation and fuel allocations.

I'm not sure if these plots are in response to my request on the call, but I was wanting to compare the heat rate distributions by fuel and year, since we know what they should look like and also that we think they should be about the same in the old and new versions of the data.
The features I would be looking for to know that things are still working as expected (and that I think are present in the old data):

In gas (weighted by heat content) we should see a big peak around 7 mmbtu/MWh (CCGT) and a small peak around 10-11 mmbtu/MWh (standalone gas turbines, which don't generate much).
The relative size of the CCGT peak should increase over time, as combined cycle plants become more prevalent, both compared to the open cycle gas turbines, and compared to coal fired generation.
We should see a coal peak around 10-11 mmbtu/MWh (typical steam turbine heat rate)
The coal peak should shrink over time relative to the gas peak as generation shifts from coal to gas.

@zaneselvans my understanding on the call was that you wanted to see fuel consumption in the final MCOE tables broken out by fuel and time. Here's heat rate broken out by fuel and time weighted by total MMBTU

I can't really tell what's going on with 4 different types of very skinny bars in those histograms.

@zaneselvans what would you prefer?

Separating them out into coal and gas series separately helps a lot!
The only big change that I'm curious about is the 2014 gas, which with the newly allocated fuel looks much more like the subsequent years with a big peak in the CC heat rate range around 7.5 MMBTU/MWh. This is an improvement, but do we understand what happened to change it? Does 2013 look like 2012 or 2014?

@zaneselvans hopefully there's an actual explanation for the 2014 vs 2015 data reporting difference, not just an off by one.

OK, took a look at this again since Katie raised a flag about “this is taking a long time."
My proposal for next steps is:

[ ] @zaneselvans / @katie-lamb / me pair on beefing up the validation tests to assert things about the actual shape of the data: "there should be peaks in the gas heat rate at ~7 and ~10" etc.
[ ] We get the validation tests passing and merge with as little effort as possible - likely using allocated generation, but not allocated fuel
[ ] We make a new ticket for using cool new data in MCOE, which can be worked on separately from Plant Parts.

notes/context/thought process, so you can see all the things I forgot to consider
Sounds like we have a couple intertwined things to consider:

what is the overall goal of this PR?

are we going to keep trying to use the allocated generation data, or just use the same data sources we were using before?

if we use the same data sources we were using before, do we need to check the outputs for "actually connected to reality"?

if we want to keep trying with the newer/better data, how can we make the feedback loop shorter? right now it appears to be "katie makes some graphs, zane asks for new graphs, repeat"

My own understanding as someone parachuting into this project is:

we want MCOE outputs in the database (mcoe and mcoe_generators in particular) so that end users can access it; secondarily we want to move these calculations into dagster so that PPL can depend on that

I think that we can decouple "get data into the database" and "make the data better," and just focus on the old data sources. We can take all this analysis we've done and put it towards another PR, that can be worked on in parallel with the PPL stuff.

I think we should write some tests that express Zane's acceptance criteria for heat rates. I'm imagining some sort of clever usage of scipy.signal.find_peaks or similar... This basically caches all the thinking y'all have done about the correctness of the data, so that when we work on improving things later we can do so with confidence. Are there other acceptance criteria, and do we need these for CF/FC/MCOE/etc.?

I think the tests would help the feedback loop be shorter, but also I could imagine a good Zane/Katie pairing session would be much faster and more pleasant than the async back-and-forth we have going on here. That might be a good way to discover the right assertions we want to make in our tests!

Agree that we should build the "success criteria" into the validation tests to make improvements to the MCOE that we do later down the line easier to validate (when we get better coverage for unit_id_pudl for example). This would be somewhat new to me, so it might be useful to pair with @jdangerx on how this should be best implemented (find_peaks seems like a good place to start). I think it's likely that the MCOE passes these validation tests with both allocated generation and fuel, in which case I think we should merge with both. Otherwise, I can rewind a commit and we can just use generation allocations.

We know the Gregs use this data downstream, so I've been more concerned than normal about wanting to see confirmation that we haven't broken anything with the new methodology.
I haven't seen any problems with using both the allocated fuel and allocated generation, it has just a bit of a communications struggle to see the relevant metrics to know that. IIRC EIA started reporting the full fuel consumption for the CCGTs mid-2014, which I suspect is why the 2014 data looks different -- not sure why the new and old data would have yielded different results there, but the new results look more like what we would expect from CCGTs in general, so I don't think it's bad.
We have basic quantile value checks for the heat rate distribution coded in the validations right now, and given the plots above, I think that the MCOE using both allocated fuel and allocated generation will pass them. Getting a new type of data validation check set up sounds like a good idea in general -- we need to overhaul and expand our current data validations... given that we've basically never expanded them to cover the many, many new tables we've been creating, and there is much better tooling for this kind of validation than what we've got now -- but to me it feels beyond the scope of this PR. It would be great to do in conjunction with revisiting the expansion of coverage by unit_id_pudl which is the limiting factor in our heat rate coverage.
But I don't think that work is going to happen within the scope of any work we currently have funded, and I would really like to get the work that GregM contributed and we integrated into the outputs within the scope of our current funding.

@katie-lamb I created this PR originally so I can't approve it, but I'm good with it getting merged in and using the allocated fuel and generation for the MCOE.

@katie-lamb I created this PR originally so I can't approve it, but I'm good with it getting merged in and using the allocated fuel and generation for the MCOE.

rubber stamp incoming

I honestly don't have strong feelings about the dropping of null fuel_cost_per_mwh. BUT if we did want that then you could make a non-null non-db asset that feeds into a db skinny asset & the wide db asset.
Also I assume that the xfail situation is because of the expanded time series? which the skinny table doesn't have right?
All these other options sound good to me!

Any idea what's up with the integration tests? Looks like there's a unit_id_pudl column missing somewhere.


foundational_skills not parsed from taxonomy

foundational_skills are not parsed from the taxonomy currently. Need to update TAXONOMY_FOLDER to include foundational skills as well.

I see foundational skills was ditched in latest taxonomy
https://github.com/instructlab/schema/tree/main/src/instructlab/schema/v3


Unhandled Run Time Error

Hello,  I'm having issues adding my product on builder.io.  It show's all the products but immediately after adding it throws an error.

Hi @mikecicutto anything you can provide more about this error? reproduction steps and your space'spublic api key would be appreciated.

Closing this issue for now, please create a new one and add reproduction steps if you ran into this issue.


Add "Actor: Face Player"

Please check if the PR fulfills these requirements

[X] The commit message follows our guidelines
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Adds a new event, "Actor: Face Player".

This changes an actor's direction to face the player. By default, it determines whether the X or Y direction has a greater magnitude of difference between the player and the specified actor and sets the actor's direction to the greater. You can also specify if you only want the actor to face left/right ("Horizontal Only") and up/down ("Vertical Only"). You can finally invert the direction the actor faces so it faces away from the player.
Normal:

Inverted:

What is the current behavior? (You can also link to an open issue here)
No event to face player.

What is the new behavior (if this is a feature change)?
Adds "Actor: Face Player".

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
Not that I'm aware of.

Other information:
This seems to work for me, but I'm not sure if I added the event properly. I think I did, but might need someone to double check I didn't forget something or made unnecessary additions to get this working.
Also, localisations need to be updated.

Could this be achieved with a custom event that combines "actor relative to actor" and "set direction"?

@pau-tomas it can be; both this event and the boundary check one I've implemented in my game as a custom event. However, it is much slower. Applying the custom event to 8 actors, it takes about 5 seconds to traverse the area due to slowdown. With this code, I was able to cut out a lot of redundant calls, and it takes about 3 seconds to traverse the same area. Still some slowdown, but not as bad. Plus, it takes about 8 variables and cannot be used in other custom events.
{
    "script": [
        {
            "id": "938d56ce-5d79-4b3e-99b9-1b7dc763fcd0",
            "command": "EVENT_ACTOR_GET_POSITION",
            "args": {
                "actorId": "0",
                "vectorX": "0",
                "vectorY": "1",
                "__collapse": true,
                "__label": "Store Entity A's Position"
            }
        },
        {
            "id": "d493ab57-596d-4cae-b5c3-15d69a59135a",
            "command": "EVENT_ACTOR_GET_POSITION",
            "args": {
                "actorId": "1",
                "vectorX": "2",
                "vectorY": "3",
                "__collapse": true,
                "__label": "Store Entity B's Position"
            }
        },
        {
            "id": "9f6d20ee-353e-41ed-b370-1f219c8d0f83",
            "command": "EVENT_IF_ACTOR_RELATIVE_TO_ACTOR",
            "args": {
                "actorId": "0",
                "operation": "left",
                "otherActorId": "1",
                "__collapseElse": false,
                "__collapse": true,
                "__label": "If Entity A is Left of Entity B"
            },
            "children": {
                "true": [
                    {
                        "id": "8aa2489d-066b-4e06-b02a-6c73aac022f3",
                        "command": "EVENT_VARIABLE_MATH",
                        "args": {
                            "vectorX": "4",
                            "operation": "set",
                            "other": "var",
                            "vectorY": "2",
                            "value": "1",
                            "minValue": "0",
                            "maxValue": "255",
                            "clamp": false,
                            "__collapse": true,
                            "__label": "Store Entity B's X in Difference X"
                        }
                    },
                    {
                        "id": "9ba49f64-a344-4b1c-b880-92cf0b98c55e",
                        "command": "EVENT_VARIABLE_MATH",
                        "args": {
                            "vectorX": "4",
                            "operation": "sub",
                            "other": "var",
                            "vectorY": "0",
                            "value": "1",
                            "minValue": "0",
                            "maxValue": "255",
                            "clamp": true,
                            "__collapse": true,
                            "__label": "Subtract Entity A's X from Difference X"
                        }
                    },
                    {
                        "id": "62c62950-1a84-4e66-b252-e17946fdb642",
                        "command": "EVENT_SET_VALUE",
                        "args": {
                            "variable": "6",
                            "value": {
                                "type": "number",
                                "value": 4
                            },
                            "__collapse": true,
                            "__label": "Set Direction to Right",
                            "__comment": false
                        }
                    },
                    {
                        "id": "8ddbeb1e-673c-4f2a-a3e4-9def7e380107",
                        "command": "EVENT_END"
                    }
                ],
                "false": [
                    {
                        "id": "13112ad9-c40b-44fe-a705-6f30dae22d6a",
                        "command": "EVENT_VARIABLE_MATH",
                        "args": {
                            "vectorX": "4",
                            "operation": "set",
                            "other": "var",
                            "vectorY": "0",
                            "value": "1",
                            "minValue": "0",
                            "maxValue": "255",
                            "clamp": false,
                            "__collapse": true,
                            "__label": "Store Entity A's X in Difference X"
                        }
                    },
                    {
                        "id": "948c7794-2b6e-442f-85f9-e8bb24606513",
                        "command": "EVENT_VARIABLE_MATH",
                        "args": {
                            "vectorX": "4",
                            "operation": "sub",
                            "other": "var",
                            "vectorY": "2",
                            "value": "1",
                            "minValue": "0",
                            "maxValue": "255",
                            "clamp": true,
                            "__collapse": true,
                            "__label": "Subtract Entity B's X from Difference X"
                        }
                    },
                    {
                        "id": "8cbce616-52ca-4a6e-a698-ffd48bcf59a5",
                        "command": "EVENT_SET_VALUE",
                        "args": {
                            "variable": "6",
                            "value": {
                                "type": "number",
                                "value": 2
                            },
                            "__collapse": true,
                            "__label": "Set Direction to Left",
                            "__comment": false
                        }
                    },
                    {
                        "id": "0aa0d78f-24da-4d23-806f-0cb2004b705b",
                        "command": "EVENT_END"
                    }
                ]
            }
        },
        {
            "id": "83750296-a1f3-4b96-8a61-70cfc91e4cdf",
            "command": "EVENT_IF_ACTOR_RELATIVE_TO_ACTOR",
            "args": {
                "actorId": "0",
                "operation": "up",
                "otherActorId": "1",
                "__collapseElse": false,
                "__collapse": true,
                "__label": "If Entity A is Above Entity B"
            },
            "children": {
                "true": [
                    {
                        "id": "1aa08d62-2697-4834-86b3-e64d5ca41b65",
                        "command": "EVENT_VARIABLE_MATH",
                        "args": {
                            "vectorX": "5",
                            "operation": "set",
                            "other": "var",
                            "vectorY": "3",
                            "value": "1",
                            "minValue": "0",
                            "maxValue": "255",
                            "clamp": false,
                            "__collapse": true,
                            "__label": "Store Entity B's Y in Difference Y"
                        }
                    },
                    {
                        "id": "772cd3ba-b3ab-45c3-9dae-46f38c38bbbc",
                        "command": "EVENT_VARIABLE_MATH",
                        "args": {
                            "vectorX": "5",
                            "operation": "sub",
                            "other": "var",
                            "vectorY": "1",
                            "value": "1",
                            "minValue": "0",
                            "maxValue": "255",
                            "clamp": true,
                            "__collapse": true,
                            "__label": "Subtract Entity A's Y from Difference Y"
                        }
                    },
                    {
                        "id": "ce820921-e5b5-4ace-9382-779fc7291915",
                        "command": "EVENT_SET_VALUE",
                        "args": {
                            "variable": "7",
                            "value": {
                                "type": "number",
                                "value": 1
                            },
                            "__collapse": true,
                            "__label": "Set Direction to Down",
                            "__comment": false
                        }
                    },
                    {
                        "id": "2ae542dc-8f1b-44e9-9a7f-082a67c1767f",
                        "command": "EVENT_END"
                    }
                ],
                "false": [
                    {
                        "id": "3f7b4b18-fab7-43b6-a379-7cc730d2ac9c",
                        "command": "EVENT_VARIABLE_MATH",
                        "args": {
                            "vectorX": "5",
                            "operation": "set",
                            "other": "var",
                            "vectorY": "1",
                            "value": "1",
                            "minValue": "0",
                            "maxValue": "255",
                            "clamp": false,
                            "__collapse": true,
                            "__label": "Store Entity A's Y in Difference Y"
                        }
                    },
                    {
                        "id": "636da00a-9b83-49c2-aa2c-ec52ad414c40",
                        "command": "EVENT_VARIABLE_MATH",
                        "args": {
                            "vectorX": "5",
                            "operation": "sub",
                            "other": "var",
                            "vectorY": "3",
                            "value": "1",
                            "minValue": "0",
                            "maxValue": "255",
                            "clamp": true,
                            "__collapse": true,
                            "__label": "Subtract Entity B's Y from Difference Y"
                        }
                    },
                    {
                        "id": "579826f8-3e26-4672-9224-5f96b8cab35f",
                        "command": "EVENT_SET_VALUE",
                        "args": {
                            "variable": "7",
                            "value": {
                                "type": "number",
                                "value": 8
                            },
                            "__collapse": true,
                            "__label": "Set Direction to Up",
                            "__comment": false
                        }
                    },
                    {
                        "id": "da707b38-1ca3-4534-bca6-a631d9963885",
                        "command": "EVENT_END"
                    }
                ]
            }
        },
        {
            "id": "4687046e-daf1-454f-a603-3be01eda35f3",
            "command": "EVENT_IF_VALUE_COMPARE",
            "args": {
                "vectorX": "4",
                "operator": ">",
                "vectorY": "5",
                "__collapseElse": false,
                "__collapse": true,
                "__label": "If Difference X is Greater than Difference Y"
            },
            "children": {
                "true": [
                    {
                        "id": "76f1efdc-7c3c-4255-99ee-ab8d8989b36f",
                        "command": "EVENT_ACTOR_SET_DIRECTION",
                        "args": {
                            "actorId": "0",
                            "direction": {
                                "type": "variable",
                                "value": "6"
                            },
                            "__label": "Set Direction to Direction X",
                            "__collapse": true,
                            "__comment": false
                        }
                    },
                    {
                        "id": "ffe28386-43b4-4069-a9e8-fc4af62c1b11",
                        "command": "EVENT_END"
                    }
                ],
                "false": [
                    {
                        "id": "81626fa3-cd31-45ac-bca2-fe6c05d88159",
                        "command": "EVENT_ACTOR_SET_DIRECTION",
                        "args": {
                            "actorId": "0",
                            "direction": {
                                "type": "variable",
                                "value": "7"
                            },
                            "__label": "Set Direction to Direction Y",
                            "__collapse": true,
                            "__comment": false
                        }
                    },
                    {
                        "id": "1ffa7356-6dc6-4ea6-8c2e-2b6761e89e81",
                        "command": "EVENT_END"
                    }
                ]
            }
        },
        {
            "id": "63096829-b799-4665-8fb3-4299af7eef80",
            "command": "EVENT_END"
        }
    ],
    "__type": "script"
}

I figured this may be useful to others built into GB Studio as an event for enemies such as turrets or so.


[stable/rabbitmq] failing probes on disk or memory alarms

Is this a request for help?:

Is this a BUG REPORT or FEATURE REQUEST? (choose one):
BUG REPORT

Version of Helm and Kubernetes:
kubernetes v1.11, helm v2.11.0
Which chart:
stable/rabbitmq
What happened:

When memory usage reaches high watermark the response for probes looks like this:

$ curl -f --user sas:$RABBITMQ_PASSWORD <IP_ADDRESS>:15672/api/healthchecks/node
{"status":"failed","reason":"resource alarm(s) in effect:[memory]"}

so probe is failed. But rabbitmq is working at the moment and disabling incoming connections is not fixing anything.

When the same occur with disk alarm rabbitmq loose connections, consumers can't connect and get messages. So container is killed when liveness probe fails. But its not helping. Actually after that rabbitmq can't start because the liveness probe fails while rabbitmq reading mnesia data.

What you expected to happen:
Rabbitmq can accept connections when disk or memory alarm fires.
How to reproduce it (as minimally and precisely as possible):
values:
rabbitmq:
  clustering:
    address_type: hostname
  configuration: |-
      ## Clustering
      cluster_formation.peer_discovery_backend  = rabbit_peer_discovery_k8s
      cluster_formation.k8s.host = kubernetes.default.svc.cluster.local
      cluster_formation.node_cleanup.interval = 10
      cluster_formation.node_cleanup.only_log_warning = true
      cluster_partition_handling = autoheal
      ## queue master locator
      queue_master_locator=min-masters
      ## enable guest user
      loopback_users.guest = false
      ## https://www.rabbitmq.com/memory.html#memsup-usage
      vm_memory_high_watermark.absolute = 3GB
      disk_free_limit.absolute = 1GB
replicas: 1
persistence:
  enabled: true
  storageClass: local-storage
  size: 3Gi
resources:
  limits:
    cpu: 5
    memory: 3Gi
  requests:
    cpu: 5
    memory: 3Gi

You need to fill the pv with durable queues data or just create files in the pv to trigger disk alarm.
Anything else we need to know:
@tompizmor

This is probably something that needs to be addressed upstream with RabbitMQ. We need a health check endpoint without taking into effect disk and memory alarms. Either a new endpoint or the existing endpoint could make the alarm optional with a HTTP parameter. Switching back to rabbitmqctl status is not an option since it causes high CPU usage and doesn't properly check rabbitmq is functioning by listing channels and queues. I've seen scenarios where rabbitmqctl status shows it is up but I couldn't connect to it until I restarted rabbitmq.

Has someone started a discussion with upstream rabbitmq about this issue?

@thomas-riccardi, I dont think it's some kind of the rabbitmq management plugin issue. That's just misconfigured probes.

@f84anton how would you configure the probes then?
The readiness probe should raise an error when cutting new incoming connections would help resolve the issue.
For memory and disk alarms it is tricky as maybe solving the issue is done by adding more consumers, which do need to connect to rabbitmq. Or maybe new connections are just for producers, which would then be blocked by the alarm: these new connections may indeed be better off not connecting to this node.
As for the liveness probe: it should raise an error when killing the container would help resolve the issue. The memory alarm could indeed be resolved by killing the container, but not the disk alarm (for persistent messages).
Conclusion

The memory and disk alarms could be useful as probe errors only in some cases. It should thus be a deployment setting.
Not sure if it should be the default as it is today.
Documentation would be useful in any case.
To be able to selectively ignore memory and disk alarms in the probe we do need new upstream features: an api endpoint for healthchecks/node where we can optionally ignore memory and disk (and more?) alarms.

@f84anton as for your second sub-issue:

When the same occur with disk alarm rabbitmq loose connections, consumers can't connect and get messages. So container is killed when liveness probe fails. But its not helping. Actually after that rabbitmq can't start because the liveness probe fails while rabbitmq reading mnesia data.

It seems to be a different issue: your node seems to take a lot of time to start up, and the default liveness probe configuration is not calibrated for that and raises an error too early.
If that is the case, then you should change the liveness probe configuration (mainly the initialDelaySeconds, which defaults to 120):
https://github.com/helm/charts/blob/6a4608e91b6bb74225f792fbceefb550465f3df2/stable/rabbitmq/values.yaml#L194


NEXT fix empty switch padding (fixes #3010)

Linked Issue
Fixes #3010
Description
Fixes the Switch component having some extra padding to the right when there is no child (they're shown as a label)
before

after

Awesome, thanks @SIMULATAN


Sticker info

Hello. I remember the API was returning more information about stickers(name, wear) but now I have only stickerId and slot. Has the rest data been removed from the response? If not, how can I get it?
    "stickers": [
      {
        "stickerId": 4538,
        "slot": 3
      }
    ],

URL:
steam://rungame/730/76561202255233023/+csgo_econ_action_preview%20M4652848484126482244A35394143813D4812146788585465113

It also used to return the item name in iteminfo, but now it doesn't
Full response
{   "iteminfo": {     "origin": 8,     "quality": 4,     "rarity": 4,     "a": "35394143813",     "d": "4812146788585465113",     "paintseed": 386,     "defindex": 7,     "paintindex": 1035,     "stickers": [       {         "stickerId": 4538,         "slot": 3       }     ],     "floatid": "35394143813",     "low_rank": 1,     "high_rank": 2,     "floatvalue": 0.4011116921901703,     "m": "4652848484126482244",     "s": "0"   } }

haven't looked into all the underlaying packages, but sending the message to the GC myself also returned less data than before. I would also be interested in where to get a mapping stickerId<->market_hash_name


Print, but don't fail on deprecation notice

A simple change so that deprecation notices are printed, but don't cause test failures. A possible fix for issue #27.

Thanks for pushing those amendments @pcfens. Did you get chance to look at the tests for fail_on_warnings?

I'll need to write some tests around the fail_on_warnings flag.
Any thoughts on how you'd like the tests to be written? I'm not the most experience with Ruby, and it doesn't look like there are others in spec/puppet-syntax/tasks/puppet-syntax_spec.rb for me to model tests after.

Sure, I'll have a go at adding a test for fail_on_warnings.

A quick update on this; I have some minor changes to add and have added tests for the rake task. I'll tidy those up and push them up soon for review.

@pcfens Following up from my comment 10 days ago, I realised the additional tests I was adding should not block this pull request and I think this is almost ready to merge.
I have added some comments above, once these have been addressed I think this is good to merge, as this is a useful fix.

Other than the knowing that we'll run in to issues as soon as Puppet 4 is released - I think that we've gotten just about everything fixed up.

Thanks for your work on this @pcfens, I will review the changes you have pushed. In the meantime, could you please look at the build failure?

I think that the 1.8.7 tests are failing because of a change in rspec (a new version was released on February 3rd). Pinning the rspec version to 3.1.0 seems to fix the issue.

We decided this morning to drop support for 1.8.7 since even 1.9 is about to be EOLed but will still exist on precise so we will continue to support it.
So those test failures arn't a problem anymore.

Thanks for all of your hard work on this @pcfens, much appreciated :+1:

This is amazing! Thank you for persevering with us Phil \o/

Released as version 2.0.0; thanks @pcfens.


code cannot  run, gives Assertion '__pos <= size()' failed. error

I run it on simple terminal and xterm, both died with same error, here's the whole output:
% ./quinesnake.cpp
./quinesnake.cpp: In function ‘int C(int, int, int)’:
./quinesnake.cpp:19:80: warning: no return statement in function returning non-
void [-Wreturn-type]
   19 | win();})x";I G(I x,I y){K 3&s[y*w+x]>>8;}I C(I x,I y,I c){(s[y*w+x]&=~z
)|=c<<8;}
      |
        ^
./quinesnake.cpp: In function ‘int P(int, int&, int&)’:
./quinesnake.cpp:20:62: warning: no return statement in function returning non-
void [-Wreturn-type]
   20 | I P(I d,I &x,I &y){F(d==1)x-=2;!d&&y++;d==2&&y--;F(d==3)x+=2;}I M(){cur
s_set(0);
      |                                                              ^
/usr/src/debug/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:1221: std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::reference std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator[](size_type) [with _CharT = wchar_t; _Traits = std::char_traits<wchar_t>; _Alloc = std::allocator<wchar_t>; reference = wchar_t&; size_type = long unsigned int]: Assertion '__pos <= size()' failed.
                                                                                sh: line 3: 13148 Aborted                 ./o < /dev/tty

I do have ncurses and g++ installed.

woops, I just clone this repo and the original file has no issue, maybe my editor did some indent to cause this error, close this now, sry for the bother...


Open other notifications make whatsie active too

If I click to any others notifications whatsie opened too.
Ubuntu 20.10
WhatSie snap 0+git.15de59c

Other notifications, mean notifications from other applications ? :flushed:

yep

What desktop environment, OS you using? Can you share screen recording of what is happening?

Ubuntu 20.10 Gnome
I have problems with screen recording because it's affecting personal data..


Move node/api access logs from info to debug

⚠ Support requests in an issue-format will be closed immediately. For support, go to Swarm's Discord.
Context
I'm running a bee node and a dashboard on a dappnode.
At the logging info level i get valuable info like this:

But i get also spammed with node/api access messages:

It might be more useful to move  node/api access logs to debug imo.
Summary

Expected behavior

Actual behavior

Steps to reproduce

Possible solution

This would be a simple change but as I know API access logs are typically logged at the info level. @istae, @ldeffenb ?

I've wanted to do this for a while to clean up my --verbosity 3 log output, especially when I've got a script running that really beats up the API.   So I've got no issues with changing the default logging level.
But it would be really really nice if there was better documentation on the logging API, like maybe examples of how to use it to individually enable the API logging if a user desires to still see it.
https://docs.ethswarm.org/api/#tag/Logging

I've wanted to do this for a while to clean up my --verbosity 3 log output, especially when I've got a script running that really beats up the API. So I've got no issues with changing the default logging level. I can certainly see a node being used by bee dashboard (like on DAppNode) would suffer from continuous API logs as well.
But it would be really really nice if there was better documentation on the logging API, like maybe examples of how to use it to individually enable the API logging if a user desires to still see it.
https://docs.ethswarm.org/api/#tag/Logging

Thank you for the feedback. Regarding better documentation would be great if you can open a new issue on this aspect. Let me loop in @NoahMaizels also.

to fix your trouble check this solution click
maybe this will solve your problem.


Nodejs is installed in WSL. How to set up the node path ? Thanks

Before you submit an question we recommend you to check out the DOCUMENT first.
You can also find more information in:

TROUBLESHOOTING
FAQ

💬 Questions and Help
Please outline the questions.
Hi,
First thing first, thanks for the awesome plugin!
According to the documentation, I need to "	Specify the Node.js executable path. for example, C:\Program Files\nodejs\node.exe".
However, I install nodejs in my WSL, Ubuntu 16.04 LTS, to be precise. So, there is not a node path for "node.exe".
But according to the solved issue #46 , your plugin does support WSL.
So, I am confused. How do I use this awesome pluin while I am using WSL and have installed Nodejs in WSL? Thanks.

Just reset to the setting to the default value, which is node.
Since I believe in the WSL environment, the node executable is in your PATH env already

I guess it may be a path problem:
I've got this:
Error: Cannot find module '/mnt/c/Users/Yumin/AppData/Local/Programs/Microsoft VS Code/\mnt\c\Users\Yumin\.vscode\extensions\shengchen.vscode-leetcode-0.15.2\node_modules\vsc-leetcode-cli\bin\leetcode'
This is an obvious wrong path to look for the leetcode command, which has been installed globally.
So, any configuration to override this path ?

Can you provide your extension settings?

  "leetcode.useWsl": true,
  "leetcode.nodePath": "node",
  "leetcode.defaultLanguage": "javascript",
  "leetcode.showLocked": true,
  "leetcode.showCommentDescription": true,
  "leetcode.outputFolder": "/mnt/d/leetcode",
  "leetcode.workspaceFolder": "/mnt/d/leetcode",

What if set the "leetcode.outputFolder" to empty?

@medmin It would be great if you would like to offer some help for this issue. Debugging the extension is very simple, just:

clone the repo
run npm install to install the dependencies
Open the repo in VS Code
Hit F5 to start a debug session.

That's it.

@medmin The new release contains a fix of the WSL path issue. Could you have a try to see if the problem solved?


Experimenting with Pydantic and Swagger APIs

Hi will,
Chanced upon the project and thought i'd try to contribute a bit. I've managed to get a simple swagger and redoc documentation running which does request time validation with Pydantic.
I've done it for the first few APIs and plan on slowly working through the other APIs when I get the time.
I'm a bit unsure as to what might be the best way to type the response type of the db.info() call. Was wondering if you had any suggestions.
Somethings I'd like to figure out but am not too sure how to

Provide the body in the response by using the default api.validate() decorator
Allow for Success Message and Error Message to be returned and @pydantic_to_dict to automatically extract out an error code and return them

Thanks Ivan, this is super helpful! Let me know when you're ready for me to merge.

Thanks Ivan, this is super helpful! Let me know when you're ready for me to merge.


$hideNullAttributes to DetailViewWidget

Added feature that allows you to hide null attributes.

Non optimal expression order inside if.

Disabling of the attribute display already covered by visible option.
I don't think this enhancement should be taken. Here you are removing null values, but what if I want to remove all 'empty' values for example?


Associate existing Security Group with Network Interface on creation

Hi,
Is there a way to create a network interface, and have it associated / assigned to an existing security group?
My use case is thus;
A customer I work for require all network interfaces created in Azure has a security group.
This is enforced though a policy assignment.
Through a separate process, I have an existing vnet, and subnet (which is already assigned to a security group).
I'd like the network interface to inherit the existing security group of the subnet.
example code
import pulumi_azure as azure

name = "resource-prefix"

resource_group_name = "<Company subscription>-network"

subnet = azure.network.get_subnet(
    name="<Company subscription>-subnet",
    virtual_network_name="<Company subscription>-vnet",
    resource_group_name=resource_group_name,
)

network_interface = azure.network.NetworkInterface(
    f"{name}:server-nic",
    ip_configurations=[
        azure.network.NetworkInterfaceIpConfigurationArgs(
            name="ip-config",
            private_ip_address_allocation="Dynamic",
            subnet_id=subnet.id,
        ),
    ],
    resource_group_name=resource_group_name,
)

nic = azure.network.NetworkInterfaceSecurityGroupAssociation(
    f"{name}:server-nic:sg",
    network_interface_id=network_interface.id,
    network_security_group_id=subnet.network_security_group_id,
)

This code fails at the creation of network_interface, due to policy assignment.

Apologies for never responding to this question.
I think the answer is "no". The policy would probably need to change to account for this.
Since the issue is three years old, I'll go ahead and close it.


CFFL

CFFL

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_camz45pab8/clone/recipe/meta.yaml:19: missing_wheel: For pypi packages, wheel should be present in the host section
ERROR: /tmp/abs_camz45pab8/clone/recipe/meta.yaml:26: missing_pip_check: For pypi packages, pip check should be present in the test commands
WARNING: /tmp/abs_camz45pab8/clone/recipe/meta.yaml:32: missing_description: The recipe is missing a description
ERROR: /tmp/abs_camz45pab8/clone/recipe/meta.yaml:32: missing_dev_url: The recipe is missing a dev_url
ERROR: /tmp/abs_camz45pab8/clone/recipe/meta.yaml:32: missing_documentation: The recipe is missing a doc_url or doc_source_url
ERROR: /tmp/abs_camz45pab8/clone/recipe/meta.yaml:32: http_url: http://github.com/themiurgo/ratelim is not https
ERROR: /tmp/abs_camz45pab8/clone/recipe/meta.yaml:32: missing_license_family: The recipe is missing the about/license_family key.
Errors were found


T3PA clutch break input isn't read

Hi, first I want to say thank you for making this project. It work perfectly well with a Ferrari 485 Spider. I have an issues that the input from my clutch can't be read for some reason. Just wonder that did you test with a 3 pedals brake? Cause if you do it probably mean that my pedals is broken.
Again thank you for making this project

Hey thanks for reporting this issue. I haven't tested it with any other wheels/pedals other than the Spider. I did not implement clutch functionality, but I believe I can push an update to support clutch input. Just to be sure, all other functionality works properly right?

Hi yes all other functionality work properly. Just the clutch seem to be the issue.

hey so I edit the code so the rightThumstickY is set to RacingWheel.Clutch, figure I just need to set so the computer read it as y thumbstick. I was able to build the project but then it hit me with this

Mind you that the stable version doesn't have this issues. I wonder if you have this issue before.

Seems like it failedto load the .NET runtime. Did VS prompt you to change the .NET runtime version or anything when you first opened the project?


Encryption in transit / which versions of SSL/TLS are allowed?

Please can you specify applicable versions of TLS you are able to connect in all client to service connections? You recommend version 1.2 but you do not specify whether also lower versions (e.g. 1.0 or 1.1) are allowed. It is important in combination with only preview ability of firewall filtering.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: cffc5753-1125-f6ee-de76-8ea460144c10
Version Independent ID: af3b7535-e78b-abb6-4a54-cdc55b6641bf
Content: Security and data privacy - Azure Cognitive Search
Content Source: articles/search/search-security-overview.md
Service: cognitive-search
GitHub Login: @HeidiSteen
Microsoft Alias: heidist

@akczcz Hi, I just updated the docs to clearly state the 1.2 is used on all connections, and 1.0 and 1.1 are not supported.  The change should be live in about 6 hours.  Thanks for posting!
#please-close

Hello, thx! that's great, thank you for your quick response
Adam

Od: PRMerger20<EMAIL_ADDRESS>Odesláno: úterý 21. dubna 2020 18:56
Komu: MicrosoftDocs/azure-docs<EMAIL_ADDRESS>Kopie: Adam Kolarik<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Předmět: Re: [MicrosoftDocs/azure-docs] Encryption in transit / which versions of SSL/TLS are allowed? (#52942)
Closed #52942https://github.com/MicrosoftDocs/azure-docs/issues/52942.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/azure-docs/issues/52942#event-3256994424, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AMHP6MGRIMRSCTPC7FYUTB3RNXF5BANCNFSM4MNKE47Q.


Fix for #1621: Submission Rule fields are now required fields

Submission rule fields are now required to be filled in the Assignment edit/create form if a submission rule is chosen.
Fix for #1621

The issue still seems to persist even when the Submission Rule fields are populated. I'll try to look into it more and find the root cause.


(Re-)Add coalesceToEmpty method to o.o.common.Strings util class

Is your feature request related to a problem? Please describe.
A relatively common use case during REST handling is to replace a null String with an empty String:
public static String coalesceToEmpty(@Nullable String s) {
    return s == null ? "" : s;
}

Such a method exists in ml-commons and anomaly-detection plugins and is being added to job-scheduler.
This exists in the current release (2.4.1) of the Strings class here and is referenced by the alerting plugin but was removed in #5288 as "unused".  (This broke the AD plugin which prompted re-adding its own method.)
Describe the solution you'd like
Don't repeat code.  Add this method back to the Strings class.
Additionally, I'm curious why this util class is marked "internal" as it's useful for dependent classes to use (which at least the alerting plugin does).  The removal was not marked deprecated nor mentioned in the change log (likely because of its "internal" usage) but there is a lot of use of other methods in this class.
Describe alternatives you've considered
It may be a better idea to create a util class with all the RestHandlerUtils in the above-linked plugin packages.
Additional context
The method appears to have originated in com.google.common.base.Strings and was moved to the Strings class (in open-source ES pre-fork) to remove that external dependency.
If we want to remove "internal" util classes/methods like this, we should consider either using external dependencies or creating a separate supported (API) project with util classes to provide the same functionality without duplicating code.

I think we can all agree that coalesceToEmpty is not "OpenSearch-specific business logic", thus isn't not an API I think OpenSearch should expose. However, having helpers to make life easier for plugin authors may make sense if we wanted to continue building tightly-coupled plugins. Introducing RestHandlerUtils would be one way to do it. Which tells me that the right place for this method was indeed in com.google.common.base.Strings, a helper library whose only purpose in life was to do things about strings, aka coalesceToEmpty was its business logic. We just didn't want the extra dependency for such a silly method.
If we go all in with helpers, the risk is that RestHandlerUtils grows out of control and becomes common-utils, a kitchen sink of unrelated functions.
All that to say that I think putting this method back into this project and unmarking it from internal is harmless, but that I hope ~a plugin~ an extension author will not care whether we do or don't.

Closing this request as I have decided it's the wrong answer to a real problem.
I'll consider a future request for an API RestHandlerUtils class.


kite#completion#popup_exit

I had kite installed and it suddenly decided to give this error while using vim
E117: Unknown function: kite#completion#popup_exit
This  completely breaks vim because a new line cannot be made
I've uninstalled the vim plugin and kite but the problem persists. Attempting to re-install vim. Hopefully the problem doesn't persist. I just want to use vim again.

Updating vim with brew didn't help.
However, removing my .vimrc "fixed" the problem
here is my old .vimrc
map <F2> i#!/bin/bash<ESC>
map <F3> o#This file was created on <ESC>:r!date "+\%x"<ESC>kJ

au FileType c,cpp setlocal comments-=:// comments+=f://
syntax on
:ab /**************************************** /****************************************
set incsearch
:ab #e ^V^H*****************************************/
autocmd BufWinLeave *.* mkview
autocmd BufWinEnter *.* silent loadview
highlight Comment ctermfg=Green
" toggle between terminal and vim mouse
set mouse=n

filetype plugin indent on
" show existing tab with 4 spaces width
set tabstop=4
" " when indenting with '>', use 4 spaces width
set shiftwidth=4
" " On pressing tab, insert 4 spaces
set expandtab
inoremap <S-Tab> <C-d>

set visualbell
set t_vb=

augroup remember_folds
  autocmd!
  autocmd BufWinLeave * mkview
  autocmd BufWinEnter * silent! loadview
augroup END

I don't know what is causing the kite#completion#popup_exit

Okay, clearing ~/.vim/views/ helped. Still not sure what's going on but vim works now

Thanks for posting your vimrc – that's really helpful.  These lines stood out to me:
autocmd BufWinLeave *.* mkview
autocmd BufWinEnter *.* silent loadview

Vim's :mkview remembers mappings but not defined functions (see :help mkview).
The function kite#completion#popup_exit() was removed in e231c72, which was released in v1.0.76 of this plugin (you can get the version from :echo kite#utils#plugin_version()).
I think what happened was your kite plugin got updated from below v1.0.76 to v1.0.76 or above, and when you next entered a buffer, :loadview restored the mapping which pointed to kite#completion#popup_exit() but not the function itself.
There isn't much we can do about this – Vim's own docs for :mkview say that it's "not perfect" – apart from document it, which we'll do.  Still, I'm sorry you had this trouble.
If you wanted to re-install the Kite plugin it would work fine again.

Closing this now but please do open a new issue if you have any further problems.

Closing this now but please do open a new issue if you have any further problems.


Make the wing chord surface accessible for the intersection API

We need to make the wing chord surface accessible to intersection with planes etc.
Thus we also have to makeup an UID to references the chord surface. We could e.g. use the WingUID + _chord.

Implemented in commit d3f987185941032545eb54


When is v1.0.x to be published to Maven?

Hello!
I have a project that relies on the most recent version of mongoflink (1.0). I've relied on packing mongoflink on my own, but I'm wondering if there are plans to release 1.0 soon on Maven?
Thanks for the great work!

Thank you for reaching out! @kurnoolsaketh
The 1.0 release process is blocked by table API support which in the past few months we didn't have enough capacity to deal with. But as you ask about, I will revisit the process in days.
BTW, Apache Flink would support MongoDB connector in 1.17, so MongoFlink would be freezer and remain as an alternative to Flink prior to 1.17.

But as you ask about, I will revisit the process in days.

Thank you!

Apache Flink would support MongoDB connector in 1.17

Good to know – do you think the 1.0 release will happen before 1.17 goes out? In the meanwhile, I will plan on continuing using MongoFlink as is.


[ContentDialog] Fix title margin & fontweight and corners

Fix corners, title font weight and margin between title and top border
Description

Fixes CornerRadius properties for inner grids
Sets the title fontweight to SemiBold
Changes margin to 21 to match the visual design

Motivation and Context
VSO: 32303725
How Has This Been Tested?
Visual tests
Screenshots (if appropriate):

/azp run

/azp run


README BADGES

Hi @smaranjitghose
I would like to contribute to this repository by making nice badges , Let me know if you are interested in
Kindly do assign me

The above image is a example

Not required

Not required


Support for trailing headers?

Are there any plans to support trailing headers as per RFC 2616?
Right now it looks like it is intentionally not supported as per https://github.com/shazow/urllib3/pull/597#discussion_r29098757

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/31192148-support-for-trailing-headers?utm_campaign=plugin&utm_content=tracker%2F192525&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F192525&utm_medium=issues&utm_source=github).

2616 is dead. 7230-35 are the correct RFCs to cite. Specifically you want the section on Trailers.

Right now I think supporting trailers is more trouble than it's worth. httplib does not handle them properly, and while our hacked version does, most of the code has no expectation that they'll be used.
Given that they're so uncommon, I'm inclined to file this under "things we'll do if and when we replace httplib".

Added to the v2.0 wishlist. :)


Syntastic don't work with Vim 7.0.237

Hello, just installed Syntastic via vundle to my work pc, with CentOS 5.10, and upon vim launch i recieve this error message:
syntastic: error: need Vim version 7.0.175 or later
Press ENTER or type command to continue
But my Vim version is 7.0.237.

:ver
VIM - Vi IMproved 7.0 (2006 May 7, compiled Jan  8 2013 23:55:00)
Included patches: 1, 3-4, 7-9, 11, 13-17, 19-26, 29-31, 34-44, 47, 50-56, 58-64, 66-73, 75, 77-92, 94-107,
109, 202, 234-237
Modified by<EMAIL_ADDRESS>Compiled by<EMAIL_ADDRESS>

But my Vim version is 7.0.237.

Not really.  Your version is essentially 7.0.109 with a smattering of later patches.  It misses the critical patch 175. :smile: But even aside from your Vim being a Frankestein, 7.0.237 was all the rage in June 2007.  Syntastic is currently a one-man show, you can't realistically expect me to tell you anything else than to upgrade your Vim.
If you want to provide useful input to this project get a clean 7.0.175, compile it, and see if the latest version of syntastic works with it (or rather, tell me how it breaks).  To the best of my knowledge nobody has tried that yet.

FWIW, I just tripped over breakage on 7.1.138, because getpid() isn't there:
Error detected while processing .../syntastic/autoload/syntastic/util.vim:
line  404:
E117: Unknown function: getpid
E15: Invalid expression: 'syntastic_' . getpid() . '_' . reltimestr(g:_SYNTASTIC_START) . '_'

I am indeed applying the "upgrade your Vim[!]" strategy, but figured I'd pass on an FYI-in-passing that the minimum does seem to have exceeded the check. :heart:

@matthewd Fixed (well, sort of) in 49a94fe6.

I am indeed applying the "upgrade your Vim[!]" strategy

Unfortunately i'm not able to upgrade vim, since it is on server with a really old CentOS, and our admins doesn't want to install any package which isn't in official repo (or another stupid excuse, they have a lot)

@andreyorst You can always compile and install your own version in your $HOME.


refactor: small refactor

Proposed changes
Issue Number: close #xxx
Problem Summary:
Describe the overview of changes.

rename GroupExpression
use HashSet<GroupExpression> groupExpressions in memo

Checklist(Required)

Does it affect the original behavior: (Yes/No/I Don't know)
Has unit tests been added: (Yes/No/No Need)
Has document been added or modified: (Yes/No/No Need)
Does it need to update dependencies: (Yes/No)
Are there any changes that cannot be rolled back: (Yes/No)

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

PTAL @morningman @EmmyMiao87


Firefox requires xpi file type for extension code, but doesn't allow it for extension source code

When building for firefox, we automatically compress results into a XPI file. This is good for the app code as it is preferred for when submitting the code to firefox.
The problem is that firefox also requires the submission of the source code for extensions that use bundlers. That source code needs to be compressed into any of the following formats: .zip, .tar.gz, .tgz, .tar.bz2
We already provide the ability to zip-source, we should add a way to specify the file type for posterity.

If anyone needs a workaround for this, you can zipSource for your chrome build and then just zip without source for firefox. That way you get the source zip in .zip format.

hey @bo-carey, not sure I'm following. what is the optimal workflow here in your opinion?
you can compress the final build via --zip flag and the source via --zip-source like pnpm extension build --zip.

Pretty much that! I wasn't sure what you might think of the issue. I'd be happy to take this on as a first issue if that's alright.

sure! you can use extension build --zip to zip your distribution files and extension build --zip-source to zip the source files. you can also combine both:
# Generates a zip artifact for both production and development
extension build --zip-source --zip

let me know if that's not the case, happy to help