feat: add WRROC models, validators & unit tests

Hi @uniqueg and @SalihuDickson,
Summary
This PR introduces several key improvements and fixes based on recent feedback:

Refactor WRROC Models:

Created a base class WRROCDataBase to hold common fields and methods.
Refactored WRROCData, WRROCDataTES, and WRROCDataWES to inherit from WRROCDataBase to reduce code duplication and enhance maintainability.

Stricter Validation:

Replaced extra = "allow" with extra = "forbid" in all WRROC models (WRROCProcess, WRROCWorkflow, WRROCProvenance) to enforce stricter validation.

Enhanced Validation and Error Collection:

Modified validation functions to collect and report all errors found during validation, ensuring comprehensive feedback.
Simplified field validation by removing manual checks for extra fields and leveraging Pydantic's extra = "forbid" configuration.

Expanded Unit Tests:

Added test cases for edge scenarios such as empty object or result lists, missing optional fields, and incorrect data types.
Implemented tests for invalid URLs and other edge cases.
Fixed existing tests by allowing empty lists and adding URL validation in the WES conversion validation.

Summary by Sourcery
Add WRROC models with a new base class for shared fields, enhance validation with stricter rules and comprehensive error reporting, and expand unit tests to cover edge cases. Enable test execution in the CI workflow.
New Features:

Introduce WRROC models including WRROCData, WRROCDataTES, and WRROCDataWES, inheriting from a new base class WRROCDataBase to encapsulate common fields and methods.

Enhancements:

Implement stricter validation in WRROC models by setting extra fields to 'forbid', enhancing data integrity.
Enhance validation functions to collect and report all errors found during validation, providing comprehensive feedback.

CI:

Enable the execution of unit tests in the CI workflow by uncommenting the test run command.

Tests:

Expand unit tests to cover edge scenarios such as empty object or result lists, missing optional fields, and incorrect data types for WRROC models.
Add tests for invalid URLs and other edge cases in WRROC models.

Overview
This PR introduces data validation in both the TES and WES converters, ensuring that the input data adheres to the expected format and contains all necessary fields before the conversion process begins. The changes are aimed at improving the robustness and reliability of the conversion process by leveraging Pydantic models for validation.
Changes Implemented

TES Converter (tes_converter.py):

Added data validation using the TESData model before the conversion process.
Updated the conversion logic to handle only validated data, ensuring correctness and preventing errors.

WES Converter (wes_converter.py):

Implemented validation using the WESData model before conversion.
Adjusted the conversion logic to operate on validated data, improving the reliability of the conversion.

Validation Details

TES Data Validation:

The TESData model is used to validate the input TES data before conversion to WRROC.
Any data that does not adhere to the TES schema will raise a validation error, preventing the conversion process from proceeding with invalid data.

WES Data Validation:

The WESData model validates the WES data before it is converted to WRROC.
Validation ensures that all required fields are present and correctly formatted, with errors being raised for any discrepancies.

Additional Information

The validation steps ensure that only valid data is processed during the conversion, reducing the likelihood of errors and improving the overall robustness of the tool.
Deprecated fields such as task_logs in WES are now handled with warnings, and new fields like tes_logs_url are supported to maintain compatibility with the latest specifications.

Please review the changes and provide feedback.

This PR addresses several issues raised in the mentor's feedback, particularly focusing on the WRROCDataWES model and its validation logic. The following changes have been made:
1. Fixed Validation Errors in WRROCDataWES

Updated the test data in test_validate_wrroc_wes to ensure all required fields, such as status and object, are provided with valid values.
Adjusted the model to allow None values where appropriate, ensuring the model can handle cases where optional fields are not present.

2. Enhanced Test Coverage

Modified existing tests to ensure that they accurately reflect the expected data structures and validation logic.
Added new tests to cover edge cases, particularly where certain fields may be optional or could be None.

3. Updated Validators

Improved the validate_wrroc_wes function to handle the validated data more robustly by using .dict() for correct data conversion.
Ensured that validation errors are properly caught and raised with informative messages.

4. Code Consistency and Cleanup

Ensured consistency in the use of variable names and structure across the codebase, particularly in the converters and validators.
Removed unnecessary comments and redundant code to improve readability and maintainability.

How to Test

Run the test suite to verify that all tests pass:poetry run pytest --cov=crategen

Notes
This PR primarily focuses on fixing the immediate validation issues. Future PRs will address additional feedback regarding handling multiple executors and improving error messages.

@Karanjot786, @uniqueg, I just merged a PR to address a few things, namely;

separated the data models into separate files because the one models file was getting crowded.
modified tes model to better fit with the specifications from the GAGH tes schema and added a reference for each model.
configured the ruff linter to properly format and lint the code.
enabled ci checks on all branches

@Karanjot786, @uniqueg, I just merged a PR, that among other minor fixes, configures lefthook to carry out pre-push checks, making sure code pushed to repo meets a certain level of quality. Currently,  linting and fiormating are the only check.

Thank you for the updates, @SalihuDickson
I appreciate the work separating the data models into individual files; this will help keep the codebase more organized as it grows. The modifications to the TES model to better align with the GA4GH specifications are also great, and having the references directly in the models will be useful. I'll make sure to integrate these changes into my workflow. Also, the configuration of the ruff linter and enabling CI checks on all branches are much appreciated—they’ll help maintain a high standard of code quality in the future.
Adding lefthook for pre-push checks is a fantastic step toward ensuring consistent code quality. I'll make sure my code adheres to the new checks before pushing any updates. This will certainly help streamline the review process and reduce back-and-forth on formatting and linting issues.
Thanks again for implementing these improvements! I'll continue to align my work with these updates.

Hi @uniqueg,
Here are the locations where the validate_wrroc_tes() and validate_wrroc_wes() functions are used in the codebase:

validate_wrroc_tes() is used in the test file to validate WRROC entities for TES conversion. You can find its usage here: validate_wrroc_tes() Usage.

validate_wrroc_wes() is similarly used in the test file for validating WRROC entities for WES conversion. Its usage can be seen here: validate_wrroc_wes() Usage.

These functions are primarily used in the test suite to ensure that the data conforms to the expected structures for TES and WES conversions.

Hi @uniqueg, Here are the locations where the validate_wrroc_tes() and validate_wrroc_wes() functions are used in the codebase:

validate_wrroc_tes() is used in the test file to validate WRROC entities for TES conversion. You can find its usage here: validate_wrroc_tes() Usage.
validate_wrroc_wes() is similarly used in the test file for validating WRROC entities for WES conversion. Its usage can be seen here: validate_wrroc_wes() Usage.

These functions are primarily used in the test suite to ensure that the data conforms to the expected structures for TES and WES conversions.

Thanks a lot! I hadn't checked the test files.
Generally, if code is only used in tests, it should not be in the main codebase - rather you want to keep it in the test folder. And consider creating a pytest fixture from it.
Here though, I think the validator code is useful and should be used in the main code base. You should never return unvalidated code. And you should always validate inputs. So consider where in the codebase you wand/need to add these validations.

PR Description
Summary:
This PR addresses several updates and improvements based on recent mentor feedback:
1. CI Workflow Updates:

Updated the CI workflow in .github/workflows/ci.yml to use the latest versions of actions/checkout and actions/setup-python (upgraded from v2 to the latest v4).

2. Code Cleanup and Refinements:

Removed redundant type annotations from the docstrings in crategen/converters/tes_converter.py and crategen/converters/wes_converter.py. Type hints are now only present in function signatures.
Removed unnecessary comments that described straightforward code in both TESConverter and WESConverter.
Added validation steps for wrroc_data before returning it in the convert_to_wrroc method of TESConverter and ensured the output data is validated after conversion in the convert_from_wrroc method.
Added Google-style docstrings and type hints to all modules, classes, methods, and functions within the TESConverter and WESConverter.

3. Consistency Improvements:

Updated the method signature in AbstractConverter to ensure consistency, changing convert_from_wrroc(self, wrroc_data) to convert_from_wrroc(self, data).

4. Validator Integration:

Integrated validate_wrroc_tes() and validate_wrroc_wes() validators into the appropriate locations within crategen/converters/tes_converter.py and crategen/converters/wes_converter.py to ensure data validation before and after conversions.

5. Validator Usage Clarification:

Provided clarification and permalinks to where validate_wrroc_wes() and validate_wrroc_tes() are being used in the codebase.

6. Alias Usage Update:

Confirmed that the code for converting @id to id for validation purposes has been removed. The models currently use straightforward field names without aliasing. Updated the WRROC models to include Field definitions with aliases (e.g., id to @id) where necessary to conform to the WRROC schema requirements.

7. Test Case Adjustments:

Updated the test cases in tests/unit/test_wrroc_models.py to use field aliases (e.g., @id instead of id) in the test data, ensuring compatibility with the updated model definitions that require these aliases.

Hi @SalihuDickson,
I encountered a build failure during the recent CI run due to multiple errors in the WESConverter code, specifically in crategen/converters/wes_converter.py. Here are the errors that were flagged:

Attribute Errors:

Item "None" of "Log | None" has no attribute name, start_time, end_time (lines 32, 34, 35).
The result seems to be expecting objects with attributes location and name, but a string is being passed.

Missing Arguments in Log:

On line 68, multiple required arguments (cmd, stdout, stderr, exit_code, and system_logs) are missing when constructing the Log object.

Incompatible Types:

start_time and end_time are being passed as str | None but expected as datetime | None.
workflow_engine_parameters, workflow_engine, workflow_engine_version, and workflow_url are missing from the RunRequest.
The outputs attribute in WESData expects a dictionary (dict[str, str]), but a list of WESOutputs objects is being passed.

Incompatible State Type:

The state in WESData expects a State | None, but a str is being passed.

Other Issues:

Some fields are missing when constructing the WESData object, including task_logs_url.

Here's how I think we can fix these issues:

Ensure that when Log or TaskLog is created, all required fields (cmd, stdout, stderr, exit_code, and system_logs) are provided.
Convert start_time and end_time to datetime where applicable before assigning them.
Ensure outputs is passed as dict[str, str] instead of a list of WESOutputs objects.
Ensure that the correct State enum is passed instead of a raw string for state.
Complete the RunRequest by providing the necessary fields such as workflow_engine_parameters, workflow_engine, workflow_engine_version, and workflow_url.
Make sure task_logs_url is passed to WESData during creation.

Please let me know your thoughts on this or if you have any suggestions on how best to resolve these errors.
Thank you!
Best regards,
Karanjot

@Karanjot786, thank you for bringing this to my attention, I am working on a fix.

Hi @SalihuDickson,
Thank you for your feedback! I'd be happy to clarify the points you've mentioned.

WES Converter Output Object:

You pointed out that in the WES schema, the result should not be a list, and you're correct. The original implementation does handle result as a list, which isn't fully aligned with the Workflow run RO-Crate schema. I'll look into adjusting this so that the result conforms to the correct object structure.
As for the location and name keys, those were likely added based on earlier assumptions about the output structure. You're right that the WES specification doesn't explicitly define these keys. I will cross-check the schema more thoroughly and update accordingly once we finalize this.

Validators in crategen/validators.py:

The crategen/validators.py module is essentially providing a layer of custom validation logic on top of the Pydantic models. While the Pydantic models do validate the shape and types of the data, the validators module performs additional checks that are specific to the conversion logic and schema compatibility within our application.
For instance, the validators may ensure that certain fields conform to specific RO-Crate or TES/WES conversion requirements, or they may ensure compatibility between multiple models. These validations are often context-specific and may not fit neatly into the standard Pydantic model validation pipeline.
The key difference is that Pydantic's validation is generally focused on ensuring data integrity at the model level, whereas the custom validators help enforce business logic and additional rules necessary for proper conversion across schemas (TES, WES, RO-Crate). In some cases, these validators also provide error messages tailored to the conversion process, which might not be as easily customizable within Pydantic's validation system.

I hope this helps clear up the reason for the current setup. Please let me know if you'd like further details or if any adjustments should be made based on this explanation.

Hi @SalihuDickson,
Thank you for your feedback! I'd be happy to clarify the points you've mentioned.

WES Converter Output Object:

You pointed out that in the WES schema, the result should not be a list, and you're correct. The original implementation does handle result as a list, which isn't fully aligned with the Workflow run RO-Crate schema. I'll look into adjusting this so that the result conforms to the correct object structure.
As for the location and name keys, those were likely added based on earlier assumptions about the output structure. You're right that the WES specification doesn't explicitly define these keys. I will cross-check the schema more thoroughly and update accordingly once we finalize this.

Validators in crategen/validators.py:

The crategen/validators.py module is essentially providing a layer of custom validation logic on top of the Pydantic models. While the Pydantic models do validate the shape and types of the data, the validators module performs additional checks that are specific to the conversion logic and schema compatibility within our application.
For instance, the validators may ensure that certain fields conform to specific RO-Crate or TES/WES conversion requirements, or they may ensure compatibility between multiple models. These validations are often context-specific and may not fit neatly into the standard Pydantic model validation pipeline.
The key difference is that Pydantic's validation is generally focused on ensuring data integrity at the model level, whereas the custom validators help enforce business logic and additional rules necessary for proper conversion across schemas (TES, WES, RO-Crate). In some cases, these validators also provide error messages tailored to the conversion process, which might not be as easily customizable within Pydantic's validation system.

I hope this helps clear up the reason for the current setup. Please let me know if you'd like further details or if any adjustments should be made based on this explanation.

Thanks for the explanations, @Karanjot786!
Could you please give one (or better: two) concrete examples of things that we need to validate that we won't get for free from Pydantic's automatic validation? Also, for these examples (and more generally), is there any particular reason why we don't use Pydantic's support for writing custom validators?

Hi @SalihuDickson,
Thank you for your feedback! I'd be happy to clarify the points you've mentioned.

WES Converter Output Object:

You pointed out that in the WES schema, the result should not be a list, and you're correct. The original implementation does handle result as a list, which isn't fully aligned with the Workflow run RO-Crate schema. I'll look into adjusting this so that the result conforms to the correct object structure.
As for the location and name keys, those were likely added based on earlier assumptions about the output structure. You're right that the WES specification doesn't explicitly define these keys. I will cross-check the schema more thoroughly and update accordingly once we finalize this.

Validators in crategen/validators.py:

The crategen/validators.py module is essentially providing a layer of custom validation logic on top of the Pydantic models. While the Pydantic models do validate the shape and types of the data, the validators module performs additional checks that are specific to the conversion logic and schema compatibility within our application.
For instance, the validators may ensure that certain fields conform to specific RO-Crate or TES/WES conversion requirements, or they may ensure compatibility between multiple models. These validations are often context-specific and may not fit neatly into the standard Pydantic model validation pipeline.
The key difference is that Pydantic's validation is generally focused on ensuring data integrity at the model level, whereas the custom validators help enforce business logic and additional rules necessary for proper conversion across schemas (TES, WES, RO-Crate). In some cases, these validators also provide error messages tailored to the conversion process, which might not be as easily customizable within Pydantic's validation system.

I hope this helps clear up the reason for the current setup. Please let me know if you'd like further details or if any adjustments should be made based on this explanation.

Thanks for the explanations, @Karanjot786!
Could you please give one (or better: two) concrete examples of things that we need to validate that we won't get for free from Pydantic's automatic validation? Also, for these examples (and more generally), is there any particular reason why we don't use Pydantic's support for writing custom validators?

@uniqueg, Thank you for your feedback!
Two examples of validations we don’t get from Pydantic’s automatic validation include:
1. Content and URL Mutual Exclusion: In TESInput, if the content field is set, the URL field should be ignored, and vice versa. This logic requires validation beyond simple type
2. Path Validation: The path field in TESInput and TESOutput must always contain an absolute path. We are enforcing this with custom logic that ensures the value is validated beyond type constraints.
Regarding Pydantic's custom validators, we could explore leveraging them for these validations. If you agree, I can refactor the code to use Pydantic's custom validation mechanism.

Hi @Karanjot786 - there is a lot of good stuff in this PR, and it's getting there. However, it's just too big a PR to get it over the line, and I feel I am getting caught up in details when reviewing.
I strongly suggest we take this PR apart into several more focused ones, probably to be merged in this order:
* `style: support linting` (make sure that `mypy` and `ruff check` pass)

* `ci: reformat, reset branches & upgrade actions` (put just the latest `.github/workflows/ci.yml` without including the job to run unit tests; consider including `lefthook.yml` as well)

* `feat: add WES, TES & WRROC models` (please include appropriate unit tests here, if applicable; once you do add your first tests, add a job to the CI to run them)

* `feat: integrate model validation in conversions` (you can use this PR here; basically, the models should be refactored to use the new models for validation; please leave out any custom validators - we will either add these in the next PR or not at all - see separate discussion thread started by @SalihuDickson)

For changes to pyproject.toml, please use your best judgement where to put them (possibly to multiple PRs).
Some of these may not require any changes from the current state - others just a few. The models one and the last one - where everything comes together - will probably still need some work though, but will become much easier to manage when there are only a few files affected at any given time.

@uniqueg, Thanks for the suggestion. I understand the challenge of reviewing a large PR, and I agree that splitting the changes will make the process smoother.
I will break the current PR into smaller, focused ones in the following order:
1. style: Support for linting and ensuring mypy and ruff pass.
2. ci: Reformat, reset branches, and upgrade actions.
3. feat: Add WES, TES, and WRROC models, including relevant unit tests.
4. feat: Integrate model validation into conversions.
For changes to pyproject.toml, I’ll distribute them across relevant PRs as you suggested.


const clang::Expr *clang::CXXConstructExpr::getArg(unsigned int) const: Assertion `Arg < getNumArgs() && "Arg access out of range!"' failed.

velodyne_pointcloud__transform_node.log

Also: imu_filter_madgwick__imu_filter_node.log

Also:
imu_transformer__imu_transformer_nodelet.log


optimizer: simplify GROUP and LOCAL to have one of each

Now that tensor cores only use LASTLOCAL, we can simplify to use only that op everywhere.
The only use of GROUP is in matvec hand-coded opts and it doesn't make a performance difference so switching to use only the top behavior.
Also adds additional asserts to prevent tensor core dims from being altered which causes bad kernels to be generated.

Have you confirmed all behavior is identical across the test set? What about TC=2? What about the GROUP that's not a GROUPTOP in the MV stuff?

Did a diff and manual inspection on the DEBUG=4 output of test/test_linearizer.py from master and this branch, everything looks the same up to exchanges in lidx indices which are safe.
TC=2 is now part of the CI Metal tests, but confirmed it locally on all test/*.py not just test_ops.py.
For the matvec change, it doesn't seem to make a measurable difference (first is master, second is just changing the matvec GROUP to GROUPTOP):

Changed to keep the GROUPTOP opt in the latest commit.


unable to load TLS credentials: tls: failed to find any PEM data in certificate input

Background
I'm trying to run LND node on Android but i'm having issues to start up the node.
Your environment

version of lnd - 0.14.1-beta
which operating system (uname -a on *Nix) - Android API 32
version of btcd, bitcoind, or other backend - Neutrino

Steps to reproduce
I'm using the next command to try to startup the node.
--bitcoin.active --bitcoin.testnet --bitcoin.node=neutrino --tlsdisableautofill --lnddir=${LND_DIR} --neutrino.connect=faucet.lightning.community --debuglevel=debug
Expected behaviour
The node should be start up without problems.
Actual behaviour
shutting down because error in main method: unable to load TLS credentials: tls: failed to find any PEM data in certificate input

Did you edit your tls.cert file or copy it from somewhere? Sounds like that file is corrupt or empty. You can let lnd create a new one by deleting both tls.key and tls.cert and restarting.

@guggero thanks, delete the app from simulator and reinstall.
Done!


Bug new_chapter_template.tex

%TEX root = ../dissertation.tex

I think shoud be:
%!TEX root = ../dissertation.tex

You missed the  !
PS: Thank you for the template.

The page header is only a comment, so the ! will not make difference in the compilation process.

Yes you are right.
Only some text editors look at this.
But I strongly advise you to compile using our Makefile or even Grunt because there are steps such as acronyms list generation that require extra commands in the build process


[macOS] Fix dragging window from non-retina to retina display.

Fixes #17699

Thanks!

Cherry picked into 3.0.3


Cargo-generate is not able to generate GH Actions files

Describe the bug
I've tried to generate some GH Action CI files with cargo-generate and it doesn't work since both things use the same syntax for variables ({{ <variable_name> }}).
To Reproduce
Steps to reproduce the behavior:

cargo generate SergioGasquez/esp-template -b feat/ci --name test -d mcu=esp32 -d advanced=true -d alloc=false -d wokwi=false -d devcontainer=false -d ci=true
See .github/workflows/rust_ci.yml file.

Expected behavior
File is generated properly, although I am not sure how we can solve this.

For ci pipelines you can do the following 2 things:

Exclude them from being processed
Wrap the whole content of the file with the raw tag

Thanks for the quick response! Excluding is not a solution since I need some parts of the file to be processed, but the raw tag is a perfect solution!

I ran into a similar problem; placeholders weren't being substituted. After an hour of fiddling, I figured that liquid is probably just erroring out silently behind the scenes due to a false positive of a CI variable.
In other words, make sure to wrap {{ }} in your CI workloads with raw tag, even if not placeholder!
To give an example:
❌ Don't do this
jobs:
  test-native:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os:
          - ubuntu-latest
{%- if xplat %}
          - macos-latest
          - windows-latest
{%- endif %}

✅ Do this
jobs:
  test-native:
{% raw -%}
    runs-on: ${{ matrix.os }}
{%- endraw %}
    strategy:
      matrix:
        os:
          - ubuntu-latest
{%- if xplat %}
          - macos-latest
          - windows-latest
{%- endif %}


number.isLessThan is not a function

Hello,
I'm using bignumber.js v5.0.0 and I have this error:
error: Error during request processing TypeError: number.isLessThan is not a function

Could you help me ?
Thanks !

Previous to version six, the method was named lessThan.
(The name was changed so that all methods that return a boolean start with 'is'.)


Spark 2.4

Hello,
I am running the beta version image for spark 2.4 as our needs is to read AVRO format files. But the package on the documentation page says
The spark-avro module is external and not included in spark-submit or spark-shell by default.
How do I include spark-avro module and google-cloud-bigquery module in the program ?
Thanks,
Shaun

It is documented in Spark doc.
./bin/spark-submit --packages org.apache.spark:spark-avro_2.12:2.4.3 ...


App ID and Password does seem to be required when running locally

Hi,
This is partially feedback for this example project, so I can file an issue there if that would be more appropriate:
https://github.com/microsoft/BotBuilder-Samples/tree/main/samples/csharp_dotnetcore/80.skills-simple-bot-to-bot#testing-the-bot-using-bot-framework-emulator
Anyway, I'm trying to run that project locally, and this note mentions you don't need an app ID or password when running the project locally, if you have 4.11 or higher of the Bot Framework Emulator:
https://docs.microsoft.com/en-us/azure/bot-service/skill-implement-skill?view=azure-bot-service-4.0&tabs=cs#prerequisites
I updated to version 4.13, and tried running the project locally, which works, but when I make a request to it from the Bot Framework Emulator, I get an error like this:

That makes sense since I didn't set anything in my appsettings.json, so I set those variables to fake values (FakeAppIdRoot, FakeAppPasswordRoot, etc.). However, even with those set I just get 401 errors from the Bot Framework Emulator:

If I try providing the fake app ID and password I set in the appsettings.json, I get a 400 error instead:

I've tried a couple other configurations but all fail at some point, either with authenticating with the bot at all or when it starts forwarding requests to the echo skills bot.
Am I doing something wrong? It seems like either the documentation article or the example project itself is missing some details or small changes about how to run locally.
Thanks,
Greg

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: e9f33f10-eb7a-a0ca-a662-31d47af1ad54
Version Independent ID: a63dc7ae-75ac-31e7-b432-84e7e95c1437
Content: Implement a skill - Bot Service
Content Source: articles/v4sdk/skill-implement-skill.md
Service: bot-service
GitHub Login: @JonathanFingold
Microsoft Alias: kamrani

There are a few permutations here (and there's a minor bug in sample 80):

If both the skill and the skill consumer are running locally, then neither one should need an app ID and password.

If one of the bots has an app ID and password, then the other bot also needs one. (I have only tried this using valid app IDs and passwords.)

If either one is deployed, then both need a valid app ID and password.

@stevkan is working on a fix for sample 80.

Remove the following lines from the root bot's constructor:        if (string.IsNullOrWhiteSpace(_botId))
        {
            throw new ArgumentException($"{MicrosoftAppCredentials.MicrosoftAppIdKey} is not set in configuration");
        }

In the appsettings.json file in the root bot project, set the skill's app ID and password values to the empty string.
Then the bots should be testable in the emulator.

There is some additional information in how to Debug a skill or skill consumer.

@JonathanFingold Ah, okay yeah that was my problem. I assumed I needed to set the AppId for the skills bot in the appsetttings.json of the root bot. But yeah, if I just make it blank, and remove all the app ID's and passwords, it works fine.
Thanks so much for the quick response and fix! Appreciate it!

@olucafont6 Glad I could help.

Samples fix is in samples PR 3333.

@JonathanFingold Nice, change looks good :)


Feature request: Internationalization of filechooser

In style.kv you can add an id to the labels at lines 255 and 261 to allow access for changing the text and font for other languages.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

We are closing some of the stale issues, please create a new issue/pr if you'd like to work on this feature, or get in touch with us on #kivy-dev.


Magical replacement of Components

Dream goal
Goal is to replace the dynamic Component replacing pattern by explicit exports that would "magically" replace components.
// my-overrides.js, a special file that contains my Vulcan components override. Could be detected at build time.
export * from "vulcan/ui-react" // magically imports DatatableFooter, DatatableHeader, DatatableContent and Datatable
export const DatatableHeader = () => ( I AM OVERRIDEN ) // first override
export const DatatableContent = () => (
<DatatableHeader/>
 Hello
 <DatatableFooter />
 // second override

Then you consume them like this, business as usual:
// my-page.js
import { Datatable } from "vulcan/ui-react" // import default components + my custom override

export const MyPage = () => (<Datatable>Hello!</Datatable>) // DatatableContent has magically been replaced in Datatable

It's probably undoable with Meteor, but it could prove doable with Webpack.
The tricky part is that you want to override only certain component, that are themselves nested into other replaceable component. You get a kind of recursive/circular import issue.
What's doable today
This pattern is already implementable with one level of imports like this:
// my-ui.js
export * from "vulcan/react"
export const DatatableHeader // will reexport, overriding default DatatableHeader from "vulcan/react"

but it's not enough to handle more deeply nested component replacement, for complex components like DataTable or SmartForm that have multiple layers of replaceable component.
@EloyID @juliensl that's for you Material UI users

Any brain familiar with Webpack welcome. We could also tag those component with a specific syntax to allow static analysis, like naming them <@Datatable> for example

A first iteration could be dropping "Components" population at runtime and replace it by an additional build step https://github.com/VulcanJS/Vulcan/issues/2406
This way "Components.DatatableHeader" could be defined correctly (and maybe overridden) before the app would even start.

Now tracked on https://github.com/VulcanJS/vulcan-npm/issues/17


Updated community sponsors

Thank you so much to @thomasRademaker and @WFT for your support. It means the world to us.

Thank you! This is an invaluable resource you run 😃


Implement writing ID3 tags

Sometimes you upload a file and there's a mistake with the tags (or they're missing).
I saw there's a writeSongData here, any progress on this?

I agree +1

Going to rephrase this one, as it's definitely something I've wanted to add into the system.


job exceeded memory limit

Hello,
Sorry to open several different issue... I try to open 1 issue per problem so that each can be closed when solved, independently of the others...
As explained in issue #36, I'm running CITE-seq-Count 1.4.1 on data previoulsy analysed with 1.3.4.
I've tried twice and in both cases, the programme has been killed by the system because it was using too much memory. I'm running it on a cluster, using the job manager slurm and I have to tell slurm how much memory to allocate to my script. Is there a way to limit the memory used by CITE-seq-Count? And is-there a way to know how much it will need? In this case I allocated 15Gb and it was killed once after 1h30 and the second time after 33 minutes.
Here is the error message:
slurmstepd: Job 3410940 exceeded memory limit (15912452 > 15728640), being killed

You'll find the script and log file attached to the issue #36.
Thank you very much,
Best wishes,
Alice

Hello @amayer21
the amount of memory needed by the script will change based on a few different things

How many reads are being processed
How many TAGS are being searched for
How many threads you use, the overhead from each thread will demand a bit more memory.

Until now I have always asked for way more on my cluster to be sure it would be processed.
How many reads are you processing?
I will run some data with different values and give a rule of thumb of how much memory is required. I can't promise any dates right as I am working on other projects.

Hello Hoohm,
Thank for your reply.
I had 13.6M reads and about 15,291 expected cells (whitelist with 15,291 barcodes).
I will try to downsample both to test the memory needed next time I need to analyse HTO data.
This one was a preliminary experiment we have to present to our scientific advisory board tomorrow so I used the results generated using a previous version of CITE-seq-Count (and the corelation with results obtain with genetic demultiplexing with Demuxlet was already very good).
This is a great tool! Thanks for developing and maintening it!
All the best,
Alice

Hello @amayer21
I suspect part of the problem came from the UMI correction. Can you try to rerun it now with 1.4.2 and let me know if you still have too much memory being used?

Hello Patrick,
I’m sorry I didn't manage to rerun this week. Will try to do it asap and will let you know when done.
Thank you very much for your help
Alice

Picking up where this ticket left off.
We were able to get to the the whitelist generation step while running on 1.4.2, though we were unfortunately hit by the whitelist generation bug noted in #48 [1], caused in part by the shift over to use umi_tools. We then upgraded to the develop branch version 1.4.3 and reran with the following parameters [2], only to encounter OOM errors late into the job [3].
Both runs intended to process 40,334,657 reads, and ran alone on instances with 96 cores, 624GB ram.
We intend to do another run with '-T 48' to see if this alleviates issues. Does this sound reasonable? We're happy to grab some diagnostics if you'd like them, just let us know what you'd like to see.
[1] -
Mapping done for process 26683. Processed 420,152 reads Mapping done for process 26684. Processed 420,217 reads Mapping done Merging results Correcting cell barcodes Finding a whitelist /usr/lib64/python3.6/site-packages/umi_tools/whitelist_methods.py:283: RuntimeWarning: invalid value encountered in sqrt   lineVecNorm = lineVec / np.sqrt(np.sum(lineVec**2)) Traceback (most recent call last):   File "/bin/CITE-seq-Count", line 11, in <module>     load_entry_point('CITE-seq-Count==1.4.2', 'console_scripts', 'CITE-seq-Count')()   File "/usr/lib/python3.6/site-packages/cite_seq_count/__main__.py", line 352, in main     collapsing_threshold=args.bc_threshold)   File "/usr/lib/python3.6/site-packages/cite_seq_count/processing.py", line 310, in correct_cells     plotfile_prefix=False)   File "/usr/lib64/python3.6/site-packages/umi_tools/whitelist_methods.py", line 447, in getCellWhitelist     cell_barcode_counts, cell_number, plotfile_prefix)   File "/usr/lib64/python3.6/site-packages/umi_tools/whitelist_methods.py", line 322, in getKneeEstimateDistance     raise ValueError("Something's gone wrong here!!")  Processed 480,174 reads
Mapping done for process 82667. Processed 480,174 reads
Exception in thread Thread-3:
Traceback (most recent call last):
File "/usr/lib64/python3.6/threading.py", line 916, in _bootstrap_inner
self.run()
File "/usr/lib64/python3.6/threading.py", line 864, in run
self._target(*self._args, **self._kwargs)
File "/usr/lib64/python3.6/site-packages/multiprocess/pool.py", line 479, in _handle_results
cache[job]._set(i, obj)
File "/usr/lib64/python3.6/site-packages/multiprocess/pool.py", line 651, in _set
self._error_callback(self._value)
TypeError: '_io.TextIOWrapper' object is not callable
Mapping done for process 82673. Processed 480,174 reads
srun: Force Terminated job 38495
srun: Job step aborted: Waiting up to 32 seconds for job step to finish.
slurmstepd: error: *** STEP 38495.0 ON hpc-compute1 CANCELLED AT 2019-07-17T01:27:56 ***
slurmstepd: error: Detected 18819 oom-kill event(s) in step 38495.0 cgroup. Some of your processes may have been killed by the cgroup out-of-memory handler.
srun: error: hpc-compute1: task 0: Out Of Memory`

Thankfully, halfing the amount of allocated CPU was able to help us push past the OOM errors.

That's great @amayer21.
Error [1] should be now fixed with 1.4.3 being officially out!
Feel free to reopen if needed.

Hi @Hoohm ,
is it safe to ignore error [3]? I'm getting the exact same error on CITE-seq-Count v1.4.3, but the program keeps running. I found that the error doesn't occur when I run CITE-seq-Count on a single thread, so it might be an issue with multiprocessing as the error message also suggests.

Our path to resolution simply involved cutting down on the amount of allocated CPUs. You can specify this as well in your command via the -T flag.


Fixing race condition where the rule poller may start immediately before initializing the timer

Issue #, if available: 142
Description of changes:
As mentioned in the issue thread, a better approach to start the rule poller is to initialize the _timer first with the call back and infinite due time, and then use _timer.Change(0, 0) to kick off the timer immediately.
This would ensure that the _timer instance is initialized before being accessed in the callback method itself.
Unfortunately, I couldn't come up with a unit test for this race condition. But I feel this refactoring is making the rule poller safer.
Also, the issue mentioned that this problem could occur in the TargetPoller as well, but its unlikely because the first invocation of timer happens after ~10s. So, I'm not touching that code in this PR.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

LGTM


Misses classes used in AngularJS's ng-class attribute

AngularJS uses a unique attr called ng-class for conditional styling:
ng-class="{strike: deleted, bold: important, 'has-error': error}"

The class selectors are the keys in the JS Object and can optionally have single or double quotes around them e.g. strike, bold, and has-error. It doesn't appear that purifycss looks for these. Perhaps an option could be added to scan for ng-class objects when true?

usedcss does something with this... perhaps some code from there could be used here:
https://github.com/komachi/usedcss


How to not stop advertising when a device is bonded?

I am using a characteristic that needs authentication to read. Once I connect to it with one device, the advertising stops, making me unable to detect the ESP32-C3 from a different device. Is there a way to make the advertising not stop or to immediately start advertising again?
W (2928) esp32_nimble::server::ble_server: unhandled event: 18
I (15698) esp32_nimble::server::ble_server: AuthenticationComplete
W (15698) esp32_nimble::server::ble_server: unhandled event: 16
I (15698) NimBLE: GAP procedure initiated: stop advertising.

Advertising can be restarted immediately by adding the following code.
  server.on_connect(|server, desc| {
    if server.connected_count() < (esp_idf_sys::CONFIG_BT_NIMBLE_MAX_CONNECTIONS as _) {
      ble_device.get_advertising().start().unwrap();
    }
  });

@taks I already have that in my code. What happens is if I enter the pin (for example 123456) in one device, it stops the advertisement, and on_connect is not called, which makes new devices not able to see the ESP32.

I have verified and found the following.

In esp32, advertising did not stop after the event 16 (BLE_GAP_EVENT_IDENTITY_RESOLVED).
advertising.on_complete is not called after advertising is finished.
I verified this with the c++ library, but the same problem occurred.

It seems to be a problem with esp-idf itself.

@taks is the bug you found the underlying issue to this issue?

Because the end of advertising cannot be detected, it cannot be immediately restart.
It is possible to solve this problem forcibly by checking the state of advertising at regular intervals and restarting it if it has stopped.

Here is a reproducable example: https://github.com/ChocolateLoverRaj/esp32-nimble/blob/778adeb20f38de6b054a8ec0c82ef80588e0b0c8/examples/ble_secure_server.rs.
Here is how to reproduce:

Connect to the ESP32
Read from the secure characteristic
Enter the code 123456
See the messages:

I (54475) esp32_nimble::server::ble_server: AuthenticationComplete
I (54485) NimBLE: GAP procedure initiated: stop advertising.

I think a simple fix would be to start advertising (or call a function which can start advertising itself) in the AuthenticationComplete function:
https://github.com/taks/esp32-nimble/blob/02e47f71a2a96660563ea7fc67686deac488b35b/src/server/ble_server.rs#L310

Advertising is stopped after AuthenticationComplete.
Therefore, starting it in AuthenticationComplete did not work.

Is there a way of executing code after the message I (54485) NimBLE: GAP procedure initiated: stop advertising.? What about setting a delay after AuthenticationComplete and then advertising again?

I have found a workaround: Advertise on read. Here is a working example: https://github.com/ChocolateLoverRaj/esp32-nimble/blob/c23f18d0ccf4bd20fbed5b73cba07be0378f864e/examples/ble_secure_server.rs#L49-L56. This isn't an ideal solution because then every secure characteristic would have to manually implement on_read and on_write

I found that the following code works well in my environment.
Please check it.
  server.on_connect(|server, desc| {
    if server.connected_count() < (esp_idf_sys::CONFIG_BT_NIMBLE_MAX_CONNECTIONS as _) {
      ble_device.get_advertising().start().unwrap();
    }
  });

  advertising.on_complete(|_| {
    BLEDevice::take().get_advertising().start();
  });

※ advertising.on_complete is not yet released.

I checkout out the authentication-complete branch and it works.


Do not pollute home dir

Lets be good cli folks and not pollute a user's $HOME, instead lets put config files in platform specified config paths. ~/.mctl.yml is used if it exists otherwise we look in dirs provided by xdg package.

This is ready to go but I made it draft until #20 is merged as this depends on it.

:tada:

uggh I very much dislike that merge commits aren't allowed in this org


[Feature] Payload tells you time left when you reach your point limit [pushcart]

Right now, it tells you to "come back tomorrow".
The user's expiration date is stored in the database, compare that to the current date and use moment to convert that to a usable datestring.
Would make it super nice and clean and awesome to use, rather than have peope guess the time remaining, only to be disappointed.

This change will need to change how payload calculates dates.
This will need an additional field in the schema for holding the timeout expiration date (either 30 seconds after the timeout, or the full 24 hours after the last push), both of which are unobtainable with the current structure.

Merged into master

Merged into master


setup_mac does not trap errors

Collecting click==6.6 (from -r requirements.txt (line 1))
  Could not fetch URL https://pypi.python.org/simple/click/: There was a problem confirming the ssl certificate: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590) - skipping
  Could not find a version that satisfies the requirement click==6.6 (from -r requirements.txt (line 1)) (from versions: )
No matching distribution found for click==6.6 (from -r requirements.txt (line 1))
/git/vcdat/frontend
⸨    ░░░░░░░░░░░░░░⸩ ⠙ fetchMetadata: sill mapToRegistry uri https://registry.npmjs.org/redux
npm ERR! Darwin 15.5.0
npm ERR! argv "/usr/local/Cellar/node/6.3.1/bin/node" "/usr/local/bin/npm" "--cafile=/Users/doutriaux1/ca.llnl.gov.pem" "install"
npm ERR! node v6.3.1
npm ERR! npm  v3.10.3
npm ERR! code UNABLE_TO_GET_ISSUER_CERT_LOCALLY

npm ERR! unable to get local issuer certificate
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR!     <https://github.com/npm/npm/issues>

npm ERR! Please include the following file with any support request:
npm ERR!     /git/vcdat/frontend/npm-debug.log
Done installing. You should be good to go.
/git/vcdat/scripts

From the looks of it I'm not good to go 😉

@doutriaux1 If you're on your home network, you'll want to drop the --cafile part of the npm install; that only applies to the lab's network, and probably breaks stuff outside.

@chaosphere2112 I'm rewriting chunks of the setup_mac.sh I'll have a PR later next week, the ssl cdert fails both on regular network or lab network (vpn)

@doutriaux1 I merged your PR and tested on VPN and it works now. Do you think I can close this issues with your PR commit?

sure, but I'm not sure it would catch it if anything went wrong, which is the point of this issue.

okay I'll do some testing and attempt to force errors first.


[WIP] search-api: aggregations on loans

Added a function to perform elastic search aggregations on loans.

The feature that this PR is trying to resolve is already solved with searching on document.circulation in app-ils. I will close this PR if no-one has anything against


F-Droid Version Not Updated

I noticed that your app (on F-Droid) had not been updated since 2017, so I followed a link in the description and found my way here.
Clearly you have updated the app, is there some difficulty in updating F-Droid?
If I install your app from GitHub, will it update itself?
TIA

AFAIK f-droid should build a new version automatically based on tagged releases, e.g. https://github.com/d4rken/reddit-android-appstore/releases/latest
I'm not sure if I made a mistake or what's up, anyone else more familiar with F-Droid?

Wow you're fast!
Somehow I opened an issue with only a title, and you had responded before I could update my post/issue!

The app has an update check, but it's not self-updating like via f-droid. Cross updating is also not possible because the github releases are signed by me, while the f-droid updates are signed by the f-droid build servers.
I'd recommend you post on f-droid forums, maybe the build-bot is drunk and needs some assistance or positive encouragement.

I just glanced at the F-Droid docs and found this page on app updates.
I do know that you are not the only developer who struggles with F-Droid.
That said, many people do figure it out - surely someone as clever as you can do it! ;-)

Oh, also you didn't address one question - if I install your app from GitHub will it update itself?

We are all volunteers. I'm certain you are just as clever. :muscle:
Give it a try, If you hit a roadblock due to needing access to something, let me know.

Oh, also you didn't address one question - if I install your app from GitHub will it update itself?

It's everyone's app :heart:. It will not update itself AFAIK. I think someone worked on that but I don't think any code was merged.

I have an idea: ask for help.
@IzzySoft, could you look at this app to see why it is not updating in F-Droid?

@Grossdm good idea to ask. Usually I'd say to check the build log – but recently I'm not sure if that's updated correctly (there were issues with the web server part). The package name would help to check. While looking for it here in the repo, I've stumbled upon this – which already partly answers your questions: auto update check will fail as it doesn't "execute" the gradle but just parses it. So those values for versionCode and versionName MUST be literals.
Well, as the same has been done for packageId, I do not see its value and thus it's hard to check how UpdateCheckMode is set at F-Droid. Advices:

open an issue on fdroiddata asking for a manual update
fix those settings in build.gradle so automatic update checks can be enabled and work
let me know the package name and I can check what the current setting is

Ah, here it is. OK, let's have a look. And see what I already expected:
AutoUpdateMode: None
UpdateCheckMode: Tags
CurrentVersion: 0.7.1
CurrentVersionCode: 7100

So unless someone manually requested an update, there won't be any as F-Droid will never notice there are newer versions (AutoUpdateMode: None). I'd strongly recommend solving the gradle issues and then ask at fdroiddata to update AutoUpdateMode: Version v%v, so it would also work for future updates – or at least ask for a manual update now (which then would have to be repeated with each new version).
If you want to go for the "complete solution" (incl. AutoUpdateCheck) but need time to adjust the gradle stuff, I could offer to temporarily take the app into my repo (to have a recent version available ASAP). But note that the signature would then match yours (I'd take the APK you attach here to releases/) and not the one F-Droid uses. Just let me know if you want that, @d4rken – I gladly assist.

@IzzySoft , thank you for taking your time to help.
I hope this gets things moving so that more users can benefit from the work done on this project.

@d4rken, did you think that @IzzySoft's ideas could be helpful?
If you are amenable to his offer to take the latest release into his own repo (which I have installed in my F-Droid app, BTW), that would be very nice to get the latest release available before committing more time to resolve this.

@Grossdm note I'd just pick the APK from here where it is available anyway. You could do the same if you want that version (would probably require you to uninstall first if you've installed the app from F-Droid, as the signatures won't match). Taking the APK into my repo just makes it easier to (find and) update, plus you'd be notified whenever there is an update. But yes, my offer stands @d4rken :wink:

@Grossdm
I currently don't have time to further look into automating f-droid builds. I dislike hardcoding the versions in the gradle file just so the parser can read it. Maybe there is a nice workaround I currently don't see though? PRs welcome.
@IzzySoft
Feel free to copy the APK into your repo :+1: . Besides courtesy, I don't think you'd need permission from me to do that though, e.g. APK Mirror does the same hundredfold without asking anyone :thinking:. It is nice to ask though, a little more courtesy in the world never hurts :smile:.
@Grossdm Not sure how much helps this is though as users would still need to add his repo, and @IzzySoft still has to manually update the APK too.

@d4rken yes, but courtesy never hurts :smile: Apart from that, in this case the special cause is the confusion it might arise for the unaware by "signature mismatch", so I wanted to make sure not to add another burden on you if you'd not be willing to risk it. Thanks for that!

IzzySoft still has to manually update the APK too.

No, I can enable auto-update here as I only pick the APK, so no build checks on my end. I only check tag names and timestamps (depending on whether I pick the APK from a tag or from a commit – here it will be the tag).
OK, revived it in my repo (was there before it moved to the official repo – good thing I always keep metadata backed up :rofl:). Should show up again with the next sync (next regular sync will run in about 20h).

Thanks to everyone for helping with this!

in this case the special cause is the confusion it might arise for the unaware by "signature mismatch", so I wanted to make sure not to add another burden on you if you'd not be willing to risk it. Thanks for that!

I'll just direct all angry messages to @Grossdm :man_shrugging: :smile:

I guess this can be closed now. I hope everyone has a nice weekend!

I guess this can be closed now.

Sure? How was the update in the official repo addressed? Did I miss something? Guess we have a nice work-around with the app being available in my repo again – but the original issue still remains.
Options we have (as I stated a week ago, slightly adjusted):

@Grossdm opens an issue at fdroiddata asking for an update
same, but asking to enable AutoUpdateMode: Version v%v
… opens an MR to achieve one of the above
someone else does one of the above
@d4rken asks someone to do some of the above (and specifies his preference)

Don't get me wrong: I happily keep your app in my repo. But I guess users would prefer having it in the official repo.
While we're on it: @d4rken would you consider establishing Fastlane (or Triple-T) with your repo – so provide e.g. screenshots? Both can be used with Playstore (if your app is there) and F-Droid as well, probably even with more. For my repo, I've picked the screenshots manually. Other things Fastlane helps provide are localized descriptions, a featureGraphic, per-release changelogs. If you're interested, I can give more details – or you check here for a starter and follow up the relevant links.

Sure?

Not really, it was premature. It's a time motivation/issue :frowning_face: .
I'm currently not able to work much on this, though I'm also not really motivated to do so. The whole thing was supposed to be more of a group effort with 20 or so devs on reddit saying they want to help. I just took the initiative as otherwise I doubt we would have gotten here at all.
We can do anything, someone just has to step up. Fastlane is awesome! If you want to add it, send a PR :wink:. Regarding the official F-droid Repo, if changing the version in the gradle file to allow parsing, then let's do it. I'm sure there are other projects on f-droid with a good way to solve the version parsing issue, someone should send a PR :stuck_out_tongue: .
My preference is that someone else than me should step up, anything not too far of from common practice is okay.

I'm fully with you (which is why I suggested keeping this issue open until really solved). I'm not a dev, though, not even using Reddit myself and already loaded with many other tasks – so I cannot fill those gaps myself.
Thanks!

@IzzySoft,
I'd like to do more, but I am out of my depth here.
For example, I don't know what AutoUpdateMode: Version v%v is.
Honestly, it's a bit frustrating to see so many potential solutions proposed but no one willing to "pull the trigger".
If someone in this discussion knows what changes need to be made to a specific file (gradle?), I wonder why a PR is not opened.
🆘🔠🅿 (a few random emoji to show confusion)

I don't know what AutoUpdateMode: Version v%v is.

It describes by what pattern new versions can be detected. Here, with UpdateCheckMode: Tags, it's a pattern on tag names saying the tag name is the Version (%v; aka versionName in gradle/Manifest) prefixed by a v. As that seems the pattern used here, it would enable F-Droid to automatically detect and queue updates – so this change would even work for future versions.
OK, so what: here you go. I've just prepared the MR to enable auto update check. I won't merge it myself (II've got no build experience, so I better leave it to another F-Droid member to cross-check if it works or I overlooked something). :crossed_fingers:

@d4rken currently we cannot enable auto update check it seems:

Won't work because version code and name are calculated: https://github.com/d4rken/reddit-android-appstore/blob/v0.9.2/app/build.gradle#L46

We'd need literals here (as update check just performs a simple RegEx scan, it doesn't "execute" the gradle just to check the version as that would be too much overload). Would that be possible?

Would that be possible?

https://github.com/d4rken/reddit-android-appstore/issues/184#issuecomment-498024625

Regarding the official F-droid Repo, if changing the version in the gradle file to allow parsing is the best solution, then let's do it.
Thanks! 😀 (These Pie emoji look strange to me, I hope I'm not posting offensive ones)

Hehe, yeah, "terminus confusius" :laughing:

@d4rken with F-Droid having caught up with the version, do you still want me to keep the app in my repo additionally?

@IzzySoft Up to you, if you want to spent time on it, I don't mind either way.
@Grossdm I assume this can now be closed?

OK, I'll remove it again then (to avoid the confusion arising from "signature mismatch" and "2 APKs with the same version"). It's really not much more than moving the metadata file out. Should the need arise again in the future, I can always move it back in, just ping me.

CCing myself as I have the same problem with Frost. If I find a solution to my app I'll let you know

@AllanWang it's on our wish list for quite a while, but nobody found time yet to implement it. I wouldn't even know where to start (not my area of proficiency). I'm pretty sure if someone made a sound MR, that would be accepted very gladly: working auto-updates reduce the load on our packagers as well and would keep the backlog of manual updates much smaller. If someone wants to look into it: my guess is this place is the context of what would need tweaking, and this would be the function to be tweaked.

@IzzySoft I'll take a look, but on a quick glance the code seems to look at build directories and Android manifest, which seems to be after a gradle build. If there are enforced checks before any function call, then there wouldn't be any reliable way to get the version code beyond regex, as everyone would have their own way. And even if we were allowed to supply the version some other way, it would defeat the purpose as it might not match the actual version.
With that, I feel the only way this will work is if f-droid is willing to forgo version checks pre build, or allow for some version check function beforehand (eg through a pre build command)

@AllanWang The gradle checks start here. And AFAIU the idea is to make sure we have a new version (higher versionCode) before we clone the repo. Imagine on each run we'd have to clone several thousand repos just to figure which ones have valid updates 😱
As indicated, I'm not much involved with fdroidserver coding (true, I supplied a few minor tweaks – but nothing on that level), so I'm obviously the wrong person to give good advice. So what I say here is just how I understand it: I cannot speak for the team really working on fdroidserver. I guess what might be acceptable is along the lines: "New tag? Clone, check. Everything fine? Build. Issues (versionCode not increased etc.)? place a marker which tag we checked so we skip it next time." That "marker" could e.g. be a disabled build block for that tag (disabled: <reason>, e.g. disabled: versionCode not increased). But then, that would mean fixing it requires a new tag.
Well, here is certainly the wrong place to discuss this. I just looked where we had it; so may I suggest moving this to Support checkupdate for dynamically generated versioncodes/versionnames? Also relevant in this context: Auto-Update: Support reading Flutter pubspec.yaml files concerning Flutter.


Can't search by package id

Looks like raccoon doesn't work well anymore. I can't search or download by name of package id.
Search results of: "pname:com.facebook.lite" return blank page.
Search results of: "com.facebook.lite" return related apps.

Paid support is available as part of the Raccoon Premium package. That's how the project is financed. Please do not try to work around this by abusing the bug tracker as a support forum.


(FACT-1296) Avoid transient unit test failure

We've seen transient unit test failures due to the test fixture that
creates and deletes a directory. Add a loop check to ensure the
directory is deleted (with a 5-second timeout) to avoid continuing until
previous tests are cleaned up.

It looks like mingw wants the same treatment you provided in https://github.com/puppetlabs/cpp-pcp-client/commit/f478d7dcc4e41deae63d1de1bf777a2db0c7617a.

Updated.

CLA signed by all contributors.

Woo, @puppetcla party!


Disable modal version of dropdown menu on mobile

When using a dropdown as a popover, which according to #113 and #103, is the recommended solution, I noticed that when clickable they are presented as a modal on mobile (hoverable dropdowns are presented normally).
Is there a way to disable the modal on mobile? I don't see anything in the documentation or the API regarding this.  It seems like this should be something that is configurable, that a modal would always work for a dropdown seems like a pretty big assumption.
Thanks in advance, if this is not currently supported would you accept a PR for it?

@ryantbrown At the moment only hovered and inline props disable modal on mobile.
You can create a PR and we'll review it.

@jtommy - I was excited to see this issue was fixed, but I'm unfortunately not able to get it to work. I added mobil-model="false" to b-dropdown, but it still shows as a modal on smaller width screens. Have I made a dumb mistake or am I misunderstanding how it's supposed to work?
The way I recreated here was simply dragging the divider between the view and the code further to the left to simulate a small screen.
https://codepen.io/anon/pen/XZBGxG?editors=1010

@grebebird You have to bind that prop because it accept only Boolean, for example :mobile-modal="false"


fixfix func array_enumerate_uniq with param is nullable return

Proposed changes
Issue Number: close #xxx

run buildall

run cloud_p0

run cloud_p0

run buildall