Submit RBApy 1.0.2

id: rbapy
version: "1.0.2"
specificationsUrl: https://raw.githubusercontent.com/biosimulators/Biosimulators_RBApy/d4b58f667cdc9f7e6b9fec36c1f2b9b111a20beb/biosimulators.json
specificationsPatch:
version: "1.0.2"
image:
url: ghcr.io/biosimulators/biosimulators_rbapy/rbapy:1.0.2
digest: "sha256:ba864d2add5b444da6fbbc274b4eb633963e9c677b686c602efb6610b10d1ec3"
validateImage: true
commitSimulator: true

Thank you @biosimulators-daemon for your submission to the BioSimulators simulator validation/submission system!
The BioSimulators validator bot is validating the specifications of your simulator, validating your Docker image, and committing your simulator to the BioSimulators registry.
We will discuss any concerns with your submission in this issue.
A complete log of your simulator submission job will be available for 90 days here. The results of the validation of your tool will also be saved as a JSON file. A link to this file will be available for 90 days from the "Artifacts" section at the bottom of this page.

The specifications of your simulator is valid!

Summary of tests

Executed 73 test cases

Passed 28 test cases:

cli.CliDescribesSupportedEnvironmentVariablesInline
cli.CliDisplaysHelpInline
cli.CliDisplaysVersionInformationInline
combine_archive.CombineArchiveHasSedDocumentsInNestedDirectories
combine_archive.CombineArchiveHasSedDocumentsWithSameNamesInDifferentInNestedDirectories
combine_archive.WhenACombineArchiveHasAMasterFileSimulatorOnlyExecutesThisFile
combine_archive.WhenACombineArchiveHasNoMasterFileSimulatorExecutesAllSedDocuments
docker_image.DeclaresSupportedEnvironmentVariables
docker_image.DefaultUserIsRoot
docker_image.HasBioContainersLabels
docker_image.HasOciLabels
docker_image.SingularityImageExecutesSimulationsSuccessfully
log.SimulatorReportsTheStatusOfTheExecutionOfCombineArchives
log.SimulatorReportsTheStatusOfTheExecutionOfSedDocuments
log.SimulatorReportsTheStatusOfTheExecutionOfSedOutputs
log.SimulatorReportsTheStatusOfTheExecutionOfSedTasks
published_project.SimulatorCanExecutePublishedProject:rba/Escherichia-coli-K12-WT
results_report.SimulatorGeneratesReportsOfSimulationResults
sedml.SimulatorCanResolveModelSourcesDefinedByUriFragments
sedml.SimulatorCanResolveModelSourcesDefinedByUriFragmentsAndInheritChanges
sedml.SimulatorSupportsModelsSimulationsTasksDataGeneratorsAndReports
sedml.SimulatorSupportsMultipleReportsPerSedDocument
sedml.SimulatorSupportsMultipleTasksPerSedDocument
sedml.SimulatorSupportsRepeatedTasksWithFunctionalRanges
sedml.SimulatorSupportsRepeatedTasksWithLinearUniformRanges
sedml.SimulatorSupportsRepeatedTasksWithLogarithmicUniformRanges
sedml.SimulatorSupportsRepeatedTasksWithNestedFunctionalRanges
sedml.SimulatorSupportsRepeatedTasksWithVectorRanges

Failed 0 test cases

Skipped 45 test cases:

published_project.SimulatorCanExecutePublishedProject:bngl/Dolan-PLoS-Comput-Biol-2015-NHEJ
published_project.SimulatorCanExecutePublishedProject:bngl/test-bngl
published_project.SimulatorCanExecutePublishedProject:cellml/Elowitz-Nature-2000-Repressilator
published_project.SimulatorCanExecutePublishedProject:cellml/Lorenz-system
published_project.SimulatorCanExecutePublishedProject:mass/Bordbar-Cell-Syst-2015-RBC-metabolism
published_project.SimulatorCanExecutePublishedProject:neuroml-lems/Hodgkin-Huxley-cell-CVODE
published_project.SimulatorCanExecutePublishedProject:neuroml-lems/Hodgkin-Huxley-cell-Euler
published_project.SimulatorCanExecutePublishedProject:sbml-core/Caravagna-J-Theor-Biol-2010-tumor-suppressive-oscillations
published_project.SimulatorCanExecutePublishedProject:sbml-core/Ciliberto-J-Cell-Biol-2003-morphogenesis-checkpoint-Fehlberg
published_project.SimulatorCanExecutePublishedProject:sbml-core/Ciliberto-J-Cell-Biol-2003-morphogenesis-checkpoint-continuous
published_project.SimulatorCanExecutePublishedProject:sbml-core/Edelstein-Biol-Cybern-1996-Nicotinic-excitation
published_project.SimulatorCanExecutePublishedProject:sbml-core/Elowitz-Nature-2000-Repressilator
published_project.SimulatorCanExecutePublishedProject:sbml-core/Parmar-BMC-Syst-Biol-2017-iron-distribution
published_project.SimulatorCanExecutePublishedProject:sbml-core/Szymanska-J-Theor-Biol-2009-HSP-synthesis
published_project.SimulatorCanExecutePublishedProject:sbml-core/Tomida-EMBO-J-2003-NFAT-translocation
published_project.SimulatorCanExecutePublishedProject:sbml-core/Varusai-Sci-Rep-2018-mTOR-signaling-LSODA-LSODAR-SBML
published_project.SimulatorCanExecutePublishedProject:sbml-core/Vilar-PNAS-2002-minimal-circardian-clock
published_project.SimulatorCanExecutePublishedProject:sbml-core/Vilar-PNAS-2002-minimal-circardian-clock-continuous
published_project.SimulatorCanExecutePublishedProject:sbml-core/Vilar-PNAS-2002-minimal-circardian-clock-discrete-NRM
published_project.SimulatorCanExecutePublishedProject:sbml-core/Vilar-PNAS-2002-minimal-circardian-clock-discrete-SSA
published_project.SimulatorCanExecutePublishedProject:sbml-fbc/Escherichia-coli-core-metabolism
published_project.SimulatorCanExecutePublishedProject:sbml-qual/Chaouiya-BMC-Syst-Biol-2013-EGF-TNFa-signaling
published_project.SimulatorCanExecutePublishedProject:sbml-qual/Irons-J-Theor-Biol-2009-yeast-cell-cycle
published_project.SimulatorCanExecutePublishedProject:smoldyn/Lotka-Volterra
published_project.SimulatorCanExecutePublishedProject:xpp/Wu-Biochem-Pharmacol-2006-pituitary-GH3-cells
sedml.SimulatorProducesLinear2DPlots
sedml.SimulatorProducesLinear3DPlots
sedml.SimulatorProducesLogarithmic2DPlots
sedml.SimulatorProducesLogarithmic3DPlots
sedml.SimulatorProducesMultiplePlots
sedml.SimulatorProducesReportsWithCuratedNumberOfDimensions
sedml.SimulatorSupportsAddReplaceRemoveModelElementChanges
sedml.SimulatorSupportsAlgorithmParameters
sedml.SimulatorSupportsComputeModelChanges
sedml.SimulatorSupportsDataGeneratorsWithDifferentShapes
sedml.SimulatorSupportsDataSetsWithDifferentShapes
sedml.SimulatorSupportsModelAttributeChanges
sedml.SimulatorSupportsRepeatedTasksWithChanges
sedml.SimulatorSupportsRepeatedTasksWithFunctionalRangeVariables
sedml.SimulatorSupportsRepeatedTasksWithMultipleSubTasks
sedml.SimulatorSupportsRepeatedTasksWithNestedRepeatedTasks
sedml.SimulatorSupportsRepeatedTasksWithSubTasksOfMixedTypes
sedml.SimulatorSupportsSubstitutingAlgorithms
sedml.SimulatorSupportsUniformTimeCoursesWithNonZeroInitialTimes
sedml.SimulatorSupportsUniformTimeCoursesWithNonZeroOutputStartTimes

Warnings
docker_image.DeclaresSupportedEnvironmentVariables (0.6 s)

Test if a Docker image declares the environment variables that is supports
Warnings:
Docker images for simulation tools should declare the environment variables that they support.

The Docker image does not declare the following standard environment variables recognized by BioSimulators:
  - 'ALGORITHM_SUBSTITUTION_POLICY'
  - 'BUNDLE_OUTPUTS'
  - 'COLLECT_COMBINE_ARCHIVE_RESULTS'
  - 'COLLECT_SED_DOCUMENT_RESULTS'
  - 'DEBUG'
  - 'H5_REPORTS_PATH'
  - 'KEEP_INDIVIDUAL_OUTPUTS'
  - 'LOG_PATH'
  - 'OMEX_METADATA_INPUT_FORMAT'
  - 'OMEX_METADATA_OUTPUT_FORMAT'
  - 'OMEX_METADATA_SCHEMA'
  - 'PLOTS_PATH'
  - 'REPORTS_PATH'
  - 'REPORT_FORMATS'
  - 'SAVE_PLOT_DATA'
  - 'VALIDATE_IMAGES'
  - 'VALIDATE_OMEX_MANIFESTS'
  - 'VALIDATE_OMEX_METADATA'
  - 'VALIDATE_RESULTS'
  - 'VALIDATE_SEDML'
  - 'VALIDATE_SEDML_MODELS'
  - 'VIZ_FORMATS'

If the simulation tool implements these variables, they should be declared in the Dockerfile for the Docker image for the simulator.

Note, support for these environment variables is optional. Simulation tools are not required to support these variables.

Log: None

docker_image.HasBioContainersLabels (0.6 s)

Test that a Docker image has BioContainers labels with metadata about the image
Warnings:
Docker images are encouraged to have the following BioContainers labels:
  extra.identifiers.biotools

Log: None

Skips
published_project.SimulatorCanExecutePublishedProject:bngl/Dolan-PLoS-Comput-Biol-2015-NHEJ (0.0 s)

Required model formats and simulation algorithms for SED tasks:

Format: format_3972
Algorithm: KISAO_0000263

Reason for skip:
Case requires model formats format_3972 and simulation algorithms KISAO_0000263

Log: None

published_project.SimulatorCanExecutePublishedProject:bngl/test-bngl (0.0 s)

Required model formats and simulation algorithms for SED tasks:

Format: format_3972
Algorithm: KISAO_0000019

Reason for skip:
Case requires model formats format_3972 and simulation algorithms KISAO_0000019

Log: None

published_project.SimulatorCanExecutePublishedProject:cellml/Elowitz-Nature-2000-Repressilator (0.0 s)

Required model formats and simulation algorithms for SED tasks:

Format: format_3240
Algorithm: KISAO_0000019

Reason for skip:
Case requires model formats format_3240 and simulation algorithms KISAO_0000019

Log: None

published_project.SimulatorCanExecutePublishedProject:cellml/Lorenz-system (0.0 s)

Required model formats and simulation algorithms for SED tasks:

Format: format_3240
Algorithm: KISAO_0000019

Reason for skip:
Case requires model formats format_3240 and simulation algorithms KISAO_0000019

Log: None

published_project.SimulatorCanExecutePublishedProject:mass/Bordbar-Cell-Syst-2015-RBC-metabolism (0.0 s)

Required model formats and simulation algorithms for SED tasks:

Format: format_2585
Algorithm: KISAO_0000019

Reason for skip:
Case requires model formats format_2585 and simulation algorithms KISAO_0000019

Log: None

published_project.SimulatorCanExecutePublishedProject:neuroml-lems/Hodgkin-Huxley-cell-CVODE (0.0 s)

Required model formats and simulation algorithms for SED tasks:

Format: format_9004
Algorithm: KISAO_0000019

Reason for skip:
Case requires model formats format_9004 and simulation algorithms KISAO_0000019

Log: None

published_project.SimulatorCanExecutePublishedProject:neuroml-lems/Hodgkin-Huxley-cell-Euler (0.0 s)

Required model formats and simulation algorithms for SED tasks:

Format: format_9004
Algorithm: KISAO_0000030

Reason for skip:
Case requires model formats format_9004 and simulation algorithms KISAO_0000030

Log: None

published_project.SimulatorCanExecutePublishedProject:sbml-core/Caravagna-J-Theor-Biol-2010-tumor-suppressive-oscillations (0.0 s)

Required model formats and simulation algorithms for SED tasks:

Format: format_2585
Algorithm: KISAO_0000019

Reason for skip:
Case requires model formats format_2585 and simulation algorithms KISAO_0000019

Log: None

published_project.SimulatorCanExecutePublishedProject:sbml-core/Ciliberto-J-Cell-Biol-2003-morphogenesis-checkpoint-Fehlberg (0.0 s)

Required model formats and simulation algorithms for SED tasks:

Format: format_2585
Algorithm: KISAO_0000086

Reason for skip:
Case requires model formats format_2585 and simulation algorithms KISAO_0000086

Log: None

published_project.SimulatorCanExecutePublishedProject:sbml-core/Ciliberto-J-Cell-Biol-2003-morphogenesis-checkpoint-continuous (0.0 s)

Required model formats and simulation algorithms for SED tasks:

Format: format_2585
Algorithm: KISAO_0000019

Reason for skip:
Case requires model formats format_2585 and simulation algorithms KISAO_0000019

Log: None

published_project.SimulatorCanExecutePublishedProject:sbml-core/Edelstein-Biol-Cybern-1996-Nicotinic-excitation (0.0 s)

Required model formats and simulation algorithms for SED tasks:

Format: format_2585
Algorithm: KISAO_0000088

Reason for skip:
Case requires model formats format_2585 and simulation algorithms KISAO_0000088

Log: None

published_project.SimulatorCanExecutePublishedProject:sbml-core/Elowitz-Nature-2000-Repressilator (0.0 s)

Required model formats and simulation algorithms for SED tasks:

Format: format_2585
Algorithm: KISAO_0000019

Reason for skip:
Case requires model formats format_2585 and simulation algorithms KISAO_0000019

Log: None

published_project.SimulatorCanExecutePublishedProject:sbml-core/Parmar-BMC-Syst-Biol-2017-iron-distribution (0.0 s)

Required model formats and simulation algorithms for SED tasks:

Format: format_2585
Algorithm: KISAO_000019

Reason for skip:
Case requires model formats format_2585 and simulation algorithms KISAO_000019

Log: None

published_project.SimulatorCanExecutePublishedProject:sbml-core/Szymanska-J-Theor-Biol-2009-HSP-synthesis (0.0 s)

Required model formats and simulation algorithms for SED tasks:

Format: format_2585
Algorithm: KISAO_0000496

Reason for skip:
Case requires model formats format_2585 and simulation algorithms KISAO_0000496

Log: None

published_project.SimulatorCanExecutePublishedProject:sbml-core/Tomida-EMBO-J-2003-NFAT-translocation (0.0 s)

Required model formats and simulation algorithms for SED tasks:

Format: format_2585
Algorithm: KISAO_0000560

Reason for skip:
Case requires model formats format_2585 and simulation algorithms KISAO_0000560

Log: None

published_project.SimulatorCanExecutePublishedProject:sbml-core/Varusai-Sci-Rep-2018-mTOR-signaling-LSODA-LSODAR-SBML (0.0 s)

Required model formats and simulation algorithms for SED tasks:

Format: format_2585
Algorithm: KISAO_0000560

Reason for skip:
Case requires model formats format_2585 and simulation algorithms KISAO_0000560

Log: None

published_project.SimulatorCanExecutePublishedProject:sbml-core/Vilar-PNAS-2002-minimal-circardian-clock (0.0 s)

Required model formats and simulation algorithms for SED tasks:

Format: format_2585
Algorithm: KISAO_0000019
Format: format_2585
Algorithm: KISAO_0000027

Reason for skip:
Case requires model formats format_2585 and simulation algorithms KISAO_0000019, KISAO_0000027

Log: None

published_project.SimulatorCanExecutePublishedProject:sbml-core/Vilar-PNAS-2002-minimal-circardian-clock-continuous (0.0 s)

Required model formats and simulation algorithms for SED tasks:

Format: format_2585
Algorithm: KISAO_0000019

Reason for skip:
Case requires model formats format_2585 and simulation algorithms KISAO_0000019

Log: None

published_project.SimulatorCanExecutePublishedProject:sbml-core/Vilar-PNAS-2002-minimal-circardian-clock-discrete-NRM (0.0 s)

Required model formats and simulation algorithms for SED tasks:

Format: format_2585
Algorithm: KISAO_0000027

Reason for skip:
Case requires model formats format_2585 and simulation algorithms KISAO_0000027

Log: None

published_project.SimulatorCanExecutePublishedProject:sbml-core/Vilar-PNAS-2002-minimal-circardian-clock-discrete-SSA (0.0 s)

Required model formats and simulation algorithms for SED tasks:

Format: format_2585
Algorithm: KISAO_0000029

Reason for skip:
Case requires model formats format_2585 and simulation algorithms KISAO_0000029

Log: None

published_project.SimulatorCanExecutePublishedProject:sbml-fbc/Escherichia-coli-core-metabolism (0.0 s)

Required model formats and simulation algorithms for SED tasks:

Format: format_2585
Algorithm: KISAO_0000437

Reason for skip:
Case requires model formats format_2585 and simulation algorithms KISAO_0000437

Log: None

published_project.SimulatorCanExecutePublishedProject:sbml-qual/Chaouiya-BMC-Syst-Biol-2013-EGF-TNFa-signaling (0.0 s)

Required model formats and simulation algorithms for SED tasks:

Format: format_2585
Algorithm: KISAO_0000449

Reason for skip:
Case requires model formats format_2585 and simulation algorithms KISAO_0000449

Log: None

published_project.SimulatorCanExecutePublishedProject:sbml-qual/Irons-J-Theor-Biol-2009-yeast-cell-cycle (0.0 s)

Required model formats and simulation algorithms for SED tasks:

Format: format_2585
Algorithm: KISAO_0000449

Reason for skip:
Case requires model formats format_2585 and simulation algorithms KISAO_0000449

Log: None

published_project.SimulatorCanExecutePublishedProject:smoldyn/Lotka-Volterra (0.0 s)

Required model formats and simulation algorithms for SED tasks:

Format: format_9001
Algorithm: KISAO_0000057

Reason for skip:
Case requires model formats format_9001 and simulation algorithms KISAO_0000057

Log: None

published_project.SimulatorCanExecutePublishedProject:xpp/Wu-Biochem-Pharmacol-2006-pituitary-GH3-cells (0.0 s)

Required model formats and simulation algorithms for SED tasks:

Format: format_9010
Algorithm: KISAO_0000019

Reason for skip:
Case requires model formats format_9010 and simulation algorithms KISAO_0000019

Log: None

sedml.SimulatorProducesLinear2DPlots (3.5 s)

Test that a simulator produces linear 2D plots
Reason for skip:
No curated COMBINE/OMEX archives are available to generate archives for testing

Log: None

sedml.SimulatorProducesLinear3DPlots (3.5 s)

Test that a simulator produces linear 3D plots
Reason for skip:
No curated COMBINE/OMEX archives are available to generate archives for testing

Log: None

sedml.SimulatorProducesLogarithmic2DPlots (3.4 s)

Test that a simulator produces logarithmic 2D plots
Reason for skip:
No curated COMBINE/OMEX archives are available to generate archives for testing

Log: None

sedml.SimulatorProducesLogarithmic3DPlots (3.6 s)

Test that a simulator produces logarithmic 3D plots
Reason for skip:
No curated COMBINE/OMEX archives are available to generate archives for testing

Log: None

sedml.SimulatorProducesMultiplePlots (3.3 s)

Test that a simulator produces multiple plots
Reason for skip:
No curated COMBINE/OMEX archives are available to generate archives for testing

Log: None

sedml.SimulatorProducesReportsWithCuratedNumberOfDimensions (3.5 s)

Test that that the curated number of output dimensions matches the actual number of output dimensions
Reason for skip:
No curated COMBINE/OMEX archives are available to generate archives for testing

Log: None

sedml.SimulatorSupportsAddReplaceRemoveModelElementChanges (3.5 s)

Test that a simulator supports model changes that involve adding, replacing, and removing model elements.
Reason for skip:
This test is only implemented for XML-based model languages. Please contact the BioSimulators Team to discuss implementing tests for additional languages.

Log: None

sedml.SimulatorSupportsAlgorithmParameters (3.5 s)

Test that a simulator supports setting the values of parameters of algorithms
Reason for skip:
No curated COMBINE/OMEX archives are available to generate archives for testing

Log: None

sedml.SimulatorSupportsComputeModelChanges (3.6 s)

Test that a simulator supports compute model changes
Reason for skip:
This test is only implemented for XML-based model languages. Please contact the BioSimulators Team to discuss implementing tests for additional languages.

Log: None

sedml.SimulatorSupportsDataGeneratorsWithDifferentShapes (3.5 s)

Test that a simulator supports data generators with different shapes
Reason for skip:
No curated COMBINE/OMEX archives are available to generate archives for testing

Log: None

sedml.SimulatorSupportsDataSetsWithDifferentShapes (3.4 s)

Test that a simulator supports data generators with different shapes
Reason for skip:
No curated COMBINE/OMEX archives are available to generate archives for testing

Log: None

sedml.SimulatorSupportsModelAttributeChanges (3.4 s)

Test that a simulator supports changes to the attributes of model elements
Reason for skip:
This test is only implemented for XML-based model languages. Please contact the BioSimulators Team to discuss implementing tests for additional languages.

Log: None

sedml.SimulatorSupportsRepeatedTasksWithChanges (3.4 s)

Test that a simulator supports repeated tasks with multiple subtasks
Reason for skip:
This test is only implemented for XML-based model languages. Please contact the BioSimulators Team to discuss implementing tests for additional languages.

Log: None

sedml.SimulatorSupportsRepeatedTasksWithFunctionalRangeVariables (3.4 s)

Test that a simulator supports repeated tasks over nested functional ranges based on model (specification) variables
Reason for skip:
This test is only implemented for XML-based model languages. Please contact the BioSimulators Team to discuss implementing tests for additional languages.

Log: None

sedml.SimulatorSupportsRepeatedTasksWithMultipleSubTasks (621.1 s)

Test that a simulator supports repeated tasks with multiple subtasks
Reason for skip:
The image 'ghcr.io/biosimulators/biosimulators_rbapy/rbapy:1.0.2' could not execute the archive:

  [Errno 1] Operation not permitted

Log:
/usr/local/lib/python3.9/site-packages/biosimulators_utils/warnings.py:31: BioSimulatorsWarning: COMBINE/OMEX archive may be invalid.

  - The manifest does not include its parent COMBINE/OMEX archive. Manifests should include their parent COMBINE/OMEX archives.

  warnings.warn(termcolor.colored(message, Colors.warning.value), category)

/usr/local/lib/python3.9/site-packages/biosimulators_utils/warnings.py:31: BioSimulatorsWarning: The SED document is potentially incorrect.

  - Output `__repeated_task_report` may be invalid.

    - Some simulation tools will not be able to generate this output because it uses data from repeated tasks. Output for repeated tasks is an experimental feature of SED-ML, which is not officially supported.

  warnings.warn(termcolor.colored(message, Colors.warning.value), category)

/usr/local/lib/python3.9/site-packages/biosimulators_utils/warnings.py:31: BioSimulatorsWarning: The COMBINE/OMEX archive may be invalid.

  - The SED-ML file at location `simulation.sedml` may be invalid.

    - Output `__repeated_task_report` may be invalid.

      - Some simulation tools will not be able to generate this output because it uses data from repeated tasks. Output for repeated tasks is an experimental feature of SED-ML, which is not officially supported.

  warnings.warn(termcolor.colored(message, Colors.warning.value), category)

Archive contains 1 SED-ML documents with 1 models, 1 simulations, 2 tasks, 2 reports, and 0 plots:

  simulation.sedml:

    Tasks (2):

      __repeated_task_0

      task

    Reports (2):

      __repeated_task_report: 1 data sets

      task_report: 1 data sets

Executing SED-ML file 1: simulation.sedml ...

Bundling outputs ...

Cleaning up ...

============= SUMMARY =============

Executed 1 SED documents:

  SED documents (1):

    Succeeded: 1

    Skipped: 0

    Failed: 0

  Tasks (2):

    Succeeded: 2

    Skipped: 0

    Failed: 0

  Outputs (2):

    Succeeded: 2

    Skipped: 0

    Failed: 0

sedml.SimulatorSupportsRepeatedTasksWithNestedRepeatedTasks (1125.2 s)

Test that a simulator supports nested repeated tasks
Reason for skip:
The image 'ghcr.io/biosimulators/biosimulators_rbapy/rbapy:1.0.2' could not execute the archive:

  [Errno 1] Operation not permitted

Log:
/usr/local/lib/python3.9/site-packages/biosimulators_utils/warnings.py:31: BioSimulatorsWarning: COMBINE/OMEX archive may be invalid.

  - The manifest does not include its parent COMBINE/OMEX archive. Manifests should include their parent COMBINE/OMEX archives.

  warnings.warn(termcolor.colored(message, Colors.warning.value), category)

/usr/local/lib/python3.9/site-packages/biosimulators_utils/warnings.py:31: BioSimulatorsWarning: The SED document is potentially incorrect.

  - Output `__repeated_task_report` may be invalid.

    - Some simulation tools will not be able to generate this output because it uses data from repeated tasks. Output for repeated tasks is an experimental feature of SED-ML, which is not officially supported.

  warnings.warn(termcolor.colored(message, Colors.warning.value), category)

/usr/local/lib/python3.9/site-packages/biosimulators_utils/warnings.py:31: BioSimulatorsWarning: The COMBINE/OMEX archive may be invalid.

  - The SED-ML file at location `simulation.sedml` may be invalid.

    - Output `__repeated_task_report` may be invalid.

      - Some simulation tools will not be able to generate this output because it uses data from repeated tasks. Output for repeated tasks is an experimental feature of SED-ML, which is not officially supported.

  warnings.warn(termcolor.colored(message, Colors.warning.value), category)

Archive contains 1 SED-ML documents with 1 models, 1 simulations, 3 tasks, 2 reports, and 0 plots:

  simulation.sedml:

    Tasks (3):

      __repeated_task_0

      __repeated_task_1

      task

    Reports (2):

      __repeated_task_report: 1 data sets

      task_report: 1 data sets

Executing SED-ML file 1: simulation.sedml ...

Bundling outputs ...

Cleaning up ...

============= SUMMARY =============

Executed 1 SED documents:

  SED documents (1):

    Succeeded: 1

    Skipped: 0

    Failed: 0

  Tasks (3):

    Succeeded: 3

    Skipped: 0

    Failed: 0

  Outputs (2):

    Succeeded: 2

    Skipped: 0

    Failed: 0

sedml.SimulatorSupportsRepeatedTasksWithSubTasksOfMixedTypes (1847.6 s)

Test that a simulator supports repeated tasks whose sub-tasks have mixed types. Also tests that sub-types executed in order of the values of their order attributes and that reports of the results of repeated tasks handle sub-tasks to produce results of different shapes.
Reason for skip:
The image 'ghcr.io/biosimulators/biosimulators_rbapy/rbapy:1.0.2' could not execute the archive:

  [Errno 1] Operation not permitted

Log:
/usr/local/lib/python3.9/site-packages/biosimulators_utils/warnings.py:31: BioSimulatorsWarning: COMBINE/OMEX archive may be invalid.

  - The manifest does not include its parent COMBINE/OMEX archive. Manifests should include their parent COMBINE/OMEX archives.

  warnings.warn(termcolor.colored(message, Colors.warning.value), category)

/usr/local/lib/python3.9/site-packages/biosimulators_utils/warnings.py:31: BioSimulatorsWarning: The SED document is potentially incorrect.

  - Task `__repeated_task_1` may be invalid.

    - The outputs of the sub-tasks have different shapes.

  - Output `__repeated_task_report` may be invalid.

    - Some simulation tools will not be able to generate this output because it uses data from repeated tasks. Output for repeated tasks is an experimental feature of SED-ML, which is not officially supported.

  warnings.warn(termcolor.colored(message, Colors.warning.value), category)

/usr/local/lib/python3.9/site-packages/biosimulators_utils/warnings.py:31: BioSimulatorsWarning: The COMBINE/OMEX archive may be invalid.

  - The SED-ML file at location `simulation.sedml` may be invalid.

    - Task `__repeated_task_1` may be invalid.

      - The outputs of the sub-tasks have different shapes.

    - Output `__repeated_task_report` may be invalid.

      - Some simulation tools will not be able to generate this output because it uses data from repeated tasks. Output for repeated tasks is an experimental feature of SED-ML, which is not officially supported.

  warnings.warn(termcolor.colored(message, Colors.warning.value), category)

Archive contains 1 SED-ML documents with 1 models, 1 simulations, 3 tasks, 2 reports, and 0 plots:

  simulation.sedml:

    Tasks (3):

      __repeated_task_0

      __repeated_task_1

      task

    Reports (2):

      __repeated_task_report: 1 data sets

      task_report: 1 data sets

Executing SED-ML file 1: simulation.sedml ...

Bundling outputs ...

Cleaning up ...

============= SUMMARY =============

Executed 1 SED documents:

  SED documents (1):

    Succeeded: 1

    Skipped: 0

    Failed: 0

  Tasks (3):

    Succeeded: 3

    Skipped: 0

    Failed: 0

  Outputs (2):

    Succeeded: 2

    Skipped: 0

    Failed: 0

sedml.SimulatorSupportsSubstitutingAlgorithms (3.6 s)

Check that a simulator can substitute algorithms that it doesn't implement with similar algorithms when the algorithm substitution policy is less restrictive than :obj:AlgorithmSubstitutionPolicy.SAME_METHOD. Also check that a simulator ignores unsupported algorithm parameters when the algorithm substitution policy is less restrictive than :obj:AlgorithmSubstitutionPolicy.NONE.
Reason for skip:
Algorithm substitution for "Resource Balance Analysis" (http://www.biomodels.net/kisao/KISAO#KISAO_0000669) for policy SIMILAR_VARIABLES is not supported.

Log: None

sedml.SimulatorSupportsUniformTimeCoursesWithNonZeroInitialTimes (3.4 s)

Test that a simulator supports multiple time courses with non-zero initial times
Reason for skip:
No curated COMBINE/OMEX archives are available to generate archives for testing

Log: None

sedml.SimulatorSupportsUniformTimeCoursesWithNonZeroOutputStartTimes (3.6 s)

Test that a simulator supports time courses with non-zero output start times
Reason for skip:
No curated COMBINE/OMEX archives are available to generate archives for testing

Log: None

The image for your simulator is valid!

Your submission was committed to the BioSimulators registry. Thank you!
Future submissions of subsequent versions of rbapy to the BioSimulators registry will be automatically validated. These submissions will not require manual review by the BioSimulators Team.


Add Uint8Array support in @types/pbkdf2

In https://github.com/crypto-browserify/pbkdf2/pull/81, Uint8Array support was added to the npm package pbkdf2. Unfortunately we cannot use it yet because the new type is not available in @types/pbkdf2.
So we should create a PR to DefinitelyTyped to generalize the input types for password and salt.
In theory the types should be the same as in https://nodejs.org/api/crypto.html#crypto_crypto_pbkdf2_password_salt_iterations_keylen_digest_callback and https://nodejs.org/api/crypto.html#crypto_crypto_pbkdf2sync_password_salt_iterations_keylen_digest, but the mapping to TypeScript types might be a bit tricky. As far as I can see, the only relevant input types are string | Buffer | Uint8Array.
If this is done, we can remove the Buffers from
  // convert pbkdf2's calllback interface to Promise interface
  private static async pbkdf2(
    secret: Uint8Array,
    salt: Uint8Array,
    iterations: number,
    keylen: number,
    digest: string,
  ): Promise<Uint8Array> {
    return new Promise<any>((resolve, reject) => {
      // TODO: Patch @types/pbkdf2 to allow Uint8Array as secret and salt argument
      pbkdf2(Buffer.from(secret), Buffer.from(salt), iterations, keylen, digest, (err, derivedKey) => {
        if (err) {
          reject(err);
        } else {
          resolve(new Uint8Array(derivedKey));
        }
      });
    });
  }

https://github.com/DefinitelyTyped/DefinitelyTyped/pull/45933

PR was merged. I think we can use the new types now.


how to do this?

your work is great! I also get nice video.
https://github.com/s9roll7/animatediff-cli-prompt-travel/assets/21111758/11bc2cc6-1d27-4fd8-8e5b-be5abe8a73f3
however, how do you get this?

How to do this?

How to do this?

this one, very close with input img.

Numbered from left to right.
1.prompt + lora
2.prompt + lora + IP-Adapter(scale 0.5)
3.prompt + lora + IP-Adapter Plus(scale 0.5)
4.prompt + lora + Controlnet Reference Only(style_fidelity 0)

could you plz a little more detail about that?  say, what prompt stuffs.


todo: upgrade to Fresh 1.6

SaaSKit needs to be upgraded to Fresh 1.6, which was just released. We should also switch from using Twind to Tailwind CSS (guide here). Once this is done, I'll publish a new minor version of SaaSKit.

Hi. Why will you change from twind to tailwind?
I lost track of SassKit a little 🥺

Hi @gabobaxx, give this and this a read. I think they should answer your questions 🙂


Permissions-Policy header

I can't find anything about this.  Not in w3c or MDN docs.  Can you elaborate?

It's for this: https://github.com/WICG/floc/blob/main/README.md#opting-out-of-computation

I don't recall if these changes will deploy automatically.  I'll make sure it gets done.


What if the user forgot pincode?

I wonder what if the user has forgotten the pin code. The app is locked forever. I've searched all of the available parameters, I've your code and there was nothing much I can do. Finally, my walkaround was to use the QUIT button on the locked screen to remove the pin code. I changed the text of the Quit button to "Forget pin code?". And I set the callback function to display a confirm dialog to clean up all the local storage data. One may argue that it's not good to clean up data. It's not a right or wrong situation. It's just what you want. I choose losing data than locking the users forever and the app turns to be useless. They gonna remove the app.
I hope you would look into the issue and standardize the process.

@anhnch
You can use deleteUserPinCode
import { deleteUserPinCode } from '@haskkor/react-native-pincode';

const resetPinCode = async () => {
  await deleteUserPinCode();
}

<Text onPress={resetPinCode}>reset pincode</Text>

Also you can open enter pin code page again when the user forgot pin code. The user can enter new password.
use status="enter" props with PINCode component.

@anhnch
You can use deleteUserPinCode
import { deleteUserPinCode } from '@haskkor/react-native-pincode';

const resetPinCode = async () => {
  await deleteUserPinCode();
}

<Text onPress={resetPinCode}>reset pincode</Text>

Also you can open enter pin code page again when the user forgot pin code. The user can enter new password.
use status="enter" props with PINCode component.

@cagataykapuagasi i mean the pincode component is meant to prevent unauthorized access right? When the user opens up the app, the enter screen blocks and asks him to enter the code to access. There's nothing else the user can do if he forgot the code. So, at the "enter" screen, there should be a link/button at the bottom to navigate to the forgot screen. Once the fogot flow is finished. You allow accessing the app features.

Hey!
In our apps we handle this outside of the component.
If that's something you need could you please open a PR? We will not likely have time to work on this soon.

I've seen this pattern with other apps:

attempt pin 3 times incorrectly, delete pin automatically
log user out automatically
when user logs back in, ask them to set pin again

Makes sense to me b/c it still requires user to log in w/ password, to set the pin.
Thoughts?

I created another one based on this package to reset the pin. You can log out/delete personal data when the event occurs.


Print test reports in the sbt test-agent

Bloop writes a final test report at the end of the scalaTestSuites execution:

The sbt test-agent should print a similar test report. The current report is:

Maybe we can use one of the default sbt test listener to do so.

Some inputs to work on this issue.
The test suite summary is built here
We can print it using listener.out.
A test that it is correctly printed out can be added in one of the scripted test, for instance this one, using the Outputed step event.


Issues customizing theme

Hey @cschroeter !
Continuing on the topic of customizing themes, I started venturing into customizing the park-ui/panda theme using the colors of my project.
The problem is that when I use createPreset({ accentColor: 'myCustomColor' }) for example, typescript complains that I can only use the original color names from PandaCSS. Is this correct?
I then tried createPreset({ accentColor: 'blue' }) and this works, but only if I use the original blue color palette from Panda.
If I try to change the blue palette from Panda then it stops working and I get black instead of blue.
Ideally I'd like to have a custom color palette (In my case I named it "enterprise") and set that as the accentColor for park-ui. But if that doesn't work I'd be ok with overriding the blue palette from panda.
Here's my code:
panda.config.ts:
import { createPreset } from '@park-ui/panda-preset'

import beesideTheme from '@/theme'

export default defineConfig({
    // Whether to use css reset
    preflight: true,

    theme: {
      extend: {
        tokens: {
          ...beesideTheme
        }
      }
    },

    presets: [
      '@pandacss/preset-base',
      createPreset({
        accentColor: 'enterprise',
        grayColor: 'sand',
        borderRadius: 'md'
      }),
    ],

    // Where to look for your css declarations
    include: ["./src/components/**/*.{ts,tsx,js,jsx}", "./src/app/**/*.{ts,tsx,js,jsx}"],

    // Files to exclude
    exclude: [],

    jsxFramework: 'react',

    // The output directory for your css system
    outdir: "styled-system",

})

theme file (imported on panda config):
import colors from './colors'

export const theme = {
  colors: { ...colors }
}

export default theme

colors file (used on the theme file):
export const enterprise = {
  value: '#27399A',
  25: { value: '#F8F9FF' },
  50: { value: '#F4F6FF' },
  100: { value: '#EFF2FE' },
  200: { value: '#DBE0FB' },
  300: { value: '#AAB6F4' },
  400: { value: '#6A7EE8' },
  500: { value: '#27399A' },
  600: { value: '#172573' },
  700: { value: '#101B58' },
  800: { value: '#0C1547' },
  900: { value: '#040924' }
}

export const colors = {
  enterprise: {...enterprise},
  primary: {...enterprise},
  blue: {...enterprise}
}

export default colors

I found another bug related to this...
If I add the park-ui preset like this:
createPreset({
        accentColor: 'blue',
        grayColor: 'sand',
        borderRadius: 'md'
      }),

Then I can't access "nested" tokens anymore. If I do <Text color="blue.300"> while using the park-ui preset, it doesn't work. But <Text color="blue"> works (it applies blue 500).
If I remove the park-ui preset, both color="blue" and color="blue.300" works.
Any ideas?

Any news on this?
I'm working on a new commercial app and wanted to use park-ui, but this is a huge blocker 🙁
cc @cschroeter

@kaumac
Sorry for the delayed response. I'm kinda burried in the Ark UI 1.0 launch. The good news is that what you like to achieve is possible.
With @park-ui/panda-prest 0.19.0 we start using the radix colors system. Those colors work a bit different than the Panda / Tailwind default colors. So instead having colors ranging from 50 to  950 instead they gro from 1 to 12. You can read more about it here https://www.radix-ui.com/colors
The cool part is that for example blue.5 is already an semantic token matching in light to #C2E5FF and in dark to #004074
So this line <Text color="blue.5">I'm a bluish text</Text> will change its color depneding on the color mode. So in short to add a new color that follow this spec you will need to do sth like:
export const indigo = {
  1: { value: { base: '{colors.indigo.light.1}', _dark: '{colors.indigo.dark.1}' } },
  // ...
  12: {}
 }

But before you start sweating the cool part about Park UI it does not directly use this colors. So you don't really need to provide a full blown accent color instead you can simply override the main semantic tokens:
import { defineConfig } from '@pandacss/dev'

export default defineConfig({
  // ...
  theme: {
    extend: {
      tokens: {
        colors: {
          coral: {
            50: { value: '#fef2ea' },
            // etc..
          },
        },
      },
      semanticTokens: {
        colors: {
          accent: {
            default: { value: { base: '{colors.coral.500}', _dark: '{colors.coral.500}' } },
            emphasized: { value: { base: '{colors.coral.600}', _dark: '{colors.coral.600}' } },
            fg: { value: { base: '{colors.white}', _dark: '{colors.white}' } },
          },
          fg: {
            default: {
              value: { base: '{colors.grayPalette.900}', _dark: '{colors.grayPalette.100}' },
            },
          },
          border: {
            accent: { value: { base: '{colors.coral.500}', _dark: '{colors.coral.500}' } },
          },
        },
      },
    },
  },
})

Thanks for taking the time to reply @cschroeter , and I totally get it that there's a lot going on with the panda/ark ecosystem right now so no worries!
I'll do a fresh install and try it using the radix color system.
I have 3 new questions regarding this:

Do I understand correctly that the panda color system doesn't work anymore altogether when using park-ui? Or will the panda color palette still work if I use the radix color names?

If I want to extend the theme and add my own colors, do I do it on panda.config.ts using the extend option and use the radix naming scheme? Or is there a different way to add new colors? Because I couldn't use the new colors when using park-ui.

Is there a documentation somewhere for the semantic tokens used by park-ui?

Thanks again for the help!

Okay, so after playing around with this for a bit, I now understand that the panda colors are not used anymore and those are replaced with Radix colors (which is nice by the way, I'll use that convention for my project colors).
Couldn't find a place where I can see the names of the semantic tokens so that I can customize them though. For now I'm inspecting the elements and checking their css variable names to use as a reference, but a documentation would be awesome.

I have extended the documentations quite extensively. Feel free to create a new issue if something is unclear.

Fantastic work @cschroeter! I'm sure it'll be super useful for new users of park-ui. Thanks again for the hard work! 😄


[iOS] Back arrow and Menu icon are very difficult to click

WTR:

Add an account
Click Wallet icon
Try to click back arrow and menu item icons
Result: For iPhone versions >= X Back arrow and Menu item icons are very difficult to click.

@cryptoBeliever it's fixed for iOS.

@cryptoBeliever it's fixed for iOS.

It's OK

It's OK


Configure fail when install from source code

I Installed with following settings: centOS 7, CUDA 7.5, cudnn v4, python 2.7
After I filling in the configurations using
./configure
and I got this error
ERROR: /home/[...]/external/bazel_tools/src/tools/android/java/com/google/devtools/build/android/dexer/BUILD:3:1: no such target '//external:android/dx_jar_import': target 'android/dx_jar_import' not declared in package 'external' defined by /home/[...]/tensorflow/WORKSPACE and referenced by '@bazel_tools//src/tools/android/java/com/google/devtools/build/android/dexer:dexer'.
ERROR: Evaluation of query "deps((//... union @bazel_tools//tools/jdk:toolchain))" failed: errors were encountered while computing transitive closure.
Configuration finished

When I tried with v0.9 there is no such problem. And I don't need those android features.
Anybody encountered the same problem? How can I fix this issue?

+1 got the same problem when build it on centos

I don't know whether something wrong with the java environment

Guess what, using bazel with version 3.1.0 can solve the problem. Bazel team should really think of their downward compatibility


Amend Protocol to Always Require Fully-Canonical Signatures

Summary
Despite being mostly fixed in 2014, transaction malleability is still theoretically a problem today, because you have to opt in to protection from it by setting tfFullyCanonicalSig. We can fix this with an amendment that makes non-fully-canonical signatures invalid regardless of transaction flags.
Background
The tfFullyCanonicalSig flag was created to allow backwards compatibility with transactions signed with old signing logic that didn't create fully-canonical signatures. This design leaves all transactions valid, but makes full protection from transaction malleability (sort-of) opt-in.
As far as I know, every tool in use today generates fully-canonical signatures, but malicious actors could still convert transactions to non-fully-canonical signatures, resulting in a different hash, if those transactions don't have tfFullyCanonicalSig enabled. This could be used to trick naive transaction submission logic into sending the same payment multiple times.
By default, rippled's sign method supplies a Flags field with tfFullyCanonicalSig enabled if you don't provide a Flags field. However, tfFullyCanonicalSig won't be enabled in the following cases:

If you use ripple-lib's signing functionality without "preparing" the transaction first (see also: ripple-lib PR#1028)
If you multi-sign using rippled's sign_for method and didn't explicitly set the tfFullyCanonicalFlag
If you use rippled's sign method but explicitly supply a Flags field that doesn't include tfFullyCanonicalSig—for example, if you're using another flag, and you don't bitwise-OR it with the tfFullyCanonicalSig value.
If you're using your own signing logic that doesn't supply tfFullyCanonicalSig.

This state of affairs requires users to take extra steps to protect themselves against transaction malleability in some cases, and leaves many transactions vulnerable because users forgot or misunderstood the necessary steps.
Proposed Solution
Create an amendment named RequireFullyCanonicalSig (or something along those lines). With this amendment enabled, non-fully-canonical transaction signatures are always considered invalid regardless of whether tfFullyCanonicalSig is specified. (Basically, transactions are treated like tfFullyCanonicalSig is enabled even if it isn't.)
Compatibility with Legacy Transactions
If there are any tools today that create non-fully-canonical signatures by default, those tools break. Both rippled (v0.24.0?) and ripple-lib (v0.9.0?) have created only fully-canonical signatures since 2014. I'm not familiar with any tools that do not create fully-canonical signatures.
Any transactions that were signed in a non-fully-canonical way are no longer valid and cannot be successfully submitted as-is. These could be transactions that were signed in or before early 2014 and put "in cold storage" indefinitely without being submitted. It is not clear if there are any such transactions in existence or how many such transactions would still be valid under current transaction processing rules because of other breaking changes.
If necessary, we could publish a tool that can convert non-fully-canonical signatures to fully-canonical signatures. Basically, this tool would take advantage of the malleability of those transactions to make fully-canonical variants of them without needing anything beyond the signed blob of the transaction itself. This would of course result in a slightly different blob and a different hash, but anyone who has such transactions in cold storage could use this tool to convert them to fully-canonical signatures.
It would probably be advisable not to publish the tool before the amendment became enabled, since it basically would provide sample code for several steps of the existing exploit against transactions not using tfFullyCanonicalSig.
However, it remains to be seen whether such a tool is necessary at all since the existence of any such cold-storage non-fully-canonical transactions is hypothetical.

This has been merged as ec137044a014530263cd3309d81643a5a3c1fdab and the RequireFullyCanonicalSig amendment was activated with transaction 94D8B158E948148B949CC3C35DD5DC4791D799E1FD5D3CE0E570160EDEF947D3 on the mainnet.


Verify server accessibility after GAE deployment

GAE deployment is flaky and service may not be accessible right after deployment. When I ran google-cloud-gemserver create, it creates a key for me right after deployment, but the key looks like this:
$ cat ~/.gem/credentials
:master-gemserver-key:  Server Error

The server encountered a temporary error and could not complete your request.
Please try again in 30 seconds.

The gem should

Verify GAE deployment is accessible before proceeding with other commands.
Verify key is valid before setting it into ~/.gem/credentials file.

You might consider verifying several times over some short length of time (maybe 10-20 seconds) to see if it comes alive in that time, before giving up.


A shot at #35

Hey @golbin, here's something for the configurable key mappings, what do you think about it? Should I go ahead in this direction? It's not something you should pull right now, but I wanted to ask your opinion before proceeding.
Things changed: turned the JSON files of view styles into real JS files and we call them with config passed, a JSON containing keyboard mappings. We also use that config in controllers to map keys to specific methods. Users can choose between predefined vi-style and mc-style key mapping.
Custom key mapping is TBD.

@jzsfkzm It's Great! Your patch is almost same as my plan.
But one more feature is needed that is to make using user's own config file. I mean, user can use config file like "~/.git-commander.json" and it contain whole key settings like your vi.json or mc.json.
Could you plz make this? :smiley:

Sure, that's my plan! Great to hear back, I'll go ahead with this then and include a solution for user-defined custom keys mappings.

Cool! :+1:

Hello, @golbin, I think I just finished this for now. This is how it works:
There are two config files in config/key, mc.json and vi.json. Both files are containing the same JSON data except they point to different key combos.
One of these files are read as key config. It's vi.json by default now.
If you want to use mc.json, you'll need a file under ~/.config/git-commander/config.json containing a key called keySet, with the value mc.
Also, you can place a key called keys in this file, cloning parts or the whole of vi/mc.json and setting your own keys.
If you think it's ok, I'll add these to the README.md.

@jzsfkzm Great! Please update the README.md
And what do you think about you'll be a contributor of this project? :smiley: If you want, please make a contributor section in the README.md and I'll add you as a collaborator of this repo.

@golbin I just added the docs to README.md
I would happily help as a collaborator in the repo, but not sure if a Contributors block is needed in the README.md - as I see, anyone changing even one line of the code is a contributor, and all their work is visible in the Git history. I wouldn't mind maintaining such an information manually. Anyway, it's up to you.

@jzsfkzm Thanks for the update.
And sometimes when I have issues for some projects and need a fast feedback and if there is no contributor section, I'm in a deadlock because I don't know who can manage the repo.
But the contributor section is not required as you said. And for now, we don't need to have the section. So I'll just add you as a collaborator. Thanks! :smile:

@jzsfkzm one more thing, do you have a account on npmjs.com? I'll add you as a collaborator to npmjs too.


Pin dependencies in example project?

Hey, I am trying the example project setup and the dependencies don't have pinned versions:
category-encoders
coverage
datetime
Flask
gunicorn
hermione-ml
matplotlib
mlflow
mlxtend
numpy
pandas
plotly
pytest
seaborn
scikit-learn
scipy
statsmodels
tqdm
yellowbrick
vega_datasets
altair
pandas_profiling
streamlit_pandas_profiling
interpret-community
lime
lightgbm
great-expectations
tensorflow
umap-learn
keras
pingouin==0.4.0
mpmath

I have quite a few conflicts with each other when trying to install on python 3.7. Perhaps pinning them could be useful?

Hello,
first, thanks for your question!
we prefer to leave as non-fixed versions to always download as current versions of projects.


TFRobot: Add any indication that bot is working

Is your feature request related to a problem? Please describe
I waited for more than 3 minutes and didn't know if the bot was working or what was happening.

Describe the solution you'd like
Maybe we should add a loading status or print some logs for the user to keep him updated with what is happening.
Or, if not possible, at least tell him that this may take a few minutes.

More info would be displayed using the debug flag, the message Running deployment Node group=group_a is indicating that the deployer is running, I think it's informing that the deployment is running


Segfault on dtNavMesh::getPolyHeight

CARLA version: dev
Platform/OS: Linux
Problem you have experienced:
On consecutive map loads for and then adding a few walker controllers leads to a segfault. I have observed that this specifically happens when loading map Town10HD and then loading Town02. The trace is below
#0  0x00007ffeda750e33 in dtNavMesh::getPolyHeight(dtMeshTile const*, dtPoly const*, float const*, float*) const () from /home/aditya/.local/lib/python3.6/site-packages/carla/libcarla.cpython-36m-x86_64-linux-gnu.so
#1  0x00007ffeda75145e in dtNavMesh::closestPointOnPoly(unsigned int, float const*, float*, bool*) const () from /home/aditya/.local/lib/python3.6/site-packages/carla/libcarla.cpython-36m-x86_64-linux-gnu.so
#2  0x00007ffeda7562c6 in dtNavMeshQuery::closestPointOnPoly(unsigned int, float const*, float*, bool*) const () from /home/aditya/.local/lib/python3.6/site-packages/carla/libcarla.cpython-36m-x86_64-linux-gnu.so
#3  0x00007ffeda76065e in dtFindNearestPolyQuery::process(dtMeshTile const*, dtPoly**, unsigned int*, int) () from /home/aditya/.local/lib/python3.6/site-packages/carla/libcarla.cpython-36m-x86_64-linux-gnu.so
#4  0x00007ffeda75729d in dtNavMeshQuery::queryPolygonsInTile(dtMeshTile const*, float const*, float const*, dtQueryFilter const*, dtPolyQuery*) const () from /home/aditya/.local/lib/python3.6/site-packages/carla/libcarla.cpython-36m-x86_64-linux-gnu.so
#5  0x00007ffeda756a25 in dtNavMeshQuery::queryPolygons(float const*, float const*, dtQueryFilter const*, dtPolyQuery*) const () from /home/aditya/.local/lib/python3.6/site-packages/carla/libcarla.cpython-36m-x86_64-linux-gnu.so
#6  0x00007ffeda75670c in dtNavMeshQuery::findNearestPoly(float const*, float const*, dtQueryFilter const*, unsigned int*, float*) const () from /home/aditya/.local/lib/python3.6/site-packages/carla/libcarla.cpython-36m-x86_64-linux-gnu.so
#7  0x00007ffeda5b38b8 in carla::nav::Navigation::GetAgentRoute (this=0x221fc50, id=<optimized out>, from=..., to=..., path=std::vector of length 0, capacity 0, area=std::vector of length 0, capacity 0) at ../../LibCarla/source/carla/nav/Navigation.cpp:409
#8  0x00007ffeda5b7e3b in carla::nav::WalkerManager::SetWalkerRoute (this=<optimized out>, id=822, to=...) at ../../LibCarla/source/carla/nav/WalkerManager.cpp:133
#9  0x00007ffeda5b7c8f in carla::nav::WalkerManager::SetWalkerRoute (this=<optimized out>, id=<optimized out>) at ../../LibCarla/source/carla/nav/WalkerManager.cpp:107
#10 carla::nav::WalkerManager::SetWalkerNextPoint (this=0x221fdb0, id=822) at ../../LibCarla/source/carla/nav/WalkerManager.cpp:195
#11 0x00007ffeda5b7ffa in carla::nav::WalkerManager::SetWalkerRoute (this=<optimized out>, id=822, to=...) at ../../LibCarla/source/carla/nav/WalkerManager.cpp:162
#12 0x00007ffeda5b7c8f in carla::nav::WalkerManager::SetWalkerRoute (this=<optimized out>, id=<optimized out>) at ../../LibCarla/source/carla/nav/WalkerManager.cpp:107
#13 carla::nav::WalkerManager::SetWalkerNextPoint (this=0x221fdb0, id=822) at ../../LibCarla/source/carla/nav/WalkerManager.cpp:195
#14 0x00007ffeda5b7ffa in carla::nav::WalkerManager::SetWalkerRoute (this=<optimized out>, id=822, to=...) at ../../LibCarla/source/carla/nav/WalkerManager.cpp:162
#15 0x00007ffeda5b7c8f in carla::nav::WalkerManager::SetWalkerRoute (this=<optimized out>, id=<optimized out>) at ../../LibCarla/source/carla/nav/WalkerManager.cpp:107
#16 carla::nav::WalkerManager::SetWalkerNextPoint (this=0x221fdb0, id=822) at ../../LibCarla/source/carla/nav/WalkerManager.cpp:195
#17 0x00007ffeda5b7ffa in carla::nav::WalkerManager::SetWalkerRoute (this=<optimized out>, id=822, to=...) at ../../LibCarla/source/carla/nav/WalkerManager.cpp:162

Steps to reproduce:
Load Town10 and start a simulation with 100 walkers. Then load Town02 and then start a simulation with 100 walkers. Do this multiple times and eventually you will end up getting a  segfault.
Other information (documentation you consulted, workarounds you tried):
I reproduced this on another machine so hardware doesn't seem to be the issue.

Hi  @truncs,
Hi encountered the same error a few weeks ago.
In my case, the problem was that the z coordinate of the walker position was negative, and then when I did controller.go_to_location(.) that error was thrown.
My workaround was before calling controller.go_to_location(.), I check the z coordinate of the walker, and if it is negative I don't call the method controller.go_to_location.
It is not a perfect solution, but at least it avoids the error.

I had posted this comment on #4350, but I think it may be related to this issue instead. I have not tried compiling from source to find where the segfault occurs in the C++ code. However, the Z coordinate trick does not fix the issue - I am finding segfaults even when the Z index is not negative. In one segfaulting run, these are the values that lead to segfault:
walker location: Location(x=400.612518, y=206.038651, z=1.974510)
walker controller location: Location(x=400.612518, y=206.038651, z=1.974510)
going to location: Location(x=6.309162, y=220.257812, z=0.000000)

I had posted this comment on #4350, but I think it may be related to this issue instead. I have not tried compiling from source to find where the segfault occurs in the C++ code. However, the Z coordinate trick does not fix the issue - I am finding segfaults even when the Z index is not negative. In one segfaulting run, these are the values that lead to segfault:
walker location: Location(x=400.612518, y=206.038651, z=1.974510)
walker controller location: Location(x=400.612518, y=206.038651, z=1.974510)
going to location: Location(x=6.309162, y=220.257812, z=0.000000)

Edit: when I am seeing this issue does not appear to have any basis with spawning walkers in different maps. Even if I start with a certain town loaded and reload that same town, it still hits the segfault.

Were you able to find a way around this?

Were you able to find a way around this?

I have not found a way to solve this other than trying to avoid the segfault. I did not continue investigating.

Were you able to find a way around this?

I have not found a way to solve this other than trying to avoid the segfault. I did not continue investigating.

Do you mind expanding on what you mean by "avoiding the segfault". Do you not use the walker controller anymore?

Yes, I have not used the walker controller in any meaningful way since I posted here, at least not in general. I was able to spawn a handful at a time when testing things, but it was not robust enough for me to use long-term so I stopped exploring it and haven't gotten back around to it yet.
I believe other projects may get around this issue by using ScenarioRunner which has its own separate pedestrian control. I have set up demos of projects that I believe are using this code and have pedestrians walking short distances, though I have not inspected the code to see how they are accomplishing that.

Oh okay, that makes sense. I am using it for RL and the environment continuously seg faults which is getting pretty annoying so I have been investigating but looks like I might have to use ScenarioRunner.
Thanks for the suggestion!


use ellipsis to truncate breadcrumbs

WIP to address #1568.  Doesn't work.  The below proof-of-concept with the same tag structure / depth of nesting does work, so I'm a bit at a loss as to where the crucial difference is.
If anyone finds it helpful, the below HTML reconstructs the basic node structure of our theme. As written it doesn't work, but seems to work fine as long as you remove display: flex from any one of the outer flex nodes (anything parent to the ul node).

0123456789

ABCDE

                                                        abcdefg hijklmnop qrstuv wxyz

This is fantastic, @drammock - thank you! My trick for checking is to inspect the breadcrumb node in questions and then paste its own content multiple times in there.

I'm setting this up locally right now to play with it, specifically I'm going to try to apply the logic to the breadcrumb-item class directly, without having to wrap inside an ellipsis span. But I'm a front-end impostor, at best, so we might have to cha-cha and back and forth by trying this and waiting to hear back about under which situation it breaks.

It is working as expected on my side could you describe what is preventing you from making this PR ready to merge ?

It is working as expected on my side could you describe what is preventing you from making this PR ready to merge ?

I haven't thoroughly tested that things don't look weird under circumstances that don't occur in our own docs / tests. Specifically (as I mentioned above) I'm worried about user sites that put multiple items into article_header_start (we use theme default which is only 1 item, the breadcrumbs).  As I write this, I realize that if someone put the breadcrumbs somewhere else, then the ellipsis overflow might not work (putting breadcrumbs elsewhere is also not tested AFAIK).

(this might get closed by #1861 anyway, but it was easy to fix conflict)


warning using azure blob storage

Using wal-e 0.9 on ubuntu 14.04.
Here is the output of backup-list command to show the issue:
wal_e.main   INFO     MSG: starting WAL-E
        DETAIL: The subcommand is "backup-list".
        STRUCTURED: time=2016-03-11T16:57:21.657109-00 pid=2463
name	last_modified	expanded_size_bytes	wal_segment_backup_start	wal_segment_offset_backup_start	wal_segment_backup_stop	wal_segment_offset_backup_stop
requests.packages.urllib3.connectionpool INFO     Starting new HTTPS connection (1): dsstoragelts.blob.core.windows.net
/usr/local/lib/python2.7/dist-packages/requests/packages/urllib3/util/ssl_.py:315: SNIMissingWarning: An HTTPS request has been made, but the SNI (Subject Name Indication) extension to TLS is not available on this platform. This may cause the server to present an incorrect TLS certificate, which can cause validation failures. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#snimissingwarning.
  SNIMissingWarning
/usr/local/lib/python2.7/dist-packages/requests/packages/urllib3/util/ssl_.py:120: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning

https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning
I followed the steps under OpenSSL / PyOpenSSL. (For libffi: sudo apt install libffi-dev , I also had to install cryptography manually). This fixed the issue for me.

@wirehell, is there something feasible that WAL-E could do better here, or should I close things out?

I will take a look at it this week.

Are you using a version of Python < 2.7.9?  If so, it's an easy fix (I had the same issue).  Here is the urllib3 doc on the matter.

Though, given new WAL-Es are projected to be Python3, perhaps it would suffice to show that this bug is obsolete as of v1.0.0a1


Have to_openmm convert to base units if conversion would otherwise fail

Description
Supersedes #30, closes #29
Todos
Notable points that this PR has either accomplished or will accomplish.

[x] Call to_base_units on quantities that cannot be directly converted to OpenMM units
[x] Tests for the above behaviour and possible regressions for other units
[x] Support black's formatting in flake8 tests
[x] Documentation

Questions
None so far
Status

[x] Ready to go

Codecov Report

Merging #32 (0f8c1f0) into main (4a9ddc4) will decrease coverage by 62.35%.
The diff coverage is 0.00%.


Change thin film IOR default

From 1.5 to 1.4.
As this won't make much difference to the look in implementations that ignore the adjacent IORs of the film.
But for those that take it into account, this will make the film visible rather than invisible by default (since specular_ior is 1.5 by default, and coat_ior 1.6).

Since MaterialX also depends on the thin-film IOR in rendering, we should make sure this change is reflected in the MaterialX reference implementation as well.

Since MaterialX also depends on the thin-film IOR in rendering, we should make sure this change is reflected in the MaterialX reference implementation as well.

Done in 60f67ef32d7c022daa51ea5e1f554d27c72eacd3


修复系统级 bark 推送铃声 bug

PR Type
What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Other... Please describe:

What is the current behavior?

系统设置 => 通知设置 => BARK推送铃声设置无效
Issue Number: N/A
What is the new behavior?
BARK推送铃声设置修复
Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

👍


Does not compile on GHC 7.10.2, out of date dependencies

Template haskell is 2.10.0 in GHC 7.10.2
gdiff 1.1 is available on Hackage

I don't have the time to fix this. Feel free to send in a pull request

@simonvandel you can consider writing pattern synonyms as an abstraction layer for 7.10 (or vice versa). Also, there are libraries out there (see goldfirere's) which can possibly help.

I will look into this, but I have no experience with template haskell, or advanced haskell, so I can not guarantee a solution.


docs: Include scoop method of installation in README

Hi,
A few days ago in juliaup can be installed using scoop. It was enabled with https://github.com/ScoopInstaller/Main/pull/6210
Personally I been using scoop for a few years already on my personal and my work Windows machines and never had any issue. I prefer scoop over winget for cli tools as it eases the way to manage it and find issues.
Hopefully this helps with #343

Couple of thoughts:

Is there a plan to update the version that is available via scoop when we release new builds? For other platforms we automatically update things as part of the Juliaup release process (https://github.com/JuliaLang/juliaup/blob/main/.github/workflows/release.yml), we should probably do the same for scoop, right?
If we actually have a package manager use the portable builds, we should probably upload them to S3 and then download from there, rather than from GitHub directly, but also see below about other options.
Could this be listed as julia rather than juliaup in the scoop repo? So that the install command is scoop install main/julia. That is what we already have for winget, and given that Juliaup now is the official installer for Julia, I think that would make things much clearer.
Does scoop support MSI or MSIX installers? If so, maybe we should use those instead? They handle more things properly, like modifying PATH, adding start menu items, potentially down the road package identity etc. And they exist and are available at the various official download pages.
I'm happy to mention the scoop option here, but we should not make it the next best option if the Windows Store doesn't work. At the end of the day, the "official" story should be: 1) Windows Store, 2) App installer, 3) MSI, 4) all the other third-party options (which include scoop).

Hi @davidanthoff, thanks for your thoughts

Is there a plan to update the version that is available via scoop when we release new builds? For other platforms we automatically update things as part of the Juliaup release process (main/.github/workflows/release.yml), we should probably do the same for scoop, right?
If we actually have a package manager use the portable builds, we should probably upload them to S3 and then download from there, rather than from GitHub directly, but also see below about other options.

Scoop does update the packages versions manifest automatically through some scheduled process. The new version information can be obtained through different mechanisms, see App Manifest Autoupdate. Currently for Juliaup is configured to get the information from the GitHub Releases, as you can see in the manifest commit history that last week the manifest it was updated to the version 1.17.9.
Related to the autoupdate I decided to download from the GitHub Release directly because they were the only ones that had the version on the name, the links detailed on the README do not have the version information, (ie "https://install.julialang.org/Julia-x64.msi"). I suppose that this could be fixed by changing the Rename Step to copy the files instead of renaming it, in favor of not breaking anything that depends on the names as they are now.

Could this be listed as julia rather than juliaup in the scoop repo? So that the install command is scoop install main/julia. That is what we already have for winget, and given that Juliaup now is the official installer for Julia, I think that would make things much clearer.

I will say that it's possible but it might bring some issues, there has been a julia manifest since 2014 and I suspect that changing it will break other scoop users setups.

Does scoop support MSI or MSIX installers? If so, maybe we should use those instead? They handle more things properly, like modifying PATH, adding start menu items, potentially down the road package identity etc. And they exist and are available at the various official download pages.

Yes, the MSI installer seems to work without any issues. For example, the rust manifest uses it. As mentioned above, the MSI files must be published with the version in their name.

I'm happy to mention the scoop option here, but we should not make it the next best option if the Windows Store doesn't work. At the end of the day, the "official" story should be: 1) Windows Store, 2) App installer, 3) MSI, 4) all the other third-party options (which include scoop).

Of course, I updated the PR to mention the Scoop installation under the Software Repositories section


wrong template

The template may be wrong.
Additional volumes in controller.volumes.extra will result in strange rendering results.
This template: https://github.com/grafana/alloy/blob/62b6fb5f3aeba1cd48e09e9a5d9c01b4b944c801/operations/helm/charts/alloy/templates/containers/_agent.yaml#L82
values
controller:
  volumes:
    extra:
      - name: cluster-config
        configMap:
          name: cluster-config
      - name: sys
        hostPath:
          path: /sys
      - name: proc
        hostPath:
          path: /proc

rendered parts
          volumeMounts:
            - name: config
              mountPath: /etc/alloy
            - name: varlog
              mountPath: /var/log
              readOnly: true
            - name: dockercontainers
              mountPath: /var/lib/docker/containers
              readOnly: true
            -
              mountPath: /cluster-name
              name: cluster-config
              subPath: CLUSTER_NAME
            -
              mountPath: /sys
              name: sys
            -
              mountPath: /proc
              name: proc

So it's just weird, but the syntax is fine...


74AHCT595D alternative?

The part seems to be available @ Mouser only, which I can't purchase from. Is there any more common alternative available?
Thanks

I think this should work.
https://www.digikey.com/product-detail/en/texas-instruments/SN74AHCT595DR/296-26428-2-ND/1567309

I think this should work.
https://www.digikey.com/product-detail/en/texas-instruments/SN74AHCT595DR/296-26428-2-ND/1567309

No, it cant. I tried this one, nothing output in Dir and Step pin. I still can not figure out whats going on.

I think this should work.
https://www.digikey.com/product-detail/en/texas-instruments/SN74AHCT595DR/296-26428-2-ND/1567309

No, it cant. I tried this one, nothing output in Dir and Step pin. I still can not figure out whats going on.

I ordered the SN74AHCT595D from Farnell:
https://de.farnell.com/texas-instruments/sn74ahct595d/logic-8bit-shift-register-16soic/dp/3120848?ost=3120848
But it´s not working.. because they have send me the WRONG PART! Check the marking on the IC itself.. mine says HC166, that is the SN74HC166 and NOT the SN74AHCT595D.


datalad catalog-validate

errors returned as soom as it reads metadata @jsheunis help please -- json looks fine to my eyes but the validator complains :-(
datalad catalog-validate --metadata OpenNeuroPET_phantoms.json
catalog_validate(error): /indirect/openneuropet/DataCatalogue/PublicnEUro/metadata/PET-Phantoms [Expecting property name enclosed in double quotes: line 1 column 20 (char 19)]
catalog_validate(error): /indirect/openneuropet/DataCatalogue/PublicnEUro/metadata/PET-Phantoms [Extra data: line 1 column 10 (char 9)]
catalog_validate(error): /indirect/openneuropet/DataCatalogue/PublicnEUro/metadata/PET-Phantoms [Extra data: line 1 column 16 (char 15)]
catalog_validate(error): /indirect/openneuropet/DataCatalogue/PublicnEUro/metadata/PET-Phantoms [Extra data: line 1 column 15 (char 14)]
catalog_validate(error): /indirect/openneuropet/DataCatalogue/PublicnEUro/metadata/PET-Phantoms [Extra data: line 1 column 20 (char 19)]
catalog_validate(error): /indirect/openneuropet/DataCatalogue/PublicnEUro/metadata/PET-Phantoms [Extra data: line 1 column 8 (char 7)]
catalog_validate(error): /indirect/openneuropet/DataCatalogue/PublicnEUro/metadata/PET-Phantoms [Extra data: line 1 column 8 (char 7)]
catalog_validate(error): /indirect/openneuropet/DataCatalogue/PublicnEUro/metadata/PET-Phantoms [Extra data: line 1 column 13 (char 12)]
catalog_validate(error): /indirect/openneuropet/DataCatalogue/PublicnEUro/metadata/PET-Phantoms [Extra data: line 1 column 12 (char 11)]
catalog_validate(error): /indirect/openneuropet/DataCatalogue/PublicnEUro/metadata/PET-Phantoms [Extra data: line 1 column 11 (char 10)]
[42 similar messages have been suppressed; disable with datalad.ui.suppress-similar-results=off]
action summary:
catalog_validate (error: 52)

The first error looks like it gives an understandable description: Expecting property name enclosed in double quotes. But I haven't seen the rest before, looks like the metadata might contain extra fields that the validator sees as an error.
Is it possible for you to post/share the metadata that you are trying to validate? I.e. the content of the OpenNeuroPET_phantoms.json file?

oh boy I forgot to link to the json .. here https://github.com/Public-nEUro/DataCatalogue/blob/master/metadata/PET-Phantoms/OpenNeuroPET_phantoms.json

The problem is the format in which the metadata comes in. Your example has a json object spread over multiple lines of the file, and the catalog-validate command can take the following formats:

a path to a file containing JSON lines
JSON lines from STDIN
a JSON serialized string.

You can either change the file to a single line, or read it in on the command line and pass the line to catalog-validate. This should also work:
datalad catalog-validate -c . -m '{ "type": "dataset", "title": "OpenNeuroPET Phantoms", "description": "The PET Brain phantoms dataset is curated by OpenNeuroPET. This repository contains source data from PET scanners that need to be converted to nifti format, preferably following BIDS. An issue with ecat and DICOM data is that many tags are not mandatory and many values are not standardized making it difficult to harmonize the outputs of conversion, in particular side car json files. Here we collected many phantoms from different sites and scanners allowing to check the different header tags and values. This also allows validated conversion tools. Such test is performed via the code folder where one use the PET2BIDS library to do the conversion (which depends on dcm2niix for DICOM). Feel free to add to this with your own tool and submit the request to update the dataset.", "dataset_id": "datalad_hash_to_use", "dataset_version": "V1", "doi": "xxxx", "url": "xxxx", "keywords": [ "Positron Emission Tomography", "PET", "Brain", "Source files", "ecat7", "DICOM", "Phantom", "Conversion", "PET2BIDS", "dcm2niix" ], "license": { "name": "CC BY 4.0", "url": "https://creativecommons.org/licenses/by/4.0/" }, "authors": [ { "givenName": "Cyril", "familyName": "Pernet" }, { "givenName": "Sune", "familyName": "Høgild Kelle" }, { "givenName": "Gabriel", "familyName": "Gonzalez-Escamilla" }, { "givenName": "Søren", "familyName": "Baarsgaard Hansen" }, { "givenName": "Maqsood", "familyName": "Yaqub" }, { "givenName": "Murat ", "familyName": "Bilgel" } ], "metadata_sources": { "key_source_map": {}, "sources": [ { "source_name": "OpenNeuroPET", "source_version": "1", "source_parameter": {}, "agent_name": "Cyril Pernet", "agent_email": "" } ] } }'

You will see an error when you run that, but that is because of a different validation issue (I received this error when running your code locally):
[Schema validation failed in LINE 1:

{} is not of type 'number'

Failed validating 'type' in schema['allOf'][0]['then']['properties']['metadata_sources']['properties']['sources']['items']['properties']['source_time']:
    {'description': 'The time (since epoch) when this source was used to '
                    'provide the applicable metadata',
     'title': 'Source time',
     'type': 'number'}

On instance['metadata_sources']['sources'][0]['source_time']:
    {}]

The issue here is that source_time should be a number and not {}. You can solve it in this case by removing the field from it's containing object, since it is not a required field.

Hi StephanThank you so much for helping. I'll get back to it tomorrow (fully booked today 😔). Just a quick feedback from the documentation. I did read 'a path to a file containing JSON lines' but I understood this as give the path to a file. Does it means to a serialised json and not indented? I think you should state that so it is explicit. Where it is confusing is that the exemple is indented (like my file) so I expected it would work (fair enough I did not try your exemple...). Maybe an exemple of each option would make it easier. (Happy to PR those if you want, since I have to try and learning it)Again, thx man - it's gonna be great to have a EU repo with datalad and datacat! Sent from my phone-------- Original message --------From: Stephan Heunis @.>Date: Mon, 22 Apr 2024, 18.17To: Public-nEUro/DataCatalogue @.>Cc: Cyril Pernet @.>, Author @.>Subject: Re: [Public-nEUro/DataCatalogue] datalad catalog-validate (Issue #1)
The problem is the format in which the metadata comes in. Your example has a json object spread over multiple lines of the file, and the catalog-validate command can take the following formats:
a path to a file containing JSON linesJSON lines from STDINa JSON serialized string.
You can either change the file to a single line, or read it in on the command line and pass the line to catalog-validate. This should also work:
datalad catalog-validate -c . -m '{ "type": "dataset", "title": "OpenNeuroPET Phantoms", "description": "The PET Brain phantoms dataset is curated by OpenNeuroPET. This repository contains source data from PET scanners that need to be converted to nifti format, preferably following BIDS. An issue with ecat and DICOM data is that many tags are not mandatory and many values are not standardized making it difficult to harmonize the outputs of conversion, in particular side car json files. Here we collected many phantoms from different sites and scanners allowing to check the different header tags and values. This also allows validated conversion tools. Such test is performed via the code folder where one use the PET2BIDS library to do the conversion (which depends on dcm2niix for DICOM). Feel free to add to this with your own tool and submit the request to update the dataset.", "dataset_id": "datalad_hash_to_use", "dataset_version": "V1", "doi": "xxxx", "url": "xxxx", "keywords": [ "Positron Emission Tomography", "PET", "Brain", "Source files", "ecat7", "DICOM", "Phantom", "Conversion", "PET2BIDS", "dcm2niix" ], "license": { "name": "CC BY 4.0", "url": "https://creativecommons.org/licenses/by/4.0/" }, "authors": [ { "givenName": "Cyril", "familyName": "Pernet" }, { "givenName": "Sune", "familyName": "Høgild Kelle" }, { "givenName": "Gabriel", "familyName": "Gonzalez-Escamilla" }, { "givenName": "Søren", "familyName": "Baarsgaard Hansen" }, { "givenName": "Maqsood", "familyName": "Yaqub" }, { "givenName": "Murat ", "familyName": "Bilgel" } ], "metadata_sources": { "key_source_map": {}, "sources": [ { "source_name": "OpenNeuroPET", "source_version": "1", "source_parameter": {}, "agent_name": "Cyril Pernet", "agent_email": "" } ] } }'
You will see an error when you run that, but that is because of a different validation issue (I received this error when running your code locally):
[Schema validation failed in LINE 1:
{} is not of type 'number'
Failed validating 'type' in schema['allOf'][0]['then']['properties']['metadata_sources']['properties']['sources']['items']['properties']['source_time']:
{'description': 'The time (since epoch) when this source was used to '
'provide the applicable metadata',
'title': 'Source time',
'type': 'number'}
On instance['metadata_sources']['sources'][0]['source_time']:
{}]
The issue here is that source_time should be a number and not {}. You can solve it in this case by removing the field from it's containing object, since it is not a required field.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

Thanks for the feedback. JSON Lines is a known format where a single line is a single json object with no indentation. Perhaps it's a good idea to add a link in the doc to the json lines format. And I agree, if something is confusing in the docs, that's a reason to improve it. You are very welcome to make a PR, it would be much appreciated :)
Another note, I forgot to mention that the catalog_serve command, and any other commands taking metadata as an argument, can also accept Python dictionaries when working via the Python api.

success :-)  -- just the 'title' does not render, "title": "OpenNeuroPET Phantoms" yet it is there in https://github.com/Public-nEUro/DataCatalogue/blob/master/metadata/datalad_hash_to_use/V1/049/a1078084a97532a48a316e5bb30cd.json

There isn't actually a title property specified in the dataset schema. I suspect it doesn't give you a warning or error about this since extra properties aren't explicitly prohibited. But if you rather populate the name field, I think it should display correctly.

indeed, solved! thx


Error: read ECONNRESET When debugging

Environment data
dotnet --info output:

dotnet --info
.NET Command Line Tools (1.0.0-rc4-004771)

Product Information:
Version:            1.0.0-rc4-004771
Commit SHA-1 hash:  4228198f0e
Runtime Environment:
OS Name:     arch
OS Version:
OS Platform: Linux
RID:         ubuntu.14.04-x64
Base Path:   /opt/dotnet/sdk/1.0.0-rc4-004771
VS Code version:

code --version
1.9.1
f9d0c687ff2ea7aabd85fb9a43129117c0ecf519

C# Extension version: 1.7.0
Steps to reproduce
debug a C# process
Expected  behavior
debugger launches and attaches
Actual behavior
errors in console, doesn't start or attach
if using the run configuration (as opposed to attach) it will prelaunch build but fail after prelaunch
distro is Arch, up to date

launch.json
{
    "version": "0.2.0",
    "configurations": [
        {
            "name": ".NET Core Launch (console)",
            "type": "coreclr",
            "request": "launch",
            "preLaunchTask": "build",
            "program": "${workspaceRoot}/bin/Debug/netcoreapp1.0/mercury.dll",
            "cwd": "${workspaceRoot}",
            "externalConsole": false,
            "stopAtEntry": false,
            "internalConsoleOptions": "openOnSessionStart"
        },
        {
            "name": ".NET Core Attach",
            "type": "coreclr",
            "request": "attach",
            "processId": "${command.pickProcess}"
        }
    ]
}

@gregflynn my guess is that our debug adapter process is crashing, though this is just a guess. Arch isn't really a supposed OS distro for .NET Core, so we are happy to help if we can, but it might turn out we can't get this to work. Based on other Arch customers, we currently use the Ubuntu 16.04 version of .NET Core for running the debugger itself. Sounds like you are using the Ubuntu 14.04 .NET Core. So I am not sure if something changed in Arch, or if they both run (which would be somewhat weird since they don't even manage that on Ubuntu).
To see if our adapter is just completely on the floor, you can try:
cd ~/.vscode/extensions/ms-vscode.csharp-1.7.0/.debugger
./OpenDebugAD7 --help
If that successfully prints something then you can try:
./OpenDebugAD7 --server
// which will launch our debugger on a socket
And then try adding: "debugServer":4711, to your active launch.json configuration setting and try launching that way.
Hopefully you will find that at least one of these crashes giving something useful over stderr.

 ./OpenDebugAD7 --help
Failed to initialize CoreCLR, HRESULT: 0x80131500

:disappointed:
From a command I found on another thread:
 find /opt/dotnet -name '*.so' -type f -print | xargs ldd | grep 'not found'
	liblldb-3.6.so => not found
	liblldb-3.6.so => not found
/opt/dotnet/shared/Microsoft.NETCore.App/1.0.3/System.Net.Http.Native.so: /usr/lib/libcurl.so.4: version `CURL_OPENSSL_3' not found (required by /opt/dotnet/shared/Microsoft.NETCore.App/1.0.3/System.Net.Http.Native.so)

 pacman -Ss lldb
extra/lldb 3.9.1-2 [installed]
    Next generation, high-performance debugger

So that's installed just too new :thinking:
This is the AUR package link also https://aur.archlinux.org/packages/dotnet-cli/

That HRESULT is not helpful unfortunately -- COR_E_EXCEPTION.
lldb shouldn't be the problem - CoreCLR doesn't need it in this scenario.
System.Net.Http.Native sounds like it may be an issue if you are trying to ASP.NET, but I don't think OpenDebugAD7 will have an issue.
The first thing I might suggest is downloading https://vsdebugger.azureedge.net/coreclr-debug-1-7-1/coreclr-debug-ubuntu.14.04-x64.zip and see if OpenDebugAD7 -h works any better there.
If that doesn't help, you are finding over the version of dotnet installed to run apps, but the debugger has its own copy of CoreCLR/CoreFX in the .debugger directory, so you could try running find in the .debugger directory instead. I think there are also ways to get CoreCLR to print some logging. So we could try that too.

Alright something worked
 ./OpenDebugAD7 -h
OpenDebugAD7: Visual Studio Code debug adapter bridge for using Visual Studio
debug engines in VS Code

Available command line arguments:
--trace: print the requests coming from VS Code to the console.
--trace=response: print requests and response from VS Code to the console.
--engineLogging[=filePath]: Enable logging from the debug engine. If not
    specified, the log will go to the console.
--server[=port_num] : Start the debug adapter listening for requests on the
    specified TCP/IP port instead of stdin/out. If port is not specified
    TCP 4711 will be used.
--pauseForDebugger: Pause the OpenDebugAD7.exe process at startup until a
    debugger attaches.

and
 ./OpenDebugAD7 --server
waiting for v8 protocol on port 4711
waiting for v8 protocol on stdin/stdout

When running OpenDebugAD7 from within that zip archive, I'm not quite sure what this means though

@gregflynn you can try this then --
Replace the .debugger folder
echo install.complete > .debugger/install.complete
chmod +x .debugger/OpenDebugAD7
chmod +x .debugger/clrdbg
And see if this produces something that works.

@gregg-miskelly works like a charm, a little hacky but I'll take it :smile:


Are you open to making TLS ciphers configurable?

Generally I'm reluctant to enter the custom cipher configuration game - the hunt for the perfect configuration to get an A+ on qualys ssl labs is a mugs game.
However, we've hit a situation where we'd prefer to sacrifice some backwards compatibility to get perfect forward secrecy in place for all connections. Rats.
Are you open to a patch to make the ciphers enabled in envoy configurable?
The following comment in the ingress route design doc (design/ingressroute-design.md) sounds promising:

other properties like cipher suites may be added later

We're currently still using contour 0.7 with traditional Ingress objects, but I guess we'll have to switch to using IngressRoute eventually, and if they make configurable ciphers an option then that'd be a bonus.

Yes, I think we can do that in both ingress via an annotation and ingress route in the virtual host.tls spec.

On 28 Nov 2018, at 23:41, James Healy<EMAIL_ADDRESS>wrote:
Generally I'm reluctant to enter the custom cipher configuration game - the hunt for the perfect configuration to get an A+ on qualys ssl labs is a mugs game.
However, we've hit a situation where we'd prefer to sacrifice some backwards compatibility to get perfect forward secrecy in place for all connections. Rats.
Are you open to a patch to make the ciphers enabled in envoy configurable?
The following comment in the ingress route design doc (design/ingressroute-design.md) sounds promising:
other properties like cipher suites may be added later
We're currently still using contour 0.7 with traditional Ingress objects, but I guess we'll have to switch to using IngressRoute eventually, and if they make configurable ciphers an option then that'd be a bonus.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

That's good news.
The envoy cipher config is the standard list of cipher labels as a string. Is your preference to expose that directly so contour users can can provide a cipher string?

My first preference is to fix whatever ssl labs is complaining about without an option to change it.
I’m not sure that is achievable, so the fallback is to choose a reasonable default then add a list argument to the tls spec where an alternative list can be supplied.

On 29 Nov 2018, at 10:35, James Healy<EMAIL_ADDRESS>wrote:
That's good news.
The envoy cipher config is the standard list of cipher labels as a string. Is your preference to expose that directly so contour users can can provide a cipher string?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

I had a bit of a poke at this. Customising the list of ciphers passed to envoy is simple enough, but making the feature robust and not a giant foot cannon was difficult.
It seems that passing an unrecognised cipher to envoy results in envoy not starting a TLS listener on the the requested port, and the supported list of ciphers depends on the vendored cersion of boringssl in envoy. It was very easy for me to end up with nothing listening on (8)443 without obvious feedback about why.
Does anyone know if it's possible to query envoy for a list of supported ciphers? if so, we could compare that list against the user provided list and return a nice error if the user has requested one that boringssl doesn't support.

At the moment Envoy and Contour are tightly coupled so I would like to avoid having to sense the ciphers supported by envoy, present them to the user, have them adjust them on a per ingress basis, presumably with some filtering from the administrator. Apart from the fiddlyness of this process, I don't think its actually solving the problem.
The problem users and administrators want is for people to not use insecure ciphers. I would prefer to see the list of ciphers supported by contour kept up to date so that all users can benefit. We did this before when we turned off TLS/1.1 support, nobody seemed to actively want to use insecure ciphers and the argument that they need to support old busted pieces of equipment get weaker over time.
In summary, even though we could present the option for users and administrators to control their cipher set, I would prefer that we did not, instead Contour should configure Envoy so that nobody is using insecure ciphers.

I'm on board with being opinionated, although I'm worried that my opinion about what ciphers are secure may be ill-informed. Particularly over the long term where the recommended ciphers will evolve and someone (possibly not me) in the contour community will have to take on the responsibility of keeping contours cipher list up to date.
I guess I could prepare a PR that selects the ciphers required to get an A on qualys, and we could have a discussion about the compatibility impacts. We'd have to be prepared for a few folks to find upgrading contour breaks compatibility with a device they care about though.

Qualys or ssl labs would be a good start. I'm not an expert on this either,
but I know that ssllabs A+ is a goal for some teams, so shooting for that
(the current cipher list isn't that short of A+ at the moment) sounds like
a reasonable goal
On Thu, 14 Mar 2019 at 22:41, James Healy<EMAIL_ADDRESS>wrote:

I'm on board with being opinionated, although I'm worried that my opinion
about what ciphers are secure may be ill-informed. Particularly over the
long term where the recommended ciphers will evolve and someone
(possibly not me) in the contour community will have to take on the
responsibility of keeping contours cipher list up to date.
I guess I could prepare a PR that selects the ciphers required to get an A
on qualys, and we could have a discussion about the compatibility impacts.
We'd have to be prepared for a few folks to find upgrading contour breaks
compatibility with a device they care about though.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/heptio/contour/issues/823#issuecomment-472816781, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcAy1OD-avx_6kksyG3nvgTQtoyMpXks5vWjVzgaJpZM4Y3hdJ
.

Based on my two most recent comments I’m marking this as help wanted for 0.12.
If you want to work on it the spec is to revise the list of permitted ciphers to raise the ssl labs score.
No design doc is needed but I expect a detailed commit message detailing the decisions and trade offs of applying the PR.
Thank you.

Thanks @davecheney - I've had a crack at something in #1011


Where should we enforce/check ForceField.aromaticity_model?

Keeping track of my thoughts so we can come back to this:
Current Implementation
Both Topology and ForceField have aromaticity_model attributes. These are set to OEAroModel_MDL by default, and will raise an exception if the user (or OFFXML file) tries to set them to anything else. We've also hard-coded MDL aromaticity assignment when creating OFFMols using from_openeye and from_rdkit. The current implementation is quick and dirty, and won't actually support other aromaticity models if asked.
Proposed Implementation
I think the best thing to do would be to validate molecules against the aromaticity model at the beginning of system parameterization. The specific aromaticity model would come from the value read from a SMIRNOFF data source. If multiple data sources were read, the ForceField object would ensure that they all specified the same aromaticity model. It seems best thar aromaticity would be checked at parameterization-time. Any sooner, and the user could change the requested aromaticity model. Any later, and we wouldn't match SMIRKS correctly. This check would first go through Topology.check_aromaticity(aro_model), which would loop over all reference molecules and run Molecule.check_aromaticity(aro_model) on each.
Molecule.check_aromaticity(aro_model) would perform a round trip using the highest priority available cheminformatics toolkit (OE > RDK, presently). The toolkit would be set to raise an Exception if the molecule does not make sense given the requested aromaticity model.
Remaining Questions

Does it make sense for a Topology to "enforce" an aromaticity model for all of its molecules separate from/before system parameterization? It's not clear that this would save any time vs. just checking each molecule when ForceField.create_system is called. Checking sooner would also make it more complicated to define molecules using the API.

The only time we need to use aromaticity models are when we perform operations on Molecule objects that require it. Since we will let molecules and topologies be edited up until that point, they may exist in a non-chemical state up until that point, so it's best not to do any sort of checking if we can avoid it---except when desired to catch errors earlier.
I'm not sure we even want Molecule.check_aromaticity() or Topology.check_aromaticity() methods---and it doesn't even make sense to me what that means. Instead, when we are performing an operation that requires the molecule be perceived with a particular aromaticity model, such as finding SMARTS matches, we want to make sure the molecule has been perceived with the desired aromaticity model.
TL;DR: The only time we want to use aromaticity model information is when performing operations on a Molecule that require it.

I agree with John here. And... the aromaticity model will be specified by the forcefield; it is otherwise irrelevant (and not something applied to a molecule, EXCEPT when we require it to do an operation on that molecule).

OK. I'm in agreement that a check_aromaticity model is poorly specced. However I keep running into ambiguities in my understanding around aromaticity in general, which model we assume where, and how much of a defining feature of molecules we consider it to be. This has led me to play "whack a mole" with aromaticity perception (leading to a pretty inconsistent system of aromaticity handling implemented in the toolkit), and I've finally drafted a proposal for where I smell smoke in the current toolkit implementation and what we can do about it at #697.


Operationalizing AAD System

Issue

An operations-team needs to be selected.

Operationalizing AAD
Operations is a business unit that handles recurring tasks.  Operations is responsible for the day to day "operations" of the system, hence the name.  The operations-team is devoted to completing operational tasks in timely way.  In contrast, the developer-team is responsible for new systems, new system features, and updates to existing systems and features.
In short, Operationalization is the process of transitioning the responsibility and control of the AAD system from the developers to the administrators, from the developer-team to the operations-team, or from development to production.
Development vs Operations
Formally, a member of the operations-team is not a member of the development-team. Separating the duties and personnel provides better security via the strategy of least privileges principles. The greater the separation of duties and personnel the better the security.
Smaller organizations often don't have enough people or resources to achieve full separation and will blur the duties and and share members between the development-team and the operations-team. Blurring and sharing between teams decreases the security of the system and increases the opportunity for mistakes. You may have already guessed that having a single team to provide coverage for both development and operational tasks is the least secure solution.
Citizen Labs' Preferences
Our preferences for an operations-team are as follows, we prefer team-members to be LGROW employees over Citizen Labs' volunteers.  We prefer a mix of LGROW employees and Citizen Labs' volunteers over all Citizen Labs volunteers.  We will accept an all Citizen Labs' volunteer team but we will require a formal agreement to define obligations of Citizen Labs.

LGROW is on board with this. We would love to sit down with Citizen Labs and learn how to operate the system once deployed. We are open to a formal agreement to define roles. Thank you all so much for your hard work on this!


include: Remove compat include headers

Remove the compat headers as its been 2 releases since we introduced
them.
Signed-off-by: Kumar Gala<EMAIL_ADDRESS>

hmm, looks like the deprecation warnings were not working correctly?