Variables

Creating a Varaibles.JSON

Some suggestions:

purge .DS_Store files
move all Auxilary/.. files to upper level with MIP_$ prefix

@wolfiex to try and quantify my suggestions:
  "ps": {
    "ps_1hr-ap-tav-z0-hxy": {
      "branded_variable_name": "ps_1hr-ap-tav-z0-hxy",
      "cell_measures": "area: areacella",
      "cell_methods": "area: time: mean",
      "comment": "surface pressure (not mean sea-level pressure), 2-D field to calculate the 3-D pressure field from hybrid coordinates",
      "dimensions": [
        "longitude",
        "latitude",
        "time"
      ],
      "frequency": "1hr",
      "long_name": "Surface Air Pressure",
      "modeling_realm": [
        "atmos"
      ],
      "out_name": "ps",
      "positive": "",
      "provenance": [
        {
          "CMIP6": {
            "dreq_uid": "19c071f8-81b1-11e6-92de-ac72891c3257",
            "mip_table": "AERhr",
            "variable_name": "ps"
          }
        }
      ],
      "standard_name": "surface_air_pressure",
      "type": "real",
      "units": "Pa",
      "validation": {
        "ok_max_mean_abs": "",
        "ok_min_mean_abs": "",
        "valid_max": "",
        "valid_min": ""
      }
    },
    "ps_3hr-ap-tpt-z0-hxy": {
...
    },
    "ps_6hr-ap-tpt-z0-hxy": {
...

Becomes something like
  "ps": {
    "standard_name": "surface_air_pressure",
    "long_name": "Surface Air Pressure",
    "table_id": {
      "AP1hr": {
        "branded_variable_name": "ps_1hr-ap-tav-z0-hxy",
        "cell_measures": "area: areacella",
        "cell_methods": "area: time: mean",
        "comment": "surface pressure (not mean sea-level pressure), 2-D field to calculate the 3-D pressure field from hybrid coordinates",
        "dimensions": [
          "longitude",
          "latitude",
          "time"
        ],
        "frequency": "1hr",
        "modeling_realm": [
          "atmos"
        ],
        "out_name": "ps",
        "positive": "",
        "provenance": [
          {
            "CMIP6": {
              "dreq_uid": "19c071f8-81b1-11e6-92de-ac72891c3257",
              "mip_table": "AERhr",
              "variable_name": "ps"
            }
          }
        ],
        "type": "real",
        "units": "Pa",
        "validation": {
          "ok_max_mean_abs": "",
          "ok_min_mean_abs": "",
          "valid_max": "",
          "valid_min": ""
        }
      },

@wolfiex I'd remove the subdirectory altogether, so you can see files directly, particularly the MIP_variables.json

So here's a take on what is "generic" (across all tables) and what is table-specific:

    "ps": {
# generic
      "long_name": "Surface Air Pressure",
      "out_name": "ps",
      "positive": "",
      "standard_name": "surface_air_pressure",
      "type": "real",
      "units": "Pa",
# table-specific e.g. AP1hr, Amon, etc
      "branded_variable_name": "ps_1hr-ap-tav-z0-hxy",
      "cell_measures": "area: areacella",
      "cell_methods": "area: time: mean",
      "comment": "surface pressure (not mean sea-level pressure), 2-D field to calculate the 3-D pressure field from hybrid coordinates",
      "dimensions": [
        "longitude",
        "latitude",
        "time"
      ],
      "frequency": "1hr",

      "modeling_realm": [
        "atmos"
      ],
      "provenance": {
        "CMIP6": {
          "dreq_uid": "19c071f8-81b1-11e6-92de-ac72891c3257",
          "mip_table": "AERhr",
          "variable_name": "ps"
        }
      },
      "validation": {
        "ok_max_mean_abs": "",
        "ok_min_mean_abs": "",
        "valid_max": "",
        "valid_min": ""
      }
    },

And the "final" format is close:
  "ps": {
# generic
    "long_name": "Surface Air Pressure",
    "out_name": "ps",
    "positive": "",
    "standard_name": "surface_air_pressure",
    "type": "real",
    "units": "Pa",
# table-specific
    "tables": {
      "AP1hr":{
          "branded_variable_name": "ps_subhr-ap-tpt-z0-hxy",
          "comment": "surface pressure (not mean sea-level pressure), 2-D field to calculate the 3-D pressure field from hybrid coordinates",
          "dreq_uid": "a1fa78aecfc6a17c21ff759d0b322306504a47e1",
          "frequency": "subhrPt",
          "mip_table": "Esubhr",
          "dimensions": [
            "longitude",
            "latitude",
            "time1"
          ],
          "modeling_realm": [
            "atmos"
          ],
          "validation": {
            "ok_max_mean_abs": "",
            "ok_min_mean_abs": "",
            "valid_max": "",
            "valid_min": ""
          },
        "provenance": {
          "CMIP6": {
            "dreq_uid": "19c071f8-81b1-11e6-92de-ac72891c3257",
            "mip_table": "AERhr",
            "variable_name": "ps"
          },
        },
      "APday": { },
      "APsubhrPt":{ },
      ...,
      },
    }
  },

this should now be consistent with the rest of the variables file. @durack1

@durack1  any comments on the variables.json?

@wolfiex this looks perfect!

Outlining the format of what is contained in the root dir of this repo (as identified in the google slide):

MIP_calendar.json
MIP_esgf_node_id
MIP_frequency
MIP_institution_id (ROR refs)
MIP_license
MIP_projects (to CVs URLs, e.g. CMIP6Plus_CVs, input4MIPs_CVs, etc) <- test suite
MIP_src_type
MIP_realm
MIP_regions (CF or CORDEX)
MIP_variables.json (master var list)

@wolfiex I had a quick chat with @taylor13, showing him the structure of the Auxilary/variables.json which he thinks looks great as a first pass.
If the org tweaks https://github.com/PCMDI/mip-cmor-tables/pull/24#issuecomment-1779879780 can be made, then I think we're good to go for the CV drop-in with this repo.
It would be great to pad out an example with CMIP5/3 provenance, but that will not be done inline for the presentation, rather edited I think

I have made a first pass at adding CMIP 3/5 tables.
(3 will require table renaming).
have extracted the cmip3varaiables.json in src/variables:

https://github.com/PCMDI/mip-cmor-tables/blob/variables/src/variables/cmip3variables.json
https://github.com/PCMDI/mip-cmor-tables/blob/variables/src/variables/cmip5variables.json

Matching on standard names does however incur some problems - e.g.  'area_fraction' in the CMIP5 provenence
  "wetlandFrac": {
    "long_name": "Wetland Percentage Cover",
    "out_name": "wetlandFrac",
    "positive": "",
    "standard_name": "area_fraction",
    "type": "real",
    "units": "%",
    "tables": {
      "LPmon": {
        "branded_variable_name": "wetlandFrac_mon-ld-tav-z0-hxy",
        "comment": "Percentage of grid cell covered by wetland. Report only one year if  fixed percentage is used, or time series if values are determined dynamically.",
        "frequency": "mon",
        "dimensions": [
          "longitude",
          "latitude",
          "time",
          "typewetla"
        ],
        "modeling_realm": [
          "land"
        ],
        "provenance": {
          "CMIP6": {
            "dreq_uid": "6f6acb20-9acb-11e6-b7ee-ac72891c3257",
            "mip_table": "Emon",
            "variable_name": "wetlandFrac"
          },
          "CMIP5": {
            "mip_table": "Lmon",
            "variable_name": "c4PftFrac"
          }
        },
        "validation": {
          "ok_max_mean_abs": "",
          "ok_min_mean_abs": "",
          "valid_max": "",
          "valid_min": ""
        }
      }
    }
  },```

Problem above fixes using fuzzy matching with a threshold ratio of 70%.  Failed variables logged in .log

@wolfiex CMIP3/5 matching, nice! I had assumed this was a job for another time.
The direct match will likely be using the standard_name attribute, e.g.
https://github.com/PCMDI/cmip3-cmor-tables/blob/2c9b2cddbf911a1b00bab01586b0b9782c916342/Tables/IPCC_table_A1#L915-L934
This would likely get most of the CMIP3 variables matched up well

Matching on standard names does however incur some problems - e.g. 'area_fraction' in the CMIP5 provenance

Yes, this will be a challenge for some of the more generic variables, such as the percentage cover variables, which most often don't change in the physics realms.

e generic variables, such as the percentage cover variables, which most often don't change in the physics realms.

The fracturing of tables e.g.
  "Eday" ->
                            "LPday",
                            "APday",
                            "OPday",
                            "LIday"

Make a straight forward mapping using just the standard name is more difficult. I am aware that there is logic to determine these etc. and will be looked into at a later point.
Since the providence is based on the table -> I would need to create a table mapping from A1,...An to each of these values for CMIP3 before this is usable.

@taylor13
The mismatches occur in two groups.  The following is just an information dump, and might have some trivial answers but I have yet to figure them out.
CMIP3 Dataset : Missing table mapping:

      Table A1: --all vars--
      Table O1: --all vars--
      Table A5: --all vars--
      Table A2: --all vars--
      Table A3: --all vars--
      Table A4: --all vars--

CMIP5 Dataset :Missing table mapping

      Table cf3hr: --all vars--
      Table grids: --all vars--
      Table cfSites: --all vars--
      Table OImon: --all vars--
      Table aero: --all vars--
      Table cfOff: --all vars--
      Table cfMon: --all vars--
      Table cfDay: --all vars--

CMIP5: Table exists, however the variable does not seem to in the mapped tables (based on the existing provenance tags.

      Table Lmon: treeFrac, grassFrac, shrubFrac, cropFrac, pastureFrac, bareSoilFrac, residualFrac, burntArea, cVeg, lai, fHarvest, nbp, landCoverFrac, treeFracPrimDec, treeFracPrimEver, treeFracSecDec, treeFracSecEver, c3PftFrac, c4PftFrac

      Table Oclim: zfull
      Table 3hr: pr, tas, hfls, hfss, rlus, rsus, uas, vas, huss, tslsi, tso, mrro, clt
      Table fx: orog, deptho, volcello, sftof, basin, hfgeou

      Table Oyr: dissic, dissoc, zooc, bacc, detoc, calc, arag, phydiat, phycalc, phypico, phymisc, zmicro, zmeso, zoocmisc, talk, ph, no3, nh4, dfe, chldiat, chlcalc, chlpico, chlmisc, pon, pop, bfe, phyn, phyp, phyfe, physi, dms, co3, pp, expc, expn, expp, expcfe, expsi, expcalc, exparag, pdi, dpocdtcalc, dpocdtpico, zfull
      Table Amon: tas, ts, tasmin, tasmax, uas, vas, hurs, huss, pr, hfls, hfss, rlus, rsus, rsdscs, rsuscs, rsdt, rsut, rlut, rlutcs, clt, fco2antt, cl, mc, ta, ua, va, hus, hur, wap, zg, tro3, tro3Clim, co2, ch4, ch4Clim, n2o, n2oClim, pfull, tasAdjust, tsAdjust

      Table day: huss, tasmin, tasmax, tas, pr, tossq, tos, omldamax, rhs, rhsmin, rhsmax, snc, clt, tslsi, mrro, uas, vas, hfls, hfss, rlus, rsus, rlut, usi, vsi, sic, sit, ta, hur, hus, wap, va, ua
      Table 6hrPlev: ua, va, ta
      Table Omon: zoocmisc, ph, thkcello, omldamax, omlmax, hfnorth, pr, zfull

Please note that "--all vars--" indicates all variables under the respective table.

My extracted mapping using can be found here: https://github.com/PCMDI/mip-cmor-tables/blob/variables/src/variables/table_6_to_6plus.json

@wolfiex CMIP3/5 matching, nice! I had assumed this was a job for another time.
The direct match will likely be using the standard_name attribute, e.g.

standard name
Just to clarify, that this is what I a using (incase it was not explicitly mentioned earlier).

Since the providence is based on the table -> I would need to create a table mapping from A1,...An to each of these values for CMIP3 before this is usable.

@wolfiex as noted during our chat this am, some of this info is available on the https://pcmdi.llnl.gov/mips/cmip3/variableList.html site. This breakdown the A1 table to A1a, A1b, ..., A1f.
Less relevant is the original AMIP1 (~CMIP1) request, which can be viewed at https://pcmdi.llnl.gov/mips/amip/OUTPUT/AMIP2/outlist.html. Note there was no CMOR, and no standard format in AMIPx or CMIP1/2, so these will not likely be easy to reference

Outlining the format of what is contained in the root dir of this repo (as identified in the google slide):

[x]  Tables/
[x]  src/
[ ]  MIP_calendar.json
[ ]  MIP_esgf_node_id
[x]  MIP_frequency
[x]  MIP_institution_id (ROR refs)
[x]  MIP_license
[ ]  MIP_projects (to CVs URLs, e.g. CMIP6Plus_CVs, input4MIPs_CVs, etc) <- test suite
[ ]  MIP_src_type
[x]  MIP_realm
[ ]  MIP_regions (CF or CORDEX)
[x]  MIP_variables.json (master var list)
[x]  .gitignore
[x]  LICENSE-CC-BY
[x]  README.md

Other *.ipynb files go into src/ subdir

Remaining tasks:

[ ] locate missing items
[ ] wip/update all version information to reflect the current pre-tag release.

@durack1 @matthew-mizielinski  Happy to merge in current state.


Remove our dependency on any CRT--AppX or forwarders

The upgrade to Microsoft.UI.Xaml 2.8 was the last piece we needed to
break our dependency on the App CRT and any CRT whatsoever.

For @awakecoding, the unpackaged distribution looks like this now:

This is quite the sight! Windows Terminal is becoming much cleaner, with a lot less individual files for a working distribution!

This one is not exactly suitable for backport to 1.17, as unfortunately that one's still stuck on MUX 2.7 ... unless we backport the big scary UI framework update too :P


Add a build step to the mocha tests for easier cross-package integration

R: @jeffposnick @addyosmani @gauntface
This PR does a few primary things:

Replaces all instances of workbox.. with just , which is imported at the top of the file and bundled into the test build.
Fixes up some inconsistencies that I noticed while doing my replacements in (1).
Includes part of @prateekbh's fix to the background sync queue initialization from IDB (without it some additional tests wouldn't pass).

Individual responses inline, general responses below:

1.) The reason for it(), describe(), before() and after() all receiving functions rather than fat arrow functions is that Mocha does some weird binding to the functions to add methods like this.timeout() etc. I'd keep this functionality in rather than block it on fat arrow syntax.

Yeah, I'm aware of this (and annoyed by it), and I didn't convert function to => anywhere this was referenced in a describe or it block. The reason I made the change in the first place is we were being inconsistent with usage, so I standardized on =>. I can standardize on function if that's preferred, but I think we should be consistent.

2.)  I like the support of bundled test files, but I don't want the entire test suite requiring a single bundle file. The reason for this is that these tests are no longer testing the final builds which has caught subtle issues in the past (when we release we run the tests against dev and prod versions)

I'm not sure I understand the issue here. Couldn't we run the unit tests in prod mode to test that behavior, and then don't the webdriver tests check the final builds?
Also, if we're going to be doing away with individual package builds in the future, won't this be a non-issue?

@philipwalton
For 1 - yes go for consistency and yes to using function() everywhere, just to avoid weirdness if anyone tries to use describe() etc with timeouts or retries.
For 2 - We aren't doing away with package builds in the future, UMD will still be bundles of the packages, they just won't bundle the shared dependencies and how are they are used / served will be different. All of this is run through webdriver tests. The CLI and Build tests which are "closer to integration tests" will catch some errors, but the individual packages still catch different issues between the build types.
For now I'd rather add support to bundled tests along side the current testing approach and not replace it with bundling (i.e. forcing our tests to be bundled).
I would be happy to look at our testing infra in a different light for V3 but wouldn't want to make this big of a change at this point.

For now I'd rather add support to bundled tests along side the current testing approach and not replace it with bundling (i.e. forcing our tests to be bundled).

Ok, I think this is still possible. AFAICT I don't think any of my changes prohibit this. If you'd like me to revert any of the tests I've converted to bundling, let me know as I'm not sure which ones in particular you're concerned about.
Otherwise I think I've made all the requested changes, so pending the above we should be able to merge.

@philipwalton workbox-precaching is the only one I would like to be unbundled (largely because I have to maintain it and the un-bundling has helped me catch bugs in my tests). Will leave the other modules to @jeffposnick's discretion as the main author and fan of es2015 modules ;)
On a side not, I'd be curious if any of the browser tests could just take advantage of script type="module". But that's for a future exploration and definitely not for this.

@gauntface I reverted all test changes to workbox-precaching and the tests still pass, so I think we should be good. PTAL.

(I'm good if @gauntface is good.)

Ahh, yes, sorry!
I updated the code to just use bundling for all modules (including precache), but since precache doesn't have any import statements, the bundling process is effectively just a concat, so it should be functionally identical to how it was before.

@philipwalton what are your plans for this?

@gauntface Just waiting for an LGTM :)

The service worker tests are running on precache.

aren't*

Re-reverted the test files in precaching.


Починить CTA в тестовом приложении

:tada: This issue has been resolved in version 7.32.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Delete Extra Team Migration

Turns out I'm a goofus and had two migrations for the same thing. Let's fix that...

Could not review pull request. It may be too large, or contain no reviewable changes.


[ruff] Add never-union rule to detect redundant typing.NoReturn and typing.Never

Summary
Adds a rule to detect unions that include typing.NoReturn or typing.Never. In such cases, the use of the bottom type is redundant.
Closes https://github.com/astral-sh/ruff/issues/9113.
Test Plan
cargo test

This should be fixable but isn't trivial, working on it separately.

Interesting notes in the ecosystem e.g.

XXX: no return should be needed with NoReturn type (type-checker bug?)

ref


package.json: Acknowledge PR from Yuyi

Giving credit where credit is due

Coverage remained the same at 95.977% when pulling 112507203a01b3b66122af844d26eb3f2953add3 on rhoggSugarcrm-patch-1 into 89e88e646195bd8d864c00f09d298f8a1303d0eb on master.

Coverage remained the same at 95.977% when pulling 112507203a01b3b66122af844d26eb3f2953add3 on rhoggSugarcrm-patch-1 into 89e88e646195bd8d864c00f09d298f8a1303d0eb on master.


Handle networking failures when downloading

While reviewing #16 I ran the ETL process and the network dropped out which caused one of the downloads to fail (see log in PR comments).
It may be worth the code being more robust and retrying the download a (small) number of times on network failures.

Duplicate


Logging can't be associated to transaction

https://github.com/ONSdigital/sdx-downstream/blob/develop/app/helpers/ftp_helper.py#L20
Logging in this function only mentions file names which contain collection exercise and sequence numbers,  but give no context for the transaction this was associated with.
As we scale and the logs become busier, it will be important to know exactly which transactions have been processed downstream.

Has been superseded by new sdxftp library which logs the tx_id as required


Show error messages for regex failures

When an invalid regex is given, show a more helpful error than "Error: Couldn't parse regex".

Nice idea, it should be quite possible to pass the regex compilation error through from the regex library to show in the UI


Container/Instance relationship

Goal
Associate an Instance with a Container, such that when a Container is deleted the Instance dies with it.
Implementation
In remove(), read custom attribute children of Container and remove contained members, only if the member has an equivalent parentContainer attribute with itself as value. This would enable a user to "disconnect" the relationship and not have their instances accidentally deleted.
Motivation
Loading a mindbender.rig automatically creates a mindbender.animation Instance.

For reference, see apt-get autoremove for implementation details. It associates automatic actions performed whilst installing a package, in order to automatically remove them when removing the original package.


Preview window and zoom rendering issue.

VSCode Version: Code 1.5.3 (5be4091987a98e3870d89d630eb87be6d9bafd27, 2016-09-22T08:50:42.185Z)
OS Version: Windows_NT ia32 10.0.14393

Steps to Reproduce:

Use the zoom feature on the editor (Ctrl/=)
Open the Preview Window.
The Preview window will not open zoomed. It will only show as much text as is visible in the editor window. Using the zoom hot keys causes the Preview Window to jump to the correct zoom.
If you open a second Preview Window by clicking on a link the new Preview Window is correctly zoomed. However if you close the second Preview window the firs one reverts to its original unzoomed state.

This is an electron bug: https://github.com/electron/electron/issues/7375
@jrieken fyi

dup of #5745


ARROW-11581: [Packaging][C++] Formalize distribution through vcpkg

The actual work is done in https://github.com/microsoft/vcpkg/pull/17975; this PR just adds a copy of the arrow version 4.0.0 vcpkg port files under dev/tasks/vcpkg-port.

@ianmcook Does this PR need finishing up?
Also cc @assignUser @raulcd

@ianmcook @kou Does it make sense to keep this PR open?

Probably not, but I do think it makes sense to keep the port files in the arrow repo. I will open another PR once the 9.0.0 bump in vcpkg is done.

I think that we can close this pull request.
If we need a nightly job for vcpkg like Homebrew's one, we can rework this based on the latest vcpkg arrow port as @assignUser said.


LITE GFX

A text editor is just as hard to make in a terminal as it is a GUI, so why not get all GUI together?
We need to keep it platform-agnostic, so the GUI will be accessed through a custom library
that we can write for each platform we'd like to support (like LensorOS in the future).
It also allows us to focus on getting something up and running on existing operating
systems like Windows and Linux using a library for the library, like SDL2.
I presume that, along with the graphical changes, buffers and file editing will work their way into this PR.

After some thought, I think the best way to go about it may be to have an association list in the list environment that is checked against for lower-to-uppercase conversions.
Something like LOWER-UPPER-CONVERSIONS-ALIST with a default value that matches US QWERTY keyboards (eventually we could add in helper functions to set it to common layouts in the standard LISP library).


Add disable_tpm_sensor

This commit adds the disable_tpm_sensor such that its IPMI sensor name will be 0xCC04. 0xCC04 is made up of 1-byte of the sensor type (0xCC) plus one byte of the sub-type (0x04),

@Erich-Hauptli can you please review this, as well ?
I just manually added this new "disable_tpm_sensor" in the same format as the existing "tpm_required_sensor", with I think the subtle tweaks needed to make it work.
I hope it's ok if I just manually made this change, rather than having you do it via server-wiz

This change looks fine to me.


compile error

I got ``undefined method `[]' for nil:NilClass''
ERROR Jekyll::Img: Jekyll::Img died with a /var/lib/gems/3.0.0/gems/jekyll_plugin_support-0.7.0/lib/jekyll_plugin_support.rb:163:in `render': undefined method `[]' for nil:NilClass (NoMethodError)
        from /var/lib/gems/3.0.0/gems/liquid-4.0.4/lib/liquid/block_body.rb:103:in `render_node_to_output'
        from /var/lib/gems/3.0.0/gems/liquid-4.0.4/lib/liquid/block_body.rb:91:in `render'
        from /var/lib/gems/3.0.0/gems/liquid-4.0.4/lib/liquid/template.rb:206:in `block in render'
        from /var/lib/gems/3.0.0/gems/liquid-4.0.4/lib/liquid/template.rb:240:in `with_profiling'
        from /var/lib/gems/3.0.0/gems/liquid-4.0.4/lib/liquid/template.rb:205:in `render'
        from /var/lib/gems/3.0.0/gems/liquid-4.0.4/lib/liquid/template.rb:218:in `render!'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:39:in `block (3 levels) in render!'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:59:in `measure_counts'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:38:in `block (2 levels) in render!'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:63:in `measure_bytes'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:37:in `block in render!'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:70:in `measure_time'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:36:in `render!'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/renderer.rb:129:in `render_liquid'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/renderer.rb:80:in `render_document'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/renderer.rb:63:in `run'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/site.rb:572:in `render_regenerated'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/site.rb:557:in `block (2 levels) in render_docs'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/site.rb:556:in `each'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/site.rb:556:in `block in render_docs'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/site.rb:555:in `each_value'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/site.rb:555:in `render_docs'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/site.rb:210:in `render'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/site.rb:80:in `process'
        from /var/lib/gems/3.0.0/gems/jekyll-watch-2.2.1/lib/jekyll/watcher.rb:128:in `process'
        from /var/lib/gems/3.0.0/gems/jekyll-watch-2.2.1/lib/jekyll/watcher.rb:64:in `block in listen_handler'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/event/config.rb:28:in `call'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/event/processor.rb:117:in `block in _process_changes'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/thread.rb:26:in `rescue_and_log'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/event/processor.rb:116:in `_process_changes'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/event/processor.rb:25:in `block in loop_for'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/event/processor.rb:20:in `loop'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/event/processor.rb:20:in `loop_for'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/event/loop.rb:85:in `_process_changes'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/event/loop.rb:51:in `block in start'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/thread.rb:26:in `rescue_and_log'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/thread.rb:18:in `block in new'

  Liquid Exception: exit in /users/a1a1a11a/fastscp-website/_posts/2021-10-01-segcache.md
                    ------------------------------------------------
      Jekyll 4.3.2   Please append `--trace` to the `serve` command
                     for any additional information or backtrace.
                    ------------------------------------------------
/var/lib/gems/3.0.0/gems/jekyll_plugin_support-0.7.0/lib/jekyll_plugin_support.rb:168:in `exit': exit (SystemExit)
        from /var/lib/gems/3.0.0/gems/jekyll_plugin_support-0.7.0/lib/jekyll_plugin_support.rb:168:in `rescue in render'
        from /var/lib/gems/3.0.0/gems/jekyll_plugin_support-0.7.0/lib/jekyll_plugin_support.rb:148:in `render'
        from /var/lib/gems/3.0.0/gems/liquid-4.0.4/lib/liquid/block_body.rb:103:in `render_node_to_output'
        from /var/lib/gems/3.0.0/gems/liquid-4.0.4/lib/liquid/block_body.rb:91:in `render'
        from /var/lib/gems/3.0.0/gems/liquid-4.0.4/lib/liquid/template.rb:206:in `block in render'
        from /var/lib/gems/3.0.0/gems/liquid-4.0.4/lib/liquid/template.rb:240:in `with_profiling'
        from /var/lib/gems/3.0.0/gems/liquid-4.0.4/lib/liquid/template.rb:205:in `render'
        from /var/lib/gems/3.0.0/gems/liquid-4.0.4/lib/liquid/template.rb:218:in `render!'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:39:in `block (3 levels) in render!'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:59:in `measure_counts'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:38:in `block (2 levels) in render!'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:63:in `measure_bytes'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:37:in `block in render!'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:70:in `measure_time'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:36:in `render!'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/renderer.rb:129:in `render_liquid'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/renderer.rb:80:in `render_document'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/renderer.rb:63:in `run'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/site.rb:572:in `render_regenerated'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/site.rb:557:in `block (2 levels) in render_docs'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/site.rb:556:in `each'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/site.rb:556:in `block in render_docs'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/site.rb:555:in `each_value'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/site.rb:555:in `render_docs'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/site.rb:210:in `render'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/site.rb:80:in `process'
        from /var/lib/gems/3.0.0/gems/jekyll-watch-2.2.1/lib/jekyll/watcher.rb:128:in `process'
        from /var/lib/gems/3.0.0/gems/jekyll-watch-2.2.1/lib/jekyll/watcher.rb:64:in `block in listen_handler'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/event/config.rb:28:in `call'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/event/processor.rb:117:in `block in _process_changes'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/thread.rb:26:in `rescue_and_log'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/event/processor.rb:116:in `_process_changes'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/event/processor.rb:25:in `block in loop_for'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/event/processor.rb:20:in `loop'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/event/processor.rb:20:in `loop_for'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/event/loop.rb:85:in `_process_changes'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/event/loop.rb:51:in `block in start'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/thread.rb:26:in `rescue_and_log'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/thread.rb:18:in `block in new'
/var/lib/gems/3.0.0/gems/jekyll_plugin_support-0.7.0/lib/jekyll_plugin_support.rb:163:in `render': undefined method `[]' for nil:NilClass (NoMethodError)
        from /var/lib/gems/3.0.0/gems/liquid-4.0.4/lib/liquid/block_body.rb:103:in `render_node_to_output'
        from /var/lib/gems/3.0.0/gems/liquid-4.0.4/lib/liquid/block_body.rb:91:in `render'
        from /var/lib/gems/3.0.0/gems/liquid-4.0.4/lib/liquid/template.rb:206:in `block in render'
        from /var/lib/gems/3.0.0/gems/liquid-4.0.4/lib/liquid/template.rb:240:in `with_profiling'
        from /var/lib/gems/3.0.0/gems/liquid-4.0.4/lib/liquid/template.rb:205:in `render'
        from /var/lib/gems/3.0.0/gems/liquid-4.0.4/lib/liquid/template.rb:218:in `render!'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:39:in `block (3 levels) in render!'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:59:in `measure_counts'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:38:in `block (2 levels) in render!'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:63:in `measure_bytes'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:37:in `block in render!'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:70:in `measure_time'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:36:in `render!'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/renderer.rb:129:in `render_liquid'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/renderer.rb:80:in `render_document'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/renderer.rb:63:in `run'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/site.rb:572:in `render_regenerated'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/site.rb:557:in `block (2 levels) in render_docs'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/site.rb:556:in `each'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/site.rb:556:in `block in render_docs'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/site.rb:555:in `each_value'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/site.rb:555:in `render_docs'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/site.rb:210:in `render'
        from /var/lib/gems/3.0.0/gems/jekyll-4.3.2/lib/jekyll/site.rb:80:in `process'
        from /var/lib/gems/3.0.0/gems/jekyll-watch-2.2.1/lib/jekyll/watcher.rb:128:in `process'
        from /var/lib/gems/3.0.0/gems/jekyll-watch-2.2.1/lib/jekyll/watcher.rb:64:in `block in listen_handler'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/event/config.rb:28:in `call'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/event/processor.rb:117:in `block in _process_changes'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/thread.rb:26:in `rescue_and_log'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/event/processor.rb:116:in `_process_changes'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/event/processor.rb:25:in `block in loop_for'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/event/processor.rb:20:in `loop'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/event/processor.rb:20:in `loop_for'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/event/loop.rb:85:in `_process_changes'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/event/loop.rb:51:in `block in start'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/thread.rb:26:in `rescue_and_log'
        from /var/lib/gems/3.0.0/gems/listen-3.8.0/lib/listen/thread.rb:18:in `block in new'

Interesting. Please show the tag invocation that caused the problem.
Also, what version are you running? I only support the current version, which is v0.1.5:
$ gem info jekyll_img
*** LOCAL GEMS ***
jekyll_img (0.1.5, 0.1.4, 0.1.3, 0.1.2, 0.1.1, 0.1.0)
Author: Mike Slinn
Homepage: https://www.mslinn.com/jekyll_plugins/jekyll_img.html
License: MIT
Installed at (0.1.5): /home/mslinn/.rbenv/versions/3.1.0/lib/ruby/gems/3.1.0
(0.1.4): /home/mslinn/.rbenv/versions/3.1.0/lib/ruby/gems/3.1.0
(0.1.3): /home/mslinn/.rbenv/versions/3.1.0/lib/ruby/gems/3.1.0
(0.1.2): /home/mslinn/.rbenv/versions/3.1.0/lib/ruby/gems/3.1.0
(0.1.1): /home/mslinn/.rbenv/versions/3.1.0/lib/ruby/gems/3.1.0
(0.1.0): /home/mslinn/.rbenv/versions/3.1.0/lib/ruby/gems/3.1.0
Provides a Jekyll tag that generates images.

Mike

Thank you for the response!
*** LOCAL GEMS ***

jekyll_img (0.1.5)
    Author: Mike Slinn
    Homepage: https://www.mslinn.com/jekyll_plugins/jekyll_img.html
    License: MIT
    Installed at: /var/lib/gems/3.0.0

    Provides a Jekyll tag that generates images.

The error can be reproduced using the demo, on a newly installed Ubuntu22.04 system.

I need to see the invocation. For example:
{% img src="blah.png" %}

{% img src="diagram_s3fifo.svg" %}
is it possible that svg is not supported?

Correct, svg is not supported, for historical reasons ... which are no longer valid.
The plugin should not generate a stack trace when it has a problem.
The docs do not discuss why  elements are generated (they are fallback formats for older browsers)

I will address the above in separate issues.

Hi Mike, Thank you for your prompt response and help! I am happy to test the new version once they are ready. :)

I released v0.1.6, and updated the documentation accordingly.
SVG format is not currently supported because it might not make sense for an image format fallback from/to SVG. That said, image fallback may not be a useful feature for everyone. Please provide your remarks about that topic in issue #5.
To update your Jekyll website to the current version, change to your website directory and type:
$ bundle update

Look for a message stating that jekyll_img v0.1.6 was installed before testing.

Hi Mike, Thank you! This is great work! I did not know it was for webp fallback (I was looking for a plugin that allows me to better align and size the images). I just tested with a webp converted from gif, but it still throws the error.
ERROR Jekyll::Img: Jekyll::Img died with a /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll_plugin_support-0.7.0/lib/jekyll_plugin_support.rb:163:in `render': undefined method `[]' for nil:NilClass (NoMethodError)

      @mode = @config['env']['JEKYLL_ENV'] || 'development'
                            ^^^^^^^^^^^^^^
        from /usr/local/rvm/gems/ruby-3.2.2/gems/liquid-4.0.4/lib/liquid/block_body.rb:103:in `render_node_to_output'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/liquid-4.0.4/lib/liquid/block_body.rb:91:in `render'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/liquid-4.0.4/lib/liquid/template.rb:206:in `block in render'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/liquid-4.0.4/lib/liquid/template.rb:240:in `with_profiling'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/liquid-4.0.4/lib/liquid/template.rb:205:in `render'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/liquid-4.0.4/lib/liquid/template.rb:218:in `render!'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:39:in `block (3 levels) in render!'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:59:in `measure_counts'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:38:in `block (2 levels) in render!'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:63:in `measure_bytes'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:37:in `block in render!'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:70:in `measure_time'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:36:in `render!'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/renderer.rb:129:in `render_liquid'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/renderer.rb:80:in `render_document'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/renderer.rb:63:in `run'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/site.rb:572:in `render_regenerated'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/site.rb:557:in `block (2 levels) in render_docs'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/site.rb:556:in `each'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/site.rb:556:in `block in render_docs'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/site.rb:555:in `each_value'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/site.rb:555:in `render_docs'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/site.rb:210:in `render'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/site.rb:80:in `process'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/command.rb:28:in `process_site'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/commands/build.rb:65:in `build'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/commands/build.rb:36:in `process'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/command.rb:91:in `block in process_with_graceful_fail'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/command.rb:91:in `each'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/command.rb:91:in `process_with_graceful_fail'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/commands/serve.rb:86:in `block (2 levels) in init_with_program'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/mercenary-0.4.0/lib/mercenary/command.rb:221:in `block in execute'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/mercenary-0.4.0/lib/mercenary/command.rb:221:in `each'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/mercenary-0.4.0/lib/mercenary/command.rb:221:in `execute'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/mercenary-0.4.0/lib/mercenary/program.rb:44:in `go'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/mercenary-0.4.0/lib/mercenary.rb:21:in `program'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/exe/jekyll:15:in `<top (required)>'
        from /usr/local/rvm/gems/ruby-3.2.2/bin/jekyll:32:in `load'
        from /usr/local/rvm/gems/ruby-3.2.2/bin/jekyll:32:in `<main>'

  Liquid Exception: exit in /workspaces/myblog/_posts/2021-04-01-segcache.md
                    ------------------------------------------------
      Jekyll 4.3.2   Please append `--trace` to the `serve` command
                     for any additional information or backtrace.
                    ------------------------------------------------
/usr/local/rvm/gems/ruby-3.2.2/gems/jekyll_plugin_support-0.7.0/lib/jekyll_plugin_support.rb:168:in `exit': exit (SystemExit)
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll_plugin_support-0.7.0/lib/jekyll_plugin_support.rb:168:in `rescue in render'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll_plugin_support-0.7.0/lib/jekyll_plugin_support.rb:148:in `render'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/liquid-4.0.4/lib/liquid/block_body.rb:103:in `render_node_to_output'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/liquid-4.0.4/lib/liquid/block_body.rb:91:in `render'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/liquid-4.0.4/lib/liquid/template.rb:206:in `block in render'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/liquid-4.0.4/lib/liquid/template.rb:240:in `with_profiling'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/liquid-4.0.4/lib/liquid/template.rb:205:in `render'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/liquid-4.0.4/lib/liquid/template.rb:218:in `render!'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:39:in `block (3 levels) in render!'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:59:in `measure_counts'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:38:in `block (2 levels) in render!'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:63:in `measure_bytes'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:37:in `block in render!'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:70:in `measure_time'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:36:in `render!'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/renderer.rb:129:in `render_liquid'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/renderer.rb:80:in `render_document'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/renderer.rb:63:in `run'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/site.rb:572:in `render_regenerated'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/site.rb:557:in `block (2 levels) in render_docs'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/site.rb:556:in `each'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/site.rb:556:in `block in render_docs'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/site.rb:555:in `each_value'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/site.rb:555:in `render_docs'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/site.rb:210:in `render'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/site.rb:80:in `process'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/command.rb:28:in `process_site'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/commands/build.rb:65:in `build'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/commands/build.rb:36:in `process'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/command.rb:91:in `block in process_with_graceful_fail'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/command.rb:91:in `each'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/command.rb:91:in `process_with_graceful_fail'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/commands/serve.rb:86:in `block (2 levels) in init_with_program'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/mercenary-0.4.0/lib/mercenary/command.rb:221:in `block in execute'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/mercenary-0.4.0/lib/mercenary/command.rb:221:in `each'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/mercenary-0.4.0/lib/mercenary/command.rb:221:in `execute'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/mercenary-0.4.0/lib/mercenary/program.rb:44:in `go'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/mercenary-0.4.0/lib/mercenary.rb:21:in `program'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/exe/jekyll:15:in `<top (required)>'
        from /usr/local/rvm/gems/ruby-3.2.2/bin/jekyll:32:in `load'
        from /usr/local/rvm/gems/ruby-3.2.2/bin/jekyll:32:in `<main>'
/usr/local/rvm/gems/ruby-3.2.2/gems/jekyll_plugin_support-0.7.0/lib/jekyll_plugin_support.rb:163:in `render': undefined method `[]' for nil:NilClass (NoMethodError)

      @mode = @config['env']['JEKYLL_ENV'] || 'development'
                            ^^^^^^^^^^^^^^
        from /usr/local/rvm/gems/ruby-3.2.2/gems/liquid-4.0.4/lib/liquid/block_body.rb:103:in `render_node_to_output'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/liquid-4.0.4/lib/liquid/block_body.rb:91:in `render'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/liquid-4.0.4/lib/liquid/template.rb:206:in `block in render'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/liquid-4.0.4/lib/liquid/template.rb:240:in `with_profiling'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/liquid-4.0.4/lib/liquid/template.rb:205:in `render'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/liquid-4.0.4/lib/liquid/template.rb:218:in `render!'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:39:in `block (3 levels) in render!'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:59:in `measure_counts'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:38:in `block (2 levels) in render!'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:63:in `measure_bytes'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:37:in `block in render!'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:70:in `measure_time'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/liquid_renderer/file.rb:36:in `render!'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/renderer.rb:129:in `render_liquid'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/renderer.rb:80:in `render_document'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/renderer.rb:63:in `run'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/site.rb:572:in `render_regenerated'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/site.rb:557:in `block (2 levels) in render_docs'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/site.rb:556:in `each'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/site.rb:556:in `block in render_docs'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/site.rb:555:in `each_value'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/site.rb:555:in `render_docs'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/site.rb:210:in `render'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/site.rb:80:in `process'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/command.rb:28:in `process_site'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/commands/build.rb:65:in `build'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/commands/build.rb:36:in `process'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/command.rb:91:in `block in process_with_graceful_fail'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/command.rb:91:in `each'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/command.rb:91:in `process_with_graceful_fail'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/lib/jekyll/commands/serve.rb:86:in `block (2 levels) in init_with_program'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/mercenary-0.4.0/lib/mercenary/command.rb:221:in `block in execute'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/mercenary-0.4.0/lib/mercenary/command.rb:221:in `each'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/mercenary-0.4.0/lib/mercenary/command.rb:221:in `execute'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/mercenary-0.4.0/lib/mercenary/program.rb:44:in `go'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/mercenary-0.4.0/lib/mercenary.rb:21:in `program'
        from /usr/local/rvm/gems/ruby-3.2.2/gems/jekyll-4.3.2/exe/jekyll:15:in `<top (required)>'
        from /usr/local/rvm/gems/ruby-3.2.2/bin/jekyll:32:in `load'
        from /usr/local/rvm/gems/ruby-3.2.2/bin/jekyll:32:in `<main>'

I confirm that I am using 0.1.6, did I miss something?

Hmm, what do you get when you run the following?
$ gem info jekyll_plugin_support

Also, please show your Gemfile and Gemfile.lock.

BTW, I noticed the following are not in your Gemfile's :jekyll_plugins section. Not sure if they are supposed to be in that section or not.
gem "jekyll-paginate"
gem "jekyll-sitemap"
gem "jekyll-toc"

oh, it was not intentional (I am new to jekyll and copied things from various places), I should move them into the block. Thank you for catching it! :)

I addressed the problem in jekyll_plugin_support and also suppressed the stack trace that should have been suppressed previously.
Please run:
$ bundle update

... and verify that jekyll_plugin_support 0.7.1 is shown. Then try running your Jekyll website again.

Thank you! I still get an error
Jekyll::Img died with a 'undefined method `key?' for nil:NilClass' in 'render_node_to_output' on line 103 of /usr/local/rvm/gems/ruby-3.2.2/gems/liquid-4.0.4/lib/liquid/block_body.rb

Alright, I pushed another version.  bundle update again and please retry.


Bug bounty test - PLEASE DO NOT APPROVE. dssmuv

Bug bounty test - PLEASE DO NOT APPROVE. dssmuv

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


stable null safety release

This is now ready for release and will unblock publishing stable versions of other packages that depend on it.

@davidmorgan


migrations: remove dead code in gitea uploader

When migrating, g.issues is a map with all issues created during the
migration. If an issue is not found in g.issues when inserting a
comment or a review, it cannot exist in the database and trying to get
it via GetIssueByIndex() will always fail and return an error.

I think g.issues is used as a cache. If we want to support incremental migration, then we need these code.

It is dead code because there is no codepath that leads to it. There is no test that exist or could be written that would lead to these lines. If incremental migrations do not require modifying the migrateRepository functions, issues are handled first and the cache is populated in full. If incremental migrations use a logic different from migrateRepository the Gitea uploader will need to be refactored entirely. Or something else implemented from scratch. I can't imagine a single scenario where this dead code comes back to life. Can you?

It may be helpful to add a warning to the top of the functions involved stating that all of the issues need to be created before this is called occurs.
The code paths here are somewhat convoluted and complex (likely necessarily so) but we need to be clearer in the comments about what each function is expecting to have already happened.
I can easily imagine some new API coming out whereby people get the issue and all of its comments in one go - the refs would then probably break

This is totally wrong. CreateIssues and CreateComments maybe invoked

I'm confused about what is wrong. Could you please explain? Is the proposed change wrong? Or am I wrong in thinking that the gitea uploader CreateComments function is only called from the migrateRepository function?

It may be helpful to add a warning to the top of the functions involved stating that all of the issues need to be created before this is called occurs.
The code paths here are somewhat convoluted and complex (likely necessarily so) but we need to be clearer in the comments about what each function is expecting to have already happened.
I can easily imagine some new API coming out whereby people get the issue and all of its comments in one go - the refs would then probably break

The only thing I was able to come up with is the following:
//
// The migrateRepository function determines the context in which this method is invoked.
// It relies on other methods being called first, to populate caches, update the git
// repository, etc. If it was to be called independently, care must be taken to fulfill
// its expectations.
//
// CreateReviews create pull request reviews
func (g *GiteaLocalUploader) CreateReviews(reviews ...*base.Review) error {

This is very vague and not useful, I'm afraid. I can't figure out how to be more specific without being so specific that the comment will likely become obsolete as soon as the slightest change is introduced in the logic. For instance at the moment it  relies on CreatePullRequests updating the git repository to create references to pull requests and, if there is a fork, fetching the commits from the fork into the repository.
Do you have a suggestion?

Do you have a suggestion?

- // CreateReviews create pull request reviews
+ // CreateReviews create pull request reviews of currently migrated issues

The CreateIssues is already called before hand which already inserts the issues into g.issues, so something along the lines of currently imported issues or currently known issues, no need to go big, otherwise the code should be self-explanatory.

Do you have a suggestion?

- // CreateReviews create pull request reviews
+ // CreateReviews create pull request reviews of currently migrated issues

The CreateIssues is already called before hand which already inserts the issues into g.issues, so something along the lines of currently imported issues or currently known issues, no need to go big, otherwise the code should be self-explanatory.

That makes perfect sense, thanks for the advice. I added a commit with your suggestion :+1:

The CI is stuck with:
Initialized empty Git repository in /drone/src/.git/

+ git fetch origin +refs/heads/main:


GoSleep! UX improvements

Even with the new update, the boot time is very high. This can lead to you holding up a race if you forget to turn them on.
It might be possible to reduce power consumption to the point where the units don't need to be powered down. I suggest that a mode could be activated (by way of some button press, perhaps both buttons at once) to enter "standby mode".
In standby mode, the HDZero radios and OLED as powered down, and there could be additional firmware actions which reduce power consumption of the MCU. Fans are disabled or run at minimum. Standby mode ends as soon as any button is pressed.
Standby mode could also be entered automatically after a period of no signal, similar to the current OLED-off function.

Edit
Since this issue was created, a new function "GoSleep!" has been added to the menu. I've updated this issue to represent my suggestions for UX changes to GoSleep! See comment https://github.com/hd-zero/hdzero-goggle/issues/223#issuecomment-1598843309

@robhaswell a Go Sleep! function recently added and I have submit PR #268 with some improvements.
In your view of Standby mode... should the goggle attempt to immediately return to Live view on resume? or would you prefer it to return to the menu with "Go Sleep!" still highlighted?
Anyone else wish to weight in?
Thank you,
-p

As of 9.1.0-rc2 the Go Sleep! function appears to provide the basic hardware sleep functionality needed to resolve this issue. However, performance and usability are lacking.
Outstanding items I see are:
-make Go Sleep! function independent of menu.
-add logic for corded long left + right button press to actuate Go Sleep! function.
Sound correct?
If so maybe @robhaswell can update the title for this issue in a few days?

I updated my googles to the lastet version and the GoSleep is cool. However some quick acess for this is needed.
Either both buttons or some kind of double click on the rec-button to send them to sleep.
Optional I think something like one beep every 30sec like on Orqa googles would be cool, so you are reminded that the googles are still powered on.


refactor: move child directories to unique path

denops/@ddu-sources is the shared directory for ddu-sources.
It is better not to put files with conflicting names there.
Because it will cause problems if users use plugin managers that merge vim-plugins.

thx!


Migrate Azure to Simple Resource Class Selection

Description of your changes

Fixes #34.
Apologies in advance reviewers for this huge and unwieldy PR. This PR:

Adds comment markers to make all providers, resources, and classes cluster scoped.
Regenerates all generated code and manifests (using https://github.com/crossplaneio/crossplane-tools/pull/7) to support cluster scoped managed resources.
Updates all controller logic to reflect that providers and managed resources are no longer namespaced, and thus they must specify which namespace their secrets live in.
I tried to keep these changes minimal but after struggling for many hours with the old SQL server code and tests I decided it would be faster to port them to the managed resource reconciler since @muvaf is hoping to bring this to v1beta1 this week.

So far I have tested:

Creating a Redis by submitting a RedisCluster that references a RedisClass.
Creating a Redis by submitting an unopinionated RedisCluster claim that falls back to using the RedisClass annotated as default.
Creating several RedisClass classes with the same label and ensuring RedisCluster claims that select those labels are allocated a random matching class.

I've also tested:

Creating a Postgres database by explicitly referencing a resource class.
Creating a storage account and container by explicitly referencing a resource class.
Creating an AKS cluster, except this is failing for reasons that seem unrelated to my changes.

I don't intend to manually test claim scheduling and defaulting logic for these kinds, because it's all the same reconciler under the hood.
I still need to:

Test the non-dynamically provisionable resources.
Figure out what's up with AKS?

Checklist

I have:

[x] Run make reviewable to ensure this PR is ready for review.
[x] Ensured this PR contains a neat, self documenting set of commits.
[ ] Updated any relevant documentation, examples, or release notes.
[ ] Updated the dependencies in app.yaml to include any new role permissions.

@hasheddan PTAL. Mostly looking for your input on this one, but I've also copied @jbw976 for his historical familiarity with the AKS and SQL Server controllers.

Also CCing @muvaf on this one, since I jumped the gun on porting the Azure database controller a little.

@hasheddan I notice the integration tests are consistently failing for this PR, but couldn't immediately determine why. Can you see a reason why this PR would break the tests?

It appears as though the deployment of the stack is failing. I can checkout this branch and test locally.

@hasheddan This is the issue I encountered when trying to test out AKS:
Message:               failed to start create operation for AKS cluster default-app-kubernetes-gnxv5: containerservice.ManagedClustersClient#CreateOrUpdate: Failure sending request: StatusCode=400 -- Original Error: Code="LinkedInvalidPropertyId" Message="Property id '' at path 'properties.agentPoolProfiles[0].vnetSubnetID' is invalid. Expect fully qualified resource Id that start with '/subscriptions/{subscriptionId}' or '/providers/{resourceProviderNamespace}/'."

Using this class:
---
apiVersion: compute.azure.crossplane.io/v1alpha2
kind: AKSClusterClass
metadata:
  name: akscluster-standard
specTemplate:
  writeConnectionSecretsToNamespace: crossplane-system
  # NOTE(negz): This field being required by resource classes is a bug. It is
  # ignored when dynamically provisioning AKS clusters.
  writeServicePrincipalTo:
    namespace: unused
    name: unused
  resourceGroupName: group-westus-1
  location: West US
  version: "1.12.8"
  nodeCount: 1
  nodeVMSize: Standard_B2s
  dnsNamePrefix: crossplane-aks
  disableRBAC: false
  providerRef:
    name: example
  reclaimPolicy: Delete

Which is https://github.com/crossplaneio/crossplane/blob/12be413b9/cluster/examples/compute/kubernetescluster/azure/resource-class.yaml updated to support simple resource class selection.

AKS cluster fixed with #37
@negz I investigated the integration tests and the issue is that it uses the alpha version of Crossplane (v0.3.0). This version does not like that stack-azure is attempting to install cluster-scoped resources. The exact error is:
crossplane: error: failed to unpack stacks: failed to walk Stack filesystem: Stack CRD "/ext-pkg/.registry/resources/azure.crossplane.io_providers.crd.yaml" must be namespaced scope

This will also presumably fail for the updates to the other stacks as well. This will need to be fixed in Crossplane (if it isn't already), then we will need to address in integration tests. Do you think it would also be wise to always use the latest master version of Crossplane instead for now? In the long-run I would like to be able to test against Crossplane versions based on the most recent declared compatible version of each stack. In the mean time, we could just run integration tests against alpha and master and make judgement calls about which of them needs to be able to pass for merge. I have bandwidth to implement this week.


Fixed events.rst Lifecycle Callbacks example

Because we know that m means month and not minutes.

Definitely you're right :) Thanks!


RELEASE: v0.12.0

Release tracking bug for v0.12.0.
Cut-off time for commits is EOD Monday 3/23.

This is the release bug to keep notes on what is happening.
If you have a feature or bug you want to tag to a future release to indicate when it will land please use the milestone.  For each release we will make sure things tagged for the milestone release and are not checked in get pinged.

Here is the CHANGES.md file for this release:
v0.12.0

Add per-phase timestamp samples (GH171)
Regex improvement (GH182)
Fix a bug in mesh network benchmarks (GH163)
Fix for running on AWS when user has a non-JSON output format
configured(GH167)
Clarify how to provide scratch disk for static VMs (GH166)
Add benchmark name, run URI to log messages (GH157)
Fix fio_benchmark to support static VMs (GH162)
Optional patch to the unix bench for 16+ core VMs (GH 135)

Release qualification and side-by-side run is in progress, ETA is tomorrow.

This release has been completed.

Thanks!  On to the next release.
Perfies - Please start tagging features and bugs you are actively working
on with the targeted milestone label.
On Wed, Mar 25, 2015 at 4:22 PM, stfeng<EMAIL_ADDRESS>wrote:

This release has been completed.
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/PerfKitBenchmarker/issues/187#issuecomment-86250736
.

--
Anthony F. Voellm (aka Tony)
Google Voice:<PHONE_NUMBER>
https://www.google.com/voice/b/0?pli=1#phones
Blog: http://perfguy.blogspot.com/


Dataset definition

Hi, I noticed in your code, the dataset contains five files.

full_graph.txt, graph.txt, train/dev/test.txt

I was wondering what's those files for respectively? I know that train/dev/test.txt is for train/dev/test, but what is graph.txt/full_graph.txt used for? The length of full_graph.txt file isn't equal to the sum of train/dev/test files' length. And what's the difference between full_graph.txt and graph.txt?
Thanks!

Hi Shihan,
For some datasets, like NELL, we don't train on all the tuples in the graph so the train set is much smaller than the graph. Also, graph.txt contains the inverse relations that we don't train the RL agent.
Full_graph if there is just the sum of train/dev. It's only used to mask out the other positive answers during inference.
Hope that clarifies your questions!
-Shehzaad


psol download in more compressed formats ?

For https://dl.google.com/dl/page-speed/psol/${NPS_VERSION}.tar.gz some servers have slow download speeds even as low as 300-650KB/s and at 112MB tar.gz file it can take a while to download. A suggestion is to offer the PSOL in other more compressed formats for smaller download size like xz or bzip2.
this is with xz and bzip2 at level 4 compression compared to original 112MB tar.gz file
-rw-r--r-- 1 root   root 511M Jan 13 15:50 <IP_ADDRESS>.tar
-rw-r--r-- 1 root   root 104M Jan 13 15:50 <IP_ADDRESS>.tar.bz2
-rw-r--r-- 1 root   root 112M Dec  1 20:59 <IP_ADDRESS>.tar.gz
-rw-r--r-- 1 root   root  69M Jan 13 15:50 <IP_ADDRESS>.tar.xz

xz format at level 6 compression
-rw-r--r-- 1 root   root 511M Jan 13 15:50 <IP_ADDRESS>.tar
-rw-r--r-- 1 root   root 104M Jan 13 15:50 <IP_ADDRESS>.tar.bz2
-rw-r--r-- 1 root   root 112M Dec  1 20:59 <IP_ADDRESS>.tar.gz
-rw-r--r-- 1 root   root  64M Jan 13 15:50 <IP_ADDRESS>.tar.xz

currently we're doing gzip at compression level 9, xz is probably a good idea for future releases if it can get us down to ~1/2 the size. thanks for the info :+1:

yeah just trying to speed up my lemp install times and this probably takes up to 1/5th of the total time :)
another idea is split up the download into 2 to 4 parts, folks can then download them in parallel too - so 64MB/4 = 16MB per part

for the parallel connections, you can use a tool like axel http://manpages.ubuntu.com/manpages/hardy/man1/axel.1.html
and do something like
axel -n 4 url

yeah i use to use axel but seems broken on centos in the past .. probably need to take another look at it as it seems to work now


Fog Exploration tied to Scene Darkness color

Expected Behavior
Fog exploration color to only be tied in to the fog exploration color setting, not multiplied by the scene darkness setting.
Current Behavior
Fog exploration color is multiplied by the scene darkness color, making it impossible to use with a scene darkness color of black.
Steps to Reproduce

Leave all settings at default except scene darkness color change to #000000
Fog Exploration shows as black so it is not usable.

Context
Normal behavior:

Scene darkness at black:

Reason for running with scene darkness at black:
Horror themed game where lighting is important and scene darkness at black gives a much more appealing visual gradient (especially with light attenuation maxed). Ideally would have a smooth gradient to whatever color is selected by the fog exploration setting.
Version
v4.0.34
Foundry VTT Version
v10.288
Operating System
Windows
Browser / App
Chrome
Game System
dnd55e
Relevant Modules
none

Don't set the Darkness Color to black: the color is multiplied on top of everything, making everything black. The multiplicative behavior is core and not PV; the interaction with the explored fog as well. PV just exposes the darkness and daylight colors in the scene settings.
I should add a warning or disallow dark colors. Choose a gray instead, for example #303030. Let me know if that solves this problem for you.

I added a warning in 4.0.55 that is displayed if the Daylight/Darkness Color is #000000.


 This pull adds exception handling to the response.

Codecov Report

Merging #11 into master will decrease coverage by 5.57%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master      #11      +/-   ##
==========================================
- Coverage   36.99%   31.41%   -5.58%
==========================================
  Files          14       14
  Lines         884      888       +4
  Branches      121      121
==========================================
- Hits          327      279      -48
- Misses        526      598      +72
+ Partials       31       11      -20

Impacted Files
Coverage Δ

modules/cdGetBitly.py
11.82% <0%> (-29.75%)
:arrow_down:

modules/cdGetBing.py
13.51% <0%> (-29.73%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 696be56...73b2361. Read the comment docs.


What's the best way to learn about changes in the Catalogue API?

Changes in METS/assets come through Goobi workflow.
Bibliographic changes (e.g., update title of work) come through Sierra.
How does DDS.new learn about descriptive metadata changes, so that it can reflect them in IIIF resources?
NB given the data DDS needs to keep to manage its own work, provision of IIIF Change Discovery API is pretty simple.

Discussed earlier with @kenoir and @jtweed - have added some further thoughts.
The Sierra adaptor can provide a firehose of change notifications.
There might be A LOT of these, so listening to them needs to be lightweight and low cost.
e.g., SNS topic, take a look at the update, evaluate whether it is worth processing.
The DDS is only interested in changes that are going to change the IIIF manifest. So bibliographic rather than admin/systems changes, and even then, only changes to fields that appear in public API, or influence public API. An update to a MARC field that doesn't get reflected in IIIF isn't a change as far as DDS is concerned.
What might the message contain?
If the message doesn't contain enough info to make the evaluation, then the DDS might end up hammering the Catalogue API very hard.

e.g., message: b12345678 has changed.
Do we have a row in the DDS db for b12345678?
If not, we'll ignore the message. Only Goobi can tell us about new digitised things. A Sierra event can't trigger a record creation in the DDS.
OK, we do have a record for b12345678.
Get b12345678 from the catalogue API.
Compare its fields with what we have. How? Did we save the catalogue API response last time so we can do a quick diff?
If not, do we need to construct the IIIF resource anyway and then see if it's different from what we have? That's effectively the same as diffing fields because the catalogue API and the eventual manifest are not themselves diffable, you have to run the logic to see if the product is different.
But now we've just gone and built a new manifest for every message - so we've done the hard work anyway. The only little benefit is that if the manifest is the same as the one we already had, don't save it to S3 or update the DB.

Optimisations

Message body says whether it's digitised, so don't even have to do a SQL EXISTS
Message body tells us something that helps us decide whether it contains a significant (for us) change. Don't know what that is yet.
Storing the catalogue API response just so that we can diff it when notified of a change is not as odd as it sounds. Keep it in S3 alongside the generated IIIF resources. This isn't every b number - just the digitised ones. It's a few hundred thousand JSON blobs. Still sounds a bit weird though. Could also store it as a JSON blob in PostgreSQL.

IIIF Collections are dynamically generated from queries to the DB so we shouldn't have cascading update issues from changes to collections. We don't have this problem in current DDS.
Other considerations

Are there any other systems that are interested in the same sort of significant changes in the Catalogue API that DDS is interested in? If so, should this service be external to the DDS? I suspect that they are currently getting that info via OAI/PMH.
Current DDS does not provide the IIIF Change Discovery API. New one can easily do so from the DDS DB data. But, it really wants to be able to consume something like that itself, for changes to descriptive metadata from the catalogue API. Without the firehose.

This sounds very brute-forcey, but it might be quicker than other alternatives.

Use catalogue API dumps from #4820
rattle through every line picking up digital locations (just string matching)
compute record hash for objects with digital locations to create a big dictionary (bnumber => hash of line string json)
get current hash dictionary via something like SELECT identifier, record_hash from manifestations where index=0
compare dictionaries and enqueue any required reprocessing as appropriate

Note - for this to work the stored hash for a b number record must be made from a string that matches the line in the dump, not the pretty-printed API HTTP response. I think that would just be the JSON re-stringified with no whitespace.

We should really be able to provide this feed by tapping the catalogue pipeline.

Addendum
Bulk reprocessing should be careful not to do unnecessary work.
We already have config for what a job should do:
https://github.com/wellcomecollection/iiif-builder/blob/master/src/Wellcome.Dds/WorkflowProcessor/RunnerOptions.cs
If we could mark a job for reprocessing but rather than a single bool flag, a set of flags for how it should be re-processed, we can do bulk manifest-only refreshes without hammering the DLCS.

Addendum
Bulk reprocessing should be careful not to do unnecessary work.
We already have config for what a job should do:
https://github.com/wellcomecollection/iiif-builder/blob/master/src/Wellcome.Dds/WorkflowProcessor/RunnerOptions.cs
If we could mark a job for reprocessing but rather than a single bool flag, a set of flags for how it should be re-processed, we can do bulk manifest-only refreshes without hammering the DLCS.


v2.0.0-PRE

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Proposal for finalized anchor endpoint/id

The issue:
We broadly use debug/state endpoint for checkpoint sync in consensus layer clients. The spec defines weak subjectivity period denouncing full sync and it's the only endpoint where the clients could request the latest state for sync. Usually finalized id is used, which leads to differences in interpretation in some cases. When a finalized epoch doesn't end with a block and has empty slots after it, some clients transition state to the end of the epoch (Lighthouse) and others don't (Teku). I don't know about other clients, it would be interesting to know other clients' approaches for this case too.
Both views look more or less legit in absence of API clarification, moreover Lighthouse approach seems more correct as it's truly the end of finalized epoch. But when we initialize client from the blank, we use anchor block and anchor state, so the block state_root should match hash_tree_root (See the spec) as a prerequisite for fork choice start. When we've transitioned for empty slots, we change the state, so block state_root (which is actually ZERO after processBlock) will not match hash_tree_root. It could be assumed that it shouldn't break anything, if it doesn't match, but until the check is in the spec and safety analysis on removal is not done, I don't feel safe removing it from the Teku code.
To sum up, when you request debugStateV2 with finalized id, you couldn't be sure that the response state will contain a state matching the block in latest_block_header.
Proposal:
We could introduce a separate id, something like finalizedanchor to get state at the moment of the last block in finalized epoch, or even better we could add a new endpoint dedicated for checkpoint sync. Weak subjectivity period sync is the most common type of sync today, and it's strange that we use debug API to get state for it. debug/state endpoint could be not very cheap for many of id inputs and doesn't sound as something that should be widely open for broad use, potentially could be overloaded with heavy queries. So a dedicated endpoint for finalized anchor state (at the moment of last block in finalized epoch) in beacon scope could be a better alternative.
Happy to get some feedback on this.

I believe the beacon api provides enough grounds for a requirement that the state is advanced to the empty slot (which is also what nimbus does):
https://github.com/ethereum/beacon-APIs/blob/d2f846e0e0d551973253df4b5341655eddf92f1d/types/primitive.yaml#L55C17-L55C115

True if the response references the finalized history of the chain, as determined by fork choice.

Fork choice doesn't know about slots.
You don't need any block to checkpoint-sync, only a state. Once you have a state, you can apply the next block to it without having the "state block" or "finalized block" available - some clients may have additional requirements but these are local to the implementation / can be removed.
If you also want to download a block, you can do so by computing its block root from the latest_block_header, patching in the state root (which you now know) like so: https://github.com/status-im/nimbus-eth2/blob/unstable/beacon_chain/spec/beaconstate.nim#L1408
You can then match the block to the state (instead of matching the state to the block).

If you also want to download a block (which in the case of an empty finalized epoch slot will be from the previous epoch), you can do so by computing its block root from the latest_block_header

Yeah, so we need 2 requests instead of one + state patching and only after that it will pass anchor validation. Doesn't it look too much for such a common task?

@zilm13 Don't you already have 2 requests? One for the block and one for the state?
With Jacek's approach (which is what Lighthouse does) you just request the state first and then the block, instead of the other way around. It's also less racy than Lighthouse's previous approach which was to request the finalized block, and then the state matching that block's state root. With our previous approach sometimes the state would end up having been pruned by the time we requested it (if it is no longer the newest finalized state).

With the state patching, you also don't need to actually modify the state, you can copy the block header and patch it

Technically, nimbus' checkpoint sync is in two parts:

download the state - this is needed to operate the beacon node protocol, process blocks etc - it's one request and it's all that's needed to start the client
backfill blocks - this is required to serve historical data per the p2p range request (but nothing else)

notably, the block on the finalized boundary is not needed for anything (as far as the protocol goes) other than p2p requests of historical data so a single request (for the state) is all that's needed to bootstrap a consensus client and start processing blocks from the network.
The way nimbus works, it also tries to backfill blocks via REST on checkpoint sync (all the ~6 months) - the boundary block is just a special case of that backfill but it could just as well be done via p2p (if the user doesn't want REST-based backfill).
fwiw, the REST backfill also addresses a grey area that current clients otherwise exploit simply because there's no enforcement - a client that hasn't backfilled is technically not in compliance with the p2p spec because it's not serving historical blocks but it is (typically) profiting from validator duties already - not a problem as long as leeching is moderate / limited to a small subset of the network but still.

@michaelsproul we use one request and it's not working for states with empty slots transitioned, so yeah, we need 2 requests and patching unless we have API for finalized anchor. I understand that it's doable, just wonder why it should be so hacky for a very common case. Plus depends on debug API with much broader usage which could be an issue for  nodes sharing it (could be misused, easier to DoS)

I understand that it's doable, just wonder why it should be so hacky for a very common case.

Just so we're clear, there is no hack here where a second download is needed - the latest_block_header approach works equally well for a slot-transitioned state and non-slot-transitioned state (see the linked code - it handles both cases) - in fact, to comply with the API, it would probably be a good idea for teku to provide a slot-transitioned state (per above spec reasoning) - we have a special case for servers like teku to handle non-transitioned states as well, but that's because we're liberal in what we accept in the interest of pragmatism.

Thank you for feedback, @michaelsproul and @arnetheduck
To sum up we will fix current behavior in Teku to provide transitioned state via debug/state/finalized and update our checkpoint sync start to be compatible with such state.
Cheers!


AutoML Code

Summary by CodeRabbit

New Features

Introduced XGBoost model training and evaluation functionality, including iterators for handling dynamic and static data.

Documentation

Updated README.md with detailed explanations of tabular data concepts, installation instructions, and usage examples.

Configuration

Enhanced configuration files for better data processing and model training setups.
Added new dependencies to pyproject.toml for improved functionality.

Scripts

Added and updated multiple scripts for data processing, tabularization, and summarization.
Introduced new functions for handling static and time-series data.

Bug Fixes

None.

Refactor

Updated Python version setup in workflows and added new arguments to pre-commit hooks for better code quality.

Chores

Added various configuration and setup scripts to streamline data processing and model training tasks.

Closing as #1 has all requisite changes according to @teyaberg . Thanks!


Problem with util_file.fix_slashes and UNC paths

The routine vtool.util_file.fix_slashes() attempts to convert Windows "\" path separator backslashes to the forward slash "/", which will still work on Windows.  But it then converts doubled slashes ("//") to a single slash.  This is problematic for UNC paths on windows, which start with a doubled separator ("\\hostname\sharename\dirname", etc).  Given that example, it produces "/hostname/sharename/dirname", which is no longer valid on Windows.  We came across the problem while trying to use a shared network copy the vtool package on a networked drive (UNC path) in our studio pipeline.
    if not directory.find('https://') > -1:
        directory = directory.replace('//', '/')

I'm not sure what the intent of removing the doubled slashes was.  Posix filesystems are designed to treat multiple slashes to a single slash and should have no problem with them, and Windows appears to handle doubled slashes internally as well, while removing the initial doubled slash for a UNC path obviously breaks it.
We're going to try just disabling that bit of fix_slashes, and if I get a chance I'll submit a pull request with that patch.

I've created this pull request if you'd like to check it.  I can add you to the vtool project as a developer if you would like.
https://github.com/louisVottero/vtool/pull/25

The fix is merged into main. Closing this issue.


DEV-14729 - Fixes a deprecation warning about interpolation-only expressions

Spotted this deprecation warning when working on the config module:
Warning: Interpolation-only expressions are deprecated

  on .terraform/modules/tamr-es-cluster/main.tf line 8, in module "tamr-es-cluster":
   8:   security_group_ids              = ["${module.elasticsearch-sg.es_security_group_id}"]

Terraform 0.11 and earlier required all non-constant expressions to be
provided via interpolation syntax, but this pattern is now deprecated. To
silence this warning, remove the "${ sequence from the start and the }"
sequence from the end of this expression, leaving just the inner expression.

Template interpolation syntax is still used to construct strings from
expressions when the template includes multiple interpolation sequences or a
mixture of literal strings and interpolations. This deprecation applies only
to templates that consist entirely of a single interpolation sequence.

This PR doesn't appear to be linked to a DevOps/SRE jira ticket

This PR doesn't appear to be linked to a DevOps/SRE jira ticket

This PR doesn't appear to be linked to a DevOps/SRE jira ticket

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Refactor variable interface

Some NodeJS versions do not support the term "interface" as a variable
as it is a reserved keyword.
Specifically Node 6.9.5 does not support this version.
This change removes the "interface" variable name and replaces it with "intf"

Hey all,
I'm trying to deploy something to our production environment running on Node 6.9.5 (we have plans to update but can't currently).
Any chance you all could publish a new patch version to npm for this change?
Thanks much!

Thanks Greg for this fix, the new release will come in a couple minutes

@infusion thank you tons for the fast response! Really, really appreciate it

v0.2.20 is live :)

Thanks! already shipping on our side. Fastest github response I've ever received, thank you @infusion !


How to calculate climate metrics faster, in the case of mask nc data?

Setup Information

Xclim version:0.46.0
Python version:3.11
Operating System:Linux

My original data was huge, 22G, and as a result caused my program run to crash frequently. It's a global precipitation dataset from ERA5 data pool.
My idea is to mask this data by my shape file and calculate climate indicators, which might be faster.
ERA5_pre_clip=pre_ERA5.rio.clip(gdf.geometry.apply(mapping),gdf.crs,drop=True,invert=False) ERA5_p95=xclim.core.calendar.percentile_doy(ERA5_pre_clip.tp,per=95,window=5)

But so far it doesn't seem to be much faster. I guess maybe the xclim can't avoid the NAN value?
Now I use this command.It is right? Ref from this
with xclim.set_options(check_missing="any"): ERA5_p95=xclim.core.calendar.percentile_doy(ERA5_pre_clip.tp,per=95,window=5)
Context
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Hi @CGL5230,
I'm wondering if you are making proper use of Dask. All the indicators and indexes are optimized to make use of dask.array objects. These can be created by opening your NetCDF datasets in xarray with the chunks option.
In case you haven't come across this before: https://examples.dask.org/xarray.html

I second the recommendation about using dask, IMO this is the first step to try. In addition to the good documentation linked above, you can look at the examples in xclim's doc.
The check_missing='any' option will not change the computation itself. It will only change the "post-processing" step. All indicators that peform some kind of resampling (i.e. functions under xclim.atmos) have this masking step that puts NaN for the periods where there were too many invalid values. In fact, check_missing='any' is already the default, it simply means that any NaN in a given period will propagate as a NaN in the output.
Also, percentile_doy is not an indicator,  setting check_missing has no effect on this function.
So, simply masking your data by clipping areas of interest will not significantly accelerate the computation.
It seems however, that after clipping your data is extremely sparse. In this case you could pull the following trick. It will only work if the "mask"[^1]  is constant in time.  The idea is you could collapse your 2D grid to a 1D one by dropping the points where there's never any data. This will reduce the size of the dataset greatly and should make everything faster. A
ERA5_pre_clip = pre_ERA5.rio.clip(gdf.geometry.apply(mapping), gdf.crs, drop=True, invert=False)
# Put all lon and lat points into a single dimension, drop any spatial points where everything is NaN
ERA5_pre_clip_1d = ERA5_pre_clip.stack(site=['lat', 'lon']).dropna('site')

# make xclim computation
out_1d = blablabla

# Recover full grid
out_2d = out_1d.unstack('site').reindex(lat=pre_ERA5.lat, lon=pre_ERA5.lon)

I'll leave you with the details of this implementation, this is just an (untested!) idea.
Chances are that using dask will be easier and faster anyway.
[^1] : which spatial points are NaN and which have data

That's great! I will try dask for calculations. I'm thinking the way of @aulemahal . The obvious convenient way is avioding the NAN value. That's will save lot of resource and time.
But I look through the dask example as your offer, It also great and easier.

I use those command to parallelize operations for xclim. But I don't know if this line of code is capable of parallel computation, because this computation still takes a lot of time and I haven't come up with a result so far.
The code is
pre_ERA5_chunk = pre_ERA5.chunk({'time': -1, 'lon': 100, 'lat': 100}) wb_ERA5= xclim.indices.water_budget(pr=pre_ERA5_chunk.tp, tas =tas_ERA5.t2m, method="MB05")

I use the suggestion of @aulemahal . That's will be faster. Drop the  NAN value speed up the calculation for the climate index. Because the clip dataset is obviously sparse. Still now,I‘m not sure the dask works .

I second the recommendation about using dask, IMO this is the first step to try. In addition to the good documentation linked above, you can look at the examples in xclim's doc.
The check_missing='any' option will not change the computation itself. It will only change the "post-processing" step. All indicators that peform some kind of resampling (i.e. functions under xclim.atmos) have this masking step that puts NaN for the periods where there were too many invalid values. In fact, check_missing='any' is already the default, it simply means that any NaN in a given period will propagate as a NaN in the output. Also, percentile_doy is not an indicator, setting check_missing has no effect on this function.
So, simply masking your data by clipping areas of interest will not significantly accelerate the computation.
It seems however, that after clipping your data is extremely sparse. In this case you could pull the following trick. It will only work if the "mask" 1 is constant in time. The idea is you could collapse your 2D grid to a 1D one by dropping the points where there's never any data. This will reduce the size of the dataset greatly and should make everything faster. A
ERA5_pre_clip = pre_ERA5.rio.clip(gdf.geometry.apply(mapping), gdf.crs, drop=True, invert=False)
# Put all lon and lat points into a single dimension, drop any spatial points where everything is NaN
ERA5_pre_clip_1d = ERA5_pre_clip.stack(site=['lat', 'lon']).dropna('site')

# make xclim computation
out_1d = blablabla

# Recover full grid
out_2d = out_1d.unstack('site').reindex(lat=pre_ERA5.lat, lon=pre_ERA5.lon)

I'll leave you with the details of this implementation, this is just an (untested!) idea. Chances are that using dask will be easier and faster anyway.
Footnotes

which spatial points are NaN and which have data ↩


Fix/select remaining suggestion

This fixes the following issue:

Type a few letters, highlight a suggestion on the list second down or farther, and keep typing so that the suggestion disappears. selectedIndex will be out of bounds of the suggestions array. (And hitting enter will add an undefined tag 💀)

This ensures that selectedIndex is adjusted to the last available suggestion while typing. Also added a test.
Also updated package.json to v4.2.1.
P.S. this library is great, I'm happy to have a chance to contribute!

Heya @whitmanschorn, this is awesome and it looks great! Thanks for adding the tests and fixing this bug. I'll merge this in and release this on NPM right away.
Thanks a ton!


We can not use camelCase method name.

In the current implementation, we can not use camelCase naming.
For example, if the camelCase() method is defined in interface as follows:
interface ExampleInterface {
    void camelCase();
};

Our generator generates codes as follows:
class ExampleInterface {
    void Camelcase();    // This is a bug.
};

I try this issue by adding filter. please review :+1:

@yjaeseok, Can we close this issue? If so, please close this. Thanks!

This issue is closed.


[DO NOT MERGE] Berkeley QA release 32a9161 + epoch ledger sync

Release code from https://github.com/MinaProtocol/mina/discussions/11872, plus the epoch ledger sync code recently merged to develop.

!ci-build-me


🐞 Send Poll is not working

What happened?
After using the Send Poll resource, the message appears to be sent, but no content is displayed in WhatsApp
Reproduction Steps
The behavior can be replicated:
1. Using the Send Poll endpoint as described in the openapi.yaml documentation.
2. Using Send Poll in the Dashboard.

Relevant log output
whatsapp_go-1  | 15:22:24 | 200 |  916.284853ms | <IP_ADDRESS> | POST | /send/poll | -
whatsapp_go-1  | 15:22:25.955 [Client/Send DEBUG] <ack class="receipt" id="3EB05AC105DDDDC319E95D"<EMAIL_ADDRESS>type="inactive"/>
whatsapp_go-1  | 15:22:26.262 [Client/Recv DEBUG] <receipt<EMAIL_ADDRESS>id="3EB05AC105DDDDC319E95D"<EMAIL_ADDRESS>t="1712676146" type="sender"/>
whatsapp_go-1  | 15:22:26.262 [Client/Recv DEBUG] <receipt<EMAIL_ADDRESS>id="3EB05AC105DDDDC319E95D" t="1712676146"/>
whatsapp_go-1  | 15:22:26.263 [Client/Send DEBUG] <ack class="receipt" id="3EB05AC105DDDDC319E95D"<EMAIL_ADDRESS>whatsapp_go-1  | 15:22:26.263 [Main INFO] 3EB05AC105DDDDC319E95D was delivered to<EMAIL_ADDRESS>in<EMAIL_ADDRESS>at 2024-04-09 15:22:26 +0000 UTC
whatsapp_go-1  | 15:22:26.263 [Client/Send DEBUG] <ack class="receipt" id="3EB05AC105DDDDC319E95D"<EMAIL_ADDRESS><EMAIL_ADDRESS>type="sender"/>
whatsapp_go-1  | 15:22:26.415 [Client/Recv DEBUG] <receipt<EMAIL_ADDRESS>id="3EB05AC105DDDDC319E95D" t="1712676146"/>
whatsapp_go-1  | 15:22:26.416 [Client/Send DEBUG] <ack class="receipt" id="3EB05AC105DDDDC319E95D"<EMAIL_ADDRESS>whatsapp_go-1  | 15:22:26.416 [Main INFO] 3EB05AC105DDDDC319E95D was delivered to<EMAIL_ADDRESS>at 2024-04-09 15:22:26 +0000 UTC

Screenshots or Additional Context
No response
Application Version
v4.12.0
Verification

[X] I have checked for existing closed issues and discussions.

You might want to try with a different account. I sent a poll from the homepage menu, and it worked.


Roll engine to fed2ea458ed49088d33eddabc546ba56d600c717 (includes dart roll) again

This relands https://github.com/flutter/flutter/pull/19044 with single-line fix for test failure in tracing.dart.


Draft of typed getExtension

cc: @nichite

👀

Do you remember what problem this is solving @sigurdm? PR description doesn't refer to any issues.

Do you remember what problem this is solving @sigurdm? PR description doesn't refer to any issues.

Currently you get back a dynamic from GeneratedMessage.getExtension(). But we have an Extension object that can carry the type of the extension. This would lead to stronger typing. Every dynamic ends up including a cast.
I don't think I'll find the time to pursue this - feel free to close.


Add keyframe numbers to (CLI) ouput

Would be nice to get a CLI option that outputs the frame-numbers of the keyframes. A comma-seperated string would probably be most usefull (1,82,196,245 i.e.).
Then you can do a turbo turbo pass, (speed 10, quarter resolution, etc.) to get the optimal keyframe placement, which can be used to split the video at the correct points for optimal encoding in chunks.
Maybe I have some time to implement this later, for now I will leave it here as an issue.

What are the thoughts on having rav1e output its stats file in some standardized format, e.g. JSON? In the past, if I wanted to parse output from xvid or x264's stats file to find the keyframes, I needed to write a custom parser. This would make that a bit easier by allowing use of existing parsers.

I think that's a great idea. Also, having both a public and private stats file would make sense, where the private one can change each version (and might be binary). The public one might have less info but is defined as part of the API.