[2.2.x] OPENJPA-2817: OpenJPA enhancer needs improved reentrancy

OpenJPA's class transformer was designed in a time when ClassLoader access was synchronized. Because it was assumed that if the ClassLoader caused another class to load while it was already enhancing a class, causing another triggering of the class transformer, it was assumed that that could only happen if OpenJPA was bundled as part of the application (loaded by the app classloader in an EE environment), and was safe to assume that this reentrant invocation would not be a request to enhance a persistent type, and thus return null (no enhancement needed).
With Java 7+, ClassLoader locking has been changed (https://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html).
Now, because the same ClassLoader (and thus same transformer), can be invoked concurrently by different threads, this assumption was no longer valid.
OpenJPA needs to be updated to be mindful of reentrancy on a thread scope, instead of just simply reacting to reentrancy whenever it happens.
JIRA: https://issues.apache.org/jira/browse/OPENJPA-2817

Will create a trunk PR after this has been reviewed.

@jgrassel , for now I'm trying to see in which case we need that. Say me if I'm wrong but the scope is only about the javaagent (other cases - ie container deployment enhancement and build time enhancement - must be single threaded by construction today). Since all entities are loaded when the EMF is created it should also be single threaded until the EMF is lazily created and concurrently at runtime - which must be handled by the EMF then IMO. The comment is surprising though cause it means it only happens when loading openjpa itself - which kind of implies the temp loader should filter openjpa "runtime" instead of adding this boolean. So wonder if you are able to replicate the issue in a test (even abusing of countdownlatch or "sleep" in loadClass) to ensure we fix an issue instead of propagating dead code. Hope it makes sense.

@rmannibucau  This issue was brought to my awareness after Open Liberty's application classloader was updated to allow multi-threaded concurrency (even though concurrency was allowed after JDK 7, OpenLiberty only very recently updated its own application classloader to allow this).  Presumably, this would also affect other application servers which are also updated to take advantage of that particular approach for performance improvement.
I was not able to replicate this in a test environment, but my customer has confirmed that this resolved the symptoms caused by the old design approach (in the form of entity types not being class transformed).

@jgrassel can you thread dump (even with a monkey patch) when the issue occurs? OpenLiberty is supposed to have the EMF ready during CDI boot (I know there is a chicken egg issue between cdi and jpa in the spec so can be a toggle thing in OpenLiberty) and this part is monothreaded so classes are either concurrently loaded before (which can be but would be weird and wouldn't use enhancement at deploy time properly) or it is when bypassing this part (not EE case?).
I'm just trying to refine the exact use case cause today I would be more keen to remove the boolean but I'm sure I miss a case if you hit it hard, we just need to ensure we fully get why ;). Also happy to run it locally if you can share a mvn project on github.

True, OpenLiberty creates the EMF during application start (it has to, in order to register the Class Transformer [with the application classloader] before any of the persistent capable classes are loaded), but the transformation is invoked when the class is first loaded, which can happen at any time after the transformer has been registered.  In the customer scenario, two concurrent threads triggered a classload on the same application classloader.  Before the classloader perf-update, one thread would secure a lock on the classloader, while the second thread would get blocked, the class that it requested would be enhanced, and then it would unlock the classloader, which then the other thread would get its lock.
Now, both threads can concurrently request a class load without one being blocked, so both can enter the transformer (enhancer) and the same time.  One thread sets the _transforming boolean, and while that thread is doing its transforming work, the other thread sees that _transforming has been set, assumes that this is a reentrant call(x), and returns null -- meaning don't transform the class.  So the second thread's transform request does not happen, and the class is loaded untransformed, and thus cannot be used by openjpa.
(x) - The _transforming field was to prevent reentrancy which, in the days of single-threaded access, was assumed to be only possible by the thread that had the lock on the classloader, and during the transform, a classload occurred while in the transform method body and that classload (an openjpa library class is the only possibility at this point, it wouldn't be a PC-type) is being performed by the classloader that has the enhancer registered to it.  Since it was safe to assume that a reentrant call to the enhancer could only be an openjpa library type, that would never be enhanced, so just return null instead of going through the effort spent to check the type against the persistence unit's PC-type membership list.

Now, I can try to come up with an example to demonstrate it, but I am on a very tight deadline, so I can agree to delay committing the update to trunk, but I'm going to insist on the example not being a gating requirement for integrating into 2.2.x.

(updated the commit to rename _tl to _isTransformingInLocalThread based on a review comment by Albert.  Thanks!)

@jgrassel Hmm, a few things which makes this fix looking very weird to me:

fact is it is already synchronized by metadatarepository until Preload=true (see org.apache.openjpa.meta.MetaDataRepository#preload) so concurrency here is very unlikely so removing the threadlocal (and boolean) sounds better to me - I guess only Geronimo (and maybe WAS?) was using it out there due to a not conrrectly configured temp loader.
that _transforming boolean was not here for exactly what you describe but for the case you load a transformed class and - using the javaagent, not a deploy time or build time enhancement - you load openjpa (org.apache.openjpa.enhance.PCEnhancer typically but a few other classes as well).
a correct concurrent classloader locks around transform so the case you describe does not really happen and the boolean protection is not needed even with the javaagent (classloader#loadclass > findClass > transform for custom classloaders or loadclass > findclass > defineClass > transform for the jvm classloader)

So at the end it sounds like a bug in the classloader you use in openliberty so I would fix it there.
BTW where is Albert's review? I can't see it it seems.

I asked Albert via company internal slack to review my changes, he's not set up a link between github and apache yet.

@rmannibucau

preload=true is not enabled by default (at least it is not in the 2.2.x branch.)  Therefore the MDR will lazily initialize itself in incrementals that it finds necessary.  Also, processing reaches the _transforming check before touching the MDR (which yes, has synchronized access, but it is invoked only after _transforming is checked and set)

The _transforming field is there because it is possible for a classloader load to occur while the transform() is being executed, where the second load is an OpenJPA library type (for the scenario where OpenJPA is bundled in the application and thus is being loaded by the application classloader that will call on the enhancer to transform a class before loading it), which when classloader access is synchronized across threads, a reentrant call could be assumed to be this situation.  See Marc's commit from 14 years ago:

commit f74ac8b6b9f8d6f5c4fdae6798018458687741fc
Author: Marc Prud'hommeaux<EMAIL_ADDRESS>2006-09-29 21:00:40
Committer: Marc Prud'hommeaux<EMAIL_ADDRESS>2006-09-29 21:00:40
Parent:<PHONE_NUMBER>400dd42e4942d25cff310ac304dac0 (removed unneeded imports)
Child: e30632b60b26430fe4f95dd3f5a3bd79c4a36f9f (Trying a new approach to automatic enhancement in a container.  Might have to revert.)
Branches: 2.2.x_debug, 2.2.x_OJ2287, 2.2.x_OJ2790, 2.2.x_TS003776060_PH26967, 2.4.x_OJ2790, currentaccessdiag, DIAG_TS003449484, master, master_OJ2790, OJ2603, OPENJPA_2817_22X, pmr42014_211_788, QueryDebugForCase, trunk, TS000798754, TS001107772, TS001228829_DIAG01, TS001491495, TS002193952_detach_issue, TS002637050_testfix_2.2.x, ibmgit/1.2.x, ibmgit/2.2.x_debug and 71 more branches

Prevent reentrant calls to transform() in order to prevent attempts to enhance OpenJPA libraries (for cases where OpenJPA falls under the control of the enhancing class loader).

git-svn-id: https://svn.apache.org/repos/asf/incubator/openjpa/trunk@451517 13f79535-47bb-0310-9956-ffa450edef68

However, because now the classloader isn't going to synchronize between threads, we can't make that assumption anymore, hence we need to rely on a marker that is independent of the thread -- a ThreadLocal instead of a boolean.

This is an issue within the transformer/enhancer, I do not think shifting the burden of single-transformer entrancy to the application server is the correct solution.

@jgrassel

hmm, depends once again the env, with a javaagent it will be triggered on a new MyEntity() but on other cases it will not. And for javaagent this is not an issue since the context is protected properly by the classloader normally.
this is a setup bug we shouldn't have. Correct fix is probably to prevent openjpa to be loaded from the temp loader (likely container integration) and/or to skip openjpa stack in transform (we can skip more actually, see https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/util/classloader/URLClassLoaderFirst.java#L207 for a list example). A toggle is a quick and dirty fix but does not solve the cause of this issue IMHO. The threadlocal generalizes this workaround but still does not tackle the source of the issue. I'd like to fix it right on master at least.
The transformer is executed in a secured context by design/contract so this must be an issue with the env so part of 2 (the exclusion list in transform) and potentially server classloader enhancement support.

What the boolean - with a threadlocal or not - enables is to not enhance some classes - this is why sometimes we can have "missing metadata" error in some setup because if an enhancement triggers the load of another entity, this last one is not enhanced - depends the tmploader which can be the same as app loader when using an agent to speed up the execution/boot.
FYI: dropping the boolean the build still works fine so guess we should work forward the exclusion list.

This has nothing to do with the temp classloader.  The temp classloader itself doesn't have an enhancer registered to it, it only exists as a means for the persistence provider impl to load a class (in order to inspect it via reflection, though OpenJPA uses SERP for that business, I don't believe OpenJPA does much with the temp classloader that PersistenceUnitInfo can provide) without using the real application classloader (because once a class is loaded, that's it, the opportunity to enhance it has been missed.)

Personally, I'm not a fan of the "exclude list", because that adds a lot of unnecessary processing time, as String comparing a jar with hundreds and even thousands of classes against a group of patterns is not going to come cheap.  In an application server environment, as long as the jpa provider impl is not bundled with the application (that is, loaded by the same classloader that we register a class transformer with), then the reentrancy that the _transforming boolean was put in to guard against is not going to happen.  But it can if openjpa is bundled as part of the application and is loaded by the classloader which has the transformer registered to it.  That's what Marc's original method was to guard against.
But like I've said many times now, with ClassLoaders that permit concurrent classloading (and thus concurrent enhancing), the boolean method falls short because it doesn't detect thread-scoped reentrancy.

Okay, here is a maven project that will demonstrate the problem with an application server using openjpa.
Couple of notes:

Yes, you can use the mvn liberty:start goal in the ear directory (after building the entire project) to download Open Liberty and start the server, but it will use Eclipselink.
Open Liberty does not ship with OpenJPA, only Eclipselink.  It's Commercial Liberty that ships with OpenJPA in the form of the jpa-2.0 feature.  The maven tools will thus not be able to download the jpa-2.0 feature because it is not available to the open public.

However, you can build and extract the ear application generated, and run it on an application server that will run with OpenJPA.  The problem will only manifest itself if the application classloader allows for concurrent classloading and enhancement.
Example output using Commercial Liberty with the ear generated by this application:
OPENJPA-2817 Test Case

Starting Worker thread 1...
Starting Worker thread 2...
Worker Threads Complete.
Worker thread Thread-30 started.

Now to verify enhancement. Look at the interfaces associated with EntityA and EntityC:
Class: model.EntityA
Worker thread Thread-30 finished.
Interfaces:
org.apache.openjpa.enhance.PersistenceCapable

Class: model.EntityC
No Interfaces Found
Worker thread Thread-31 started.
Worker thread Thread-31 finished.

Note that with Eclipselink, which has a bytecode weaver that properly manages reentrancy, doesn't suffer from this problem:
OPENJPA-2817 Test Case

Starting Worker thread 1...
Starting Worker thread 2...
Worker thread Thread-16 started.
Worker thread Thread-17 started.
Worker thread Thread-17 finished.
Worker thread Thread-16 finished.
Worker Threads Complete.

Now to verify enhancement. Look at the interfaces associated with EntityA and EntityC:
Class: model.EntityA
Interfaces:
java.lang.Cloneable
org.eclipse.persistence.internal.weaving.PersistenceWeaved
org.eclipse.persistence.internal.descriptors.PersistenceEntity
org.eclipse.persistence.internal.descriptors.PersistenceObject
org.eclipse.persistence.queries.FetchGroupTracker
org.eclipse.persistence.internal.weaving.PersistenceWeavedFetchGroups
org.eclipse.persistence.descriptors.changetracking.ChangeTracker
org.eclipse.persistence.internal.weaving.PersistenceWeavedChangeTracking
org.eclipse.persistence.internal.weaving.PersistenceWeavedRest

Class: model.EntityC
Interfaces:
java.lang.Cloneable
org.eclipse.persistence.internal.weaving.PersistenceWeaved
org.eclipse.persistence.internal.descriptors.PersistenceEntity
org.eclipse.persistence.internal.descriptors.PersistenceObject
org.eclipse.persistence.queries.FetchGroupTracker
org.eclipse.persistence.internal.weaving.PersistenceWeavedFetchGroups
org.eclipse.persistence.descriptors.changetracking.ChangeTracker
org.eclipse.persistence.internal.weaving.PersistenceWeavedChangeTracking
org.eclipse.persistence.internal.weaving.PersistenceWeavedRest

openjpa_2817-project.zip

And in the OpenJPA case above, here is a cut of the trace log file showing EntityA (thread 000000a2) being enhanced, but EntityC (thread 000000a3) is not:
[7/13/20 17:44:15:317 CDT] 0000008f JPAPUnitInfo_ >  transformClass: PUID = PuId=jpasandbox_simple_web.ear-1.0-SNAPSHOT.ear#webapp.war#TestPU, class name = web.SimpleTestServlet$Worker, classBytes.length = 1907 Entry
                                 (file:/Users/jgrassel/Dev/Liberty/WS-CD-Open/dev/build.image/wlp/usr/servers/defaultServer/apps/jpasandbox_simple_web.ear-1.0-SNAPSHOT.ear <no signer certificates>)
                                 com.ibm.ws.classloading.internal.AppClassLoader@369bc432
[7/13/20 17:44:15:317 CDT] 0000008f JPAPUnitInfo  >  classNeedsTransform : PUID = PuId=jpasandbox_simple_web.ear-1.0-SNAPSHOT.ear#webapp.war#TestPU, class name = web.SimpleTestServlet$Worker Entry
[7/13/20 17:44:15:317 CDT] 0000008f JPAPUnitInfo  <  classNeedsTransform : web.SimpleTestServlet$Worker needs transform. Exit
[7/13/20 17:44:15:317 CDT] 0000008f JPAPUnitInfo_ 3   transformer: org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl@4192b75d , className: web.SimpleTestServlet$Worker
[7/13/20 17:44:15:317 CDT] 0000008f JPAPUnitInfo_ 3   transformer:org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl@4192b75d, web.SimpleTestServlet$Worker is NOT transformed. Byte length(old/new)=1907/1907
[7/13/20 17:44:15:317 CDT] 0000008f JPAPUnitInfo_ <  transformClass: 0/1 Exit
[7/13/20 17:44:15:321 CDT] 000000a3 JPAPUnitInfo_ >  transformClass: PUID = PuId=jpasandbox_simple_web.ear-1.0-SNAPSHOT.ear#webapp.war#TestPU, class name = model.EntityC, classBytes.length = 1219 Entry
                                 (file:/Users/jgrassel/Dev/Liberty/WS-CD-Open/dev/build.image/wlp/usr/servers/defaultServer/apps/jpasandbox_simple_web.ear-1.0-SNAPSHOT.ear <no signer certificates>)
                                 com.ibm.ws.classloading.internal.AppClassLoader@369bc432
[7/13/20 17:44:15:321 CDT] 000000a2 JPAPUnitInfo_ >  transformClass: PUID = PuId=jpasandbox_simple_web.ear-1.0-SNAPSHOT.ear#webapp.war#TestPU, class name = model.EntityA, classBytes.length = 2258 Entry
                                 (file:/Users/jgrassel/Dev/Liberty/WS-CD-Open/dev/build.image/wlp/usr/servers/defaultServer/apps/jpasandbox_simple_web.ear-1.0-SNAPSHOT.ear <no signer certificates>)
                                 com.ibm.ws.classloading.internal.AppClassLoader@369bc432
[7/13/20 17:44:15:322 CDT] 000000a2 JPAPUnitInfo  >  classNeedsTransform : PUID = PuId=jpasandbox_simple_web.ear-1.0-SNAPSHOT.ear#webapp.war#TestPU, class name = model.EntityA Entry
[7/13/20 17:44:15:322 CDT] 000000a3 JPAPUnitInfo  >  classNeedsTransform : PUID = PuId=jpasandbox_simple_web.ear-1.0-SNAPSHOT.ear#webapp.war#TestPU, class name = model.EntityC Entry
[7/13/20 17:44:15:322 CDT] 000000a2 JPAPUnitInfo  <  classNeedsTransform : model.EntityA needs transform. Exit
[7/13/20 17:44:15:322 CDT] 000000a2 JPAPUnitInfo_ 3   transformer: org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl@4192b75d , className: model.EntityA
[7/13/20 17:44:15:322 CDT] 000000a3 JPAPUnitInfo  <  classNeedsTransform : model.EntityC needs transform. Exit
[7/13/20 17:44:15:322 CDT] 000000a3 JPAPUnitInfo_ 3   transformer: org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl@4192b75d , className: model.EntityC
[7/13/20 17:44:15:322 CDT] 000000a3 JPAPUnitInfo_ 3   transformer:org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl@4192b75d, model.EntityC is NOT transformed. Byte length(old/new)=1219/1219
[7/13/20 17:44:15:322 CDT] 000000a3 JPAPUnitInfo_ <  transformClass: 0/1 Exit
[7/13/20 17:44:15:325 CDT] 000000a2 Enhance       3   openjpa.Enhance: Trace: "model.EntityA" requires runtime enhancement: true
[7/13/20 17:44:15:366 CDT] 000000a2 MetaData      3   openjpa.MetaData: Trace: Loading metadata for "class model.EntityA" under mode "[META][QUERY]".
[7/13/20 17:44:15:387 CDT] 000000a2 MetaData      3   openjpa.MetaData: Trace: Parsing class "model.EntityA".
[7/13/20 17:44:15:387 CDT] 000000a2 MetaData      3   openjpa.MetaData: Trace: Parsing package "model.EntityA".
[7/13/20 17:44:15:408 CDT] 000000a2 MetaData      3   openjpa.MetaData: Trace: Generating default metadata for type "model.EntityA".
[7/13/20 17:44:15:408 CDT] 000000a2 MetaData      3   openjpa.MetaData: Trace: Using reflection for metadata generation.
[7/13/20 17:44:15:420 CDT] 000000a2 MetaData      3   openjpa.MetaData: Trace: Set persistence-capable superclass of "model.EntityA" to "null".
[7/13/20 17:44:15:422 CDT] 000000a2 MetaData      3   openjpa.MetaData: Trace: Resolving metadata for "model.EntityA@5732165".
[7/13/20 17:44:15:422 CDT] 000000a2 MetaData      3   openjpa.MetaData: Trace: 	Resolving field<EMAIL_ADDRESS>[7/13/20 17:44:15:422 CDT] 000000a2 MetaData      3   openjpa.MetaData: Trace: Loading metadata for "class model.EntityB" under mode "[META][QUERY]".
[7/13/20 17:44:15:422 CDT] 000000a2 MetaData      3   openjpa.MetaData: Trace: Parsing class "model.EntityB".
[7/13/20 17:44:15:422 CDT] 000000a2 MetaData      3   openjpa.MetaData: Trace: Generating default metadata for type "model.EntityB".
[7/13/20 17:44:15:422 CDT] 000000a2 MetaData      3   openjpa.MetaData: Trace: Using reflection for metadata generation.
[7/13/20 17:44:15:423 CDT] 000000a2 MetaData      3   openjpa.MetaData: Trace: Set persistence-capable superclass of "model.EntityB" to "null".
[7/13/20 17:44:15:430 CDT] 000000a2 MetaData      3   openjpa.MetaData: Trace: 	Resolving field<EMAIL_ADDRESS>[7/13/20 17:44:15:430 CDT] 000000a2 MetaData      3   openjpa.MetaData: Trace: 	Resolving field<EMAIL_ADDRESS>[7/13/20 17:44:15:430 CDT] 000000a2 MetaData      3   openjpa.MetaData: Trace: 	Resolving field<EMAIL_ADDRESS>[7/13/20 17:44:15:430 CDT] 000000a2 MetaData      3   openjpa.MetaData: Trace: 	Resolving field<EMAIL_ADDRESS>[7/13/20 17:44:15:431 CDT] 000000a2 MetaData      3   openjpa.MetaData: Trace: Resolving metadata for "model.EntityB@55778804".
[7/13/20 17:44:15:431 CDT] 000000a2 MetaData      3   openjpa.MetaData: Trace: 	Resolving field<EMAIL_ADDRESS>[7/13/20 17:44:15:431 CDT] 000000a2 MetaData      3   openjpa.MetaData: Trace: 	Resolving field<EMAIL_ADDRESS>[7/13/20 17:44:15:432 CDT] 000000a2 Enhance       3   openjpa.Enhance: Trace: Enhancing type "class model.EntityA" loaded by com.ibm.ws.classloading.internal.ShadowClassLoader@79eae7e4.
[7/13/20 17:44:15:459 CDT] 000000a2 Enhance       3   openjpa.Enhance: Trace: Enhancement for "model.EntityA" completed. Class size: [2,258/10,803]
[7/13/20 17:44:15:459 CDT] 000000a2 JPAPUnitInfo_ 3   transformer:org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl@4192b75d, model.EntityA is transformed. Byte length(old/new)=2258/10803
[7/13/20 17:44:15:459 CDT] 000000a2 JPAPUnitInfo_ <  transformClass: 1/1 Exit

Notice we only see: openjpa.Enhance: Trace: "model.EntityA" requires runtime enhancement: true, but not for EntityC, because the boolean short circuits hitting the MDR.

I've now read the SE7 documentation about a few times and I think the ThreadLocal is not enough for this specific case. From the ClassLoader doc it appears that the lock now got moved from a full exclusive Semaphore to a Lock by ClassLoader+Classname.
So - without digging into all the details - it seems logical to also move from a Boolean to a Map<String, Boolean> were the key is the CL id + Classname ?

@struberg point is that the classloader does it and the transformer is called under that lock already
@jgrassel will test your sample but today I'm off but I will come back to you likely tomorrow, thanks a lot for setting up a project!

Created https://github.com/apache/openjpa/pull/65 as a proposed fix on master if you want to give it a try.

Here's a version of the test bucket that will run with the jpa-2.2 complaint version of OpenJPA
You'll need to edit the pom.xml file at the project root, and put in the full classname for the ProviderImpl class, as well as the directory where all of the jpa impl jar and its dependent libraries are (be sure to remove the jars containing javax.* packages) -- I moved the openjpa impl jar into lib so that all of the jars were in one dir:
        <!-- Third Party JPA Persistence Provider Configuration
             Persistence Provider Class - fully qualified classname of the provider's implementation of javax.persistence.spi.PersistenceProvider -->

        <thirdPartyJPAProviderClass>org.apache.openjpa.persistence.PersistenceProviderImpl</thirdPartyJPAProviderClass>

        <!-- Path to Third Party JPA Persistence Privider jars -->

        <!-- For openjpa, removed the jars containing javax. packages, and moved the openjpa impl into lib -->
        <thirdPartyJPAProviderPath>/Users/jgrassel/dev/Apache/drivers/apache-openjpa-3.1.0/lib</thirdPartyJPAProviderPath>

simple-webWithThirdPartyJPAProvider-project.zip

I was able to reproduce the enhancement failure issue with OpenJPA 3.1.0 this way on Open Liberty.

@jgrassel thanks a lot, I was able to test it on 3.1.2 too and also checked the proposed patch in my PR fixes that issue.

@jgrassel not with 3.1.2  (:() but with a patched 3.1.3-SNAPSHOT (still trying to find a good solution we both agree on before merging/pushing)


Trackplayer.getProgress() return pause state instead of ideal after finishing the current track in iOS

Configuration
Run react-native info in your project and share the content.
What react-native-track-player version are you using?
Issue

Code
Show us the code you are using

Please provide more details.
Please test if this has improved in v1.2.3


Use winget to install or modify Visual Studio

Have a look at Use winget to install or modify Visual Studio:

You can use the Windows Package Manager "winget" tool to programmatically install, modify, or update Visual Studio on your machine along with other packages managed by winget.

I have used this before (see https://github.com/tarides/infrastructure/blob/791e0f8bb6ff5c8dd9e3f54122edcaa158087ec5/hopi.caelum.ci.dev/windows-desktops/roles/visual-studio/tasks/main.yml#L3) however, I found Chocolatey to be more reliable when running under Ansible.
I noticed that we jump through a lot of hoops to install WinGet on Windows Server Core, where it isn't actually supported. Then, we only use it to install Git. I wondered if we could actually dispense with WinGet altogether and just use the Git installer.

The idea was to use WinGet to install other things in the future, and to make sure we have one default package manager for Windows things.
I'm not surprised that another package manager would be more reliable.


Option to reset instead of halting

Halting is fine for development, but I can't really expect end-users to grab a pair of tweezers and short a pair of pads in case their device panics. At least not in every one of my projects :)

True - until now this is mainly meant to help during development. Not really thought about the production use case.
I could also think about some additional features like persisting the backtrace and panic/exception information - then the application could optionally send this to a server on next boot

Persisting is a good idea. To spin it further, I think it should be opt-in, with a user-provided buffer. A bit tricky to use because the buffer needs to be placed in an uninitialized section, but one can then choose how much memory one can sacrifice for something that, in an ideal world would never be used :)


Add support for fetching consumer offsets stored in Kafka to monitor_unlisted_consumer_groups

Add support for fetching consumer offsets stored in Kafka to monitor_unlisted_consumer_groups
Major refactor of kafka_consumer check with a new code path that will exist alongside the legacy code path. The new code path:

Eliminates legacy cruft:

drops support for fetching consumer offsets from zookeeper
drops support for brokers < 0.10.2 which do not support fetching all known offsets for a consumer group
migrates from the hand-rolled group-coordinator lookup code, retries, etc to relying on  kafka-python's KafkaAdminClient to handle all that under the covers

Adds support for monitor_unlisted_consumer_groups to fetch consumer offsets from Kafka
Refactors from sync to async using callbacks for improved performance, especially with larger clusters and more consumer groups.

To clarify: Fetching consumer offsets from older brokers and from zookeeper is still supported, it just uses the legacy code path instead of this new code path.
Motivation
This has been under discussion in various forms for over two years, see https://github.com/DataDog/integrations-core/pull/423 and https://github.com/DataDog/integrations-core/pull/2730. The main blocker was coming up with a clean way to support legacy features like fetching from Zookeeper / older brokers while simultaneously migrating to kafka-python's new KafkaAdminClient which only supports brokers >= 0.10.0. After several rounds of discussion, the decision was to move the legacy code into a separate file and start from scratch with a new implementation of the check which would be the primary one for new features moving forward.
Status: Working
The remaining TODO's mentioned in the code are small refinements that I am unlikely to have time to do, but wanted to still note for later developers.
This depends on unreleased code within kafka-python, so can't be merged until kafka-python releases 1.4.7 (I'm on the maintainer team, so will help make that happen).
My personal TODO list:

[x] port the check changes from https://github.com/DataDog/integrations-core/pull/2730
[x] port relevant changes to conf.yaml.example from https://github.com/DataDog/integrations-core/pull/2730
[x] review the commit history of existing legacy check after I wrote https://github.com/DataDog/integrations-core/pull/2730 to make sure I incorporate any additional necessary changes such as A6 and python3 related changes
[x] make the change from sync to async callbacks
[x] bump the kafka-python dep version to pull in the patches required for callbacks and faster polling

Blocked on https://github.com/dpkp/kafka-python/issues/1903


Remove show page for description requests

Description of change
Design change requests:

Remove show page for description requests
Link new document edit page to change requests index

I think we need to remove the show action from the controller too?


[feature]: Search function helper for navbar

A reader should be able to open a popup when clicking on a 'Search' button
This popover is composed of an input item and a list item
The list should be loaded asynchronously
The search icon could be placed next to the theme button
Perhaps try https://lunrjs.com/guides/getting_started.html? (without jquery)

implemented in v0.2.1


Right-to-left arabic weirdness with parentheses

I'm using safari Version 7.1 (95<IP_ADDRESS>.1) on the OSX 10.9.5
if i type open parenthesis ش closeparenthesis ش the outcome looks like

rather than

Which I'm informed is the unicode standard way of rendering them (all documented here apparently http://www.unicode.org/reports/tr9/ ).

I should say, this can be reproduced with the hosted version of http://codemirror.net/demo/bidi.html  (just delete all the text and start typing in what I describe above).

The direction branch isn't relevant anymore -- anything in there is probably implemented better in the master branch.


Hubot doesn't respond to messages from integrations/bots

Hubot doesn't respond to trigger words posted using other integrations/bots/webhooks.

@mrkrumhausen Were you able to get around this problem? If so, how?

No, it's to avoid infinite loops.

@mrkrumhausen I was able to get around this by listening to all messages, which include the bot messages

Cool. How?

https://github.com/github/hubot/blob/master/docs/patterns.md#dynamic-matching-of-messages

I should be clear. It doesn't get its own messages with this. Which is a good thing. Infinite loops and such

Awesome. Thanks!


It says yarn is not installed when it's installed

What version of Turborepo are you using?
1.0.10
Describe the Bug
It says yarn is not installed but it is installed

Expected Behavior
I can use yarn
To Reproduce
run npx create-turbo@latest

same for me

I also face the same issue using Windows

I also have the same problem on Linux (kde neon, based on ubuntu 20.04)

i think I found the problem still investigating

I cannot reproduce the problem with the following localy, so maybe npm_config_user_agent is set to something strange when running create-turbo from npx.
const inquirer = require("inquirer");
const { execSync } = require("child_process");

function shouldUseYarn() {
  try {
    const userAgent = process.env.npm_config_user_agent;
    if (userAgent) {
      return Boolean(userAgent && userAgent.startsWith("yarn"));
    }
    execSync("yarnpkg --version", { stdio: "ignore" });
    return true;
  } catch (e) {
    return false;
  }
}

const isYarnInstalled = shouldUseYarn();

async function main() {
  let answers = await inquirer.prompt([
    {
      name: "packageManager",
      type: "list",
      message: "Which package manager do you want to use?",
      choices: [
        {
          name: "Yarn",
          value: "yarn",
          disabled: !isYarnInstalled && "not installed",
        },
        { name: "NPM", value: "npm" },
        // { name: "PNPM", value: "pnpm" },
      ],
    },
    {
      name: "install",
      type: "confirm",
      message: function (answers) {
        return `Do you want me to run \`${answers.packageManager} install\`?`;
      },
      default: true,
    },
  ]);
}

main();

the issue was here
if (userAgent) {       return Boolean(userAgent && userAgent.startsWith("yarn"));     }
if you used npm this will always return false and the function won't continue to the next line that checks if yarn is installed


Permission denied PKG_CONFIG_PATH

I'm trying to use this buildpack on aws/dokku but everytimr got errors.
=====> Downloading Buildpack: https://github.com/alex88/heroku-buildpack-vips.git
=====> Detected Framework:
-----> Installing libvips
       Downloading libvips and unpacking
       libvips installed
remote: /tmp/buildpackoUpxX/bin/compile: line 52: /tmp/env/PKG_CONFIG_PATH: Permission denied

Dokku bug, sorry

@dotcypress I know it a Dokku issue but did you find a fix as having the same problem and struggling to fix


⚠ Bofrost.be has degraded performance

In 77b71e1, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1304 ms

Resolved: Bofrost.be performance has improved in 1445219.


low on memory warning chromeOS

`

#### Please describe your issue: procs stay in memory doing nothing

#### If known, describe the steps to reproduce the issue:
run sudo startxiwi -f -b xfce4-terminal
exit the terminal
in the crosh shelll
here what happens
chronos@localhost /media/removable/sd200/z $ sudo rm -rf chroots
Password:
rm: cannot remove 'chroots/bull/run': Device or resource busy
rm: cannot remove 'chroots/bull/home/z/Downloads': Device or resource busy
rm: cannot remove 'chroots/bull/proc': Device or resource busy
rm: cannot remove 'chroots/bull/dev': Device or resource busy
rm: cannot remove 'chroots/bull/tmp': Device or resource busy
rm: cannot remove 'chroots/bull/var/host/shill': Device or resource busy
rm: cannot remove 'chroots/bull/var/host/timezone': Device or resource busy
rm: cannot remove 'chroots/bull/var/host/cras': Device or resource busy
rm: cannot remove 'chroots/bull/var/host/udev': Device or resource busy
rm: cannot remove 'chroots/bull/var/host/media': Device or resource busy
rm: cannot remove 'chroots/bull/var/host/chrome': Device or resource busy
rm: cannot remove 'chroots/bull/var/host/dbus': Device or resource busy
rm: cannot remove 'chroots/bull/sys': Device or resource busy
rm: cannot remove 'chroots/bull/usr/lib/modules/4.19.255-13653-ga5ef616743fe': Device or resource busy

bookworm has much better proc management and the video is not the same as kali-rolling

move to my fork


File permissions

Hello, there are many files in the lexbor Git repository tracked with permissions 0755 (executable). Git can track executable (0755) and non-executable (0644) file modes. Would it be fine to sent PR that changes permissions for some of those files that can be tracked with the usual 644 permissions?
This would help when the lexbor needs to be bundled in other Git repositories. Thanks.
5 files from 664 to 775
✘ utils/lexbor/unicode/idna_test.pl
  - permissions from 664 to 775

✘ utils/lexbor/unicode/make.pl
  - permissions from 664 to 775

✘ utils/lexbor/unicode/test.pl
  - permissions from 664 to 775

✘ utils/lexbor/css/syntax/definitions.py
  - permissiosn from 664 to 775

✘ utils/lexbor/css/syntax/tokenizer_code_map.py
  - permissions from 664 to 775

458 of 1142 files from 775 to 664
✘ source/lexbor/utils/config.cmake
  - permissions from 775 to 664

✘ source/lexbor/punycode/config.cmake
  - permissions from 775 to 664

✘ source/lexbor/css/syntax/tokenizer.h
  - permissions from 775 to 664

✘ source/lexbor/css/syntax/tokenizer/error.c
  - permissions from 775 to 664

✘ source/lexbor/css/syntax/tokenizer/error.h
  - permissions from 775 to 664

✘ source/lexbor/css/syntax/tokenizer.c
  - permissions from 775 to 664

✘ source/lexbor/css/config.cmake
  - permissions from 775 to 664

✘ source/lexbor/tag/tag.h
  - permissions from 775 to 664

✘ source/lexbor/tag/tag.c
  - permissions from 775 to 664

✘ source/lexbor/tag/config.cmake
  - permissions from 775 to 664

✘ source/lexbor/url/config.cmake
  - permissions from 775 to 664

✘ source/lexbor/html/token.h
  - permissions from 775 to 664

✘ source/lexbor/html/tree.h
  - permissions from 775 to 664

✘ source/lexbor/html/tree.c
  - permissions from 775 to 664

✘ source/lexbor/html/token.c
  - permissions from 775 to 664

✘ source/lexbor/html/interface.c
  - permissions from 775 to 664

✘ source/lexbor/html/tag.h
  - permissions from 775 to 664

✘ source/lexbor/html/tree_res.h
  - permissions from 775 to 664

✘ source/lexbor/html/interface.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/anchor_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/output_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/d_list_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/heading_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/html_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/body_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/table_caption_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/directory_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/table_section_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/d_list_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/u_list_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/paragraph_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/legend_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/label_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/template_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/font_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/title_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/embed_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/div_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/button_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/track_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/script_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/script_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/head_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/table_cell_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/base_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/document.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/frame_set_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/time_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/document.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/form_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/menu_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/select_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/text_area_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/data_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/media_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/menu_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/unknown_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/image_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/select_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/details_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/hr_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/window.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/quote_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/details_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/option_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/data_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/table_cell_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/area_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/label_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/canvas_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/source_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/iframe_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/track_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/table_row_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/heading_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/meter_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/title_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/quote_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/link_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/table_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/window.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/br_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/frame_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/table_row_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/progress_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/meta_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/meta_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/map_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/pre_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/audio_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/frame_set_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/canvas_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/video_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/template_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/input_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/pre_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/field_set_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/form_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/opt_group_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/mod_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/meter_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/body_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/html_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/paragraph_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/hr_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/mod_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/li_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/slot_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/picture_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/legend_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/object_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/option_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/output_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/dialog_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/br_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/style_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/base_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/style_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/u_list_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/slot_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/marquee_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/frame_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/table_col_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/link_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/span_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/dialog_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/table_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/head_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/marquee_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/image_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/table_col_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/li_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/data_list_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/map_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/span_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/font_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/table_section_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/opt_group_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/audio_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/source_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/area_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/field_set_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/progress_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/data_list_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/param_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/div_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/anchor_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/input_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/iframe_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/table_caption_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/picture_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/directory_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/text_area_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/param_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/button_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/o_list_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/object_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/unknown_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/o_list_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/media_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/embed_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/video_element.c
  - permissions from 775 to 664

✘ source/lexbor/html/interfaces/time_element.h
  - permissions from 775 to 664

✘ source/lexbor/html/tokenizer.h
  - permissions from 775 to 664

✘ source/lexbor/html/tree/open_elements.c
  - permissions from 775 to 664

✘ source/lexbor/html/tree/insertion_mode.h
  - permissions from 775 to 664

✘ source/lexbor/html/tree/active_formatting.h
  - permissions from 775 to 664

✘ source/lexbor/html/tree/insertion_mode/in_caption.c
  - permissions from 775 to 664

✘ source/lexbor/html/tree/insertion_mode/in_table_body.c
  - permissions from 775 to 664

✘ source/lexbor/html/tree/insertion_mode/in_frameset.c
  - permissions from 775 to 664

✘ source/lexbor/html/tree/insertion_mode/in_table.c
  - permissions from 775 to 664

✘ source/lexbor/html/tree/insertion_mode/in_template.c
  - permissions from 775 to 664

✘ source/lexbor/html/tree/insertion_mode/in_head_noscript.c
  - permissions from 775 to 664

✘ source/lexbor/html/tree/insertion_mode/foreign_content.c
  - permissions from 775 to 664

✘ source/lexbor/html/tree/insertion_mode/in_table_text.c
  - permissions from 775 to 664

✘ source/lexbor/html/tree/insertion_mode/in_body.c
  - permissions from 775 to 664

✘ source/lexbor/html/tree/insertion_mode/after_body.c
  - permissions from 775 to 664

✘ source/lexbor/html/tree/insertion_mode/in_head.c
  - permissions from 775 to 664

✘ source/lexbor/html/tree/insertion_mode/after_frameset.c
  - permissions from 775 to 664

✘ source/lexbor/html/tree/insertion_mode/before_head.c
  - permissions from 775 to 664

✘ source/lexbor/html/tree/insertion_mode/initial.c
  - permissions from 775 to 664

✘ source/lexbor/html/tree/insertion_mode/after_after_body.c
  - permissions from 775 to 664

✘ source/lexbor/html/tree/insertion_mode/in_select.c
  - permissions from 775 to 664

✘ source/lexbor/html/tree/insertion_mode/text.c
  - permissions from 775 to 664

✘ source/lexbor/html/tree/insertion_mode/before_html.c
  - permissions from 775 to 664

✘ source/lexbor/html/tree/insertion_mode/in_select_in_table.c
  - permissions from 775 to 664

✘ source/lexbor/html/tree/insertion_mode/in_cell.c
  - permissions from 775 to 664

✘ source/lexbor/html/tree/insertion_mode/after_head.c
  - permissions from 775 to 664

✘ source/lexbor/html/tree/insertion_mode/in_row.c
  - permissions from 775 to 664

✘ source/lexbor/html/tree/insertion_mode/after_after_frameset.c
  - permissions from 775 to 664

✘ source/lexbor/html/tree/insertion_mode/in_column_group.c
  - permissions from 775 to 664

✘ source/lexbor/html/tree/error.c
  - permissions from 775 to 664

✘ source/lexbor/html/tree/active_formatting.c
  - permissions from 775 to 664

✘ source/lexbor/html/tree/template_insertion.h
  - permissions from 775 to 664

✘ source/lexbor/html/tree/error.h
  - permissions from 775 to 664

✘ source/lexbor/html/tree/template_insertion.c
  - permissions from 775 to 664

✘ source/lexbor/html/tree/open_elements.h
  - permissions from 775 to 664

✘ source/lexbor/html/tokenizer/state_doctype.h
  - permissions from 775 to 664

✘ source/lexbor/html/tokenizer/res.h
  - permissions from 775 to 664

✘ source/lexbor/html/tokenizer/state_rcdata.h
  - permissions from 775 to 664

✘ source/lexbor/html/tokenizer/state_comment.c
  - permissions from 775 to 664

✘ source/lexbor/html/tokenizer/state_script.c
  - permissions from 775 to 664

✘ source/lexbor/html/tokenizer/state_rawtext.h
  - permissions from 775 to 664

✘ source/lexbor/html/tokenizer/state_rcdata.c
  - permissions from 775 to 664

✘ source/lexbor/html/tokenizer/error.c
  - permissions from 775 to 664

✘ source/lexbor/html/tokenizer/state_rawtext.c
  - permissions from 775 to 664

✘ source/lexbor/html/tokenizer/state.c
  - permissions from 775 to 664

✘ source/lexbor/html/tokenizer/state.h
  - permissions from 775 to 664

✘ source/lexbor/html/tokenizer/state_doctype.c
  - permissions from 775 to 664

✘ source/lexbor/html/tokenizer/error.h
  - permissions from 775 to 664

✘ source/lexbor/html/tokenizer/state_comment.h
  - permissions from 775 to 664

✘ source/lexbor/html/tokenizer/state_script.h
  - permissions from 775 to 664

✘ source/lexbor/html/base.h
  - permissions from 775 to 664

✘ source/lexbor/html/serialize.c
  - permissions from 775 to 664

✘ source/lexbor/html/token_attr.c
  - permissions from 775 to 664

✘ source/lexbor/html/serialize.h
  - permissions from 775 to 664

✘ source/lexbor/html/tokenizer.c
  - permissions from 775 to 664

✘ source/lexbor/html/config.cmake
  - permissions from 775 to 664

✘ source/lexbor/html/parser.h
  - permissions from 775 to 664

✘ source/lexbor/html/parser.c
  - permissions from 775 to 664

✘ source/lexbor/html/token_attr.h
  - permissions from 775 to 664

✘ source/lexbor/unicode/config.cmake
  - permissions from 775 to 664

✘ source/lexbor/encoding/config.cmake
  - permissions from 775 to 664

✘ source/lexbor/ns/ns.c
  - permissions from 775 to 664

✘ source/lexbor/ns/ns.h
  - permissions from 775 to 664

✘ source/lexbor/ns/config.cmake
  - permissions from 775 to 664

✘ source/lexbor/dom/interface.h
  - permissions from 775 to 664

✘ source/lexbor/dom/interfaces/character_data.h
  - permissions from 775 to 664

✘ source/lexbor/dom/interfaces/document_type.h
  - permissions from 775 to 664

✘ source/lexbor/dom/interfaces/comment.c
  - permissions from 775 to 664

✘ source/lexbor/dom/interfaces/element.h
  - permissions from 775 to 664

✘ source/lexbor/dom/interfaces/element.c
  - permissions from 775 to 664

✘ source/lexbor/dom/interfaces/document.h
  - permissions from 775 to 664

✘ source/lexbor/dom/interfaces/document.c
  - permissions from 775 to 664

✘ source/lexbor/dom/interfaces/document_type.c
  - permissions from 775 to 664

✘ source/lexbor/dom/interfaces/shadow_root.h
  - permissions from 775 to 664

✘ source/lexbor/dom/interfaces/document_fragment.h
  - permissions from 775 to 664

✘ source/lexbor/dom/interfaces/node.h
  - permissions from 775 to 664

✘ source/lexbor/dom/interfaces/shadow_root.c
  - permissions from 775 to 664

✘ source/lexbor/dom/interfaces/character_data.c
  - permissions from 775 to 664

✘ source/lexbor/dom/interfaces/comment.h
  - permissions from 775 to 664

✘ source/lexbor/dom/interfaces/document_fragment.c
  - permissions from 775 to 664

✘ source/lexbor/dom/interfaces/text.c
  - permissions from 775 to 664

✘ source/lexbor/dom/interfaces/event_target.h
  - permissions from 775 to 664

✘ source/lexbor/dom/interfaces/node.c
  - permissions from 775 to 664

✘ source/lexbor/dom/interfaces/text.h
  - permissions from 775 to 664

✘ source/lexbor/dom/interfaces/processing_instruction.c
  - permissions from 775 to 664

✘ source/lexbor/dom/interfaces/event_target.c
  - permissions from 775 to 664

✘ source/lexbor/dom/interfaces/cdata_section.c
  - permissions from 775 to 664

✘ source/lexbor/dom/interfaces/processing_instruction.h
  - permissions from 775 to 664

✘ source/lexbor/dom/interfaces/cdata_section.h
  - permissions from 775 to 664

✘ source/lexbor/dom/config.cmake
  - permissions from 775 to 664

✘ source/lexbor/core/shs.h
  - permissions from 775 to 664

✘ source/lexbor/core/utils.h
  - permissions from 775 to 664

✘ source/lexbor/core/strtod.c
  - permissions from 775 to 664

✘ source/lexbor/core/in.h
  - permissions from 775 to 664

✘ source/lexbor/core/sbst.h
  - permissions from 775 to 664

✘ source/lexbor/core/lexbor.h
  - permissions from 775 to 664

✘ source/lexbor/core/dtoa.c
  - permissions from 775 to 664

✘ source/lexbor/core/bst.h
  - permissions from 775 to 664

✘ source/lexbor/core/str.c
  - permissions from 775 to 664

✘ source/lexbor/core/dtoa.h
  - permissions from 775 to 664

✘ source/lexbor/core/bst_map.h
  - permissions from 775 to 664

✘ source/lexbor/core/shs.c
  - permissions from 775 to 664

✘ source/lexbor/core/array.h
  - permissions from 775 to 664

✘ source/lexbor/core/diyfp.h
  - permissions from 775 to 664

✘ source/lexbor/core/dobject.h
  - permissions from 775 to 664

✘ source/lexbor/core/mraw.h
  - permissions from 775 to 664

✘ source/lexbor/core/plog.h
  - permissions from 775 to 664

✘ source/lexbor/core/avl.h
  - permissions from 775 to 664

✘ source/lexbor/core/bst_map.c
  - permissions from 775 to 664

✘ source/lexbor/core/str_res.h
  - permissions from 775 to 664

✘ source/lexbor/core/bst.c
  - permissions from 775 to 664

✘ source/lexbor/core/dobject.c
  - permissions from 775 to 664

✘ source/lexbor/core/array.c
  - permissions from 775 to 664

✘ source/lexbor/core/str.h
  - permissions from 775 to 664

✘ source/lexbor/core/utils.c
  - permissions from 775 to 664

✘ source/lexbor/core/mem.h
  - permissions from 775 to 664

✘ source/lexbor/core/fs.h
  - permissions from 775 to 664

✘ source/lexbor/core/in.c
  - permissions from 775 to 664

✘ source/lexbor/core/types.h
  - permissions from 775 to 664

✘ source/lexbor/core/def.h
  - permissions from 775 to 664

✘ source/lexbor/core/avl.c
  - permissions from 775 to 664

✘ source/lexbor/core/mraw.c
  - permissions from 775 to 664

✘ source/lexbor/core/array_obj.c
  - permissions from 775 to 664

✘ source/lexbor/core/diyfp.c
  - permissions from 775 to 664

✘ source/lexbor/core/config.cmake
  - permissions from 775 to 664

✘ source/lexbor/core/plog.c
  - permissions from 775 to 664

✘ source/lexbor/core/mem.c
  - permissions from 775 to 664

✘ source/lexbor/core/strtod.h
  - permissions from 775 to 664

✘ source/lexbor/core/array_obj.h
  - permissions from 775 to 664

✘ source/lexbor/selectors/config.cmake
  - permissions from 775 to 664

✘ source/lexbor/ports/posix/lexbor/core/memory.c
  - permissions from 775 to 664

✘ source/lexbor/ports/posix/lexbor/core/fs.c
  - permissions from 775 to 664

✘ source/lexbor/ports/posix/config.cmake
  - permissions from 775 to 664

✘ source/lexbor/ports/windows_nt/lexbor/core/memory.c
  - permissions from 775 to 664

✘ source/lexbor/ports/windows_nt/config.cmake
  - permissions from 775 to 664

✘ examples/lexbor/encoding/single/from_to.c
  - permissions from 775 to 664

✘ examples/lexbor/encoding/single/decode/decode.c
  - permissions from 775 to 664

✘ examples/lexbor/encoding/single/decode/validate.c
  - permissions from 775 to 664

✘ examples/lexbor/encoding/single/decode/decoder.c
  - permissions from 775 to 664

✘ examples/lexbor/encoding/single/encode/validate.c
  - permissions from 775 to 664

✘ examples/lexbor/encoding/single/encode/encoder.c
  - permissions from 775 to 664

✘ examples/lexbor/encoding/single/encode/encode.c
  - permissions from 775 to 664

✘ packaging/README.md
  - permissions from 775 to 664

✘ utils/lexbor/tag_ns/tmp/interface.c
  - permissions from 775 to 664

✘ utils/lexbor/tag_ns/tmp/ns_res.h
  - permissions from 775 to 664

✘ utils/lexbor/tag_ns/tmp/html_interface_res.h
  - permissions from 775 to 664

✘ utils/lexbor/tag_ns/tmp/html_tag_res.h
  - permissions from 775 to 664

✘ utils/lexbor/tag_ns/tmp/ns_const.h
  - permissions from 775 to 664

✘ utils/lexbor/tag_ns/tmp/test/tag_res.c
  - permissions from 775 to 664

✘ utils/lexbor/tag_ns/tmp/test/ns_res.c
  - permissions from 775 to 664

✘ utils/lexbor/tag_ns/tmp/interface.h
  - permissions from 775 to 664

✘ utils/lexbor/tag_ns/tmp/tag_res.h
  - permissions from 775 to 664

✘ utils/lexbor/tag_ns/tmp/tag_const.h
  - permissions from 775 to 664

✘ utils/lexbor/tag_ns/data/tags.json
  - permissions from 775 to 664

✘ utils/lexbor/tag_ns/data/interfaces.json
  - permissions from 775 to 664

✘ utils/lexbor/css/tmp/res.h
  - permissions from 775 to 664

✘ utils/lexbor/css/tmp/value_res.h
  - permissions from 775 to 664

✘ utils/lexbor/css/tmp/value_const.h
  - permissions from 775 to 664

✘ utils/lexbor/css/tmp/const.h
  - permissions from 775 to 664

✘ utils/lexbor/css/selectors/tmp/res.h
  - permissions from 775 to 664

✘ utils/lexbor/css/selectors/tmp/const.h
  - permissions from 775 to 664

✘ utils/lexbor/html/tmp/insertion_mode.h
  - permissions from 775 to 664

✘ utils/lexbor/html/tmp/tokenizer_res.h
  - permissions from 775 to 664

✘ utils/lexbor/html/tmp/insertion_mode.c
  - permissions from 775 to 664

✘ utils/lexbor/html/data/entities.json
  - permissions from 775 to 664

✘ utils/lexbor/grammar/token.h
  - permissions from 775 to 664

✘ utils/lexbor/grammar/token.c
  - permissions from 775 to 664

✘ utils/lexbor/grammar/node.h
  - permissions from 775 to 664

✘ utils/lexbor/grammar/tokenizer.h
  - permissions from 775 to 664

✘ utils/lexbor/grammar/base.h
  - permissions from 775 to 664

✘ utils/lexbor/grammar/node.c
  - permissions from 775 to 664

✘ utils/lexbor/grammar/grammar.c
  - permissions from 775 to 664

✘ utils/lexbor/grammar/tokenizer.c
  - permissions from 775 to 664

✘ utils/lexbor/grammar/parser.h
  - permissions from 775 to 664

✘ utils/lexbor/grammar/parser.c
  - permissions from 775 to 664

✘ utils/lexbor/encoding/tmp/range.h
  - permissions from 775 to 664

✘ utils/lexbor/encoding/tmp/multi.h
  - permissions from 775 to 664

✘ utils/lexbor/encoding/tmp/res.h
  - permissions from 775 to 664

✘ utils/lexbor/encoding/tmp/buffer_single_byte_test.c
  - permissions from 775 to 664

✘ utils/lexbor/encoding/tmp/single_byte_test.c
  - permissions from 775 to 664

✘ utils/lexbor/encoding/tmp/single.h
  - permissions from 775 to 664

✘ utils/lexbor/encoding/tmp/single.c
  - permissions from 775 to 664

✘ utils/lexbor/encoding/tmp/range.c
  - permissions from 775 to 664

✘ utils/lexbor/encoding/tmp/multi.c
  - permissions from 775 to 664

✘ utils/lexbor/encoding/tmp/const.h
  - permissions from 775 to 664

✘ utils/lexbor/encoding/tmp/res.c
  - permissions from 775 to 664

✘ utils/lexbor/dom/tmp/res.h
  - permissions from 775 to 664

✘ utils/lexbor/dom/tmp/const.h
  - permissions from 775 to 664

✘ CHANGELOG.md
  - permissions from 775 to 664

✘ test/lexbor/punycode/base.c
  - permissions from 775 to 664

✘ test/lexbor/css/declarations.c
  - permissions from 775 to 664

✘ test/lexbor/css/stylesheet.c
  - permissions from 775 to 664

✘ test/lexbor/css/syntax/an_plus_b.c
  - permissions from 775 to 664

✘ test/lexbor/css/syntax/tokenizer_queue.c
  - permissions from 775 to 664

✘ test/lexbor/css/syntax/style.c
  - permissions from 775 to 664

✘ test/lexbor/css/syntax/tokenizer.c
  - permissions from 775 to 664

✘ test/lexbor/css/syntax/parser.c
  - permissions from 775 to 664

✘ test/lexbor/css/syntax/parser_offsets.c
  - permissions from 775 to 664

✘ test/lexbor/css/selectors/specificity.c
  - permissions from 775 to 664

✘ test/lexbor/css/selectors/selectors.c
  - permissions from 775 to 664

✘ test/lexbor/url/parser.c
  - permissions from 775 to 664

✘ test/lexbor/html/attributes.c
  - permissions from 775 to 664

✘ test/lexbor/html/tags.c
  - permissions from 775 to 664

✘ test/lexbor/html/tokenizer_helper.h
  - permissions from 775 to 664

✘ test/lexbor/html/parse.c
  - permissions from 775 to 664

✘ test/lexbor/html/tree_builder.c
  - permissions from 775 to 664

✘ test/lexbor/html/other.c
  - permissions from 775 to 664

✘ test/lexbor/html/element_by.c
  - permissions from 775 to 664

✘ test/lexbor/html/build-cpp.cpp
  - permissions from 775 to 664

✘ test/lexbor/html/tree/open_elements.c
  - permissions from 775 to 664

✘ test/lexbor/html/encoding.c
  - permissions from 775 to 664

✘ test/lexbor/html/tokenizer_tokens.c
  - permissions from 775 to 664

✘ test/lexbor/html/serialize.c
  - permissions from 775 to 664

✘ test/lexbor/html/clone.c
  - permissions from 775 to 664

✘ test/lexbor/unicode/normalization_forms.c
  - permissions from 775 to 664

✘ test/lexbor/unicode/idna_type.c
  - permissions from 775 to 664

✘ test/lexbor/unicode/normalization_forms_code_points.c
  - permissions from 775 to 664

✘ test/lexbor/unicode/idna_codepoints.c
  - permissions from 775 to 664

✘ test/lexbor/unicode/idna.c
  - permissions from 775 to 664

✘ test/lexbor/unicode/edges_normalization_forms.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/koi8_r.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/windows_1251.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/iso_8859_14.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/utf-8.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/windows_1258.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/iso_8859_4.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/iso_8859_8.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/macintosh.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/iso_8859_16.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/iso_8859_13.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/windows_1254.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/encoding.h
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/iso_2022_jp.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/x_mac_cyrillic.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/shift_jis.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/windows_1253.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/iso_8859_5.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/big5.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/iso_8859_15.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/windows_1250.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/iso_8859_10.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/windows_1256.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/iso_8859_3.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/iso_8859_6.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/iso_8859_2.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/windows_874.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/gb18030.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/ibm866.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/euc_kr.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/utf-16.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/windows_1257.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/koi8_u.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/windows_1255.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/euc_jp.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/windows_1252.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/single/iso_8859_7.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/buffer/utf-8.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/buffer/iso_2022_jp.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/buffer/shift_jis.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/buffer/big5.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/buffer/gb18030.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/buffer/euc_kr.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/buffer/utf-16.c
  - permissions from 775 to 664

✘ test/lexbor/encoding/buffer/euc_jp.c
  - permissions from 775 to 664

✘ test/lexbor/core/str.c
  - permissions from 775 to 664

✘ test/lexbor/core/bst_map.c
  - permissions from 775 to 664

✘ test/lexbor/core/bst.c
  - permissions from 775 to 664

✘ test/lexbor/core/dobject.c
  - permissions from 775 to 664

✘ test/lexbor/core/array.c
  - permissions from 775 to 664

✘ test/lexbor/core/in.c
  - permissions from 775 to 664

✘ test/lexbor/core/avl.c
  - permissions from 775 to 664

✘ test/lexbor/core/mraw.c
  - permissions from 775 to 664

✘ test/lexbor/core/array_obj.c
  - permissions from 775 to 664

✘ test/lexbor/core/hash.c
  - permissions from 775 to 664

✘ test/lexbor/core/mem.c
  - permissions from 775 to 664

✘ test/lexbor/selectors/selectors.c
  - permissions from 775 to 664

✘ test/lexbor/style/element_events.c
  - permissions from 775 to 664

✘ test/lexbor/style/not_html_namespace.c
  - permissions from 775 to 664

✘ test/lexbor/style/style_tag.c
  - permissions from 775 to 664

✘ test/files/lexbor/css/syntax/tokenizer/reverse-solidus.ton
  - permissions from 775 to 664

✘ test/files/lexbor/css/syntax/tokenizer/string.ton
  - permissions from 775 to 664

✘ test/files/lexbor/html/html5_test/README.md
  - permissions from 775 to 664

✘ test/files/lexbor/html/tokenizer/tag_name.ton
  - permissions from 775 to 664

✘ test/files/lexbor/html/tokenizer/doctype.ton
  - permissions from 775 to 664

✘ test/files/lexbor/html/tokenizer/comment.ton
  - permissions from 775 to 664

✘ test/files/lexbor/html/tokenizer/tag_attr.ton
  - permissions from 775 to 664

✘ test/files/lexbor/html/tokenizer/char_ref.ton
  - permissions from 775 to 664

✘ test/unit/kv_rules.c
  - permissions from 775 to 664

✘ test/unit/test.h
  - permissions from 775 to 664

✘ test/unit/kv_state.c
  - permissions from 775 to 664

✘ test/unit/kv.c
  - permissions from 775 to 664

✘ test/unit/kv.h
  - permissions from 775 to 664

✘ test/unit/test.c
  - permissions from 775 to 664

✘ README.md
  - permissions from 775 to 664

Hello @petk
You can send a PR or I can change the permissions myself.
Thanks for the report!

Great. PRs sent. Thanks!

@petk
Merged. Thanks!


[FR] Implement full support for updating literature notes with grouped annotations in bullet lists

Since update 1.0.2, Update Literature Note partially works for grouped list items using the templates I've shared before. But there are still issues:
Here are some scenarios:

No new annotations.

This now works as expected. Nothing is added (no duplicate annotations).

New annotation

The literature note is updated, but the new annotations are not placed under the existing heading where they belong. Duplicate headings are created.

A comment is added to an existing annotation:

The comment is not added.

An existing comment is changed.

The comment is not updated.

Note: I tested point 3. and 4. with the In-place Update of Existing Annotation toggled on.
Regarding point 2.:
I tried to make an zt-annots.eta template that could fix this issue, by keeping track of which headings have already been created, and only creating them if they don't exist. However, it doesn't work and I think it's because the createdColorLabels map doesn't persist.
Here is the template:
<%
// Define a map to keep track of which color labels have been created
const createdColorLabels = new Map();
// Loop over each annotation and group them by color
const colorGroups = it.group(annotation => annotation.colorName);

// Define the color label map
const colorLabel = {
  'blue': '⚡ Hypotheses',
  'green': '💡 Main ideas and conclusions',
  'orange': '⚙ Method',
  'yellow': '⭐ Important',
  'purple': '🧩 Definitions and concepts',
  'red': '⛔ Weaknesses and caveats',
  'gray': '📣 Survey instruments'
};

// Loop over each color group and output the annotations
for (const [color, annotations] of Object.entries(colorGroups)) {
  const colorHeading = colorLabel[color] ?? 'Group';

// Check if the heading for this color has already been created
if (!createdColorLabels.has(colorHeading)) {%>
\n
### <%= colorHeading %>
\n
<% createdColorLabels.set(colorHeading, true); %>
<% }

// Output the annotations for this color
for (const annotation of annotations) { %>
<%~ include("annotation", annotation) %>
<% } %>
<% } %>

I had some ideas for persistence, either by storing the names of existing headings for each it.key in a separate file (JSON), or by checking level three headings in the existing literature note. However, I didn't manage to implement these ideas in the template successfully. I have several such experimental templates which are probably misguided.

it's kind of tricky to update existing group in a generic way, since we can't tell which heading/list item is the container for the grouped items without explictly specifying it. Before I come up with a new API to handle this, you can use overwrite mode to update note properly.

@aidenlx have you considered the way that Zotero integration does it?
There is a special keyword called persist notes where the overwrite will ignore anything commented out by % tags. 'Persistent block'
Another feature is to add only annotations since the last update date. 'Update by recent'
https://github.com/mgmeyers/obsidian-zotero-integration/blob/main/docs/Templating.md
The intent is to safely organize thoughts inside the imported annotations incrementally and non destructively.
As far as features are concerned I am far more interested in the 'update by recent' than the 'persistent block'

the way that Zotero integration does it?

This could make the overwrite update mode less destructive, but it wouldn't enable all the update modes that Obsidian-Zotero offers or aims to offer for custom templates - especially not the in-place updating of annotations.
This is the most promising/innovative update mode, in my view.
If you do the basic persist block (following the Zotero Integration's docs' example) for all annotations, the subsequent updates will not get added to the same group heading as the existing annotations. The existing ones persist as is, and the new ones get appended at the end, creating duplicate headings in the case of annotations grouped by color.
Unless you are using some custom template that has different behavior?
There is this experimental template that puts every annotation in separate persist blocks: https://forum.obsidian.md/t/zotero-integration-import-templates/36310/107?u=feralflora
I am not sure of the merits of this approach, and it seems like it would be quite messy. And again, it does not allow in-place updating of existing annotations, as far as I can tell.

Is there any change regarding how well the plugin can cope with updating non-callout annotations and highlight? In the plugin settings it says:

Note: If you disable callout warpping in annotation template, you need to make sure the block-id is added properly in the template.

However, it's not documented how block-ids are properly added in order for the updating feature to work with callout wrapping disabled. Could you clarify that?


Pin version of html5lib because of breaking change in latest release

Bug on BS4
Current Wagtail version susceptible
Wagtail version upgrade still susceptible
Wagtail commit to solve issue that's not released yet

Additions

html5lib version after wagtail in requirements/base.txt

Testing

pip install -r requirements/local.txt
tox

Review

@richaagarwal
@rosskarchner
@willbarton

Todos

CHANGELOG

Checklist

[x] Changes are limited to a single goal (no scope creep)
[x] Code can be automatically merged (no conflicts)
[ ] Code follows the standards laid out in the front end playbook
[x] Passes all existing automated tests
[x] New functions include new tests
[x] New functions are documented (with a description, list of inputs, and expected output)
[x] Placeholder code is flagged
[x] Visually tested in supported browsers and devices
[ ] Project documentation has been updated (including the "Unreleased" section of the CHANGELOG)

👍

👍


anki-np: remove 32 bit and update to 2.1.37

Since Anki 2.1.36, 32 bits builds are not supported (see here). This PR removes the 32 bits architecture from the manifest so that it can continue to get updated.

Thanks!


First time mkdocs usage mkdocs.yml does not exist

Followed the instructions, running mkdocs serve from the docs directory, getting the error.
D:\Path\To\OrchardDocs-Trunk\docs>mkdocs serve
INFO     -  Building documentation...
Error: Config file 'mkdocs.yml' does not exist.

The instructions are silent on the subject.
Also, is mkdocs really necessary? i.e. as long as you can browse and have a markdown viewer perhaps a Visual Studio Code or what have you, the paths should just 'be there' and so on?
I'll do some more digging on the topic, but if there are any suggestions, much appreciated, thank you.

mkdocs.yml is in the parent folder, not in docs.

You are aware that this is the docs for Orchard 1, not Orchard Core, right?

https://github.com/OrchardCMS/OrchardCore/tree/main/src/docs
OrchardCore documentation is part of its main source code repository.

mkdocs.yml is in the parent folder, not in docs.

Possibly needs clarification:
Go to the docs folder and run ...

Rather, the repo directory, correct?


Assets CI

checks not successful because i cancelled the workflow, it's already tested to be working


Remove title and rename onFinished to onFinish

Note: Since this breaks the API we provide we should bump the major version after merging.
Also see https://github.com/britishcouncil/tiger-quiz/pull/3

Unrelated: If you're interested, I built a react/redux quiz that was inspired by many examples I found on GitHub; including yours. https://github.com/gabemartinez/trivia

Reviewing ...

@gabemartinez Great to hear you found this repo useful!

@robinedman Everything looks good to me. 👍


typo "lack fo"

[Enter feedback here]

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

ID: c2ab0c47-e61d-0419-1e75-29172fcbe097
Version Independent ID: 796337da-9f25-5d68-6c40-2f73263a5bfa
Content: Azure Files performance troubleshooting guide
Content Source: articles/storage/files/storage-troubleshooting-files-performance.md
Service: storage
Sub-service: files
GitHub Login: @gunjanj
Microsoft Alias: gunjanj

@javester Thanks for bringing this to our attention. We have made the change and it is already live.
https://github.com/MicrosoftDocs/azure-docs-pr/commit/597a5e7f7e9868116ec839ef07c676b33b5019b4


Pulsar stucked and all producer on topic disconnected

Describe the bug
Hi all, the detailed discussion can be seen here:
https://github.com/milvus-io/milvus/issues/15535#issuecomment-1042597113
From the user's log there is producerBlocked Quota exception and we've seen some Connection reset by peer exception as well.
Could this be related? How do we know which consumer is not consuming correctly and causing the producerBlocked Quota exception ?
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS]

Additional context
Add any other context about the problem here.

Looks like we can close the issue since https://github.com/milvus-io/milvus/issues/15535#issuecomment-1042597113 has provided the solution.

thanks for the help, we hit many backlog issues and we will try to sum up some rules to follow

Looks like we can close the issue since milvus-io/milvus#15535 (comment) has provided the solution.

In this issue you mentioned above, they solved the problem by clear the backlog，which I think didn't real solve the problem.
I have met with the same problem. Shut down all proudcers forcely and wait for a long time then restart can solve the problem. But I want to know why this happen? What I need to do to solve this problem completely~


Need better examples for using with authentication

Important gapi.auth2 notice: gapi.auth2 has been deprecated and replaced with Google Identity Services. Please see https://developers.google.com/identity/sign-in/web/deprecation-and-sunset for more information. If you have questions related to authentication/authorization please look at the associated documentation or post questions on Stack Overflow with the google-oauth tag.
(I don't know what the above means on the issue template. Should this library be used for calling google api's in a webapp)
Summary
I am working on a webapp which I want to use google login to call google API's while the user is present.
I have followed instructions here - https://developers.google.com/identity/authentication
I have generated a button and it is working and I can login and I get a response simular to the following in a javascript callback:
{clientId: 'xx',
client_id: 'xx',
credential: 'yyy',
select_by: 'user'}

The credential is a valid JWT token and I have verified it at jwt.io.
The problem is I now need to know how to use this credential to call an API.
https://developers.google.com/identity/authorization says I should use a library to quickly and securly call google API's.
The links bring me to this repo.
I can see no reference to this credential anywhere in this repo.
This repo talks about an access token which is different to the credential JWT token. I can't find how I should be exchanging one to the other.
Can a sample be added to this library which shows how it should be used?
Browser(s)/Version(s)
All of them
Expected Behavior
I should come to this repo and it should have at least one example of how to use the credential to call an API.
Actual Behavior
I get lots of examples using an out dated method which won't work because new google client id's have this method disabled.
Steps to Reproduce
Try and develop a webapp that uses google API's.

For authorization, you need access token. You can use Google Identity Services JavaScript for Web SDK to obtain access token. See https://developers.google.com/identity/oauth2/web/guides/overview.
There are more sample code under this page - https://developers.google.com/identity/oauth2/web/guides/migration-to-gis.


Change react scaffolding unmounting system

Changes

Added unmount by pathname scaffolding API
Added active app flags
ScalprumRoute no longer handles unmounting
Applications are unmounted from the route when ScalprumLink is clicked and location changes
Change react dependencies to v^17

Tests

added integration test to check application nested routing

Codecov Report

Merging #19 into main will increase coverage by 0.95%.
The diff coverage is 48.57%.

@@            Coverage Diff             @@
##             main      #19      +/-   ##
==========================================
+ Coverage   52.30%   53.26%   +0.95%
==========================================
  Files           4        5       +1
  Lines          65       92      +27
  Branches        9       13       +4
==========================================
+ Hits           34       49      +15
- Misses         31       43      +12

Impacted Files
Coverage Δ

packages/react-core/src/scalprum-link.tsx
33.33% <33.33%> (ø)

packages/react-core/src/scalprum-route.tsx
30.76% <50.00%> (ø)

packages/core/src/index.ts
72.72% <52.63%> (-27.28%)
:arrow_down:

packages/react-core/src/index.ts
84.21% <100.00%> (+0.87%)
:arrow_up:

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 14b31a9...e2deca3. Read the comment docs.


fix-#77:Refactor Form Validation with react-hook-form & zod

Summary
This PR address
1.Validation schema modification
2.Form validation logic enhancement
3. Image selection Improvements
Description
Added react hook form and zod which helps in validating the input fields and to show the error as user fills the required input field rather than showing error after complete submission.
The validation schema has been updated to include checks for the author's name length and the maximum number of selected categories, image selection, blog title length and description of blog to be posted.
Users now have the option to select an image for their blog post either by providing a URL or uploading a file from their device. Additionally, feedback is provided to the user upon image selection.
Images
Helping user to fill the input as per requirement beforehand:

and once corrected, error gets removed-

Issue(s) Addressed
Closes #77
Prerequisites

[x] Have you followed all the CONTRIBUTING GUIDELINES?

Build is failing because of above
Kindly make sure you follow everything from the previous PR thread, let's finish this asap. Its too much time passed...
https://github.com/krishnaacharyaa/wanderlust/pull/254
Mainly
The error messages and validations
Video showing the implementation
All the review comments of #254

Kindly rebase for the PR title checker to pass

@ShristiSharan you can delete the package-lock.json and then do npm install that should ideally solve the build failure

okh sir, will do this asap

@ShristiSharan you can delete the package-lock.json and then do npm install that should ideally solve the build failure

Still not working!

@ShristiSharan please arrange a call, may be tomorrow night. It is most needed, and it is quite delayed now

@ShristiSharan please arrange a call, may be tomorrow night. It is most needed, and it is quite delayed now

Ohk Sir!


meta/cos-modules pulls in elemental-cli

Is your feature request related to a problem? Please describe.
meta/cos-modules is supposed to bring in only the cos static bits which are not compiled binaries. This is used for example to bring the cos modules within other environments where the cli, or other golang components are built separately
Describe the solution you'd like
currently the installer package depends on the cli, which in turns makes meta/cos-modules to ship the elemental-cli binary. As before we didn't had a cli binary in golang, this was an oversight and a regression.
Besides the installer package should be actually deprecated, in order to do this gradually I would start off by splitting it in a separate package: one for the bash wrappers to provide backward compatibility, and for example a separate one to provide the system-upgrade-controller integration
Describe alternatives you've considered

Additional context

installer is mostly deprecated already, only the rebrand stuff is missing (and the suc-upgrade) IIRC

Seems also cos-deploy is still using cos.sh


Setting name for HttpSampler is not working

Setting name for HttpSampler("name","url") is not being picked up. All the requests are being recorded under label "Https request". In azure load test , the only sampler name displayed is "Http Request"

Issue is fixed.


Add comments, fix clippy lints, other minor fixups

This commit does a few different things:

Fixes clippy lints, mostly by actually fixing them, although a couple are "fixed" with #[allow(clippy::...)] annotations so that we don't see the warnings anymore. Those are described in more detail below.
Adds or clarifies existing comments both to better document the parts of the API, and to explain the functioning of the code better in places.
Renames some variables for clarity. In particular, any digest local variable is renamed digester, and Source::get_digest is now Source::get_digester. This is intended to make clearer that the function returns the type which performs the digest operations, and does not return the digest itself.
Removes a couple of unnecessary allocations. Namely, 1) the logic for producing a bunch of futures for GitOid generation and then using join_all on them doesn't actually require allocating an intermediate Vec for the futures, join_all just takes an iterator; 2) GitBom::add doesn't need to make a Vec of one element to pass to add_many, it can use a regular array. This does raise a Minimum-Supported Rust Version question, as arrays implementing IntoIter was introduced a few versions ago. I can revert this change if we aren't comfortable with the compatibility issue.

After this I'd like to work on splitting out the GitOid bits from the GitBom bits, and matching the API of the Go implementation, as described in #18.

This is one of the best "First-time Contributor" patches I've seen for a project!
Thank you, merging now!


First argument of MongoDB\Laravel\Query\Builder::where must be a field path as "string". Got "null"

Laravel-mongodb Version: 4.1.1
PHP Version: 8.3.2
Database Driver & Version: 1.17.2

Description: I am currently upgrading to Laravel 10 and v4 of this library and when calling save on an embeded document I get the error: First argument of MongoDB\Laravel\Query\Builder::where must be a field path as "string". Got "null"
Steps to reproduce
I have the following models (simplified for clarity)
class Account extends Model {
public function stripe(): EmbedsOne
    {
        return $this->embedsOne(Stripe::class);
    }
}

class Stripe extends Model {}

Then when I try to update the stripe subdocument like so:
$account = Account::find(...);
$stripe = $account->stripe;
$stripe->subscription = ['some data'];
$stripe->save();

Expected behaviour
Tell us what should happen jenssegers/mongodb 3.9 it would save the data just fine.
Actual behaviour
1) Tests\Feature\Actions\Stripe\CancelPendingChangeTest::it_will_cancel_a_pending_modification
InvalidArgumentException: First argument of MongoDB\Laravel\Query\Builder::where must be a field path as "string". Got "null"

/Users/clarkeash/code/sites/billing/vendor/mongodb/laravel-mongodb/src/Query/Builder.php:1012
/Users/clarkeash/code/sites/billing/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Builder.php:302
/Users/clarkeash/code/sites/billing/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Model.php:1254
/Users/clarkeash/code/sites/billing/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Model.php:1213
/Users/clarkeash/code/sites/billing/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Model.php:1130
/Users/clarkeash/code/sites/billing/vendor/mongodb/laravel-mongodb/src/Eloquent/Model.php:737
/Users/clarkeash/code/sites/billing/app/Actions/Stripe/StoreSubscriptionInformation.php:82
/Users/clarkeash/code/sites/billing/vendor/lorisleiva/laravel-actions/src/Concerns/AsObject.php:24
/Users/clarkeash/code/sites/billing/tests/Feature/Actions/Stripe/CancelPendingChangeTest.php:41

I am unsure if this is a bug or if I have missed something, can you point me in the right direction? Thanks

Hi, we have a test for the embedOne feature, but it seems that your use-case is not covered.
Tracking this issue in Jira to investigate. PHPORM-144

This exception was introduced in #2642 063d73f
I've been unable to reproduce the bug by creating a model similar to yours.

Hi @clarkeash, were you able to find a reproducer?

Okay fair enough, I have not had the time to reproduce it as I have a workaround.


[1.x]  Create Service Container

Description
In some cases we need to inject some classes or services like Repositories
Acceptance Criteria

[ ] Create container.
[ ] Inject services with their parameters using ReflectionClass.

Example
$container = Container::instance(); // singleton instance
$service = $container->get('SomeService');

We already have a container, the Symfony container.
As per our discussion, we need to use repositories as services to be able to inject them into our actions.


Allow dnsmasq caching config to be modified

Which issue this PR addresses:

Fixes https://issues.redhat.com/browse/ARO-2427. Introduces a new field to ClusterSpec dnsmasq that allows configuring of dnsmasq cache-size, min-cache-ttl, max-cache-ttl and no-negcache.
Depends on

release-4.10-azure: https://github.com/jewzaam/installer-aro/pull/20
release-4.11-azure: https://github.com/jewzaam/installer-aro/pull/19

What this PR does / why we need it:
If a query is forwarded by dnsmasq is lost, then dnsmasq will hold on to that query for 40 seconds waiting for a response. If additional queries for that same name (and type) come in during that time, they will block on waiting for the first forwarded query. To reduce the number of upstream requests needed, this PR allows enabling and tuning caching.
Test plan for issue:
Deploy to a test cluster. Let it run for a while (1 day or more) and check CoreDNS logs for "i/o timeout". PENDING
Install the new aro operator and make sure it doesn't update any machineconfig :heavy_check_mark: PASS
Test that each setting updates the machineconfig appropriately. Also verify the resulting dnsmasq.conf config file is formatted coorectly and dnsmasq loads.

cacheSize  :heavy_check_mark: PASS
maxCacheTTL  :heavy_check_mark: PASS
minCacheTTL :heavy_check_mark: PASS
noNegCache  :heavy_check_mark: PASS

Is there any documentation that needs to be updated for this PR?
Internal documentation needs to be created detailing how to configure dnsmasq caching, when to enable it, and how to tune it for workload.
Once we have this deployed in the field solving real customer issues, we will consider enabling cache by default. Data will need to be collected to determine how big a cache to configure; the dnsmasq upstream default is 150 entries.

Were the changes in the vendor folder made upstream and are being incorporated here or are we just changing the vendor files directly?

@dem4gus I'm changing the vendor files directly only to make it easier to test and review. I'll split out those changes to aro-installer once I'm sure this approach will work and I'm ready to take this out of draft.

/azp run e2e

/azp run e2e

I'd be curious to know if @bennerv sees any issues with us adding caching to dns as it relates to installer changes? I know that in a recent openshift/installer sync, we had mentioned that DNSMasq is a non-caching DNS server (ref: https://docs.google.com/presentation/d/1axmIrS3dyzAyGlLcJOly5vPFv1uymvu-jOy2uATYi_E/edit#slide=id.g136f68161c2_0_118), would this implementation change our ability to use upstream in the future?

Didn't get a chance to address this yet, but it's been in the back of my mind.
Here's my issue with the caching; CoreDNS already leverages caching.  So by adding caching at the top-level (dnsmasq), we're introducing a chain of caches which can result in unexpected behavior from a DNS side.  If a DNS record is updated, the TTL on the DNS record isn't honored from Corefile, and then there's also caching at dnsmasq level.
The reason dnsmasq was never meant to cache things is that we wanted the normal behavior to happen with the addition of dnsmasq.  Unfortunately it has had some unexpected consequences.  I would rather use the fast retries option if possible, but it seems that's not the case quite yet, and won't be unless we ask the RHEL team to backport.  I don't see this as an option short-term.
I'm not sure if it's possible to force dnsmasq to use TCP to make it more reliable when querying upstream DNS servers.  That might be one possibility, otherwise we're stuck with this without using a different resolver or waiting for fast retries.
$ oc -n openshift-dns get cm dns-default  -o yaml
apiVersion: v1
data:
  Corefile: |
    .:5353 {
        bufsize 512
        cache 900 {
            denial 9984 30
        }


ObjectType, Input, Enum, and Interface Definitions should not be allowed with zero fields.

Current
type Query {}
type Foo {}
input Bar {}
interface Qux {}
enum Quux {}

fails the following test
func TestMustHaveOneField(t *testing.T) {
	_, err := graphql.ParseSchema("type Query {} input Bar {} interface Qux {} enum Quux {}", nil)
	if err == nil {
		t.Fatal("types, inputs, interfaces and enums must have at least one field")
	}
}

Expected
Types, inputs, interfaces, and enums should be validated to ensure that there is at least one field.
Relevant specification links
ObjectTypeDefinition validation: https://spec.graphql.org/draft/#sel-HAHZhCFBABABuBq9O
InterfaceTypeDefinition validation: https://spec.graphql.org/draft/#sel-HAHbnBFBABABxB4a
EnumTypeDefinition validation: https://spec.graphql.org/draft/#sel-HAHfVFBABAB4B_6J
InputObjectTypeDefinition validation: https://spec.graphql.org/draft/#sel-HAHhBXDBABAB6BpkU
Environment

tested against the master branch

I'd be more than happy to contribute a fix.

There is a PR open for this issue: https://github.com/graph-gophers/graphql-go/pull/127, but it hasn't been touched in 2 years.

@ssko1 feel free to take it and resolve the conflicts


DSA:<IP_ADDRESS> Strings: Implementation of Strings in C & C++ fixes#3071-Docume…

…ntation

Description 📜
Implementation of Strings in C & C++.
Fixes # 3071

Type of change 📝

[x] Documentation (Content Creation in the form of codes or tutorials)

Domain of Contribution 📊

[x] C/CPP

Checklist ✅

[x] I follow Contributing Guidelines & Code of conduct of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I'm GWOC'21 contributor

@Suvraneel remove this c/cpp label from this issue ( don't consider this message @1PRatgit ).


User app installation notification

When installing User app via Teams setup policy, users see a notification "Your IT admin has added a new app". Is there a way to add it silently, without any notification?

Hi @Mykhailo-D ,
This is not in a scope of Company Communicator application. This is a behavior of Admin Teams. We won't be able to provide any inputs on this.


Gauri/static initialization problem r08 cherry-pick from #1691

TESTNOW

just cherry-picking from r0.8 to master


fix: skip generating error events for unauthorized or forbidden errors

part of https://github.com/bucketeer-io/bucketeer/issues/1284
also fix #91

@cre8ivejp please help me to take a look


Test fixes for Darwin

lastPathComponent is a NSString method so bridge appropiately.

JSONEncoder.OutputFormatting.sortedKeys requires macOS 10.13, add an
#available around it.

@swift-ci please test and merge


Will this project support lora?

Thanks for giving me an easy way finetuning model on TPU. I tried finetune a full model using this project on kaggle's tpu and it works.
I'm wondering whether there is a schedule for supporting finetune a lora or qlora model? it's a more practical way for those only have access to limited computing resources like me...

yes in the upcoming future and after finishing DPO, SFT Trainers the Lora process will start in FJFormer (EasyDel Computation Backend) and ill Update BITs too

Awesome! I think lots of people are looking forward to it. Thank you!