FIM 3 Gaps in Huc6 020200 - upstate New York (fix or explanation needed ASAP for APG support)

APG - support for the NERFC Tabletop exercises for the August 2011 event in NY:
History: Last year (2020) I generated RnR 5-day Max Inundation maps (using the FIM v2.x libraries) for a set of event dates and times using max streamflows calculated from their 2011 forecasts. To fix the gaps seen in Fort Hunter, NY area, we decided in January 2021 to recreate these maps using the FIM v3.x libraries, but still generating 2-D vector maps.
Current: There are now 2 gaps in the Schoharie Creek area where they are focusing the exercises (HUC8 = 02020005) - in Middleburgh and Gilboa.
I tried to include as much FIM v3.x data in the detail map screenshots, as well as the streamflow lines with Feature IDs. Let me know if you need anything else.
Note: They prefer to have this corrected, not patched. They're expectation is that whatever they demo for the tabletop will be the inundations they can expect when the services are released later this year.
In addition, there are several more gaps in the other Huc 8 areas. Those are less of a priority, but IF this is a fairly easy fix, they would like those as well.
Mostly, I am looking for guidance on what to report back to them as soon as possible. If this looks fixable well ahead of the June Tabletop, when they can expect it, etc. They are just trying to plan :)
Attached are screenshots of the latest inundation maps, showing the new RnR FIM v3.x inundations in Blue, and the older RnR FIM 2.x in Red:

Sorry duplicate maps included in the above initial description! Ignore the very first image...

@KatherinePowell-NOAA What is the ahps/lid name?

@KatherinePowell-NOAA Which version of FIM 3.X is this ticket in reference to?

Middleburgh =
Schoharie Creek at Middleburgh (MDBN6)
https://waterdata.usgs.gov/usa/nwis/uv?01350500  (USGS)
Gilboa =
Schoharie Creek at Gilboa Dam (GILN6)
https://waterdata.usgs.gov/ny/nwis/uv?site_no=01350101 (USGS)

I cannot access my network drive currently, the vrsion number is on the Transfer drive in temp\Laura folder... dated January 19, 2021 (Laura acquired these to help fix the Fort Hunter junction)

I cannot access my network drives currently, the version number is on the
Transfer drive in temp\Laura folder... dated January 19, 2021 (Laura
acquired these to help fix the Fort Hunter junction)
On Mon, Mar 29, 2021 at 2:49 PM Brad @.***> wrote:

@KatherinePowell-NOAA https://github.com/KatherinePowell-NOAA Which
version of FIM 3.X is this ticket in reference to?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NOAA-OWP/cahaba/issues/334#issuecomment-809665345,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASLKYDSRHPLXZ3LPYWN4VMTTGDKURANCNFSM42AHMCMA
.

I don't see a temp/Laura folder, but I do see a temp/laura.keys folder, but no subdirectories dated Jan 19.  However, if the version is from Jan 19, then I would wager that this bug has been addressed already in the latest FIM version. I believe that Corey has the latest version for CONUS (fim_3_0_9_0_ms_c). @CoreyKrewson-NOAA can you please confirm?

That's correct... laura.keys folder (I just remembered it incorrectly).
I'll check with Corey and let you know... thanks!
On Mon, Mar 29, 2021 at 2:58 PM Brad @.***> wrote:

I don't see a temp/Laura folder, but I do see a temp/laura.keys folder,
but no subdirectories dated Jan 19. However, if the version is from Jan 19,
then I would wager that this bug has been addressed already in the latest
FIM version. I believe that Corey has the latest version for CONUS
(fim_3_0_9_0_ms_c). @CoreyKrewson-NOAA
https://github.com/CoreyKrewson-NOAA can you please confirm?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NOAA-OWP/cahaba/issues/334#issuecomment-809671042,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASLKYDXEWMNCIYBAEJZTAPTTGDLXVANCNFSM42AHMCMA
.

Gilboa =This gap is in a NWM Lake feature:

Really we should be removing all of the inundation mapped within lake boundaries (gray polygons) but for now that should explain why the missing area isn't mapped. It's the only polygon actually doing what it is supposed to. This inconsistency is a known issue and will get cleaned up in a future version.

Yes, we mask inundation at waterbodies intentionally in FIM3.x and would recommend that the maps produced from FIM2 data also mask NWM waterbodies.

I can verify, but I believe the NERFC hydrologists treat the area that is a "reservoir" as a part of the stream as that was a flood issue during this event. Also, I have Feature ID = 3247586, the reach just south of the "waterbody" you indicated as the area that is the gap for the Gilboa Dam area. Why would that be?

Middleburgh = Looks like this has been addressed in FIM v<IP_ADDRESS>:

That is great! I also really appreciate the clarification about the waterbodies... they just want to understand the FIMs better.

We do have the fim_3_0_9_0 for MS and FR, but that is only on AWS and using gridded output.
Our on prem system is using 2.X (not sure what exact version), and using the flood stack library output.
We could move to FIM 3.X for our on prem system but that would require us to compute the flood stack libraries.

I can verify, but I believe the NERFC hydrologists treat the area that is a "reservoir" as a part of the stream as that was a flood issue during this event. Also, I have Feature ID = 3247586, the reach just south of the "waterbody" you indicated as the area that is the gap for the Gilboa Dam area. Why would that be?

We currently do not support FIM for lakes/reservoirs in FIM v2/3. I'm not sure I follow the second question.. are you saying that you are seeing another gap downstream of the lake boundary?

OK, Brian, this image helps. ..thanks. Looks like I would need to recreate these with the latest FIM 3.
Corey, this is a special case where I use a modified inundation script that Laura created just for this NERFC map output - using the FIM 3 libraries, but converting the output to vector (no depth). No need to move FIM 3.X to the on prem system currently. I just need flood stacks for the fim_3_0_9_0 for MS only, and only for HUC6 = 020200.

@KatherinePowell-NOAA can I close this ticket? If you are still seeing these gaps in FIM v<IP_ADDRESS> we can start a new one.

I am still seeing a gap at Gilboa Dam, but let me verify - could be flow
dependent. I'll let you know...
On Thu, Apr 1, 2021 at 1:52 PM brian.avant @.***> wrote:

@KatherinePowell-NOAA https://github.com/KatherinePowell-NOAA can I
close this ticket? If you are still seeing these gaps in FIM v<IP_ADDRESS> we
can start a new one.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NOAA-OWP/cahaba/issues/334#issuecomment-812104141,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASLKYDXERC52RRTM4SNMD4TTGS6GVANCNFSM42AHMCMA
.

OK, we can close this, but can you open a ticket for the gap at Gilboa Dam?
Thanks!
[image: image.png]
Katherine
On Thu, Apr 1, 2021 at 3:03 PM Katherine Powell - NOAA Affiliate <
@.***> wrote:

I am still seeing a gap at Gilboa Dam, but let me verify - could be flow
dependent. I'll let you know...
On Thu, Apr 1, 2021 at 1:52 PM brian.avant @.***>
wrote:

@KatherinePowell-NOAA https://github.com/KatherinePowell-NOAA can I
close this ticket? If you are still seeing these gaps in FIM v<IP_ADDRESS> we
can start a new one.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NOAA-OWP/cahaba/issues/334#issuecomment-812104141,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASLKYDXERC52RRTM4SNMD4TTGS6GVANCNFSM42AHMCMA
.

@KatherinePowell-NOAA looks like that image didn't load properly, can you repost it? Just to be clear there still should not be any mapping where there is a lake feature. Are you saying that there is a gap upstream or downstream of the lake feature?

OK, looks like the image made it this time! It is a reach north of the feature you are calling a lake, though any water bodies along here are reservoirs. I have the feature IDs listed. Let me know if you need more info...

@KatherinePowell-NOAA was this fully addressed either in this ticket or in another ticket? Since the NWM treats NWM feature_ids 3247586 and 3247592 as waterbodies, we should not be creating inundation extents for either of these reaches with the FIM 3.X capability. If there was inundation during the Schoharie event along these reaches, I think we say at this time we can not provide guidance on inundation in this area as we only create inundation extents along NWM reaches and not NWM waterbodies. Inundation for NWM waterbodies is a feature enhancement in the backlog and would require some considerable attention if this capability is desired for the APG.

The conclusion of this discussion was that the NWM had mis-encoded this
reach as a waterbody and that the customer is encouraged to submit this
feedback to the NWM modeling team (or viz/FIM can submit). Once the NWM is
updated, then FIM would recognize as a reach and provide inundation for it.
We agreed that FIM should not be attempted at waterbodies at present.
On Thu, Apr 15, 2021 at 4:06 PM FernandoSalas-NOAA @.***>
wrote:

@KatherinePowell-NOAA https://github.com/KatherinePowell-NOAA was this
fully addressed either in this ticket or in another ticket? Since the NWM
treats NWM feature_ids 3247586 and 3247592 as waterbodies, we should not be
creating inundation extents for either of these reaches with the FIM 3.X
capability. If there was inundation during the Schoharie event along these
reaches, I think we say at this time we can not provide guidance on
inundation in this area as we only create inundation extents along NWM
reaches and not NWM waterbodies. Inundation for NWM waterbodies is a
feature enhancement in the backlog and would require some considerable
attention if this capability is desired for the APG.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/NOAA-OWP/cahaba/issues/334#issuecomment-820730322,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQS66E5LW2VF3T3ZP2ODRNTTI5INPANCNFSM42AHMCMA
.

--
Brad Bates
Geospatial Developer
NOAA Office of Water Prediction | U.S. Department of Commerce
@.***
NOAA Affiliate, Lynker

Ok. Just confirming NERFC expectations after this was communicated. Also, doesn't look to me like the NWM is incorrectly representing feature_id 3247592. Looks like the tail end of the waterbody in the imagery.
@KatherinePowell-NOAA all good from the NERFC perspective?

Hi Fernando - all good with NERFC, Whitney and I have had several
conversations with them and we keep reinforcing that they are getting a
hybrid RnR FIM solution that doesn't yet exist and they are OK with it.
They want to dig into these details! As for any gaps or areas that don't
seem correct, ones that have a FIM 2 solution but not one in the latest
FIM 3....  such as at Gilboa... first we have clarified what Brad mentioned
above - that anything the NWM designates as a waterbody really can't
correctly have a synthetic rating curve or FIM. Therefore, we will have a
FIM using both in the tabletop in order to cover the area at GIlboa. They
will explain the version differences to participants.
On Thu, Apr 15, 2021 at 7:33 PM FernandoSalas-NOAA @.***>
wrote:

Ok. Just confirming NERFC expectations after this was communicated. Also,
doesn't look to me like the NWM is incorrectly representing feature_id
3247592. Looks like the tail end of the waterbody in the imagery.
@KatherinePowell-NOAA https://github.com/KatherinePowell-NOAA all good
from the NERFC perspective?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NOAA-OWP/cahaba/issues/334#issuecomment-820825249,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASLKYDQUBO24BDGGYCPBYJDTI6AVTANCNFSM42AHMCMA
.

Thanks Katherine. So the plan is to use FIM 2 and FIM 3 for the tabletop?
If so, we should make clear that the operational system will not provide
inundation guidance along that reach unless a feature enhancement is
delivered to provide inundation guidance at waterbodies. Would like to make
sure our stakeholders understand this as well so that they don't expect
guidance in that location during a future flood event. If this causes
confusion suggest we stick with FIM 3 and message that guidance is
currently not available along waterbodies. We should then discuss where
this waterbody feature enhancement lies on our dev priority list.
On Friday, April 16, 2021, KatherinePowell-NOAA @.***>
wrote:

Hi Fernando - all good with NERFC, Whitney and I have had several
conversations with them and we keep reinforcing that they are getting a
hybrid RnR FIM solution that doesn't yet exist and they are OK with it.
They want to dig into these details! As for any gaps or areas that don't
seem correct, ones that have a FIM 2 solution but not one in the latest
FIM 3.... such as at Gilboa... first we have clarified what Brad mentioned
above - that anything the NWM designates as a waterbody really can't
correctly have a synthetic rating curve or FIM. Therefore, we will have a
FIM using both in the tabletop in order to cover the area at GIlboa. They
will explain the version differences to participants.
On Thu, Apr 15, 2021 at 7:33 PM FernandoSalas-NOAA @.***>
wrote:

Ok. Just confirming NERFC expectations after this was communicated. Also,
doesn't look to me like the NWM is incorrectly representing feature_id
3247592. Looks like the tail end of the waterbody in the imagery.
@KatherinePowell-NOAA https://github.com/KatherinePowell-NOAA all good
from the NERFC perspective?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NOAA-OWP/cahaba/issues/334#issuecomment-820825249,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/
ASLKYDQUBO24BDGGYCPBYJDTI6AVTANCNFSM42AHMCMA>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/NOAA-OWP/cahaba/issues/334#issuecomment-821162542,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AO6EII6YEMKVIO4M6HX4AYTTJAZKTANCNFSM42AHMCMA
.

--
Fernando R. Salas
National Water Center
Geo-Intelligence Division | Office of Water Prediction
NOAA National Weather Service
Office:<PHONE_NUMBER> | @.*
@.**>
http://water.noaa.gov http://water.noaa.gov

Fernando - They do understand all of that, and they also understand that
future guidance will change. However, they are simply unwilling to have a
solution that has a gap at that location (GIlboa) for the tabletop
exercise.
Please note:

The hybrid FIM 3 solution generated for the NY exercise is already a
non-existent solution. The current RnR FIM was translated to a 2-D
shapefile, when it will actually be a raster with depth information when
FIM 3 is released with HydroViz.
They FULLY understand that the areas designated as water
bodies shouldn't have FIM guidance in the future and they understand why.
They want a process by which to question and change reaches that they
deem mis-identified by the NWM team as "water bodies" so that there
may be FIM
guidance in the future.
The event for which the maps were generated is still the record flood
event for the Schoharie creek area and these FIMs are extraordinary.
I will be participating in the June tabletop and they are encouraging me
to clarify all of this and give any additional information at that time.

I hope this helps!
Katherine
On Fri, Apr 16, 2021 at 8:37 AM FernandoSalas-NOAA @.***>
wrote:

Thanks Katherine. So the plan is to use FIM 2 and FIM 3 for the tabletop?
If so, we should make clear that the operational system will not provide
inundation guidance along that reach unless a feature enhancement is
delivered to provide inundation guidance at waterbodies. Would like to make
sure our stakeholders understand this as well so that they don't expect
guidance in that location during a future flood event. If this causes
confusion suggest we stick with FIM 3 and message that guidance is
currently not available along waterbodies. We should then discuss where
this waterbody feature enhancement lies on our dev priority list.
On Friday, April 16, 2021, KatherinePowell-NOAA @.***>
wrote:

Hi Fernando - all good with NERFC, Whitney and I have had several
conversations with them and we keep reinforcing that they are getting a
hybrid RnR FIM solution that doesn't yet exist and they are OK with it.
They want to dig into these details! As for any gaps or areas that don't
seem correct, ones that have a FIM 2 solution but not one in the latest
FIM 3.... such as at Gilboa... first we have clarified what Brad
mentioned
above - that anything the NWM designates as a waterbody really can't
correctly have a synthetic rating curve or FIM. Therefore, we will have a
FIM using both in the tabletop in order to cover the area at GIlboa. They
will explain the version differences to participants.
On Thu, Apr 15, 2021 at 7:33 PM FernandoSalas-NOAA @.***>
wrote:

Ok. Just confirming NERFC expectations after this was communicated.
Also,
doesn't look to me like the NWM is incorrectly representing feature_id
3247592. Looks like the tail end of the waterbody in the imagery.
@KatherinePowell-NOAA https://github.com/KatherinePowell-NOAA all
good
from the NERFC perspective?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/NOAA-OWP/cahaba/issues/334#issuecomment-820825249
,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/
ASLKYDQUBO24BDGGYCPBYJDTI6AVTANCNFSM42AHMCMA>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/NOAA-OWP/cahaba/issues/334#issuecomment-821162542,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AO6EII6YEMKVIO4M6HX4AYTTJAZKTANCNFSM42AHMCMA
.

--
Fernando R. Salas
National Water Center
Geo-Intelligence Division | Office of Water Prediction
NOAA National Weather Service
Office:<PHONE_NUMBER> | @.*
@.**>
http://water.noaa.gov http://water.noaa.gov
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NOAA-OWP/cahaba/issues/334#issuecomment-821183469,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASLKYDSCNINRHXJKU5SKBX3TJA4QFANCNFSM42AHMCMA
.

Thanks Katherine. Appreciate it. Glad you're participating in the tabletop.
Feedback for the NWM dev team should go through VLab. Look for the National
Water Model Output Assessment project and create a ticket.
However, NWM waterbodies are derived from NHDPlus waterbodies and the
extent of the waterbodies are informed by USGS/EPA and local stewards. This
particular area has a NHDPlus waterbody present. In order to modify the
representation here, we would need to alter the NHDPlus waterbody polygon
when creating the NWM hydrofabric. Up until now I believe we have tried to
limit edits to NHDPlus features for reproducibility purposes and instead
submit feedback to the NHDPlus development team. This can be a slow process.
IMO this waterbody should stay as is and we should instead enhance our
capabilities to perform FIM on waterbodies.
On Friday, April 16, 2021, KatherinePowell-NOAA @.***>
wrote:

Fernando - They do understand all of that, and they also understand that
future guidance will change. However, they are simply unwilling to have a
solution that has a gap at that location (GIlboa) for the tabletop
exercise.
Please note:

The hybrid FIM 3 solution generated for the NY exercise is already a
non-existent solution. The current RnR FIM was translated to a 2-D
shapefile, when it will actually be a raster with depth information when
FIM 3 is released with HydroViz.
They FULLY understand that the areas designated as water
bodies shouldn't have FIM guidance in the future and they understand why.
They want a process by which to question and change reaches that they
deem mis-identified by the NWM team as "water bodies" so that there
may be FIM
guidance in the future.
The event for which the maps were generated is still the record flood
event for the Schoharie creek area and these FIMs are extraordinary.
I will be participating in the June tabletop and they are encouraging me
to clarify all of this and give any additional information at that time.

I hope this helps!
Katherine
On Fri, Apr 16, 2021 at 8:37 AM FernandoSalas-NOAA @.***>
wrote:

Thanks Katherine. So the plan is to use FIM 2 and FIM 3 for the tabletop?
If so, we should make clear that the operational system will not provide
inundation guidance along that reach unless a feature enhancement is
delivered to provide inundation guidance at waterbodies. Would like to
make
sure our stakeholders understand this as well so that they don't expect
guidance in that location during a future flood event. If this causes
confusion suggest we stick with FIM 3 and message that guidance is
currently not available along waterbodies. We should then discuss where
this waterbody feature enhancement lies on our dev priority list.
On Friday, April 16, 2021, KatherinePowell-NOAA @.***>
wrote:

Hi Fernando - all good with NERFC, Whitney and I have had several
conversations with them and we keep reinforcing that they are getting a
hybrid RnR FIM solution that doesn't yet exist and they are OK with it.
They want to dig into these details! As for any gaps or areas that
don't
seem correct, ones that have a FIM 2 solution but not one in the latest
FIM 3.... such as at Gilboa... first we have clarified what Brad
mentioned
above - that anything the NWM designates as a waterbody really can't
correctly have a synthetic rating curve or FIM. Therefore, we will
have a
FIM using both in the tabletop in order to cover the area at GIlboa.
They
will explain the version differences to participants.
On Thu, Apr 15, 2021 at 7:33 PM FernandoSalas-NOAA @.***>
wrote:

Ok. Just confirming NERFC expectations after this was communicated.
Also,
doesn't look to me like the NWM is incorrectly representing
feature_id
3247592. Looks like the tail end of the waterbody in the imagery.
@KatherinePowell-NOAA https://github.com/KatherinePowell-NOAA all
good
from the NERFC perspective?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/NOAA-OWP/cahaba/issues/334#issuecomment-
820825249
,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/
ASLKYDQUBO24BDGGYCPBYJDTI6AVTANCNFSM42AHMCMA>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/NOAA-OWP/cahaba/issues/334#issuecomment-821162542
,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AO6EII6YEM
KVIO4M6HX4AYTTJAZKTANCNFSM42AHMCMA
.

--
Fernando R. Salas
National Water Center
Geo-Intelligence Division | Office of Water Prediction
NOAA National Weather Service
Office:<PHONE_NUMBER> | @.*
@.**>
http://water.noaa.gov http://water.noaa.gov
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NOAA-OWP/cahaba/issues/334#issuecomment-821183469,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASLKYDSCN
INRHXJKU5SKBX3TJA4QFANCNFSM42AHMCMA>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/NOAA-OWP/cahaba/issues/334#issuecomment-821198127,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AO6EII6GIB2S6L3XO5YSOG3TJA7H5ANCNFSM42AHMCMA
.

--
Fernando R. Salas
National Water Center
Geo-Intelligence Division | Office of Water Prediction
NOAA National Weather Service
Office:<PHONE_NUMBER> | @.*
@.**>
http://water.noaa.gov http://water.noaa.gov

OK, thanks Fernando. Agreed - sounds like the preferred solution to a
situation like this one is to enhance our capabilities. I will submit
feedback as a VLab ticket, and likely add significantly to that ticket
after the tabletop.
Cheers,
Katherine
On Fri, Apr 16, 2021 at 9:21 AM FernandoSalas-NOAA @.***>
wrote:

Thanks Katherine. Appreciate it. Glad you're participating in the tabletop.
Feedback for the NWM dev team should go through VLab. Look for the National
Water Model Output Assessment project and create a ticket.
However, NWM waterbodies are derived from NHDPlus waterbodies and the
extent of the waterbodies are informed by USGS/EPA and local stewards. This
particular area has a NHDPlus waterbody present. In order to modify the
representation here, we would need to alter the NHDPlus waterbody polygon
when creating the NWM hydrofabric. Up until now I believe we have tried to
limit edits to NHDPlus features for reproducibility purposes and instead
submit feedback to the NHDPlus development team. This can be a slow
process.
IMO this waterbody should stay as is and we should instead enhance our
capabilities to perform FIM on waterbodies.
On Friday, April 16, 2021, KatherinePowell-NOAA @.***>
wrote:

Fernando - They do understand all of that, and they also understand that
future guidance will change. However, they are simply unwilling to have a
solution that has a gap at that location (GIlboa) for the tabletop
exercise.
Please note:

The hybrid FIM 3 solution generated for the NY exercise is already a
non-existent solution. The current RnR FIM was translated to a 2-D
shapefile, when it will actually be a raster with depth information when
FIM 3 is released with HydroViz.
They FULLY understand that the areas designated as water
bodies shouldn't have FIM guidance in the future and they understand why.
They want a process by which to question and change reaches that they
deem mis-identified by the NWM team as "water bodies" so that there
may be FIM
guidance in the future.
The event for which the maps were generated is still the record flood
event for the Schoharie creek area and these FIMs are extraordinary.
I will be participating in the June tabletop and they are encouraging
me
to clarify all of this and give any additional information at that time.

I hope this helps!
Katherine
On Fri, Apr 16, 2021 at 8:37 AM FernandoSalas-NOAA @.***>
wrote:

Thanks Katherine. So the plan is to use FIM 2 and FIM 3 for the
tabletop?
If so, we should make clear that the operational system will not
provide
inundation guidance along that reach unless a feature enhancement is
delivered to provide inundation guidance at waterbodies. Would like to
make
sure our stakeholders understand this as well so that they don't expect
guidance in that location during a future flood event. If this causes
confusion suggest we stick with FIM 3 and message that guidance is
currently not available along waterbodies. We should then discuss where
this waterbody feature enhancement lies on our dev priority list.
On Friday, April 16, 2021, KatherinePowell-NOAA @.***>
wrote:

Hi Fernando - all good with NERFC, Whitney and I have had several
conversations with them and we keep reinforcing that they are
getting a
hybrid RnR FIM solution that doesn't yet exist and they are OK with
it.
They want to dig into these details! As for any gaps or areas that
don't
seem correct, ones that have a FIM 2 solution but not one in the
latest
FIM 3.... such as at Gilboa... first we have clarified what Brad
mentioned
above - that anything the NWM designates as a waterbody really can't
correctly have a synthetic rating curve or FIM. Therefore, we will
have a
FIM using both in the tabletop in order to cover the area at GIlboa.
They
will explain the version differences to participants.
On Thu, Apr 15, 2021 at 7:33 PM FernandoSalas-NOAA @.***>
wrote:

Ok. Just confirming NERFC expectations after this was communicated.
Also,
doesn't look to me like the NWM is incorrectly representing
feature_id
3247592. Looks like the tail end of the waterbody in the imagery.
@KatherinePowell-NOAA https://github.com/KatherinePowell-NOAA
all
good
from the NERFC perspective?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/NOAA-OWP/cahaba/issues/334#issuecomment-
820825249
,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/
ASLKYDQUBO24BDGGYCPBYJDTI6AVTANCNFSM42AHMCMA>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<
https://github.com/NOAA-OWP/cahaba/issues/334#issuecomment-821162542
,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AO6EII6YEM
KVIO4M6HX4AYTTJAZKTANCNFSM42AHMCMA
.

--
Fernando R. Salas
National Water Center
Geo-Intelligence Division | Office of Water Prediction
NOAA National Weather Service
Office:<PHONE_NUMBER> | @.*
@.**>
http://water.noaa.gov http://water.noaa.gov
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/NOAA-OWP/cahaba/issues/334#issuecomment-821183469
,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASLKYDSCN
INRHXJKU5SKBX3TJA4QFANCNFSM42AHMCMA>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/NOAA-OWP/cahaba/issues/334#issuecomment-821198127,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AO6EII6GIB2S6L3XO5YSOG3TJA7H5ANCNFSM42AHMCMA
.

--
Fernando R. Salas
National Water Center
Geo-Intelligence Division | Office of Water Prediction
NOAA National Weather Service
Office:<PHONE_NUMBER> | @.*
@.**>
http://water.noaa.gov http://water.noaa.gov
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NOAA-OWP/cahaba/issues/334#issuecomment-821212459,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASLKYDTCPFL56COCL3S7KT3TJBBXBANCNFSM42AHMCMA
.


Why some TLS aync logic did not use the async in CRYPTO

Why some TLS aync logic did not use the async in CRYPTO, this make the miminor statemachine in TLS more complex.
TLS async logic:
    /* Finished parsing the ClientHello, now we can start processing it */
    /* Give the ClientHello callback a crack at things */
    if (sctx->client_hello_cb != NULL) {
        /* A failure in the ClientHello callback terminates the connection. */
        switch (sctx->client_hello_cb(ssl, &al, sctx->client_hello_cb_arg)) {
        case SSL_CLIENT_HELLO_SUCCESS:
            break;
        case SSL_CLIENT_HELLO_RETRY:
            s->rwstate = SSL_CLIENT_HELLO_CB;
            return -1;
        case SSL_CLIENT_HELLO_ERROR:
        default:
            SSLfatal(s, al, SSL_R_CALLBACK_FAILED);
            goto err;
        }
    }

The async in CRYPTO:
/crypto/async

There is no asynchronous processing in the code snippet above. So I do not quite understand how this is related to crypto/async.

sctx->client_hello_cb

The SSL_CLIENT_HELLO_RETRY was asynchronous processing. That is, the SSL_accept required called again to process this mini state.

crypto/async is a much newer addition than the IO style async that most of libssl uses. Unfortunately crypto/async is not available on all platforms so cannot be used as a general replacement for the IO style of async. There would also be backwards compat issues swapping from one form to the other, even if it were desirable to do so.

crypto/async is a much newer addition than the IO style async that most of libssl uses. Unfortunately crypto/async is not available on all platforms so cannot be used as a general replacement for the IO style of async. There would also be backwards compat issues swapping from one form to the other, even if it were desirable to do so.

got it,thanks.


Update mqttha.cfg

All the Status device have the name "Status" changed the name to something unique

Thanks @proditaki


Auto generate collections index page

Automatically generate index page under the paths specified in routesConfig.ts.
There are a couple of observations:

For some reason, when viewing a post under a collection path, Nextjs will request favicon.png and Ghost will report that it's an invalid slug. This doesn't affect the post at all but it'd be nice to know why Nextjs does that.
A post will always be reachable at the root as well as under the collection path. Not sure why and if it matters at all.

This PR assumes that the Ghost installation does NOT have its own collections setup.

@chancharles: thanks so much for this implementation. I will have do the code review within the next week. Form an architectural view, you have to make sure the post is only reachable under one path - otherwise SEO is affected badly, so that should be sorted out.
We haven't talked about it yet, but this repo has 2 modes of operation (one with (isr=false and one with isr=true). You need to make sure it works for both modes (start with isr=false first).
Don't know about the favicon, but am sure this can be sorted out - that's not so important at the moment.

Just tried with the ISR flag and my changes didn't work with ISR set to true.  :(
Unfortunately, I have to switch back to Gatsby due to a more pressing need. If you get around to this issue, I would love to see what was your solution and learn from it. Thanks!

Hi Charles, no problem. Seems like there is some more work that needs to be put into this feature. If you are switching priorities, I will decline this PR and keep it for later reference. I might revisit it, once I get more time for it myself. Or someone else with the same need will take the lead, let's wait and see.
For future reference, I think the following requirements must be fulfilled

better separation between collection and regular endpoints
no duplicate content (articles showing up in a collection should not be reachable elsewhere)
support for ISR

@chancharles: thanks so much for this first implementation, I think it will serve as an inspiration.


Update documentation to leverage IPAM and DNS

@rade @bboreham I'm not expecting this to be actually merged yet, I'm just using it to make changes available to you ASAP to get early feedback; I'll continue pushing self contained updates to other areas of the documentation + incorporate your feedback as you make it.
This PR updates just the main README initially - examples look much much better! Any advance on the rather boring h1c1/h2c1 container names? They're a bit mechanistic... something fun that we can carry through as a theme would be better IMO.
Fixes #879. Fixes #471. (eventually...)

For the README I think c1 and c2 would work fine.  Is there a point where there is an h1c2 or h2c2?

I've updated the manual addressing feature so it's a replay of the first example - this means that the following application subnet isolation makes sense without changes (unless there is a way that can be IPAMified - thoughts?)

You can request IPAM allocate an address in a subnet, e.g. net:<IP_ADDRESS>/16

LGTM, apart from the names h1c2 etc., which I still find ugly.

@rade suggests a1, a2 and b1, b2 (letter == subnet, number == host) - thoughts @bboreham?

Better.  Or you could start with c1, c2 as before and then move to b1, b2 when you have a second subnet?


Commenting throughout, glyph labelling function added

Add a label to a glyph by adding 'label' dictionary within user_parameters. The 'label' dict takes 'text' as a string, 'color' as an (a,b,c) tuple , 'xy_skew' as a (x,y) tuple, and 'userfont' as a dictionary using matplotlib font parameters (https://matplotlib.org/3.1.1/tutorials/text/text_props.html#default-font).

so I had this issue a few days ago and removing the glyph and changing it to an open parameter solved it for me. if that doesnt work you can try updating your cache and loading up the python.jar file found on your desktop, quick solve and im unsure how you got this far without this knowledge?

Looks good to me. Might be worth adding a new example to show all the ways this can be used.


Model disappeared when same 3 models pathtraced

Describe the bug
in three.js editor you can reproduce 100%

Create 1 cube(other models also reproduce)
PathTrace Render(set Realistic upper right)
Create 2 cubes
again PathTrace Render then you can see 2 cubes disappear in pathTraced Scene

https://github.com/user-attachments/assets/bc288c6e-af14-4428-a36e-53dbb0c90a35
Only this scenario reproduce this bug
add 1 model -> pathTrace render -> add same model of two -> PathTrace render
Expected behavior
all 3 cubes rendered in realistic
Platform:

Device: [Desktop]
OS: [MacOS]
GPU: [NVidia ??, Radeon ??, ...]
Browser: [Chrome]
Three.js version: [r167(editor)]
Library version: [current library version]

Can you reproduce in a jsfiddle or smaller example? Something like initializing / rendering the initial scene with 1 cube and then 1 second later (ore pressing a button) adding two more cubes?

@gkjohnson I found a reason but not perfectly digged
this line is a problem
PathTracingSceneGenerator.js in line.217
if ( result.changeType === GEOMETRY_REBUILT ) {

				const bvhOptions = {
					strategy: SAH,
					maxLeafTris: 1,
					indirect: true, //<-- this options causes a problem
					onProgress,
					...this.bvhOptions,
				};

because most(react three fiber, etc...) of indirect option is false as default, but PathTracingSceneGenerator this.generateBVH true as a default
so MeshBVH instantiates indirectBuffer at PathTracingSceneGenerator constructor, and MeshBVH's indirect check like below code (MeshBVH line.111)
	get indirect() {

		return ! ! this._indirectBuffer;

	}

so it causes a bug. it affects many codes ex. MeshBVHUniformStruct updateFrom // indirect false but true

currently I make a smaller example to reproduce a bug, then pr for check an example

Open a pr for check a bug @gkjohnson

I found a reason and why it's 3 same model causes a bug
if indirect set true in bvhOptions it causes an error because bvhToTextures not supported Multi root Nodes
function bvhToTextures( bvh, boundsTexture, contentsTexture ) {

	const roots = bvh._roots;
       //if indirect false this error occurred
	if ( roots.length !== 1 ) {

		throw new Error( 'MeshBVHUniformStruct: Multi-root BVHs not supported.' );

	}

https://github.com/gkjohnson/three-mesh-bvh/blob/9718501eee2619f1015fa332d7bddafaf6cf562a/src/gpu/MeshBVHUniformStruct.js#L52
and in three-mesh-bvh
// dereference a new index attribute if we're using indirect storage
		if ( bvh.indirect ) {

			const indirectBuffer = bvh._indirectBuffer;
			if (
				this._cachedIndexAttr === null ||
				this._cachedIndexAttr.count !== indirectBuffer.length
			) {

				if ( geometry.index ) {

					this._cachedIndexAttr = geometry.index.clone();

				} else {

					const array = getIndexArray( getVertexCount( geometry ) );
					this._cachedIndexAttr = new BufferAttribute( array, 1, false );

				}

			}

			dereferenceIndex( geometry, indirectBuffer, this._cachedIndexAttr );
			this.index.updateFrom( this._cachedIndexAttr );

		}

MeshUniformBVHStruct is a struct that in PhysicalPathTracingMaterial https://github.com/gkjohnson/three-gpu-pathtracer/blob/46b395e6d521f031eb5f357d49cd36cf831d0129/src/materials/pathtracing/PhysicalPathTracingMaterial.js#L87
focus on here
if ( bvh.indirect ) {

			const indirectBuffer = bvh._indirectBuffer;
			if (
				this._cachedIndexAttr === null ||
				this._cachedIndexAttr.count !== indirectBuffer.length
			) {

				if ( geometry.index ) {

					this._cachedIndexAttr = geometry.index.clone();

				}

in BoxGeometry case

at first PathTrace Rendering

this._cachedIndexAttr.count(null) !== indirectBuffer.length(12)
this._cachedIndexAttr = BufferAttribute(length 36)

add two BoxGeometry

this._cachedIndexAttr.count(36) !== indirectBuffer.length(36) <-- it's same so it Pass update _cachedIndexAttr
-> there's no update at _cachedIndexAttr it causes a bug


Configurable chunk size

Feature Request
Currently, the chunk size in the data sink is hard-coded to 500MB as CHUNK_SIZE_IN_BYTES. This could limit users in particularl environments with constrained memory resources.
We propose making the chunk size configurable via the EDC configuration.
Which Areas Would Be Affected?
S3-Dataplane-extension , S3-Datasink
Why Is the Feature Desired?
When edc is being deployed in an environment which has limited memory size 500mb chunk size is too much and dataplane cannot transfer a large size file
Solution Proposal
Get the value from configuration , and after validation pass it to the datasink.

thanks, could you take care of this? eventually I will assign the issue to you


Hello, view of browser is blue ? How I can fix it

Environment (please complete the following information):

OS (e.g., Windows 10):
Extension version (e.g., 1.2.3):

Describe the bug:

Repro steps:

Expected behavior:

Additional context:

Closing as incomplete. Please feel free to add more information if you have any and we can re-open the issue.


Explainer (explanation object) vs Kernel/Tree explainer (ndarray shap values) tabular data

Hello! I'm having some issues in plotting some results and that depends on the algorithm that I use.
For instance, using class Explainer I can obtain a shap.explanation objects and thus use it for bar, beeswarm, waterfall... plots.
but I can't use summary.plot and decision plots which require a ndarray.
X,y = shap.datasets.adult()
model = xgboost.XGBClassifier().fit(X, y)
explainer = shap.Explainer(model, X)
shap_values = explainer(X) #shap values are an explanation object_
shap.plots.bar(shap_values, max_display=12)

on the other hand, if I use a Kernel/Tree Explainer, I can obtain shap_values and use them for summary/decision plots but I don't have the shap.explanation object to plot a waterfall, beeswarm or bar.
  explainer = shap.TreeExplainer(model)
  shap_values= explainer.shap_values(X) # list of np.ndarrays
  shap.summary_plot(shap_values[1], X, plot_type="violin")
  shap.decision_plot(explainer.expected_value[1],
                         shap_values[1],
                         features_display,
                         highlight=misclassified)

My questions is: can I obtain shap_values as a ndarray from Explainer or can I obtain the explanation object from Kernel/Tree? i'd like to have all these plots but it does not seem possible
I also tried to use Explainer (algorithm="kernel") but it returns that the algorithm doesn't exist (even if it is suggested in the documentation).
thanks a lot!
Noemi

Any update on this issue, I have the same problem here, when I'm trying to plot some graphs for the Catboost algorithm

Same problem here

Same problem here too.

This is the solution I found:
new_shap_values = shap.Explanation(values=shap_values[0], data=X.values, feature_names=X.columns)

the above almost works for me, my wokring version is:
explanation = shap.Explanation(values=shap_values[0], base_values=explainer.expected_value[0], feature_names=X.columns, data=X.iloc[0,:])
shap.plots.waterfall(explanation)

Not sure if this is due to a newer version, but you can (now?) simply do this:
  explainer = shap.TreeExplainer(model)
  # don't do this...
  # shap_values = explainer.shap_values(X) # list of np.ndarrays
  # shap.summary_plot(shap_values[1], X, plot_type="violin")
  # do this:
  explanation = explainer(X)
  shap.summary_plot(explanation, plot_type="violin")
  shap.plots.bar(explanation, max_display=12)

I.e., instead of calling explainer.shap_values(X), call explainer(X) - which will give you an Explanation object containing the actual shap values in the .values attribute. All plot methods I tried accept this.


Converting multiple files json2xml result in missing XML header on second and subsequent files

If I convert multiple files into xml, here a example:
      convert: {
         options: {
           explicitArray: false,
         },
         json2xml: {
            options: {
               xml: {
                  headless: false,
                  header: true,
               }
            },

           files: [{
             expand: true,
             src: ['package.json', 'bower.json'],
             dest: './',
             ext: '.xml'
           }]
         },

The package.xml gets the xml header
<?xml version="1.0" encoding="UTF-8"?>

but bower.xml is missing the header.
Is this an bug or a feature, which I do not understand?

any updates on this?

yes, I've refactored the entire underlying, lib. just need to finish unit tests and I'll push it up and merge it over as soon as I get a chance...
thanks for your patient!

Hello jon,
do you have any updates? we can test your changes, but we need your sources to be able to do it.

Hello Jon,
do you have any updates on this? As mentioned before, if you publish your changes, I could support you.

@dpalic sorry for delay.

if you publish your changes, I could support you.

that would be great, I'll try to review and push up in the next couple of days. thank you

a happy new year!
some time has passed. Any updates so far?

a happy new year!
some time has passed. Any updates so far?


Package request: nautilus-admin

Project description
Extension for Nautilus to do administrative operations
Metadata

homepage URL:
source URL: https://github.com/nautilus-extensions/nautilus-admin
license: gpl3.
platforms: unix, linux, darwin, ...

Add a :+1: reaction to issues you find important.

With nautilus-image-converter, it is probably the two best and important nautilus extension in Gnome DE


tensorflow Frozen Graph to mxnet Error

Platform: win10
Python version: 3.6.9
Source framework with version: like Tensorflow 1.14.0 with CPU
Destination framework with version: mxnet 1.5.0 with GPU
Pre-trained model path (webpath or webdisk path): https://pan.baidu.com/s/1QFnJjenEunjqIKz1Om9Vtg
Extraction code:   ghvw
Running scripts: mmconvert -sf tensorflow -iw inceptionv1onfire.pb --inNodeName InputData/X --inputShape 224,224,3 --dstNodeName FullyConnected/Softmax -df mxnet -om inceptionv1onfire -dw mxnet_inceptionv1onfire-0000.params
Hi, I want to convert the pb file to mxnet model. I have converted TensorFlow mobilenet slim model with frozen_pb to mxnet successfully.  However, I failed to convert the above tensorflow pb model. Error occurs:
raise IOError("Graph doesn't have node [%s]." % name.split(':')[0])
OSError: Graph doesn't have node [data].
The log is as follows:
(gluon) E:\python\model_convert\mxnet>mmconvert -sf tensorflow -iw inceptionv1onfire.pb --inNodeName InputData/X --inputShape 224,224,3 --dstNodeName FullyConnected/Softmax -df mxnet -om inceptionv1onfire -dw mxnet_inceptionv1onfire-0000.params
WARNING:tensorflow:From d:\app\anaconda\install\envs\gluon\lib\site-packages\mmdnn\conversion\tensorflow\tensorflow_frozenparser.py:107: The name tf.reset_default_graph is deprecated. Please use tf.compat.v1.reset_default_graph instead.
WARNING:tensorflow:From d:\app\anaconda\install\envs\gluon\lib\site-packages\mmdnn\conversion\tensorflow\tensorflow_frozenparser.py:108: The name tf.GraphDef is deprecated. Please use tf.compat.v1.GraphDef instead.
WARNING:tensorflow:From d:\app\anaconda\install\envs\gluon\lib\site-packages\tensorflow\python\tools\strip_unused_lib.py:86: extract_sub_graph (from tensorflow.python.framework.graph_util_impl) is deprecated and will be removed in a future version.
Instructions for updating:
Use tf.compat.v1.graph_util.extract_sub_graph
WARNING:tensorflow:From d:\app\anaconda\install\envs\gluon\lib\site-packages\mmdnn\conversion\tensorflow\tensorflow_frozenparser.py:147: The name tf.placeholder is deprecated. Please use tf.compat.v1.placeholder instead.
WARNING:tensorflow:From d:\app\anaconda\install\envs\gluon\lib\site-packages\mmdnn\conversion\tensorflow\tensorflow_frozenparser.py:161: The name tf.Session is deprecated. Please use tf.compat.v1.Session instead.
2019-10-11 11:06:46.512410: I tensorflow/core/platform/cpu_feature_guard.cc:142] Your CPU supports instructions that this TensorFlow binary was not compiled to use: AVX2
WARNING:tensorflow:From d:\app\anaconda\install\envs\gluon\lib\site-packages\mmdnn\conversion\tensorflow\tensorflow_frozenparser.py:164: The name tf.train.export_meta_graph is deprecated. Please use tf.compat.v1.train.export_meta_graph instead.
IR network structure is saved as [76ddc54d558d495a8105afc36d9375c3.json].
IR network structure is saved as [76ddc54d558d495a8105afc36d9375c3.pb].
IR weights are saved as [76ddc54d558d495a8105afc36d9375c3.npy].
Parse file [76ddc54d558d495a8105afc36d9375c3.pb] with binary format successfully.
Warning: Graph Construct a self-loop node Dropout/cond/dropout/sub/x. Ignored.
Warning: Graph Construct a self-loop node Dropout/cond/dropout/rate. Ignored.
Warning: Graph Construct a self-loop node Dropout/cond/dropout/truediv/x. Ignored.
Warning: Graph Construct a self-loop node Dropout/cond/dropout/random_uniform. Ignored.
Detect input layer [Placeholder] using infer batch size, set it as default value [1]
Traceback (most recent call last):
File "d:\app\anaconda\install\envs\gluon\lib\runpy.py", line 193, in _run_module_as_main
"main", mod_spec)
File "d:\app\anaconda\install\envs\gluon\lib\runpy.py", line 85, in run_code
exec(code, run_globals)
File "D:\app\anaconda\install\envs\gluon\Scripts\mmconvert.exe_main.py", line 9, in
File "d:\app\anaconda\install\envs\gluon\lib\site-packages\mmdnn\conversion_script\convert.py", line 108, in _main
ret = IRToCode._convert(code_args)
File "d:\app\anaconda\install\envs\gluon\lib\site-packages\mmdnn\conversion_script\IRToCode.py", line 61, in _convert
emitter.run(args.dstModelPath, args.dstWeightPath, args.phase)
File "d:\app\anaconda\install\envs\gluon\lib\site-packages\mmdnn\conversion\common\DataStructure\emitter.py", line 22, in run
self.save_code(dstNetworkPath, phase)
File "d:\app\anaconda\install\envs\gluon\lib\site-packages\mmdnn\conversion\common\DataStructure\emitter.py", line 59, in save_code
code = self.gen_code(phase)
File "d:\app\anaconda\install\envs\gluon\lib\site-packages\mmdnn\conversion\mxnet\mxnet_emitter.py", line 102, in gen_code
line = func(current_node)
File "d:\app\anaconda\install\envs\gluon\lib\site-packages\mmdnn\conversion\mxnet\mxnet_emitter.py", line 997, in emit_Sub
self.parent_variable_name(IR_node),
File "d:\app\anaconda\install\envs\gluon\lib\site-packages\mmdnn\conversion\common\DataStructure\emitter.py", line 48, in parent_variable_name
return self.IR_graph.get_parent_variable_name(IR_node.name, path)
File "d:\app\anaconda\install\envs\gluon\lib\site-packages\mmdnn\conversion\common\DataStructure\graph.py", line 124, in get_parent_variable_name
current_node = self.get_node(parent_name)
File "d:\app\anaconda\install\envs\gluon\lib\site-packages\mmdnn\conversion\common\DataStructure\graph.py", line 72, in get_node
raise IOError("Graph doesn't have node [%s]." % name.split(':')[0])
OSError: Graph doesn't have node [data].
I don't know how to solve this problem.

why did this close without solve?


ng-pattern binding is not working in v1.4

I understand that v1.3 introduced some changes in the recommended usage of ng-pattern when the validation pattern / RegExp is exposed as a model property. This change is documented in the migration notes and works correctly in v1.3, as demonstrated in this JSFiddle.
However, using the same implementation in v1.4 does not work, as this JSFiddle shows. Instead, pattern validation always fails.

It doesn't actually have to do with ngPattern as much as it has to do with input[type="date"].
@aquisio: the 1.3.0-beta.8 version of Angular that you where using, didn't have support for date inputs, which means that they where treated as text inputs (i.e. reading the value from the input as the browser sets it). Per the spec, date input values are use the yyyy-MM-dd format, so ngPatern can match the string against the regex.
Now Angular has support for date inputs and has logic in place in order to convert the yyyy-MM-dd string value to an actual Date object. ngPattern tries to match the Date object to the regex (and fails).
@team (especially forms people): There seems to be a need for custom handling of pattern/ngPattern on date inputs (date, datetime-local, 'week'. 'month').
We do this for min/ngMin and max/ngMax anyway.

hm. ngPattern should probably only try to match the viewValue, not the modelValue. Because that's what pattern does.

Thinking about it again, you can't convert a regex to a date for comparing with the $modelValue :)
So, for the date input it does make sense for ngPattern to compare against the $viewValue.
(Not so sure about other inputs though, if that's what you meant.)

It completely brakes the idea of ngModel's $parsers and $validators pipeline.
Imagine I have a mask directive applied to the input to prettify some digital value. The masking directive formats the input data with some dashes and spaces, displaying it in the desired format, but surely it saves the $modelValue as a stripped string without any unnecessary symbols, only numbers.
I might want to apply a pattern attribute which would specify a regex to accept only numbers. Because why not! Maybe my masking directive is written to allow old-fashioned phone numbers with both letters and digits, but i want this particular input element to allow only digits. My mask directive combined with the pattern directive would be perfect together, because pattern directive would be checking the value returned from the masking directive.
And you broke that! And you added some questionable reasoning like HTML5 pattern constraint validates the input value, so we validate the viewValue. What? If i wanted native html5 validation I wouldn't add novalidate to my form and perhaps I wouldn't even use angular in the first place.
That's why we add the novalidate attribute — because we want our customary logic validating the inputs.

We could look at the problem from another angle. Ng directives should be prefixed with ng-, right? How come the pattern directive became an exception? Pattern is a native html attribute which I don't want angular to mess with. There are good semantic reasons why I'd want to add this attribute and not have angular intervene. For example, I wish the mobile users to use a numeric keyboard — then I would add pattern="\d*" attribute. The mobile OS would know what to do.  That's expected, consisted and desired behavior.

@everdimension, there are two different subjects touched here:

Changing the pattern/ngPattern directive to match against the $viewValue (instead of the $modelValue).
Having the native HTML5 validators (such as pattern, max, min, required etc) also be recognized by Angular as validators.

--
Regarding (1), while it is true that no solution is perfect (i.e. not everyone will be happy with any one solution), we picked the one that would be useful in most usecases. Now that Angular supports several types of inputs (e.g. number, date, time etc), it's not uncommon for the $modelValue to be non-string. Since a RegExp (such that the one applied by ngPattern) can only be tested against strings, we figured it would be more useful to use the $viewValue (which is always a string).
Of course, the usecase you describe is still valid and you can support it via a custom validator. I understand this is more work than just using a built-in validator, but it's still pretty trivial and the usecase is not very common.
IMO, it makes more sense for a framework to support the most common usecases out-of-the-box and require a little extra work for the less common ones than the other way around.
--
Regarding (2), indeed one could have gone the other way around - both approaches have pros and cons. At this point though, I believe that, altering the current behavior, would be too much of a breaking change to justify the benefit.
Also, note that [novalidate] doesn't mean that the native validators are not applied (e.g. the control's validity property is still updated as usual); it just doesn't natively prevent the form from being submitted.

Of course, the usecase you describe is still valid and you can support it via a custom validator. I understand this is more work than just using a built-in validator, but it's still pretty trivial and the usecase is not very common.

This would be appropriate solution if all I wanted was to validate a field using a regex pattern.
But like I said, there is a place where I use pattern="\d*" with a different intention — to bring up the numeric keyboard, which a valid practice
So basically my solution would be to overwrite the existing pattern directive, which is a kind of dirty solution.
--
Yes, there are two different issues, and in my opinion both of them are done wrong.
The (1) breaks the native angular pipeline, killing an important part of the framework. Date, number inputs? Handle them like a special case! They are a special case anyway, in my opinion.
The (2) interferes with expected behavior. Although this one is more understandable as there are several places where angular creates directives for native html attributes. This is kind of how angular is built. But still I never expected pattern to be controlled by angular since there is an ng-pattern specially for that.

@everdimension I don't think it was ever intended that using the HTML5 validation attributes keeps Angular from adding validation rules based on them. Even going back to 1.3, the docs state clearly that using the pattern attribute adds a validator.

So basically my solution would be to overwrite the existing pattern directive, which is a kind of dirty solution.

You can do something simple, such as apply the pattern attribute through a custom directive (in the post-link phase). Demo
It's not ideal, but again applying a pattern on a number or date field don't seem less common that using an input mask or applying pattern="\d*" on a text field to bring up a numeric keyboard.
Unfortunately we can't make everyone happy: We chose some usecase to work out-of-the-box and some to need a little more code. Could be the other way around, but there is no solution where every usecase works out-of-the-box - there are always going to be compromizes.
Regarding (2), whether it was a good or bad decision is a different discussion, but at this point changing it doesn't justify the breaking change, so it might be a pointless discussion :wink:

why isn't it documented in the migration guide the ng-pattern directive code changed from
ctrl.$validators.pattern = function(value) {
    return ctrl.$isEmpty(value) || isUndefined(regexp) || regexp.test(value);
 };

to
ctrl.$validators.pattern = function(modelValue, viewValue) {
    // HTML5 pattern constraint validates the input value, so we validate the viewValue
     return ctrl.$isEmpty(viewValue) || isUndefined(regexp) || regexp.test(viewValue);
 };

For future reference: #15765


chore: update admin/*/composer.json

Description
Both appstarter and framework are for CodeIgniter projects, and the configuration itmes to be added in this PR should be the same.

add config
remove suggest in appstarter

Checklist:

[x] Securely signed commits
[] Component(s) with PHPDoc blocks, only if necessary or adds value
[] Unit testing, with >80% coverage
[] User guide updated
[] Conforms to style guide

@totoprayogo1916 I remove suggest in appstarter.
If we add it, it shows the same things as the framework's suggest.
$ composer suggest
codeigniter4/appstarter suggests:
 - ext-oci8: If you use Oracle Database
 - ext-sqlsrv: If you use SQL Server
 - ext-memcache: If you use Cache class MemcachedHandler with Memcache

codeigniter4/framework suggests:
 - ext-memcache: If you use Cache class MemcachedHandler with Memcache
 - ext-oci8: If you use Oracle Database
 - ext-sqlsrv: If you use SQL Server

fakerphp/faker suggests:
 - doctrine/orm: Required to use Faker\ORM\Doctrine

2 additional suggestions by transitive dependencies can be shown with --all

It seems because you have installed fileinfo.


Data Explorer Aggregates Layers with Same Attribute Name

For example, I have a voxel project with 4 Twitter layers (corresponding to different times of day) and an accident layer. Rather than showing 5 layers in the chart, the chart shows 2 layers. It looks like it is aggregating data layers with like attribute names (count1).
http://paintingwithdata.mit.edu/app/10

Solved here. Now we name the axis in the data explorer by adding the layer name as a prefix.


add support for Audio Cues (notebook cell completion)

Is it possible to add the ability to configure an audio bell in vscode settings.json to sound upon completion of a cell in jupyter notebook? If so, is there any reason in particular this is not yet implemented or is it on the horizon? Thanks.

Looks like you are also assigned to Audio Cues issues @isidorn? If this is easy to adopt I could take a look with some pointers. Maybe the "taskCompleted" sound can be repurposed or would we need a new one?

I agree the task completed could be helpful here. Let me assign to @meganrogge for consideration
@roblourens it should be easy to adopt. You just use the audioCueService. Code pointer https://github.com/microsoft/vscode-distro/blob/6c2adaa1ab153382818ff972d16377cd3a101e25/src/vs/workbench/contrib/inlayHints/browser/inlayHintsAccessibilty.ts#L159

@roblourens you could also use taskFailed if the cell fails to execute/complete

Hi everyone, I've open a PR with a possible implementation, let me know if it is helpful.
ps: @isidorn thank you for your code pointer

I needed this feature but the implementation is for simple on/off switch. It would be nice if we can play sound only if the cell takes more than a pre-specified threshold. We don't need a sound for each cell, rather for the ones that take long time to run.


Integration tests/prognostic run broken

06934dc6494cd282cb404b3624c084292a1329f4 broke the integration tests. The logs were a bit tricky to track down (had to look in gs://vcm-ml-scratch/test-end-to-end-integration/2021-09-15/39b4fcd-e96a-nudge-to-fine-run/fv3gfs_run/artifacts/20160801.001500/logs.txt), but this is the error:
KeyError: 'pressure_thickness_of_atmospheric_layer'
Traceback (most recent call last):
  File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/usr/local/lib/python3.6/dist-packages/mpi4py/__main__.py", line 7, in <module>
    main()
  File "/usr/local/lib/python3.6/dist-packages/mpi4py/run.py", line 196, in main
    run_command_line(args)
  File "/usr/local/lib/python3.6/dist-packages/mpi4py/run.py", line 47, in run_command_line
    run_path(sys.argv[0], run_name='__main__')
  File "/usr/lib/python3.6/runpy.py", line 263, in run_path
    pkg_name=pkg_name, script_name=fname)
  File "/usr/lib/python3.6/runpy.py", line 96, in _run_module_code
    mod_name, mod_spec, pkg_name, script_name)
  File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/fv3net/workflows/prognostic_c48_run/runtime/main.py", line 48, in <module>
    for time, diagnostics in loop:
  File "/fv3net/workflows/prognostic_c48_run/runtime/loop.py", line 475, in __iter__
    diagnostics.update(substep())
  File "/fv3net/workflows/prognostic_c48_run/runtime/loop.py", line 404, in _compute_postphysics
    self._state.time, self._state
  File "/fv3net/workflows/prognostic_c48_run/runtime/steppers/nudging.py", line 49, in __call__
    tendencies = get_nudging_tendency(state, reference, self._nudging_timescales)
  File "/fv3net/workflows/prognostic_c48_run/runtime/nudging.py", line 234, in get_nudging_tendency
    return_dict[STATE_NAME_TO_TENDENCY[name]] = return_data
KeyError: 'pressure_thickness_of_atmospheric_layer'

I'm surprised this didn't cause any errors in the regression tests. If possible, we should modify the nudging configuration to more closely match the integration tests, so that we can catch this earlier.
cc @AnnaKwa

Fixed by PR https://github.com/VulcanClimateModeling/fv3net/pull/1359


GDS Fails To Launch With Unknown Types In Dictionary

F´ Version
all

Problem Description
The GDS crashes on launch when provided with a dictionary containing references to a handcoded type. See: https://github.com/nasa/fprime/discussions/1643#discussioncomment-3484767
This may also apply to other complicated types like serlizables.
Expected Behavior
Instead of failing to launch, the GDS should launch but warn that it's unable to deserialize EVRs referencing the handcoded type.

Moved to: https://github.com/nasa/fprime/issues/2230


Fix poster play so hides on click or play event only

or whilst buffering is happening (because buffering indicator will be in the same place)
Refs #998

Coverage remained the same at 70.166% when pulling 1542b6dc27fdf76ecfb14fcc948581d8ca8c40d5 on fix-poster-play-hiding into efbacded402b6cc1872ea48f5c182ae0867f062f on master.

LGTM

🍻 @tjenkinson


Prompt nested calls?

Hi,
Thanks for the hard work, this library makes a lot of sense in my work flow.
I was wondering if that is possible to use Inquirer.js nested calls:
https://github.com/SBoudrias/Inquirer.js/blob/master/packages/inquirer/examples/nested-call.js
Cheers.

Ok, found it!
http://www.hygen.io/generators/#advanced-params
Awesome, no more prompt array limitations.


Persisting built geometry including texture/material

I've been looking around, but can't find anything on the topic.
I need to be able to store a SabreCSG model to be loaded in at runtime (level instansing and such).
I know there is a way to build the geometry built in SabreCSG into a .obj file, however this strips away any textures previously applied to the model.
I have tried to create a prefab with the SabreCSG model in it, but whenever I pull it into a scene the model needs to be re-built. This is an issue since there is no run-time brush-building from what I've gathered. It also breaks any prefab instance, meaning that if I later update the prefab it will not reflect in the scene. Is there a way for us to be able to persist the full SabreCSG model including textures other than keeping it stored in a scene and loading that in?
Thanks!

The reason for this behaviour is that there are two ways to store a generated mesh asset - implicitly by just generating a mesh in a scene (these kind of assets are stored in the scene file), or explicitly by generating a .asset file on disk (allowing the mesh asset to be referenced by a prefab or other scenes). Right now SabreCSG only supports mesh assets that are part of the scene, but I'll take a look at what's required to add a mesh asset option.

Okay! I'd be happy to help if necessary/wanted. A second follow up question: is it possible to export UV'S and textures/materials alongside the .obj export?

The OBJ exporter should export the primary UVs correctly, but does not export textures or materials as that's something I've never got around to adding. If you wanted to add that support it would be very much appreciated!

Had a quick look at this issue and I've added an experimental option for it - see https://github.com/sabresaurus/SabreCSG/commit/b2a6b8f709a194bdeb8ae55a894da411b9a568e9

Thank you for speedy response! I'll try it out later today.
I'd love to give material/texture exporting a go, could you perhaps point me in the right direction where to look in the code, and I'll see what I can conjure up!

Sure, so the main class that handles exporting OBJs in SabreCSG is the
OBJFactory
https://github.com/sabresaurus/SabreCSG/blob/master/Scripts/Geometry/OBJFactory.cs
From memory, in addition to the OBJ file we need to export an MTL file
which holds the materials, references to the materials should then be
hooked up in the OBJ using the 'usemtl' command.
There's actually quite a good spec for it on Wikipedia -
https://en.wikipedia.org/wiki/Wavefront_.obj_file
Barnaby Smith
Director | Sabresaurus Ltd. http://sabresaurus.com
http://sabresaurus.com/
Follow Sabresaurus on Twitter https://twitter.com/sabresaurus
On 15 March 2017 at 06:14, Alex<EMAIL_ADDRESS>wrote:

Thank you for speedy response! I'll try it out later today.
I'd love to give material/texture exporting a go, could you perhaps point
me in the right direction where to look in the code, and I'll see what I
can conjure up!
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/sabresaurus/SabreCSG/issues/5#issuecomment-286650730,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQ9eywBwGhg-ZQYGhiMey7nzIXxdDEWOks5rl4G_gaJpZM4Majt3
.

Hmm. I'm getting some errors with building that last commit. I'm on  5.5.1f and it complains that the "EditorSceneManager.EnsureUntitledSceneHasBeenSaved(string) is inaccessible due to its protection level".
Sorry for the confusion, I was referring to saving the textures/materials as a unity material file that can just be pulled onto the meshrenderer, although I think I'll give the MTL export a shot!


CMake not working with experimental nix develop command

Describe the bug
Within nix develop, buildPhase uses make instead of cmake:
$ nix build -f .

  CMake Error at CMakeLists.txt:1 (message):
    used CMake

$ nix develop --build -f .

Makefile:1: *** used Make.  Stop.

To Reproduce
==> default.nix <==
with import (builtins.fetchTarball "https://nixos.org/channels/nixos-unstable/nixexprs.tar.xz") {};

stdenv.mkDerivation {
  name = "nix-develop-cmake-test";
  buildInputs = [ cmake ];
  src = ./.;
}

==> Makefile <==
$(error used Make)

==> CMakeLists.txt <==
message(FATAL_ERROR "used CMake")

Expected behavior
buildPhase uses cmake within nix develop
Metadata

system: "x86_64-linux"
host os: Linux 4.19.116, NixOS, 19.09.2520.289466dd6a1 (Loris)
multi-user?: yes
sandbox: relaxed
version: nix-env (Nix) 3.0pre20200829_f156513
channels(atnnn): "home-manager"
channels(root): "nixos-19.09.2520.289466dd6a1, nixos-unstable-21.03pre243690.441a7da8080"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

Have you tried putting CMake into nativeBuildInputs.

cmakeConfigurePhase has to be run before building


GitHub Token on GitHub Enterprise Server does not work

When we use this action on GitHub Enterprise Server the default github token does not work (HttpError: Bad credentials)
Can this action be fixed to be used without a token? Or is there any other approach?
But: We do not want to put GitHub.Com Tokens into our GitHub Enterprise Instance.
Thanks a lot.

Thank you. I tried your suggestion. And it works :-)
Is it possible to completely avoid accessing the GitHub Api or minimize it to not run in such problems?
Otherwise we can install tflint just in our image.

No, the GitHub API is used to discover releases. HashiCorp runs their own release infrastructure for both CLIs and plugins at a substantial cost.
If you want a fixed version rather than discovery, bundling will work. Keep in mind you need to do this for both TFLint itself and plugins. The internal mechanism in the CLI for loading plugins uses the same mechanics as this action, minus the ability to use "latest." Running tflint --init when building your image should take care of that, provided you configure the same version you'll use in your jobs.


Check for executables is not working for "global binaries" (Image Optimizations)

This change introduced a file check for the binary: https://github.com/aelvan/Imager-Craft/commit/7aabb13136850f521c58628f86eb0d446eadbc4f
If the binary is available via the default os paths (/bin,…) this check will fail and return that the file does not exist.
Using the custom Path for the binary is not an option if the open_basedir restricts access to /bin,…

See issue #85
I did not found a solution besides removing the conditional.

How about adding an option, so the file check can be disabled? This would at least enable the optimization on such systems.

I've added a skipExecutableExistCheck config setting to version 1.5.1 that let's you disable the check.


Added the 'hellofastj' package

Added the 'hellofastj' package
Additions

Added a new package in the example directory called hellofastj
Added code to:

Initialize the engine with the title "Hello, FastJ!"
Run the engine with an empty scene and LogicManager
Display an empty window

PRs related to #20 should be merged into the tutorials branch.


stdenv/darwin/make-bootstrap-tools.nix: add libcodedirectory.1.dylib

Description of changes
libcodedirectory.1.dylib is needed by ld64 and several tools from cctools such as codesign_allocate.
Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] 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/)
24.11 Release Notes (or backporting 23.11 and 24.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

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Thanks.


Azure Container Registry / Manifests - Get Attributes endpoint not working as per documentation

As per the documentation endpoint should accept both tag and digest.
https://learn.microsoft.com/en-us/rest/api/containerregistry/manifests/get-attributes?tabs=HTTP
But the response is only coming when I give digest. For tag getting 404 page not found.
Tried hitting the endpoint with Postman as well from NodeJs code getting the same results.

With digest: Masking the registry for security reasons. Getting 200 OK as a response

Without digest: Giving tag instead. Getting 404 not found

@MageshSrinivasulu
Thanks for your feedback! We will investigate and update as appropriate.

@tejaswikolli-web
Can you please check and add your comments on this doc feedback as applicable.
Note: This is a API doc related to ACR. Request you to loop in appropriate members who can help on this.
https://learn.microsoft.com/en-us/rest/api/containerregistry/manifests/get-attributes?tabs=HTTP

Sure, I will update you shortly.

We have changed the documentation as just Digest. This supports just Digest.

#please-close


Add proposed view of integration with Analytical Platform

What does this pull request do?
Adds the proposed view of how Legal Aid Agency systems/services might integrate with the Analytical Platform.
It focuses on team interactions and integrations.
⚠ This diagram is a proposed view and will change.
However, we can still merge it if the proposed state is evident.
Why make these changes?
The Legal Aid Agency's "Data and Reporting" team is investigating the feasibility of moving to the Ministry of Justice's Analytical Platform.
I wanted to capture the current view of the integration.
What is the result?

Any ideas on how to make the "proposed" or "draft" status more apparent? The filename? Titles?

Interesting. A few questions:

Is LAA Management information team the same as Data and Reporting team? I thought Analytical platform team and MI team were part of the same team
There’s something I don’t understand from the diagram in relation to subject area transformer: Analytical platform team manages it but the Data and Reporting team owns the rules in it? Doesn’t that cause any issue in terms of who changes these rules?
In a future diagram, the two users (Analytical Platform and MI team) would be merged into one team?

@ddippolito 🙇

Is LAA Management information team the same as Data and Reporting team? I thought Analytical platform team and MI team were part of the same team

No, the LAA MI team is a non-digital functional team, working to provide LAA reports to business users.
The "Data and Reporting team" is a digital team owning some of the MI transformation processes and the business intelligence application. This diagram's "LAA Service Team" encompasses them.

There’s something I don’t understand from the diagram in relation to subject area transformer: Analytical platform team manages it but the Data and Reporting team owns the rules in it? Doesn’t that cause any issue in terms of who changes these rules?

I think the idea is: Platform team owns the infrastructure, Analyst/MI teams own the content. Perhaps I should re-label to make this explicit.

In a future diagram, the two users (Analytical Platform and MI team) would be merged into one team?

I doubt it; I think the intended split of infrastructure/content will remain the same.

@sldblog Thanks for clarifying 🎉

:tophat: :bowing_man:


breakfix:  RBAC can't access [realm_access-roles]

Describe the issue**
RBAC can't access:

realm_access - roles
app_metadata - authorization - roles

Expected behavior
According the documentation
By default, the plugin should finds role information in the following token fields:

roles
role
group
groups
app_metadata - authorization - roles
realm_access - roles

I believe I am experiencing this issue and have documented my approach to setting app_metadata.authorization.roles in this Auth0 thread.
I think the next step for me to confirm the condition is to find a way to  access the portal's /whoami page so I  can inspect the token received by Caddy Security. Presently, I am always redirected to /login with I visit that page, even when I'm already authenticated.
		authentication portal authn {
			crypto default token lifetime 3600
			crypto key sign-verify {env.JWT_SHARED_KEY}
			enable identity provider auth0
			cookie domain {$ZROK_DNS_ZONE}
			ui {
				links {
					"Homepage" "https://www.example.com" icon "las la-home"
					"My Account Info" "/whoami" icon "las la-user"
				}
			}
		}

		authorization policy authz {
			set auth url https://auth.example.com/oauth2/generic
			crypto key verify {env.JWT_SHARED_KEY}
			allow roles user
			validate bearer header
			inject headers with claims
		}

Although I can not access the portal's account info page when the provider is enabled, only when local store is enabled, I do see the debug logs that include the id token and access token from the provider.
Strangely, the access token has no claims. Only the header and signature are defined. The OAuth 2.0  server access token from Auth0, which is a JWT, looks like this asdklfjhasdkljh..lkjhasdlkjhasdlkjhsadlkjhasdflkjhasdf (zero bytes in the claimset between header and signature).
Then Caddy Security does something unexpected.

DEBUG: decoded claims from OAuth 2.0 authorization server access token

The claims shown next are from the OIDC id token, not the OAuth access token. Maybe Caddy Security has confused the two?

The claims shown next are from the OIDC id token

@qrkourier , see the below source code references. https://github.com/search?q=repo%3Agreenpau%2Fgo-authcrunch id_token&type=code
Happy to jump on google meet to troubleshoot. Feel free to reach me on LinkedIn.


Uncaught TypeError: Cannot read property 'setScrollTop' of null

I have had this issue for a long time now but unfortunately I haven't been able to solve it. I even had to ask for help in StackOverflow and some dudes apparently have sent the repo admins pull requests. but no updates has came so far. I would appreciate if you could solve this. it is irritating.
you may find the complete explanation in this SO post:
http://stackoverflow.com/questions/41351215/atom-editor-atom-beautify-plugin-error-uncaught-typeerror-cannot-read-propert

This appears to be a duplicate of #1339.  Thank your for the SO link as the additional information may prove very helpful.


The perlin_interp function not returning correct values?

When I followed the tutorial in the book, I found that just before the turbulence is added I encountered some issues with my scene not rendering correctly.
I expected it to look like this:

What I actually got was this:

After continuing the tutorial to the turbulence section, I noticed that fabs() was used on the accumulated total. I wondered if this would fix my issue with the perlin_interp function (i.e. noise.noise() not noise.turb()), so I used it at the end there.
It did get rid of the black boxes but the result was also still not quite what was intended:

Perhaps this is because I used a scale value of 1, but setting it higher leads to results more similar to using turbulence.

Can confirm. I'm getting the same exact results at this point of the book. And the same when using fabs(). Unfortunately I'm not sure how to fix it! I can at least say I had the same looking images.

Update: I left this issue for a while, and progressed with the rest of the book but I went back to it today.
I decided to clamp the value before outputting it to the texture file instead of in the perlin_interp() function and got a result that looked closer to the intended result, but it still had a lot of contrast. Here it is:

I think that the low contrast image provided in the book is not what you'll receive if you follow along (there have been errors in the book up to that point, so it might just be one of them).
If you apply turb using the perlin noise function that gives the high contrast result as above, you will get the expected output just like in the book.

The issue with the book version is perlin_interp, without the turb function, can return negative values due to the dot product. This leads to negative values being passed to the sqrt function. You can recreate the correct output at that specific point in the book simply by rescaling the dot product from -1 to 1 to 0 to 1.
inline float perlin_interp(vec3 c[2][2][2], float u, float v, float w) {
  float uu = u*u*(3-2*u);
  float vv = v*v*(3-2*v);
  float ww = w*w*(3-2*w);
  float accum = 0;
  for(int i = 0; i < 2; i++) {
    for(int j = 0; j < 2; j++) {
      for(int k = 0; k < 2; k++) {
        vec3 weight_v(u-i,v-j, w-k);
        accum += (i*uu + (1-i)*(1-uu))*
                 (j*vv + (1-j)*(1-vv))*
                 (k*ww + (1-k)*(1-ww))*
                 0.5 * (1 + dot(c[i][j][k], weight_v));
      }
    }
  }
  return(accum);
}

@tylermorganwall you are right. An alternative can be to scale the final accum result, instead of each  dot product:
inline float perlin_interp(vec3 c[2][2][2], float u, float v, float w) {
  float uu = u*u*(3-2*u);
  float vv = v*v*(3-2*v);
  float ww = w*w*(3-2*w);
  float accum = 0;
  for(int i = 0; i < 2; i++) {
    for(int j = 0; j < 2; j++) {
      for(int k = 0; k < 2; k++) {
        vec3 weight_v(u-i,v-j, w-k);
        accum += (i*uu + (1-i)*(1-uu))*
                 (j*vv + (1-j)*(1-vv))*
                 (k*ww + (1-k)*(1-ww))*dot(c[i][j][k], weight_v);
      }
    }
  }
  return (accum + 1.0) * 0.5;
}

I think it brings to similar results


Argument algorithm_name

Hello again! Hope you are doing well!
I spent some more time looking at the command line arguments and I am confused with algorithm_name
Supported algorithms are:  1. AutoFuzz (GA-UN-NN-GRAD), 2. NSGA2-SM, 3. NSGA2-DT, 4. AV-Fuzzer.
But by reading the code I see algorithm_name can be any of:
- random
- random-un
- avfuzzer
- nsga2
- nsga2-un-dt
- nsga2-dt
- nsga2-un
- naga2-emcmc
- nsga2-un-emcmc

Am I missing any possible input for algorithm_name?
Can you label supported algorithm with its corresponding algorithm_name?

Thank you in advance!

Hi @YuqiHuai , I have updated the readme with key relevant parameters for the supported algorithms. Please have a look.

Thank you for the update! They are very clear to me now.


rados/striper test suite is flaky on octopus

Example: https://github.com/ceph/go-ceph/actions/runs/10413135499/job/28840033245
The new rados/striper package appears to occasionally panic when the test suite is run with the ceph octopus job.
Over the past week it has failed 2 or 3 times.
Given that this only appears to occur on octopus and octopus is next on this to lose support in the go-ceph test matrix I'm considering just disabling rados/striper on octopus preemptively. But I haven't made up my mind yet and I am open to suggestions.

Example: https://github.com/ceph/go-ceph/actions/runs/10413135499/job/28840033245

=== RUN   TestStriperTestSuite
=== RUN   TestStriperTestSuite/TestListXattrs
=== RUN   TestStriperTestSuite/TestNewStriper
=== RUN   TestStriperTestSuite/TestNewStriperWithLayout
=== RUN   TestStriperTestSuite/TestReadAppend
coverage: 63.8% of statements in github.com/ceph/go-ceph/rados/striper
panic: test timed out after 10m0s
	running tests:
		TestStriperTestSuite (10m0s)
		TestStriperTestSuite/TestReadAppend (9m59s)
. . .
goroutine 24 [syscall]:
github.com/ceph/go-ceph/rados._Cfunc_rados_shutdown(0x7f32540134c0)
	_cgo_gotypes.go:1606 +0x3f
github.com/ceph/go-ceph/rados.freeConn.func1(0xc000141c90?)
	/go/src/github.com/ceph/go-ceph/rados/rados.go:126 +0x34
github.com/ceph/go-ceph/rados.freeConn(0xc000204b00)
	/go/src/github.com/ceph/go-ceph/rados/rados.go:126 +0x45
github.com/ceph/go-ceph/rados.(*Conn).Shutdown(...)
	/go/src/github.com/ceph/go-ceph/rados/conn.go:77
github.com/ceph/go-ceph/rados/striper.(*StriperTestSuite).TearDownTest(0xc000072240)
	/go/src/github.com/ceph/go-ceph/rados/striper/striper_test.go:70 +0x35
github.com/stretchr/testify/suite.Run.func1.1()
	/go/pkg/mod/github.com/stretchr/testify@v1.9.0/suite/suite.go:184 +0x269
github.com/stretchr/testify/suite.Run.func1(0xc0002404e0)
	/go/pkg/mod/github.com/stretchr/testify@v1.9.0/suite/suite.go:203 +0x498
testing.tRunner(0xc0002404e0, 0xc0002001b0)
	/opt/go/src/testing/testing.go:1690 +0xf4
created by testing.(*T).Run in goroutine 7
	/opt/go/src/testing/testing.go:1743 +0x390
FAIL	github.com/ceph/go-ceph/rados/striper	600.108s

I see TearDownTest in the backtrace. At least this one most likely timed out.
I couldn't find any other occurrence(post merge) where it points at a real failure.

CI runs are stable enough these days. Please reopen in case it fails more consistently.


The response should be parsed by Insomnia

Recently, I migrated from Postman to Insomnia and it worked very well. A few moments ago I tried to get a response from a private service and the result didn't work as expected.
The Header contains:
Cache-Control | no-cache
Pragma | no-cache
Content-Type | application/x-gzip; charset=UTF-8
Server | Microsoft-IIS/8.5
X-AspNet-Version | 4.0.30319
X-Powered-By | ASP.NET
...

Screenshots
I ran the same request in Postman and worked as expected.
Postman

Insomnia

OS

OS: Mint 19.2 Cinnamon
Installation Method: apt-get
Versions

Can you please provide a public endpoint that can be used to reproduce this?

Hi @gschier thanks for the response. I don't know how proceed to reproduce this case, it is a paid service that I don't have access to the server. I stored the response obtained by Postman and I built a simple api to provide the data. The Insomnia got the data with success. I think it is something related to client-side when try to enconding/parsing the data but I really don't know what happened.

Without being to reproduce this error, it's hard for us to know what was in the data that caused the parsing error.  While I understand that this is frustrating to encounter, I feel I should close this issue until more definite details are available.  Please feel free to open a new issue if you are able to give more details


Fix displayed coverage

Mark tests assembly with ExcludeFromCodeCoverage because it has been creating noise for coverage analysis by either analyzing the lines that don't matter or straight up incorrectly calculating it for local methods or exception-checking asserts.

Coverage increased (+5.6%) to 100.0% when pulling 5a42f3c902db1f1a325feeee2c548358ef8166e9 on fix-displayed-coverage into 8d6f42b939e20664c8836e6bbfaafbd210803434 on main.


Linting errors are thrown from the default template when enabling prettier

This PR should resolve the errors that are thrown by the default template when users enable the prettier option during project creation.

@liam-potter Nice catch :) What about prettier errors with all other templates e.g. vuetify, buefy etc. Did u checked it?

@aldarund The only other framework template with CSS changes required for prettier was Vuetify - I have now updated the required files too.
I have also fixed https://github.com/nuxt-community/create-nuxt-app/issues/97 in this PR.

https://github.com/nuxt/nuxt.js/issues/3933 will also be resolved by this (related to https://github.com/nuxt-community/create-nuxt-app/issues/97).


Use a context class passed via constructor for nicer dependency injection

Take some design cues from Urho3D. It's much cleaner to pass in a special object rather then mess about with Singletons and passing in a hundred things into some classes.

Completed in feature/refactor branch


Central Panel Need to hide the Menu ICONS

How to hide the Central Panel choose hide the Left Menu and Right Menu icons.

Hi @mekalasiva
Just call the openCenter(animated:Bool) to open the existing centre panel.

or if you want to change it then use below code,
        let panelVC = FAPanelController()
                homeVC = UIStoryboard.home.instantiateInitialViewController()
            _ = panelVC.center(homeVC!)
        window?.rootViewController = panelVC

What is homeVC?is it any class method name?

Any centre controller you want to assign to centre panel.

Either a UIViewController, UINavigationController or a UITabBarController etc.


Possibility to set differ options

Need
As a user
I need to have the possibility to set my diffing options
So that I can have more control over the diff process

Deliverables
A better LooksSame Adaptor, that stores the user options and then uses it.
Solution
Exactly like the WebdriverIOAdaptor.
Constructor:
function LooksSameAdapter(userOptions) {
   var options = {
     highlightColor: '#ff00ff',
     strict: true,
     save: false
   };

   this._options = userOptions || options;
   this._options.save = false;
}

@andrei-picus-hs please review specs

@flore77 can you please add more details about how the constructor will look like? Code snippets are welcome.

sure.

done @andrei-picus-hs

I see that the adapter has two sets of options: one for isEqual and one for createDiff. I'm OK with bundling them together in the constructor, but you should use object-assign to merge the given options with the defaults so a user can specify only a subset.

Aa yes you are right, to use object-assign, so the user can override only some of the defaults.
Yes they are slightly different, the createDiff methods receives the highlightColor. The save options does not even exists.

How about dropping the save: false and let it return a buffer when no diff: path is specified?

at the suggestion on the PR made on looks-same repo.
I have updated the constructor. We must enforce diff.path to be undefined, otherwise Mugshot will have undefined behaviour, because it will not receive a Buffer. take a look @andrei-picus-hs

We must enforce diff.path to be undefined

Because we fear the user might pass in a value for it, right? SGTM.

Yes.

@andrei-picus-hs please review the code :smile:

should we also have a test like should be the default options if the no others are provided ?

should we also have a test like should be the default options if the no others are provided ?

You're implicitly checking that through the other tests.
LGTM.


Problems with self-signed certificates

Hey - thanks for all your work. I was able to get the APM integration up and running on an ELK stack that was based on sherifabdlnaby/elastdocker. The problem I had was that the certificates it generates are self-signed and when the Guzzle7 adapter attempts to contact the APM server using https: there was no configuration option that I could find that provided either:

a way to specify a custom CA certificate
turn of verification of the certificate

In the end I had to subclass the ServiceProvider with my own implementation that created a hand-rolled client and fed that to AgentBuilder.
It works, but for such a simple use-case I'm wondering if I missed something? I found this issue for the official PHP APM agent: https://github.com/elastic/apm-agent-php/issues/414 - and they supported a verify_server_cert=false in the php.ini file or a ELASTIC_APM_VERIFY_SERVER_CERT env var. As far as I could tell this project doesn't.
I'm not used to using Psr18ClientDiscovery::find() which is what nipwaayoni/Middleware/Connector uses under the hood to create the default http client - so I don't know if it's possible to hook into that process and feed it config options.
I'll post my subclass here in case others find it helpful. I'd be curious to know if there's a simpler solution.
class CustomElasticApmServiceProvider extends ElasticApmServiceProvider
{
    protected function registerAgent(): void
    {
        $this->app->singleton(Agent::class, function ($app) {
            // Use the original configuration method
            $agentConfig = $this->getAgentConfig();

            // Configure Guzzle to not verify SSL
            $guzzleClient = new GuzzleClient(['verify' => false]);

            // Wrap the Guzzle client with a PSR-18 adapter
            $psr18Client = new GuzzleAdapter($guzzleClient);

            $builder = $this->app->make(AgentBuilder::class);

            // Building the agent with custom HTTP client and existing configurations
            return $builder
                ->withConfig(new Config($agentConfig))
                ->withHttpClient($psr18Client) // Inject the custom-configured HTTP client
                ->withEnvData(config('elastic-apm-laravel.env.env'))
                ->withAppConfig($this->app->make(Repository::class))
                ->withEventCollectors(collect($this->app->tagged(self::COLLECTOR_TAG)))
                ->build();
        });
    }
}

Enabling the HTTP client configuration would need to start in underlying agent rather than this package. I'm not exactly sure how support client auto-discovery while enabling client configuration (which may vary by client). The 'bring your own client" approach is the compromise. If you want to open an issue we can further explore options.
For this package, we've used a slightly different approach to configure the client. In the standard AppServiceProvider::register() method, you can bind a configured AgentBuilder and provide only the http client:
        $this->app->bind(AgentBuilder::class, function () {
            $builder = new AgentBuilder();

            $builder->withHttpClient(new \Http\Adapter\Guzzle7\Client(new Client(['verify' => false])));

            return $builder;
        });

Do you want to give that a try and see if it works for you? If so, we can suggest this be added to the documentation of this project.

Hi @ElvisIsKing666,
As mentioned by @dstepe, this is the way to go. We actually use this approach to reduce the timeout when connecting to Elasting:
$this->app->bind(AgentBuilder::class, function (): AgentBuilder {
    $builder = new AgentBuilder();
    $builder
        ->withHttpClient(new GuzzleClient([
            'timeout' => 1.0,
        ]));

    return $builder;
});

Ah, right, I see now that the original service provider is calling app()->make() to get the AgentBuilder. So all I need to do is just bind a new one with the client configured the way I need it. Thanks for pointing that out.


feat: add module versioning compat checks

As discussed in https://github.com/dagger/dagger/issues/7640.
This is a follow-up to https://github.com/dagger/dagger/pull/5315, which will allow us to add a backwards compatibility check if/when we make breaking changes to the module API, etc.
This uses the engineVersion field introduced in 1377f13 (#6469).

Hm, had an idea - so currently, in this PR, we have the ability to enforce a minimum version compatibility for modules that require engine versions that are too old.
Should we also enforce a minimum compatibility for engine versions that too new? e.g. if I try and run a module that has engineVersion v0.12.1 on an engine version v0.12.0, should we explicitly error out?
Obviously, this has the potential to introduce some more friction in upgrading, but on the plus side, we get a more useful error message about what's wrong (instead of getting weird type errors all over the place from each SDK as they encounter things that don't exist). Additionally, this constraint could hopefully motivate users to upgrade to more recent dagger versions - if a daggerverse module uses dagger v0.12.1, then a user has to upgrade to use that.

Right, decided to implement my above comment - if a user tries to run a v0.13.0 module on v0.12.0, this should definitely fail - it will probably not compile.
This is similar in behavior to how go.mod works in compilation of it's code - so shouldn't be too unexpected.


[FSDE-21008] Update dependencies to fix dependabot alerts

The CI pipeline did not run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-398/1/. :x:

The CI pipeline did not run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-398/2/. :x:

The CI pipeline has run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-398/3/. :white_check_mark:

You can check this PRs instance in https://799ba6930a18176f9ad78f121f4f201c667047f2-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-398-ux-chi.kubeodc-test.corp.intranet/ (internal)


Node.js Code Samples - PostgreSQL - Remove Node Install

I think that we can assume that if people are looking at a Node guide, they already have Node installed. It seems OK to me to just have it listed as a prerequisite.

@burkeholland,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

Wrong repo. Moving internal.