Identifiers validation failed for dataset Phytoplankton North Adriatic-Gulf of Trieste C1 – LTER time-series from 2010 onwards

Identifier validation failed for the dataset Phytoplankton North Adriatic-Gulf of Trieste C1 – LTER time-series from 2010 onwards:

Crawler attempt: 109
Publishing organization: National Institute of Oceanography and Applied Geophysics
Publishing country: ITALY
Installation: National Oceanographic Data Centre for Italy
Number of occurrences indexed for this dataset at the time of the issue: 43392
Cause: GBIF ID problems exceed 50% threshold: 100% duplicates; 240768 total records; 240768 absent records
Pipelines execution steps: http://api.gbif.org/v1/pipelines/history/execution/4000857/step

New IDs sample:

Old IDs sample:

2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Acanthoica quattrospina_urn:lsid:marinespecies.org:taxname:235802_present
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Acanthoica spp._urn:lsid:marinespecies.org:taxname:115083_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Acanthosolenia_urn:lsid:marinespecies.org:taxname:602985_mediterranea_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Achnanthes brevipes_urn:lsid:marinespecies.org:taxname:149387_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Achnanthes spp._urn:lsid:marinespecies.org:taxname:149191_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Actiniscus pentasterias_urn:lsid:marinespecies.org:taxname:109717_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Akashiwo sanguinea_urn:lsid:marinespecies.org:taxname:232546_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Alexandrium pseudogonyaulax_urn:lsid:marinespecies.org:taxname:109713_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Alexandrium spp._urn:lsid:marinespecies.org:taxname:109470_present
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Alexandrium_urn:lsid:marinespecies.org:taxname:109470_minutum_absent

Publisher email
Hello,
I am contacting you from the GBIF Secretariat about a dataset published by the Phytoplankton North Adriatic-Gulf of Trieste C1 – LTER time-series from 2010 onwards : https://doi.org/10.13120/rf7p-7w07.
We noticed that the occurrenceIDs were changed. We have temporarily paused the ingestions of this dataset.
As you might already know, when an occurrence record has a new occurrenceID for a given dataset, our system considers it to be a new occurrence.
This means that it will be given a new gbifid and a new occurrence URL (like this one: https://www.gbif.org/occurrence/1252968762) and the old gbifid and URL will be deprecated.
In this case, this means that the occurrence URLs would be deprecated when ingesting the newest versions of these datasets.
We would like to check with you if those changes were intentional. Do you know if this is the case?
Please let us know, thanks! We are happy to resume the dataset ingestion.
Note that some users rely on those occurrence URLs and gbifids (like https://bionomia.net for example). In an attempt to improve
the stability of the occurrence URLs and gbifids, we have implemented a warning system to detect these type of changes in datasets (see this news item).
If the data publisher can provide us with a list of old and new occurrenceIDs per record, we can avoid the identifier and URL changes. Could that be an option?
Please let us know if you have any question. Thanks!
All the best,

You can skip/fix identifier validation using the registry UI.

Identifier validation still  failing for the dataset Phytoplankton North Adriatic-Gulf of Trieste C1 – LTER time-series from 2010 onwards:

Crawler attempt: 111
Publishing organization: National Institute of Oceanography and Applied Geophysics
Publishing country: ITALY
Installation: National Oceanographic Data Centre for Italy
Number of occurrences indexed for this dataset at the time of the issue: 43392
Cause: GBIF ID problems exceed 50% threshold: 100% duplicates; 240768 total records; 240768 absent records
Pipelines execution steps: http://api.gbif.org/v1/pipelines/history/execution/4000883/step

New IDs sample:

Old IDs sample:

2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Acanthoica quattrospina_urn:lsid:marinespecies.org:taxname:235802_present
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Acanthoica spp._urn:lsid:marinespecies.org:taxname:115083_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Acanthosolenia_urn:lsid:marinespecies.org:taxname:602985_mediterranea_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Achnanthes brevipes_urn:lsid:marinespecies.org:taxname:149387_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Achnanthes spp._urn:lsid:marinespecies.org:taxname:149191_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Actiniscus pentasterias_urn:lsid:marinespecies.org:taxname:109717_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Akashiwo sanguinea_urn:lsid:marinespecies.org:taxname:232546_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Alexandrium pseudogonyaulax_urn:lsid:marinespecies.org:taxname:109713_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Alexandrium spp._urn:lsid:marinespecies.org:taxname:109470_present
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Alexandrium_urn:lsid:marinespecies.org:taxname:109470_minutum_absent

Publisher email
Hello,
I am contacting you from the GBIF Secretariat about a dataset published by the Phytoplankton North Adriatic-Gulf of Trieste C1 – LTER time-series from 2010 onwards : https://doi.org/10.13120/rf7p-7w07.
We noticed that the occurrenceIDs were changed. We have temporarily paused the ingestions of this dataset.
As you might already know, when an occurrence record has a new occurrenceID for a given dataset, our system considers it to be a new occurrence.
This means that it will be given a new gbifid and a new occurrence URL (like this one: https://www.gbif.org/occurrence/1252968762) and the old gbifid and URL will be deprecated.
In this case, this means that the occurrence URLs would be deprecated when ingesting the newest versions of these datasets.
We would like to check with you if those changes were intentional. Do you know if this is the case?
Please let us know, thanks! We are happy to resume the dataset ingestion.
Note that some users rely on those occurrence URLs and gbifids (like https://bionomia.net for example). In an attempt to improve
the stability of the occurrence URLs and gbifids, we have implemented a warning system to detect these type of changes in datasets (see this news item).
If the data publisher can provide us with a list of old and new occurrenceIDs per record, we can avoid the identifier and URL changes. Could that be an option?
Please let us know if you have any question. Thanks!
All the best,

You can skip/fix identifier validation using the registry UI.

Identifier validation still  failing for the dataset Phytoplankton North Adriatic-Gulf of Trieste C1 – LTER time-series from 2010 onwards:

Crawler attempt: 112
Publishing organization: National Institute of Oceanography and Applied Geophysics
Publishing country: ITALY
Installation: National Oceanographic Data Centre for Italy
Number of occurrences indexed for this dataset at the time of the issue: 43392
Cause: GBIF ID problems exceed 50% threshold: 100% duplicates; 240768 total records; 240768 absent records
Pipelines execution steps: http://api.gbif.org/v1/pipelines/history/execution/4000892/step

New IDs sample:

Old IDs sample:

2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Acanthoica quattrospina_urn:lsid:marinespecies.org:taxname:235802_present
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Acanthoica spp._urn:lsid:marinespecies.org:taxname:115083_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Acanthosolenia_urn:lsid:marinespecies.org:taxname:602985_mediterranea_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Achnanthes brevipes_urn:lsid:marinespecies.org:taxname:149387_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Achnanthes spp._urn:lsid:marinespecies.org:taxname:149191_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Actiniscus pentasterias_urn:lsid:marinespecies.org:taxname:109717_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Akashiwo sanguinea_urn:lsid:marinespecies.org:taxname:232546_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Alexandrium pseudogonyaulax_urn:lsid:marinespecies.org:taxname:109713_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Alexandrium spp._urn:lsid:marinespecies.org:taxname:109470_present
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Alexandrium_urn:lsid:marinespecies.org:taxname:109470_minutum_absent

Publisher email
Hello,
I am contacting you from the GBIF Secretariat about a dataset published by the Phytoplankton North Adriatic-Gulf of Trieste C1 – LTER time-series from 2010 onwards : https://doi.org/10.13120/rf7p-7w07.
We noticed that the occurrenceIDs were changed. We have temporarily paused the ingestions of this dataset.
As you might already know, when an occurrence record has a new occurrenceID for a given dataset, our system considers it to be a new occurrence.
This means that it will be given a new gbifid and a new occurrence URL (like this one: https://www.gbif.org/occurrence/1252968762) and the old gbifid and URL will be deprecated.
In this case, this means that the occurrence URLs would be deprecated when ingesting the newest versions of these datasets.
We would like to check with you if those changes were intentional. Do you know if this is the case?
Please let us know, thanks! We are happy to resume the dataset ingestion.
Note that some users rely on those occurrence URLs and gbifids (like https://bionomia.net for example). In an attempt to improve
the stability of the occurrence URLs and gbifids, we have implemented a warning system to detect these type of changes in datasets (see this news item).
If the data publisher can provide us with a list of old and new occurrenceIDs per record, we can avoid the identifier and URL changes. Could that be an option?
Please let us know if you have any question. Thanks!
All the best,

You can skip/fix identifier validation using the registry UI.

Identifier validation still  failing for the dataset Phytoplankton North Adriatic-Gulf of Trieste C1 – LTER time-series from 2010 onwards:

Crawler attempt: 113
Publishing organization: National Institute of Oceanography and Applied Geophysics
Publishing country: ITALY
Installation: National Oceanographic Data Centre for Italy
Number of occurrences indexed for this dataset at the time of the issue: 43392
Cause: GBIF ID problems exceed 50% threshold: 100% duplicates; 240768 total records; 240768 absent records
Pipelines execution steps: http://api.gbif.org/v1/pipelines/history/execution/4001538/step

New IDs sample:

Old IDs sample:

2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Acanthoica quattrospina_urn:lsid:marinespecies.org:taxname:235802_present
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Acanthoica spp._urn:lsid:marinespecies.org:taxname:115083_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Acanthosolenia_urn:lsid:marinespecies.org:taxname:602985_mediterranea_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Achnanthes brevipes_urn:lsid:marinespecies.org:taxname:149387_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Achnanthes spp._urn:lsid:marinespecies.org:taxname:149191_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Actiniscus pentasterias_urn:lsid:marinespecies.org:taxname:109717_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Akashiwo sanguinea_urn:lsid:marinespecies.org:taxname:232546_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Alexandrium pseudogonyaulax_urn:lsid:marinespecies.org:taxname:109713_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Alexandrium spp._urn:lsid:marinespecies.org:taxname:109470_present
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Alexandrium_urn:lsid:marinespecies.org:taxname:109470_minutum_absent

Publisher email
Hello,
I am contacting you from the GBIF Secretariat about a dataset published by the Phytoplankton North Adriatic-Gulf of Trieste C1 – LTER time-series from 2010 onwards : https://doi.org/10.13120/rf7p-7w07.
We noticed that the occurrenceIDs were changed. We have temporarily paused the ingestions of this dataset.
As you might already know, when an occurrence record has a new occurrenceID for a given dataset, our system considers it to be a new occurrence.
This means that it will be given a new gbifid and a new occurrence URL (like this one: https://www.gbif.org/occurrence/1252968762) and the old gbifid and URL will be deprecated.
In this case, this means that the occurrence URLs would be deprecated when ingesting the newest versions of these datasets.
We would like to check with you if those changes were intentional. Do you know if this is the case?
Please let us know, thanks! We are happy to resume the dataset ingestion.
Note that some users rely on those occurrence URLs and gbifids (like https://bionomia.net for example). In an attempt to improve
the stability of the occurrence URLs and gbifids, we have implemented a warning system to detect these type of changes in datasets (see this news item).
If the data publisher can provide us with a list of old and new occurrenceIDs per record, we can avoid the identifier and URL changes. Could that be an option?
Please let us know if you have any question. Thanks!
All the best,

You can skip/fix identifier validation using the registry UI.

Identifier validation still  failing for the dataset Phytoplankton North Adriatic-Gulf of Trieste C1 – LTER time-series from 2010 onwards:

Crawler attempt: 114
Publishing organization: National Institute of Oceanography and Applied Geophysics
Publishing country: ITALY
Installation: National Oceanographic Data Centre for Italy
Number of occurrences indexed for this dataset at the time of the issue: 43392
Cause: GBIF ID problems exceed 50% threshold: 100% duplicates; 240768 total records; 240768 absent records
Pipelines execution steps: http://api.gbif.org/v1/pipelines/history/execution/4001562/step

New IDs sample:

Old IDs sample:

2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Acanthoica quattrospina_urn:lsid:marinespecies.org:taxname:235802_present
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Acanthoica spp._urn:lsid:marinespecies.org:taxname:115083_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Acanthosolenia_urn:lsid:marinespecies.org:taxname:602985_mediterranea_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Achnanthes brevipes_urn:lsid:marinespecies.org:taxname:149387_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Achnanthes spp._urn:lsid:marinespecies.org:taxname:149191_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Actiniscus pentasterias_urn:lsid:marinespecies.org:taxname:109717_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Akashiwo sanguinea_urn:lsid:marinespecies.org:taxname:232546_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Alexandrium pseudogonyaulax_urn:lsid:marinespecies.org:taxname:109713_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Alexandrium spp._urn:lsid:marinespecies.org:taxname:109470_present
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Alexandrium_urn:lsid:marinespecies.org:taxname:109470_minutum_absent

Publisher email
Hello,
I am contacting you from the GBIF Secretariat about a dataset published by the Phytoplankton North Adriatic-Gulf of Trieste C1 – LTER time-series from 2010 onwards : https://doi.org/10.13120/rf7p-7w07.
We noticed that the occurrenceIDs were changed. We have temporarily paused the ingestions of this dataset.
As you might already know, when an occurrence record has a new occurrenceID for a given dataset, our system considers it to be a new occurrence.
This means that it will be given a new gbifid and a new occurrence URL (like this one: https://www.gbif.org/occurrence/1252968762) and the old gbifid and URL will be deprecated.
In this case, this means that the occurrence URLs would be deprecated when ingesting the newest versions of these datasets.
We would like to check with you if those changes were intentional. Do you know if this is the case?
Please let us know, thanks! We are happy to resume the dataset ingestion.
Note that some users rely on those occurrence URLs and gbifids (like https://bionomia.net for example). In an attempt to improve
the stability of the occurrence URLs and gbifids, we have implemented a warning system to detect these type of changes in datasets (see this news item).
If the data publisher can provide us with a list of old and new occurrenceIDs per record, we can avoid the identifier and URL changes. Could that be an option?
Please let us know if you have any question. Thanks!
All the best,

You can skip/fix identifier validation using the registry UI.

Identifier validation still  failing for the dataset Phytoplankton time-series in the North Adriatic, C1-LTER time-series 2010-2020:

Crawler attempt: 115
Publishing organization: National Institute of Oceanography and Applied Geophysics
Publishing country: ITALY
Installation: National Oceanographic Data Centre for Italy
Number of occurrences indexed for this dataset at the time of the issue: 43392
Cause: GBIF ID problems exceed 50% threshold: 100% duplicates; 240768 total records; 240768 absent records
Pipelines execution steps: http://api.gbif.org/v1/pipelines/history/execution/4001634/step

New IDs sample:

Old IDs sample:

2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Acanthoica quattrospina_urn:lsid:marinespecies.org:taxname:235802_present
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Acanthoica spp._urn:lsid:marinespecies.org:taxname:115083_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Acanthosolenia_urn:lsid:marinespecies.org:taxname:602985_mediterranea_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Achnanthes brevipes_urn:lsid:marinespecies.org:taxname:149387_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Achnanthes spp._urn:lsid:marinespecies.org:taxname:149191_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Actiniscus pentasterias_urn:lsid:marinespecies.org:taxname:109717_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Akashiwo sanguinea_urn:lsid:marinespecies.org:taxname:232546_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Alexandrium pseudogonyaulax_urn:lsid:marinespecies.org:taxname:109713_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Alexandrium spp._urn:lsid:marinespecies.org:taxname:109470_present
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Alexandrium_urn:lsid:marinespecies.org:taxname:109470_minutum_absent

Publisher email
Hello,
I am contacting you from the GBIF Secretariat about a dataset published by the Phytoplankton time-series in the North Adriatic, C1-LTER time-series 2010-2020 : https://doi.org/10.13120/rf7p-7w07.
We noticed that the occurrenceIDs were changed. We have temporarily paused the ingestions of this dataset.
As you might already know, when an occurrence record has a new occurrenceID for a given dataset, our system considers it to be a new occurrence.
This means that it will be given a new gbifid and a new occurrence URL (like this one: https://www.gbif.org/occurrence/1252968762) and the old gbifid and URL will be deprecated.
In this case, this means that the occurrence URLs would be deprecated when ingesting the newest versions of these datasets.
We would like to check with you if those changes were intentional. Do you know if this is the case?
Please let us know, thanks! We are happy to resume the dataset ingestion.
Note that some users rely on those occurrence URLs and gbifids (like https://bionomia.net for example). In an attempt to improve
the stability of the occurrence URLs and gbifids, we have implemented a warning system to detect these type of changes in datasets (see this news item).
If the data publisher can provide us with a list of old and new occurrenceIDs per record, we can avoid the identifier and URL changes. Could that be an option?
Please let us know if you have any question. Thanks!
All the best,

You can skip/fix identifier validation using the registry UI.

Identifier validation still  failing for the dataset Phytoplankton time-series in the North Adriatic, C1-LTER time-series 2010-2020:

Crawler attempt: 116
Publishing organization: National Institute of Oceanography and Applied Geophysics
Publishing country: ITALY
Installation: National Oceanographic Data Centre for Italy
Number of occurrences indexed for this dataset at the time of the issue: 43392
Cause: GBIF ID problems exceed 50% threshold: 100% duplicates; 240768 total records; 240768 absent records
Pipelines execution steps: http://api.gbif.org/v1/pipelines/history/execution/4001675/step

New IDs sample:

Old IDs sample:

2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Acanthoica quattrospina_urn:lsid:marinespecies.org:taxname:235802_present
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Acanthoica spp._urn:lsid:marinespecies.org:taxname:115083_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Acanthosolenia_urn:lsid:marinespecies.org:taxname:602985_mediterranea_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Achnanthes brevipes_urn:lsid:marinespecies.org:taxname:149387_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Achnanthes spp._urn:lsid:marinespecies.org:taxname:149191_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Actiniscus pentasterias_urn:lsid:marinespecies.org:taxname:109717_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Akashiwo sanguinea_urn:lsid:marinespecies.org:taxname:232546_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Alexandrium pseudogonyaulax_urn:lsid:marinespecies.org:taxname:109713_absent
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Alexandrium spp._urn:lsid:marinespecies.org:taxname:109470_present
2011-01-25__C1_45.6976666_13.7083333_0.5_0.5_OGS_phytoplankton_north_adriatic_C1-LTER_time-series_2010_onwards_Alexandrium_urn:lsid:marinespecies.org:taxname:109470_minutum_absent

Publisher email
Hello,
I am contacting you from the GBIF Secretariat about a dataset published by the Phytoplankton time-series in the North Adriatic, C1-LTER time-series 2010-2020 : https://doi.org/10.13120/rf7p-7w07.
We noticed that the occurrenceIDs were changed. We have temporarily paused the ingestions of this dataset.
As you might already know, when an occurrence record has a new occurrenceID for a given dataset, our system considers it to be a new occurrence.
This means that it will be given a new gbifid and a new occurrence URL (like this one: https://www.gbif.org/occurrence/1252968762) and the old gbifid and URL will be deprecated.
In this case, this means that the occurrence URLs would be deprecated when ingesting the newest versions of these datasets.
We would like to check with you if those changes were intentional. Do you know if this is the case?
Please let us know, thanks! We are happy to resume the dataset ingestion.
Note that some users rely on those occurrence URLs and gbifids (like https://bionomia.net for example). In an attempt to improve
the stability of the occurrence URLs and gbifids, we have implemented a warning system to detect these type of changes in datasets (see this news item).
If the data publisher can provide us with a list of old and new occurrenceIDs per record, we can avoid the identifier and URL changes. Could that be an option?
Please let us know if you have any question. Thanks!
All the best,

You can skip/fix identifier validation using the registry UI.


feat: structured logging (JSON)

⚠⚠⚠ Since we do not accept all types of pull requests and do not want to waste your time. Please be sure that you have read pull request rules:
https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#can-i-create-a-pull-request-for-uptime-kuma
Tick the checkbox if you understand [x]:

[x] I have read and understand the pull request rules.

Description
Implements structured logging, as requested by #5107.
Resolves #5107
This feature can be enabled by using the environment variable UPTIME_KUMA_LOG_FORMAT set to json.
This PR also incorporates the work of #4391 and #4392 (with minor fixes to both as per the linter), for the feature itself I would direct your attention to commit 3e922be39cba2eba05ca814183c60def93e6ae2f.
Closes #4391
Closes #4392
Type of change
Please delete any options that are not relevant.

User interface (UI)
New feature (non-breaking change which adds functionality)
This change requires a documentation update

Before

After

Checklist

[x] My code follows the style guidelines of this project
[x] I ran ESLint and other linters for modified files
[x] I have performed a self-review of my own code and tested it
[x] I have commented my code, particularly in hard-to-understand areas (including JSDoc for methods)
[x] My changes generates no new warnings
[ ] My code needed automated testing. I have added them (this is optional task)

I think it also breaks the hide logging feature.

I think it also breaks the hide logging feature.

I'm not sure how that's possible, those lines weren't modified at all...

+1 this does not break the hide log feature.
https://github.com/louislam/uptime-kuma/issues/5157 is a pretty unfortunate thing, but I don't think the whole console logging filtering code should be executed in the browser.
We should remove that part (in a different PR).
I think pushing this is not nessesary, but don't want to fight about this
=> lets push this for one release.


Resuming from checkpoint

My first run of the trainer could not save the model because the evaluate() call fails. I have removed that method call and now would like to resume from the last checkpoint. However,  I cannot seem to get that working. Is there some disparity between model architecture and checkpoint architecture? The change I made to accommodate checkpoint resumption and the error I get are shown below show below.
Change for checkpoint resumption
data_module = make_supervised_data_module(tokenizer=tokenizer, data_args=data_args)     trainer = Trainer(model=model, tokenizer=tokenizer, args=training_args, **data_module)     transformers.logging.set_verbosity_info()     trainer.train()     #trainer.train("output/checkpoint-18000")     #trainer.evaluate()     trainer.save_state()     safe_save_model_for_hf_trainer(trainer=trainer, output_dir=training_args.output_dir)
Error stacktrace
`Loading model from output/checkpoint-18000/.
Traceback (most recent call last):
File "/home/ubuntu/alpaca/stanford_alpaca/train.py", line 246, in
train()
File "/home/ubuntu/alpaca/stanford_alpaca/train.py", line 239, in train
trainer.train("output/checkpoint-18000/")
File "/home/ubuntu/.local/lib/python3.10/site-packages/transformers/trainer.py", line 1617, in train
self._load_from_checkpoint(resume_from_checkpoint)
File "/home/ubuntu/.local/lib/python3.10/site-packages/transformers/trainer.py", line 2120, in _load_from_checkpoint
load_result = load_sharded_checkpoint(model, resume_from_checkpoint, strict=is_sagemaker_mp_enabled())
File "/home/ubuntu/.local/lib/python3.10/site-packages/transformers/modeling_utils.py", line 385, in load_sharded_checkpoint
state_dict = torch.load(os.path.join(folder, shard_file), map_location="cpu")
File "/home/ubuntu/.local/lib/python3.10/site-packages/torch/serialization.py", line 809, in load
return _load(opened_zipfile, map_location, pickle_module, **pickle_load_args)
File "/home/ubuntu/.local/lib/python3.10/site-packages/torch/serialization.py", line 1172, in _load
result = unpickler.load()
File "/home/ubuntu/.local/lib/python3.10/site-packages/torch/_utils.py", line 169, in _rebuild_tensor_v2
tensor = _rebuild_tensor(storage, storage_offset, size, stride)
File "/home/ubuntu/.local/lib/python3.10/site-packages/torch/_utils.py", line 148, in rebuild_tensor
return t.set(storage._untyped_storage, storage_offset, size, stride)
RuntimeError: Trying to resize storage that is not resizable
WARNING:torch.distributed.elastic.multiprocessing.api:Sending process 122406 closing signal SIGTERM
WARNING:torch.distributed.elastic.multiprocessing.api:Sending process 122407 closing signal SIGTERM
WARNING:torch.distributed.elastic.multiprocessing.api:Sending process 122409 closing signal SIGTERM
ERROR:torch.distributed.elastic.multiprocessing.api:failed (exitcode: 1) local_rank: 2 (pid: 122408) of binary: /usr/local/bin/python3.10
Traceback (most recent call last):
File "/home/ubuntu/.local/bin/torchrun", line 8, in
sys.exit(main())
File "/home/ubuntu/.local/lib/python3.10/site-packages/torch/distributed/elastic/multiprocessing/errors/init.py", line 346, in wrapper
return f(*args, **kwargs)
File "/home/ubuntu/.local/lib/python3.10/site-packages/torch/distributed/run.py", line 794, in main
run(args)
File "/home/ubuntu/.local/lib/python3.10/site-packages/torch/distributed/run.py", line 785, in run
elastic_launch(
File "/home/ubuntu/.local/lib/python3.10/site-packages/torch/distributed/launcher/api.py", line 134, in call
return launch_agent(self._config, self._entrypoint, list(args))
File "/home/ubuntu/.local/lib/python3.10/site-packages/torch/distributed/launcher/api.py", line 250, in launch_agent
raise ChildFailedError(
torch.distributed.elastic.multiprocessing.errors.ChildFailedError:
train.py FAILED
`

have you solved it ? I cann't Resume too, with the same problem RuntimeError: Trying to resize storage that is not resizable


no viable alternative at input '\n' - Window Line endings

Just added this to my Eclipse (4.5.1) and when i open a config file more or less every line have this error no viable alternative at input '\n', however if i change line endings from windows (CR + LF) to linux (LF) they disappear (instead i get no viable alternative at input '<EOF>' on the last line)
In the below example snippet the only line without the error would be loglevel = "DEBUG", even the blank line has this error
akka {
  loglevel = "DEBUG"
  actor {
    # comment line

    # comment after blank line

Same as #7?

The <EOF> issue is the same as #7 but there is also an issue with Windows line endings what ever is parsing the file doesn't handle them thus the no viable alternative at input '\n'

Yes, the problem is most likely at this line. I am extremely busy for the next couple of weeks, but if you could help (seems like a simple one), I'd be more than happy to cut a new release.

Closed via #9


still nan problem

I trianed with my own datasets, about 1000 images to 2 classes(text and background).
I've tried the default configs.
I've tried lr=1e-4, WARMUP_FACTOR=0.03333, and WARMUP_ITERS=1000.
And nan still remains.
Do you have any suggestion to solve this problem?
I'm wondering what principles I should follow to adjust those super parameters.

I find that in ssd/modeling/box_head/loss.py, some values in tensor gt_locations are nan.
But my xml files are generateted by same script, and I checked boxes in dataset file like voc.py, there's nothing wrong.
So my next move is to figure out how boxes become gt_locations.

The main reason is that torch.log() should not accept parameter less than 0.
I found something wrong about my data(xmin > xmax), solved it.


nz-select tags - Two options are selected

Version
7.0.0-rc.3
Environment
ng-zorro Official website   https://ng.ant.design/components/select/en
Reproduction link
https://stackblitz.com/edit/angular-l7kt2u?file=src/app/app.component.ts
Steps to reproduce
https://ng.ant.design/components/select/zh
Data Entry  ->  Select  ->  tags select
Enter the letter a，There should be only one Option selected，
The two options  ( a  a10)   are all selected
0.7x   1.8x   7.0.0-rc.3
They all have such problems.
Is this a bug? I am not very sure,
This is the official website demo
But this seems strange.
What is expected?
There should be only one Option selected
What is actually happening?
The  two  Option are all selected.
Other?
Please forgive me for my bad English (from Google Translate)

this bug has been fixed by #2741
plz try again when next version released


Using Bark with multi-organisation database schemas

Hey there, I faced an issue when implementing the Bark extension with our app.
I see that path is required to be a unique field across the database for Bark to work as expected, but the thing is, we have multiple organisations under the same database (not so multi-tenant, but just B2B). So because of this, I had to remove the unique constraint on path and set a @@unique([path, locationId]) constraint instead, but this seems to break the implementation of createChild as it tries to insert a row using findUnique:
Argument `where` of type WorkOrderWhereUniqueInput needs at least one of `id`, `id_locationId` or `path_deleted_locationId` arguments. Available options are marked with ?.
PrismaClientValidationError:

Is there a work around to this?

It's specifically because of this line: https://github.com/adamjkb/bark/blob/eb664d11c833719a5f63ea7a9c73fb236d15f57d/packages/prisma-extension-bark/src/create/create-child.js#L68C4-L77C6
Where there is a query on just path. Instead, if it would be possible to reuse the same query that was provided in where or node, that just might work... I'm not too sure if it has other consequences though.

From a technical perspective path is required to be unique because we can't have two nodes pointing to same location in the tree. If my assumptions are correct what you're trying to do here is to create multiple roots, each representing an organization. Essentially you would no longer need locationId, at least not on the tree model; you might need to make make note of the root path on related models.
Hopefully that makes sense!

Ah, I see. That makes sense. I still would have location ID as we use it for other relations, but basically the path field would be the only universal field across the database. And since everyone would be creating multiple "root" nodes or children of them, it should be fine.
Thank you for explaining the construct :) Much appreciated!


Timing Settings

This is a split of a entered issue #60, see that thread for more information.
Congratulations - a great project with lots of features.
1 Please consider having different timing settings for HTTP 1 say for Brewfather 900s and HTTP2 MQTT 180s this would allow good flexibility in use.

Added feataure to v1.0


refactor: sort bot comments

    Hey @Steveantor I noticed some unusual behavior. I think they are out of order. Its a small detail but would you mind reordering it? https://github.com/ubiquity/ubiquity-dollar/pull/454#issuecomment-1371692834

Originally posted by @pavlovcik in https://github.com/ubiquity/ubiquity-dollar/issues/446#issuecomment-1375207589
Resolves #

Thank you ser much appreciated 🙏 let's see how this goes.


Immediate access to browsing by categories, not only search

Kora suggested this is important, see paper (Table 1). Browse as imporant as search. Maybe:

#11
split the right panel into a) browsing categories and b) work listing?
replace work listing with browsing categories
we select manually a set of significant äo and genreform terms
we pick the 10 most frequent terms
an example: Ebay

Done in:

*   52eaa1b - (HEAD -> dev, origin/dev) Merge branch 'collections' into dev (2 minutes ago)
|\
| * 348164b - (origin/collections, collections) Click to expand tree progressively (4 minutes ago)
| * cd99a86 - Show term trees in collection (16 minutes ago)
| * 9d811b7 - Collections before comboboxes (5 hours ago)
| * 922ec47 - TermFilters component (5 hours ago)
| * d53ae72 - Fix height for collection open state (Mon Jun 5 17:00)
| * e1d05e6 - Restyle collection open state (Mon Jun 5 16:56)
| * 9b3034e - Load terms in collection (Mon Jun 5 16:39)
| * 9d708a0 - Use collections API (Mon Jun 5 11:13)
| * 9e3cb63 - Mockup collections in search form (Mon Jun 5 11:01)
|/

Some follow-up issues:

Enable a larger listing of category content (term tree)
Drag-and-drop terms into search fields
Hide and show parts of the search form to housekeep space


added badges

I have added the badges If I did it wrong can u let me know wht changes are to be done

@castarco I did made the changes can u let me know wht else shld be done

@castarco may ik if there are any changes that are needed to be done

@castarco can u chck the pr i have made

Hi @Tejoooo , please excuse me for my delay, I'm having some complications in my personal life lately.
Regarding the changes, they are still not complete. I can find many references to the nominal package across all the modified files, which is precisely the problem I pointed out.

UPDATE: I see that you opened a new PR instead of changing this one. Some comments about that:

If you don't want this want to continue, ideally you should have closed this one.
The other PR does not have a good title, as it does not refer to the changes you are bringing to the project, but to the corrections I indicated for this specific PR I am commenting on.

More on that, if you want to keep the number of commits in your PR from growing too much, you can always rely on git rebase -i (so you can squash commits, or rename their titles).

I'll close this PR as I understand that you opened a new one with the same work plus some corrections.


Hyperledger fabric lab BDLS consensus protocol proposal

Signed-off-by: Ahmed Al Salih<EMAIL_ADDRESS>Checklist for Hyperledger Lab Proposal PR

[x] Read README.md carefully
[x] Make sure your changes are committed with the proper sign-off
[x] Use the labs name as the PR title
[x] Copy the short description of the proposal as the description of the PR
[ ] Remove this checklist section
[x] Submit your PR and the labs stewards will review your proposal
[x] Ask your sponsor to confirm sponsorship by stating so in a comment to the PR

please let me know if there is any required change that I am not aware off.
Thanks,

Please see comments above.

@tkuhrt  I'm not sure if something still missing or not. And yes, if we need to Manually transfer the code from the existing repo to the newly created repo within the hyperledger-labs GitHub organization. Let me know what I can do to make that project success.

Hi, @ahmed82 . It looks like commits that happened prior to and including commit 0c114c3b90e06c1011f715d19e4d295c5fe855bb do not have sign offs. We will need to get the following folks to sign off their commits:

bestmosquito@gmail.com,Jingwen
imap@live.com|daniel820313@gmail.com,xtaci
yongge.wang@gmail.com,Yongge Wang

Also, they should make sure that they agree to the changes in the license that happened after their commits. Otherwise, we will not be able to transfer the repository as is.

Hi @tkuhrt,
Regarding the license update, Dr. Yongge Wang who own the research, he updated the licenses not me, please check his repo
https://github.com/yonggewang/bdls
The others developers, I tried to contact but not getting any response at all, almost a year.
Is there another solution, like if I create a new initialize repository, since the project is my research area and the protocol is belonged to my advisor.
If that approach would work, I will update the repository information with the new repo that does not have any history or contributes but me>
https://github.com/BDLS-bft/bdls

Hi @tkuhrt, Regarding the license update, Dr. Yongge Wang who own the research, he updated the licenses not me, please check his repo https://github.com/yonggewang/bdls
The people who contributed prior to the license being updated need to agree that they want their code contributed under the new license (i.e., Apache 2.0)

The others developers, I tried to contact but not getting any response at all, almost a year. Is there another solution, like if I create a new initialize repository, since the project is my research area and the protocol is belonged to my advisor. If that approach would work, I will update the repository information with the new repo that does not have any history or contributes but me> https://github.com/BDLS-bft/bdls
The key here is that we need to make sure that the code contributors agree to the DCO in order to make sure that they are not bringing in code that is not Apache 2.0 licensed and not owned by anyone other than themselves. How can we be sure that the legalities are met?

@tkuhrt. My Advisor Dr. Yongge Wang helped me to get the sign-off form xtaci<EMAIL_ADDRESS>"The BDLS protocol was designed by Yongge Wang and the code was implemented by [imap@live.com|daniel820313@gmail.com,xtaci ]. [bestmosquito@gmail.com,Jingwen] was only involved at some point to update a configure file. She did not actually write any single code there.  Since Jingwen was not available (we have no contact information for her right now), we moved the previous repo to https://github.com/yonggewang/bdlsBACKUP and created a fresh repo https://github.com/yonggewang/bdls . Both repos were signed by Yongge Wang and xtaci. But you can use the https://github.com/yonggewang/bdls for merging purposes. "
Thanks,

Approved and merged

Thank you.


(1) A* Pathfinding Algorithm with GUI in Python (2) Adding programs in: (a) C => folders: ds, math, other; (b) JavaScript => various cp, ds, and maths programs

🚀 Feature
(A clear and concise description of what the feature is.)
(1) A Star Pathfinding Algorithm with GUI in Python:
Implemented with pygame, this script will find the shortest distance between two nodes using A* Algorithm.
Instructions/ Keys Functionalities :

Left Click to add start and end nodes
Right Click to remove the nodes
Space Bar to start finding the shortest distance
'C' to clear and reset the grid

(2) Under ds folder in C =>  Doubly Linked List
(3) Under math folder in C => palindrome, special no., magic number, binary to decimal (and vice-versa),  Smith no., perfect square no. and so on.
(4) Under JavaScript, I'll provide different cp, ds, and math programs
Have you read the Contributing Guidelines on Pull Requests?
(Write your answer here.)
Yes, I have read the Contributing Guidelines on Pull Requests.
Motivation
(Please outline the motivation for the proposal.)
People who are visiting this repository have a common purpose - to get most of the popular and well-used data structures and algorithms. The programs I am adding are very popular and are common interview and competitive questions. They will get a tonne of benefits from this.
Pitch
(Please explain why this feature should be implemented and how it would be used.)
These programs enhance the workflow and give a better sight of how we can use different data structures and algorithms and are very common in examinations too.

Please assign this issue to me. Waiting for your response.

Hi @proghead00
Thanks for making this Issue! As a Side-Note, we would not need a GUI for our Code. You can safely omit that part.
Also, try to make PRs as discrete as possible. Don't push a lot of Code into a single PR. Make PRs with only one language and corresponding README changes.

Okay @HarshCasper . So, I'll omit the GUI as you say.
Can I open multiple PRs then? Like, if I code some programs in C, then open PR, and then code in JS, and again open PR for the same?

And I'd like to get assigned for this :)

Okay @HarshCasper . So, I'll omit the GUI as you say.
Can I open multiple PRs then? Like, if I code some programs in C, then open PR, and then code in JS, and again open PR for the same?

Works! Please go ahead

So, I am creating separate branches for separate PRs.
I already made a branch named proghead00 2 days back and added files for C.
For the programs for other languages like JS, the branch name goes like this:  proghead00_JS, and so on.

@HarshCasper So, I am creating separate branches for separate PRs.
I already made a branch named proghead00 2 days back and added files for C.
For the programs for other languages like JS, the branch name goes like this: proghead00_JS, and so on.

Looks good!

@HarshCasper So, I am creating separate branches for separate PRs.
I already made a branch named proghead00 2 days back and added files for C.
For the programs for other languages like JS, the branch name goes like this: proghead00_JS, and so on.

Looks good!

@HarshCasper So, I am creating separate branches for separate PRs.
I already made a branch named proghead00 2 days back and added files for C.
For the programs for other languages like JS, the branch name goes like this: proghead00_JS, and so on.

Looks good!

Should I go and start opening PRs?
Because you closed the issue.

@HarshCasper So, I am creating separate branches for separate PRs.
I already made a branch named proghead00 2 days back and added files for C.
For the programs for other languages like JS, the branch name goes like this: proghead00_JS, and so on.

Looks good!

Should I go and start opening PRs?
Because you closed the issue.

yes go ahead @proghead00

yes go ahead @proghead00


added variable to have rprompt on the newline

To alleviate issue #145

:+1: Looks good to me. I tested various states with OMZ, prezto and antigen. Worked in all of them.
Thanks for the contribution. :)

Awesome!! Thanks for the great contribution, @Tritlo!!
Can you update the Wiki and add some docs detailing how to use the new feature? =)


Change timeout value used to detect if docker is available

Hi,
I would to decrease the timeout value used to detect if Docker is available. Is it possible to change this timeout by configuration ?
2021-09-01 17:17:35,642 [main] INFO org.testcontainers.dockerclient.DockerClientProviderStrategy - Loaded org.testcontainers.dockerclient.NpipeSocketClientProviderStrategy from ~/.testcontainers.properties, will try it first
2021-09-01 17:18:06,494 [main] INFO org.testcontainers.dockerclient.DockerMachineClientProviderStrategy - docker-machine executable was not found on PATH ([])

#4386 should do this 😄
Unless you're looking to limit the total time spent trying to find docker; #4386 will achieve this indirectly, pretty much, but we don't have plans to set a total time limit.

With the property "client.ping.timeout", that's exactly what I'm looking for. 👍


[R] Remove dependency on gendef for Visual Studio builds (fixes #5608)

This pull request proposes a fix #5608 .
Overview
Rtools 4.0 removed gendef.exe, a tool used to generate an R.def file from R.dll, which is then used to create an R.lib for linking with Visual Studio compilers. That removal can result in the following error for R 4.0 users trying to build the xgboost R package with Visual Studio:

CMake Error at cmake/modules/FindLibR.cmake:49 (message):

Either gendef.exe or dlltool.exe not found!

Do you have Rtools installed with its MinGW's bin/ in PATH?
Call Stack (most recent call first):
cmake/modules/FindLibR.cmake:154 (create_rlib_for_msvc)
R-package/CMakeLists.txt:1 (find_package)

This PR proposes an alternative method to creating R.def from R.dll, using objdump. objdump is a tool bundled in Rtools 4.0 and earlier versions of Rtools by default, so it preserves the user experience of "you can install the library if you have Visual Studio, CMake, and Rtools".
A similar approach is currently being reviewing in LightGBM https://github.com/microsoft/LightGBM/pull/3065, and has been working for us there on my local machine and in multiple Continuous Integration environments.
Notes for Reviewers

I'm also proposing adding documentation on how to build the R package with Visual Studio. Currently the R package installation docs do not include this documentation
The new script being introduced, R-package/inst/make-r-def.R introduces an optional dependency on {processx}. We've found in LightGBM that there is a lot of overhead in calling shell commands from R on Windows with system() and system2(), and {processx} can be much faster.

How I tested this
mkdir build
cd build
cmake .. -G"Visual Studio 16 2019" -A x64 -DR_LIB=ON
cmake --build . --target install --config Release

More References
For more details, see the discussion in LightGBM:

https://github.com/microsoft/LightGBM/pull/3065#issue-415667245
https://github.com/microsoft/LightGBM/issues/3064

Codecov Report

Merging #5764 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #5764   +/-   ##
=======================================
  Coverage   82.61%   82.61%
=======================================
  Files          12       12
  Lines        2726     2726
=======================================
  Hits         2252     2252
  Misses        474      474

Continue to review full report at Codecov.

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

Creating 'C:/projects/xgboost/build_rmsvc2015/R-package/R.def' from 'C:/R/bin/x64/R.dll'
Successfully created 'C:/projects/xgboost/build_rmsvc2015/R-package/R.def'

https://ci.appveyor.com/project/tqchen/xgboost/builds/33401601/job/yj6tgstdy3ea2hm1?fullLog=true#L1172
It looks pretty good on the CI. I'm going to try it myself on a Windows machine.

@jameslamb I tried it on my Windows machine and got it to work (with some difficulties). I had to modify CMakeLists.txt so that it would actually handle errors that might arise from running R CMD INSTALL <generated R package>. I pushed the changes to your branch.

I just verified that I can now install the R package with GPU enabled.


Use gravatar as a backup if no avatar was uploaded

In case the user hasn't uploaded an avatar use the one from http://www.gravatar.com

While I'd like to have avatars imported from facebook if facebook login is used to create account, or taken from gravatar if an email is given, and have these avatars stored in the system, for now I'm just re-adding the old gravatar line of code.


Changed check_proc_mem.sh added getopts

Added getopts instead of positional arguments.

@goodard , thanks for the effort!
This repo has grown to big. Thus I'm trying to break it into small repos.
Could you please check this repo, and send your PR there?
https://github.com/DennyZhang/monitoring
Don't worry that repo won't be changed like this any more. Sorry for any inconvenience!


DEP 6 - Notes

The Job result payload must have errorcode and description fields in case of error in executing the operation.

I don't think DEP 6 should require Agents to return an error code. I think we could require an error key which its value is an Object with at least the description key. Since error is an Object, Agents could potentially add custom keys.
Error shouldn't be part of the result
I find it semantically strange that error is in results. If there was an error, the Operation didn't produce a "result", so the error key should be at the root level and there shouldn't be a results key:
{"status": "failed",
  "error": {
    "description": "Friendly error description"
  }
}

Rename results to outputs
We even use the word 'outputs' to describe results, so why not simply use outputs then?

...  implementations are free to define schemas for inputs (params) and outputs (results).

Rename params to inputs
Same for params. Why don't we use inputs instead?
Rename jobid to job-id
We use operation-id, so it makes sense to use job-id instead of jobid.

I think I agree with these changes, but would like to confirm that with everyone who is doing DEP-based interop that this makes sense before we make any breaking changes.
@billbsing @shark8me @superstructor @AyushVerma2 Please comment from the perspective of your respective implementations.

https://github.com/DEX-Company/starfish-java/pull/169


Changed to the getHeight function for fonts so it will return a more accurate height

The getHeight in the fonts gave back approximated heights and in some cases only height the first time the function was called. Tried to clean up the functions and return a more accurate height for each glyph.

This repo is an SVN mirror and the PDFBox project team do not have access to PRs created here. Please close this issue and follow the instructions on http://pdfbox.apache.org/support.html to create issues on JIRA.


Timestamps for URL downloads match the download time

By enabling CMake policy 135 we ensure that extracted files timestamp match that of the download time, instead of when the
archive is created. This makes sure that if the URL changes to an older version we still rebuild everything as the timestamp
stays newer.
https://cmake.org/cmake/help/latest/policy/CMP0135.html

@gpucibot merge


"No address book policies" paragraph clarification

I am referring to article https://docs.microsoft.com/cs-cz/microsoft-365/compliance/information-barriers-policies#prerequisites.
Please clarify with Engineering if ABPs can be recreated after Information Barriers have been implemented or not.
The message we are sending is not very clear because we are not saying that ABPs are not supported in conjunction with IBPs. We just say that they should be removed if they exist prior of implementing IBPs.
Going through some internal Engineering requests, I've seen that there is a long term plan to replace ABPs with IBPs in Exchange, and that there is also a conflict between the two, which explains the existence of the paragraph in question, in the article.

Hi @Alex-Catalin
No, you cannot have Exchange address book polices and Information Barrier policies implemented simultaneously.  Exchange ABP + Information Barrier polices = are not supported.


Figure 1.7 mismatch between images, captions, and section text

Edition: Dec 31, 2020
Print pages: 9-10
PDF pages: 39-40
§<IP_ADDRESS> says:

In Fig. 1.7(b), we see that using D = 2 results in a much better fit.

However, the Fig. 1.7(b) image is a polynomial of degree 14, or at least that's what the title above it says. Assuming the figure images are arranged as intended, I think the section text meant to refer to 1.7(a), which is of degree 2, and is not currently referenced by the text.
Also, the caption under Fig. 1.7 reads, in part:

(a-b) Polynomial of degrees 1 and 14"

The polynomial in 1.7(a) is of degree 2 (and is labeled as such above the graph). I assume the caption should instead read:

(a-b) Polynomial of degrees ~1~ 2 and 14

fixed

fixed


Documentation of container classifications seems confusing.

This is about the documentation page with the chapter "container classifications", and the table therein.
I find the following things confusing:

The text talks about serializing containers into sol3. Surely this isn't meant to imply that the container contents are being copied into a Lua table? One would expect the table to be used in-place, right? Perhaps it should be made clear what serializing a container into sol3 actually means, or the place where it is decribed in detail should be referred to.

Fixed containers have a note/caveat saying that "C++ implementation inserts using operator[]", but I thought that a fixed container can't be inserted into. Am I missing something?

I have a fixed associative container that has a find function, and the find function is actually used by sol3 (to check, I have removed the implementation and the linker complains). However, it doesn't appear to be called. If I type container["key"] in Lua, I would have expected my find() function to be used, but instead an iteration using begin() and end() is happening. So my question is, of the functions that are listed in the table as being relevant for container classification, in which situations are they actually being called? In my case, find() must be used for something, otherwise it wouldn't get linked, but what is it?

serialization occurs by moving or copying the container into sol3, albeit it should be clear whether we are just moving it into a userdata or placing it into a table. serialization generally refers to making things into something they are not, so that is probably a worse description: "move into table" seems like a better way to go.
"inserts" is probably the wrong word: we write into slots using operator[]. That's about it.
I'd have to peer into the implementation again. find() is used for... well, the find() call, but some associative containers have subtly different semantics for operator[] calls.

I'll try to get a better answer for 3. For 1 and 2: pull requests welcome.

Well, the most important bit of information for me would be whether the container, i.e. its elements, are copied or not. In other words, is serialization going to create a deep copy of the container? Or is it merely creating a reference for the existing container? This matters from a  memory consumption viewpoint, and from a usage viewpoint, i.e. whether modifying the container after serialization affects the original container or not. I know the term "serialization" from marshalling data for persistence or communication, which always involves making a copy, hence my confusion. I'd provide a verbiage if it was completely clear to me, but it isn't yet.

Ah, so a "fixed" container is only fixed in terms of which elements it holds, the elements themselves can be overwritten? IOW you can overwrite an existing element, but not add new ones or delete existing ones? In this case the note in the table should probably read: "C++ implementation uses operator[] to read/write existing elements." This leaves the question: What about constant containers, which can only be read? Are they supported? How are they detected?

Well, for starters, operator[] usually adds a new element to an associative container if it doesn't find the key. The behavior of find() is to not change the container. If the container doesn't have an operator[], you would use find(), possibly along with insert(), to emulate it, right?

Do you have an example container for the associative container you speak of? I'd like to try and step through some of the logistics for when it is called in that case.

I don't know of any container that is "constant", other than std::array. If you create a std::array<const T, N> or something, I'm sure the implementation will explode, and I do not have the time to try or even attempt to fix anything related to someone trying to const-qualify container elements. At that point, you're in "sufficiently special" territory and the default implementation likely won't be enough: use the customization points.

Fixed the docs to look better, the find stuff is probably better off not being tracked in a docs issue. Post the example code here and then I'll open a new issue (or if you've got the energy, you open the new issue).

Well, any container is constant if you only have a const& to it. Take vector as an example, where all nonmodifying function members exist in a const variant. So I would have expected constant containers to be much less of a special case. They're just ordinary containers where modifying operations like insert or erase are unavailable. When binding them using Sol, I would expect all operations to work that don't modify the container, and those that do would produce an error.
BTW, a container with constant elements isn't the same as a constant container, strictly speaking. The former could theoretically allow addition of new elements, only existing ones can't be changed. The latter would forbid insertion and deletion of elements, and so is even more restricted. IOW it is "fixed", AND has constant elements. That's what I am interested in.
My container is a bit too complicated to serve as a simple example, but I'll come up with something simpler to illustrate the point. Give me a bit of time, I'll open a separate ticket for that.


Production run won't read .out.chk with '-' within the file name.

Bug summary
While running an equilibration and subsequent production run for a negative chemical potential, I used a naming scheme for the output files equil_{chem_pot:.0f}_{temp:.0f} or prod_{chem_pot:.0f}_{temp:.0f}. The production run errored out after the creation of the .log and .inp file.
In the .out.log file for the production run:
************ERROR************
An error in the input line 97 of input file.
This error occurred in subroutine Get_Start_Type on step 0.
Fatal Error. Stopping program.

In the .inp file for the production run:
!------------------------------------------------------------------------------# Start_Type
checkpoint surfequil_-100_406.out.chk
!------------------------------------------------------------------------------

Code to reproduce the behavior
import mbuild
import foyer
import mosdef_cassandra as mc
import unyt as u

def run_npt(custom_args={}):

    # Use mbuild to create molecules
    ethane = mbuild.load("CC", smiles=True)

    # Create an empty mbuild.Box
    box = mbuild.Box(lengths=[3.0, 3.0, 3.0])

    # Load forcefields
    oplsaa = foyer.forcefields.load_OPLSAA()

    # Use foyer to apply forcefields
    ethane_ff = oplsaa.apply(ethane)

    # Create box and species list
    box_list = [box]
    species_list = [ethane_ff]

    # Use Cassandra to insert some initial number of species
    mols_to_add = [[5]]

    # Define the system object
    system = mc.System(box_list, species_list, mols_to_add=mols_to_add)
    # Get the move probabilities
    moveset = mc.MoveSet("npt", species_list)

    default_args = {
        "pressure": 1.0 * u.bar,
    }

    # Combine default/custom args and override default
    custom_args = {**default_args, **custom_args}
    custom_args["run_name"] = "equil_-1_300"
    # Run a simulation with at 300 K with 10000 MC moveset
    # Note we must define a pressure for an NPT simulation
    mc.run(
        system=system,
        moveset=moveset,
        run_type="equilibration",
        run_length=10000,
        temperature=300.0 * u.K,
        **custom_args,
    )
    custom_args["run_name"] = "prod_-1_300"
    custom_args["restart_name"] = "equil_-1_300"
    mc.restart(
        system=system,
        moveset=moveset,
        run_type="production",
        run_length= 10000,
        temperature=300.0 * u.K,
        **custom_args,
    )

if __name__ == "__main__":
    run_npt()

Expected behavior
The production run should have successfully initialized from the checkpoint specified and provided the .xyz, .prp, .H, and .log files upon simulation progression.
Software versions

Operating system and version: Linux 3.10.0-1127.el7.x86_64
Cassandra version: 1.2.2
mosdef_cassandra version: 0.2.1
mbuild version: 0.10.8
foyer version: 0.7.4

Closed by #92 and #93.


Verify "big red button" works

The "big red button" is an account-wide configuration setting to turn log forwarding off, regardless of the configuration setting in each individual account. To support this setting, we need to make sure the LogEventAggregator and the PrioritySampledBuffer will change the application_logging.forwarding.max_samples_stored value to zero when this value is sent by the collector.
For additional details, read APM Agent Log Forwarding: Account-Level Shutoff Control (Internal)

#1103 adds a unit test to our suite to verify the functionality.
The remaining work will be done in a pairing session with members of other teams to evaluate how the new setting responds end-to-end.

After my User ID was added to the feature flag and I disabled account logs for the Ruby Agent Test account, I saw the event_harvest_config.harvest_limit.log_event_data value get reported as zero. The agent upheld this value and forwarded zero logs: https://staging.onenr.io/0DvwBK1GVRp
After this, I re-enabled account logs and had the response as the expected 833 and logs were forwarded to NR1: https://staging.onenr.io/0LZQWgb3BQW


Quick Sort_code

Description
I will write code of quick sort and explain this | |  ### Documentation

Domain of Contribution
-[x]C/CPP

/assign


Fixes a panic when Trace level log fired

This was a minor issue introduced in 3f53baa3c58d64eca2db6317a479a17fb27d8184
The issue is minor, because Trace should not be enabled in most prod deployments, but still bit nasty :)

Codecov Report
Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (a41ff05) 52.31% compared to head (d425460) 52.75%.

Files
Patch %
Lines

writer.go
33.33%
1 Missing and 1 partial :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##           master      #15      +/-   ##
==========================================
+ Coverage   52.31%   52.75%   +0.43%
==========================================
  Files           1        1
  Lines         216      218       +2
==========================================
+ Hits          113      115       +2
  Misses         96       96
  Partials        7        7

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Ok, thanks, lets fix the panic first
I guess we can think later about breadcrumbs and watch for now will there be such feature request or not


Remove duplicated cookie section and fix section header

In the clustering md the section about the node logging out the home dir of the effective user and default cookie location is duplicated under the ###Troubleshooting header and the ###Troubleshooting Cookie-based Authentication headers.
Removed the second dupe and moved the anchor link header to replace the first ###Troubleshooting header.
I can't quite tell what the methodology was with linking and not linking headers; took my best guess.

@koslowdavida Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.

@koslowdavida Thank you for signing the Contributor License Agreement!


undertale-mod-tool: remove extract_dir

Closes https://github.com/Calinou/scoop-games/issues/1080

[x] I have read the Contributing Guide.

Covered by https://github.com/Calinou/scoop-games/pull/1081


the .obj result of test examples are weird

sorry. same to another issue.

I also have this question, and I would like to ask how you solved it?

Probably you did not load the checkpoinit when running the script. It will run even if there is no ckpt. Please check if the ckpt is loaded correctly.


How to manage when cast is deleted

this is url https://warpcast.com/dwr.eth/0x78e746aa and this cast is deleted So I am getting a error on frontend side. So how to manage this

You can either pass in your custom cast data JSON to render a deleted cast or use the silentError option.
Fixed with 1.8.1.

and Reply casts are not showing


Couldn't read log of graphql container

log.txt
We have a container of graphql service.
It writes a log to stdout
I open logs form to view logs and see an error:
"null is not an object (evaluating 'b.substring')"
Expected behavior
Portainer have to show log like this:
{"level":50,"time":1531119821586,"msg":"http://play:9000/api/v1/user/profile","pid":14,"hostname":"d776238093b9","req":{"id":1,"method":"POST","url":"/fromProtectedNetwork","headers":{"accept":"*/*","content-type":"application/json","authorization":"Bearer undefined","x-csrf-token":"","accept-encoding":"gzip,deflate","user-agent":"node-fetch/1.0 (+https://github.com/bitinn/node-fetch)","connection":"close","content-length":"147","host":"graphql:3090"},"remoteAddress":"::ffff:<IP_ADDRESS>","remotePort":40976},"response":{"name":"FetchError","message":"request to http://play:9000/api/v1/user/profile failed, reason: getaddrinfo ENOTFOUND play play:9000","type":"system","errno":"ENOTFOUND","code":"ENOTFOUND"},"request":null,"v":1}
{"level":30,"time":1531119821603,"msg":"request completed","pid":14,"hostname":"d776238093b9","req":{"id":1,"method":"POST","url":"/fromProtectedNetwork","headers":{"accept":"*/*","content-type":"application/json","authorization":"Bearer undefined","x-csrf-token":"","accept-encoding":"gzip,deflate","user-agent":"node-fetch/1.0 (+https://github.com/bitinn/node-fetch)","connection":"close","content-length":"147","host":"graphql:3090"},"remoteAddress":"::ffff:<IP_ADDRESS>","remotePort":40976},"res":{"statusCode":200,"header":"HTTP/1.1 200 OK\r\nX-Powered-By: Express\r\nContent-Type: application/json; charset=utf-8\r\nContent-Length: 25\r\nETag: W/\"19-2tlaeTMfQrUTP0IBvpG3f83Bybc\"\r\nDate: Mon, 09 Jul 2018 07:03:41 GMT\r\nConnection: close\r\n\r\n"},"responseTime":81,"v":1}

Technical details:

Portainer version: 1.16.4
Docker version (managed by Portainer): 17.05.0-ce
Platform (windows/linux): Ubuntu 16.4
Command used to start Portainer (docker run -p 9000:9000 portainer/portainer): don't remember
Browser: All

Unfortunately, I cannot share this image.

I was unable to reproduce this on 1.23.2 using the graphql image hasura/graphql-engine.
@vazuev could you please try and reproduce this on 1.23.2, also it would really help to have reproduction steps and know an image this occurs with for us to try and reproduce with


Add default constructor to Wrapper classes

Necessary to correctly deserialize Wrappers with Jackson using property-based creators using the necessary type converters. Otherwise Jackson uses delegate-based creators and initialize the wrappers directly using the constructor with the Map parameter.

Codecov Report

Merging #25 into master will increase coverage by 0.11%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master      #25      +/-   ##
============================================
+ Coverage     80.03%   80.14%   +0.11%
- Complexity      183      184       +1
============================================
  Files            27       27
  Lines           531      534       +3
  Branches         82       82
============================================
+ Hits            425      428       +3
  Misses           68       68
  Partials         38       38

Impacted Files
Coverage Δ
Complexity Δ

.../java/com/kaufland/generation/WrapperGeneration.kt
98.43% <100.00%> (+0.07%)
8.00 <1.00> (+1.00)

Continue to review full report at Codecov.

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


yosys_optimizer: Directly convert MLIR to Yosys' AST instead of using Verilog

The YosysOptimizer uses the Verilog Emitter to emit code that can be passed to Yosys, then runs a yosys script. It would be a better practice to directly convert to the RTLIL IR and skip that intermediate step.

I suspect we will not continue to use Yosys forever, so I am optimistically closing this.


WIP: Dont review

What changes were proposed in this pull request?

Why are the changes needed?

Does this PR introduce any user-facing change?

Is the change a dependency upgrade?

How was this patch tested?

check

Hey @akshat0395 @tanishq-chugh I will stop the ongoing precommit run to perform the scheduled Jenkins upgrade. Please wait for the upgrade to finish before launching another.

Thanks for the update @zabetak, will wait for the upgrade

@akshat0395 The upgrade is finished. Feel free to proceed as you see fit!

@akshat0395, can we close this PR as duplicate?

Hey @deniskuzZ, yes we can close this PR
Thanks for checking it

hi @akshat0395, is that a duplicate PR? can we close it?


perfdash: a few improvements

Load config for tests from local directory.
Limit number of builds to 10 for faster bootstrap.
Redirect to gs on click on the graph.

FYI @hemanthmalla you can just run:
CONFIG_PATH="../../jobs/fqdn.yaml" BUILDS=20 ./run_perfdash.sh

and you should be able to see metrics from FQDN runs for last 20 runs


Add 'other' reason description in to application withdrawal reasons

We had previously removed the 'other' free text input on the Application Withdrawal reasons page, this adds it back in.
Screenshots of UI changes
Before

After

thanks @yndajas - all good suggestions


Incorrect link handling

Orga doesn't appear to handle links in definition lists, and also does not apply the correct formatting if a link is formatted as source code using the ~ character.
I appreciate that these are two separate issues, but I hope you don't mind me opening them together, as the images show both issues.
Expected outcome

When using links in definition list headers,  I expect them to render as links.
When using a link in text surrounded by ~ characters, I expect it to be rendered in a <code> tag.

As a visual, I expected the rendered text to look like this (as rendered by Pandoc and Hakyll):

Notice the definition list 'header', and the two links at the end of the paragraph, Maybe and Either
Actual outcome

Links in definition lists are not rendered or even picked up on properly. They render as plain text.
Links that should be formatted as <code> are not, and are instead just surrounded by ~ characters in the rendered HTML output.

Here's what Orga and Gatsby renders:

In this image, the header is rendered as the literal link text content in org mode and is not a link. The two links at the end are surrounded by ~ characters and are not in <code> tags.

On the subject of link formatting: It seems to apply to any formatting within a link:
In this screenshot, the text between the / characters should have been rendered in Italics.

I have also noticed that the lack of formatting happens within other blocks (such as #+BEGIN_ASIDE) even when it's not in a link context. I suspect these issues are related.
This image shows how formatting is not applied within this #+BEGIN_ASIDE block. As mentioned in #13, this is actually a <pre> block, though it should be an <aside>.

For posterity and if anyone else runs into the first of these problems (links not being transformed properly), here's a workaround you can wrap your html content in to transform untransformed org links to HTML anchor tags:
export const orgLinktoHtml = (url, text) =>
  `<a href="${url}">${text ?? url}</a>`

export const transformLinks = input =>
  input.replace(
    /\[\[([^\]]+)\](\[([^[\]]*)\])?\]/g,
    (_, url, __, text) => orgLinktoHtml(url, text),
  )

This assumes that you don't use the org link pattern for any other parts of your content.


How do i set alarm at Particular Day of the Week (for example only alarm for Monday and Tuesday etc.) ? And How Do i set Alarm Every Day?

Hi @ApWin.
Unfortunately, there is no function that set an alarm at particular day in this library.
Only you can do is set an alarm through time.
But, you can set an alarm for every day.
Just choose the time you want and keep your switch on.
Unless the switch is off, the alarm will be triggered at the time you set.


don't publish .babelrc

When I install, I get an error when I build with webpack because it says it can't find the babel plugin add-module-exports which is specified in react-dropzone's .babelrc. It is my understanding that this file shouldn't be published to npm at all.
Searching around I found this which seems to resolve it by being specific about which files are published to the npm registry, by specifying something like "files": "src/index.js".
This way the .babelrc won't end up on the user's system, so babel won't attempt to obey it. I had to remove the .babelrc file myself from node_modules/react-dropzone/.babelrc to resolve this.

You shouldn't compile sources from node_modules. Exclude them in your webpack config.

Also, in package.json the main field is set to the compiled JS file.

Thanks! Sorry for the noise, I hadn't realized something went wrong in my webpack config.


Exported dates in CSV are in UTC

Export in local time, also split date and time

Fixed in 68c23b7252569b333881d9b6b782529911eb6e0c and 291f3e4f389604afadfc7ea1b406e246ef309696


Thermostat Card does not show target temperature and operating mode (it does not change the color) with climate.nest

Hi,
I've a Nest thermostat configured in my Home Assistant. I configured the thermostat card as follows:
      - type: custom:thermostat-card
        title: Nest
        entity: climate.nest
        chevron_size: 100
        highlight_tap: true
        hvac:
          states:
            'Off': 'off'
            'Eco': 'eco'
            'Heating': 'heat'
          attribute: operation_mode

But the thermostat card does not show the target temperature. Furthermore when I increase or decrease the target temperature, by tapping on the widget, it starts always from 0 degrees.
Neither the operating mode is showed by changing color.
I've seen that the attributes of climate.nest are:
operation_list: off,heat,eco
away_mode: on
supported_features: 1153
max_temp: 32
friendly_name: Entryway (Termostato)
operation_mode: heat
current_temperature: 23.5
temperature: null
min_temp: 9

The other "attributes" are sensor or bynary_sensor like:
binary_sensor.entryway_thermostat_termostato_has_leaf
sensor.entryway_thermostat_termostato_target
sensor.entryway_thermostat_termostato_hvac_state

this is my widget when the nest is heating:

This is the most interesting @francesconazzaro
The card uses target_temperature or target_temperature_low & target_temperature_high to set and maintain the target. So far the climate interface forced this to be mandatory, but your setup looks like it's working differently.
Does it work properly with the default "climate" entity in the old /status interface?
While the component can have extra adjustments to accommodate your setup, I'd be reluctant to start implementation before understand if this is a normal setup or not.
Also to fix the state issue, please remove:
          states:
            'Off': 'off'
            'Eco': 'eco'
            'Heating': 'heat'

The problem is your thermostat is reporting operation_mode: heat but you're forcing the card to try to map heat (from your Nest) through a mapping from 'Heating' which defaults then to 'off'.
hvac_state: config.hvac.states[hvac_state] || 'off',

The default setup for states is defined in the code (you can also define it yourself, but must do it correctly):
    if (!cardConfig.hvac.states) cardConfig.hvac.states = { 'off': 'off', 'heat': 'heat', 'cool': 'cool', };

To explain better the mapping allows a thermostat that reports it's state as something weird like H3ating to still map to a valid value to display color by mapping it to heat used internally.
'H3ating': 'heat'

Hi @ciotlosm thanks for the responsive answer!
I configured climate.nest with the official guide here https://www.home-assistant.io/components/nest/:
nest:
  client_id: my-client-id
  client_secret: my-client-secret

I removed the states entry as you suggest. Now I have a different "state issue".
When the Nest is ON, it is always orange-red, also when it is not heating.
I guess because the operation_mode is heat also when the Nest is not heating.
I'll resume:

Nest On, Not heating (because the target temperature is below the ambient temperature): state is heat.
Nest On, heating (because the target temperature is upper the ambient temperature): state isheat.
Nest is Off: state is off.
Nest is Eco: state is eco.

The color of the widget, in my case, should be set from the sensor sensor.entryway_thermostat_termostato_hvac_state.
This sensor has state heating when the Nest is actually heating, and it is off when the Nest is not heating.

I found 2 interesting documentation pages about Nest that i haven't seen before. And it seems exactly my situation:
https://www.home-assistant.io/components/binary_sensor.nest/
https://www.home-assistant.io/components/sensor.nest/
I have all those sensors in my Home Assistant instead of having them as climate.nest attributes.
But I don't know why I have those sensors because I did not configured them.

I have the same issue with NEST.
It looks like the card looks for "operation_mode" to change the color of the display. In 'climate.XXX', the nest uses operation_mode to indicate if the HVAC is set to heating or cooling which would not allow the color to change as the furnace or A/C starts running.
The nest uses 'hvac_state' to indicate the current state. The problem is, the Nest's 'climate.XXX' does not include this variable. The 'sensor.XXX_hvac_state' however, does. Is there anyway to pull the variable from the sensor?

I will add it as an enhancement.
Sent with GitHawk

Hi @ciotlosm , are there any news on this?

How do you get the state mode to work with Ecobee3? I used this code but no operation mode is displayed:
- type: custom:thermostat-card
      title: Ecobee
      entity: climate.my_ecobee3
      chevron_size: 100
      hvac:
        states:
          'Off': 'off'
          'Cooling': 'cool'
          'Heating': 'heat'
        attribute: operation_mode

- type: 'custom:thermostat-card'         title: Hallway         entity: climate.xyz         ambient_temperature: sensor.xyz_temp         hvac:           states:             idle: 'off'             heating: heat           attribute: hvac_action


Sync at sequence 13570 aborts with error

I'm syncing from SkimDB to my local couchdb.
Application at sequence 13570 quits.
After restarting at sequence 13570 I've got something like this:
START npm FullFat/1.1.4 node/v0.10.9 pid=20272
13571: derby-auth
-> derby-auth-0.0.6.tgz
<- derby-auth-0.0.6.tgz
ERROR { [Error: {"error":"unknown_error","reason":"function_clause"}
] statusCode: 500 }

Error: {"error":"unknown_error","reason":"function_clause"}

    at IncomingMessage.<anonymous> (/opt/scripts/node_modules/npm-fullfat-registry/node_modules/parse-json-response/parse.js:38:12)
    at IncomingMessage.EventEmitter.emit (events.js:117:20)
    at _stream_readable.js:910:16
    at process._tickCallback (node.js:415:13)

The npm couchapp requires CouchDB 1.4.0 or greater, though 1.5.0 is recommended. I run CouchDB 1.6.1 and have not had these problems.


Highlight yml injections in enqueuer's webpage

Highlighting and distinguishing keys from values would make this page more readable.

In the example above, requisitions, name, iterations and delay would a different color from the one that colorizes some requisition name, 2, another requisition name and 200.

:tada: This issue has been resolved in version 4.5.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Shadowing error when field names matches package

I encountered a false positive shadowing error when the field name of a message matches the package name of an imported message. This is accepted by protoc but protox detects it as a shadowing issue.
Minimal reproducible example
Having 2 Protobuf schemas with the following content:
In other.proto
syntax = "proto3";

package other;

message Other {}

In sample.proto
syntax = "proto3";

package sample;

import "other.proto";

message Sample {
  other.Other other = 1;
}

Error message
  Error:   × name 'other.Other' is shadowed
     ╭─[sample.proto:8:3]
   7 │ message Sample {
   8 │   other.Other other = 1;
     ·   ─────┬─────
     ·        ╰── found here
   9 │ }
     ╰────
    help: 'other.Other' is is resolved to 'sample.Sample.other.Other', which
          is not defined. The innermost scope is searched first in name
          resolution. Consider using a leading '.'(i.e., '.other.Other') to
          start from the outermost scope.

Current workaround
When renaming the field the issue can be worked around, but changing the field names is not really an option in my bigger setup, as they are already being used in several places.

Thanks for the report, I expect that you can work around this by locking the version of prost-reflect to version 0.14.0 which didn't have https://github.com/andrewhickman/prost-reflect/pull/126. I'll take a look at fixing this.

This is also a re-occurrence of #57

Thanks for taking a look so quickly. I'll pin it to that version for now as a temporary workaround 👍.

@dnaka91 Hopefully this is fixed in prost-reflect 0.14.2


Nested Dialogs

The overlay appears in front of nested dialogs.
https://jsfiddle.net/4kdz00t5/4/
The fiddle will use the native support in Chrome and works ok, in IE11 it will use the Polyfill and you cannot interact with elements on the nested dialog.

@samthor can I ask why this has been closed?  The issue still seems to be present in the jsfiddle?

I was actually confused about the issue. I understand now: you're nesting a <dialog> within another <dialog>.
This is a known limitation as per the README - your dialogs should be children of <body>. Your fix #48 actually breaks the spec, because it means I can tap on any dialog/backdrop I can get to (even though backdrops are initially full-sized, you can shrink them).
I do have a thought: maybe the dialog overlay (different to backdrop) could always be a sibling of the currently open dialog, and that's fine since it's position: fixed, it won't be effected by its position on the page. Although it's a bit awkward.

Thanks for reopening.  Yes you're right the fix wont work as it wont mask out the parent dialog.  Your thought should work though.

I've implemented the suggestion I made in Jun 2015 now - it's not perfect for modals, we'll still warn you it's probably not what you want, but it's the best we can do.


C++ modules, xmake and compile_commands.json?

Xmake Version
v2.8.3
Operating System Version and Architecture
arch linux
Describe Bug
I am experimenting with C++ modules and Xmake. Building and running modularized code on xmake works flawlessly, however, clangd seems not to work with the exported compile_commands.json.
I have the latest llvm ecossystem instaled (clang 18.0.0 and the latest libc++) with the experimental clangd modules support applyed on top.
Expected Behavior
Is this a expected behavior? Does Xmake support generating a compile_commands.json compatible with c++ modules?
Project Configuration
My source code tree(basically the stl_headerunit example):
.
├── compile_commands.json
├── src
│  ├── hello.cpp
│  └── main.cpp
├── test.lua
└── xmake.lua

My xmake.lua:
add_rules("mode.release", "mode.debug")
set_languages("c++2b")
set_toolchains("clang")
add_cxxflags(
	"-fmodules",
	"-fimplicit-modules",
	"-fmodule-map-file=/usr/include/c++/v1/module.modulemap",
	"-std=c++2b",
	"-stdlib=libc++",
	"-nostdlib++",
	"-Wall",
	"-Wextra",
	"-Werror",
	"-Wpedantic",
	{ force = true }
)
add_ldflags("-lc++", "-lc++abi", "-lfmt", { force = true })

target("stl_headerunit")
set_kind("binary")
set_policy("build.c++.modules", true)
set_policy("build.c++.clang.stdmodules", true)
add_files("src/*.cpp")

Additional Information and Error Logs
The generation of my compile_commands.json
➜  xmake project -k compile_commands
[  0%]: generating.module.deps src/main.cpp
[  0%]: generating.module.deps src/hello.cpp
create ok!

The file
[
  {
    "directory": "/home/pablo/xmake/tests/projects/c++/modules/stl_headerunit",
    "arguments": [
      "/usr/bin/clang",
      "-Qunused-arguments",
      "-m64",
      "-fvisibility=hidden",
      "-fvisibility-inlines-hidden",
      "-O3",
      "-fmodules",
      "-fimplicit-modules",
      "-fmodule-map-file=/usr/include/c++/v1/module.modulemap",
      "-std=c++2b",
      "-stdlib=libc++",
      "-nostdlib++",
      "-Wall",
      "-Wextra",
      "-Werror",
      "-Wpedantic",
      "-DNDEBUG",
      "-fmodules-cache-path=build/.gens/stl_headerunit/linux/x86_64/release/rules/modules/cache",
      "-x",
      "c++-module",
      "--precompile",
      "-c",
      "src/hello.cpp",
      "-o",
      "build/.gens/stl_headerunit/linux/x86_64/release/rules/modules/cache/37b9dad1/hello.pcm"
    ],
    "file": "src/hello.cpp"
  },
  {
    "directory": "/home/pablo/xmake/tests/projects/c++/modules/stl_headerunit",
    "arguments": [
      "/usr/bin/clang",
      "-c",
      "-Qunused-arguments",
      "-m64",
      "-fvisibility=hidden",
      "-fvisibility-inlines-hidden",
      "-O3",
      "-fmodules",
      "-fimplicit-modules",
      "-fmodule-map-file=/usr/include/c++/v1/module.modulemap",
      "-std=c++2b",
      "-stdlib=libc++",
      "-nostdlib++",
      "-Wall",
      "-Wextra",
      "-Werror",
      "-Wpedantic",
      "-DNDEBUG",
      "-fmodule-file=hello=build/.gens/stl_headerunit/linux/x86_64/release/rules/modules/cache/37b9dad1/hello.pcm",
      "-o",
      "build/.objs/stl_headerunit/linux/x86_64/release/src/main.cpp.o",
      "src/main.cpp"
    ],
    "file": "src/main.cpp"
  },
  {
    "directory": "/home/pablo/xmake/tests/projects/c++/modules/stl_headerunit",
    "arguments": [
      "/usr/bin/clang",
      "-c",
      "-Qunused-arguments",
      "-m64",
      "-fvisibility=hidden",
      "-fvisibility-inlines-hidden",
      "-O3",
      "-fmodules",
      "-fimplicit-modules",
      "-fmodule-map-file=/usr/include/c++/v1/module.modulemap",
      "-std=c++2b",
      "-stdlib=libc++",
      "-nostdlib++",
      "-Wall",
      "-Wextra",
      "-Werror",
      "-Wpedantic",
      "-DNDEBUG",
      "-o",
      "build/.objs/stl_headerunit/linux/x86_64/release/src/hello.cpp.o",
      "src/hello.cpp"
    ],
    "file": "src/hello.cpp"
  }
]

It should work for 2.8.3
see https://github.com/xmake-io/xmake/pull/4199

Note that I don't think compile_commands.json is suitable for module information. There is some effort in SG15 to define a file, similar to compile_commands.json, that does provide sufficient information.

Idk if the problem is in my setup or in clangd then, because I keep getting the error:

You can check the generated compile_commands, if the generated flags don't have any problem, it should be an issue with clangd.

I'm working on a big refactor of module compilation so maybe somes of your issues Will be fixed
With the current implementation the compile_commands """work""" if your clangd is exactly the same version of the clang used for module compilation but it require full project compilation before linting and (and you need to rebuild your files before the lint get updatef)

Yeah, my clangd and clang are both in version 18.0. Also, my stl header modules are generated using my system clang( I compiled libc++ from source), but despite of that I can't get it working.
Let me know when you progress with that. I can help too if you want.

I'm working on a big refactor of module compilation so maybe somes of your issues Will be fixed
With the current implementation the compile_commands """work""" if your clangd is exactly the same version of the clang used for module compilation but it require full project compilation before linting and (and you need to rebuild your files before the lint get updatef)

Yeah, my clangd and clang are both in version 18.0. Also, my stl header modules are generated using my system clang( I compiled libc++ from source), but despite of that I can't get it working.
Let me know when you progress with that. I can help too if you want.

No problem, i'll probably recompile my llvm with the clangd PR to try it

Note that I don't think compile_commands.json is suitable for module information. There is some effort in SG15 to define a file, similar to compile_commands.json, that does provide sufficient information.

Does clang support it now?

No, the support is incomplete: https://github.com/llvm/llvm-project/pull/66462.
I think we can close this.

Note that, despite some intellisense working, I still got errors while importing std modules, like:

Could not build module std_iostream

Note that, despite some intellisense working, I still got errors while importing std modules, like:

Could not build module std_iostream

The only way i got the intellisense working is by using only modules (and not headerunits)
On Linux / macOS, and it work only after a full build of the project (and modification of a module interface is only updated after rebuild)


Adding William Angliss Institute Email Domain

Website: www.angliss.edu.au
Email domain: myangliss.edu.au
Technology (including IT course): https://www.angliss.edu.au/courses/foods/food-science-and-technology/

@StefanBuchman Thank you for the update! Pull request merged.


phpExtensions.rrd: init at 2.0.3

Description of changes
This PR adds the PHP RRD extension.
Things done

Built on platform(s)

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

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

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

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[X] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.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.

@drupol Seems like bulidPecl doesn't support the hash attribute and strictly uses sha256 for the fetchurl function it builds when there's no src attribute applied :wink:

Builds again with this fix

Looks like I will need to fix that upstream too :)

@GrahamcOfBorg build phpExtensions.rrd


Readme file needs to be updated

There is not any develop branch in the project but the 'readme.md' says that pull from develop branch. So develop needs to be changed to master.

Hi, I would like to work on this issue.

@anubhavsingh16 can you also add the CWOC lable otherwise it won't be counted.


Document mtxFromRows / mtxFromCols

Fixes concerns in #1933, together with PR #1934 .

Documentation is generated, this is not source.


Indent Partials

As referenced in this issue: https://github.com/janl/mustache.js/issues/562
Partials aren't indented as per the spec: https://github.com/mustache/spec/blob/master/specs/partials.yml#L13-L15
This adds indentation tracking for partials and applies them to the first instance of a partial on a line (to not indent inline partials which would violate a different part of the spec).
It's not really a perfect implementation - to really sort this would require reproaching how tokenising is done, so this sort of slots around the current approach to that.

Any update?

Nope, all updates are in the respective Issues / PRs. We lack maintainer force. Any help reviewing issues / PRs is appreciated! :)

Is it possible to receive the indentation string within the called template?
I read the indentation of the first line is part of the specs, but It would be a reasonable solution to merely remove the indentation of the first partial's line and delegating this task to the called template; doing this way, the developer could decide to apply (or not) the indentation as needed.

These changes with some additions was merged in https://github.com/janl/mustache.js/pull/705, therefore closing this PR.
Thanks for your contribution 💯