SWMT shifts to lighter densities in MOM6-01

I calculated the SWMT in six different  1/10th MOM6 configurations:

panant-01-zstar-v13: 1/10th panantarctic zstar run with ACCESS-OM2-01 year 200 IC + BF
panant-01-hycom1-v13: 1/10th panantarctic hybrid run with ACCESS-OM2-01 year 200 IC + BF
panant-01-zstar-ACCESSyr2: 1/10th panantarctic zstar run with ACCESS-OM2-01 year 2 IC + BF
global-01-v1: 1/10th global zstar run (version 1) with ACCESS-OM2-01 year 200 IC
global-01-v2: 1/10th global zstar run (version 2) with ACCESS-OM2-01 year 2 IC
global-01-v3: 1/10th global hybrid run (version 3) with ACCESS-OM2-01 year 2 IC

The peak of the mean (1996-2000) SWMT in each of the 4 formation regions occurs at different densities with runs that start from year 200 of ACCESS-OM2-01 being denser (blue, orange, red line) and runs starting from year 2 of ACCESS-OM2-01 (i.e. close to WOA observations) being lighter. This is especially visible in the Weddell Sea.

The peak of the SWMT shifts to lighter densities each year in the runs that start from ACCESS-OM2-01 year 2 in all regions and especially in the Ross Sea.

In runs starting from ACCESS-OM2-01 year 200 the density of the peak SWMT isn't shifting to lighter densities as much and also slower (note that the 2nd Plot with panant-01-zstar-v13 includes 46 years more)

A timeries of the SWMT for a density at a mean (1991-2012) transport of 70% of the maximum transport (orange line) for panant-01-zstar-ACCESSyr2 shows that after 10 years the SWMT dropped below 0.5 Sv from around 2 Sv in the Weddell/Ross Seas.

I didn't see a difference between vertical coordinates, or whether it was global or panantarctic.
Plots for all of the runs are here: https://github.com/schmidt-christina/mom6_comparison/blob/main/SWMT_Plots.ipynb

We were wondering whether that had something to do with the initial stratification, so I looked at bottom T/S/rho and compared panant-01-zstar-v13 and panant-01-zstar-ACCESSyr2.
All plots and more detailed text are here: https://github.com/schmidt-christina/mom6_comparison/blob/main/Shelf_properties_Plots.ipynb
Initial temperatures don't differ much between panant-01-zstar-v13 and panant-01-zstar-ACCESSyr2 in the DSW formation regions, but it's up to 2°C warmer in the Amundsen/Bellingshausen Sea (not shown here).
Salinity: The initial conditions in the Weddell Sea are fresher (up to 0.2 psu) in panant-01-zstar-v13 compared to panant-01-zstar-ACCESSyr2. But this reverses with panant-01-zstar-v13 being saltier everywhere on the shelf after 10 years. The Weddell Sea gets saltier in panant-01-zstar-v13  and fresher in panant-01-zstar-ACCESS-yr2. The Amundsen Sea gets saltier and the Ross Sea fresher in both runs, but the magnitude of the freshening is slightly stronger in panant-01-zstar-ACCESSyr2, so that panant-01-zstar-v13 is still saltier.
Overall, it’s getting lighter everywhere on the Antarctic shelf in panant-01-zstar-ACCESS-yr2, especially in the Ross Sea.

Horizontal mean density profiles in the Weddell and Ross Sea have mostly the same shape in both runs, panant-01-zstar-ACCESS-yr2 is often lighter (with a constant offset over the whole water column compared to panant-01-zstar-v13). But it is not necessarily like that from the start, it often gets lighter over time as the SWMT shifts to lighter densities.

Amazing analysis, thanks @schmidt-christina! Rather unexpected, because we have the same atmospheric forcing, same vertical grid and same horizontal resolution / bathymetry as ACCESS-OM2-01.
@AndyHoggANU suggested we could try playing around with the boundary layer vertical mixing schemes. I'll try to get some panan-01 test cases going today with different mixing schemes / parameters.

Yeah, I agree this is a very nice analysis. I'm also very interested in seeing what we get out of the 1/20° case.
@schmidt-christina - if you have time to look at your current 1/20° simulation before our Monday morning meeting that would be helpful!

I have 5 years of the 1/20th run now. So far it doesn't look too bad, there is certainly not the same shift that I can see already in the first 5 years in the 1/10th run with same IC + BC etc. But as I only have five years yet, I would still be a bit cautious. Also the SWMT is quite weak in the Weddell Sea.

Plot below is the panant-01-zstar-ACCESS-yr2 with the shift visible already in the first 5 years for comparison:

That’s good news! Did you decide at the meeting today to run longer? If so,
has anyone checked what the density binning on vmo and umo is like? Might
be good to double check the diagnostic list, so we don’t have to rerun 10
years (perhaps you already did this at the meeting today). Do we have x and
y heat flux diagnostics switched on too?
On Mon, Apr 17, 2023 at 8:36 AM, Christina Schmidt @.***>
wrote:

I have 5 years of the 1/20th run now. So far it doesn't look too bad,
there is certainly not the same shift that I can see already in the first 5
years in the 1/10th run with same IC + BC etc. But as I only have five
years yet, I would still be a bit cautious. Also the SWMT is quite weak in
the Weddell Sea.
[image: image]
https://user-images.githubusercontent.com/38216156/232346051-52918744-5362-497a-b61b-ed8c96901109.png
Plot below is the panant-01-zstar-ACCESS-yr2 with the shift visible
already in the first 5 years for comparison:
[image: image]
https://user-images.githubusercontent.com/38216156/232346063-d7b7dc9c-d4ad-463c-85ba-6cdeb1f76011.png
—
Reply to this email directly, view it on GitHub
https://github.com/COSIMA/mom6-panan/issues/40#issuecomment-1510506826,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACA44UZCFUHRWX3DV3FSQ5TXBRYABANCNFSM6AAAAAAW4S7JMY
.
You are receiving this because you commented.Message ID:
@.***>

Yes, we decided to run another 5 years and it's running atm. We briefly looked at the density binning, but decided that I would look at it in more detail. So maybe I can look at it first thing tomorrow morning and pause the run in the meantime?
What do you mean by "x and y heat flux diagnostics"?

I wouldn't bother pausing, just keep running and see if you can check the
density binning as soon as you can.
Zonal and meridional heat fluxes, I'm not sure what they're called in MOM6.
WIlton, do you know, or could you check?
On Mon, 17 Apr 2023 at 16:04, Christina Schmidt @.***>
wrote:

Yes, we decided to run another 5 years and it's running atm. We briefly
looked at the density binning, but decided that I would look at it in more
detail. So maybe I can look at it first thing tomorrow morning and pause
the run in the meantime?
What do you mean by "x and y heat flux diagnostics"?
—
Reply to this email directly, view it on GitHub
https://github.com/COSIMA/mom6-panan/issues/40#issuecomment-1510754789,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACA44U6QH6QSJMULF7WNRQ3XBTMP3ANCNFSM6AAAAAAW4S7JMY
.
You are receiving this because you commented.Message ID:
@.***>

I found this variable, is that the right one @adele157 @willaguiar ?
T_advection_xy"  [Unused]
    ! modules: {ocean_model,ocean_model_z,ocean_model_rho2,ocean_model_d2,ocean_model_z_d2,ocean_model_rho2_d2}
    ! long_name: Horizontal convergence of residual mean advective fluxes of heat
    ! units: W m-2
    ! cell_methods: xh:mean yh:mean zl:sum area:mean
    ! variants: {T_advection_xy,T_advection_xy_xyave}

I found this variable, is that the right one @adele157 @willaguiar ?
T_advection_xy"  [Unused]
    ! modules: {ocean_model,ocean_model_z,ocean_model_rho2,ocean_model_d2,ocean_model_z_d2,ocean_model_rho2_d2}
    ! long_name: Horizontal convergence of residual mean advective fluxes of heat
    ! units: W m-2
    ! cell_methods: xh:mean yh:mean zl:sum area:mean
    ! variants: {T_advection_xy,T_advection_xy_xyave}

I believe the fields we want are T_adx, and T_ady

I found this variable, is that the right one @adele157 @willaguiar ?
T_advection_xy"  [Unused]
    ! modules: {ocean_model,ocean_model_z,ocean_model_rho2,ocean_model_d2,ocean_model_z_d2,ocean_model_rho2_d2}
    ! long_name: Horizontal convergence of residual mean advective fluxes of heat
    ! units: W m-2
    ! cell_methods: xh:mean yh:mean zl:sum area:mean
    ! variants: {T_advection_xy,T_advection_xy_xyave}

I believe the fields we want are T_adx, and T_ady

 "ocean_model_z","T_adx",        "T_adx",            "ocean_annual_z",     "all", "mean", "none",2
 "ocean_model_z","T_ady",        "T_ady",            "ocean_annual_z",     "all", "mean", "none",2

from: https://github.com/NOAA-GFDL/MOM6-examples/blob/dev/gfdl/ice_ocean_SIS2/OM4_025/diag_table.MOM6

My tests in panan-01 of different surface boundary mixing schemes made zero difference (at least to these overturning diagnostics - I haven't checked SWMT). I started from the orange config and:

Used a different set of options in the EPBL scheme (green),
Switched off EPBL and turned on KPP (red),
Same as for 2, but I also switched on the cvmix convective instability parameterisation (purple).

The same information, but now with a much better diagnostic - cross 1000m isobath transport (thanks to @schmidt-christina for working on the code):

We haven't made a contour for the 1/20th run yet, but would be good to compare that also! And maybe panant-01-zstar-v13 would recover if we ran for longer?

Turns out we don't have salinity restoring turned on in any of the panan configs. This is quite likely the problem!

Restoring doesn't help. :(

This is using the same restoring file as ACCESS-OM2-01 with the same piston velocity and I've checked it's actually doing something.

Hmm. Can you describe how you calculated the piston velocity?

MOM6 uses piston velocity as the input parameter:
(FLUXCONST_SALT = 0.11 ! [m day-1] The constant that relates the restoring surface salt fluxes to the relative surface anomalies (akin to a piston velocity).  Note the non-MKS units.).
I set this as 0.11 m/day.
This matches what we use in ACCESS-OM2-01: 1.1 m / 10 days.

Does MOM6 restores salinity under the ice as in MOM5 or has a different flag for it? Wondering if that could be it

Yes, it also has an option to turn off restoring under ice. I opted to do
exactly what we do in ACCESS (restore under ice).
On Thu, 27 Apr 2023 at 17:02, Wilton Aguiar @.***>
wrote:

Does MOM6 restores salinity under the ice as in MOM5 or has a different
flag for it? Wondering if that could be it
—
Reply to this email directly, view it on GitHub
https://github.com/COSIMA/mom6-panan/issues/40#issuecomment-1524914310,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACA44UZWDWJQ4MSRKKCVLUDXDIKZDANCNFSM6AAAAAAW4S7JMY
.
You are receiving this because you were mentioned.Message ID:
@.***>

So, try a run with river mix?

Yep can do.
On Thu, 27 Apr 2023 at 21:20, Andy Hogg @.***> wrote:

So, try a run with river mix?
—
Reply to this email directly, view it on GitHub
https://github.com/COSIMA/mom6-panan/issues/40#issuecomment-1525514215,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACA44U6APKYQDFNGI662SM3XDJI6LANCNFSM6AAAAAAW4S7JMY
.
You are receiving this because you were mentioned.Message ID:
@.***>

Plan from this morning's meeting (feel free to edit this comment to add your name to any of these or to add more suggestions):
1. More diagnostic analysis of panan vs ACCESS-OM2-01 spinup:

Add ACCESS-OM2-01 to DSW export plot. Is it steady in the first 10 years? Wilton
Add 1/20th to DSW export plot. Christina
Look at different density thresholds for DSW export time series. Is the DSW still there just at lighter densities? Or does export stop?
Time series of T / S / rho (surface and bottom), MLD, sea ice, integrated over the continental shelf.
Look at sea ice melt/salt flux terms (need to switch on more diags, or just look at net freshwater flux for now (wfo) - time series, spatial pattern, etc. Fabio

Names of experiments to compare for the above analysis:

ACCESS-OM2-01 RYF: 01deg_jra55v13_ryf9091.
Original 1/10th panan (with year ~200 ACCESS at northern boundary and init. cond.): panant-01-zstar-v13.
Updated 1/10th panan (with year 2 ACCESS at northern boundary and init. cond.): panant-01-zstar-ACCESSyr2
Updated 1/20th panan (with year 2 ACCESS at northern boundary and init. cond.) NOTE NOT ON IK11: /scratch/e14/cs6673/mom6/archive/panan_005deg_jra55_ryf. This isn't in the main database, but is in this database: /g/data/e14/cs6673/mom6_comparison/Python_scripts/panan_005deg_jra55_ryf.db.

2. More detailed look at salinity restoring files. Salinity restoring using WOA data did not help DSW formation. Is this because WOA salinity is way too fresh in winter? Compare maps of WOA salinity restoring file (/g/data/ik11/inputs/mom6/panan/01deg/20230404/salt_restore.nc), ACCESS-OM2-01 surface salinity, and surface salinity from the Pauthenet et al. 2021 climatology (/g/data/ik11/observations/Southern_Ocean_Climatology_PauthenetETAL2021/TS_Climato_Antarctic60S.nc), focusing on winter months in particular.
Perhaps if we have a surface salinity field that would aid DSW production (i.e. high salinity over shelf in winter), we could do another test with updated salinity restoring file and higher piston velocity or higher max allowed salinity difference.
3. Check input and parameter files for any anomalies.

/g/data/ik11/outputs/mom6-panan/panant-01-zstar-ACCESSyr2/output000/MOM_parameter_doc.all
/g/data/ik11/outputs/mom6-panan/panant-01-zstar-ACCESSyr2/output000/SIS_parameter_doc.all There are many parameters in here that I'm not sure how they compare to ACCESS-OM2, because I'm not sure what the CICE names mean. @aekiss could you take a look please?
https://github.com/COSIMA/mom6-panan/blob/panan-01-zstar-run/input.nml

4. We noticed that RHO_OCEAN = 1030 in SIS_input, but RHO_0 = 1035.0 in MOM_input. Also, SEA_ICE_MEAN_DENSITY = 900.0 in MOM_input, but RHO_ICE = 905.0 in SIS_input. Does this matter? Could do a test if we think this is important.
5. Salt in sea ice. I also noticed that we have ICE_BULK_SALINITY = 0.0 (The fixed bulk salinity of sea ice.) and ICE_RELATIVE_SALINITY = 0.1 (The initial salinity of sea ice as a fraction of the salinity of the seawater from which it formed.) in SIS_input, and ICE_SALT_CONCENTRATION = 0.005 in MOM_input. Maybe we should try changing ICE_RELATIVE_SALINITY = 0.0 and ICE_BULK_SALINITY to match ICE_SALT_CONCENTRATION (noting that have different units)?

Also the updated DSW export (across 1000m isobath) plot with restoring and rivermix cases:

I'm still running rivermix, but it's not looking hopeful. We can update this once we have 1/20th and ACCESS-OM2-01 data to compare also.

I created the 1000 m isobath for the 1/20 model and computed the cross 1000m isobath transport. The offshore transport is higher in the 1/20th simulation compared to the 1/10th simulation. In agreement with the SWMT analysis it is stable for the first 5 years and then starts to slowly decline in year 1996+1997.

I also used a lighter density threshold to calculate the cross 1000 m isobath transport for all 1/10th simulations to see if we still produce DSW but at lighter densities. This is the case for the runs with year ~200 ACCESS at northern boundary and init. cond, but not when we use year 2 ACCESS BC + IC.

Thanks @schmidt-christina -- very nice! Just to check: Is this 1/20° run starting from the same WOA restart as the ACCESSyr2 simulation?
If yes, my feeling is that we have some cause for optimism that the 1/20° run will give us much better results than the 1/10° ... Is there an appetite (and spare SU) to restart the 1/20° with salinity restoring fixed, and any improvements we can make to the initial condition??

Yes I think it’s definitely worth investigating the comparison of salinity
restoring data choices suggested above.  If we come up with better data we
could do a quick test on the 1/10th first?
For initial conditions, WOA (which is pretty close to what the 1/20th is
currently starting from) is pretty terrible on the shelf. Maybe worth
comparing later years from ACCESS (I.e. v13 initial conditions) with WOA
and Schmidtko bottom data to see why the v13 case is better?
On Thu, May 4, 2023 at 9:40 PM, Andy Hogg @.***> wrote:

Thanks @schmidt-christina https://github.com/schmidt-christina -- very
nice! Just to check: Is this 1/20° run starting from the same WOA restart
as the ACCESSyr2 simulation?
If yes, my feeling is that we have some cause for optimism that the 1/20°
run will give us much better results than the 1/10° ... Is there an
appetite (and spare SU) to restart the 1/20° with salinity restoring fixed,
and any improvements we can make to the initial condition??
—
Reply to this email directly, view it on GitHub
https://github.com/COSIMA/mom6-panan/issues/40#issuecomment-1534616469,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACA44U2CRK7FCEYYMT4HTZDXEOIR5ANCNFSM6AAAAAAW4S7JMY
.
You are receiving this because you were mentioned.Message ID:
@.***>

@AndyHoggANU: Yes, the IC + BC of the 1/20th run are identically to the ACCESSyr2 simulation
I would also prefer tests in the 1/10th first, as it takes quite long to run the 1/20th (and is expensive), we would probably need at least 8 years to see changes.

Great, Christina, do you or someone else want to look at possible restoring
data and put a 1/10th test on today, so we have something to look at on
Monday? I'm still travelling, so can't do anything until next week.
On Fri, 5 May 2023 at 08:14, Christina Schmidt @.***>
wrote:

@AndyHoggANU https://github.com/AndyHoggANU: Yes, the IC + BC of the
1/20th run are identically to the ACCESSyr2 simulation
I would also prefer tests in the 1/10th first, as it takes quite long to
run the 1/20th (and is expensive), we would probably need at least 8 years
to see changes.
—
Reply to this email directly, view it on GitHub
https://github.com/COSIMA/mom6-panan/issues/40#issuecomment-1535477979,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACA44UYBDFNSWHB2IBKFGX3XEQS47ANCNFSM6AAAAAAW4S7JMY
.
You are receiving this because you were mentioned.Message ID:
@.***>

I can put the 1/10th to run today with restoring salinity + change in sea ice parameters (Bulk salinity, density, etc) . Do we have the IC+BC for year 2 and 200 of ACCESS ready for the panan01 or do we create those ? If we have, what are their dirs?

I'd suggest just running just the case with yr 2 boundary forcing to start, i.e. a copy of this case:
/home/157/akm157/mom6/panan-01-zstar-yr2forcing/
All the required forcing is linked in there.
For the salinity restoring, have you compared winter maps of the 3 suggested salt data possibilities (ACCESS-OM2-01, Pauthenet, WOA) above to see which one will be best? Would be great to see those maps here (or a new issue perhaps - this one is getting long).

A simple comparison of Winter (DJF) surface salinities between the Pauthernet, WOA and ACCESS ( in reference to WOA) below. Overall it seems that the Ross shelf has higher salinity values on the winter, but the opposite happens on Weddell. So if we restore towards Pauthernet we might have a better DSW formation in Ross, but get something worse in Weddell. ACCESS salinity field seem to be very similar to WOA, Maybe slightly saltier over the whole domain.

If you want to see Salinity Anomalies in other seasons check here.

I'm commenting on parameters here, as it seems a better spot for it https://github.com/COSIMA/mom6-panan/issues/42

Ok, some plots comparing the SSS in WOA salinity restoring target with final Surface_salt from 01deg_jra55v13_ryf9091. Comparison only for June, and winter. Notice I updated this previous comment cause it was showing summer instead of winter before. In the plots below it seems that output SSS in OM2 is fresher over the whole shelf in Jun than in WOA. But the Seasonal climatology plot for winter shows that the other months compensate somehow (Ross shelf gets saltier than WOA)  that  and that over 200 years winter salinities gradually increase to try to match the WOA target.
Fig 1 = Salinity anomalies of OM2 output  - WOA reference, for June, first 2 years of 01deg_jra55v13_ryf9091 and then year 201 and 202
Fig 2 = WOA, June salinity for reference
Fig 3 = Average SSS South of the 1000m isobath (Shelf) and the same for the WOA target for reference.
Fig 4. = Climatology of Seasonal Anomalies of SSS (OM2 output - WOA target), last 10 years of OM2 output

I don't really agree with your comment that output SSS in OM2 is fresher over the whole shelf in Jun than in WOA. It is certainly fresher very close to the coast, especially in the Weddell/Bellingshausen/Amundsen Seas, but that's not were we have strong SWMT. We normally have strong SWMT in the western Ross Sea and Adelie Coast, where the SSS in ACCESS-OM2 is a lot saltier , and in the western Weddell Sea (but not directly on the coast of the peninsula) and Prydz Bay, where the anomaly is not as strong, but it's still saltier in winter and spring.

Thanks for plotting all these up @willaguiar! It's not as straightforward as I was thinking it might be. That really fresh band along the coast in ACCESS-OM2 might do weird things (make the shelf fresher) if we try restoring to that. But then again WOA is saltier, as Christina points out, directly over the DSW formation sites.
It's not clear to me what the best test would be. I'm thinking maybe another restoring run using WOA data, but ramp up the restoring parameters. For the last test I used:
RESTORE_SALINITY = True
ADJUST_NET_SRESTORE_TO_ZERO = True
FLUXCONST_SALT = 0.11
SALT_RESTORE_FILE = "salt_restore.nc"
SRESTORE_AS_SFLUX = True
MAX_DELTA_SRESTORE = 0.5
MASK_SRESTORE_UNDER_ICE = False.
We could try as above, but increasing these to the OM4 values of:
FLUXCONST_SALT = 0.1667
MAX_DELTA_SRESTORE = 5
To make this test a bit different to the last one, we could also use Pauthenet data south of 60S, patched to WOA north of that. It looks like Pauthenet is fairly different in the Amundsen / Bellingshausen / WAP, where we normally have large biases in ACCESS-OM2.
Any other opinions?

Also for those who missed yesterday's meeting, our plan for the next week is as follows:

Run 3 tests in the 1/10th panan to see if we can improve / understand the lack of DSW formation better:

Hit the model harder with salinity restoring. Wilton to do this.
Try some different initial conditions - so far the best DSW formation occurs with year 200 ACCESS-OM2-01 initial conditions, but these are pretty far from obs. We discussed MIMOC yesterday, but looking at this now, I see it doesn't include seal data, which is the largest data type on the shelf. Christina to do this.
Update a bunch of the sea ice parameters, as outlined in this issue. Adele to do this.

Continue to analyse the sea ice formation in more detail. Fabio to do this.

Hopefully one of these tests might give us some better DSW formation in the 1/10th. But if not, we will start the 1/40th run next week anyway.

I ran 10 years of panan-01 starting with initial conditions from "World ocean circulation experiment-argo global hydrographic climatology (WAGHC)" (Gouretski, 2018, Ocean Science).
This climatology is saltier than WOA in the upper 40 m but fresher below, see here for a comparison between different climatologies.
This run is probably even worse compared to starting from ACCESSyr2 IC by just looking at the cross-1000m transport but it does confirm that the initial conditions indeed have quite a strong effect on the DSW formation and export.

And results here for the test run with altered sea ice parameters (red line compared to equivalent control in orange):

I changed a bunch of sea ice parameters, and the shortwave penetration depth, as outlined in this issue. I guess - while not helpful for our purposes right now in setting up the 1/40th - this does indicate there is a strong sensitivity to sea ice parameters. Maybe if we tried to change those parameters individually we'd be able to identify which are the crucial ones and modify them to get more DSW formation rather than less as we've done here.

Added to Adeles plot here the case of restoring salinity with a stronger piston velocity (FLUXCONST_SALT = 0.1667 MAX_DELTA_SRESTORE = 5) and towards Pauthenet target salinities. It doesn't seem to change too much the final DSW export ( I checked to make sure it was using the new Salinity target, and it was). I guess it agrees with Adele's case of nothing changing when turning on salinity restore.

I checked the salinity over the shelf (south of 1000m isobath), and both SSS and SOBottom  get lower and lower within 10 years (it maybe explains why we have less and less DSW?) , while in a OM2 run restored towards WOA (IC from WOA) salinities over the shelf get roughly stable around 5yrs (Added there for comparrison)

Turns out we do get some improvement in DSW formation in the panan-01 when we use these salinity restoring settings (green line compared with control orange line):
RESTORE_SALINITY = True
ADJUST_NET_SRESTORE_TO_ZERO = False
FLUXCONST_SALT = 0.1667
SRESTORE_AS_SFLUX = True
MAX_DELTA_SRESTORE = 5

Note we also used Pauthenet et al. 2021 SSS instead of WOA, but I don't think that was the important part. The crucial parts seem to be ADJUST_NET_SRESTORE_TO_ZERO = False and MAX_DELTA_SRESTORE = 5. I think with all the Antarctic runoff input at the surface next to the coast, we get a really extreme coastal freshening. Ramping up MAX_DELTA_SRESTORE = 5 (same as GFDL OM4 setting) acts to counteract the coastal freshening. Wilton's previous case had the same high settings, but without ADJUST_NET_SRESTORE_TO_ZERO = False and that did next to nothing, so I think with the global offset to zero the restoring, we must have ended up putting the wrong sign restoring flux in some places.
We're running with these settings for the panan production runs now.

nice. that's starting to make sense :)
P
On Fri, May 26, 2023 at 11:28 AM Adele Morrison @.***>
wrote:

Turns out we do get some improvement in DSW formation in the panan-01 when
we use these salinity restoring settings (green line compared with control
orange line):
RESTORE_SALINITY = True
ADJUST_NET_SRESTORE_TO_ZERO = False
FLUXCONST_SALT = 0.1667
SRESTORE_AS_SFLUX = True
MAX_DELTA_SRESTORE = 5
[image: Screen Shot 2023-05-26 at 11 41 28 am]
https://user-images.githubusercontent.com/8506963/241111121-2252cd0f-9bf2-4e11-842e-5ab88dfa86e3.png
Note we also used Pauthenet et al. 2021 SSS instead of WOA, but I don't
think that was the important part. The crucial parts seem to be ADJUST_NET_SRESTORE_TO_ZERO
= False and MAX_DELTA_SRESTORE = 5. I think with all the Antarctic runoff
input at the surface next to the coast, we get a really extreme coastal
freshening. Ramping up MAX_DELTA_SRESTORE = 5 (same as GFDL OM4 setting)
acts to counteract the coastal freshening. Wilton's previous case had the
same high settings, but without ADJUST_NET_SRESTORE_TO_ZERO = False and
that did next to nothing, so I think with the global offset to zero the
restoring, we must have ended up putting the wrong sign restoring flux in
some places.
We're running with these settings for the panan production runs now.
—
Reply to this email directly, view it on GitHub
https://github.com/COSIMA/mom6-panan/issues/40#issuecomment-1563764660,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABSWJXFKFBEU4CD5W2GFOCLXIAPOFANCNFSM6AAAAAAW4S7JMY
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

--
I’m sending this message at a time that suits me. I don’t expect you to
reply outside of your own work hours.
Paul Spence, Assoc. Prof.
ARC Future Fellow
Institute for Marine and Antarctic Studies https://www.imas.utas.edu.au/
University of Tasmania, Hobart, Australia
https://paulspence.github.io/


Clean up subscription if unsubscription request fails

If an unsubscription request fails, the Subscription object is not properly cleaned up. This can lead to dangling failed subscriptions which conflict with attempts to recreate new subscriptions.
The call to _cancel_subscription is currently called in request failure scenarios for both subscriptions and renewals, but not after unsubscription request failures:
https://github.com/SoCo/SoCo/blob/5602d2880af8a3daa9158a2982fca8130d41b13f/soco/events_asyncio.py#L367-L368
https://github.com/SoCo/SoCo/blob/5602d2880af8a3daa9158a2982fca8130d41b13f/soco/events_asyncio.py#L418-L419

Coverage decreased (-0.01%) to 52.696% when pulling 7b333364c39ca105620e2791c96feba218991ef3 on jjlawren:clean_up_unsubscriptions_after_exception into 5602d2880af8a3daa9158a2982fca8130d41b13f on SoCo:master.

Along with this I think it would be prudent to downgrade this message level to debug:
https://github.com/SoCo/SoCo/blob/5602d2880af8a3daa9158a2982fca8130d41b13f/soco/events_base.py#L664

Along with this I think it would be prudent to downgrade this message level to debug:
https://github.com/SoCo/SoCo/blob/5602d2880af8a3daa9158a2982fca8130d41b13f/soco/events_base.py#L664

LGTM. Do you want to make the log severity change as part of this PR, or as a separate one? If the latter, I'll proceed with the merge.


Award Points Manually

Acceptance Criteria:
Depends on #194

[ ] create permission that will allow certain users to manually award/subtract points
[ ] create api route that allows user award points to another user

[ ] restrict this to users with award points permission
[ ] prevent users from awarding points to themselves
[ ] require award amount to be a full number
[ ] require award amount to be greater than 0
[ ] set limit for how much can be awarded

[ ] create UI for awarding points

No longer relevant as the backend system is happening in a separate app now.


Update osculator to 3.1.2-63-gb9634423,2356a19f-47c4-4689-9f3b-5f5c83d6c85f

After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} left no offenses.
[x] The commit message includes the cask’s name and version.

Running script.sh...

>>> brew cask _audit_modified_casks 8dae8fb6565602711994c576b00b9156b6329760...e3ea776e0367a10a778defa359903b42e9cfe799
==> 1 modified cask: osculator
==> Downloading https://distribution.wildora.net/products/osculator-v3/revisions/2356a19f-47c4-4689-9f3b-5f5c83d6c85f/osculator-3.1.2-63-gb9634423.dmg
==> Verifying checksum for Cask osculator
audit for osculator: passed

>>> brew cask style Casks/osculator.rb

1 file inspected, no offenses detected

>>> brew cask reinstall --verbose Casks/osculator.rb
==> Satisfying dependencies
==> Downloading https://distribution.wildora.net/products/osculator-v3/revisions/2356a19f-47c4-4689-9f3b-5f5c83d6c85f/osculator-3.1.2-63-gb9634423.dmg
Already downloaded: /Users/travis/Library/Caches/Homebrew/Cask/osculator--3.1.2-63-gb9634423,2356a19f-47c4-4689-9f3b-5f5c83d6c85f.dmg
==> Verifying checksum for Cask osculator
==> Installing Cask osculator
==> Purging files for version 3.1.2-63-gb9634423,2356a19f-47c4-4689-9f3b-5f5c83d6c85f of Cask osculator
Error: It seems the App source '/usr/local/Caskroom/osculator/3.1.2-63-gb9634423,2356a19f-47c4-4689-9f3b-5f5c83d6c85f/OSCulator ƒ/OSCulator.app' is not there.
Error: Kernel.exit


Check $currentRange variable exists before calling overlaps() function

Thanks for the contribution!  I've included this in PR #78.


new dependency isn't added to lock file

To reproduce:
mkdir oops
cd oops
rebar3 compile
cat rebar.lock
echo '{deps, [cf]}.' > rebar.config
rebar3 compile
cat rebar.lock

Hah, yup, I figured it out. It is only the case if the lock file is empty :). If the lock file already had something it would properly add it. Should be easy to fix.

https://github.com/rebar/rebar3/pull/834 fixes


Compiled Ramdascript does not import the Ramda library

When I tried to compile Ramdascript to javascript with the following command:
ram compile -src server/server.ram -format none
It compiled without error however when trying to run the file it throws an error that R is not defined. This is due to the fact that the compiled file never imports the ramda library. A workaround for now is to manually add the line 'R = require('ramda') at the top of each compiled file but it's not ideal.

Try:
ram compile -src server/server.ram -format cjs

or just
ram compile -src server/server.ram

The -format CLI option specifies the module format of the resulting JS. As of you provide none the compiler does not add the requires to the header, because it is a specific for CommonJS idiom. So, you can either provide -format cjs or leave it without specify -in this case RamdaScript will use CommonJS (cjs) as default-

Okay I tried to compile it using -format cjs but it yields the error
`/usr/local/lib/node_modules/ramdascript/src/compiler.js:385
Object.keys(ctx.definedVars).forEach(function(name, idx, arr){
^
TypeError: Cannot convert undefined or null to object
at Function.keys ()
at writeCommonJSStub (/usr/local/lib/node_modules/ramdascript/src/compiler.js:385:12)
at Object.astToChunks (/usr/local/lib/node_modules/ramdascript/src/compiler.js:423:13)
at srcToChunks (/usr/local/lib/node_modules/ramdascript/src/ramdascript.js:53:25)
at Object.compile (/usr/local/lib/node_modules/ramdascript/src/ramdascript.js:23:18)
at /usr/local/lib/node_modules/ramdascript/src/cli.js:202:26
at tryToString (fs.js:514:3)
at FSReqWrap.readFileAfterClose [as oncomplete] (fs.js:502:12)`
but it compiles with -format none. This was tested with a file that just contains (console.log 'hello')

Nice catch! let me know if this works for you

Tested it and it works now. Thanks, this is a fantastic project.


[analyzer] Test static files are not formatted

Running npm run format in the analyzer package changes a lot of the files in src/test/static. However, formatting these requires updates to the assertions, as the sourceRange would be changed. Either we should ignore src/test/static in the formatter, or we should format them and update the assertions accordingly.

@rictic Would you be okay if I formatted all these files and then fixup any test failures? Should be quite straightforward


Release Camunda Modeler v5.5.1

What's inside?
This is a bug fix release addressing a C7 properties panel bug.

https://github.com/camunda/camunda-modeler/pull/3306
https://github.com/camunda/camunda-modeler/issues/3304
https://github.com/camunda/camunda-modeler/issues/3303
https://github.com/camunda/camunda-modeler/pull/3309

Release Checklist
To be done immediately after creating this issue.

[ ] ~add Slack role to release manager (@modeling-release-manager)~

To be done to prepare and build the release.

[x] make sure changes in upstream libraries are merged and released

bpmn-js, dmn-js, *-properties-panel, *-moddle, camunda-bpmn-js, form-js, ...

[x] make sure dependencies to upstream libraries are updated and can be installed (rm -rf node_modules && npm i && npm run all works)
[x] close all issues which are solved by dependency updates
[x] smoke test to verify all diagrams can be created
[ ] ~update Release Info~
[x] update CHANGELOG (https://github.com/camunda/camunda-modeler/pull/3309)
[x] create release (npm run release), cf. release schema

[x] wait for release build to create the artifacts

[x] prepare a list of what was changed or needs to be tested
[x] execute integration test, verifying fixed things are actually fixed
[ ] optionally trigger QA for testing

To be done to make the release publicly available.

[x] publish release on Github Releases
[x] trigger mirroring of release to Camunda Download Center via Jenkins
[x] request marketing to update the downloads page via request form
[x] add new version to update server releases (https://github.com/camunda/camunda-modeler-update-server/pull/103)
[ ] publish release via update server (push to live)

I did a smoke test and verified the fixes on Windows. ✅

Requested website update.

All done. Closing this issue.


Noscript error when deployed on Kubernetes with Nginx Ingress

Version
2.6.11
Reproduction link
https://github.com/TallamQuiz/tallam
Steps to reproduce
Deploy an EKS Kubernetes Cluster With Nginx Ingress and NLB.
Build the docker image :
`
FROM node:lts-alpine
RUN npm install -g http-server
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build
EXPOSE 8080
CMD [ "http-server", "dist", "-p", "80"]
`
Deploy the following service/deployment :
apiVersion: v1
kind: Service
metadata:
  name: backoffice-service
  namespace: internal
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  selector:
    app.kubernetes.io/name: app-backoffice
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-backoffice
  namespace: internal
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: app-backoffice
  replicas: 1
  revisionHistoryLimit: 3
  template:
    metadata:
      labels:
        app.kubernetes.io/name: app-backoffice
    spec:
      containers:
        - name: app-backoffice
          image: backoffice:0.0.1
          imagePullPolicy: Always
          ports:
            - containerPort: 80

Deploy the Ingress
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-tallam-internal
  namespace: internal
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
    nginx.ingress.kubernetes.io/force-ssl-redirect: "false"
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - http:
        paths:
        - path: /backoffice/*
          backend:
              serviceName: backoffice-service
              servicePort: 80

See that the no script error is shown
What is expected?
the project should be served on /backoffice and should be displayed
What is actually happening?
The div app is empty and the no script error is raised while JS is enable in browser

I want to run a vue app on an EKS Cluster with Nginx Ingress and NLB for balancing.
I have tried to set the baseUrl to /backoffice like in the ingress but it doesn't change a thing.
The browser gets 200 on all the files but the app div is empty and the no script error is raised. Also, an unexpected < is found in the console.

Hi, thanks for your interest but Github issues are for bug reports and feature requests only. You can ask questions on the forum, the Discord server or StackOverflow.


nixos/stage-1-systemd: fix initrd-fstab generation for bind mounts

Description of changes
To fix compatibility with https://github.com/nix-community/impermanence

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Interesting. For reference, here's how the scripted initrd does it:
https://github.com/NixOS/nixpkgs/blob/d3fc75cb6c45d8a2fd41873dab367490824843c7/nixos/modules/system/boot/stage-1-init.sh#L512-L532
The way it's done in this PR is probably better, right?

I think both approaches are kinda a hack, I'm not aware whether any other filesystems also takes a path as the device argument.

@NickCao Just curious: how does this fix compatibility with Impermanence? I ask since it doesn't make any of its bind mounts neededForBoot, so as long as you're not persisting any of these paths, it would work without this change. I assume you're persisting one of these paths (or setting the mounts manually to neededForBoot for whatever reason)?

Ah, I failed to make that clear. I am using impermanence yo persist the paths you mentioned.

Btw it seems like this might actually be considered a bug by the systemd folks. Though it appears there's been no activity to try and fix it aside from one person making some commits that don't seem to have made it into a PR even.

Reminder for myself: revert this once https://github.com/systemd/systemd/pull/28385 hits systemd-stable.

@NickCao Oh whoa they fixed it upstream. That's awesome


Publish under both CJS and ESM

For projects that use CJS, it's not possible to use this library. This is a huge usage blocker for some projects.

Fixed in #5 by @crutchcorn (💜 thanks).
Included in release v1.0.3

Just as a heads up @blahah I think this issue is requesting the opposite of what my PR did 😅
Currently, as I recall, we publish ESM only, as does the Unified ecosystem.

Hm. Grumble grumble. I understand that ESM is handy and the way of the future, but there are ways to develop in ESM, and publish in both. I hoped that this could have been the resolution.

Ah, how silly of me. I parsed the issue wrongly. Sorry @kaspar-p (and thank you @crutchcorn for pointing it out).
Hmm, I also did not do a major version bump as I should have when publishing the ESM change.
As to the first problem - @kaspar-p , can you not just depend on the previous CJS version (v1.0.2)? There are no functional changes in the ESM update.
As to the second - @crutchcorn, thoughts about whether to unpublish and do a major bump? Unfortunately the module is widely used so it might already have caused a problem for some.

I would see if you're able to unpublish and republish under a 2.0. However, I suspect NPM might disallow it 😅

Ah it was too late - others have already published updates depending on the new version! Lesson learned for future: don't publish when sleep deprived.

I just read this thread after posting #12. Like I mentioned there, the solution is to publish 1.0.2 (the last CJS version) as version 1.0.4, and then just publish the ESM version as 2.0.0.

Solved, everything’s ESM-only now, no plans to add dual.


AI内容安全插件 panic 错误

If you are reporting any crash or any potential security issue, do not
open an issue in this repo. Please report the issue via ASRC(Alibaba Security Response Center) where the issue will be triaged appropriately.

[x] I have searched the issues of this repository and believe that this is not a duplicate.

Ⅰ. Issue Description
请求上游阿里云内容安全服务时，插件报 panic: runtime error: index out of range 错误
Ⅱ. Describe what happened
If there is an exception, please attach the exception trace:
2024-10-08T09:03:08.776386Z     debug   envoy wasm external/envoy/source/extensions/common/wasm/context.cc:1384 wasm log higress-system.ai-security-guard-1.0.0: http call end, id: 7438aa55-1860-42d9-a3e8-92f4c52a2036, code: 200, normal: true, body: {"RequestId":"289A0546-6BCB-5239-A039-B00B77C38C94","Message":"OK","Data":{"RiskLevel":"high","Result":[{"Description":"命中自定义库","CustomizedHit":[{"LibName":"暴恐","KeyWords":"法~抡,法~仑,法~掄,法~沦,法~伦,法~侖,法~倫"},{"LibName":"政治","KeyWords":"政府,多党,共产党"},{"LibName":"反动","KeyWords":"主权"},{"LibName":"违禁词","KeyWords":"民主,多党,共产党"},{"LibName":"短信违禁词","KeyWords":"民主,共产,共产党"}],"Confidence":100.0,"Label":"customized"}]},"Code":200}       thread=276
2024-10-08T09:03:08.776440Z     info    envoy wasm external/envoy/source/extensions/common/wasm/context.cc:1387 wasm log higress-system.ai-security-guard-1.0.0: panic: runtime error: index out of range       thread=276
2024-10-08T09:03:08.776544Z     error   envoy wasm external/envoy/source/extensions/common/wasm/wasm_vm.cc:41   Function: proxy_on_http_call_response failed: Uncaught RuntimeError: unreachable\nProxy-Wasm plugin in-VM backtrace:\n  0:  0x2e25b - runtime.runtimePanicAt\n  1:  0x1cd8b - runtime.lookupPanic\n  2:  0x5fd3c - main.onHttpResponseBody$1\n  3:  0x5c94d - github.com/alibaba/higress/plugins/wasm-go/pkg/wrapper.HttpCall$1\n  4:  0x4daa9 - proxy_on_http_call_response    thread=276
2024-10-08T09:03:11.195680Z     info    xdsproxy        connected to upstream XDS server: <IP_ADDRESS>:15012

Ⅲ. Describe what you expected to happen
Ⅳ. How to reproduce it (as minimally and precisely as possible)

xxx
xxx
xxx

Ⅴ. Anything else we need to know?
Ⅵ. Environment:

Higress version:
OS :
Others:

cc @rinfx

原因已经定位，问题代码如下：
https://github.com/alibaba/higress/blob/main/plugins/wasm-go/extensions/ai-security-guard/main.go#L403
if config.protocolOriginal {
	jsonData = []byte(denyMessage)
} else if strings.Contains(strings.Join(hdsMap["content-type"], ";"), "event-stream") {
	randomID := generateRandomID()
	jsonData = []byte(fmt.Sprintf(OpenAIStreamResponseFormat, randomID, model, respAdvice.Array()[0].Get("Answer").String(), randomID, model))
} else {
	randomID := generateRandomID()
	jsonData = []byte(fmt.Sprintf(OpenAIResponseFormat, randomID, model, respAdvice.Array()[0].Get("Answer").String()))
}

前面的代码都对 respAdvice 进行了判定，这里没有。整个插件里对各种 array 是否为空都没有做比较严格的判定。建议对代码进行重构，精简冗余代码，完善边界判定。

已修复 #1394


🔄 Synced file(s) with WordPress/openverse

Synced local file(s) with WordPress/openverse.

Changed files

Synced local  .github/workflows/pr_label_check.yml with remote  .github/workflows/pr_label_check.yml

This PR was created automatically by the repo-file-sync-action workflow run #1263955543

Closing in favour of WordPress/openverse#76.


Timestamp Index

I'm getting the following error in my code when I try to scan a table that has a index that has a Sort Index for the property createdAt.
Is there any reason for this happening and how to fix it?
ValidationException: One or more parameter values were invalid: Type mismatch for Index Key createdAt Expected: S Actual: N IndexName: url-createdAt-index-1
    at Request.extractError (/home/ubuntu/node/node_modules/aws-sdk/lib/protocol/json.js:48:27)
    at Request.callListeners (/home/ubuntu/node/node_modules/aws-sdk/lib/sequential_executor.js:105:20)
    at Request.emit (/home/ubuntu/node/node_modules/aws-sdk/lib/sequential_executor.js:77:10)
    at Request.emit (/home/ubuntu/node/node_modules/aws-sdk/lib/request.js:683:14)
    at Request.transition (/home/ubuntu/node/node_modules/aws-sdk/lib/request.js:22:10)
    at AcceptorStateMachine.runTo (/home/ubuntu/node/node_modules/aws-sdk/lib/state_machine.js:14:12)
    at /home/ubuntu/node/node_modules/aws-sdk/lib/state_machine.js:26:10
    at Request.<anonymous> (/home/ubuntu/node/node_modules/aws-sdk/lib/request.js:38:9)
    at Request.<anonymous> (/home/ubuntu/node/node_modules/aws-sdk/lib/request.js:685:12)
    at Request.callListeners (/home/ubuntu/node/node_modules/aws-sdk/lib/sequential_executor.js:115:18)
    at Request.emit (/home/ubuntu/node/node_modules/aws-sdk/lib/sequential_executor.js:77:10)
    at Request.emit (/home/ubuntu/node/node_modules/aws-sdk/lib/request.js:683:14)
    at Request.transition (/home/ubuntu/node/node_modules/aws-sdk/lib/request.js:22:10)
    at AcceptorStateMachine.runTo (/home/ubuntu/node/node_modules/aws-sdk/lib/state_machine.js:14:12)
    at /home/ubuntu/node/node_modules/aws-sdk/lib/state_machine.js:26:10
    at Request.<anonymous> (/home/ubuntu/node/node_modules/aws-sdk/lib/request.js:38:9)

@nbarnett Is this a duplicate of #226, or not?

I don't think so. It's been a little while, but from memory #226 was specific to an issue with updatedAt but was fine with using createdAt. This issue looks like its to do with the type associated with createdAt. Expected: S Actual: N makes me think that createdTime is being stored as an ISO string, but is being passed a UNIX timestamp

@nbarnett Ok thanks! Maybe @brandongoode will have ideas about this.

Hello @fishcharlie what's the status on this one? We are currently seeing it in one of our model with a global index with createdAt as the range key.


autoscaling:GetAsgForInstance is not a valid policy action

I have issues
I'm submitting a...

[x ] bug report
[ ] feature request
[ ] support request
[ ] kudos, thank you, warm fuzzy

What is the current behavior?
When creating an EKS cluster with this module, the worker node autoscaling policy bears a warning:
Unrecognized actions
GetAsgForInstance

If this is a bug, how to reproduce? Please include a code sample if relevant.
Configure a terraform codebase to use terraform-aws-eks module to create a cluster.
The behaviour I'm seeing is described exactly here https://github.com/kubernetes/kops/issues/5549
What's the expected behavior?
No warnings should be issued against the auto-generated worker node policy
Are you able to fix this problem and submit a PR? Link here if you have already.
I might be able to look into it, as a PR in kops has been merged already.
I believe the bug has been introduced (or rather "pulled in" from kops) here:
https://github.com/terraform-aws-modules/terraform-aws-eks/issues/78
the bug was reported against kops here:
https://github.com/kubernetes/kops/issues/5549
and has been fixed here:
https://github.com/kubernetes/kops/pull/5566
Environment details

Affected module version: 1.8.0
OS: Mac OS X 10.13.6
Terraform version: 0.11.11

Any other relevant info

This has been fixed.


move go module to v2

With the advent of Podman 2.0.0 we crossed the magical barrier of go
modules.  While we were able to continue importing all packages inside
of the project, the project could not be vendored anymore from the
outside.
Move the go module to new major version and change all imports to
github.com/containers/libpod/v2.  The renaming of the imports
was done via gomove [1].
[1] https://github.com/KSubedi/gomove
Signed-off-by: Valentin Rothberg<EMAIL_ADDRESS>

LGTM

/hold

/lgtm

LGTM

/lgtm

@mheon can we have this in v2 branch as well before we cut a new release please?

@mheon can we have this in v2 branch as well before we cut a new release please?

https://github.com/containers/libpod/pull/6865 in progress :)

/hold cancel


Yarn v2 Upgrade

Other information
Updated yarn version to v2 (berry).

PR Checklist

Toggle...
What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting)
[ ] Refactoring (no functional changes)
[ ] Documentation changes
[x] Other - Please describe:

Please check all that apply to this PR using "x":

[x] I have checked that this PR is not a duplicate of an existing PR (open, closed or merged)
[x] I have checked that this PR does not introduce a breaking change
[ ] This PR introduces breaking changes and I have provided a detailed explanation below

What are the benefits and implications of upgrading?
We still have another big upgrade pr that we haven't pushed yet due to potential breaking changes.

What are the benefits and implications of upgrading?
We still have another big upgrade pr that we haven't pushed yet due to potential breaking changes.

@tzarebczan check the full changelog:
https://dev.to/arcanis/introducing-yarn-2-4eh1

hmm checking

I will also test the dev server first also


Dataset cleanup

ValueStore now maintains validation cache info across Commit() calls,
so we can remove a workaround in Dataset.Commit()
Update comment for setNewHead
setNewHead was decomposing a Commit object just so it could pass the pieces to Dataset.Commit()...which put them all back together again. Seemed silly.

PTAL

lgtm. let's wait on response from @arv

I walked through all the code here and NewCommit with the same value, parents and meta produces an identical Commit object.
LGTM


Add Time feature for Search

We should add the time feature in Search option and it will display all the recipes which take lesser time than the given time so whenever users want to search quick recipes with ingredients they can do it easily.

Feature added


Superatoms stick together when they move on top of each other

Preconditions:
Chain structure with at least 2 Superatom S-Groups is already exist.
Steps to Reproduce:

Select part of structure with Superatom and move it to another Superatom.
Select again this Superatom and move it back.

Expected Result:
Superatoms moves without problems and separately of each other.
Actual Result:
Superatoms are sticked together (see Attachment).

Issue is discussed with @AlexanderSavelyev  19/2/2021.
Issue is not a bug, closed as won't fix.


Fix Works About or Depicting People and Groups search links

Problem Description:
The links in the Works About or Depicting People and Groups accordion on concept pages currently returns an error.
Expected Behavior/Solution:
The links should redirect to the results page with valid results.
Requirements:

[x] Update the formatSearchJson function

Needed for promotion:
If an item on the list is not needed, it should be crossed off but not removed.

[ ] ~Wireframe/Mockup - Mike~
[ ] ~Committee discussions - Sarah~
[ ] ~Feasibility/Team discussion - Sarah~
[ ] ~Backend requirements - TBD~
[ ] Frontend requirements - Kam
[ ] ~Questions~

UAT/LUX Examples:

https://lux-front-dev.collections.yale.edu/view/concept/bf572421-ad85-4b8b-9d14-d631371375df --> Test any Show all x results links in the Works About or Depicting People and Groups accordion

Dependencies/Blocks:
N/A
Related Github Issues:
N/A
Related links:

Bugherd: https://www.bugherd.com/projects/284041/tasks/2079

Wireframe/Mockup:
There should be no change to the frontend.

Per UAT this is approved.

Looks good in prod, closing


Rendering issue with mini-react

What?
Look like there are some issues when the first component is removed from the tree.

Following component has two or more children with the same key attribute: "89". This may cause glitches and misbehavior in rendering process.

How to reproduce?

Create checkout extension via shopify extension create
Use below package.json and the extension script
Run the extension with yarn server. Also run ngrok tunnel on port 8910 in differen terminal.
Run Checkout Web and add DevRuntimeExtension

<DevRuntimeExtension script="https://98b77261b0bb.ngrok.io/assets/extension.js" />

Verify that the extension is rendered as normal.
Type in the search field to the the result.

Type 1, verify the filter works fine, no exception in console.
Type 2, verify the last item (Add Random Item) button is duplicated => This is the issue.

package.json
{
  "name": "checkout-ui-extensions-template",
  "version": "0.1.0",
  "engines": {
    "node": ">=10.16.0"
  },
  "repository": "https://github.com/Shopify/checkout-ui-extensions-template.git",
  "author": "Shopify<EMAIL_ADDRESS>  "license": "MIT",
  "devDependencies": {
    "@shopify/checkout-ui-extensions-run": "0.7.0",
    "@types/prettier": "^2.1.5",
    "@typescript-eslint/eslint-plugin": "^4.15.0",
    "@typescript-eslint/parser": "^4.15.0",
    "eslint": "^7.19.0",
    "eslint-config-prettier": "^7.2.0",
    "eslint-plugin-prettier": "^3.3.0",
    "eslint-plugin-react": "^7.22.0",
    "prettier": "^2.1.2",
    "typescript": "^4.1.0"
  },
  "scripts": {
    "build": "checkout-ui-extensions-run build",
    "server": "yarn start",
    "start": "checkout-ui-extensions-run serve",
    "lint": "eslint 'src/**'",
    "type-check": "tsc --pretty"
  },
  "dependencies": {
    "@remote-ui/mini-react": "^1.3.5",
    "@shopify/checkout-ui-extensions": "0.12.0",
    "@shopify/checkout-ui-extensions-react": "0.12.0"
  }
}

Extension script
import {useState} from '@remote-ui/mini-react';
import {
  render,
  TextField,
  TextBlock,
  BlockStack,
  Checkbox,
  InlineStack,
  Button,
} from '@shopify/checkout-ui-extensions-react';

function CheckboxExample() {
  const [fooChecked, setFooChecked] = useState(false);
  const [barChecked, setBarChecked] = useState(false);

  return (
    <>
      <BlockStack>
        <InlineStack>
          <Checkbox
            checked={fooChecked}
            onChange={(newValue) => setFooChecked(newValue)}
          />
          <TextBlock>Foo</TextBlock>
        </InlineStack>
        <InlineStack>
          <Checkbox
            value={barChecked}
            onChange={(newValue) => setBarChecked(newValue)}
          />
          <TextBlock>Bar</TextBlock>
        </InlineStack>
      </BlockStack>
    </>
  );
}

function ListExample() {
  const [dataList, setDataList] = useState([1, 2, 3, 4, 5, 12, 13, 145]);

  const [resourceListQuery, setResourceListQuery] = useState('');
  const [selectedItems, setSelectedItems] = useState<number[]>([]);
  const [listItems, setListItems] = useState(dataList);

  return (
    <>
      <TextField
        label="Search..."
        value={resourceListQuery}
        onInput={(query) => {
          setResourceListQuery(query);
          setListItems(
            dataList.filter((item) => item.toString().includes(query))
          );
        }}
      />
      {listItems.map((item, index) => (
        <InlineStack alignment="center" key={item}>
          <Checkbox
            checked={selectedItems.includes(item)}
            onChange={() => {
              console.log('ResourceList item toggle:', item);
              if (selectedItems.includes(item)) {
                setSelectedItems(
                  selectedItems.filter((_item) => _item !== item)
                );
              } else {
                setSelectedItems(selectedItems.concat(item));
              }
            }}
          />
          <TextBlock>Every {item} week or 15 days * 20-25% off</TextBlock>
          <TextBlock>{item} product</TextBlock>
        </InlineStack>
      ))}
      <Button
        onPress={() => {
          setDataList([...dataList, Math.floor(Math.random() * 100)]);
          setResourceListQuery('');
          setListItems(dataList);
        }}
      >
        Add Random Item
      </Button>
    </>
  );
}

function App({extensionPoint}: {extensionPoint: string}) {
  const [count, setCount] = useState(0);

  return (
    <BlockStack>
      <TextBlock>
        Welcome to the {extensionPoint} extension! {count}
      </TextBlock>
      <TextField
        label="Order note"
        onInput={(value) => {
          setCount(value.length);
        }}
      />
      <CheckboxExample />
      <ListExample />
    </BlockStack>
  );
}

render('Checkout::Feature::Render', ({extensionPoint}) => (
  <App extensionPoint={extensionPoint} />
));

render('Checkout::KitchenSink', ({extensionPoint}) => (
  <App extensionPoint={extensionPoint} />
));

I narrow down the issue:

✅ The initial render is fine
❌ It's wrong when the tree is update, specifically when the extension renders a list of items.

renderComponent is called when typing to the TextField which will render the list https://github.com/Shopify/remote-ui/blob/85ce495780a6a342b8eb064c0e3c2dfc35b1cf6b/packages/mini-react/src/diff/diff.ts#L105. The vnode is correct. See below screenshot.
The newRemoteNode is wrong after calling diff https://github.com/Shopify/remote-ui/blob/85ce495780a6a342b8eb064c0e3c2dfc35b1cf6b/packages/mini-react/src/diff/diff.ts#L115. So, I think something wrong with the diff function. However, it's too nested and I could find where the bug is. See below screenshot.

cc @lemonmade

I found there are 2 places that remote-ui mini-react has custom implementation compared to preact.

The logic of resolvedOldRemoteNode here https://github.com/Shopify/remote-ui/blob/85ce495780a6a342b8eb064c0e3c2dfc35b1cf6b/packages/mini-react/src/diff/diff.ts#L759-L772. Preact doesn't have to custom oldDom https://github.com/preactjs/preact/blob/master/src/diff/children.js#L35
From what I debug (with similar layout), excessDomChildren when rendering array list from preact is an empty array https://github.com/preactjs/preact/blob/master/src/diff/index.js#L302 while in mini-react it's an array of all previous rendered components.


New user onboarding failing using greymass fuel

Confirmed on both desktop and mobile
Fresh Anchor install and fresh Greymass account jt.gm
Buying RAM at wallet.telos.net should work with Greymass Fuel with 0 CPU and 0 NET
What the user sees:

Browser Debug:

Missing Signature for Cosign?
1. {signatures: [,…], compression: 0, packed_context_free_data: "00",…} 	1. compression: 0 	2. packed_context_free_data: "00" 	3. packed_trx: "b4e16166b9d7b167f706000000000250299d181be9d565000000000050299d0110955e181be9d565000000004ce63045000000000000ea3055000000004873bd3e010000000000c9407e00000000a8ed3232200000000000c9407e0000000000c9407ee80300000000000004544c4f5300000000" 	4. signatures: [,…] 0: "SIG_K1_KXMuQd72fndtFgMkxS9xQ83SRkp1Q69DSfNDHzzDPaML9znotWT7rXDuKMiJ97Q9iVAQNXA6WjzkbtYwabg8SY4BGL1jV4"
I believe it should actually look like this:
1. {signatures: [,…], compression: 0, packed_context_free_data: "00",…} 	1. compression: 0 	2. packed_context_free_data: "00" 	3. packed_trx: "4ad66166c9dc80191b31000000000250299d181be9d565000000000050299d0110955e181be9d565000000004ce63045000000000000ea3055000000004873bd3e010000000000c9407e00000000a8ed3232200000000000c9407e0000000000c9407ee80300000000000004544c4f5300000000" 	4. signatures: [,…] 		1. 0: "SIG_K1_JypiKQ79r41WS87pvTWyoRComDBhjXWak3q7KA19gAQduL2T9eoJAqubnb5ezm146mZPeoyXA2DCMm2ijEs68g3CBZRtuu" 1: "SIG_K1_KbA3DiWbxPUEs4H3X4VmJ71dfExk4ZTSkogpKHiekt1MUgHjurKoQTGTS5nhWisTMQq7fnt5pcZRYV1SRP3M1xX7iwQKbJ"

That Resource Warning Dialog was removed a while ago, so I'm guessing you were not using the latest version where this was fixed. However, Justin found another related issue in the latest version that I just fixed here.
If you want to try again in this new version, you would need to pull the branch 817-fuel-service-not-working-as-expected to your PC and run it locally (since the GitHub Netlify deployment was created only for Testnet).


Added Linux instructions to README.md

Hi Jean-Christophe,
i've added some instructions how to use and install on (Ubuntu) Linux.
I don't know how to create an AppImage or other kind of binary on Linux like you did for MacOS and Windows - how did you do this?
kind regards
Christoph

Hi @happenpappen,
To build a MacOS bundle or a Windows executable, I use the great https://pyinstaller.org.
But for mac, it's quite complex with the closed policies of Apple for packaging... (and on Arm64 + Intel x86 / x64 architectures with the universal2 file format).
After, I can compress it and prepare it in a custom disk image (.dmg) for MacOS and in a wizard setup for Windows :)


Event log file does not have headers or column names

I was running the how_to jupyter notebook (see the code that I ran below) and encounter the following errors. I think the issue is that the code expects the first column of the event log file to have the column names. I can resolve this issue by setting the read_option to be ReadOptions(autogenerate_column_names=True), but then another error popped up as the code is expecting the some fixed column names such as date_time.
Code
from time import perf_counter
from wombat import Simulation
from wombat.core.library import load_yaml, DINWOODIE

library_path = DINWOODIE
config = load_yaml(library_path / "project/config", "base.yaml")
sim = Simulation.from_config(config)
sim.env.cleanup_log_files()

start = perf_counter()
sim.run()
end = perf_counter()
timing = end - start
print(f"Run time: {timing / 60:,.2f} minutes")

Error Message
ValueError                                Traceback (most recent call last)
Cell In[2], line 2
      1 start = perf_counter()
----> 2 sim.run()
      3 end = perf_counter()
      4 timing = end - start

File ~/miniconda3/envs/wisdem/lib/python3.10/site-packages/wombat/core/simulation_api.py:326, in Simulation.run(self, until, create_metrics, save_metrics_inputs)
    324     self.save_metrics_inputs()
    325 if create_metrics:
--> 326     self.initialize_metrics()

File ~/miniconda3/envs/wisdem/lib/python3.10/site-packages/wombat/core/simulation_api.py:330, in Simulation.initialize_metrics(self)
    328 def initialize_metrics(self) -> None:
    329     """Instantiates the ``metrics`` attribute after the simulation is run."""
--> 330     events = self.env.load_events_log_dataframe()
    331     operations = self.env.load_operations_log_dataframe()
    332     power_potential, power_production = self.env.power_production_potential_to_csv(
    333         windfarm=self.windfarm, operations=operations, return_df=True
    334     )

File ~/miniconda3/envs/wisdem/lib/python3.10/site-packages/wombat/core/environment.py:679, in WombatEnvironment.load_events_log_dataframe(self)
    671 convert_options = pa.csv.ConvertOptions(
    672     timestamp_parsers=["%Y-%m-%d %H:%M:%S.%f", "%Y-%m-%d %H:%M:%S"]
    673 )
    674 parse_options = pa.csv.ParseOptions(delimiter="|")
    675 log_df = pa.csv.read_csv(
    676     self.events_log_fname,
    677     convert_options=convert_options,
    678     parse_options=parse_options,
--> 679 ).to_pandas()
    680 if not pd.api.types.is_datetime64_any_dtype(log_df.datetime):
    681     log_df.datetime = pd.to_datetime(
    682         log_df.datetime, yearfirst=True, format="mixed"
    683     )

File ~/miniconda3/envs/wisdem/lib/python3.10/site-packages/pyarrow/array.pxi:837, in pyarrow.lib._PandasConvertible.to_pandas()

File ~/miniconda3/envs/wisdem/lib/python3.10/site-packages/pyarrow/table.pxi:4114, in pyarrow.lib.Table._to_pandas()

File ~/miniconda3/envs/wisdem/lib/python3.10/site-packages/pyarrow/pandas_compat.py:819, in table_to_blockmanager(options, table, categories, ignore_metadata, types_mapper)
    816     ext_columns_dtypes = _get_extension_dtypes(table, [], types_mapper)
    818 _check_data_column_metadata_consistency(all_columns)
--> 819 columns = _deserialize_column_index(table, all_columns, column_indexes)
    820 blocks = _table_to_blocks(options, table, categories, ext_columns_dtypes)
    822 axes = [columns, index]

File ~/miniconda3/envs/wisdem/lib/python3.10/site-packages/pyarrow/pandas_compat.py:938, in _deserialize_column_index(block_table, all_columns, column_indexes)
    935     columns = _reconstruct_columns_from_metadata(columns, column_indexes)
    937 # ARROW-1751: flatten a single level column MultiIndex for pandas 0.21.0
--> 938 columns = _flatten_single_level_multiindex(columns)
    940 return columns

File ~/miniconda3/envs/wisdem/lib/python3.10/site-packages/pyarrow/pandas_compat.py:1184, in _flatten_single_level_multiindex(index)
   1182     # Cheaply check that we do not somehow have duplicate column names
   1183     if not index.is_unique:
-> 1184         raise ValueError('Found non-unique column index')
   1186     return pd.Index(
   1187         [levels[_label] if _label != -1 else None for _label in labels],
   1188         dtype=dtype,
   1189         name=index.names[0]
   1190     )
   1191 return index

ValueError: Found non-unique column index

First 4 lines of the event log file (note no column names)
2023-06-20 21:56:06.625773|2003-01-01 00:00:00|0|S00T1|subassemblies created: ['turbine']|windfarm initialization|initialization|S00T1|S00T1|||1.0|1|0|0|na|na|0|0|0|0|0|0
2023-06-20 21:56:06.657014|2003-01-01 00:00:00|0|S00T2|subassemblies created: ['turbine']|windfarm initialization|initialization|S00T2|S00T2|||1.0|1|0|0|na|na|0|0|0|0|0|0
2023-06-20 21:56:06.685828|2003-01-01 00:00:00|0|S00T3|subassemblies created: ['turbine']|windfarm initialization|initialization|S00T3|S00T3|||1.0|1|0|0|na|na|0|0|0|0|0|0

Hi @johnwang0576, not sure how I missed this, but in any case thanks for opening this up!
This is something that I've seen a couple of times, but stems from modifying the example workflow. In particular, sim.env.cleanup_log_files() deletes the initialized operations and events logging files, and therefore the headers contained inside. I recommend moving this to either the end of your analysis workflow, or removing it altogether if you plan to inspect the files later because sim.run() is recreating and writing to those files that have just been deleted.
Bellow, is what your example should look like to operate correctly. I'll be sure to update the documentation to be more clear about when users should and shouldn't run sim.env.cleanup_log_files().
from time import perf_counter
from wombat import Simulation
from wombat.core.library import load_yaml, DINWOODIE

library_path = DINWOODIE
config = load_yaml(library_path / "project/config", "base.yaml")
sim = Simulation.from_config(config)

start = perf_counter()
sim.run()
end = perf_counter()
timing = end - start
print(f"Run time: {timing / 60:,.2f} minutes")

sim.env.cleanup_log_files()  #  delete the events and operations CSV files


Lazy loading implementation

Lazy loading implemented as i proposed in GSOC'20 Ideas list
List of modules for which i have included lazy loading:

[x] Auth Module
[x] Challenge Module
[x] Publiclist Module

Work left to be done:

[ ] Certain enhancement is required, like these modules can be further divided into sub-modules to further improve the performance of the site.

GIF showing lazy route:

@Shekharrajak @lunayach @Sanji515 Can you please review this?

Codecov Report

Merging #303 into master will decrease coverage by 0.10%.
The diff coverage is 10.00%.

@@            Coverage Diff             @@
##           master     #303      +/-   ##
==========================================
- Coverage   50.63%   50.52%   -0.11%
==========================================
  Files          66       66
  Lines        3772     3782      +10
  Branches      444      444
==========================================
+ Hits         1910     1911       +1
- Misses       1767     1776       +9
  Partials       95       95

Impacted Files
Coverage Δ

...rc/app/components/challenge/challenge.component.ts
81.19% <10.00%> (-6.66%)
:arrow_down:

Impacted Files
Coverage Δ

...rc/app/components/challenge/challenge.component.ts
81.19% <10.00%> (-6.66%)
: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 e5816b9...5bfb3d8. Read the comment docs.

@Kajol-Kumari It seems you have refactored other modules also which are mentioned in this PR. Can you also please update the PR description with these changes.

@Sanji515 those modules are only refactored.Lazy loading implementation is still left to be done in those sub modules.

@Kajol-Kumari It seems you have refactored other modules also which are mentioned in this PR. Can you also please update the PR description with these changes.

@Sanji515 those modules are only refactored.Lazy loading implementation is still left to be done in those sub modules.

Yes, can you please mention that in the PR description.

@Kajol-Kumari I am seeing many changes than required for this PR. Do we need to merge any other PR before reviewing this?

@Kajol-Kumari I am seeing many changes than required for this PR. Do we need to merge any other PR before reviewing this?

@lunayach This PR includes refactoring part also as it is needed for lazy loading implementation. Also as suggested by @Sanji515 i closed the separate PR opened for refactoring and so this is the only pr containing both refactoring and lazy-loading.


(Direct2D] Add native drawing effect overload

Hello,
as per the issue discussed several times about passing Direct2D brush to a text layout, since modifying the old version breaks some samples, here is a simple overload to allow to simply pass a native pointer.
I'm fully aware that we could handle this a bit more gracefully, but sadly there are no ways to do so without breaking examples....

Fixed by commit 93b9840 (exposing directly the underlying method instead of creating a new one)

Ah indeed, even easier, missed that one.
Thanks!


migrated code into different files

Thanks @milancurcic for the reviews, and I will make sure to incorporate your suggestions in my future work.


ERROR: Unexpected bus error encountered in worker.

I get this error running the model on replicate for a 5 minute song (If I truncate the song to 1 minute it works.)
Any ideas?
ERROR: Unexpected bus error encountered in worker. This might be caused by insufficient shared memory (shm).

Hi,
Sorry for the delay reply, pretty busy these weeks.
When I process the 5-min song, the process is successful.
When the error is encountered is worker, I assume you could reduce the numworker to see if it goes well. And check the GPU memory and RAM to see if one of them exceed.


Archiving inline images

Dear ArchiveBox community,
I am attempting to migrate my archive from Wallabag to this platform. One feature I cannot seem to grasp is image saving.
In Wallabag, I have the option to (by default) link to images or, as I prefer for achival purposes, save images on a page with modified readability output replacing the hot link with a local copy and automatically editting the output of readability to avoid linking outside my network.
Does such a feature exist with ArchiveBox?
Thank you.

The Wget and Singlefile extractors in ArchiveBox both do as you describe, downloading all images locally and replacing the URLs to point to the local versions.
You can toggle this behavior for wget with the archivebox config --set SAVE_WGET_REQUISITES=True/False option.

I see my error. When I long press on Android it was giving me the original
URL but I see now when I copy-link-location it presents the base encoding.
Sorry to bother.
On Fri, Mar 12, 2021, 2:42 PM Nick Sweeting @.***>
wrote:

The Wget and Singlefile extractors in ArchiveBox both do as you describe,
downloading all images locally and replacing the URLs to point to the local
versions.
You can toggle this behavior for wget with the archivebox config --set
SAVE_WGET_REQUISITES=True/False option.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ArchiveBox/ArchiveBox/issues/661#issuecomment-797711779,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAON37DK3RCXKOA2QLLONUTTDJOBZANCNFSM4ZCOJVDQ
.


Support custom secondaryButton onClick in Modal component

A current pain point with using the Modal component is that the onRequestClose function is tightly shared with the secondaryButton onClick.  In our team’s use case, we are trying to build a multi-step modal experience where the close button onClick is different from the secondary button onClick.
We propose that the Modal component support providing separate callback functions for the close button onClick and the secondary button onClick, and can work on a PR that implements this change.

@chrisdhanaraj do you mind helping accept a PR if it comes your way ?

This sounds pretty reasonable to me, will review next week.
Just for our own context, can you upload a screenshot of the Modal experience you're trying to build? If not, can you explain what the secondary button would do other than "cancel"?

Here's our example. Step 1:

Step 2:

Bluemix toolchain: Delivery Pipeline deployed carbon-components-react to Bluemix Design System, including commit 5df6e30094eac4e28afe09f6ba46146cca6c9929


Run tests also with Selenium 3.x

There were 3 errored and 2 failing tests, see post below for analysis and how they were fixed.

1) Behat\Mink\Tests\Driver\Basic\IFrameTest::testIFrame
WebDriver\Exception\InvalidArgument: data did not match any variant of untagged enum FrameId at line 3 column 1

/home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/vendor/instaclick/php-webdriver/lib/WebDriver/Exception.php:198
/home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/vendor/instaclick/php-webdriver/lib/WebDriver/AbstractWebDriver.php:167
/home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/vendor/instaclick/php-webdriver/lib/WebDriver/Session.php:286
/home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/src/Selenium2Driver.php:426
/home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/vendor/behat/mink/src/Session.php:321
/home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/vendor/mink/driver-testsuite/tests/Basic/IFrameTest.php:17

2) Behat\Mink\Tests\Driver\Js\ChangeEventTest::testSetValueChangeEvent with data set "file" ('the-file', '/home/runner/work/MinkSeleniu...e1.txt', '/home/runner/work/MinkSeleniu...e2.txt')
WebDriver\Exception\InvalidArgument: File not found: /home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/vendor/mink/driver-testsuite/tests/Js/../../web-fixtures/file1.txt

/home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/vendor/instaclick/php-webdriver/lib/WebDriver/Exception.php:198
/home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/vendor/instaclick/php-webdriver/lib/WebDriver/AbstractWebDriver.php:167
/home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/vendor/instaclick/php-webdriver/lib/WebDriver/AbstractWebDriver.php:234
/home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/vendor/instaclick/php-webdriver/lib/WebDriver/Container.php:241
/home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/src/Selenium2Driver.php:679
/home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/vendor/behat/mink/src/Element/NodeElement.php:105
/home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/vendor/mink/driver-testsuite/tests/Js/ChangeEventTest.php:50

3) Behat\Mink\Tests\Driver\Js\WindowTest::testWindow
WebDriver\Exception\InvalidArgument: missing field `handle` at line 3 column 1

/home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/vendor/instaclick/php-webdriver/lib/WebDriver/Exception.php:198
/home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/vendor/instaclick/php-webdriver/lib/WebDriver/AbstractWebDriver.php:167
/home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/vendor/instaclick/php-webdriver/lib/WebDriver/Session.php:269
/home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/src/Selenium2Driver.php:418
/home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/vendor/behat/mink/src/Session.php:311
/home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/vendor/mink/driver-testsuite/tests/Js/WindowTest.php:17

1) Behat\Mink\Tests\Driver\Custom\TimeoutTest::testInvalidTimeoutSettingThrowsException
Failed asserting that exception of type "\Behat\Mink\Exception\DriverException" is thrown.

2) Behat\Mink\Tests\Driver\Js\EventsTest::testRightClick
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'right clicked'
+'single clicked'

/home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/vendor/mink/driver-testsuite/tests/Js/EventsTest.php:45

natively via webdriver it seems impossible/broken, contextClick method is also not supported, can be probably fixed by using syn.js https://github.com/minkphp/MinkSelenium2Driver/pull/358 for right click - https://github.com/bitovi/syn/blob/v0.15.0/test/mouse_button_test.js#L439

1) Behat\Mink\Tests\Driver\Basic\IFrameTest::testIFrame
WebDriver\Exception\InvalidArgument: data did not match any variant of untagged enum FrameId at line 3 column 1

/home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/vendor/instaclick/php-webdriver/lib/WebDriver/Exception.php:198
/home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/vendor/instaclick/php-webdriver/lib/WebDriver/AbstractWebDriver.php:167
/home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/vendor/instaclick/php-webdriver/lib/WebDriver/Session.php:286
/home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/src/Selenium2Driver.php:426
/home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/vendor/behat/mink/src/Session.php:321
/home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/vendor/mink/driver-testsuite/tests/Basic/IFrameTest.php:17

test must be fixed, only integer indexes are accepted, when string id is passed, the following exception is shown:
name key tested, but it is not supported, not handle, nor element itself (might be supported when serialized correctly, but the latest driver does not support it)
WebDriver\Exception\InvalidArgument: invalid argument: 'id' can not be string
(Session info: chrome=84.0.4147.105)
Build info: version: '3.141.59', revision: 'e82be7d358', time: '2018-11-14T08:25:53'
System info: host: 'DX6B48F375QD', ip: '<IP_ADDRESS>', os.name: 'Windows 10',
os.arch: 'amd64', os.version: '10.0', java.version: '12.0.2'

Does Selenium 3 still follow the JsonWire protocol, that allows id parameter to be a string (see https://www.selenium.dev/documentation/legacy/json_wire_protocol/#sessionsessionidframe)?
Otherwise, an upgrade Selenium is only removing stuff instead of adding it :( .
Offtopic:
Some time ago we're discussing another driver creation (like WebDriverDriver), that will use https://github.com/php-webdriver/php-webdriver (previously developed at Facebook) internally instead of https://github.com/instaclick/php-webdriver, which supports Selenium 2 only (as per the repo's README.md file).
There are also unmerged/closed PRs with attempts to use https://github.com/php-webdriver/php-webdriver in this driver instead.
Maybe we should move in that direction, @stof  ?

1) Behat\Mink\Tests\Driver\Basic\IFrameTest::testIFrame
WebDriver\Exception\InvalidArgument: data did not match any variant of untagged enum FrameId at line 3 column 1

Fixed in https://github.com/minkphp/MinkSelenium2Driver/pull/382 .
2) Behat\Mink\Tests\Driver\Js\ChangeEventTest::testSetValueChangeEvent with data set "file" ('the-file', '/home/runner/work/MinkSeleniu...e1.txt', '/home/runner/work/MinkSeleniu...e2.txt')
WebDriver\Exception\InvalidArgument: File not found: /home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/vendor/mink/driver-testsuite/tests/Js/../../web-fixtures/file1.txt

Fixed in https://github.com/minkphp/MinkSelenium2Driver/pull/385 .
3) Behat\Mink\Tests\Driver\Js\WindowTest::testWindow
WebDriver\Exception\InvalidArgument: missing field `handle` at line 3 column 1

Fixed in https://github.com/minkphp/MinkSelenium2Driver/pull/384 .
4) Behat\Mink\Tests\Driver\Custom\TimeoutTest::testInvalidTimeoutSettingThrowsException
Failed asserting that exception of type "\Behat\Mink\Exception\DriverException" is thrown.

Fixed in https://github.com/minkphp/MinkSelenium2Driver/pull/380 , but now test fails again, because no exception is thrown on Selenium 3: https://github.com/minkphp/MinkSelenium2Driver/issues/397 .
5) Behat\Mink\Tests\Driver\Js\EventsTest::testRightClick
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'right clicked'
+'single clicked'

/home/runner/work/MinkSelenium2Driver/MinkSelenium2Driver/vendor/mink/driver-testsuite/tests/Js/EventsTest.php:45

This will work only through actions and actions not supported in current https://github.com/instaclick/php-webdriver version. So dead end. Issue created: https://github.com/minkphp/MinkSelenium2Driver/issues/381 . Recommended switch to https://github.com/minkphp/webdriver-classic-driver driver if such functionality is needed.
Testing on Selenium 3 was added in https://github.com/minkphp/MinkSelenium2Driver/pull/383.
Closing.

Thank you. I am very happy this funcitonality has landed, but I am quite disappointed that I put a lot of efford into this 2 years ago fow nothing. It would be great to warm developers to not invest into this project any energy. I am sorry to say this. Have a great day!

@mvorisek , it wasn't for nothing. Every contribution is welcome. In this case, this was research work, that allowed PRs creation at a later time.
Due to limited maintainer time it might have looked abandoned, but it's not.

Thank you for taking care of this project.


Null safety migration feedback: test broken with 'Null' is not a subtype of type 'Object'

I have a Flutter plugin that I'm trying to migrate to null safety (https://github.com/MaikuB/flutter_local_notifications/tree/master/flutter_local_notifications_platform_interface). Unfortunately one of the tests is broken and I can't figure out why as it's similar to what the url_launcher platform interface is doing and the latter passes its tests. I've even tried removing a lot of code for both platform interfaces to be as close as possible but still have the same issue.
I've tried to create a minimal sample to reproduce the issue here. Running the tests via the flutter test command will fail with the following message
00:06 +0 -1: UrlLauncherPlatform Cannot be implemented with `implements` [E]
  Expected: throws <Instance of 'AssertionError'>
    Actual: <Closure: () => Null>
     Which: threw _TypeError:<type 'Null' is not a subtype of type 'Object'>
            stack package:plugin_platform_interface/plugin_platform_interface.dart 46:16              ImplementsUrlLauncherPlatform._instanceToken
                  package:plugin_platform_interface/plugin_platform_interface.dart 72:36              PlatformInterface.verifyToken
                  package:url_launcher_platform_interface/url_launcher_platform_interface.dart 23:23  UrlLauncherPlatform.instance=
                  url_launcher_platform_interface_test.dart 11:29                                     main.<fn>.<fn>.<fn>
                  package:test_api                                                                    expect
                  package:flutter_test/src/widget_tester.dart 429:3                                   expect
                  url_launcher_platform_interface_test.dart 10:7                                      main.<fn>.<fn>

            which is not an instance of 'AssertionError'

  package:test_api                                   expect
  package:flutter_test/src/widget_tester.dart 429:3  expect
  url_launcher_platform_interface_test.dart 10:7     main.<fn>.<fn>

Am I missing something or is there an issue that will need to be resolved? In case it helps the output of running flutter doctor -v is...
[✓] Flutter (Channel beta, 1.25.0-8.1.pre, on macOS 11.1 20C69 darwin-x64,
    locale en-AU)
    • Flutter version 1.25.0-8.1.pre at /Users/michaelbui/flutter
    • Framework revision 8f89f6505b (2 weeks ago), 2020-12-15 15:07:52 -0800
    • Engine revision 92ae191c17
    • Dart version 2.12.0 (build 2.12.0-133.2.beta)

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

[✓] Xcode - develop for iOS and macOS (Xcode 12.3)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.3, Build version 12C33
    • CocoaPods version 1.9.3

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

[✓] Android Studio (version 4.1)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6915495)

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

[✓] Connected device (1 available)
    • Chrome (web) • chrome • web-javascript • Google Chrome 87.0.4280.88

• No issues found!

P.S. Apologies if this is the wrong repo to report this. I have seen other similar issues opened here so I assume this is the right location.

To make the code more friendly, the declaration final Object _instanceToken; in package:plugin_platform_interface/plugin_platform_interface.dart 46:16 should probably be changed to final Object? _instanceToken; to allow for an uninitialized _instanceToken (i.e. null) as it seems to occur here.
But I am not familiar at all with this code, and it may not be the correct fix. Could @xster or @blasten have a look? Thanks.

To make the code more friendly, the declaration final Object _instanceToken; in package:plugin_platform_interface/plugin_platform_interface.dart 46:16 should probably be changed to final Object? _instanceToken; to allow for an uninitialized _instanceToken (i.e. null) as it seems to occur here.
But I am not familiar at all with this code, and it may not be the correct fix. Could @xster or @blasten have a look? Thanks.

Thanks @crelier for identifying the issue. Looks like the plugin_platform_interface has been updated and fixes the issue :)


ERROR:torch.distributed.elastic.multiprocessing.api:failed (exitcode: -6) local_rank: 1 (pid: 2960901)

Can you check this error for me? I trained with two Gpus. Whether the results of our experiments must be evaluated after training is the final method result.

It seems that this bug does not affect the final result of our method and can be ignored.

Hello, when I was training SGDet command, after iterating for a certain number of times, I always reported an error and continued training without sending. Do you know how to solve it？

It looks like there is an error on one of the GPUs, causing the whole task to fail. I didn't try multi-gpu training on this repo. If you have multiple gpus, you could try different tasks on each gpu.

其中一个 GPU 似乎存在错误，导致整个任务失败。我没有在这个存储库上尝试多 gpu 训练。如果您有多个 GPU，则可以在每个 GPU 上尝试不同的任务。

Okay, thank you


Asset editor animation transformed into a grey block

Describe the bug
I made a named animation, but later it changed to a gray block. The animation still works, but I can't enter the field editor anymore. This is the project: https://makecode.com/_3z0JTu41d5tC

To Reproduce
I haven't been able to repro yet - I only switched between Blocks and Asset Editor, never went to JS/PY, and noticed that my block had changed. When I import the project, the block is still grey
Desktop (please complete the following information):

OS: ChromeOS
Browser Chrome86

hmmmm i can't seem to repro it either. if i import that project, switch to javascript, make a change, and go back to blocks, it decompiles correctly

hmmmm i can't seem to repro it either. if i import that project, switch to javascript, make a change, and go back to blocks, it decompiles correctly

Resolve as can't repro if this doesn't reproduce. We can test again tomorrow.

Resolve as can't repro if this doesn't reproduce. We can test again tomorrow.

Can't repro! But I will try my darndest tomorrow 😈

Can't repro! But I will try my darndest tomorrow 😈


harfbuzz: 1.7.1 -> 1.7.5

Semi-automatic update. These checks were done:

built on NixOS
Warning: no binary found that responded to help or version flags. (This warning appears even if the package isn't expected to have binaries.)
found 1.7.5 with grep in /nix/store/6w64dajinqqnbdyb78p92wa9xy7p7bcz-harfbuzz-1.7.5
found 1.7.5 in filename of file in /nix/store/6w64dajinqqnbdyb78p92wa9xy7p7bcz-harfbuzz-1.7.5

cc @garbas

@GrahamcOfBorg build harfbuzz-icu harfbuzz-icu-58 gnome3.sushi

Failure on x86_64-darwin (full log)
Partial log (click to expand)
Package ‘sushi-3.24.0’ in /Users/graham/nix-borg/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-ndnd/pkgs/desktops/gnome-3/core/sushi/default.nix:46 is not supported on ‘x86_64-darwin’, refusing to evaluate.

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowBroken = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowBroken = true; }
to ~/.config/nixpkgs/config.nix.

Failure on x86_64-darwin (full log)
Partial log (click to expand)
Package ‘sushi-3.24.0’ in /private/var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/lnl7-mac/pkgs/desktops/gnome-3/core/sushi/default.nix:46 is not supported on ‘x86_64-darwin’, refusing to evaluate.

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowBroken = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowBroken = true; }
to ~/.config/nixpkgs/config.nix.

The same update has been staged in e571f14d3

Success on x86_64-darwin (full log)
Partial log (click to expand)
post-installation fixup
Removing /nix/store/4g0d7hspxacd8kb3byhsnrpans5rjmi2-harfbuzz-1.7.5/share/gtk-doc
Removing empty /nix/store/4g0d7hspxacd8kb3byhsnrpans5rjmi2-harfbuzz-1.7.5/share/ and (possibly) its parents
Patching '/nix/store/13ng8pzs4sh3sqf9zs94gd7cam12nj17-harfbuzz-1.7.5-dev/lib/pkgconfig/harfbuzz.pc' includedir to output /nix/store/13ng8pzs4sh3sqf9zs94gd7cam12nj17-harfbuzz-1.7.5-dev
strip is /nix/store/4sdh09gmvl15cy0zb6i7mbvxh5syz206-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/4g0d7hspxacd8kb3byhsnrpans5rjmi2-harfbuzz-1.7.5/lib
patching script interpreter paths in /nix/store/4g0d7hspxacd8kb3byhsnrpans5rjmi2-harfbuzz-1.7.5
strip is /nix/store/4sdh09gmvl15cy0zb6i7mbvxh5syz206-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/13ng8pzs4sh3sqf9zs94gd7cam12nj17-harfbuzz-1.7.5-dev/lib  /nix/store/13ng8pzs4sh3sqf9zs94gd7cam12nj17-harfbuzz-1.7.5-dev/bin
patching script interpreter paths in /nix/store/13ng8pzs4sh3sqf9zs94gd7cam12nj17-harfbuzz-1.7.5-dev

Success on aarch64-linux (full log)
Partial log (click to expand)
/nix/store/5cadwhhwkap30gwygf9r1y6ipxbpb0gz-harfbuzz-1.7.5

Failure on x86_64-linux (full log)
Partial log (click to expand)
[ 18%] Building CXX object Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/runtime/ReflectObject.cpp.o
[ 18%] Building CXX object Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/runtime/RegExp.cpp.o
[ 18%] Building CXX object Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/runtime/RegExpCache.cpp.o
[ 18%] Building CXX object Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/runtime/RegExpCachedResult.cpp.o
[ 18%] Building CXX object Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/runtime/RegExpConstructor.cpp.o
[ 18%] Building CXX object Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/runtime/RegExpMatchesArray.cpp.o
[ 18%] Building CXX object Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/runtime/RegExpObject.cpp.o
building of ‘/nix/store/finllrc4fryjhzd4mhib4cjh7gnzn6wc-webkitgtk-2.18.6.drv’ timed out after 3600 seconds
cannot build derivation ‘/nix/store/z4k5mpw1070gbdgmls3z8gcvhyywjxpk-sushi-3.24.0.drv’: 1 dependencies couldn't be built
error: build of ‘/nix/store/z4k5mpw1070gbdgmls3z8gcvhyywjxpk-sushi-3.24.0.drv’ failed

Success on x86_64-linux (full log)
Partial log (click to expand)
/nix/store/6w64dajinqqnbdyb78p92wa9xy7p7bcz-harfbuzz-1.7.5

Failure on aarch64-linux (full log)
Partial log (click to expand)
[ 37%] Building CXX object Source/WebCore/CMakeFiles/WebCoreDerivedSources.dir/__/__/DerivedSources/WebCore/JSSVGPreserveAspectRatio.cpp.o
[ 37%] Building CXX object Source/WebCore/CMakeFiles/WebCoreDerivedSources.dir/__/__/DerivedSources/WebCore/JSSVGStopElement.cpp.o
[ 37%] Building CXX object Source/WebCore/CMakeFiles/WebCoreDerivedSources.dir/__/__/DerivedSources/WebCore/JSSVGStyleElement.cpp.o
[ 37%] Building CXX object Source/WebCore/CMakeFiles/WebCoreDerivedSources.dir/__/__/DerivedSources/WebCore/JSSVGStringList.cpp.o
[ 37%] Building CXX object Source/WebCore/CMakeFiles/WebCoreDerivedSources.dir/__/__/DerivedSources/WebCore/JSSVGSetElement.cpp.o
[ 37%] Building CXX object Source/WebCore/CMakeFiles/WebCoreDerivedSources.dir/__/__/DerivedSources/WebCore/JSSVGSwitchElement.cpp.o
[ 38%] Building CXX object Source/WebCore/CMakeFiles/WebCoreDerivedSources.dir/__/__/DerivedSources/WebCore/JSSVGScriptElement.cpp.o
building of '/nix/store/wcszhj4v4wjv2isgl2q9agbrx6nw9dxm-webkitgtk-2.18.6.drv' timed out after 3600 seconds
cannot build derivation '/nix/store/ac72z1qqpv4bkp593a2081vijf8avphg-sushi-3.24.0.drv': 1 dependencies couldn't be built
error: build of '/nix/store/ac72z1qqpv4bkp593a2081vijf8avphg-sushi-3.24.0.drv' failed


No types of Dropzone in TypeScript

"node_modules/react-dropzone-component/typescript/types"' has no exported member 'DropzoneFile'.

@tronya same over here, I had to go back to the 3.0.0 tag to fix it.

@tronya  @0x1ad2  the issue is with import only
import {DropzoneComponent} from 'react-dropzone-component';
as the types is define the component needs to be called.
worked in my case

Also worked for me. Thank you!


Do not allow duplicate GENESIS block creation - #1556

Resolves #1556

Codecov Report

Merging #1612 into master will decrease coverage by 73.09%.
The diff coverage is 20%.

@@            Coverage Diff             @@
##           master    #1612      +/-   ##
==========================================
- Coverage   98.44%   25.34%   -73.1%
==========================================
  Files          58       58
  Lines        2828     2833       +5
==========================================
- Hits         2784      718    -2066
- Misses         44     2115    +2071

Codecov Report

Merging #1612 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #1612      +/-   ##
==========================================
+ Coverage   98.45%   98.45%   +<.01%
==========================================
  Files          58       58
  Lines        2850     2854       +4
==========================================
+ Hits         2806     2810       +4
  Misses         44       44

LGTM

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@9c96147). Click here to learn what that means.
The diff coverage is 100%.

@@            Coverage Diff            @@
##             master    #1612   +/-   ##
=========================================
  Coverage          ?   98.45%
=========================================
  Files             ?       58
  Lines             ?     2854
  Branches          ?        0
=========================================
  Hits              ?     2810
  Misses            ?       44
  Partials          ?        0