text:
Add specific route to create did key

In recent discussions, we approached the topic of having separate routes for registering respective did methods did in the wallet.
I would like to propose this first route using the current did key registration method, in order to align on the model to use. From then on, we can have a look for other did methods such as web, tdw, peer, in subsequent PRs
My proposal is to include did method specific operators to conduct operations related to specific did methods, such as registering, updating, removing, etc...
@aritroCoder @dbluhm @Jsyro @jamshale let's discuss this proposal

@dbluhm I removed, the cli argument, instead defining a default value for the web request model. There is already a did_key file at the root of the did folder and its a resolver class, I don't want to touch it for now. Instead I created a key directory and labeled the class DidKeyManager, please share thoughts on that.
Let me know if I didn't address something in your comment.

Why return a DID Document rather than the DID? Also, why not combine the functions of this DID Key Manager with the existing DID Key class?

The existing DIDKey class is expecting key_bytes and key_type being passed as a requirement to initialize the class. It was designed to resolve an existing did. If I want to create my did, these values don't exist. I would be more inclined towards moving resolving feature to this new class and make these elements only applicable to that function. The reason I don't want to change this base class is because I do not know where else it's used in aca-py and don't want to introduce too much scope creep in this PR.
For returning the did doc...no real good answer here besides this will ensure the registered did is compliant. You can get the did value by getting the didDoc.id. Might be redundant with did key but I was thinking this could be a good pattern to have for all did registration as it ensures the did is conformant. The goal of a did is ultimately to resolve to a did doc.
This being said we can also return just the did.

The existing DIDKey class is expecting key_bytes and key_type being passed as a requirement to initialize the class. It was designed to resolve an existing did. If I want to create my did, these values don't exist. I would be more inclined towards moving resolving feature to this new class and make these elements only applicable to that function. The reason I don't want to change this base class is because I do not know where else it's used in aca-py and don't want to introduce too much scope creep in this PR.

:+1:

For returning the did doc...no real good answer here besides this will ensure the registered did is compliant. You can get the did value by getting the didDoc.id. Might be redundant with did key but I was thinking this could be a good pattern to have for all did registration as it ensures the did is conformant. The goal of a did is ultimately to resolve to a did doc.
This being said we can also return just the did.

Generally speaking, working with DID Docs is complicated. When resolving, we don't have any choice but to work with the DID Doc representation of the keys and services of the resolved DID. Fortunately, though, we don't have to make this the controller's problem; ACA-Py handles extracting the necessary information and using it to accomplish whatever operation was requested.
For creation of DIDs, we should continue to handle the details for the controller, potentially with the option for the controller to directly be involved in the DID Doc if absolutely necessary. But I don't think it's necessary in most cases. What we care about when creating a DID is making sure it is capable of doing the things we want it to (e.g. DIDComm v1, DIDComm v2, signing VCs with a particular crypto suite, etc.) I think returning DID Documents by default from the DID Creation endpoint is leading in the direction of making DID Document semantics and maintenance the controller's problem. I think this should be avoided. The controller can always call the resolve endpoint if they really want to get the full DID Document.
This is why I proposed in the did:tdw implementation doc that we have "feature flags" for DID Creation. These flags would be used to indicate what features the DID should support (again e.g. DIDComm v1, DIDComm v2, signing VCs with a particular crypto suite, etc.).
These feature flags would of course not really apply to a did:key or did:jwk, though.

@dbluhm This is ready for a final review, I've merged the two classes together, added some unit tests. I return the did, verificationMethod and multikey instead of a did document.
I also had a first attempt at binding a verificationMethod with a did. I think this is a perfect use case for did key. I notice the binding was actually coded for the key creation, not local did creation so I had to make a small modification to the in_memory wallet.

I think the did directory should get restructured, because we are expecting more did methods to be added here. did_key and it's routes, objects, manager should get moved to a subdirectory. did --> key. Maybe the file could be renamed to key.py.
Also, I think the manger could possibly become an abstract class as well but that could be tackled when additional methods get added.

@jamshale I had it in a sub-directory then moved it to the already existing did_key class, since that class was already used by other components in the code base and we wanted to avoid duplicates. I'm happy to move it back but let's make sure we are on the same page about the model we want here.
what I had was more of a /did/key/manager.py, which I also prefer. The issue is that the current directory is only used as a did_key resolver.
I'm not sure if an abstract class is a great idea since we will be looking at maybe 2-3 did methods at top, (key, indy, web/tdw), and they are all fairly different.
I'm not seeing any SonarCloud issues? all checks are passed for me.

Can we have this conversation at the ACA-Pug meeting tomorrow?  I’ll put it on the agenda. Please come ready to discuss.  I don’t know enough of the technical details — I just know that I want us to be able to easily support registering other DID Methods — key, web, tdw, cheqd, hedera, etc.

Ok. The only problem I have is we have did_key.py and manager.py in the root did directory. Now if we want to add did_tdw it will just be another file and the routes/manager will keep getting bigger. Thought it would be nice to have them seperated, but I didn't realize there was extra complexity.
FYI. For sonarcloud sometimes it fails on issues and sometimes it doesn't. I'm not sure why.

@swcurran sounds good.
@jamshale I like this idea, as long as the abstract class is kept as minimal as possible. I fixed the issue with SonarCloud thanks for pointing it out. I see 3 current 'families' of dids. Self resolvable dids (peer, key, jwk), resolver dependent dids (sov, indy) and 'hosted' dids (web, tdw). Some reasons why this can create complexities is the relationship between the did and a keypair in aca-py. With self-resolvable dids, there is (most of the time) a one to one mapping between the did and a key pair (I think did peer can have multiple, not too sure).
DIDs are used by aca-py as an issuer when signing a document, where it needs to find the associated signing key (in this scenario, it's fine to use a did in situations where there's a 1 to 1 mapping, but for others, you would want to use the verificationMethod or kid to find the signing key, this is where the key binding comes at play). As a verifier, aca-py also needs to resolve the did document from the did and fetch the corresponding verificationMethod. This is easy for self resolvable dids and hosted dids, but for resolver dependent dids can create some complications.

closing this PR as the features have been implemented in #3246

authors: PatStLouis dbluhm jamshale swcurran

repo: hyperledger/aries-cloudagent-python


text:
feat: agent mediation role

Add mediationRole property to AgentConfig to ensure MediatorModule is initialized correctly. This prevents concurrency issues when multiple attempts to create a mediatorRoutingRecord fail.
Signed-off-by: Niall Shaw niall.shaw@absa.africa

Aims to fix #899

Technically an agent can be both a mediator and a recipient, so I'm not to keen on adding the role property to the config. I see two options, but there's probably other good options:

Always initialize it. It adds some overhead, but it's not that much
Add an option e.g. initializeMediatorKeysOnStartup that will init the mediator keys.

In addition, I'm not sure if it should be impossible to use mediation without the mediation role . E.g. with the ledger we have connectToLedgersOnStartup. If you have it enabled it will connect on startup, but otherwise when first requested. Is that something we could also do here?
Another issue is that this won't work for high availability deployments (multiple instances connecting to the same database). There's more places where this will lead to issues, so we can probably ignore this for now.

Technically an agent can be both a mediator and a recipient

Then it might be an array of roles. I usually try to avoid these flag config attributes, but if the array is a problem I'm also ok with something like initializeMediatorRoutingOnStartup. The word Keys seem to be too low-level detail.

Another issue is that this won't work for high availability deployments (multiple instances connecting to the same database). There's more places where this will lead to issues, so we can probably ignore this for now.

Yes, without this change, it doesn't work even with a few edge agents trying to connect at the same time, so I would rather do this now and fix "high availability deployments" later.

Is there any

Technically an agent can be both a mediator and a recipient, so I'm not to keen on adding the role property to the config. I see two options, but there's probably other good options:

Always initialize it. It adds some overhead, but it's not that much
Add an option e.g. initializeMediatorKeysOnStartup that will init the mediator keys.

In addition, I'm not sure if it should be impossible to use mediation without the mediation role . E.g. with the ledger we have connectToLedgersOnStartup. If you have it enabled it will connect on startup, but otherwise when first requested. Is that something we could also do here?
Another issue is that this won't work for high availability deployments (multiple instances connecting to the same database). There's more places where this will lead to issues, so we can probably ignore this for now.

Probably I'm missing something, but I don't see a major problem on always initializing mediator module, as it will actually initialize the routing key only once and then just query it and store it in the internal variable.
In such case, no new config parameters would be needed. What do you think?

Agree with @genaris here. I think avoiding the config option is worth the little bit of extra overhead.

Moved to #985

source: gharchive/pull-request

authors: TimoGlastra genaris jakubkoci niallshaw-absa

repo: hyperledger/aries-framework-javascript

license_type: permissive

license_source: github-api


text:
fix: credential not found on navigation from chat screen

Summary of Changes

Fixed Credential Not Found error on navigating to credential details from the chat screen (from You received a credential message).

Related Issues
N/A
Pull Request Checklist
Tick all boxes below to demonstrate that you have completed the respective task. If the item does not apply to your this PR check it anyway to make it apparent that there's nothing to do.

[x] All commits contain a DCO Signed-off-by line (we use the DCO GitHub app to enforce this);
[x] Updated LICENSE-3RD-PARTY.md for any added dependencies or vendored components;
[x] Updated documentation as needed for changed code and new or modified features;
[x] Added sufficient tests so that overall code coverage is not reduced.

If you have any questions to any of the points above, just submit and ask! This checklist is here to help you, not to deter you from contributing!
Pro Tip 🤓

Read our contribution guide at least once; it will save you a few review cycles!
Your PR will likely not be reviewed until all the above boxes are checked and all automated tests have passed.

PR template adapted from the Python attrs project.

@AlexanderShenshin PR looks good. The DCO is not quite right though. I think its your name does not match. Its expecting "Alexander Shenshin" but gets "alexander.shenshin".
Expected "Signed-off-by: Alexander Shenshin [alexander.shenshin@dsr-corporation.com]", but got "alexander.shenshin [alexander.shenshin@dsr-corporation.com]".

You're right, thanks. Fixed the DCO.

authors: AlexanderShenshin jleach


text:
Besu crashed after request

Hi. I'm trying to execute a request curl -X POST --data '{"jsonrpc":"2.0","method":"debug_traceBlockByHash","params":["0x0111aa7b7eb394144fdb3dca7b1f72dab5c1e38e01a0b842d0814f4480eb3f75"], "id":1}' http://127.0.0.1:8545
, but get the besu error:
ethereum_1  | 2022-09-08 14:36:30.879+00:00 | Timer-0 | INFO  | DNSTimerTask | Refreshing DNS records with enrtree://AKA3AM6LPBYEUDMVNU3BSVQJ5AD45Y7YPOHJLEF6W26QOE4VTUDPE@all.mainnet.ethdisco.net
ethereum_1  | 2022-09-08 14:36:37.685+00:00 | nioEventLoopGroup-3-10 | INFO  | BlockPropagationManager | Saving announced block 15497150 (0x1eb8b37849007bf8285bc17cdd8aff20097ad02bd3b7421dc2803e9055312935) for future import
ethereum_1  | 2022-09-08 14:36:37.838+00:00 | nioEventLoopGroup-3-10 | INFO  | BlockPropagationManager | Saving announced block 15497151 (0x33cca876da52c5291c95b2d7eb1d7df0641107492c811590ca7d1d6ac9104013) for future import
ethereum_1  | 2022-09-08 14:36:40.944+00:00 | nioEventLoopGroup-3-7 | INFO  | BlockPropagationManager | Saving announced block 15497152 (0x92ab5181ce605580a030593eb53ac6d392c42c5dc6de4848a74105c2a4cf8b9d) for future import
ethereum_1  | 2022-09-08 14:36:40.948+00:00 | nioEventLoopGroup-3-9 | INFO  | BlockPropagationManager | Saving announced block 15497153 (0x5d686b5aeb794fcf15e7f7886acd91dfc12547767c5cb80c06c2f606b63e26cf) for future import
ethereum_1  | 2022-09-08 14:36:44.173+00:00 | nioEventLoopGroup-3-9 | INFO  | SyncTargetManager | Found common ancestor with peer Peer 0xadc5d4e480de09ffa7... PeerReputation 99, validated? true, disconnected? false at block 15497148
ethereum_1  | 2022-09-08 14:36:54.076+00:00 | vertx-blocked-thread-checker | WARN  | BlockedThreadChecker | Thread Thread[vert.x-worker-thread-18,5,main] has been blocked for 61233 ms, time limit is 60000 ms
ethereum_1  | io.vertx.core.VertxException: Thread blocked
ethereum_1  | 	at app//org.apache.tuweni.bytes.Bytes.appendHexTo(Bytes.java:1410)
ethereum_1  | 	at app//org.apache.tuweni.bytes.Bytes.toUnprefixedHexString(Bytes.java:1553)
ethereum_1  | 	at app//org.hyperledger.besu.ethereum.api.jsonrpc.internal.results.StructLog$$Lambda$1667/0x00000008404c6c40.apply(Unknown Source)
ethereum_1  | 	at java.base@11.0.15/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
ethereum_1  | 	at java.base@11.0.15/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
ethereum_1  | 	at java.base@11.0.15/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
ethereum_1  | 	at java.base@11.0.15/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
ethereum_1  | 	at java.base@11.0.15/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:550)
ethereum_1  | 	at java.base@11.0.15/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
ethereum_1  | 	at java.base@11.0.15/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:517)
ethereum_1  | 	at app//org.hyperledger.besu.ethereum.api.jsonrpc.internal.results.StructLog.lambda$new$1(StructLog.java:49)
ethereum_1  | 	at app//org.hyperledger.besu.ethereum.api.jsonrpc.internal.results.StructLog$$Lambda$1666/0x00000008404c6840.apply(Unknown Source)
ethereum_1  | 	at java.base@11.0.15/java.util.Optional.map(Optional.java:265)
ethereum_1  | 	at app//org.hyperledger.besu.ethereum.api.jsonrpc.internal.results.StructLog.<init>(StructLog.java:49)
ethereum_1  | 	at app//org.hyperledger.besu.ethereum.api.jsonrpc.internal.results.DebugTraceTransactionResult.createStructLog(DebugTraceTransactionResult.java:53)
ethereum_1  | 	at app//org.hyperledger.besu.ethereum.api.jsonrpc.internal.results.DebugTraceTransactionResult$$Lambda$1664/0x00000008404c6040.apply(Unknown Source)
ethereum_1  | 	at java.base@11.0.15/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
ethereum_1  | 	at java.base@11.0.15/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
ethereum_1  | 	at java.base@11.0.15/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
ethereum_1  | 	at java.base@11.0.15/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
ethereum_1  | 	at java.base@11.0.15/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
ethereum_1  | 	at java.base@11.0.15/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
ethereum_1  | 	at java.base@11.0.15/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
ethereum_1  | 	at app//org.hyperledger.besu.ethereum.api.jsonrpc.internal.results.DebugTraceTransactionResult.<init>(DebugTraceTransactionResult.java:41)
ethereum_1  | 	at app//org.hyperledger.besu.ethereum.api.jsonrpc.internal.results.DebugTraceTransactionResult$$Lambda$1663/0x00000008404c5c40.apply(Unknown Source)
ethereum_1  | 	at java.base@11.0.15/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
ethereum_1  | 	at java.base@11.0.15/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
ethereum_1  | 	at java.base@11.0.15/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
ethereum_1  | 	at java.base@11.0.15/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
ethereum_1  | 	at java.base@11.0.15/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
ethereum_1  | 	at java.base@11.0.15/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
ethereum_1  | 	at java.base@11.0.15/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
ethereum_1  | 	at app//org.hyperledger.besu.ethereum.api.jsonrpc.internal.results.DebugTraceTransactionResult.of(DebugTraceTransactionResult.java:47)
ethereum_1  | 	at app//org.hyperledger.besu.ethereum.api.jsonrpc.internal.methods.DebugTraceBlockByHash$$Lambda$1662/0x00000008404c5840.apply(Unknown Source)
ethereum_1  | 	at java.base@11.0.15/java.util.Optional.map(Optional.java:265)
ethereum_1  | 	at app//org.hyperledger.besu.ethereum.api.jsonrpc.internal.methods.DebugTraceBlockByHash.response(DebugTraceBlockByHash.java:59)
ethereum_1  | 	at app//org.hyperledger.besu.ethereum.api.jsonrpc.execution.BaseJsonRpcProcessor.process(BaseJsonRpcProcessor.java:42)
ethereum_1  | 	at app//org.hyperledger.besu.ethereum.api.jsonrpc.execution.TracedJsonRpcProcessor.process(TracedJsonRpcProcessor.java:41)
ethereum_1  | 	at app//org.hyperledger.besu.ethereum.api.jsonrpc.execution.TimedJsonRpcProcessor.process(TimedJsonRpcProcessor.java:45)
ethereum_1  | 	at app//org.hyperledger.besu.ethereum.api.jsonrpc.execution.JsonRpcExecutor.execute(JsonRpcExecutor.java:91)
ethereum_1  | 	at app//org.hyperledger.besu.ethereum.api.handlers.JsonRpcExecutorHandler.lambda$handler$6(JsonRpcExecutorHandler.java:76)
ethereum_1  | 	at app//org.hyperledger.besu.ethereum.api.handlers.JsonRpcExecutorHandler$$Lambda$672/0x00000008404a3440.handle(Unknown Source)
ethereum_1  | 	at app//io.vertx.ext.web.impl.BlockingHandlerDecorator.lambda$handle$0(BlockingHandlerDecorator.java:48)
ethereum_1  | 	at app//io.vertx.ext.web.impl.BlockingHandlerDecorator$$Lambda$1265/0x00000008406e3040.handle(Unknown Source)
ethereum_1  | 	at app//io.vertx.core.impl.ContextImpl.lambda$null$0(ContextImpl.java:159)
ethereum_1  | 	at app//io.vertx.core.impl.ContextImpl$$Lambda$812/0x000000084059f040.handle(Unknown Source)
ethereum_1  | 	at app//io.vertx.core.impl.AbstractContext.dispatch(AbstractContext.java:100)
ethereum_1  | 	at app//io.vertx.core.impl.ContextImpl.lambda$executeBlocking$1(ContextImpl.java:157)
ethereum_1  | 	at app//io.vertx.core.impl.ContextImpl$$Lambda$811/0x000000084059e840.run(Unknown Source)
ethereum_1  | 	at app//io.vertx.core.impl.TaskQueue.run(TaskQueue.java:76)
ethereum_1  | 	at app//io.vertx.core.impl.TaskQueue$$Lambda$606/0x000000084046d040.run(Unknown Source)
ethereum_1  | 	at java.base@11.0.15/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
ethereum_1  | 	at java.base@11.0.15/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
ethereum_1  | 	at app//io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
ethereum_1  | 	at java.base@11.0.15/java.lang.Thread.run(Thread.java:829)

besu version is 22.7.1
config:
besu --network=mainnet --rpc-http-enabled --sync-mode=fast --host-allowlist=* --nat-method=upnp --Xdns-enabled=true --rpc-http-api=ETH,NET,CLIQUE,DEBUG,MINER,NET,PERM,ADMIN,EEA,TXPOOL,PRIV,WEB3

hardware:
4cpu/16ram, ssd
Could anyone help?

Thanks @githubswisschain we are looking into this

@githubswisschain We've investigated, but haven't been able to replicate the issue you've logged or identify the cause.
Could you advise whether you've experienced this issue again?

@mark-terry Now it works. I've added more RAM

Thanks for the update! 👍

Could you advise what RAM / JVM configuration resolved the issue?

source: gharchive/issue

authors: githubswisschain macfarla mark-terry

repo: hyperledger/besu


text:
Besu has poor performance for tracing blocks / transactions

Description
As an user I want to be able to trace blocks and transactions reliably and quickly without OOM errors or hitting timeouts on the RPC layer so that I can get the info I need for my use-case.
Related to #3786
Acceptance Criteria

Queries return quickly
Queries do not OOM
Queries do not timeout

Actual behavior: [What actually happens]

Not sure why we are slow
Many times Besu would crash when tracing a full block
OOM errors eg #4050
Short timeout can cause issues - some blocks take 10+ min to trace

Potential Approach

Solution?: Instead of replaying each time the traces for each user request, why not saving this trace result (could generate at the time of block creation?) in a separate database of a separate module instead of saving the block and the worldstate for each block
Solution?: Separate into a different microservice
Separate the query part of Besu into a completely separate process. Queries that are asking Besu questions related to chain do not need to slow down the main flow.

NEED SCOPING / TIMING ESTIMATE

Bug mentioned in #4050, #3786


text:
feat(fabric) Update manage-user-certificate.yaml playbook

Description
As a developer I want to update the manage-user-certificate.yaml playbook, since it uses roles that have been decoupled from ansible and are no longer available
Acceptance Criteria
Deploy the playbook with the corresponding charts that replaced roles.

I'll work on this

authors: alvaropicazo mgCepeda

repo: hyperledger/bevel


text:
[FABCN-413] Add e2e test for chaincode server

This patch adds new e2e test for the chaincode gRPC server feature.
The test performs as following:

Create a package which contains server and cc information
Build a container image of the chaincode
Install the package into peers
Obtain the installed package ID from the peers
Start the chaincode container with the package ID
Approve and commit the chaincode definition
Invoke and query the chaincode

"rush test:e2e" will perform both tests for both server and client mode.
"start-fabric" is also modified to use external builder scripts.
Signed-off-by: Taku Shimosawa taku.shimosawa@hal.hitachi.com

Hello @shimos   just looking at the build logs... not seen this error before..
ERROR: Internal Error: Could not find peer dependency 'google-auth-library'
that satisfies version '5.x || 6.x
Could it be related to the this PR?
(link to the exact location of the log)
https://dev.azure.com/Hyperledger/Fabric-Chaincode-Node/_build/results?buildId=15481&view=logs&j=ffafc2ec-a09b-5922-a611-c81727b1330f&t=2ec7bbee-918b-5208-fb54-31b4f1c5cbf9&l=199

@mbwhite I have no idea for the error because this patch (or any of the recent patch series) does not change package dependency...
The error might be transient as it sometimes succeeded like this build: https://dev.azure.com/Hyperledger/Fabric-Chaincode-Node/_build/results?buildId=15509&view=logs&j=ffafc2ec-a09b-5922-a611-c81727b1330f&t=2ec7bbee-918b-5208-fb54-31b4f1c5cbf9
(this build failed due to another reason)
Anyway, as a workaround, I added "google-auth-library" (which is a dependency of grpc-js) to the dependency of fabric-shim... but not sure it is appropriate or not. Do you have any idea or suggestion?

@mbwhite The error seems to occur only in the release-2.x branch. I have no idea for the exact cause because these patches never touched package dependencies, but I have found upgrading pnpm version in release-2.x solves the issue. I will submit another PR for that fix.

@shimos great work.. thanks!

authors: mbwhite shimos

repo: hyperledger/fabric-chaincode-node


text:
[ja_JP] Translate "deployment_guide_overview.rst" into Japanese

This patch translates deployment_guide_overview.rst into Japanese.
Resolves #596
Signed-off-by: Satomi Tsujita satomi.t.sora@gmail.com

@shimos レビューありがとうございます！修正しましたので、ご確認よろしくお願いいたします。


text:
pbft modules and pbft core data access needs to be synchronized

Description

obcBatch accesses op.pbft.activeView, which is racy.  Either provide a blocking "RPC" (which would return outdated values), or merge batch and pbft core goroutines.

Should be handled by new event system

repo: hyperledger/fabric

license_source: bigquery


text:
shouldn't we be consistent in naming components?

Description
Our component naming is all over the map. peer, membersrvc, whoknowswhatconsensuswillbecalled, etc.
I would propose that we adopt a consistent naming scheme for all components of the Fabric project: specifically - fabric-xxx where 'xxx' is the short name for a component. Image names and binary names should be the same.
eg.
fabric-peer
fabric-ca
fabric-consenter (or whatever)
fabric-sdk-node
fabric-api
fabric-chaintool
Thoughts?
Describe How to Reproduce

@hyperledger/fabric-maintainers @mastersingh24

@christo4ferris  - we definitely need to have a more uniform component and repository structure.  I believe we have always wanted to pull membersrvc into it's own project/repo.

@mastersingh24 there's something to be said for a single repo strategy... you know for certain when you break the build;-) That said, I was just lamenting that the chaincode shims are not in their own repo as it would make chaincode development much saner to simply vendor the appropriate shim in your chaincode project repo rather than having to vendor the whole of fabric (which is lame),

@hyperledger/fabric-maintainers @mastersingh24 @rameshthoomu @rjones-lf
per the discussion in slack. I really do think we need to settle on a naming scheme. Docker is bringing multi-arch support real soon now https://github.com/docker/distribution/issues/200. In fact the capability is there, the thing missing is the tooling to build images with the v2 manifest. I am told that this is also coming soon. So, we will only need named arch versions temporarily. Since I would expect that most usage will be x86_64, I propose that we have that as the default and omit the architecture from the name for x86_64. For x390x and open power (whatever that arch string is).
I would also suggest that at least for now, we go with the names we have... I would still like to revisit the name of the membersrvc/ca/whatever it is. And, I would like to have agreement on the names of the new components for v2 consensus etc. So, for now that would leave us:
hyperledger/fabric-peer
hyperledger/fabric-membersrvc
hyperledger/fabric-baseimage
hyperledger/fabric-peer-s390x
hyperledger/fabric-membersrvc-s390x
hyperledger/fabric-baseimage-s390x
Again, the s390x will probably be needed only through the fall of this year, until Docker releases a version that includes multi-arch support and we have transitioned to that version.
Please weigh in here with thumbs up or down.
Thanks

:+1:


text:
proposal for ttl fix

for @awrichar 's review comment here: https://github.com/hyperledger/firefly-common/pull/71#pullrequestreview-1503466769
Made a breaking change in the cache interface of all Get methods to make the consumer aware of a bug so that they can now make a decision on how to deal with their existing TTL configurations if exposed.
Resolves https://github.com/hyperledger/firefly-common/issues/78

replaced by https://github.com/hyperledger/firefly-common/pull/86

repo: hyperledger/firefly-common


text:
fix: migrate wallet nonsecret storage to quill

Description:
Summarize the changes you're submitting in a few sentences, including Jira ticket ATL-xxxx if applicable.
Link to any discussion, related issues and bug reports to give the context to help the reviewer understand the PR.
Alternatives Considered (optional):
Link to existing ADR (Architecture Decision Record), if any. If relevant, describe other approaches explored and the selected approach. Documenting why the methods were not selected will create a knowledge base for future reference, helping prevent others from revisiting less optimal ideas.
Checklist:

[ ] My PR follows the contribution guidelines of this project
[ ] My PR is free of third-party dependencies that don't comply with the Allowlist
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have checked the PR title to follow the conventional commit specification

:rocket: Merge success!

:rocket: Merge success

repo: hyperledger/identus-cloud-agent


text:
Remove package-lock.json file from vcx nodejs wrapper

Signed-off-by: artem.ivanov artem.ivanov@dsr-company.com

@jovfer Probably not critical to include package-lock.json in vcx demo, but a rule of thumb is to include package-lock.json in repository. The reasoning behind it is here https://stackoverflow.com/questions/44206782/do-i-commit-the-package-lock-json-file-created-by-npm-5/44210813 Particularly good to note comments by curiousdannii  and  Panu Horsmalahti under the accepted answer.

Why are we duplicating what I already did and proved it didn't work?

@Patrik-Stas In my opinnion vcx demo should be moved to the samples folder. And lock file will be committed there. But for wrapper lock file shouldn't be commited. I also have checked if openssl and zmq wrappers do i.

@mattraffel Yesterday you wrote that couldn't achive changes we had agreed before (removing lock files from folder).
I had tried the solutionyou you had provided and it didn't work for me.
I tried to solve tsconfig errors and pretty fast found the solution.

@mattraffel in other words Artem not duplicates but extend your attempt and have found a solution
@Patrik-Stas @Artemkaaas @mattraffel I think we have 2 options:

merge this one (removing lock files)
or use npm audit fix and just increment problematic dependency issue.

2nd option wasn't work in Matt's environment (the PR #1528 just re-generates lock files, without increment of nested dependency version)
but in my env I'm able to have updated dependency and resolved security warning

alternative solution #1528 has been merged

authors: Artemkaaas Patrik-Stas jovfer mattraffel

repo: hyperledger/indy-sdk


text:
Upgrade Grafana docker image to to 6.0.0

Signed-off-by: Richard Berg rberg@bitwise.io

FYI, while it is not the only reason for this pull obviously, it was in part inspired by the CVE scans mentioned in another pull.  grafana/grafana:6.0.0 starts out much better but there is still one high risk CVE in this image.  Since this image is based on stretch, there isn't a fix for it currently available.
CVE-2017-14062          libidn11-1.33-1                            High              None                   https://security-tracker.debian.org/tracker/CVE-2017-14062

repo: hyperledger/sawtooth-core


text:
added MAINTAINERS.md file

Probably missing some maintainers. Feel free to add them.
Signed-off-by: blu3beri berend@animo.id

I still review PRS I just haven’t submitted any new ones for a while

I still review PRS I just haven’t submitted any new ones for a while

True, and if your name is still on the list our hopes that you'll return to us more fully will continue to burn brightly . . .

@mikelodder7 if you approve this PR we can officially keep you . . .

Done

repo: hyperledger/ursa


text:
generating deep link data and packing it into a URI

🗃 Github Issue Or Explanation for this PR. (What is it supposed to do and Why is needed)
Generate deep link data
I changed some of the guardian data model classes
Also changed a use case
Did not change code upstream since I think we don't need a lot of it - we don't need to keep track of the recovery process, it's all on chain. I think the only thing we need to keep track of on the user's end is which account addresses they have initiated recoveries for.
Once the recovery is complete we will be able to access the "proxy" table on the recovery pallet to see which active recoveries an account has (next PR)
✅ Checklist

[ ] Github issue details are up to date for people to QA.
[x] I have tested all my changes.

🕵♂ Notes for Code Reviewer
This creates a link
https://app.hashed.io/vouch/?lostAccount=&rescuer=

Which is then wrapped into a deeplink.
It does not parse the incoming link.
I think some of the old code should be removed - really all we need is take two strings, lostAccount and rescuer, and create a deep link with that for the user to share with their guardians.
No need to have a lot of lookups and logic as we needed on the seeds light wallet.
🙈 Screenshots
👯♀ Paired with

https://app.hashed.io/vouch/?lostAccount=&rescuer=
Is this link missing something?

https://app.hashed.io/vouch/?lostAccount=&rescuer=
Is this link missing something?

The data...
5FyG1HpMSce9As8Uju4rEQnL24LZ8QNFDaKiu5nQtX6CY6BH
5GwwAKFomhgd4AHXZLUBVK3B792DvgQUnoHTtQNkwmt5h17k
https://app.hashed.io/vouch/?lostAccount= 5FyG1HpMSce9As8Uju4rEQnL24LZ8QNFDaKiu5nQtX6CY6BH&rescuer= 5GwwAKFomhgd4AHXZLUBVK3B792DvgQUnoHTtQNkwmt5h17k
^^ like this

repo: hypha-dao/hashed-wallet

license: MIT


text:
Slow boot experience

I flashed 1.12.0 and a PR build
On the first boot I see a very slow boot experience.
It hangs at a start job is running for /dev/disk/by-partuuid... for 90 seconds.

Fixed with #356

repo: hypriot/image-builder-rpi

license: mit


text:
Some apps takes a ridiculously long time to open

Please consult the issue guidelines at
https://github.com/vaxerski/Hyprland/blob/main/docs/ISSUE_GUIDELINES.md
BEFORE submitting.
I've tried this
exec-once=systemctl --user import-environment WAYLAND_DISPLAY XDG_CURRENT_DESKTOP
no help
exec-once=dbus-update-activation-environment --systemd WAYLAND_DISPLAY XDG_CURRENT_DESKTOP
Similar stuff, also no help.
Currently I'm trying to use wezterm and sirula, both takes a super long time to open.
The logs clearly says it successfully launch it, but in fact I can't see anything on my screen.
https://0x0.st/ojBi.log
[LOG] Executing WAYLAND_DISPLAY=wayland-0 DISPLAY=:1 sirula
[LOG] Process Created with pid 16044

After further inspection, enabling wayland in wezterm fixes it, but I have to have it off for my input method to work.
I've failed to find any workarounds for sirula

Found a really really really werid way to fix this problem

Login into hyprland, will notice the programs are launching very slowly.
Logout, and logie to sway. And the launch the programs you need in sway.
Log out sway, and login into

the apps you're trying to launch are probably gtk / dbus, you probably have a part of the xdg portals broken (most likely xdg-desktop-portal) and dbus times out after 30s.

yep, after using the special version in the AUR, it works flawlessly!

well, I still have to do some weird xdg-desktop-portal hacks.
#!/bin/bash
systemctl --user stop pipewire wireplumber xdg-desktop-portal xdg-desktop-portal-wlr
systemctl --user start wireplumber
/usr/lib/xdg-desktop-portal-wlr -r

I ran this script, and it works! although from what I've heard, doesn't xdg-desktop-portal will be spawned whenever any programs needs it?

doesn't xdg-desktop-portal will be spawned whenever any programs needs it?

no, afaik, it has to be running at all times.

authors: KyleUltimate vaxerski

repo: hyprwm/Hyprland


text:
Only notify if something fails - hyprpm reload -n

Description
In the --help it says  --notify | -n    → Send a hyprland notification for important events (e.g. load fail) but it's also generating on success.

https://github.com/hyprwm/Hyprland/blob/1822707c7e7394ce8c7572f2fe890763a307f499/hyprpm/src/main.cpp#L145-L159

@vaxerski any thoughts. pass & fail are mutually exclusive. No need to notify for both cases.
I don't think anything needs to be changed for hyprpm --help as -n  -> Send a hyprland notification for important events (e.g. load fail) seems to states that it will only send important events like failing.

no it just gives an example. This is a fair request tho, MRs welcome


text:
Replace code of conduct with NCoC

Describe your PR, what does it fix/add?
Better CoC that doesn't add needless politics
Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)
Is it ready for merging, or does it need work?

very funny

No discussion at all? Wow!

Ngl doesn't look that bad (The link at the bottom lol) XDDDD

Ngl doesn't look that bad (The link at the bottom lol) XDDDD

Very depressing that a project claiming inclusion doesn't want to switch to a CoC that is inherently more inclusive than the Contributor Covenant (aka False Covenant, the only true Covenant is that of the Lord)

It's his own project, he decides what CoC/NCoC/BingBongCoC he wants to use.
The very least you could have done is improve the pre-existing one, rather than replacing it with some URL to an external repository, because nobody is gonna it serious when you do it like that, but it's to be expected.

It's his own project, he decides what CoC/NCoC/BingBongCoC he wants to use.
The very least you could have done is improve the pre-existing one, rather than replacing it with some URL to an external repository, because nobody is gonna it serious when you do it like that, but it's to be expected.

"This project adheres to No Code of Conduct.  We are all adults.  We accept anyone's contributions.  Nothing else matters."
That sounds an awful lot like an improvement to the existing code of conduct.

Matter of fact here's a better CoC.
Contributor CoC Slop
Please do not be mean

Actually, I have a better idea...

authors: Eclextic binex-dsk vars1ty vaxerski


text:
Zapping a stream does not seem to work

Zapping stream comments does though

Edit: it seems just that particular stream wasn't setup correctly. I managed to zap another one


text:
"Use Legacy Swift Version" (SWIFT_VERSION)

After updating from xcode 7.2 to xcode 8, my project has stopped compiling at this juncture. It says
(SWIFT_VERSION) is required to be configured correctly for targets which use Swift. Use the [Edit > Convert > To Current Swift Syntax…] menu to choose a Swift version or use the Build Settings editor to configure the build setting directly.
I went into my project, went into build settings, selected swiftcharts and set use legacy swift language version to 'yes' from 'unspecified'. After I did this, I got a few syntax errors which I manually corrected, but ultimately, I got the same error(Use Legacy Swift Version). Furthermore, I cleaned my build, my build folder and deleted the derived data folder for the project. I still get the same error and the build wont complete. How can I resolve this issue? Is this library going to be updated with the newest swift syntax or is there any other workaround I can use to get my project up and running again?

Try updating cocoapods. More details in #168

Was this solved?

Closing for inactivity, feel free to comment if you still need help!

repo: i-schuetz/SwiftCharts


text:
Error when trying to pluralise

I am getting:
key 'main:section.join (en)' returned an object instead of string.

My locales/en/main.json file:
{
  "section": {
    "join": {
      "key": "Text __onlinePlayers__ text",
      "key_plural": "Text __onlinePlayers__ text"
    }
  }
}

access plural like: i18n.t('main:section.join.key', {count: 10});

@jamuhl when I do that it always just takes the key. Also if onlinePlayers > 1.

the passed in option needs to be count for the plural so:
a)
{
  "section": {
    "join": {
      "key": "Text __count__ text",
      "key_plural": "Text __count__ text"
    }
  }
}

or b)
i18n.t('main:section.join.key', {count: 10, onlinePlayers: 10});

Thanks a lot! The option to use custom variable names as feature would be nice. Because I can imagine that I'll need to make more than 1 string pluralisable in the future.

authors: ApfelUser jamuhl


text:
Add instructions on how to load translations with webpack

I use webpack in my front-end projects and the translations are not served on the back-end. They are static json files inside the front-end application.
I managed to use this plugin with webpack loading the translations files async.
I think this solution could be shared with the community, since I had some difficulties finding out how should I write my custom xhr function and its callback and, later, with the parse function. I thought that will help someone else doing those same mistakes.

not sure...what's the benefit of using the bundle-loader instead of the xhr function built in?
would it make sense to have a separate backend just for webpack usage? so devs just can use that without manual override xhr and parse?

@jamuhl
Most front end applications using webpack are build this way:
src/
dist/
webpack.config.js

Webpack get the files in src process them (transpile with babel, convert jsons to js files, uglify, etc) and dump them in dist. For webpack to work on the src files you need to require them using import x from './x'; or var x = require('./x');. Those files will be bundled together in a single file (also called an entry-point).
When you want to require files asynchronously using webpack you may want to use bundle-loader. The bundle loader will include the required files in the webpack build, but will not bundle it together with the entry-point, it will create a separate file, since this file will be required asynchronously.
let waitForLocale = require('bundle!./locales/'+url+'.json');

Webpack will interpret this line and all the files in ./locales/*.json will be included in the build like so:
src/
-- app.js
-- locales/
---- en.json
---- es.json
dist/
-- app.js
-- 1.app.js (this was formely en.json)
-- 2.app.js (this was formely es.json)

TL;DR: Using the built in xhr function, will not work here, because the translation files will not be included in the dist/ folder, since no file processed by webpack required those files.

sorry was not clear enough...i know the build process of webpack...it just wasn't clear to me you want the locales bundled to dist.
We keep our translation out of the build main reason is we update translations without deploying a new version.
Will merge this. But still would love to see a i18next-webpack-backend ;)

Oh, now I get it what you mean by a new backend, you mean a new i18next plugin! Yes, that could be a good solution as well!
Maybe I'll revisit and do this, but it's up for grabs anyways.

yes...meant a complete backend plugin...so one just needs to grab that and no manual override in the basic xhr-backend.
would be great to see this...right now i'm hard on time...so if you get on this before me feel free to add it to documentation: https://github.com/i18next/i18next.com/blob/master/pages/docs/ecosystem/index.md

authors: brenoc jamuhl


text:
Load all packages in application - Issue 2514

This breaks recompilation badly and probably not the best way to handle this. Still investigating.
fixes: #2514

Closing - will revisit.

repo: iBotPeaches/Apktool


text:
Version 3.x support

Add support for version 3.x fixing #70;
change behavior of the Layers checkbox (default off) fixing #67

@renatoalmeidaoliveira Great job!
I have tested this in my local NetBox 3.x environment. The plugin embeds into the new NetBox Web-UI fine.
One thing before we can proceed with merge.
Please move the suggested changes regarding #67 into a separate PR as this issue is not directly related to NetBox 3.x compatibility. It requires a separate discussion and solution.

@iDebugAll sure, have you tested on the older versions too? I did my best to mantain backward compatibility.

@renatoalmeidaoliveira I have tested on NetBox 2.11 as well – it works as expected. All the changes for NB 3.x in your PR are conditional so the backward compatibility should be preserved.

@iDebugAll, reverted the changes relative to #67

authors: iDebugAll renatoalmeidaoliveira

repo: iDebugAll/nextbox-ui-plugin


text:
🛑 OBEC Academy is down

In 4b8ca7e, OBEC Academy (https://dlp.obec.go.th) was down:

HTTP code: 0
Response time: 0 ms

Resolved: OBEC Academy is back up in c9ad6be after 8 minutes.


text:
Github Actions toevoegen

Branch name: workflow/github-actions-toevoegen
Part of: -
Blocked by: -
Omschrijving:
Het zorgt ervoor dat de standaarden nageleefd worden. Ik kan maar een iemand assignen, maar @iSirThijs is ook onderdeel van deze taak.

@iSirThijs Ik heb een begin gemaakt met verschillende files. Ik denk dat het leuk is om daar vandaag even naar te kijken. Nog niet heel veel gedaan, dus er is nog genoeg te doen 🙂

Pipeline faalde door workflow_dispatch. Nog niet goed naar gekeken, dus kunnen we vandaag nog even doen (https://docs.github.com/en/actions/reference/events-that-trigger-workflows#workflow_dispatch).
Faalt nog steeds half (https://github.com/iSirThijs/jungle-gym/tree/workflow/github-actions-toevoegen). Lijkt mij wel leuk om er vanmiddag even goed naar te kijken. Ik heb nu gewoon wat templates gekopieerd.

Fixed

repo: iSirThijs/jungle-gym


text:
Feature/conflicten develompent oplossen 2

Description
Closes #158
Branch name: /
Hierdoor is development straks up to date met main
Type of change
Please select the option that is relevant

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation

Checklist

[x] I have commented my code, particularly in hard-to-understand areas.
[x] All the required documentation is added.
[x] My code follows the style guidelines of this project.
[x] I have performed a self-review of my own code.

Additional information
[Provided extra information if necessary]

Ik heb dit gefixt op mijn PC en gepushed

authors: iSirThijs jochemvogel


text:
非常棒的项目

我搜遍了全网，就想找个TabLayout的对于TV上的焦点处理的例子学习下，太感谢老哥了！

客气

repo: iSuperRed/LeanbackTvSample


text:
Table: columns become sticky right when added with column manager

Describe the bug (actual behavior)
After reordering columns and selecting not visible columns in column manager, they become sticky right.
Expected behavior
Columns should not become sticky after reordering and selecting not visible columns in column manager..
Reproduction
https://codesandbox.io/s/itwinui-react-example-forked-g9xroe?file=/src/App.tsx
Steps to reproduce

Add sticky: right column manager and enable column reordering.
In column manager unselect a few columns
Reorder existing columns. For example, drag the first column onto the second
In column manager select any not selected column
Selected column becomes sticky right

Additional information
"itwinui-react": 1.47.1
https://user-images.githubusercontent.com/75395229/196682818-296306eb-6805-467f-8135-acd1525220e4.mp4

@adamhock any progress with this one?

@GintV A PR for this issue has been merged and will be releasing soon

authors: GintV adamhock medikornov

repo: iTwin/iTwinUI


text:
Workspace peerDependencies should be specified without ^

Describe the bug
Because all packages in this repo are released in lockstep and they are using @internal APIs between each other, workspace peerDependencies should be specified without ^ to enforce that same version of packages will be installed by the package manager. At the moment all workspace peerDependencies are specified with ^ and package manager might resolve some of them to a different (higher) version if auto-install-peers are enabled.
Specifying peerDependencies without ^ would result in warning/error during installation.
To Reproduce
Steps to reproduce the behavior:

Go to https://stackblitz.com/edit/vitejs-vite-rthgsj?file=package.json&terminal=dev
No warnings are reported during install regarding different @itwin/core-frontend and @itwin/core-common versions.

Expected behavior
Warning or error should be produced by package manager during installation if different versions of locked step packages are installed.

fyi @wgoehrig

I made one more sample to show why peerDependencies between itwinjs-core packages should be specified without ^. As we publish packages from itwinjs-core in lockstep we assume that consumers will use same version of those packages. Looking at package.json files this requirement is no clear and package managers do not try to resolve all packages to the same version.
For example @itwin/core-frontend@4.0.0 specifies peer dependency on @itwin/core-common as ^4.0.0 which means that it supports versions >4.0.0 and <5.0.0. However, trying to build app with @itwin/core-frontend@4.0.0 and @itwin/core-common@4.10.0 results in build failure although package manager was happy while installing dependencies. This can be seen be cloning peer-deps-fix branch from this repo: https://github.com/saskliutas/itwin-viewer-app/tree/peer-deps-fix and running pnpm install pnpm build.
This is quite an extreme example but it can be encountered accidentally if auto-install-peers flag is set to true and we add only @itwin/core-frontend@4.0.0 to package.json file. Package manager will resolve @itwin/core-common to the latest version based on ^4.0.0 specifier.
This could be mitigated by removing ^ from peerDependencies specifiers between itwinjs-core packages. In that case we would explicitly declare in package.json that @itwin/core-frontend@4.0.0 works and should be used only with @itwin/core-common@4.0.0. If different version are specified package manager will produce warning/error during installation. This can be seen in the example repo by setting fixDeps = true in .pnpmfile.cjs. It will remove ^ from peerDependencies between itwinjs-core package during install and running pnpm install will result in error.

5.0 seems like a good time to fix this oversight

@aruniverse is this in fact slated for 5.0?

5.0 seems like a good time to fix this oversight

@aruniverse is this in fact slated for 5.0?

Not yet, but we can add it if we all agree on this. I haven't had time to circle back on this and evaluate the proposal, still torn on this

authors: aruniverse pmconne saskliutas

repo: iTwin/itwinjs-core


text:
Move package core-bentley to normal dependencies.

Move package core-bentley to normal dependencies.
Uniformize error handling.

@EricPaquetB core-bentley shouldve been added as a peer dep

@aruniverse , for which reason ? The way I understand peer dependencies, core-bentley is not one; it is a direct dependency. It would be a peer dependency if it was a host hosting a reality-data-client "plugin" ... ?

@aruniverse , for which reason ?

Typically a bad idea to have a direct dep on a pkg if it uses statics and the usage isn't pure. Sicne you're returning instances of BentleyError, there might be collisions with BentleyError from other versions (even patches). I think it's best to make core-bentley here a dev+peer. I will review again tomorrow morning to make sure if its safe or not to do so.

@EricPaquetB @MarcBedard8 @aruniverse this change should have been a minor version bump to go to 0.8.0 since this is a breaking change.

authors: EricPaquetB aruniverse calebmshafer

repo: iTwin/reality-data-client


text:
bump viewer repo to use cra 4.0

Bump to bentley/react-scripts 4.0
Had to update linting configs a bit, but they should still work like before

fyi, 4.0.3-dev.1 works as expected here, but will break once #12 goes through, due to an issue with the new CopyStaticAssetsPlugin having trouble traversing pnpm workspaces

fyi, 4.0.3-dev.1 works as expected here, but will break once #12 goes through, due to an issue with the new CopyStaticAssetsPlugin having trouble traversing pnpm workspaces

edit: we had found a workaround for this, but then found an issue with pnpm 6.x and duplicated peer deps, so this comment can be ignored

repo: iTwin/viewer


text:
docs (contributing) Update local environment setup steps to fix npm link problems per issue #472

In the Contributing documentation, the order of steps in the local environment setup section was in an order that broke the link between React in next-auth and the consuming application.
Reversing the order of Steps 3 & 4 fixed this issue and allowed me to link my project with next-auth for local development.
https://github.com/iaincollins/next-auth/issues/472

Thanks Ben! This makes sense. I'll check this out on a clean folder!

authors: BenjaminWFox iaincollins

repo: iaincollins/next-auth

license: ISC


text:
Node 18 throws ERR_LOADER_CHAIN_INCOMPLETE

More details to follow shortly!
  Error {
    code: 'ERR_LOADER_CHAIN_INCOMPLETE',
    message: '"./src/esmockLoader.mjs \'load\'" did not call the next hook in its chain and did not explicitly signal a short circuit. If this is intentional, include `shortCircuit: true` in the hook\'s return.',
  }

I was going to publish the other PR and the tests were failing locally. Using node v18.5.0, this patch resolves the errors,
diff --git a/src/esmockLoader.mjs b/src/esmockLoader.mjs
index 1377a48..e98df4c 100644
--- a/src/esmockLoader.mjs
+++ b/src/esmockLoader.mjs
@@ -36,7 +36,7 @@ const resolve = async (specifier, context, defaultResolve) => {
   if (!esmockKeyParam)
     return defaultResolve(specifier, context, defaultResolve);

-  const resolved = defaultResolve(specifier, context, defaultResolve);
+  const resolved = await defaultResolve(specifier, context, defaultResolve);
   const resolvedurl = decodeURI(resolved.url);
   const moduleKeyRe = new RegExp(
     '.*(' + resolvedurl + '\\?' + esmockKeyParam + '[^#]*).*');

adding it in a separate PR soonish

When running the tests locally this error is not seen. How does one reproduce this?

My apologies. Forgot to come back and fill out more details.
$ node --version
18.6.0

$ npm --version
8.13.2

$ git rev-parse HEAD
7c37739f5e56a54cc3cc48ca520275bd1d09d0ee

$ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

$ uname -a
Linux - 5.17.4-arch1-1 #1 SMP PREEMPT Wed, 20 Apr 2022 18:29:28 +0000 x86_64 GNU/Linux

Running the following produces the error:
git clean -dxf
npm i
npm run test

Here's an exhaustive display of the errors I received locally when testing:
> esmock@1.7.6 test
> npm run test-ava && npm run test-uvu

> esmock@1.7.6 test-ava
> ava --node-arguments="--loader=./src/esmockLoader.mjs" ./spec/ava/*.spec.js

(node:1386701) ExperimentalWarning: Custom ESM Loaders is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
(node:1386701) ExperimentalWarning: Custom ESM Loaders is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)

  ✖ esmock.ava.only › should not error when esmock used with ava.only // Rejected promise returned by test
  ✔ esmock.ava › should throw error if !esmockloader
  ✔ esmock.ava › should throw error if local definition file not found
  ✔ esmock.ava › should throw error if local file not found (420ms)
  ✔ esmock.ava › should have small querystring in stacktrace filename (421ms)
  ✖ esmock.ava › should mock core module // Rejected promise returned by test
  ✖ esmock.ava › returns spread-imported [object Module] default export // Rejected promise returned by test
  ✖ esmock.ava › should mock a module // Rejected promise returned by test
  ✖ esmock.ava › should mock a module, many times differently // Rejected promise returned by test
  ✖ esmock.ava › mocks inline `async import("name")` // Rejected promise returned by test
  ✖ esmock.ava › should work well with sinon // Rejected promise returned by test
  ✖ esmock.ava › should mock local file // Rejected promise returned by test
  ✖ esmock.ava › should mock module and local file at the same time // Rejected promise returned by test
  ✖ esmock.ava › should mock a module, globally // Rejected promise returned by test
  ✖ esmock.ava › should purge local and global mocks // Rejected promise returned by test
  ✖ esmock.ava › should have small querystring in stacktrace filename, deep // Rejected promise returned by test
  ✖ esmock.ava › __esModule definition, inconsequential // Rejected promise returned by test
  ✖ esmock.ava › should mock a local file // Rejected promise returned by test
  ✖ esmock.ava › should mock an mjs file // Rejected promise returned by test
  ✖ esmock.ava › should mock an mjs file, again // Rejected promise returned by test
  ✖ esmock.ava › should apply third parameter "global" definitions // Rejected promise returned by test
  ✖ esmock.ava › should mock an exported constant values // Rejected promise returned by test
  ✖ esmock.ava › should not error when mocked file has space in path // Rejected promise returned by test
  ✔ esmock.ava › should return un-mocked file (703ms)
  ✔ esmock.ava › should return un-mocked file (again) (678ms)
  ✖ esmock.ava › should merge "default" value, when safe // Rejected promise returned by test
  ─

  esmock.ava.only › should not error when esmock used with ava.only

  Rejected promise returned by test. Reason:

  Error {
    code: 'ERR_LOADER_CHAIN_INCOMPLETE',
    message: '"./src/esmockLoader.mjs \'load\'" did not call the next hook in its chain and did not explicitly signal a short circuit. If this is intentional, include `shortCircuit: true` in the hook\'s return.',
  }

  esmock.ava › should mock core module

  Rejected promise returned by test. Reason:

  Error {
    code: 'ERR_LOADER_CHAIN_INCOMPLETE',
    message: '"./src/esmockLoader.mjs \'load\'" did not call the next hook in its chain and did not explicitly signal a short circuit. If this is intentional, include `shortCircuit: true` in the hook\'s return.',
  }

  esmock.ava › returns spread-imported [object Module] default export

  Rejected promise returned by test. Reason:

  Error {
    code: 'ERR_LOADER_CHAIN_INCOMPLETE',
    message: '"./src/esmockLoader.mjs \'load\'" did not call the next hook in its chain and did not explicitly signal a short circuit. If this is intentional, include `shortCircuit: true` in the hook\'s return.',
  }

  esmock.ava › should mock a module

  Rejected promise returned by test. Reason:

  Error {
    code: 'ERR_LOADER_CHAIN_INCOMPLETE',
    message: '"./src/esmockLoader.mjs \'load\'" did not call the next hook in its chain and did not explicitly signal a short circuit. If this is intentional, include `shortCircuit: true` in the hook\'s return.',
  }

  esmock.ava › should mock a module, many times differently

  Rejected promise returned by test. Reason:

  Error {
    code: 'ERR_LOADER_CHAIN_INCOMPLETE',
    message: '"./src/esmockLoader.mjs \'load\'" did not call the next hook in its chain and did not explicitly signal a short circuit. If this is intentional, include `shortCircuit: true` in the hook\'s return.',
  }

  esmock.ava › mocks inline `async import("name")`

  Rejected promise returned by test. Reason:

  Error {
    code: 'ERR_LOADER_CHAIN_INCOMPLETE',
    message: '"./src/esmockLoader.mjs \'load\'" did not call the next hook in its chain and did not explicitly signal a short circuit. If this is intentional, include `shortCircuit: true` in the hook\'s return.',
  }

  esmock.ava › should work well with sinon

  Rejected promise returned by test. Reason:

  Error {
    code: 'ERR_LOADER_CHAIN_INCOMPLETE',
    message: '"./src/esmockLoader.mjs \'load\'" did not call the next hook in its chain and did not explicitly signal a short circuit. If this is intentional, include `shortCircuit: true` in the hook\'s return.',
  }

  esmock.ava › should mock local file

  Rejected promise returned by test. Reason:

  Error {
    code: 'ERR_LOADER_CHAIN_INCOMPLETE',
    message: '"./src/esmockLoader.mjs \'load\'" did not call the next hook in its chain and did not explicitly signal a short circuit. If this is intentional, include `shortCircuit: true` in the hook\'s return.',
  }

  esmock.ava › should mock module and local file at the same time

  Rejected promise returned by test. Reason:

  Error {
    code: 'ERR_LOADER_CHAIN_INCOMPLETE',
    message: '"./src/esmockLoader.mjs \'load\'" did not call the next hook in its chain and did not explicitly signal a short circuit. If this is intentional, include `shortCircuit: true` in the hook\'s return.',
  }

  esmock.ava › should mock a module, globally

  Rejected promise returned by test. Reason:

  Error {
    code: 'ERR_LOADER_CHAIN_INCOMPLETE',
    message: '"./src/esmockLoader.mjs \'load\'" did not call the next hook in its chain and did not explicitly signal a short circuit. If this is intentional, include `shortCircuit: true` in the hook\'s return.',
  }

  esmock.ava › should purge local and global mocks

  Rejected promise returned by test. Reason:

  Error {
    code: 'ERR_LOADER_CHAIN_INCOMPLETE',
    message: '"./src/esmockLoader.mjs \'load\'" did not call the next hook in its chain and did not explicitly signal a short circuit. If this is intentional, include `shortCircuit: true` in the hook\'s return.',
  }

  esmock.ava › should have small querystring in stacktrace filename, deep

  Rejected promise returned by test. Reason:

  Error {
    code: 'ERR_LOADER_CHAIN_INCOMPLETE',
    message: '"./src/esmockLoader.mjs \'load\'" did not call the next hook in its chain and did not explicitly signal a short circuit. If this is intentional, include `shortCircuit: true` in the hook\'s return.',
  }

  esmock.ava › __esModule definition, inconsequential

  Rejected promise returned by test. Reason:

  Error {
    code: 'ERR_LOADER_CHAIN_INCOMPLETE',
    message: '"./src/esmockLoader.mjs \'load\'" did not call the next hook in its chain and did not explicitly signal a short circuit. If this is intentional, include `shortCircuit: true` in the hook\'s return.',
  }

  esmock.ava › should mock a local file

  Rejected promise returned by test. Reason:

  Error {
    code: 'ERR_LOADER_CHAIN_INCOMPLETE',
    message: '"./src/esmockLoader.mjs \'load\'" did not call the next hook in its chain and did not explicitly signal a short circuit. If this is intentional, include `shortCircuit: true` in the hook\'s return.',
  }

  esmock.ava › should mock an mjs file

  Rejected promise returned by test. Reason:

  Error {
    code: 'ERR_LOADER_CHAIN_INCOMPLETE',
    message: '"./src/esmockLoader.mjs \'load\'" did not call the next hook in its chain and did not explicitly signal a short circuit. If this is intentional, include `shortCircuit: true` in the hook\'s return.',
  }

  esmock.ava › should mock an mjs file, again

  Rejected promise returned by test. Reason:

  Error {
    code: 'ERR_LOADER_CHAIN_INCOMPLETE',
    message: '"./src/esmockLoader.mjs \'load\'" did not call the next hook in its chain and did not explicitly signal a short circuit. If this is intentional, include `shortCircuit: true` in the hook\'s return.',
  }

  esmock.ava › should apply third parameter "global" definitions

  Rejected promise returned by test. Reason:

  Error {
    code: 'ERR_LOADER_CHAIN_INCOMPLETE',
    message: '"./src/esmockLoader.mjs \'load\'" did not call the next hook in its chain and did not explicitly signal a short circuit. If this is intentional, include `shortCircuit: true` in the hook\'s return.',
  }

  esmock.ava › should mock an exported constant values

  Rejected promise returned by test. Reason:

  Error {
    code: 'ERR_LOADER_CHAIN_INCOMPLETE',
    message: '"./src/esmockLoader.mjs \'load\'" did not call the next hook in its chain and did not explicitly signal a short circuit. If this is intentional, include `shortCircuit: true` in the hook\'s return.',
  }

  esmock.ava › should not error when mocked file has space in path

  Rejected promise returned by test. Reason:

  Error {
    code: 'ERR_LOADER_CHAIN_INCOMPLETE',
    message: '"./src/esmockLoader.mjs \'load\'" did not call the next hook in its chain and did not explicitly signal a short circuit. If this is intentional, include `shortCircuit: true` in the hook\'s return.',
  }

  esmock.ava › should merge "default" value, when safe

  Rejected promise returned by test. Reason:

  Error {
    code: 'ERR_LOADER_CHAIN_INCOMPLETE',
    message: '"./src/esmockLoader.mjs \'load\'" did not call the next hook in its chain and did not explicitly signal a short circuit. If this is intentional, include `shortCircuit: true` in the hook\'s return.',
  }

  ─

  20 tests failed

Looks like this was an issue introduced with v18.6.0

I did some digging, and it looks like it was a breaking change introduced here: https://github.com/nodejs/node/pull/42623
In the release notes of the tag, they reference this article as well: https://dev.to/jakobjingleheimer/custom-esm-loaders-who-what-when-where-why-how-4i1o

Thanks for all the info. Upstream node 18.5.0-1 is still used by my package manager but that will probably update in the next day or two.

wonder if there is any negative consequence to using 'shortCircuit: true'... returning that extra property in the load and resolve hooks likely resolves the issue w/out any further changes

I actually tried that, and it fixes all but one of the tests. The remaining failing test complains about a missing "responseURL", oddly enough.
diff --git a/src/esmockLoader.mjs b/src/esmockLoader.mjs
index 30464c6..85fb6d2 100644
--- a/src/esmockLoader.mjs
+++ b/src/esmockLoader.mjs
@@ -83,6 +83,7 @@ const load = async (url, context, defaultGetSource) => {
   if (exportedNames.length) {
     return {
       format : 'module',
+      shortCircuit : true,
       source : exportedNames.map(name => name === 'default'
         ? `export default global.esmockCacheGet("${url}").default`
         : `export const ${name} = global.esmockCacheGet("${url}").${name}`

Here are the results that I got when I changed it:
> esmock@1.7.6 test
> npm run test-ava && npm run test-uvu

> esmock@1.7.6 test-ava
> ava --node-arguments="--loader=./src/esmockLoader.mjs" ./spec/ava/*.spec.js

(node:1389345) ExperimentalWarning: Custom ESM Loaders is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
(node:1389345) ExperimentalWarning: Custom ESM Loaders is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
  ✔ esmock.ava.only › should not error when esmock used with ava.only
  ✔ esmock.ava › should throw error if !esmockloader
  ✔ esmock.ava › should throw error if local definition file not found
  ✔ esmock.ava › should throw error if local file not found (431ms)
  ✔ esmock.ava › should have small querystring in stacktrace filename (408ms)
  ✔ esmock.ava › should mock core module (434ms)
  ✔ esmock.ava › returns spread-imported [object Module] default export (434ms)
  ✔ esmock.ava › should mock a module (481ms)
  ✔ esmock.ava › mocks inline `async import("name")` (468ms)
  ✔ esmock.ava › should mock local file (515ms)
  ✔ esmock.ava › should work well with sinon (518ms)
  ✔ esmock.ava › should mock module and local file at the same time (529ms)
  ✔ esmock.ava › __esModule definition, inconsequential (534ms)
  ✔ esmock.ava › should mock an mjs file (604ms)
  ✔ esmock.ava › should mock an mjs file, again (605ms)
  ✔ esmock.ava › should mock an exported constant values (607ms)
  ✖ esmock.ava › should not error when mocked file has space in path Rejected promise returned by test
  ✔ esmock.ava › should return un-mocked file (711ms)
  ✔ esmock.ava › should return un-mocked file (again) (671ms)
  ✔ esmock.ava › should mock a local file (707ms)
  ✔ esmock.ava › should have small querystring in stacktrace filename, deep (658ms)
  ✔ esmock.ava › should apply third parameter "global" definitions (673ms)
  ✔ esmock.ava › should mock a module, many times differently (723ms)
  ✔ esmock.ava › should purge local and global mocks (730ms)
  ✔ esmock.ava › should mock a module, globally (739ms)
  ✔ esmock.ava › should merge "default" value, when safe (704ms)
  ─

  esmock.ava › should not error when mocked file has space in path

  Rejected promise returned by test. Reason:

  TypeError {
    code: 'ERR_INVALID_RETURN_PROPERTY_VALUE',
    message: 'Expected undefined or a fully resolved URL string to be returned for the "responseURL" from the "./src/esmockLoader.mjs \'load\'" function but got instance of String.',
  }

  ─

  1 test failed

Additional test:
diff --git a/src/esmockLoader.mjs b/src/esmockLoader.mjs
index 30464c6..f274616 100644
--- a/src/esmockLoader.mjs
+++ b/src/esmockLoader.mjs
@@ -73,16 +73,21 @@ const load = async (url, context, defaultGetSource) => {
   if (esmockModuleKeysRe.test(url)) // parent of mocked modules
     return defaultGetSource(url, context, defaultGetSource);

+  if (/\s/.test(url)) console.log('1', url);
+
   url = url.replace(esmockGlobalsAndAfterRe, '');
   if (url.startsWith(urlDummy)) {
     url = url.replace(withHashRe, '');
   }

+  if (/\s/.test(url)) console.log('2', url);
+
   const exportedNames = exportNamesRe.test(url) &&
     url.replace(exportNamesRe, '$1').split(',');
   if (exportedNames.length) {
     return {
       format : 'module',
+      shortCircuit : true,
       source : exportedNames.map(name => name === 'default'
         ? `export default global.esmockCacheGet("${url}").default`
         : `export const ${name} = global.esmockCacheGet("${url}").${name}`

Resulted in:
...
  ✔ esmock.ava › __esModule definition, inconsequential (593ms)
  ✔ esmock.ava › should mock an mjs file (664ms)
  ✔ esmock.ava › should mock an mjs file, again (665ms)
  ✔ esmock.ava › should mock an exported constant values (667ms)
1 file:///home/****/src/by-project/esmock/spec/local/space in path/wild-file.js?esmockKey=23&esmockModuleKey=../local/space in path/wild-file.js&isesm=true&exportNames=default
  ✖ esmock.ava › should not error when mocked file has space in path Rejected promise returned by test
2 file:///home/****/src/by-project/esmock/spec/local/space in path/wild-file.js?esmockKey=23&esmockModuleKey=../local/space in path/wild-file.js&isesm=true&exportNames=default
  ✔ esmock.ava › should return un-mocked file (772ms)
  ✔ esmock.ava › should return un-mocked file (again) (732ms)
  ✔ esmock.ava › should mock a local file (768ms)
  ✔ esmock.ava › should have small querystring in stacktrace filename, deep (714ms)
...

https://github.com/guybedford/node/blob/106303679fa98c5337494aef0c89ffeeaa971832/lib/internal/modules/esm/loader.js#L376
https://github.com/guybedford/node/blob/106303679fa98c5337494aef0c89ffeeaa971832/lib/internal/modules/esm/loader.js#L553
its possible the tests could pass if the loaders return an additional field "responseURL". not sure if the responseURL should include the query string or not.

@Swivelgames if all tests pass with that change, its probably a good change

@iambumblehead Looks like the change was actually replacing all spaces with %20, believe it or not.
I'll finish testing and push a PR shortly.

authors: Swivelgames iambumblehead

repo: iambumblehead/esmock


text:
Set default value of Prediction to "Unknown"

Set the default value of Prediction to "Unknown"
and some minor changes in predict.py

Okay ayush!
I will surely do that...
On Sun, Dec 8, 2019, 11:27 PM Ayush Gupta notifications@github.com wrote:

You can view, comment on, or merge this pull request online at:
https://github.com/iamchinu14/hand_gesture_recognition/pull/6
Commit Summary

Set default value of Prediction to "Unknown"

File Changes

M predict.py
https://github.com/iamchinu14/hand_gesture_recognition/pull/6/files#diff-0
(19)

Patch Links:

https://github.com/iamchinu14/hand_gesture_recognition/pull/6.patch
https://github.com/iamchinu14/hand_gesture_recognition/pull/6.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/iamchinu14/hand_gesture_recognition/pull/6?email_source=notifications&email_token=AKLZWEDL2RSXFIWBQBTCKD3QXUYP5A5CNFSM4JX6VL5KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4H64753A,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKLZWEBTELG3TCFYWTAKZI3QXUYP5ANCNFSM4JX6VL5A
.

please check the pull request.

Hey bro!
My distro has crashed since a week. Also, my exam is going on. It will end
on 13 Dec.
I will surely check your request...
Keep some patience.
On Tue, Dec 10, 2019, 12:56 AM Ayush Gupta notifications@github.com wrote:

please check the pull request.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/iamchinu14/hand_gesture_recognition/pull/6?email_source=notifications&email_token=AKLZWED2CO2ICZFR72YKMXDQX2LWHA5CNFSM4JX6VL5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGKLM4Y#issuecomment-563394163,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKLZWEF46SJTQLGFYU2MARLQX2LWHANCNFSM4JX6VL5A
.

oK sure take your time.

Hey! @siAyush . There is problem in it. I don't know  which case you took. But, it is not showing anything 'Unknown'. Check it out and make another pull request....

ok i try to fix it.


text:
Ajax + custom fields

Need a feature to use Ajax loading and virtual repeat...
For example I need to show all record from database with custom html fileld (additional actions for example)
Can you help to realize that?

@Stormsher virtual repeat is under development right now. You have to be patient for few days until I get it implemented.
Additional actions are also in the next steps but I can't tell you when exactly. In this month for sure.

Aww, I was hoping this grid would do that... Kind of defeats the purpose of virtual repeat if it has to load all the rows upfront

Now there is an html support for mdt-row attribute. Does it help you?
It's still not working with virtual-repeat, but maybe pagination is enough for you.

Also there is mdt-custom-cell you can use. Check the documentation.

authors: Stormsher iamisti manifestarium

repo: iamisti/mdDataTable


text:
Slow first connection to DB

First project run is very slow because of DB

Probably this is an answer

@Lenkelheit mentioned, that we could do very simple request to DataBase on Application startup

repo: iamprovidence/Coursework


text:
Library not found: libmetasec_ov.so

i always get the message
Library not found: libmetasec_ov.so
even though i can find this library via the File manager app

i dont have an android phone to test on right now so i ran the server on a memu player emulator
i edited injector.py to make it work but got the above error
`import frida
import subprocess
class Inject:
def init(self, target: str, is_emulator: bool = False):
"""
Initialize the class with the target name or process ID.
Set is_emulator to True if the target is an emulator.
"""
self.target = target
self.is_emulator = is_emulator
def attach(self):
    """
    Attach to the target device or emulator.
    """
    device = frida.get_usb_device()

    if self.is_emulator:
        # Attach to the emulator process
        pid = self.get_emulator_pid()
        if not pid:
            raise Exception(f"Could not find the emulator: {self.target}")
        session = device.attach(pid)
    else:
        # Attach to a physical device using the package name or PID
        app = device.get_frontmost_application()
        if app:
            target_pid = app.pid
        else:
            target_pid = self.target
        session = device.attach(target_pid)

    return device, session

def get_emulator_pid(self) -> int:
    """
    Get the process ID (PID) of the emulator using ADB.
    """
    result = subprocess.run(['adb', 'shell', 'ps'], stdout=subprocess.PIPE)
    processes = result.stdout.decode('utf-8').splitlines()

    for process in processes:
        if self.target in process:
            return int(process.split()[1])

    return None

def source(self, session, code):
    """
    Inject JavaScript code into the Frida session.
    """
    return session.create_script(code)`

Is the App on Emulator started before executing the Injector?

@vanbac91 please reopen if the problem occurs again.

repo: iamtorsten/SherlockElf


text:
🛑 mi-core is down

In 51a073a, mi-core (https://www.mi-core.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: mi-core is back up in f47b793.


text:
Add Czech language

There is a Czech wordlist available in BIP39, so I think I'd would be great to have it here as well to have possibility to generate mnemonic in additional language for people from Czechia.

Great thanks!
I didn't see this was merged to master in the  bips repository, thanks for creating a PR.

authors: hladik-dan iancoleman


text:
inSpan without UnliftIO

I am working on an app where the monad doesn't support unliftio. I would like to understand why inSpan requires UnliftIO? It seems like it is just in the bracketError function. It would be great to provide an inSpan function that doesn't require this constraint, but I am not sure where to start.

for example, I think this works:
bracketErrorIO :: IO a -> (Maybe SomeException -> a -> IO b) -> (a -> IO c) -> IO c
bracketErrorIO before after thing = EUnsafe.mask $ \restore -> do
  x <- before
  res1 <- EUnsafe.try $ restore $ thing x
  case res1 of
    Left (e1 :: SomeException) -> do
      -- explicitly ignore exceptions from after. We know that
      -- no async exceptions were thrown there, so therefore
      -- the stronger exception must come from thing
      --
      -- https://github.com/fpco/safe-exceptions/issues/2
      _ :: Either SomeException b <-
        EUnsafe.try $ EUnsafe.uninterruptibleMask_ $ after (Just e1) x
      EUnsafe.throwIO e1
    Right y -> do
      _ <- EUnsafe.uninterruptibleMask_ $ after Nothing x
      return y

This is probably a good overview on the tradeoffs around catching errors for various monads:
https://stackoverflow.com/questions/46425062/should-i-prefer-monadunliftio-or-monadmask-for-bracketting-like-functions

if you know [...] (that you) want compile time guarantees about the correctness of your code vis-a-vis monadic state, use MonadUnliftIO.

This is a particularly important principal for observability tooling– the presence of of tracing should not affect the semantics of the code that's being instrumented. Therefore, we go with the most conservative option for what the library supports by default. If you don't particularly care about maintaining those semantics in your situation, you could use the exceptions-package based implementation provided here: https://github.com/iand675/hs-opentelemetry/tree/main/utils/exceptions
However, there are often ways to make it work for your situation, even with MonadUnliftIO:
Say you're working with ExceptT, for example:
getUser :: MonadIO m => ExceptT HttpResponse m User
getUser = do
  thing1 <- foo
  thing2 <- bar
  thing3 <- baz
  pure $ constructUser thing1 thing2 thing3

Option 1: use inSpan within liftIO if you are able

  ...
  thing2 <- liftIO $ inSpan "bar" bar
  ...

Option 2: use a natural transformation to convert your code that doesn't support MonadUnliftIO into one that handles exceptions better. This is a bit of code I use when I use servant to avoid the overhead of ExceptT and support a MonadUnliftIO instance, as an example:

-- natural transformation
nt :: AppState -> AppM a -> Handler a
nt s x = Handler $ ExceptT $ catch (Right <$> runAppM s x) $ \(e :: ServerError) -> pure $ Left e

Option 3: Use the exceptions based OTel instrumentation I mentioned above. Likely the easiest drop in solution, but with the caveat that it can be subtly wrong in some cases if you don't pay close attention to the semantics of your monad transformer stack.

Oh this is great. I actually ended up implementing exactly the exceptions solution, but I think the natural transformation is the one I want (and I happen to be using servant).

I do think there's value in providing a class (Monad m) => MonadSpan m where inSpan :: (span arguments) -> m a -> m a, even if that ends up being implemented as something else.

authors: JonathanLorimer iand675 parsonsmatt


text:
How to programmatically toggle a tree node?

Question pretty much says it all. I need to toggle (close) the whole tree (or even better, a single node) following an event occuring outside the immediate tree scope. I've tried setting isOpen to false but that doesn't work. Ideally I could fire a "reset" prop method of some kind that automatically closes all open tree nodes.
Any help will be gratefully appreciated!

Just to clarify, I can leverage the existing reset method that exists as part of the Children props, but this only works within the scope of the tree:
            <TreeMenu                 hasSearch={false}                 data={data}                 initialOpenNodes={[data[0].id]}             >                 { ({ items, reset }) => (                     <React.Fragment>                         <button onClick={reset}>Reset</button>                         <ul>                             {                                 items.map(props => (                                     <ListItem                                         onToggleItem={onToggleItem}                                         onClickItem={onClickItem}                                         {...props}                                     />                                 ))                             }                         </ul>                     </React.Fragment>                 )}             </TreeMenu>

Figured this out. The answer is to surface the reset method up and out of the tree component, into a global space (I used Redux's Store, your mileage may vary). Then you can fire the reset prop wherever you like.

Thanks for sharing your solution. That's exactly what this library is designed for. By exposing the API inside of the component, you can freely control the behavior of the Tree Menu 😃

Any code example how to solve this?
I'm bit stuck where I need programmatically  open some tree branches in TreeMenu, but all I have managed so far is to change from "+" to "-" in front of tree, but chider won't open.

authors: JasonLunsford iannbing sanderaiaots

repo: iannbing/react-simple-tree-menu


text:
🎨 显示问题

这个2.0新版本，相较于之前的版本，就是一片白，有点刺眼，不象老版本的画面层次丰富，字体有粗有细，字的颜色有黑色、咖色，背景色是绿色，护眼效果比较好，字典、文本等等版块也更清晰……
——学员反馈

颜色问题不好解决。护眼的话先凑合用暗黑模式吧。

authors: bhikkhu-kosalla-china visuddhinanda

repo: iapt-platform/mint


text:
Deprecate multiple functions since Go 1.21

https://go.dev/blog/go1.21rc

Codecov Report

Merging #11 (c548123) into master (41f1163) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #11   +/-   ##
=======================================
  Coverage   83.47%   83.47%
=======================================
  Files           8        8
  Lines         230      230
=======================================
  Hits          192      192
  Misses         34       34
  Partials        4        4

Impacted Files
Coverage Δ

array/array.go
100.00% <ø> (ø)

maps/maps.go
100.00% <ø> (ø)


text:
If 10% then must accept in EBC

In the EBC judging screen, if the penalty box is ticked the rejects buttons should be disabled. Unticking the box re-enables the buttons

or should it be a separate button [Accept with penalty]

PercentPenalty now implemented as additional judging button. Applies/records penalty and closes as good decision.


text:
Add stop headsigns for flex

Checklist

[x] Appropriate branch selected (all PRs must first be merged to dev before they can be merged to master)
[x] Any modified or new methods or classes have helpful JSDoc and code is thoroughly commented
[x] The description lists all applicable issues this PR seeks to resolve
[x] The description lists any configuration setting(s) that differ from the default settings
[x] All tests and CI builds passing

Description
Add stop headsigns for flex now too. GTFS-lib PR for testing: https://github.com/conveyal/gtfs-lib/pull/373

Awaiting backend PR merge

repo: ibi-group/datatools-ui


text:
YYLabel的autolayout兼容问题

在同时使用YYLabel和autolayout进行编写图文混排界面的时候，目前发现只能使用那种把label的宽高都先计算的约束方式，不支持设定好内容然后根据内容自动计算宽高的功能。
而系统的UILabel是支持自动计算宽高的

更新到最新代码试试。
如果不行，设置一下 label.preferredMaxLayoutWidth。
如果还不行，取一下  label.intrinsicContentSize。

我是用的是pod上的最新版，0.9.11，而不是目前的1.0.2。
至少在0.9.11上面yylabel直接就不支持preferredMaxLayoutWidth这个属性，直接报错。原生的UILabel可以设置这个属性。
通过CGSize size = [label intrinsicContentSize];的方法发现在相同NSAttributeString的情况和约束下yylabel的size是
(width = -1, height = -1)
(width = -1, height = -1)，
而原生的UIlabel的size则是
(width = 153, height = 33.5)
(width = 153, height = 33.5)
第一次看到宽高还能为负数。。。
估计是因为这个导致的不显示吧

1.0 以前，不支持 AutoLayout。

那赶紧把cocoapods上的版本升级到最新吧

几天前就发布出去了：
http://cocoapods.org/?q=YYKit
http://cocoapods.org/?q=YYText
你该更新下 CocoaPods 列表了

我在终端运行
pod search yykit
-> YYKit (0.9.11)
A collection of iOS components.
pod 'YYKit', '~> 0.9.11'

Homepage: https://github.com/ibireme/YYKit
Source:   https://github.com/ibireme/YYKit.git
Versions: 0.9.11, 0.9.10, 0.9.9, 0.9.8, 0.9.7, 0.9.6, 0.9.5, 0.9.4, 0.9.3,
0.9.2, 0.9.1, 0.9.0, 0.2.0 [master repo]
Subspecs:

YYKit/no-arc (0.9.11)
``

我还以为一直没有更新呢，刚刚试了试直接运行pod update是正常的，可以升级，这个地方也更新一下吧

执行 pod setup 来更新本地列表

升级到1.0之后问题解决，可以支持autolayout了
还有就是我的意思是执行pod search yykit的时候仍然显示最新版本是0.9.11，这个地方请更新一下

搜索是 CocoaPods 自己本身的功能，我发布出去了，你没有搜到，那你应该执行 pod setup 来更新你电脑上的索引。这个，我是改不了的。。

多谢了，看来我还是不太明白cocoapods的原理。

authors: ibireme ldasein

repo: ibireme/YYKit


text:
子类序列化问题

子类在序列化json 时，无法带入父类属性！

Sorry!  我搞错了！

repo: ibireme/YYModel


text:
YYTextEditExample 当文字垂直时，可以试自左向右吗

YYTextEditExample 当文字垂直时，可以试自左向右吗

不支持。。
竖排版的标准就是从右到左啊：http://www.w3.org/TR/jlreq/

authors: AndyZhaoHe ibireme

repo: ibireme/YYText


text:
fixed readme typo from 2022 to 2023

merging from network labs clone

merge to fix typo


text:
Scrub credentials from the project

It would be a good idea to scrub credentials from this project. https://github.com/ibmets/rainbow-octopus/blob/master/RainbowOctopus/Assets/RainbowOctopus/Scripts/ConversationHandler.cs#L50-L53
Not sure if there are more instances of this.

Thank you - these are old - but I have removed the credentials, and replaced with xxx. Many thanks for raising the issue.

authors: kevinxbrown mediumTaj

repo: ibmets/rainbow-octopus


text:
Formatting config.js, updating image capture, allowing for continous conversation

update how microphone hardware is specified
remove preview from image capture to make it faster
add timeout param for speech to text in config. Remove continuous parameter to allow a callback get called each time there is a new transcript. this is important .
format config.js ... set config params within same json object.

Addressed the review comments.
merging.

repo: ibmtjbot/tjbotlib


text:
0.8.0 Feature List

[ ] Remove trailing slash functionality (https://github.com/ibraheemdev/matchit/issues/31#issuecomment-1588148126)
[ ] Switch to {x} syntax for route parameters (https://github.com/ibraheemdev/matchit/issues/23#issuecomment-1272107900, https://github.com/ibraheemdev/matchit/issues/17#issuecomment-1112830972)
[ ] Implement route normalization (https://github.com/ibraheemdev/matchit/issues/13).

I think I read a discussion about the new syntax before, this includes escaping { and } with {{ and }} just like in Rust's format! strings, right?

@jplatte yes. Catch-all routes will also be specified within the { } as /foo/{*wildcard}.

With {} parameters, we also run into more interesting conflicts. For example, given /{foo}.{bar} and /{foo}b{bar}, what does /ab.cd match? Both are /{ab}.{cd} and {a}b{.cd} are matches, but without a user-given priority the choice is unclear, so the routes should be considered conflicting.
There are two rules that I can see working for conflicts:

Only allow a single specialized pattern per route segment. e.g. /{foo} and /{foo}.{bar} is fine, but adding /{foo}b{bar} causes a conflict.
Allow multiple specialized patterns as long as they contain a different number of parameters. e.g. /{foo}, /{foo}.{bar}, /{foo}.{bar}.{baz} are fine, but adding /{foo}-{bar} causes a conflict. Specializations with a larger number of parameters take priority, e.g. /foo.bar.baz matches /{foo}.{bar}.{baz}, not /{foo}.{bar.baz}.

I'm leaning towards option 1 for simplicity's sake, and I'm not sure how much value option 2 would add.

Hey @ibraheemdev, could you use any help with this? Looks like we'll want to ship axum 0.8 sooner rather than later (maybe around end of Q1'24, but that's entirely my personal guess) and it would be great to have the new matchit with different routing syntax included.

@jplatte Thanks for the reminder. I have most of the work finished locally, just need to clean some things up. It should be done by then, if not I'll try to have a 0.8 release with the new syntax that's still restricted to the old conflict rules.

Hey @ibraheemdev, #49 will be part of this version? Or do you plan to release it later? It is a feature that I would really need for my lib socketioxide.

0.8 has been released! See the release notes for details.
@Totodore we can get #49 merged with a minor version bump now once it's ready that the major changes are out of the way.

authors: Totodore ibraheemdev jplatte

repo: ibraheemdev/matchit


text:
Convert script to OOP format

Convert the model code to OOP structure, for better readability and style.

Closed via (https://github.com/ibrahimsharaf/doc2vec/pull/19).


text:
关于Knot的各客户端数据无缝同步

特别提醒：新版(1.0.55之后的版本)的Android端Knot支持同步服务，其存储数据的目录结构发生了变化，在升级到最新版之前（比如使用的是1.0.54等旧版本），请一定先做好数据备份，以免升级到新版后造成数据丢失！！！
目前Knot支持数据同步服务，以“Syncthing”为例（推荐）：
https://github.com/syncthing/syncthing
下载“syncthing”各个平台的客户端，将同步文件夹设置为：
1.Android端：“KnotData”（内部存储）
2.桌面端：“用户”目录下的“KnotData”
设置完成，整个过程非常简单，其它网络同步盘各目录设置原理同上。
“KnotData”目录是Knot存储数据的专用目录，它仅供机器使用，请勿自行修改或删除里面的文件，以免造成数据丢失。
注：Knot桌面端还在不端完善中，界面和功能细节随时都有可能调整和更新。

😁

虽然说最终解决了同步问题但是用户却多下载了工具。

syncthing似乎没有安卓版。是knot安卓本身就是syncthing客户端呢？
ipfs不知道比这个同步工具？

也难为你一个人了。回头你去推广推广把。我试着分享过没效果。用的人多了功能完善的也快。你自己一个人维护也累的。

我大概的看了下syncthing入门。我还注意到syncthing没有发布安卓版。你是打算用knot手机版当作syncthing的安卓版本嘛？knot手机版和pc端syncthing同步。然后knot的pc端读取？

我还注意到syncthing没有发布安卓版

Android版本在此：https://github.com/syncthing/syncthing-android/releases/tag/1.22.2

你是打算用knot手机版当作syncthing的安卓版本嘛？knot手机版和pc端syncthing同步。然后knot的pc端读取？

不、不，Knot只是和它们驳接而已，两边数据的同步交给更专业的Syincthing
所谓的驳接，就是感知数据变动进行自我自动刷新的功能

也难为你一个人了。回头你去推广推广把。我试着分享过没效果。用的人多了功能完善的也快。你自己一个人开发维护也累的。

没事的，因为日常需要Todo和网络笔记等，之前用了很多类似的产品，感觉都不满意，所以才打算自己写一个，因为自己要用，会一直更新的

我大概的看了下syncthing入门。

这个使用简单，有任何疑问可随时留言
它的主页介绍里面有关于其它GUI平台的链接：https://docs.syncthing.net/users/contrib.html#gui-wrappers

@xp12047 一定注意要多多备份数据，以免调试过程中出现数据丢失

@xp12047 之前手机里装一堆软件，比如随手记、印象笔记、多看阅读、计步器等等，现在一个Knot全部搞定，更新会一直进行的，无关其他因素 当然也非常欢迎多提意见

好

@xp12047 一定注意要多多备份数据，以免调试过程中出现数据丢失

明白

你是打算用knot手机版当作syncthing的安卓版本嘛？knot手机版和pc端syncthing同步。然后knot的pc端读取？

不、不，Knot只是和它们驳接而已，两边数据的同步交给更专业的Syncthing 所谓的驳接，就是感知数据变动进行自我自动刷新的功能

明白，

我想说的是。这岂不是让手机更耗电了。又多装了一个app😐

这岂不是让手机更耗电了

经过实测，一点都不耗电，这个里面是有一些科学的策略存在的。 如果Knot自身做这些东西的话，也同样会采取类似的策略，比如以服务的形式常驻后台等等 但耗电量几乎可以忽略不计，就像Knot常驻后台一样的省电

哦。晚点回家试试。手机端那个同步工具也配置好了。

@xp12047 之后我相信你会非常喜欢这个同步工具，从电脑上往手机上或手机往电脑上倒东西实在是太方便了等等

@xp12047 之后我相信你会非常喜欢这个同步工具，从电脑上往手机上或手机往电脑上倒东西实在是太方便了等等

鞥，回头试试吧。但目前俺更喜欢ipfs

ipfs

这个真没接触过，有什么优点？能否同步文件呢

ipfs

这个真没接触过，有什么优点？能不能同步文件呢

我对它的认识也不多。备份可以，估计不好同步。星际文件

俺刚刚下载试了下。要说感受，除了有点慌。不大放心外没别的了。因为一开始没有和同步工具配置的时候。我先在pc端编辑了几个文字。后面手机端配对完成后，手机上面的内容把pc端的覆盖掉了。

@xp12047 是的，同步策略是新文件覆盖旧文件（废话，呵呵），在我实际使用过程中，它比那些网盘更省事和快捷
其实我用了很长时间的印象笔记，它的刷新速度还不如Syncthing，可能跟Syncthing首先发现本地网络有关
同步问题解决之后，欢迎有时间的时候多提提建议和问题

@xp12047 是的，同步策略是新文件覆盖旧文件（废话，呵呵），在我实际使用过程中，它比那些网盘更省事和快捷 其实我用了很长时间的xx笔记等APP，它的刷新速度还不如Syncthing，可能跟Syncthing首先发现本地网络有关
同步问题解决之后，欢迎有时间的时候多提提建议和问题

它这个不在同一个网络下，不知道可以不。

它这个不在同一个网络下，不知道可以不。

我没记错的话，当然可以，它支持远程，用它自己的服务器进行中转存储

@xp12047 是的，同步策略是新文件覆盖旧文件（废话，呵呵），在我实际使用过程中，它比那些网盘更省事和快捷 其实我用了很长时间的xx笔记等APP，它的刷新速度还不如Syncthing，可能跟Syncthing首先发现本地网络有关
同步问题解决之后，欢迎有时间的时候多提提建议和问题

俺以前用微信收藏或者，qq邮箱记事本。下过印象，但自从上了github外面那些非开源的基本不用了。

它这个不在同一个网络下，不知道可以不。

我没记错的话，当然可以，它支持远程，用它自己的服务器进行中转存储
你可以用手机流量测试下看看

我租的房子没宽带。电脑用的是手机热点。公司里的我用不了了。今天刚离职了。有空你给测试下吧

俺以前用微信收藏或者，qq邮箱记事本。下过印象，但自从上了github外面那些非开源的基本不用了。

其实那些软件也挺好的，但是用着用着就变味了，出现了各种限制。

俺以前用微信收藏或者，qq邮箱记事本。下过印象，但自从上了github外面那些非开源的基本不用了。

其实那些软件也挺好的，但是用着用着就变味了，出现了各种限制。

是的。

有空你给测试下吧

我刚才测试了一下，完全没问题。
当你关闭手机wifi时，它会询问你是否变更设置，你点变更设置，之后打开设置界面里的数据流量就可以了，片刻，手机就又找到你的电脑了，手机端的Knot todo改个东西，马上桌面端的Knot就有了

刚发现个同步问题。在手机端和pc端都有改动的情况下。如果没有启动同步工具，那么其中一方就会覆盖掉另外一方的数据。导致数据丢失。比如，我昨天在手机端记录了东西。今天刚好下载最新版，顺便在电脑上也记录了东西。然后我想同步一下吧。结果它把我手机端的丢掉了，也不好说是覆盖。我寻思着可能是我设置的同步中新文件优先导致的，然后设置了旧文件优先，同样也不行。除非同步开启。两方数据正常交叉。所以我觉得，当时提同步这个建议可能是个馊主意。方向好像偏了。

当时建议数据同步是因为领导开会时，有人抱怨微信信息过多看不过来。领导说先标注未读然后...我觉得这不就是待办嘛。刚好knot这个更新速度让我感动。但是待办要是一直在手机端记显然不够方便。像他们那种天天要用电脑的。
当把笔记也一块同步的时候我觉得也很好。问题是就上面所说，不开同步。两端都有变动的话，会造成一方数据丢掉这就会很麻烦。

我觉得你是否考虑，重新回到云端备份。我能想到的是webdav，这个协议的东西我以前只用过一次。我的想法是pc端更改完webdav，手机端也是这样。但倘若其中有一端忘了webdav，是否也跟同步工具一样造成丢失。或者两端都操作后，它会有怎样的文件排序在各端下载后。

@xp12047 是的，如果同步，则必须始终开着Syncthing，否则双方的文件“冲突”不太好处理，一般机器处理都是用新的覆盖旧的
关于这些问题，我也在思考，同时欢迎随时提供一些算法思路，比如网上找的有参考价值的资料等等

@xp12047是的，如果同步，则必须开始终着Syncthing，否则双方的文件“冲突”不太好处理，一般机器处理都是用新的外壳盖旧的
关于这些问题，我也在思考，同时欢迎随时提供一些计算方法，比如网上找的有参考价值的资料等

好

@xp12047 给你推荐一个  https://github.com/laurent22/joplin

@xp12047给你推荐一个 https://github.com/laurent22/joplin

鞥，这个很早我就用过，它有些问题我不满意，忘了具体什么问题了。但看的出来knot同步跟它的同步类似如果我没记错的话。我昨天还专门去看了下它的同步原理。后面慢慢我也就知道你会啥执意用同步工具了。在用同步工具比起joplin的方式是方便了些。我最近在想，ankidroid的同步服务器它是有人花钱买的嘛？即时不花钱也能用。我不太懂它是咋操作的。

我的意思是，ankidroid用户很多。但用户都可以和网页端同步数据，只需要登录它的网站。它服务器的钱？
关于那个同步工具我觉得也还行就是麻烦。首先在没有配对的情况下只能在一端修改数据然后另一端同步。或者配对完成后两边都可以更改同步。还要再去单独下载同步工具。

那个joplin我没记错的话它虽然没用那个同步工具，是备份到云端，然后放到它的文件夹。但它提到那个同步工具好像。

请求把win客户端体积缩小，同步问题也优化不少了。那么体积的问题给解决下吧。

请求把win客户端体积缩小，同步问题也优化不少了。那么体积的问题给解决下吧。

好，后面会继续优化和完善的，不过你看看joplin的客户端体积，立马释然了

请求把win客户端体积缩小，同步问题也优化不少了。那么体积的问题给解决下吧。

好，后面会继续优化和完善的，不过你看看joplin的客户端体积，立马释然了

所以我没用它。

我发现我搞错了。无论有没有配对。都只能改动一边，另一边同步。并非在同步工具配对的情况下。两边都改动它会同步，它只能同步一方改动的。哎。

我发现我搞错了。无论有没有配对。都只能改动一边，另一边同步。并非在同步工具配对的情况下。两边都改动它会同步，它只能同步一方改动的。哎。

joplin？

我发现我搞错了。无论有没有配对。都只能改动一边，另一边同步。并非在同步工具配对的情况下。两边都改动它会同步，它只能同步一方改动的。哎。

joplin？没太明白你的意思，Syncthing不存在这个现象
可能还有其它的类似Syncthing的同步工具，空闲的时候都可以找一找，看看哪个最理想

是knot。一开始记得我试过，只要syncthing的pc端和手机端链接好。两端都改就可以进行同步。但这是有个前提，修改后的无论那一端得先同步。syncthing算是最好的了我都看了至少在开源这上面。我还得再说一遍。有一方数据变动就得同步。如果忘了又改了另一方的数据再进行同步，那么有一方的数据就没了。而且我发现个安卓版和pc版syncthing同步的时候，安卓得打开，安卓挂后台都不好用的。不然它也同步不上。

建议后面有时间让knot支持webdav协议吧。

有一方数据变动就得同步。如果忘了又改了另一方的数据再进行同步，那么有一方的数据就没了

所以这就是Syncthing存在的价值了，它总是在最短的时间内解决同一个的文件的内容冲突。

而且我发现个安卓版和pc版syncthing同步的时候，安卓得打开

这是肯定的，否则安卓如何和桌面端的Syncthing通信呢？

安卓挂后台都不好用的

你的手机需要设置一下，不同的手机，设置方法不同。
比如我的华为手机，需要在“应用启动管理”里面将Syncthing设置为“手动”并开启自启动等三个选项，否则息屏后过段时间，安卓系统会自动杀掉这个后台，这样的话实时同步就无从谈起了，因为安卓端的Syncthing已经停止运行了。

建议后面有时间让knot支持webdav协议吧

好的，Knot将会不断发展的

@xp12047 桌面端将Syncthing设置为开机启动，手机端设置系统别杀掉Syncthing这个后台，这样才能保证数据的实时同步和更新。

安卓挂后台都不好用的

你的手机需要设置一下，不同的手机，设置方法可能不同。 比如我的华为手机，需要在“应用启动管理”里面将Syncthing设置为“手动”并开启自启动等三个选项，否则息屏后过段时间，安卓系统会自动杀掉这个后台，这样的话实时同步就无从谈起了，因为安卓端的Syncthing已经停止运行了。
我记得OPPO手机是“电池优化”，其它品牌就不太知道了，总之就是设置安卓系统别杀掉某个后台APP即可。

我的也是华为的，mate20，该设置的都已经设置了。也没有杀死后台。同步的时候要打开那个同步应用，即时没有关掉它的后台也不行。要在syncthing的界面上才能同步。比如我打开后让它留在后台切到了knot做笔记。那么我同步的时候得切回到syncthing上，不然不能同步。

安卓挂后台都不好用的

你的手机需要设置一下，不同的手机，设置方法可能不同。 比如我的华为手机，需要在“应用启动管理”里面将Syncthing设置为“手动”并开启自启动等三个选项，否则息屏后过段时间，安卓系统会自动杀掉这个后台，这样的话实时同步就无从谈起了，因为安卓端的Syncthing已经停止运行了。
我记得OPPO手机是“电池优化”，其它品牌就不太知道了，总之就是设置安卓系统别杀掉某个后台APP即可。

我的也是华为的，mate20，该设置的都已经设置了。也没有杀死后台。同步的时候要打开那个同步应用，即时没有关掉它的后台也不行。要在syncthing的界面上才能同步。比如我打开后让它留在后台切到了knot做笔记。那么我同步的时候得切回到syncthing上，不然不能同步。

我在设置设置看看把。我刚仔细看到你把自动改为手动了。我试试，这个我之前没这样设置过。谢谢😊

可以了，原来是我没设置好。我说咋用起来怪怪的。完全没有你说的那么好用。结果是要改成手动。。谢谢😊
这个问题你要不要先关闭，有点长了吧。

结果是要改成手动

对于Knot，你也可以同样改下，这样Knot就可以常驻后台，运行效果高，不用每次都打开它重头加载，Knot是没有任何后台活动的，更不用担心耗电问题。

结果是要改成手动

对于结，你也可以同样改下，这样的结就可以常驻后台，运行效率高，不用每次都打开它重载，结是没有任何后台不动的，更。

哦。pc端的页面给改下吧，太丑了。

pc端的页面给改下吧，太丑了

目前的PC端，是完全基于移动端改装的，这样时间成本最小、最省事。
关键是我不会美工，连个图标都不会画，都是网上找现成的，如果有美工能参与到这个项目就非常Ok了。
你可以画一个界面或者设计一个界面，我有空的时候，看看能否实现它。
总之，Knot会不断完善和发展的。

pc端的页面给改下吧，太丑了

目前的PC端，是完全基于移动端改装的，这样时间成本最小、最省事。 关键是我不会美工，连个图标都不会画，都是网上找现成的，如果有美工能参与到这个项目就非常Ok了。 你可以画一个界面或者设计一个界面，我有空的时候，看看能否实现它。 总之，Knot会不断完善和发展的。

额...我也不会美工


text:
Crash on iOS 16 and Xcode 14

This loader was working fine in iOS 15 but recently I had updated my Xcode 13 to Xcode 14 and iOS 15 to iOS 16 and getting the following crash:
Thread 52: "Modifications to the layout engine must not be performed from a background thread after it has been accessed from the main thread."
I am getting this error in the Swift Spinner class on line 171

containerView.addSubview(spinner)

Following is the link of the pic of the crash:
https://ibb.co/fHbGP9z

Hey @Taimoor20 I just tested the demo app and everything is working correctly. My best guess is that you are calling show from a background thread, you might want to double check your code and eventually wrap that call in a block called on the main thread instead, something like:
DispatchQueue.main.async {
  SwiftSpinner.show(delay: 0.5, title: "Hello world", animated: true)
}

Thanks, it works.

repo: icanzilb/SwiftSpinner


text:
Multiline text input

It should be possible to allow line breaks in a text input (probably not by default though).

That would be cool.

TextArea

?

FYI: https://www.reddit.com/r/rust/comments/i9q5nt/kas_gui_toolkit_v05/
Hopefully kas-text is suitable for integration into other GUI toolkits too. Though @hecrj may already be working on something?

Closing in favor of #320.

authors: aisq2008 dhardy fenhl hecrj teymour-aldridge

repo: iced-rs/iced