Fix ConcurrentModificationException in DefaultSerializerRegistry

Fixes https://github.com/JLLeitschuh/ktlint-gradle/issues/518
Context
This is a very naive fix for the ConcurrentModificationException in DefaultSerializerRegistry.
This is the exception a user of the Ktlint Gradle project was getting:

Stack Trace

* What went wrong:
Execution failed for task ':feedback:loadKtlintReporters'.
> A failure occurred while executing org.jlleitschuh.gradle.ktlint.worker.LoadReportersWorkAction
   > Could not serialize unit of work.
      > java.util.ConcurrentModificationException (no error message)

Try:
Run with --info or --debug option to get more log output. Run with --scan to get full insights.

Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':feedback:loadKtlintReporters'.
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.lambda$executeIfValid$1(ExecuteActionsTaskExecuter.java:188)
at org.gradle.internal.Try$Failure.ifSuccessfulOrElse(Try.java:282)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeIfValid(ExecuteActionsTaskExecuter.java:186)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:174)
at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:109)
at org.gradle.api.internal.tasks.execution.FinalizePropertiesTaskExecuter.execute(FinalizePropertiesTaskExecuter.java:46)
at org.gradle.api.internal.tasks.execution.ResolveTaskExecutionModeExecuter.execute(ResolveTaskExecutionModeExecuter.java:51)
at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:57)
at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:56)
at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:36)
at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:77)
at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:55)
at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52)
at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:200)
at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:195)
at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:75)
at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:68)
at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:153)
at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:68)
at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:62)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.lambda$call$2(DefaultBuildOperationExecutor.java:79)
at org.gradle.internal.operations.UnmanagedBuildOperationWrapper.callWithUnmanagedSupport(UnmanagedBuildOperationWrapper.java:54)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:79)
at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter.execute(EventFiringTaskExecuter.java:52)
at org.gradle.execution.plan.LocalTaskNodeExecutor.execute(LocalTaskNodeExecutor.java:74)
at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:402)
at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:389)
at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:382)
at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:368)
at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.lambda$run$0(DefaultPlanExecutor.java:127)
at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.execute(DefaultPlanExecutor.java:191)
at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.executeNextNode(DefaultPlanExecutor.java:182)
at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.run(DefaultPlanExecutor.java:124)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:61)
Caused by: org.gradle.workers.internal.DefaultWorkerExecutor$WorkExecutionException: A failure occurred while executing org.jlleitschuh.gradle.ktlint.worker.LoadReportersWorkAction
at org.gradle.workers.internal.DefaultWorkerExecutor.lambda$submitWork$2(DefaultWorkerExecutor.java:208)
at org.gradle.internal.work.DefaultConditionalExecutionQueue$ExecutionRunner.runExecution(DefaultConditionalExecutionQueue.java:214)
at org.gradle.internal.work.DefaultConditionalExecutionQueue$ExecutionRunner.runBatch(DefaultConditionalExecutionQueue.java:164)
at org.gradle.internal.work.DefaultConditionalExecutionQueue$ExecutionRunner.run(DefaultConditionalExecutionQueue.java:131)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:61)
Caused by: org.gradle.workers.internal.WorkSerializationException: Could not serialize unit of work.
at org.gradle.workers.internal.DefaultActionExecutionSpecFactory.serialize(DefaultActionExecutionSpecFactory.java:79)
at org.gradle.workers.internal.DefaultActionExecutionSpecFactory.newTransportableSpec(DefaultActionExecutionSpecFactory.java:42)
at org.gradle.workers.internal.IsolatedClassloaderWorkerFactory$1.lambda$execute$0(IsolatedClassloaderWorkerFactory.java:51)
at org.gradle.workers.internal.AbstractWorker$1.call(AbstractWorker.java:44)
at org.gradle.workers.internal.AbstractWorker$1.call(AbstractWorker.java:41)
at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:200)
at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:195)
at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:75)
at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:68)
at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:153)
at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:68)
at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:62)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.lambda$call$2(DefaultBuildOperationExecutor.java:79)
at org.gradle.internal.operations.UnmanagedBuildOperationWrapper.callWithUnmanagedSupport(UnmanagedBuildOperationWrapper.java:54)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:79)
at org.gradle.workers.internal.AbstractWorker.executeWrappedInBuildOperation(AbstractWorker.java:41)
at org.gradle.workers.internal.IsolatedClassloaderWorkerFactory$1.execute(IsolatedClassloaderWorkerFactory.java:49)
at org.gradle.workers.internal.DefaultWorkerExecutor.lambda$submitWork$2(DefaultWorkerExecutor.java:206)
... 6 more
Caused by: java.util.ConcurrentModificationException
at org.gradle.internal.serialize.DefaultSerializerRegistry.build(DefaultSerializerRegistry.java:84)
at org.gradle.workers.internal.IsolatableSerializerRegistry.writeIsolatable(IsolatableSerializerRegistry.java:129)
at org.gradle.workers.internal.IsolatableSerializerRegistry$IsolatedManagedValueSerializer.write(IsolatableSerializerRegistry.java:345)
at org.gradle.workers.internal.IsolatableSerializerRegistry$IsolatedManagedValueSerializer.write(IsolatableSerializerRegistry.java:338)
at org.gradle.workers.internal.IsolatableSerializerRegistry.writeIsolatable(IsolatableSerializerRegistry.java:129)
at org.gradle.workers.internal.IsolatableSerializerRegistry.writeIsolatableSequence(IsolatableSerializerRegistry.java:142)
at org.gradle.workers.internal.IsolatableSerializerRegistry.access$2200(IsolatableSerializerRegistry.java:62)
at org.gradle.workers.internal.IsolatableSerializerRegistry$IsolatedArraySerializer.write(IsolatableSerializerRegistry.java:515)
at org.gradle.workers.internal.IsolatableSerializerRegistry$IsolatedArraySerializer.write(IsolatableSerializerRegistry.java:510)
at org.gradle.workers.internal.IsolatableSerializerRegistry.writeIsolatable(IsolatableSerializerRegistry.java:129)
at org.gradle.workers.internal.IsolatableSerializerRegistry$IsolatedManagedValueSerializer.write(IsolatableSerializerRegistry.java:345)
at org.gradle.workers.internal.IsolatableSerializerRegistry$IsolatedManagedValueSerializer.write(IsolatableSerializerRegistry.java:338)
at org.gradle.workers.internal.IsolatableSerializerRegistry.writeIsolatable(IsolatableSerializerRegistry.java:129)
at org.gradle.workers.internal.DefaultActionExecutionSpecFactory.serialize(DefaultActionExecutionSpecFactory.java:76)
... 23 more

I'm not entirely certain how to unit test this change best. Any suggestions welcome.
Contributor Checklist

[ ] Review Contribution Guidelines
[ ] Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
[ ] Make sure all contributed code can be distributed under the terms of the Apache License 2.0, e.g. the code was written by yourself or the original code is licensed under a license compatible to Apache License 2.0.
[ ] Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team
[ ] Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective
[ ] Provide unit tests (under <subproject>/src/test) to verify logic
[ ] Update User Guide, DSL Reference, and Javadoc for public-facing changes
[ ] Ensure that tests pass sanity check: ./gradlew sanityCheck
[ ] Ensure that tests pass locally: ./gradlew <changed-subproject>:quickTest

Gradle Core Team Checklist

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation
[ ] Recognize contributor in release notes

No, I don't believe so. I think those two objects still require external locking when performing iteration over their elements. Please feel free to correct me if I'm mistaken.

@bot-gradle help

Currently, the following commands are supported:
@bot-gradle test <BuildStage>

triggers the specified build for this PR. This command takes a single argument, i.e. @bot-gradle test QF.  Common stages are:

SanityCheck/CompileAll/QuickFeedbackLinux/QuickFeedback/ReadyForMerge/ReadyForNightly/ReadyForRelease
Shortcuts: SC/CA/QFL/QF/RFM/RFN/RFR
Specific builds:

AST: AllSmokeTestsReadyForMerge
AFT: AllFunctionalTestsReadyForMerge
ASB: AllSpecificBuildsReadyForMerge
ACC: AllConfigCacheTestsReadyForMerge
ACT: AllCrossVersionTestsReadyForNightly
APTN: AllPerformanceTestsReadyForNightly
AFTN: AllFunctionalTestsReadyForNightly
ACTR: AllCrossVersionTestsReadyForRelease
AFTR: AllFunctionalTestsReadyForRelease

@bot-gradle test and merge

queues this PR for testing and merges if all tests pass by:

Creating a merge commit from your PR branch HEAD and the target branch
Running a ReadyForNightly build against the merge commit
When it passes, fast-forward the target branch to this merge commit (i.e. merge the PR)

The merge commit is called a pre-tested commit, which means that it fully tests the integration
of your branch HEAD and latest master, instead of only testing your branch HEAD.
@bot-gradle cancel

cancel a running pre-tested commit build or remove it from queue

@bot-gradle clean

clear the conversation history

@bot-gradle help

display this message

To run a command, simply submit a comment.  For detailed instructions see here.

@bot-gradle test APTN

Sorry some internal error occurs, please contact the administrator @blindpirate

@bot-gradle test APTN

Sorry some internal error occurs, please contact the administrator @blindpirate

@bot-gradle test AllPerformanceTestsReadyForNightly

Sorry some internal error occurs, please contact the administrator @blindpirate

I found some documentation that I think proves that iteration is safe without locking. In the doc page for ConcurrentSkipListMap, it says: "Iterators and spliterators are weakly consistent."
This means:

Most concurrent Collection implementations (including most Queues) also differ from the usual java.util conventions in that their Iterators and Spliterators provide weakly consistent rather than fast-fail traversal:

they may proceed concurrently with other operations
they will never throw ConcurrentModificationException
they are guaranteed to traverse elements as they existed upon construction exactly once, and may (but are not guaranteed to) reflect any modifications subsequent to construction.

The same is true for iterators over ConcurrentHashMap and the sets derived from it.
If these collections need to be kept in sync with each other, or with something else that is happening, then locking will be needed.

@bot-gradle test AllPerformanceTestsReadyForNightly

OK, I've already triggered AllPerformanceTestsReadyForNightly build for you.

@bot-gradle test AllPerformanceTestsReadyForNightly

OK, I've already triggered the following builds for you:

AllPerformanceTestsReadyForNightly build

@bot-gradle test AllPerformanceTestsReadyForNightly

OK, I've already triggered the following builds for you:

AllPerformanceTestsReadyForNightly build

@wolfs @ljacomet this is ready for a re-review

@bot-gradle test AllPerformanceTestsReadyForNightly

OK, I've already triggered the following builds for you:

AllPerformanceTestsReadyForNightly build

It's still relevant and the test that I have does reproduce the failure. This would be a good bug to fix.

Fixed up this change from review feedback

@JLLeitschuh Thank you for your PR! The fix will be included in Gradle 7.5.

Much appreciated! Hope you and the rest of the team are doing well! 🙂


Should fully specify the effect of using this intrinsic

We should fully specify in documentation the effects of the intrinsics.
In particular (relevant to me as I write this), for __noop(), its arguments are considered "referenced" by the compiler, so it can be used to silence warning C4100 "unreferenced formal parameter" and similar, wherever appropriate.
Example:
// Use __noop so assertions on variables that are not otherwise referenced won't cause "unreferenced" warnings.
#define MyAssert(c) do { assert(c); __noop(c); } while (false)

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

ID: 8bf760e5-e83c-219d-1ced-250f9e0760f2
Version Independent ID: a27b6550-93b1-8e60-7269-4079219c2ae7
Content: __noop
Content Source: docs/intrinsics/noop.md
Product: visual-cpp
Technology: cpp-tools
GitHub Login: @corob-msft
Microsoft Alias: corob

@TheJCAB
Your initial request is a bit too broad to address all at once. However, it's easy enough to mention the fact that the compiler considers __noop arguments referenced, so I added that and updated the sample.

Thank you!


Adding support for Enum types

Currently, GraphQLite has no support for GraphQL "enum" types.
This is because PHP has no native "enum" support.
Yet, there exists a number of alternatives: myclabs/php-enum, SplEnum, eloquent/enumeration...
The idea would be to detect any class representing an enum and mapping it to the GraphQL Enum type.
Using myclabs/php-enum, code could look like this:
class Status extends Enum
{
    private const ON = 'on';
    private const OFF = 'off';
    private const PENDING = 'pending';
}

class UserController {
    /**
     * @Query
     * @return User[]
     */
    public function viewUsers(Status $status): array {
        // ...
    }
}

The "$status" argument will automatically be mapped to an InputType named "Status" of GraphQL type enum, with 3 possible values ('on', 'off' and 'pending').
Support for major enum libraries should be built in GraphQLite, with the ability to add any other library.
Implementation details
To do this, we need to be able to get a hook at the root type mapping level of GraphQLite (in https://github.com/thecodingmachine/graphqlite/blob/master/src/FieldsBuilder.php#L682-L717)
We should probably replace the toGraphQlType method with an interface that can support many different implementation (one of which would be MyclabsEnumTypeMapper):
interface RawTypeMapper {
    private function toGraphQLType(Type $type, ?GraphQLType $subType, ReflectionMethod $refMethod, DocBlock $docBlockObj): ?GraphQLType;

    private function toGraphQLInputType(Type $type, ?GraphQLType $subType, string $argumentName, ReflectionMethod $refMethod, DocBlock $docBlockObj): ?GraphQLType;
}

:+1:


Haunted West Official Character Sheet Official Commit

The first commit for the Haunted West official character sheet.
Changes / Comments
Roll20 Requests
Comments are very helpful for reviewing the code changes. Please answer the relevant questions below in your comment.

[ ] Does the pull request title have the sheet name(s)? Include each sheet name.
[ ] Is this a bug fix?
[ ] Does this add functional enhancements (new features or extending existing features) ?
[ ] Does this add or change functional aesthetics (such as layout or color scheme) ?
[ ] If changing or removing attributes, what steps have you taken, if any, to preserve player data ?
[ ] If this is a new sheet, did you follow Building Character Sheets standards ?

If you do not know English. Please leave a comment in your native language.

Character Sheet Info Roll20 Internal Use only.


Generalise sync mechanism

I'm submitting a

[ ] bug report.
[x] feature request.

Current Behaviour:
Right now the agent uses sockets to sync itself with a hydrus server.
Expected Behaviour:
This will not work with a purely REST based Hydra server. We need to make the agent generic to work with non-hydrus based Hydra servers.
Steps to reproduce:

Do you want to work on this issue?

@chrizandr sure I would love to work on it

@chrizandr I haven't completely understood what has to been done. Should it be refactored by REST over Sockets?

@chrizandr  currently the hydrus uses a socket functionality as implemented by @Guttz  in his pull request https://github.com/HTTP-APIs/hydra-python-agent/pull/123, so I thing for making it generic we will require something like a generic Resource URIs so that we can communicate with them and maitain a table like structure to keep the records of sync updates.
Adding few Resource URI's like

api/last_updated
api/updates Am I getting it right?

@xadahiya  @Guttz  @Mec-iS ! kindly rectify if I am wrong!

sockets are only used for the synchronisation mechanism. Standard REST uses HTTP requests.
As explained multiple times, there are two separate subsystems in place:

the REST server endpoints: these are Hydra-described endpoints
the sync mechanism: this is a hydrus/agent specific functionality (not in the standard), to allow hydrus to push updates to the agent so to save requests

we want to keep this setup, so any change to this is not required.

@Mec-iS so as given by @chrizandr
Current Behaviour:
Right now the agent uses sockets to sync itself with a hydrus server.

Expected Behaviour:
This will not work with a purely REST based Hydra server. We need to make the agent generic to work with non-hydrus based Hydra servers.

Doesn't the expected behaviour requires to remove sockets since they won;t work with REST based Hydra Server, so can we include some sort of caching to reduce the request!

No. it implies adding HTTP requests when the server is not hydrus. In the case the server is not hydrus (but any other standard implementation), every time some data is needed in the agent it should issue a request to the server.

So, how do you propose to generalize the mechanism! @Mec-iS

the sync mechanism for a non-hydrus server is simply requesting data via an HTTP request everytime is needed. So we should have code in the agent that finds out if the server is hydrus and switch between two modes:

if hydrus: use requests AND receive updates on sockets (already implemented)
if not hydrus: use only requests (as any other REST client). In this case the agent won't use its local graph but will always issue a request (as it doesn't receive updates and it cannot guarantee the consistency of the data)

@Mec-iS Thanks a lot! I got it how will we generalize the mechanicms now!

Has this issue been resolved ?


Multiple serial devices

Is it possible to communicate with several serial ports, instead of one?
I want to interface with multiple Arduino boards from Unreal Engine using this plugin.

Okay, I figured that out.
To do that, I need to create several blueprints in my scene: each BP for each port I want to communicate with.
(I initially tried communicating with several ports right inside of the example blueprint. That was my mistake.)


Evaluation metric: accuracy

@running-man-01 going to merge this into a branch so we can pull from this repo, and test this in a docker contgainer.


Autocomplete Required Validation Not Working as Expected

🐛 Bug Report
Using the Autocomplete control, we are dynamically setting required to "true" when a different control is populated.
This properly sets the requirement; you cannot submit the form when the control is empty.
However, the issue is that field remains required and will not validate, even after you select a value.
💻 Repro or Code Sample

🤔 Expected Behavior
When we select a value in the autocomplete control, it should no longer say that the field is required, and allow the form to submit.
😯 Current Behavior

💁 Possible Solution
I suspect there is an additional property we need to set when a selection is made?
🔦 Context

🌍 Your Environment

.NET 9
Fluent UI Blazor library Version 4.10.4

You will find here an example of Autocomplete with Required property defined: https://fluentui-blazor.net/Forms
As indicated on this page :

The FluentAutocomplete component is not yet fully compatible with the EditForm and FluentEditForm elements. Some functionalities, such as error messages, the requirement message or the validation messages are missing.

Please supply us with ready-to-run reproduction code in the form of something we can copy/paste, a (zipped) project structure or a GitHub repository. We do not have capacity to craft or compose a reproduction for every issue that gets raised. If no code or repository is provided, this issue will be closed in 3 days.
Help us to help you. Thanks.

Thank you. I have attached a example of a required autocomplete control, that will still show the requirement message, even after a selection has been made.  Please let me know if I can provide additional context.  Thank you,BlazorTestApp.zip

Closing this as Denis mentioned in his second point that this is not a supported scenario


Date support

JSON dates are supported by NSJSONSerialization. They hydrate into instances of NSDate.

As I wrote in the README, I am interested in surfacing the constraints and simplicity of the JSON spec.
Since dates are not defined in JSON, I don't think asDate belongs in TypeJSON.

I see. It's your call. Given the ubiquity of ISO-8601 dates in JSON and the "just works" nature of that format in browsers and the standard parsers like Jackson, etc, it seems to have little risk compared to annoyance of NSDateFormatter.
You can close this.

For now at least, this library is going to be a bit philosophical when it comes to JSON.
Feel free to write some code if you'd like to discuss this more. :octocat:


Fixed some spelling mistakes

Issue #, if available:
Description of changes:  Fixed two spelling mistakes in the documentation.
Description of how you validated changes:
Checklist:

[ ] Write/update tests
[ ] make pr passes
[ ] Update documentation

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

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

@@           Coverage Diff           @@
##           master     #834   +/-   ##
=======================================
  Coverage   94.32%   94.32%
=======================================
  Files          67       67
  Lines        2626     2626
  Branches      464      464
=======================================
  Hits         2477     2477
  Misses         78       78
  Partials       71       71

Continue to review full report at Codecov.

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


if you make a mistake

there are a number of ways to make mistakes
a) deleting a folder when you haven't processed all the files in the folder
b) misnaming
c) when scanning, not telling the scanner that the stack of documents are all singles instead of a single document
do we need a second copy of every document that we keep in a "raw" location?
do we need to have some better way to track?  this goes back to keeping the checksum of each file so we could find it if we needed to
do we need to have a db instead (ugh)


fix(content-docs): properly display collocated social card image

Motivation
Missed in #6720 🤦♂ Diff is so deceptive! Takeaway: always require tests...
Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan
Added a test: https://deploy-preview-6744--docusaurus-2.netlify.app/tests/docs/tests/img-tests/

(Can't believe Webpack inlined all this stuff, the 10000 limit may be a bit too much...)

😄 thanks

What about using file-loader for the social image?

We don't really have a way to use file-loader instead of url-loader for a specific asset, it's all or nothing for all assets atm
But considering all this is temporary, undocumented and only used for social images, I guess we could always use file-loader here yes:
  // TODO implementation can be completed/enhanced
  function createAssetValueCode(assetValue: unknown): string | undefined {
    if (Array.isArray(assetValue)) {
      const arrayItemCodes = assetValue.map(
        (item) => createAssetValueCode(item) ?? 'undefined',
      );
      return `[${arrayItemCodes.join(', ')}]`;
    }
    // Only process string values starting with ./
    // We could enhance this logic and check if file exists on disc?
    if (typeof assetValue === 'string' && assetValue.startsWith('./')) {
      // TODO do we have other use-cases than image assets?
      // Probably not worth adding more support, as we want to move to Webpack 5 new asset system (https://github.com/facebook/docusaurus/pull/4708)
      const inlineLoader = inlineMarkdownImageFileLoader;
      return `require("${inlineLoader}${escapePath(assetValue)}").default`;
    }
    return undefined;
  }

Yes, that's essentially what I mean... Instead of ImageFileLoader we use LinkFileLoader.

Sorry für the trouble 🙈
The file-loader should be used in the content-blog plugin aswell. (And probably the pages plugin needs it aswell 🤔)


Add Probot as a curated topic

[X] I followed the contributing guidelines: https://github.com/github/explore/blob/master/CONTRIBUTING.md

I am:

[ ] Suggesting edits to an existing Topic page
[X] Curating a new Topic page

CURATING A NEW TOPIC PAGE

[X] I've formatted my changes as a new folder directory, named for the topic as it appears in the URL on GitHub (e.g. https://github.com/topics/[NAME])
[X] My folder contains a *.png image (if applicable) and index.md
[X] All required fields in my index.md conform to the Style Guide and API docs: https://github.com/github/explore/tree/master/docs

Please explain why you think this Topic page should be curated:
Probot is an extension of GitHub Apps, created and maintained by both Hubbers and the larger GitHub community. As more Apps are created, we want to ensure users can easily find Probot Apps and related extensions using topics.
cc @bkeepers in case you'd like to add/edit anything. I used March 2017 for the release based on the first release (0.2.0).
Please note: we will close your PR without comment if you do not check the boxes above and provide ALL requested information.

@cheshire137 Thanks for the review! I wasn't sure how much the machines would glean automatically! 🤖 LMK if you have any other tips to make this awesome. 💪


RSHELL  failed to access /dev/ttyUSB0

don't understand why RSHELL can't see my ESP32 when Picocom can.
rshell is version 0.0.11
Running Ububtu 16.04 on dell I7

I face same issue.
sudo chmod 777 /dev/ttyUSB0
Above command works for me  ;)

I added some notes to the rshell README: https://github.com/dhylands/rshell#serial-port-permissions-linux


Update

Guys, I suggest updating this boilerplate?

i doubt this is being maintained anymore

I don't have time to devote to it at the moment but PRs would be welcome.


Guides menu

Issue by moschel from Wednesday Oct 07, 2015 at 20:07 GMT
Originally opened as https://github.com/donejs/donejs/issues/203

Right now, the guides menu shows "Quick start" and "place-my-order" as the two options, which semantically doesn't make sense. place-my-order is the application to be built (confusing to someone first visiting the site) and Quick start is more of a user-centric phrase.
To make this consistent, I propose changing "place-my-order" to "Deep dive tutorial" to show that the first one is for a quick intro, the second a deeper look.

If you make this change, update the guides page: http://donejs.com/Guides.html

@daffl already did that


Fix losing team logic mistakenly flagging teams that haven't lost

Losing team logic is currently marking almost every team as having lost (greyed out in home page), something's bugged up

This was actually just because the season had closed & nobody had the 'winner' flag, so gonna go ahead & close this.


Support enums

We don't support encoding or decoding enums yet. Some interesting questions will arise when adding them.
Relevant material:

https://github.com/camelid/type-layout by @camelid
a very WIP writeup by @JakobDegen suggesting "DSLs" for describing very general encoding and decoding strategies for enums

Support for enums was added in the following PRs:

Enum variant ValueExpr
Enum memory representation and well-formedness
Enum Downcast
Enum GetDiscriminant and SetDiscriminant
Switch terminator
Alignment-check fixes (mainly around enums)
Changes to discriminant handling
Minimize support for everything enum related but niche tag encoding
Minimize support for niche tag encoded enums

Currently the only enums that cannot be minimized are exponentially nested enums (each enum has four variants with one field of the nested enum, see tests/pass/enums.rs) due to minimize always recompiling the type, and Option<NonZeroINT>::None, which gets transformed into a Scalar Value that minimize would have to parse.

One point I recently noticed is still missing is enums inside unions: mark_used_bytes does not support enums yet.

and Option::None, which gets transformed into a Scalar Value that minimize would have to parse.

That issue is tracked separately in https://github.com/minirust/minirust/issues/158.

I opened https://github.com/minirust/minirust/issues/167 for the enum-in-union issue. This one here can be closed then, thanks to @essickmango. :)


Should BurmillaOS support kubernetes?

I open this issues so that they give arguments that why we should support kubernetes in the project.
Specify concrete cases of use so we can make the best decision and if you give affirmative it helps us to make the documentation in a future.

I actually created a custom system service for k3s which I got up and running which basically gave me a lightweight k8s distro running on top of the user-docker instance. Worked fine expect for when restarting the service; when k3s server was running with the --docker flag it was bringing down the user-docker instance with it when shutting down during a restart of the service which stopped all of my other runnint containers in user-docker.
As I wasn't able to find the problem where k3s server --docker was using the docker socket to close the docker daemon too I abandoned the experiment.
If this could be solved then having a k3s service could be doable.

I actually created a custom system service for k3s which I got up and running which basically gave me a lightweight k8s distro running on top of the user-docker instance. Worked fine expect for when restarting the service; when k3s server was running with the --docker flag it was bringing down the user-docker instance with it when shutting down during a restart of the service which stopped all of my other runnint containers in user-docker.
As I wasn't able to find the problem where k3s server --docker was using the docker socket to close the docker daemon too I abandoned the experiment.
If this could be solved then having a k3s service could be doable.

Adding k3s with --docker switch at least does not make any sense as support for it will be removed on near future. (Look: https://github.com/burmilla/os/issues/22#issuecomment-738593722 )
Packaging k3s + containerd to own separated system service most probably would works but it leaves open the question that what is the point? Why not using just k3OS then?
Also the reality is that currently I'm doing most of the BurmillaOS maintenance my self on my spare time which puts some limitations to that what is really doable. So minimum requirement that we are able to support Kubernetes is find someone who will do most of the maintenance related to that one but then again it is quite unclear for me that why anyone would do that as they can just participate k3OS maintenance?

Adding k3s with --docker switch at least does not make any sense as support for it will be removed on near future. (Look: https://github.com/burmilla/os/issues/22#issuecomment-738593722 )
Packaging k3s + containerd to own separated system service most probably would works but it leaves open the question that what is the point? Why not using just k3OS then?
Also the reality is that currently I'm doing most of the BurmillaOS maintenance my self on my spare time which puts some limitations to that what is really doable. So minimum requirement that we are able to support Kubernetes is find someone who will do most of the maintenance related to that one but then again it is quite unclear for me that why anyone would do that as they can just participate k3OS maintenance?

What does it mean by "support kubernetes"?
I'm running Kubernetes on RancherOS and are planning to jump over to BurmillaOS in the future.

What does it mean by "support kubernetes"?

@Raboo if we decide that we do not support Kubernetes it means that all bug reports which cannot be repeated without Kubernetes will be closed with "wontfix" label. It also means that we do not need to care about fact that it might be impossible run Kubernetes top of RancherOS/BurmillaOS after their CRI migration is ready and Docker support is removed https://www.theregister.com/AMP/2020/12/03/docker_deprecated_in_kubernetes_this/

I'm running Kubernetes on RancherOS and are planning to jump over to BurmillaOS in the future.

As short term solution that most probably works just fine but I still highly recommend for all Kubernetes users to investigate other distros (e.g. k3OS, Fedora CoreOS, etc) which focuses to support Kubernetes also on long term.
PS. Company where I'm working on is nowadays also piloting RKE2 as long term replacement for Docker Swarm and will most probably use it with "RKE2 OS" if Rancher eventually releases it (currently there is only rumor that it might happen).

Also the reality is that currently I'm doing most of the BurmillaOS maintenance my self on my spare time which puts some limitations to that what is really doable. So minimum requirement that we are able to support Kubernetes is find someone who will do most of the maintenance related to that one but then again it is quite unclear for me that why anyone would do that as they can just participate k3OS maintenance?

We are very happy to help on maintenaning this project and do contribution, since it could be part of our business.
The problem is we don't have enough doc/info how to replace/upgrade kernel/rootfs/initrd/service in this project.
Actually, I have tried some days on build a new kernel with source code from kernel.org, but the whole system can not boot up. Could you please share us the process of upgrading kernel and rootfs etc.?
My mail is<EMAIL_ADDRESS>please drop me a mail, and let's make this project more active!

@wonleing plz join to our Discord https://github.com/burmilla/os/issues/10#issuecomment-735303983 where trying to have some kind of project leading discussion.

@wonleing btw also plz share more details about your use case(s) on #6

For everyone who is planning to run Kubernetes on top of BurmillaOS on longterm. Please check my new architecture proposal on #88

To me, running Kubernetes/K3S on top of BurmillaOS is a MUST have feature for Bare Metal solution.
So I would take effort to make this happen

@wonleing btw. I just remembered that feat/k3s-support branch contains draft version of K3s support which I once started to implement but don't remember which state it.
Idea on that one was test if it is possible to support enabling K3s as parallel with user docker. Service configuration exist on https://github.com/burmilla/os-services/tree/feat/k3s

BurmillaOS should native use docker. That's why I use BurmillaOS instead of k3os.
k3s as a Burmilla system-docker service would be nice addition to user-docker.

I agree with @pwFoo here. This is why I've used RancherOS all along, but going to upgrade to BurmillaOS due to recent changes in Alpine that cause havoc with Make and Docker as described here
If first-class for k8s or k3s is added to BurmillaOS, I'd be fine with that as long as it didn't break any existing use-cases or functionality and is/was completely optional. I'd also not want to see the ISO size increase just to support this, as that (for me) would incur additional resource costs I don't need or want.

FYI for those who are running Kubernetes on RancherOS/BurmillaOS: Recently released Kubernetes 1.23 does not support Docker anymore.
In theory it might be possible to continue to use Docker still as runtime with https://github.com/Mirantis/cri-dockerd but I highly recommend to consider containerd instead of.

Oh well 😂 No loss for me, let's close this issue 😅

FYI, new interesting option for BurmillaOS users who want utilize K8s tooling without maintaining actusl K8s https://www.k2d.io (created by Portainer team).


Module for Kafka communication

We should provide sources and sinks for Kafka connectivity. Not all users would like to go down the Kafka streams road.

Should create modules for different integrations

With the move to Gradle modules are now a breeze


Enable using the Google Design library (and alike) with "library add" command

Recently Google announced the Google Design library availability. The problem is that it is distributed in a format which is not supported by our library add command.
It has a dependency on the three things:

It has resources inside the sdk folders
It depends on the AppCompat library
It depends on the Support SDK v7.

What should be the changes required in the runtime and in CLI in order this type of libraries to be added without manual steps?

I did a small project and it seems only the CLI should be changed. So far, I didn't see any need to change the runtime or metadata generator.

With the new Gradle build system in 1.3, this should be available.


How to access local startup service first

How to access local startup service first

Can you please describe in more detail what you mean and how it relates to gateway?

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.


Image disappears from the screen, when the link is scrolled up (and it leaves empty space)

https://imgur.com/gallery/image-nvim-image-disapperas-on-scroll-F86aqsY
I saw in your demonstration that you were able to scroll through the images without any issue. Is there some configuration for that?

I am using latest kitty on archlinux, with almost default config
package.path = package.path .. ";" .. vim.fn.expand("$HOME") .. "/.luarocks/share/lua/5.1/?/init.lua"
package.path = package.path .. ";" .. vim.fn.expand("$HOME") .. "/.luarocks/share/lua/5.1/?.lua"
-- default config
require("image").setup({
	backend = "kitty",
	integrations = {
		markdown = {
			enabled = true,
			clear_in_insert_mode = false,
			download_remote_images = true,
			only_render_image_at_cursor = false,
			filetypes = { "markdown", "vimwiki" }, -- markdown extensions (ie. quarto) can go here
		},
		neorg = {
			enabled = true,
			clear_in_insert_mode = false,
			download_remote_images = true,
			only_render_image_at_cursor = false,
			filetypes = { "norg" },
		},
	},
	max_width = nil,
	max_height = nil,
	max_width_window_percentage = nil,
	max_height_window_percentage = 50,
	window_overlap_clear_enabled = false, -- toggles images when windows are overlapped
	window_overlap_clear_ft_ignore = { "cmp_menu", "cmp_docs", "" },
	editor_only_render_when_focused = false, -- auto show/hide images when the editor gains/looses focus
	tmux_show_only_in_active_window = false, -- auto show/hide images in the correct Tmux window (needs visual-activity off)
	hijack_file_patterns = { "*.png", "*.jpg", "*.jpeg", "*.gif", "*.webp" }, -- render image files as images when opened
})

Hey, it's not a config issue, it's something that was disabled and comes from here: https://github.com/3rd/image.nvim/blob/master/lua/image/renderer.lua#L169
I was just looking into this yesterday (rewrite in progress), and we need to get the amount of displayed virtual lines above the topline  to make it work, and as there's no API to get it on demand we'll have to setup viewport listeners and track the virtual top fill for all the windows.
Looking for a quick way to add it in the current version.

@printfdebugging should work now


Unable to release ipa, apk.

Hi, I have troble issue releasing ipa and apk files.
On debug mode all works fine, but can't archive and releaase.
Here is my refs:
build.gradle
// Top-level build file where you can add configuration options common to all sub-projects/modules.
buildscript {
  ext {
    buildToolsVersion = "28.0.2"
    minSdkVersion = 21
    compileSdkVersion = 28
    targetSdkVersion = 26
    supportLibVersion = "27.1.0"
    multiDexEnabled = true
  }
  repositories {
    google()
    jcenter()
    maven {
      url 'https://maven.fabric.io/public'
    }
  }
  dependencies {
    classpath 'com.android.tools.build:gradle:3.2.0'
    classpath 'com.google.gms:google-services:4.0.1'
    classpath 'com.google.firebase:firebase-plugins:1.1.5'
    classpath 'io.fabric.tools:gradle:1.25.4'
    // NOTE: Do not place your application dependencies here; they belong
    // in the individual module build.gradle files
  }
}

allprojects {
  repositories {
    mavenLocal()
    google()
    jcenter()
    maven {
      // All of React Native (JS, Obj-C sources, Android binaries) is installed from npm
      url "$rootDir/../node_modules/react-native/android"
    }
  }
}

task wrapper(type: Wrapper) {
  gradleVersion = '4.10'
  distributionUrl = distributionUrl.replace("bin", "all")
}

android/app/build.gradle
apply plugin: "com.android.application"
apply plugin: "com.google.firebase.firebase-perf"
apply plugin: 'io.fabric'

import com.android.build.OutputFile

/**
 * The react.gradle file registers a task for each build variant (e.g. bundleDebugJsAndAssets
 * and bundleReleaseJsAndAssets).
 * These basically call `react-native bundle` with the correct arguments during the Android build
 * cycle. By default, bundleDebugJsAndAssets is skipped, as in debug/dev mode we prefer to load the
 * bundle directly from the development server. Below you can see all the possible configurations
 * and their defaults. If you decide to add a configuration block, make sure to add it before the
 * `apply from: "../../node_modules/react-native/react.gradle"` line.
 *
 * project.ext.react = [
 *   // the name of the generated asset file containing your JS bundle
 *   bundleAssetName: "index.android.bundle",
 *
 *   // the entry file for bundle generation
 *   entryFile: "index.android.js",
 *
 *   // whether to bundle JS and assets in debug mode
 *   bundleInDebug: false,
 *
 *   // whether to bundle JS and assets in release mode
 *   bundleInRelease: true,
 *
 *   // whether to bundle JS and assets in another build variant (if configured).
 *   // See http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Build-Variants
 *   // The configuration property can be in the following formats
 *   //         'bundleIn${productFlavor}${buildType}'
 *   //         'bundleIn${buildType}'
 *   // bundleInFreeDebug: true,
 *   // bundleInPaidRelease: true,
 *   // bundleInBeta: true,
 *
 *   // whether to disable dev mode in custom build variants (by default only disabled in release)
 *   // for example: to disable dev mode in the staging build type (if configured)
 *   devDisabledInStaging: true,
 *   // The configuration property can be in the following formats
 *   //         'devDisabledIn${productFlavor}${buildType}'
 *   //         'devDisabledIn${buildType}'
 *
 *   // the root of your project, i.e. where "package.json" lives
 *   root: "../../",
 *
 *   // where to put the JS bundle asset in debug mode
 *   jsBundleDirDebug: "$buildDir/intermediates/assets/debug",
 *
 *   // where to put the JS bundle asset in release mode
 *   jsBundleDirRelease: "$buildDir/intermediates/assets/release",
 *
 *   // where to put drawable resources / React Native assets, e.g. the ones you use via
 *   // require('./image.png')), in debug mode
 *   resourcesDirDebug: "$buildDir/intermediates/res/merged/debug",
 *
 *   // where to put drawable resources / React Native assets, e.g. the ones you use via
 *   // require('./image.png')), in release mode
 *   resourcesDirRelease: "$buildDir/intermediates/res/merged/release",
 *
 *   // by default the gradle tasks are skipped if none of the JS files or assets change; this means
 *   // that we don't look at files in android/ or ios/ to determine whether the tasks are up to
 *   // date; if you have any other folders that you want to ignore for performance reasons (gradle
 *   // indexes the entire tree), add them here. Alternatively, if you have JS files in android/
 *   // for example, you might want to remove it from here.
 *   inputExcludes: ["android/**", "ios/**"],
 *
 *   // override which node gets called and with what additional arguments
 *   nodeExecutableAndArgs: ["node"],
 *
 *   // supply additional arguments to the packager
 *   extraPackagerArgs: []
 * ]
 */

project.ext.react = [
  entryFile: "index.js"
]

apply from: "../../node_modules/react-native/react.gradle"

/**
 * Set this to true to create two separate APKs instead of one:
 *   - An APK that only works on ARM devices
 *   - An APK that only works on x86 devices
 * The advantage is the size of the APK is reduced by about 4MB.
 * Upload all the APKs to the Play Store and people will download
 * the correct one based on the CPU architecture of their device.
 */
def enableSeparateBuildPerCPUArchitecture = false

/**
 * Run Proguard to shrink the Java bytecode in release builds.
 */
def enableProguardInReleaseBuilds = false

android {
  lintOptions {
    disable 'GradleCompatible'
    disable 'InvalidPackage'
  }

  // because of firestore:
  dexOptions {
    javaMaxHeapSize "4g"
  }
  compileSdkVersion rootProject.ext.compileSdkVersion
  buildToolsVersion rootProject.ext.buildToolsVersion

  defaultConfig {
    applicationId "com.crowdbotics.yapstars"
    minSdkVersion rootProject.ext.minSdkVersion
    targetSdkVersion rootProject.ext.targetSdkVersion
    versionCode 1
    versionName "1.0"
    ndk {
      abiFilters "armeabi-v7a", "x86"
    }
    // because of firestore:
    multiDexEnabled true
  }
  signingConfigs {
    release {
      if (project.hasProperty('MYAPP_RELEASE_STORE_FILE')) {
        storeFile file(MYAPP_RELEASE_STORE_FILE)
        storePassword MYAPP_RELEASE_STORE_PASSWORD
        keyAlias MYAPP_RELEASE_KEY_ALIAS
        keyPassword MYAPP_RELEASE_KEY_PASSWORD
      }
    }
  }
  splits {
    abi {
      reset()
      enable enableSeparateBuildPerCPUArchitecture
      universalApk false  // If true, also generate a universal APK
      include "armeabi-v7a", "x86"
    }
  }
  buildTypes {
    release {
      minifyEnabled enableProguardInReleaseBuilds
      proguardFiles getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro"
      signingConfig signingConfigs.release
    }
    debug {
      minifyEnabled false
      proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
    }
  }
  // applicationVariants are e.g. debug, release
  applicationVariants.all { variant ->
    variant.outputs.each { output ->
      // For each separate APK per architecture, set a unique version code as described here:
      // http://tools.android.com/tech-docs/new-build-system/user-guide/apk-splits
      def versionCodes = ["armeabi-v7a": 1, "x86": 2]
      def abi = output.getFilter(OutputFile.ABI)
      if (abi != null) {  // null for the universal-debug, universal-release variants
        output.versionCodeOverride =
          versionCodes.get(abi) * 1048576 + defaultConfig.versionCode
      }
    }
  }
}

dependencies {
    implementation project(':react-native-twitter-signin')
    implementation project(':react-native-google-signin')
    implementation project(':react-native-webview')

    implementation 'com.facebook.android:facebook-android-sdk:4.34.0'
    //implementation project(':react-native-fbsdk')
    implementation project(':react-native-fbsdk')
  implementation 'com.android.support:multidex:1.0.3'
  implementation 'com.android.support:design:27.1.0'

  implementation project(':react-native-gesture-handler')
  implementation project(':react-native-firebase')
  implementation project(':react-native-fast-image')
  implementation project(':react-native-vector-icons')

  //noinspection GradleDynamicVersion
  implementation "com.facebook.react:react-native:+"
  implementation fileTree(dir: "libs", include: ["*.jar"])

   implementation "com.android.support:appcompat-v7:${rootProject.ext.supportLibVersion}"

/* ----------------------------
   *    REACT NATIVE FIREBASE
   * ---------------------------- */

  // Library as defined in settings.gradle
  // implementation project(path: ':react-native-firebase', configuration: 'default')
  // Required dependencies
  //noinspection GradleCompatible
  implementation "com.google.firebase:firebase-core:16.0.6"
  implementation "com.google.android.gms:play-services-base:16.0.1"

  /* -------------------------
   *   OPTIONAL FIREBASE SDKS
   * ------------------------- */

  implementation('com.google.firebase:firebase-ads:15.0.1') {
    // exclude `customtabs` as the support lib version is out of date
    // we manually add it as a dependency below with a custom version
    exclude group: 'com.android.support', module: 'customtabs'
  }

  // Authentication
  implementation "com.google.firebase:firebase-auth:16.1.0"
  // Analytics
  implementation "com.google.firebase:firebase-analytics:16.0.6"
  // Performance Monitoring
  implementation "com.google.firebase:firebase-perf:16.2.3"
  // Remote Config
  implementation "com.google.firebase:firebase-config:16.1.2"
  // Cloud Storage
  implementation "com.google.firebase:firebase-storage:16.0.5"
  // Invites
  implementation "com.google.firebase:firebase-invites:16.0.6"
  // Dynamic Links
  implementation "com.google.firebase:firebase-dynamic-links:16.1.5"
  // Real-time Database
  implementation "com.google.firebase:firebase-database:16.0.5"
  // Cloud Functions
  implementation "com.google.firebase:firebase-functions:16.1.3"
  // Cloud Firestore
  implementation "com.google.firebase:firebase-firestore:17.1.5"
  // Cloud Messaging / FCM
  implementation "com.google.firebase:firebase-messaging:17.3.4"
  // Crashlytics
  implementation('com.crashlytics.sdk.android:crashlytics:2.9.5@aar') {
    transitive = true
  }

  /* --------------------------------
   *  OPTIONAL SUPPORT LIBS
   * -------------------------------- */

  // For Firebase Ads
  implementation "com.android.support:customtabs:27.1.1"

  // For React Native Firebase Notifications
  implementation 'me.leolin:ShortcutBadger:1.1.21@aar'
}

// Run this once to be able to run the application with BUCK
// puts all compile dependencies into folder libs for BUCK to use
task copyDownloadableDepsToLibs(type: Copy) {
  from configurations.compile
  into 'libs'
}

subprojects {
    project.configurations.all {
        resolutionStrategy.eachDependency { details ->
            if (details.requested.group == 'com.android.support'
                    && !details.requested.name.contains('multidex') ) {
                details.useVersion "27.1.1"
            }
        }
    }
    afterEvaluate {
        android {
            compileSdkVersion 27
            buildToolsVersion "27.0.3"

            defaultConfig {
                targetSdkVersion 27
            }
        }
    }
}

apply plugin: 'com.google.gms.google-services'
apply from: "../../node_modules/react-native-vector-icons/fonts.gradle"
com.google.gms.googleservices.GoogleServicesPlugin.config.disableVersionCheck = true

result
Parallel execution with configuration on demand is an incubating feature.

> Configure project :app
WARNING: The option 'android.enableAapt2' is deprecated and should not be used anymore.
Use 'android.enableAapt2=true' to remove this warning.
It will be removed at the end of 2018..
Could not find google-services.json while looking in [src/nullnull/debug, src/debug/nullnull, src/nullnull, src/debug, src/nullnullDebug]
registerResGeneratingTask is deprecated, use registerGeneratedResFolders(FileCollection)
Could not find google-services.json while looking in [src/nullnull/release, src/release/nullnull, src/nullnull, src/release, src/nullnullRelease]
registerResGeneratingTask is deprecated, use registerGeneratedResFolders(FileCollection)

> Configure project :react-native-fast-image
WARNING: The option 'android.enableAapt2' is deprecated and should not be used anymore.
Use 'android.enableAapt2=true' to remove this warning.
It will be removed at the end of 2018..

> Configure project :react-native-fbsdk
WARNING: The option 'android.enableAapt2' is deprecated and should not be used anymore.
Use 'android.enableAapt2=true' to remove this warning.
It will be removed at the end of 2018..

> Configure project :react-native-firebase
WARNING: The option 'android.enableAapt2' is deprecated and should not be used anymore.
Use 'android.enableAapt2=true' to remove this warning.
It will be removed at the end of 2018..
react-native-firebase: using React Native prebuilt binary from /Volumes/Data/ReactNative/crowdbotics/yapstars-2338/node_modules/react-native/android

> Configure project :react-native-gesture-handler
WARNING: The option 'android.enableAapt2' is deprecated and should not be used anymore.
Use 'android.enableAapt2=true' to remove this warning.
It will be removed at the end of 2018..

> Configure project :react-native-google-signin
WARNING: The option 'android.enableAapt2' is deprecated and should not be used anymore.
Use 'android.enableAapt2=true' to remove this warning.
It will be removed at the end of 2018..

> Configure project :react-native-twitter-signin
WARNING: The option 'android.enableAapt2' is deprecated and should not be used anymore.
Use 'android.enableAapt2=true' to remove this warning.
It will be removed at the end of 2018..
WARNING: The specified Android SDK Build Tools version (27.0.3) is ignored, as it is below the minimum supported version (28.0.2) for Android Gradle Plugin 3.2.0.
Android SDK Build Tools 28.0.2 will be used.
To suppress this warning, remove "buildToolsVersion '27.0.3'" from your build.gradle file, as each version of the Android Gradle Plugin now has a default version of the build tools.

> Configure project :react-native-vector-icons
WARNING: The option 'android.enableAapt2' is deprecated and should not be used anymore.
Use 'android.enableAapt2=true' to remove this warning.
It will be removed at the end of 2018..

> Configure project :react-native-webview
WARNING: The option 'android.enableAapt2' is deprecated and should not be used anymore.
Use 'android.enableAapt2=true' to remove this warning.
It will be removed at the end of 2018..
:react-native-webview:reactNativeAndroidRoot /Volumes/Data/ReactNative/crowdbotics/yapstars-2338/node_modules/react-native/android

> Task :react-native-fast-image:compileReleaseJavaWithJavac
Note: [2] Wrote GeneratedAppGlideModule with: [com.bumptech.glide.integration.okhttp3.OkHttpLibraryGlideModule, com.dylanvann.fastimage.FastImageOkHttpProgressGlide
Module]

> Task :react-native-fbsdk:compileReleaseJavaWithJavac
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: /Volumes/Data/ReactNative/crowdbotics/yapstars-2338/node_modules/react-native-fbsdk/android/src/main/java/com/facebook/reactnative/androidsdk/Utility.java use
s unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

> Task :react-native-gesture-handler:compileReleaseJavaWithJavac
Note: /Volumes/Data/ReactNative/crowdbotics/yapstars-2338/node_modules/react-native-gesture-handler/android/src/main/java/com/swmansion/gesturehandler/react/RNGestu
reHandlerButtonViewManager.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

> Task :react-native-firebase:compileReleaseJavaWithJavac
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

> Task :react-native-google-signin:compileReleaseJavaWithJavac
Note: /Volumes/Data/ReactNative/crowdbotics/yapstars-2338/node_modules/react-native-google-signin/android/src/main/java/co/apptailor/googlesignin/RNGoogleSigninModu
le.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

> Task :app:bundleReleaseJsAndAssets
warning: the transform cache was reset.

> Task :react-native-webview:compileReleaseJavaWithJavac
Note: /Volumes/Data/ReactNative/crowdbotics/yapstars-2338/node_modules/react-native-webview/android/src/main/java/com/reactnativecommunity/webview/RNCWebViewManager
.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: /Volumes/Data/ReactNative/crowdbotics/yapstars-2338/node_modules/react-native-webview/android/src/main/java/com/reactnativecommunity/webview/RNCWebViewManager.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Failed to generate resource table for split ''
/Users/sbc/.gradle/caches/transforms-1/files-1.1/appcompat-v7-28.0.0.aar/d524ae92a8d2644151a5d2ea171af91b/res/values-v28/values-v28.xml:5:5-8:13: AAPT: No resource
found that matches the given name (at 'dialogCornerRadius' with value '?android:attr/dialogCornerRadius').

> Task :react-native-twitter-signin:verifyReleaseResources FAILED

> Task :app:bundleReleaseJsAndAssets
Loading dependency graph, done.
bundle: Writing bundle output to: /Volumes/Data/ReactNative/crowdbotics/yapstars-2338/android/app/build/generated/assets/react/release/index.android.bundle
bundle: Done writing bundle output
bundle: Copying 261 asset files
bundle: Done copying assets

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':react-native-twitter-signin:verifyReleaseResources'.
> com.android.ide.common.process.ProcessException: Failed to execute aapt

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

Deprecated Gradle features were used in this build, making it incompatible with Gradle 5.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/4.10/userguide/command_line_interface.html#sec:command_line_warnings

BUILD FAILED in 49s
200 actionable tasks: 184 executed, 16 up-to-date
SBCs-iMac:android sbc$

./gradlew assembleRelease --debug
...
00:38:00.619 [DEBUG] [org.gradle.internal.resources.AbstractTrackedResourceLock] Daemon worker Thread 3: released lock on root.1
00:38:00.619 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Completing Build operation 'Run build'
00:38:00.619 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Build operation 'Run build' completed
00:38:00.622 [DEBUG] [org.gradle.cache.internal.LockOnDemandCrossProcessCacheAccess] Releasing file lock for file content cache (/Volumes/Data/ReactNative/crowdbotics/yapstars-2338/android/.gradle/4.10/fileContent)
00:38:00.622 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on file content cache (/Volumes/Data/ReactNative/crowdbotics/yapstars-2338/android/.gradle/4.10/fileContent).
00:38:00.703 [DEBUG] [org.gradle.cache.internal.LockOnDemandCrossProcessCacheAccess] Releasing file lock for task history cache (/Volumes/Data/ReactNative/crowdboti
cs/yapstars-2338/android/.gradle/4.10/taskHistory)
00:38:00.703 [DEBUG] [org.gradle.cache.internal.btree.BTreePersistentIndexedCache] Closing cache taskHistory.bin (/Volumes/Data/ReactNative/crowdbotics/yapstars-233
8/android/.gradle/4.10/taskHistory/taskHistory.bin)
00:38:00.744 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on task history cache (/Volumes/Data/ReactNative/crowdbotics/yapstars-2338/an
droid/.gradle/4.10/taskHistory).
00:38:00.748 [DEBUG] [org.gradle.cache.internal.LockOnDemandCrossProcessCacheAccess] Releasing file lock for Build Output Cleanup Cache (/Volumes/Data/ReactNative/crowdbotics/yapstars-2338/android/.gradle/buildOutputCleanup)
00:38:00.748 [DEBUG] [org.gradle.cache.internal.btree.BTreePersistentIndexedCache] Closing cache outputFiles.bin (/Volumes/Data/ReactNative/crowdbotics/yapstars-2338/android/.gradle/buildOutputCleanup/outputFiles.bin)
00:38:00.749 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on Build Output Cleanup Cache (/Volumes/Data/ReactNative/crowdbotics/yapstars-2338/android/.gradle/buildOutputCleanup).
00:38:00.749 [DEBUG] [org.gradle.cache.internal.LockOnDemandCrossProcessCacheAccess] Releasing file lock for cache directory md-supplier (/Users/sbc/.gradle/caches/4.10/md-supplier)
00:38:00.750 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on cache directory md-supplier (/Users/sbc/.gradle/caches/4.10/md-supplier).
00:38:00.750 [DEBUG] [org.gradle.cache.internal.LockOnDemandCrossProcessCacheAccess] Releasing file lock for cache directory md-rule (/Users/sbc/.gradle/caches/4.10/md-rule)
00:38:00.750 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on cache directory md-rule (/Users/sbc/.gradle/caches/4.10/md-rule).
00:38:00.751 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.resolveengine.store.CachedStoreFactory] Resolution result cache closed. Cache reads: 0, disk reads: 0 (avg: 0.0 secs, total: 0.0 secs)
00:38:00.751 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.resolveengine.store.CachedStoreFactory] Resolution result cache closed. Cache reads: 49, disk reads: 49 (avg: 0.001 secs, total: 0.049 secs)
00:38:00.754 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.resolveengine.store.ResolutionResultsStoreFactory] Deleted 8 resolution results binary files in 0.003 secs
00:38:00.754 [DEBUG] [org.gradle.deployment.internal.DefaultDeploymentRegistry] Stopping 0 deployment handles
00:38:00.754 [DEBUG] [org.gradle.deployment.internal.DefaultDeploymentRegistry] Stopped deployment handles
00:38:00.755 [DEBUG] [org.gradle.cache.internal.LockOnDemandCrossProcessCacheAccess] Releasing file lock for file hash cache (/Volumes/Data/ReactNative/crowdbotics/yapstars-2338/android/.gradle/4.10/fileHashes)
00:38:00.755 [DEBUG] [org.gradle.cache.internal.btree.BTreePersistentIndexedCache] Closing cache fileHashes.bin (/Volumes/Data/ReactNative/crowdbotics/yapstars-2338/android/.gradle/4.10/fileHashes/fileHashes.bin)
00:38:00.756 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on file hash cache (/Volumes/Data/ReactNative/crowdbotics/yapstars-2338/android/.gradle/4.10/fileHashes).
00:38:00.756 [DEBUG] [org.gradle.cache.internal.DefaultPersistentDirectoryStore] VCS Checkout Cache (/Volumes/Data/ReactNative/crowdbotics/yapstars-2338/android/.gradle/vcs-1) has last been fully cleaned up 0 hours ago
00:38:00.756 [DEBUG] [org.gradle.cache.internal.DefaultCacheAccess] Cache VCS Checkout Cache (/Volumes/Data/ReactNative/crowdbotics/yapstars-2338/android/.gradle/vcs-1) was closed 0 times.
00:38:00.756 [DEBUG] [org.gradle.cache.internal.DefaultCacheAccess] Cache VCS metadata (/Volumes/Data/ReactNative/crowdbotics/yapstars-2338/android/.gradle/4.10/vcsMetadata-1) was closed 0 times.
00:38:00.757 [DEBUG] [org.gradle.launcher.daemon.server.exec.ExecuteBuild] The daemon has finished executing the build.
00:38:00.797 [DEBUG] [org.gradle.launcher.daemon.client.DaemonClientInputForwarder] Dispatching close input message: org.gradle.launcher.daemon.protocol.CloseInput@
1c6c04a0
00:38:00.798 [DEBUG] [org.gradle.launcher.daemon.client.DaemonClientConnection] thread 13: dispatching class org.gradle.launcher.daemon.protocol.CloseInput
00:38:00.799 [DEBUG] [org.gradle.launcher.daemon.client.DaemonClient] Received result Failure[value=org.gradle.initialization.ReportedException: org.gradle.internal
.exceptions.LocationAwareException: Execution failed for task ':react-native-twitter-signin:verifyReleaseResources'.] from daemon DaemonInfo{pid=7436, address=[2197
a2fb-fc93-491e-a1f2-8ba22ba27f2e port:50472, addresses:[/0:0:0:0:0:0:0:1, /<IP_ADDRESS>]], state=Idle, lastBusy=1556904566380, context=DefaultDaemonContext[uid=61833f1f-5b7a-4645-836e-a3cabf7a662c,javaHome=/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home,daemonRegistryDir=/Users/sbc/.gradle/daemon,pid=7436,idleTimeout=10800000,daemonOpts=-XX:MaxPermSize=2048m,-XX:+HeapDumpOnOutOfMemoryError,-Xmx3g,-Dfile.encoding=UTF-8,-Duser.country=KH,-Duser.language=en,-Duser.variant]} (build should be done).
00:38:00.799 [DEBUG] [org.gradle.launcher.daemon.client.DaemonClientConnection] thread 1: dispatching class org.gradle.launcher.daemon.protocol.Finished
00:38:00.799 [DEBUG] [org.gradle.launcher.daemon.client.DaemonClientConnection] thread 1: connection stop
SBCs-iMac:android sbc$

Let me know if I have some wrong configuration.

try with
        buildToolsVersion = "28.0.3"
        minSdkVersion = 16
        compileSdkVersion = 28
        targetSdkVersion = 27
        supportLibVersion = "28.0.0"

Maybe remove: implementation 'com.android.support:design:27.1.0'
Maybe also upgrade your gradle?
also see:
https://stackoverflow.com/questions/49171300/no-resource-found-that-matches-the-given-name-at-dialogcornerradius-with-valu
https://github.com/react-native-community/react-native-share/issues/393

@maximus123123 comment solves the issue. Bear in mind this change has to be made in node_modules/react-native-twitter-signin/android/build.gradle
It will need to be reapplied after a ./gradle clean or node_modules deletion

try with
edit node_modules/react-native-twitter-siging/android/build.gradle
change the following lines
dependencies {
        classpath 'com.android.tools.build:gradle:3.5.2' #should match your project build tool for gradle
    }

android {
    compileSdkVersion 28  #should match your project compileSdkVersion
   #Remove buildToolsVersion line

    defaultConfig {
        minSdkVersion 16 #should match your project minSdkVersion
        targetSdkVersion 27 #should match your project targetSdkVersion

edit node_modules/react-native-twitter-siging/android/gradle/gradle.properties
distributionUrl=https\://services.gradle.org/distributions/gradle-6.0.1-all.zip

No need to hack node_modules Adding this to android/build.gradle fixed the issue for me
subprojects {
    afterEvaluate {project ->
        if (project.hasProperty("android") && project.name == 'react-native-twitter-signin') {
            android {
                buildToolsVersion = "29.0.2"
                minSdkVersion = 24
                compileSdkVersion = 29
                targetSdkVersion = 29
                supportLibVersion = "28.0.0"
            }
        }
    }
}

Versions should match your top level versions

No need to hack node_modules Adding this to android/build.gradle fixed the issue for me
subprojects {
    afterEvaluate {project ->
        if (project.hasProperty("android") && project.name == 'react-native-twitter-signin') {
            android {
                buildToolsVersion = "29.0.2"
                minSdkVersion = 24
                compileSdkVersion = 29
                targetSdkVersion = 29
                supportLibVersion = "28.0.0"
            }
        }
    }
}

Versions should match your top level versions


Fixes #2. Use default './dict.txt' when none is given.

Uses default './dict.txt' when not present in the current working directory

:+1: thanks

published 1.1.0


Directory organization and Python3 compatibility

Cool project idea. Here's my two cents. :+1:

lethargilistic Great stuff! Thanks.


Requesting the Void type hangs the UI

Searching for the string Void in the Find feature seems to spin forever.
Scrolling down to the Void type on the left nav bar and clicking it results in an entry in the content pane that looks like it's loading. It takes a minute or so to fail with an error. UCM is totally unresponsive while this is happening.
A query to the API like api/getDefinitions?names=Void responds normally and quickly.

Yeah GET /api/find?query=void instantly causes this - very strange.


fix(hive): disable ssl for metastore

Which issue(s) this PR fixes:

Fixes #402
Additional comments:

As stated by @gboutry, disabling SSL on Hive Metastore side solves the issues. Connections to the Metastore are still secured via SASL/Kerberos. There is no more need to remove spark-sql and spark3-sql as are functional after this fix.
To make clear that you license your contribution under
the Apache License Version 2.0, January 2004 and that you give permission to TOSIT,
you have to acknowledge this by using the following check-box.

[x] I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004

[x] I hereby agree to grant TOSIT a copyright license to use my contributions.

Therefore, we should remove the ssl-tls tasks for hive metastore

Shouldn't we try to backport HIVE-15025 before disabling SSL for Hive MS?

Shouldn't we try to backport HIVE-15025 before disabling SSL for Hive MS?

Where do you want to backport this ?
The hive metastore we deploy is deployed in 3.1.X.
The hive version that's used to compile with spark is in 2.3.X which should already have the patch.

Shouldn't we try to backport HIVE-15025 before disabling SSL for Hive MS?

If I understand correctly the purpose of this patch is only to allow the use SSL when Kerberos is not used:

SSL encryption is only used to encrypt the communication to HMS when no kerberos authentication is enabled for HMS.
This is not the case of TDP.

Shouldn't we try to backport HIVE-15025 before disabling SSL for Hive MS?

Where do you want to backport this ? The hive metastore we deploy is deployed in 3.1.X. The hive version that's used to compile with spark is in 2.3.X which has the patch.

Yes my bad, I had in the mind our Hive 1.x and 2.x that we build for Spark but this issue is not related

It's outside the scope of this PR, but we should check the properties listed in the hive-sites, because some have been deprecated for a long time. For example, all properties starting with hive.metastore... for metastore configuration have been deprecated to metastore... since the metastore became a standalone project (in hive repository, project: standalone-metastore).


openmpi: build fails on aarch64-darwin

Describe the bug
I'm on a mission to get gdal (and thence postgis) compiling on M1 Macs, and having fixed hdf4, the next stumbling block is openmpi 4.1.1. Sadly, the build fails with checking size of Fortran CHARACTER... configure: WARNING: Could not determine size of CHARACTER, presumably related to gfortran.
To Reproduce
Steps to reproduce the behavior:

nix-build --argstr localSystem aarch64-darwin -A openmpi

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
checking to see if Fortran compilers need additional linker flags... none
checking  external symbol convention... single underscore
checking if C and Fortran are link compatible... yes
checking to see if Fortran compiler likes the C++ exception flags... skipped (no C++ exceptions flags)
checking to see if mpifort compiler needs additional linker flags... -Wl,-commons,use_dylibs
checking if Fortran compiler supports CHARACTER... yes
checking size of Fortran CHARACTER... configure: WARNING: Could not determine size of CHARACTER
configure: WARNING: See config.log for details
configure: error: Cannot continue
builder for '/nix/store/rnm0zh3klzh8i5n7llppncpa2rr0ifwp-openmpi-4.1.1.drv' failed with exit code 1
cannot build derivation '/nix/store/94l8ii0kr5pl9l9ahirwwvz2szq2m20p-netcdf-4.7.4.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/kn1kaph2gkqd6rc1769mqv1i49r3kk67-gdal-3.2.2.drv': 1 dependencies couldn't be built
error: build of '/nix/store/kn1kaph2gkqd6rc1769mqv1i49r3kk67-gdal-3.2.2.drv' failed

Additional context
This works fine when built for x86_64 on the same machine.
Notify maintainers
@markuskowa

Metadata

system: "x86_64-darwin"
host os: Darwin 20.5.0, macOS 10.16
multi-user?: yes
sandbox: no
version: nix-env (Nix) 2.3.10
channels(steve): "darwin, nixpkgs-21.11pre295944.0747387223e"
nixpkgs: /Users/steve/.nix-defexpr/channels/nixpkgs

Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
  - openmpi
# a list of nixos modules affected by the problem
module:

Submitted PR https://github.com/NixOS/nixpkgs/pull/127694 which disables Fortran support for OpenMPI on aarch64-darwin. Would that fix the issue for you or do you require Fortran?

This seems to be the build failure:
10775 /private/tmp/nix-build-openmpi-4.1.1.drv-0/ccg7QqR8.s:13:15: error: index must be an integer in range [-256, 255].
10776         ldr     x2, [x2, ___stack_chk_guard];momd
10777                          ^
10778 /private/tmp/nix-build-openmpi-4.1.1.drv-0/ccg7QqR8.s:28:15: error: index must be an integer in range [-256, 255].
10779         ldr     x0, [x0, ___stack_chk_guard];momd

Would that fix the issue for you or do you require Fortran?

I actually have no idea if I require Fortran. I mean, presumably it's enabled for some reason, so I'm a little wary of disabling it on only one platform/arch combination: that feels like an atypical workaround.

To reproduce:
nix-shell -p gfortran
cat <<EOF > foo.f90
program fsize
   external size
   CHARACTER :: x(2)
   call size(x(1),x(2))
end program
EOF
gfortran   foo.f90 foo.o -o foo

I wonder if the gcc maintainers can offer any insight? @synthetica, @vcunat, @ericson2314

___stack_chk_guard seems to hint at the stack-protector hardening, so perhaps something like
hardeningDisable = lib.optionals (stdenv.isAarch64 && stdenv.isDarwin) [ "stackprotector" ];

could work around that?  (no idea what's the real cause though)

could work around that?

You were right! Sent a PR in https://github.com/NixOS/nixpkgs/pull/128606


[Feature] Logging

Is there a way to implement a generic logging mechanism?
I want to log an info message when an entity is created, updated and deleted. In this way I can easily track the important events, and which user did them at what time.
I can do this by overriding the parent's crud methods but it will make the controllers quite messy.

P.S. I'll go ahead and close this issue so we don't clog the section. Feel free to open it again if you encounter problems or comment if you have follow-ups.

@tabacitu    Thanks for the suggestions, I'll check them out. Cheers


Changing the implementation of styleds

To implement a new styled drawable we currently implement, for example, impl <C: PixelColor> Drawable for Styled<Rectangle, PrimitiveStyle<C>>. This does only work inside the main e-g crate and makes it impossible to resuse the Styled struct in other crates. I think e-t implements its own Styled.
I did implement a prototype a while ago, where I added a new StyledDrawable trait, which roughly looked like this:
pub trait StyledDrawable<S> {
    type Color: PixelColor;

    fn draw_styled<D>(&self, target: &mut D, style: &S) -> Result<(), D::Error>
    where
        D: DrawTarget<Color = Self::Color>;
}

This makes it possible to implement new styleds in other crates. And I think this change is even non breaking, because Styled can be change to use the new StyledDrawable impls.
Now to the semi-breaking part of this suggestion: The new draw_styled method could also be used directly:
let style = PrimitiveStyle::with_stroke(BinaryColor::On, 1);

// before:
Line::new(start, end)
    .into_styled(style)
    .draw(target)?;

// after:
Line::new(start, end)
    .draw_styled(target, &style)?;

Would we want to advice users to use draw_styled instead of the into_styled & draw combination, if we implement this change? The old code would still work and could be useful to store a styled primitive for a longer time. But for the short lived object, that are often used in e-g code, the new variant might be easier to use. And there might be a slight performance improvement, because the style is passed using a reference and doesn't need to be cloned into a Styled object first.

I did implement a prototype a while ago, where I added a new StyledDrawable trait, which roughly looked like this:

This would mean there are two different ways to do mostly the same thing, with about the same lines of code. This would be more complex to document and maintain and I'm not sure I see the benefit.
I've typed out multiple half replies to the rest of the post now and nothing has become much clearer, so could use some concrete examples of how this breaking change would fix some problems.

I think e-t implements its own Styled.

Well I missed this, but I don't know how big a deal a simple confirmation is: e-t indeed uses it's own Styled[TextBox]. But this didn't really hurt the lib, I think. A TextBox needs it's own style object as well as a custom draw algorithm, so I don't really know what a common Styled trait would add to it. Sure, I also started with "why can't I implement Styled on this thing", but in the end it didn't really matter. But it might just be nonsense from my sleepy brain.


TLS is not used when connecting via hyper CLI to port other then 443

HttpConnection does not use TLS by default (and I haven't found a way to force it through CLI): https://github.com/Lukasa/hyper/blob/development/hyper/common/connection.py#L29-L31
I expected hyper to use TLS when connecting via CLI: hyper GET https://myserver:3000/, since I've mentioned https.
Also, I think that might be a security issue because hyper is mostly used for HTTP/2 communication and it is expected for all such communication to be secured. Maybe its better to have security=True by default?

There's a few different things going on here.
Firstly, the hyper CLI tool. That tool should absolutely be enhanced to use the scheme to set the secure argument on the HTTPConnection object: we should open a bug report for that.
Second, the HTTPConnection object itself. You're right that the HTTPConnection object only uses TLS when port 443 is requested, or when the secure flag is passed. I think this is a reasonable default for the programmatic API.
Note, however, that it's not inherently expected that HTTP/2 will be used over secure connections. It's certainly the most common, but plaintext HTTP/2 is entirely allowed (and supported by Hyper).
The concrete action item I see here is to update the CLI tool to use the scheme to determine whether to pass the secure flag.

Proposed fix in #155.


tests: lwm2m_registry: Add ZTest tests for lwm2m_registry

These tests test the basic functionality of creating object and resource instances, setting buffers, writing and reading to and from resources, and setting and triggering callbacks.
Signed-off-by: Jarno Lämsä<EMAIL_ADDRESS>

@SeppoTakalo @rlubos @carlescufi please review.

@juhaylinen please review.

Thank you @rlubos for your review. I think have addressed all of your review comments. Please re-review.

Thank you @SeppoTakalo for your review comments, those have now been addressed, please re-review.


[ASK] Change references to NLP to say NLP-recipes

Description
Check all readmes reference the repo as nlp-recipes
Other Comments

Merged to staging.. Closing.


[firebase_auth] phone recaptcha verification doesn't work with restricted api keys

Which plugins are affected?
firebase_auth
Which platforms are affected?
android , although there was this issue for ios, which was closed due to lack of response, so it might be an issue there as well
Description
When a firebase android api key is restricted it will fail to pass the recaptcha verification in phone authentication flows because the key is used outside the application for which it was restricted.
Reproducing the issue

Use the flutterfire example to authenticate with a phone number
Add an android restriction for the key used by firebase as shown in the picture below

run the example and try to authenticate with a real phone number. The recaptcha verification should fail because it uses a key restricted for an android app when doing the re captcha verification which happens in a browser / webview launched during the flow.

Firebase Core version
2.31.1
Flutter Version
3.22.1
Relevant Log Output
This request is missing a valid app identifier, meaning that Play Integrity checks, and reCAPTCHA checks were unsuccessful. Please try again, or check the logcat for more details.

Flutter dependencies
No response
Additional context and comments
No response

Hey @cedvdb - this is a well known limitation. Here is more information
Quote:

Hey there, Malcolm from Firebase here!

This is a known behavior, and is due to the fact that Apple Sign-In is based on a Web flow - it kicks you to a browser to do the sign-in and then takes you back. As a result, your API key is used in a web context, so restricting your API key to only work on Android breaks this feature.

As is presently stands, API key restrictions provide minimal benefit for Android - all it does is make it so that certain headers must show up on the request in order to be accepted. We're working on better ways to solve this issue right now, but I would suggest foregoing API key restrictions for now (since it does very little) if you need to use Apple Sign-In.

It is worth removing the restriction, if wish to know if anything is happening with this, it might be worth reaching out to Firebase support 🙏


remove json dependency

previously jmespath worked fine without having json installed,
atm it does not declare a dependency on json always requires it ...
Ideally remove the require (or require only when using certain features) since I was able to use it just fine before (v1.1.3) ... alternatively add json dependency.
@trevorrowe

correction .. aws-sdk-core 2.3.4 did not load jmespath ... stil jmespath should declare the dependency ?

It has always had an implicit dependency on JSON. For a while there was an explicit dependency on json_pure that caused multiple issues. Expressing a dependency directly on the JSON gem makes it not portable to environments that can not install gems that must be built. Since Ruby 1.9.3+ all ship with a version of json in the standard library, that is what we are using / depending on now.

Ahhh the might be that I'm running on Alpine which is stripped down ...
On Sep 18, 2016 11:51 AM, "Trevor Rowe"<EMAIL_ADDRESS>wrote:

It has always had an implicit dependency on JSON. For a while there was an
explicit dependency on json_pure that caused multiple issues. Expressing a
dependency directly on the JSON gem makes it not portable to environments
that can not install gems that must be built. Since Ruby 1.9.3+ all ship
with a version of json in the standard library, that is what we are using /
depending on now.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/jmespath/jmespath.rb/issues/39#issuecomment-247865912,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAsZ7O8tSG6tOEt6MkOemnfdWwFzWVwks5qrYg7gaJpZM4J_ykq
.


feat(core): make the tmp directory configurable

Hello there!
Thank you for this plugin, I'm using it while developing on Android using Termux and Neovim.
The problem is that Termux doesn't use a standard hierarchy for the filesystem and it basically is a giant ˋchrootˋ in ˋ/data/android/...ˋ somewhere, and the default path ˋ/tmpˋ does not exist. I had to slightly modify your script in order to make the temporary folder configurable. I also had to move the file into the ˋluaˋ folder to make it easier to configure using plugin management systems like Lazy or Packer.
Now you can configure the plugin quite easily, with Lazy:
{
  "leosmaia21/gcompilecommands.nvim",
  opts = {
    tmp_file_path = "$HOME/tmp/compilecommandsNEOVIM.json"
  },
  ft = { "c", "cpp" }, -- lazy load plugin only on C and C++ filetypes
}

I think that an even better solution would be to use the mktemp command but I do not know if that's available on all systems (MacOS for example?)

I hadn't thought about that case, thank you, this was just a small plugin/function i though because at work i can't use sudo or install bear either.


Give Admins More Computers

Add more UIs to Admin ghost for admin sanity.

Station Map
Power Monitor
Atmos Alerts

Proof I didn't break the game:

Yippeee

I asked sloth on the performance impact of this.

Previously we had rejected other PRs adding the power monitor to pAIs or such because it would be bad for performance. In most cases there should not be more than a few aghosts on wizden but this might have a stronger effect on people hosting their own servers. The station map should be ok (I thought they had that one already?).
Pinging @chromiumboy for information of the atoms monitor performance impact.


OC-446_Resolve_a_lot_of_too_many_parameters_sonar_issues_from_shared

All is well.

All is well.

All is well.

All is well.

All is well.


Refactor config.py file into package (own folder with separate files)

Short description of the problem this fixes or functionality that this introduces. This may be used for the CHANGELOG
Refactored config.py file into a package with separate module files for each class.

Give a summary of what the PR does, explaining any non-trivial design decisions

config.py is replaced by a package with classes in their respective files (as in below image)
The existing codebase doesn't require modifications as the __init__.py file in the new config package maintains the same import interface.
This new package structure preserves the existing import paths while improving code organization.
Renamed 2 constants to have "OH_" prefix to make their origin clearer if used outside
(only needed to adapt 1 unit test)
Dependent methods were moved into new file config_functions.py
As per PEP 8 style guide, relative imports are used for intra-package imports
Added developer README.md to the config folder

New structure:

IMHO this is rather a good change, thanks. It feels like it will make it easier to work with them as developer than a single dunno-how-many lines file.
I assume the files are completely unchanged, or I'd suggest to keep them unchanged. 😅 I didn't verify them, but if they were broken down with an LLM, I'd have to suggest to verify a bit, they can get stuff wrong in refactorings.

IMHO this is rather a good change, thanks. It feels like it will make it easier to work with them as developer than a single dunno-how-many lines file.
I assume the files are completely unchanged, or I'd suggest to keep them unchanged. 😅 I didn't verify them, but if they were broken down with an LLM, I'd have to suggest to verify a bit, they can get stuff wrong in refactorings.

No LLM was involved in that, I manually moved the code over. Otherwise they'd look like the readme lol

As per PEP 8 style guide, relative imports are used for intra-package imports

Why do you say PEP 8 recommends relative? As far as I can see, PEP 8 recommends absolute imports, not relative imports. Relative imports are nowadays considered acceptable if the package structure is too complex, which doesn't seem to be the case here:

Absolute imports are recommended, as they are usually more readable and tend to be better behaved (or at least give better error messages)

https://pep8.org/

As per PEP 8 style guide, relative imports are used for intra-package imports

Why do you say PEP 8 recommends relative? As far as I can see, PEP 8 recommends absolute imports, not relative imports. Relative imports are nowadays considered acceptable if the package structure is too complex, which doesn't seem to be the case here:

Absolute imports are recommended, as they are usually more readable and tend to be better behaved (or at least give better error messages)

https://pep8.org/

I hate Sonnet

Absolute imports are recommended, as they are usually more readable and tend to be better behaved (or at least give better error messages)

Done.


SerializationConfig

Just a suggestion.

It's done for AllPay. I've just pushed the changes to this branch because the maven-shade-plugin is already added here.

Hmm not sure why this didn't get autoclosed... Well I merged it.


e621/e926 API changes

The e621/e962 functionality is currently broken because they have updated thier API along with thier site. It would be great if you could try to update it.
https://e926.net/help/api

Yup, aware of this. First need to figure/find out what they changed that broke booru

Fixed in<EMAIL_ADDRESS>commit 3e625da8e91522f7cb42bf56d0c8f0a33e7dc976

For anyone else working with e621/e926's api, here's what changed for getting posts:

Endpoint changed from /post/index.json to /posts.json
Endpoint no longer returns an array of posts, it's now an object with a single key "posts" that has the array of posts
.tags properties on posts are no longer string arrays, they are now objects with keys for "general", "artist", "copyright", etc. which are arrays of strings (i.e. post.tags.general => ['foo', 'bar'])
Image url/sizes are now under:

Full-sized: post.file.url
Sample: post.sample.url
Preview: post.preview.url

e926's api now returns nsfw posts as well, although file urls are null. You have to specify rating:safe as a tag yourself for the old behavior (this library does that for you)


multiple schema support

check/fix support for cross schema usage

it works, but it needs tests ;)

done


vfs documentation

This documents every item in the vfs crate, except for a few private, windows-specific items.

I learned the API as I was doing this, so this may not always be accurate

I learned the API as I was doing this, so this may not always be accurate


Undefined method "update" for Twitter

I created an initializer called twitter in my app with the following content:
$client = Twitter::Client.new do |config|
  config.consumer_key        = "mykey"
  config.consumer_secret     = "mykey"
  config.access_token        = "mykey-mykey"
  config.access_token_secret = "mykey"
end

Then I tried to make a call:
$client.update("Fuck twitter!")

It did not work. undefined method update' for #Twitter::Client:0x00000003f73610`
Any idea why?

Hi @Rui90,
Twitter::Client doesn't implement any API methods (it is primarily used by the REST and Streaming clients and adds so basic methods used by both). Can you change your code from Twitter::Client to Twitter::REST::Client to see if that helps.
Based on the initial title of this issue, you may be using an older version of the gem.


Feat: Support for CircuitPython 8.1+

This update adds support for mypy-cross when using CircuitPython version 8.1 or greater!
Closes #8

Thank you!


Add GitHub Actions to build the webhook exporter

Covers building webhook exporter and pushing it to the quay.io repository for the commit, pre-release and release events.
Documentation will be covered as part of the #857, however here one link was added as it's directly pointing to the quay image which will be built by those actions.
Depends on: #836
@redhat-cop/mdt

Fixes #856

/retest


Where is the cow?

I don't see the cow :)

The cow is created dynamically! :-)
See :h g:startify_custom_header.
My own configuration looks like this: https://github.com/mhinz/dotfiles/blob/bcb3b6de4281f5e8381ff63b9891ecdb94d47dcc/vim/vimrc#L686-L692

Thanks. Also found in the :help startify, thanks for the awesome plugin!


Clustered: simplify public pull secrets

Crane is not actually required when using the InfluxData public image registry. It seems like referring to it before the public/private branch in the docs can cause some confusion. This moves all of the crane steps into the private branch, where it's needed.

[x] Signed the InfluxData CLA
(if necessary)
[ ] Rebased/mergeable

@jstirnaman is there anything else I'm missing?


Azure Utilization Records does not work if the data is in 2 pages.

I'm following https://msdn.microsoft.com/en-us/library/partnercenter/mt791774.aspx to get Utilization Record. But only 1st page is ok. 500 error will be thrown when receiving data in 2nd page.
It occurs on both REST API and SDK.
More detail is described in here.

Hi @laika1234, this issue should be resolved now. Can you confirm that you are still encountering this issue?


add user to auto merge

Description
Adding myself to auto merge.
Also removed Young Bu Park from the auto merge.
Issue reference

Please reference the issue this PR will close: #[issue number]
Checklist
Please make sure you've  completed the relevant tasks for this PR, out of the following list:

[ ] Code compiles correctly
[ ] Created/updated tests
[ ] Unit tests passing
[ ] End-to-end tests passing
[ ] Extended the documentation / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
[ ] Specification has been updated / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
[ ] Provided sample for the feature / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]

One problem about auto-merge I see is the flaky tests, not only about network :(


model deployed to ACI if AKS cluster not found in ML workspace

while deploying a model to AKS using aml-deploy action if the compute target cluster is not found in the workspace it then switches to ACI deployment for the model.

@vivishno  Thanks for submitting the issue. Do you consider this to be a bug?

@marvinbuss I think we should inform user that his cluster is (may be ) not attached to workspace he is using. and in that case he can either first attach it ( himself) or by using action ( aml-compute) may be.
IMO we should not default to ACI deployment as it may break his further workflow, where he is trying to access AKS cluster using the deployment info we provide.

@ashishonce  I do like the idea, that we inform the user that the AKS cluster is not available and that we also inform him or her about the possibility to attach it with aml-compute.
We can remove the ACI fallback option, if you like. I just thought that it makes sense, since it reduces the runtime significantly. If the person just misspelled the compute target, the user still ends up with a deployment that he or she can test.


Implement "map Err(unknown) to Err(Error)" operator for Result<T, E> to make it easier to combinate with tryCatchIntoResult

Motivation
At first, as a problem 1, tryCatchIntoResult produces Result<T, unknown>. We can make it into Result<T, Error> by mapErr() but it's a bit redundant.  User space can define a such operator function but it's also redundant.
Indirectly, this mean that we don't recommend to use tryCatchIntoResult easily. This is just our intended design. We recommend (or require) to write a try-catch withing thinking about deeply what an inside throws. But it's a bit inconvenient.
Second, as a problem 2, tryCatchIntoResultWithEnsureError() relax a the above problem 1. But it's implementation depends on e instanceof globalThis.Error heavily. If a thrown object e is created by a constructor since another realm. This problem is similar to the motivation of Error.isError() proposal. Times might resolve this by populating Error.isError(). However, we cannot resolve this until then.
Possible Solution
Add the special operator as a variant of mapErr() like function mapErrUnknownToError<T>(input: Result<T, unknown>): Result<T, Error>.
See https://github.com/option-t/option-t/pull/2279
Add a special variant to tryCatchIntoResult() as like tryCatch + mapErr
This increase a variants of tryCatch. It might make more complex.

Add the special operator as a variant of mapErr() like function mapErrUnknownToError<T>(input: Result<T, unknown>): Result<T, Error>.
See #2279

This would be a useful. But this is too generic approach to resolve our motivations.

Add a special variant to tryCatchIntoResult() as like tryCatch + mapErr

I seem this solution is more nice at this time.
Typical case to generate Result<T, unknown> is originated from enclosure a exist throw-exception style codebase to bridge it to Result. I think we should care only this case by this issue.
The others can be solved by mapErr.


Update lifecycle from v0.18.5 to v0.19.0-rc.2

This updates the builder images to the latest lifecycle version, 0.19.0-rc.2, Which includes a fix to https://github.com/buildpacks/lifecycle/issues/1308.

Release notes:
https://github.com/buildpacks/lifecycle/releases/tag/v0.19.0-rc.2
Full changelog:
https://github.com/buildpacks/lifecycle/compare/v0.18.5...v0.19.0-rc.2