Topic management via CRD

Describe the solution you'd like to see
It would be useful if topic management could be configurable via CRD

Strimzi is doing this well... not sure if something more complicated is needed ?
Been using Kafka for years and never had to use more tweaking that what is presented in https://strimzi.io/docs/latest/#type-KafkaTopic-reference
At least it would be a starting point

Anyone working on this ?

Hi @prune998, thanks for asking. Currently we have higher priority features please check the roadmap for more details.

@baluchicken FWIW I am working on a kafka on Kubernetes implementation right now just using helm's incubator/kafka hacked up to properly support SSL (and disable PLAINTEXT). I wanted topic/user mgt via CRDs and wrote a sidecar operator that can handle them using operator-sdk and talking to the brokers via sarama.ClusterAdmin.
It could probably be easily plugged into this project either also as a sidecar to the clusters, or since it's already go scaffolding for the most part, it could also be lifted into the main operator I think. It currently gets its broker URL and TLS config from environment variables and a mounted secret, but if it were to be brought into the main operator it would probably make more sense to get auth information per event directly from the cluster CRDs and secrets (using a clusterRef from the KafkaUser/KafkaTopic CR specs or something).
The operator assumes a cert-manager issuer backing the SSL for users but it could be refactored to point at some other TLS provider. I have another tiny operator that can inject a cert-manager certificate-secret with JKS format (I use it for the brokers), but I can't decide if that's really needed or where it's final home would be. I haven't paid any attention to SASL as an option.
Maybe we can help each other out and then I could move to using a cluster that is a lot more impressive than my current setup, but still have my CRDs for CI/CD 😛 . I can put the controller on my Github, but I'd probably want to rename the apigroups and stuff first. If you'd like me to submit a PR I'd be open to any design changes you all recommend.

To follow up, I decided to just fork and give a go at merging my stuff into this operator. I managed to get it working and if you'd be open to a PR I can definitely get one started.  The fork is here: https://github.com/tinyzimmer/kafka-operator
A few main things to note:

I added support for the user to specify KafkaCluster.Spec.ListenersConfig.SSLSecrets.Create. This will create a full PKI for the cluster and clients using cert-manager.
A cert-manager ClusterIssuer is made from the user-provided secret if the above is false. I understand this would make cert-manager a core dependency and I was possibly going to look into giving the controller the logic to generate and sign certificates instead.

In regards to the additions, here are a few sample CRs for the two new resources I add:
apiVersion: banzaicloud.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: test-topic
  namespace: kafka
spec:
  clusterRef:
    name: kafka
  name: test-topic
  partitions: 6
  replicationFactor: 2
  config:
    "retention.ms": "800000"
    "cleanup.policy": "delete"
    # ... etc, etc
---
apiVersion: banzaicloud.banzaicloud.io/v1alpha1
kind: KafkaUser
metadata:
  name: test-kafkauser
  namespace: kafka
spec:
  clusterRef:
    name: kafka
  name: test-kafkauser
  secretName: test-kafkauser-secret
  includeJKS: true
  topicGrants:
    - topicName: test-topic
      accessType: read
    - topicName: test-topic
      accessType: write

If you would be interested in a PR, I'd be happy to make any fixes and changes y'all recommend. I do know I'd want to clean up a few places first. For example, the cruise control resource having it's own topic logic is no longer necessary, and there is some code left over from when I originally ran it as a sidecar to a cluster.

You should make a PR right away (when you are ready, or create it  as WIP). I know this subject is not the top priority right now, but I'm sure there will be someone to review your code (and I will do too).
At least it will give an option for others (like me) until it is reworked or merged into master.
Thanks for your work !

I'll clean it up a bit more then open a PR as a WIP. I know at the very least I'll probably need to create some user documentation and stuff to go along with it.

Thanks for deciding to fork and contribute this.

Thanks for doing this @tinyzimmer


Change long worker initialization order

Closes: https://github.com/metarhia/impress/issues/994

Landed in c773de1


cephfs admin: doc comment improvements for clone

Improve the docs for CloneSubVolumeSnapshot.
Checklist

[x] Added tests for features and functional changes
[x] Public functions and types are documented
[x] Standard formatting is applied to Go code

@ansiwen this is based on your feedback on the other PR. Let me know if it improves things!


Client cannot read a string value

Hi, sorry for my english.
In the attached file there is my web api documentation.
API documentation.txt
I use NSwagStudio to create the client and the configurations are in the attached file.
InventorServiceClientCreator.zip
When I run my web api and use /swagger page I can use correctly the function http://localhost:20041/api/PreparazioneAllaConversione_Crea_ and it returns a string.
When I use the funcion by generated client in c# I get every time 2 exceptions

ApiException: Could not deserialize the response body stream as System.String.
JsonReaderException: Unexpected character encountered while parsing value: a. Path '', line 1, position 1.
but the returned code is 200 (all correct).

I tried to change the returned string and I returned a numeric string like "666" and all works if I return "hello" I get the error.
I can't understand what is happening
Thanks a lot

Hi, I have the same problem.
When my api return a simple string, the generated client try to parse it and of course generate an error.
Here's the line in question: let resultData200 = _responseText === "" ? null : JSON.parse(_responseText, this.jsonParseReviver);.
As a solution, I just created a simple class with a string property that I return instead of the simple string. Kind of durty, but it works. Someone has a better solution maybe ?


Hash common fields for message propagation

The most significant offender here is ECChain, which is the same (or similar) for many messages and can end up large.
The idea is to hash the ECChain before sending the message and let the receiver resolve it from the hash.
In many scenarios, we will know which ECChain corresponds to the hash because we will have the same one, but for the less common case, we need to propagate these ECChains through pubsub. This can be done on a separate topic (or maybe even on the same topic).
That propagation channel should limit the propagations to only the current instance, so the ECChain message should carry the instance number.
There are a couple of architectural questions:

Should GPBFT be aware of it, or should it continue to operate on GMessage as it is today?
Decision: GPBGT should be unaware
What should we do with messages that ECChain hashes we cannot resolve?
Decision: Buffer them, and the queue should reconstitute them when ECChain arrives. Have a metric about it.
How do we limit the ECChain lookup buffer?
Partial decision: Hard limit, but we need strategies to keep important ones if we get to the limit.
Do we need a separate topic, or is it better to use the same one?

Notes:
After receiving an ECChain, we should add all prefix chains to the lookup buffer. This provides more information and improves efficiency. We should also preload the buffer with our own ECChain.
### Tasks
- [ ] Keep things running but propagate the ECChain separately as well
- [ ] Message queue reconstitutes messages when ECChain arrives, have a metric on how many messages are in that state
- [ ] Decide on separate or common topic
- [ ] Implement ECChain hash lookup buffer
- [ ] Figure the signals from GPBFT to the hash lookup buffer

Summary of discussions in standup:

Because the chains advertised in QUALITY phase are the superset of values that could ever be decided in an instance, we could limit publication of ec chains to QUALITY proposals only.
Each node can then calculate the hash of every prefix of those proposals to then infer other hashes that the instance may be swayed towards.
This then means we do not need to change the chain that is being broadcased on the ec chain topic relative to the gpbft progress.

what is your take on question No. 4? Do you think it's better to separate the topic or use the same one with a message ID function that's smart enough?

IMO, use a separate topic. Having to decode messages in the message ID function is, IMO, a bad idea in general. But I don't feel strongly about this.

Should GPBFT be aware of it, or should it continue to operate on GMessage as it is today?

Don't we need quality information to support the ECChains? Otherwise, an attacker can just spam EC Chains and force everyone to store every possible EC chain because they'll have no idea which ones are actually useful.
That is, I think what we need is an extra phase after quality.

Don't we need quality information to support the ECChains? Otherwise, an attacker can just spam EC Chains and force everyone to store every possible EC chain because they'll have no idea which ones are actually useful.

We can limit it and discard chains aggressively after quality.

I don't really see how to do this securely (e.g., a flood can easily mask all real values). Especially before/during quality.
Are we relying on some form of continuous rebroadcast?

You are correct that it is tricky, but I think it is possible with code that is defensive enough.
Some raw thoughts:

wait to expand the ECChain into sub-hashes until the ECChain reference appears in a GMessage. This significantly reduces the memory amplification the spam adversary can get.
proactively notify ECChain receiver that we are looking for some ECChain hash based on a mostly valid GMessage, so even with a significant spam, we can pick out good values if they get re-broadcasted

This significantly reduces the memory amplification the spam adversary can get.
proactively notify ECChain receiver that we are looking for some ECChain hash based on a mostly valid GMessage, so even with a significant spam, we can pick out good values if they get re-broadcasted

How would we know if a message is valid at all. Not knowing the chain when GMessage arrives opens up another attach vector about invalid messages that cannot be validated fully until hashes arrive. The adversary can also immediately publish both gmessage with the hashes and the value associated to it across both topics.

An alternative design:

Keep the QUALITY messages as they are: include full chain in the QUALITY message. That phase has a timeout + early completion on strong quorum of proposal.

On receipt of a QUALITY message, each node would calculate sub-hashes of the chain it has received.

From then on, consecutive messages as successive phases would use hash of the chain only.
Nodes that have received the QUALITY messages can infer every hash they see from then on.
Nodes that have not would rely on QUALITY re-broadcast to receive them and can only progress wit base decision until they do so.

If they never receive the QUALITY message then base decision is most likely the right decision anyway? considering the prior assumption is that no quorum of proposal for QUALITY phase was possible from the point of view of those nodes.
If they do then they will proceed with the regular swaying etc. as implemented today.

No secondary topic required.

 The catch, of course is: larger messages in the QUALITY phase. This approach in terms of bandwidth consumption would certainly be far better than what we have today.
Now, the question would become: would the QUALITY phase in this scenario be efficient enough to not put us back at square one considering the sensitivity of gpbft progress to it? I think yes (but we can test this). Because:

We now have compression which should reduce the size of QUALITY messages significantly
Because successive phases use far less bandwidth the chances are QUALITY rebroadcasts will get delivered more effectively.
If still not sufficiently omptimised, we have the option to introduce a dedicated timeout for QUALITY phase that is independent of Delta.

In passive testing I did observe that with high delta quality phase did not wait for full delta timeout and indeed progressed once finding strong quorum of proposal. Which leaves me to believe that congestion as a whole played a bigger role in the lack of overall instance progress. Data is there we can analyse it more closely to say for sure this was the case.

From @masih: We have data on how quality has progressed. Was it sooner than delta, then the quorum was reached.
Or also differently, round 0 prepares with the non-base proposal.

The investigation into Quality and Prepare messages revealed that we could not reliably propagate quorum of large Quality messages within 3min.

Here is an example query to use in terms of checking to what extent propagation of QUALITY messages was an issue:
SELECT DISTINCT (Vote).Instance
FROM messages
WHERE (Vote).Phase = 'PREPARE'
  AND (Vote).Round = 0
  AND array_length((Vote).Value) > 1
  AND networkname = 'filecoin/45'

The issue we have with the data is that only network 44 progressed at a reasonable velocity past bootstrap and left to run at scale for a day. In that network the delta was sufficiently large to dilute the answer to the question being asked.
So we are back at investigating how to combat the spam attack vector in the 2-topic design.

Summary of discussions from standup:

We have two topics: one as is for gmessage, and one that is dedicated to propagation of ECChain values.
The gmessages contain the hashes of the values, and need to discover what ECChain they correspond to in order to fully validate a messge; but messages can partially be validaed without the mapping.
The participant maintains a map of hash -> ECChain with a capped size (actual size TBD but small enough to not risk memory exhaustion)
The map gets populated as ECChain mapping messages on the secondary topic arrive... but once a gmessage arrives for a known hash, the priority of hash -> ECChain storage for that hash increases:

Effectively, the participant prioritises on storing the mappings that it knows it needs to know because of the presence of a gmessage.
In the absense of gmessages mapping storage of all other hashes is opportunistic.

If there was a hash that was indeed useful but got evicted before gmessage arrived, then we will primarily rely on re-broadcast of messages on the ECChain topic to find out about it.

 Therefore, it does not matter who we hear the hash mapping from as long as there is someone who publishes it and it eventually gets to us.
Re-broadcast interval/intensity in the ECChain topic must be determined relative to delta, such that ideally ECChain messages arrive before the phase end within an instance.
To work around pubusb deduplication the broadcasted messages contain a rounded timestamp in addition to instance + ECChain. No messages from a future timestamp are allowed and will be rejected.

This is to protect against an advanced adversary trying to exploit the order of ECChain message arrival  such that a participant can never learn the true chain by dropping good ECChain messages too quickly once the buffer is full.

The priority of mappings stored in the capped buffer changes depending on the arrival of gmessages: a seen hash has higher priority in storage than an unseen one. This can be further optimised by taking into account the current phase, and its proposal.
As redundancy measure, when gpbft rebroadcasts a gmessage, its corresponding ecchain will also be rebroadcasted.

note that upon arrival of quality ecchain sub chain hashes can be calculated locally. but we do re-broadcast chains just for resilience.

I'd like to tackle all the spam vectors we currently have, not add more. But as long as we have rebroadcast, this should work.

Re-broadcast interval/intensity in the ECChain topic must be determined relative to delta, such that ideally ECChain messages arrive before the phase end within an instance.

Why?

The priority of mappings stored in the capped buffer changes depending on the arrival of gmessages: a seen hash has higher priority in storage than an unseen one. This can be further optimised by taking into account the current phase, and its proposal.

I'm confused. Either we know we need it or we don't know we need it. If we need it, we shouldn't put it into some space limited cache, we should save it permanently. This permanent storage will be limited to 100 tipsets per valid participant.

Honestly, I'm convinced we should do one of:

Masih's proposal to send tipsets only in quality but optimized further to only send the hash of each tipset (max 3200 bytes).
Do quality first, then broadcast ECChains. This will cost an extra round but will solve the spam issue entirely. I assume we'll also be able to reduce the delta if we do this, so it may not actually cost us any extra time.

Direct responses, I will think about your proposed options.

Re-broadcast interval/intensity in the ECChain topic must be determined relative to delta, such that ideally ECChain messages arrive before the phase end within an instance.

We need to resolve ECChains within the quality round otherwise everyone could PREPARE on base.

I'm confused. Either we know we need it or we don't know we need it. If we need it, we shouldn't put it into some space limited cache, we should save it permanently. This permanent storage will be limited to 100 tipsets per valid participant.

We expect very few ECChains per instance, which protects against an adversary who is a sybil-ed participant. The upper size of the cache could be smaller than 100N. However, participants can also get swayed, so it would probably have to be 100 N* Rounds* Phases if we had it on a per participant basis.

We need to resolve ECChains within the quality round otherwise everyone could PREPARE on base.

After quality, before prepare.

We expect very few ECChains per instance, which protects against an adversary who is a sybil-ed participant. The upper size of the cache could be smaller than 100N. However, participants can also get swayed, so it would probably have to be 100 N* Rounds* Phases if we had it on a per participant basis.

It protects against nothing because we have ho idea which ECChains are valid and which are invalid. What am I missing here?

What if we took a hybrid approach and only split out the chains during catch-up, including them in QUALTIY otherwise? Basically:

If we have more than N tipsets in quality, perform quality on a hash.
If at any point we see 2/3rds of the power vote for some hash, we start an ECChain round.

I haven't thought this through completely so I know there are likely some hidden complexities, but I don't think it's any more complex than the current proposal.

It protects against nothing because we have ho idea which ECChains are valid and which are invalid. What am I missing here?

During quality, we learn which chains are valuable, so we proposed this "within-phase rebroadcast". During normal operations, ECChains land in the buffer, and are used by quality messages. If an adversary decided to spam, we get GMessage, we don't know it's ECChain, we note the hash of it until first round of ECChain rebroadcasts hits then we are able to resolve the ECChain hash and proceed.
Each time an ECChain proves useful in a valid message, its priority would get bumped up, so it won't get discarded. That is to protect against 30% adversary that decided to start spamming valid GMessages, each with unique ECChain.

If at any point we see 2/3rds of the power vote for some hash, we start an ECChain round.

I don't see what exactly that buys us, it is all the complexity, plus more with having to support both ways of doing things.

Honestly, I'm convinced we should do one of:

Masih's proposal to send tipsets only in quality but optimized further to only send the hash of each tipset (max 3200 bytes).
Do quality first, then broadcast ECChains. This will cost an extra round but will solve the spam issue entirely. I assume we'll also be able to reduce the delta if we do this, so it may not actually cost us any extra time.

Re 1. I will look if we can convince ourselves that the gain there will be significant enough to solve the bandwidth, it could be an option, although it brings in a lot of the complexity of having to communicate hashes for smaller gain.
Re 2: That would remove the fast-forward in quality, but it should be okay if it allows us to bring the delta down.

Each time an ECChain proves useful in a valid message, its priority would get bumped up, so it won't get discarded. That is to protect against 33% adversary that decided to start spamming valid GMessages, each with unique ECChain.

But it's not possible to spam quality messages.

Each time an ECChain proves useful in a valid message, its priority would get bumped up, so it won't get discarded. That is to protect against 33% adversary that decided to start spamming valid GMessages, each with unique ECChain.

I'm still not understanding the probability part of this. Either it's included in a valid quality message and is therefore required or it's not and is therefore spam.

If at any point we see 2/3rds of the power vote for some hash, we start an ECChain round.

I don't see what exactly that buys us, it is all the complexity, plus more with having to support both ways of doing things.

My main proposal is to run a quality round first, collecting at most one quality message from all participants. Then run an EC chain round, accepting all EC chains that match hashes we expect from the quality round. This avoids having to try to "guess" which EC chains are valid and completely solves all the spam issues.
Unfortunately, this means adding an additional round. We can avoid that additional round by including short ECChains inside quality messages, skipping the ECChain round if it looks like it's unnecessary.

While we are finalising the design, I am going to start work on this by implementing hash based gpbft messaging and wiring in the on-the-side lookup from hash to chain.

My main proposal is to run a quality round first, collecting at most one quality message from all participants. Then run an EC chain round, accepting all EC chains that match hashes we expect from the quality round.

This makes sense to me. My thoughts:

Most likely we want some chain-rebroadcast still in case the chain does not get through the network in time.

Shortcut: Instances can progress without  any propagation of chain if:

The hash is known to the current node, i.e. is the hash it has proposed to the network.
There is a strong quorum for that hash.

For nodes that do not know the hash, the can blindly proceed with the instance as long as they observe strong quorum for the hash as required by GPBFT, and there is no swaying mid instance. They can then learn about the mapping of hash -> chain via cert exchange.

Another idea: Utilise the cert polling mechanism but for chain, as a look-aside lookup to map a hash to a chain proposal.

GPBFT message progress/propagate as they are, with one exception: ec chain proposal is replaced by its hash.
In parallel, nodes poll chains from one-another. to fill the gaps in the lookup table of hash -> chain.
Because it is the nodes that poll, we have control over what to ask, when to ask it etc. So nodes can be highly optimal on what they ask based on the progress of GPBFT and what they observe of the network.

The polling candidate selection can be further optimised by asking nodes that sent GPBFT messages containing the hash, i.e. an implicit assumption that if a node sends a GPBFT message containing a hash it must know the chain that corresponds to it.

This way:

no modification to core protocl is necessary: we treat an "unknown mapping of a hash -> chain" simply as "message has not arrived yet".
... with the caveat that we can potentially shortcut things similarly to what I proposed in my previous comment above (but this could totally be a YAGNI; keep reading).
no spamming, because we poll.
I think it could potentially be more efficient than any of the designs suggested so far.
This could work with the existing delta values because of parallel polling of chain. And if it does not, the tunning knob to adjust it is simple: increase delta to give time for parallel polling to do its job.

If still not enough, we can increase the degree of parallel polling based on some node selection heuristic (e.g. historical latency, participation in signed certs and so on).

In parallel, nodes poll chains from one-another to fill the gaps in the lookup table of hash -> chain.

This one small point encapsulates a lot of complexity and possible latency.

encapsulates a lot of complexity and possible latency

I'd like to flesh those out in the standup and dig deeper into the comparison between approaches.

Most likely we want some chain-rebroadcast still in case the chain does not get through the network in time.

I agree.

Shortcut: Instances can progress without any propagation of chain if:

As long as it doesn't introduce timing issues... I think it's fine because we need to see a strong quorum of votes to time out in prepare. Although it does increase our chances of failing in prepare (slightly).

I can get behind an extra phase, or maybe an extra long quality round, as ECChains "round" could be transparent to gpbft.

I think we can do that. Basically, have a separate module that receives both quality messages and EC Chains:

Each time it receives a quality message, it records that we've received a quality message from that specific participant for the instance to prevent spam.
If the quality message has no known chain, it buffers it and waits for an EC chain.
Each time it receives a chain, it looks up any quality messages waiting for said chain. If found, it records the chain in the set of known chains and immediately forwards any buffered quality messages. Otherwise, it drops the EC chain and relies on rebroadcast later.
Finally, after some timeout (delta?), this module broadcasts the EC chain from our proposal if we didn't send it inline with the initial quality message.

This should be fine because PREPARE will pause until we receive some quorum, or evidence that we cannot reach quorum.

2024-12-18 (some) standup notes:

@masih 's goal before winter break

PRs with having all the pieces of the design in place
Stretch goal because of complexity in the "buffer area"
Reason want this: tease out any unknown areas of the design and let it simmer over break.

@Kubuxu taking on the https://github.com/filecoin-project/go-f3/issues/785 portion


Enable copying folder properties to the share root.

This is a PR that I expect to cause a little debate.
The functionality, I believe we're all in agreement on. However, the naming of the flag & description are questionable.
I went through a couple different ideas for the flag's name:

--rename: Quite literal, but might mislead a user into thinking that it's a cut&paste type operation
--dest-is-target: Wordy, doesn't deliver it's point
--copy-into-destination: Similarly wordy, similarly doesn't get the point across.
--share-root: At first glance, this seemed offputting-- This operation isn't ONLY for copying to the share root. However, thinking past the technical term, I realized that it's quite fitting-- The root is literally being shared, as in, this is just a merge into the destination folder, not a new folder.
--as-subdir=false: The default (true) demonstrates present activity (placing directories as subdirectories) and the opposite functionality (treating the destination as the target) in the name

Killed the sync functionality since it requires a bit more work for testing & I don't have the time to fix it up. We'll get it in another PR.


[Refactoring] deferred is necessary only for nested functions in unittests

This is very trivial refactoring.

Thanks. I'll start to implement it.

@9rnsr Did you ever make any progress on the re-write?


[Feature] Unify Transaction and TransactionResponse trait

Component
consensus, eips, genesis
Describe the feature you would like
trait TransactionResponse: Transaction {
  // fns for block context
}

ref
https://github.com/alloy-rs/alloy/pull/1328#issuecomment-2368079765
cc @garwahl
Additional context
No response

Yep I'll take this


Windows 10 box can't be built with Windows Updates disabled

Attempting to create a Windows 10 box with Windows updates disabled will result in a failed build. The compile-dotnet-assemblies.bat script needs the .NET updates that are currently available. Leaving the updates enabled will result in a successful build.

Fortunately the happy path is to install Windows updates, but that can be frustrating when trying to debug. I'm not sure there's anything we can do about this, but this issue documents the problem and "workaround".
@avtar If there's something more specific you think we should do here, LMK.


node: LengthFeeAdjustment chain spec fix

Current dependencies on/for this PR:

main

PR #237   👈

PR #230

PR #235

This stack of pull requests is managed by Graphite.

seems outdated (changeset is already present in main)


Debug events by displaying stack traces for events

This PR adds the feature of debugging events by displaying stack traces for the handlers it calls. It implements #90. The feature is heavily inspired and based on how Sciptable Object Architecture does the same thing, so credits to Daniel Everland for that.
The stack event looks like this in the editor for events:

This feature is by default turned off (because of the performance penalty of using it). The feature can be turned on via Unity's preferecnes:

Another thing to note is that all stack traces are stored in a static variable in a static class. All calls for adding stack traces are toggled with the compilation flag UNITY_EDITOR. The reason for this is to eliminate any penalty at runtime of your build for using this feature.

Another thing to note is that all stack traces are stored in a static variable in a static class. All calls for adding stack traces are toggled with the compilation flag UNITY_EDITOR. The reason for this is to eliminate any penalty at runtime of your build for using this feature.

might want to use https://docs.microsoft.com/de-de/dotnet/api/system.diagnostics.conditionalattribute?view=netcore-3.1

might want to use https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.conditionalattribute?view=netcore-3.1

Didn't know about this one. Think what we do is basically the same, but nice to know about conditional attribute for the future.

for random id's you could generate a UUID instead of a random int

The PR is using the GetInstanceID() of the Event (Scriptable Object) as key for the stack traces. This should be sufficient in my mind.

I havn't yet found time for a proper review, just glimpsed over the code, what i meant with random is here:
https://github.com/AdamRamberg/unity-atoms/pull/159/files#diff-887e1b37c3ef84c706d938bed14496c5R16

I havn't yet found time for a proper review, just glimpsed over the code, what i meant with random is here:
https://github.com/AdamRamberg/unity-atoms/pull/159/files#diff-887e1b37c3ef84c706d938bed14496c5R16

Aha, that makes sense! Just pushed a new commit using GUID instead of a random int. I also changed the Label in the detailed stack trace view to a read only TextField, which makes it possible to copy and paste the stack trace.

@soraphis What do you say? Good to merge?
FYI. When this PR is OK:ed I'm planning to release v4.2. Let me know if there is something else we need to get in before making the release.

Since there've been activity in quite some time on this one I will merge it to canary.


Player falls through floor when riding cable car

Expected Behaviour
Player enters cable car and stays with it as it moves.
Actual Behaviour
Player enters cable car and falls through the floor, unable to ride the car.
Reproduction Steps

Enter cable car in multiplayer and soemtimes fall through the floor.

Screenshots
If applicable, add screenshots to help explain your problem.
Environment
Server

Minecraft Version: 1.16.5 Forge Server
Installed Mods:
• minecraft forge-1.16.5-36.2.34-server.jar : minecraft (1.16.5) - 1
• mods_folder elevatorid-1.16.5-1.7.13.jar : elevatorid (1.16.5-1.7.13) - 1
• mods_folder Dynmap-3.4-beta-3-forge-1.16.5.jar : dynmap (3.4-beta-3-774) - 1
• mods_folder Orva+Alarms+2.2+1.16.5.jar : orva_alarms (2.0) - 1
• mods_folder obfuscate-0.6.2-1.16.3.jar : obfuscate (0.6.2) - 1
• mods_folder worldedit-mod-7.2.5-dist.jar : worldedit (7.2.5+57d5ac9) - 1
• mods_folder Traffic+Control+Ps+Roads+3.0.0+_1.16.5.jar : traffic_control_roadsmodbyteerth (3.0.0) - 1
• mods_folder cfm-7.0.0pre22-1.16.3.jar : cfm (7.0.0-pre22) - 1
• mods_folder architectury-1.31.60 (5).jar : architectury (1.31.60) - 1
• mods_folder MTR-forge-1.16.5-3.0.1.jar : mtr (1.16.5-3.0.1) - 1
• mods_folder mapperbase-1.16.5-<IP_ADDRESS>.jar : mapperbase (1.16.5-<IP_ADDRESS>) - 1
• mods_folder vehicle-mod-0.45.2-1.16.3.jar : vehicle (0.45.2) - 1
• maven_libs forge-1.16.5-36.2.34-universal.jar : forge (36.2.34) - 1
• mods_folder flywheel-1.16-0.2.5.jar : flywheel (1.16-0.2.5) - 1
• mods_folder create-mc1.16.5_v0.3.2g.jar : create (v0.3.2g) - 1
• mods_folder roadstuff-1.16.5-4.3.0.jar : roadstuff (1.16.5-4.3.0) - 1
• mods_folder [1.16.5]+SecurityCraft+v<IP_ADDRESS>.jar : securitycraft (v<IP_ADDRESS>) - 1

Additional Information
Restarting server usually fixes the issue.

Is this due to server lag?

I don't think so, TPS is running at 20 consistently with only a few players online at any time. It happens randomly and restarting the server fixes the issue. Sometimes it happens for one player and not another, and restarting game doesn't help.
Also, while I'm here, I think it would be a really good idea to add a config option to disable chunk loading while on a train above a certain speed threshold (sometimes when going at high speeds chunks don't load fast enough to keep up and lag the server). I also think it would be a great idea to add station announcements to let passengers at a station know when trains are arriving.
Another bug I have encountered a lot is where the path gets stuck on "Generating Path" and I have to relog to remove it.
Thanks!

The chunks are loaded by the player, not by additional chunk loading code. Player chunk loading is always enabled by Minecraft. It sounds like connection lag then, if your TPS is 20. You can add announcements through resourcepacks and play them using schedule sensors and command blocks. As of the generating path bug, I will look into that, thanks.

Did you resolve this issue?

I didn't change anything but haven't encountered it since so I'm assuming so yes. Thanks!


DOM Driver is not reusable after disposal

Code to reproduce the issue:

  it('is reusable after disposal', function (done) {
    function app() {
      return {
        DOM: Rx.Observable.of(
          div('Hello world')
        )
      };
    }

    const drivers = {
      DOM: makeDOMDriver(createRenderTarget('disposal-reuse'))
    };

    const {sinks, sources, run} = Cycle(app, drivers);

    const dispose = run();

    setTimeout(() => {
      let renderTarget = document.getElementById('disposal-reuse');
      assert.equal(renderTarget.innerHTML, '
Hello world
', 'expected hello world before dispose');

      dispose();

      setTimeout(() => {
        let renderTarget = document.getElementById('disposal-reuse');
        assert.equal(renderTarget.innerHTML, '', 'expected nothing after dispose');

        let newSinksSourcesAndRun = Cycle(app, drivers);

        newSinksSourcesAndRun.run();

        setTimeout(() => {
          let renderTarget = document.getElementById('disposal-reuse');

          assert.equal(renderTarget.innerHTML, '
Hello world
', 'expected hello world after rerun');

          done();
        }, 100);
      }, 100);
    }, 100);
  });

Expected behavior:
Expected that the drivers object would be reusable for multiple successive calls to run.
Actual behavior:
Disposing an application means that if the drivers object is reused, the DOM driver will not emit any new updates.
The above test cases fails at the last assertion, 'expected hello world after rerun'. This test case can be made to pass by creating a new drivers object for the second run.
Versions of packages used:
14.1.0
@staltz I mentioned this to you, and I am able to work around it by requiring that users wrap their drivers object in a function. This is not ideal, but it works.
I wrote a test case to reproduce this issue, but I was unable to fix it without serious investigation. I'm opening this issue in the hopes that the answer might obvious to you or @TylorS.
It seems like potentially it's not worth assuming that the drivers object can be reused, as it seems like it's quite common to do setup inside of a makeFooDriver method. That setup all has to remain intact for this to work.

if to move those two lines inside driver function itself:
https://github.com/cyclejs/cyclejs/blob/master/dom/src/makeDOMDriver.ts#L43-L44
would it work?

Perhaps, it would be awesome if you'd like to give it a go.
I almost feel that this issue should just be closed, as relying on a driver being reusable means that driver authors have to be very careful about where resources are created and disposed. There is already one issue on cycle-restart caused by this: https://github.com/Widdershin/cycle-restart/issues/38

Yes probably relaying on usability is not a good thing and should be avoided, though, this should be mentioned in the docs that makeFooDriver is a factory that is used to pass configuration parameters and should return specially configured driver that should be possible to reuse as this would make it more transparent and simplify testing and usage.

Yeah I think you answered yourself already:

It seems like potentially it's not worth assuming that the drivers object can be reused, as it seems like it's quite common to do setup inside of a makeFooDriver method. That setup all has to remain intact for this to work.

Basically makeFooDriver() is similar to new FooDriver(). We create an instance of the driver. It has beginning (the setup), middle (the usage in main), and end (disposal). After that, we need to create a new instance. It's how we teach how to make drivers: https://cycle.js.org/drivers.html
Cycle.run was always the imperative part of Cycle.js and we didn't have assumptions such as "drivers object will be used multiple times". I fear there isn't a way of making that assumption valid without redesigning the framework with some breaking changes.
So let's start looking at workarounds for the use case you want to support (restarting, correct?). How about not disposing between restarts? Any other ideas?

As a workaround, if you're calling Cycle.run() multiple times already..
const drivers = {
  DOM: (...args) => makeDOMDriver('#app')(...args),
  HTTP: (...args) => makeHTTPDriver()(...args),
}

This will create new "instances" each time that Cycle.run() is being called.

For cycle-restart, I ask the users to wrap their drivers object in a
makeDrivers function and pass that in instead.
function makeDrivers () {
  return {
     DOM: restartable(makeDOMDriver (...))
  }
}

This works well and allows me to dispose the drivers as normal.
On 14/01/2017 12:11 AM, "Tylor Steinberger"<EMAIL_ADDRESS>wrote:

As a workaround, if you're calling Cycle.run() multiple times already..
const drivers = {
DOM: (...args) => makeDOMDriver('#app')(...args),
HTTP: (...args) => makeHTTPDriver()(...args),
}
This will create new "instances" each time that Cycle.run() is being
called.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/cyclejs/cyclejs/issues/485#issuecomment-272419419,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAYUHVjgkLTeyjl7VhzU_oN3RWGriYf0ks5rR1v_gaJpZM4LE_xl
.

@staltz I think this is solved with setupReusable, so we can close this issue

Agreed


Merging two or more databases [moved]

This is Issue 981 moved from a Google Code project.
Added by 2012-07-26T14:15:26.000Z by<EMAIL_ADDRESS>Please review that bug for more context and additional comments, but update this bug.
Original labels: Type-Enhancement, Priority-Low
Original description
The problem:

Sometimes databases have to be merged to one larger database. This means data is distributed over two or more databases which could also include data redundancy -- in case data is partially existing redundantly in two or more databases.

The example case:

For the sake of simplicity, let's assume a simple example where data is distributed over two databases WITHOUT any redundancy: Clusters 1,2,3 are in DB1 and 4,5,6 are in DB2 with no records or contents being duplicated/redundant.

Merging DB1 and DB2 is supposed to be done with using the "import database <filename>" command. First, DB1 is imported into a fresh (an empty) database or we just start from DB1 and would like to add DB2 contents to it.

The requirements:

When using the  IMPORT command to date, we cannot carry out the example case as mentioned above. We get issues with the orginal RID being different from the RID in the destination database (no matter if this means DB1 or a fresh database!). This is the case since OrientDB seems to successively assign a new RID to clusters from the database to be imported (in our example this is DB2). However, this newly assigned RID is different from the original RID for some cluster. The original RID is stored in the export file (i.e. the JSON export).

The solution:

Orientdb should do either of the two following options:
a) ignore original RIDs and continue with assigning RIDs during import
b) do not save RIDs with the export file and ALWAYS assign RIDs during import on the fly (in my opinion the way to go)

Best, Christian

Not relevant anymore. Closing it.


feat: implement tr

This pull request implements the tr command, which is documented in section 9.1 tr: Translate, squeeze, and/or delete characters.
One aspect of this implementation of tr that differs from GNU coreutils is how each character is handled. GNU coreutils processes byte-for-byte, not taking into account multibyte codepoints. This implementation, however, processes codepoint-for-codepoint. Here are some examples.
echo old | tr old new: Translating a single-byte codepoint to another single-byte codepoint works the same between this implementation and GNU coreutils' implementation.

Input
Output (V coreutils)
Output (GNU coreutils)

Codepoints
old
new
new

Bytes

111 108 100

110 101 119

110 101 119

echo ! | tr ! ❗: Translating a single-byte codepoint into a multibyte codepoint. The GNU implementation only replaces the first byte (226), which means programs that expect UTF-8 encoded data might render the replacement codepoint � (U+FFFD) in its place to represent incomplete data

Input
Output (V coreutils)
Output (GNU coreutils)

Codepoints
!
❗
�

Bytes

33

226 157 151

226

If replacing entire codepoints is undesirable, it's very easy to revert to the byte-for-byte behavior.
As of now, this is what is implemented

[ ] tr <arg1> <arg2>
[X] tr -d <arg>, tr --delete <arg>
[ ] tr -t <arg1> <arg2>, tr --truncate-set1 <arg1> <arg2>
[ ] tr -s <arg1> <arg2>, tr --squeeze-repeats <arg1> <arg2>
[ ] tr -c <arg1> <arg2>, tr --complement <arg1> <arg2>

The project goal is to re-implement the GNU coreutils tools behaviors as closely as possible, including error messages etc.

However, a new option could be added, to allow proper handling of multi-byte chars.
Nothing says we can't have options they don't, just that the default, and any options they do have, should act as close to theirs as possible.

A new option, will make it a harder to test again the target.
The current infrastructure is setup to expect the same outputs/help screens etc.
I think that new options are nice, but perhaps should be added at a later date, when we have more coverage and improved infrastructure that can allow it.


Chapter 8 ColorViewList: Unhandled Exception

I'm getting an unhandled exception when trying to deploy the ColorViewList program with the following message:

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.

It breaks at line 21 of the .g.cs file this.LoadFromXaml(typeof(ColorViewListPage));
I have Xamarin C8 / <IP_ADDRESS>0 installed for Visual Studio 2015 which was released only a few days ago and other projects in the chapter deploy ok.

I changed line 25 of the ColorView.xaml.cs file from ColorTypeConverter colorTypeConv = new ColorTypeConverter(); to Color color = (Color)colorTypeConv.ConvertFromInvariantString(colorName); as visual studio was highlighting that ConvertFrom() is now obsolete. The example then deployed successfully.


Add ability to manage scrapes

This adds the ability to view, resubmit and delete scrapes that have not
been completed yet.
To test:

rails db:migrate
rails test

Yes. I’ll get to it in the next hour
-Christopher Guess
@.***
US/WhatsApp/Signal: +1<PHONE_NUMBER>
PGP: AAE7 5171 0D81 B45B – https://keybase.io/cguess
On Mar 31, 2022, 10:03 -0400, Justin Reese @.***>, wrote:

@cguess Once #163 is merged into master, do you plan to rebase this branch from it? (Should I wait for that before continuing this review?)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

All cleaned up. @reefdog please take a look

@cguess Tests are currently running, but I just fired up the app and was greeted with a NameError in Archive#index, I think because of the same jobs_status_path issues you were fixing in 2db1b8da1ed4944a719b41cdb5682f71699e9be7. Might need a few more snipes:


The plugin foundation_fluttify doesn't have a main class defined in

flutter doctor
Flutter assets will be downloaded from https://storage.flutter-io.cn. Make sure you trust this source!
[√] Flutter (Channel stable, 2.10.4, on Microsoft Windows [Version 10.0.17134.2208], locale zh-CN)
    • Flutter version 2.10.4 at G:\Flutter\flutter
    • Upstream repository git@github.com:flutter/flutter.git
    • Framework revision c860cba910 (3 months ago), 2022-03-25 00:23:12 -0500
    • Engine revision 57d3bac3dd
    • Dart version 2.16.2
    • DevTools version 2.9.2
    • Pub download mirror https://pub.flutter-io.cn
    • Flutter download mirror https://storage.flutter-io.cn

[!] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at F:\SDK\Sdk
    X cmdline-tools component is missing
      Run `path/to/sdkmanager --install "cmdline-tools;latest"`
      See https://developer.android.com/studio/command-line for more details.
    X Android license status unknown.
      Run `flutter doctor --android-licenses` to accept the SDK licenses.
      See https://flutter.dev/docs/get-started/install/windows#android-setup for more details.

[√] Chrome - develop for the web
    • Chrome at C:\Users\Administrator\AppData\Local\Google\Chrome\Application\chrome.exe

[√] Visual Studio - develop for Windows (Visual Studio Community 2019 16.6.5)
    • Visual Studio at G:\Flutter\visual studio
    • Visual Studio Community 2019 version 16.6.30320.27
    • Windows 10 SDK version 10.0.18362.0

[√] Android Studio (version 2020.3)
    • Android Studio at E:\Program Files\Android4.2.2
    • Flutter plugin can be installed from:
       https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
       https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)

[√] Connected device (4 available)
    • ATU AL10 (mobile) • TPE9X18906C03616 • android-arm64  • Android 8.0.0 (API 26)
    • Windows (desktop) • windows          • windows-x64    • Microsoft Windows [Version 10.0.17134.2208]
    • Chrome (web)      • chrome           • web-javascript • Google Chrome 102.0.5005.115
    • Edge (web)        • edge             • web-javascript • Microsoft Edge 97.0.1072.62

[!] HTTP Host Availability
    X HTTP host https://maven.google.com/ is not reachable. Reason: An error occurred while checking the HTTP host: 信号灯超时时间已到

! Doctor found issues in 2 categories.
Process finished with exit code 0

pub
 # 地图定位
  amap_location_fluttify: ^0.17.0

  # https://github.com/aagarwal1012/Animated-Text-Kit
  animated_text_kit: ^4.2.1

  # 音频播放
  audioplayers: ^0.20.1

  # AzListView，Flutter 城市列表，联系人列表，自定义Header，索引，悬停效果。
  azlistview: ^2.0.0

  badges: ^2.0.2

  # 条形码
  barcode_flutter: ^1.1.2

  # 扫描二维码
  barcode_scan: ^3.0.1

  # 带缓存的图片
  cached_network_image: ^3.2.0

  convert: ^3.0.1

  clippy_flutter: ^2.0.0-nullsafety.1

  # 设备信息
  device_info_plus: ^3.2.2

  # 网络请求库
  dio: ^4.0.6

  easy_contact_picker: ^0.0.2

  encrypt: ^5.0.1

  # 英文单词库
  english_words: ^4.0.0

  fancy_bottom_navigation: ^0.3.3

  # flare 插件
  flare_flutter: ^2.0.6

  #  flutter_charts:
  #    git:
  #      url: https://github.com/shichunlei/flutter_charts

  # 颜色选择器
  flutter_colorpicker: ^1.0.3

  # 刷新加载控件
  flutter_easyrefresh: ^2.2.1

  # 侧滑菜单
  flutter_inner_drawer: 0.5.7+1

  flutter_libs:
    path: flutter_libs/

  # 加载提示组件
  flutter_spinkit: ^5.1.0

  # 瀑布流
  flutter_staggered_grid_view: ^0.4.1

  # banner
  flutter_swiper_null_safety: ^1.0.2

  # 集成图标库
  # FontAwesome 地址：http://www.fontawesome.com.cn/
  # Feather 地址：https://feathericons.com/
  # EvilIcons 地址：https://evil-icons.io/
  # AntDesign 地址：https://ant.design/components/icon/
  # Ionicons 地址：https://ionicons.com
  # Fontisto 地址：https://fontisto.com/icons
  # Foundation 地址：https://zurb.com/playground/foundation-icon-fonts-3
  # Octicons 地址：https://octicons.github.com/
  # SimpleLineIcons 地址：https://simplelineicons.github.io/
  flutter_vector_icons: ^1.0.0

  # 天气背景
  flutter_weather_bg_null_safety: ^1.0.0

  flutter_widget_from_html: ^0.8.5

  # 图片裁剪
  image_cropper: ^1.5.1

  # 图片保存
  image_gallery_saver: ^1.7.1

  # 图片选择器
  image_picker: ^0.8.5

  # 汉字转拼音库 https://github.com/flutterchina/lpinyin
  lpinyin: ^2.0.3

  modal_bottom_sheet: ^2.0.1

  multi_image_picker2: ^5.0.2

  package_info_plus: ^1.4.2

  palette_generator: ^0.3.3

  # 滑动视差效果图片 https://github.com/pulyaevskiy/parallax-image
  parallax_image: ^0.3.1+1

  # 权限管理
  permission_handler: ^7.2.0

  # PhotoView
  photo_view: ^0.13.0

  provider: ^6.0.2

  # flutter 生成二维码
  qr_flutter: ^4.0.0

  quiver: ^3.0.1+1

  #
  rounded_letter: ^0.0.6

  share_plus: ^4.0.3

  # SP
  shared_preferences: ^2.0.13

  # 对 flare API进行封装的插件，使用少量的代码即可实现交互动画
  smart_flare: ^0.2.9+1

  # 时间线 https://github.com/furkantektas/timeline_list
  timeline_list: ^0.0.6

  # 透明占位图片
  transparent_image: ^2.0.0

  url_launcher: ^6.0.20

  # 手机震动
  vibration: ^1.7.4-nullsafety.0

  wave: ^0.2.0

Hi @Luffys6, foundation_fluttify  is a third party plugin. Issues related to it must be filed in its dedicated repo. Closing as this is not an issue related to flutter.


support python 3.12

Using python3.12 if I run pip install lambdex I currently get an outdated version (0.1.3) (latest is 0.1.9)
λ ~/code/test/ .venv/bin/pip install lambdex
Collecting lambdex
  Using cached lambdex-0.1.3-py2.py3-none-any.whl.metadata (294 bytes)
Collecting pex>=1.1.15 (from lambdex)
  Using cached pex-2.3.1-py2.py3-none-any.whl.metadata (7.4 kB)
Using cached lambdex-0.1.3-py2.py3-none-any.whl (5.2 kB)
Using cached pex-2.3.1-py2.py3-none-any.whl (3.4 MB)
Installing collected packages: pex, lambdex
Successfully installed lambdex-0.1.3 pex-2.3.1

Nor is the project currently locally installable with 3.12
λ ~/code/lambdex/ main .venv/bin/pip install .
Processing /home/jackevans/code/lambdex
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Installing backend dependencies ... done
  Preparing metadata (pyproject.toml) ... done
Collecting pex>=1.1.15 (from lambdex==0.1.9)
  Using cached pex-2.3.1-py2.py3-none-any.whl.metadata (7.4 kB)
INFO: pip is looking at multiple versions of lambdex to determine which version is compatible with other requirements. This could take a while.
ERROR: Package 'lambdex' requires a different Python: 3.12.2 not in '!=3.0.*,!=3.1.*,!=3.2.*,!=3.3.*,!=3.4.*,!=3.5.*,<3.12,>=2.7'

I'm doing a little digging on the pex side, as there's something deeper going on there.

Some notes after some digging in the PEX repo:
$ python3.11 -c "from pex.third_party import pkg_resources"
$
$ python3.12 -c "from pex.third_party import pkg_resources"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/benjyw/src/pex/pex/third_party/__init__.py", line 41, in load_module
    vendored_module = importlib.import_module(self.vendor_module_name)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/benjyw/.pyenv/versions/3.12.2/lib/python3.12/importlib/__init__.py", line 90, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/benjyw/src/pex/pex/vendor/_vendored/setuptools/pkg_resources/__init__.py", line 60, in <module>
    from pex.third_party.pkg_resources.extern import six
ImportError: cannot import name 'six' from 'pex.vendor._vendored.setuptools.pkg_resources.extern' (/Users/benjyw/src/pex/pex/vendor/_vendored/setuptools/pkg_resources/extern/__init__.py)

When I debug into the importlib internals, I see that in Python 3.11 six (after a series of find_spec() failures on various finders) ends up imported by the deprecated find_module(), which is removed in Python 3.12.
Now, this all may be fine on the PEX side. Certainly, all of PEX's tests pass on Python 3.12, and this import issue doesn't appear to matter for PEX's own functionality.  Generally, PEX has no stable API other than its CLI, so Lambdex has been on thin ice all along.
However I will bring @jsirois in to this conversation on the off-chance that this import issue does matter to PEX in some way and is worth an issue over there.
If not, we will have to decide what to do with Lambdex, since it's trying to use PEX in an unsupported way. And note that Pants no longer uses it, so there is not much incentive to maintain it.

I think this can be closed now since #33 is closed, but to button things up: since Python 3.8 the stdlib can be used for this instead; so the code could have conditional logic based in sys.version_info to use:
def load_entry_point(entry_point):
    if sys.version_info[:2] >= (3, 8):
        from importlib.metadata import EntryPoint
        return EntryPoint(name=None, value=entry_point, group=None).load()
    else:
        try:
            # PEX >= 1.6.0
            from pex.third_party.pkg_resources import EntryPoint
        except ImportError:
            # PEX < 1.6.0 has an install requirement of setuptools which we leverage knowledge of.
            from pkg_resources import EntryPoint
        return EntryPoint.parse("run = {ep}".format(ep=entry_point)).resolve()

@benjyw it's up to you, but if you want to transfer lambdex to the pex-tool org, I'm happy to make this change, do a final release with support for <3.14 or maybe even <4 and a prominent README on what to use instead and then archive the project.

Thanks @jsirois, yeah, since Pants no longer uses Lambdex, and it's tightly wound to PEX, it makes sense to transfer it and archive it. I'll kick that off.

Thanks @benjy, the rest of the work is in #35.
@Jackevansevo thanks for this PR, but I think it can be closed in favor of #35. It sounds like you don't need Lambdex after all, but, if so, with #35 merged I'll publish Lambdex 0.2.0 with Python 3.12 support.

@Jackevansevo I'll close this on your behalf as per the discussion above. Lambdex 0.2.0 with Python 3.12 support is now released, there is a MIGRATION guide, and I'll be archiving this repo presently.


Feat: Onboard IDC PDP datasets

Description

IDC.migrate pipeline:

Copies image files from source bucket to destination
Transfers IDC-pdp BQ datasets from IDC project to public datasets

Checklist
Note: Delete items below that aren't applicable to your pull request.

[ ] Please merge this PR for me once it is approved.
[ ] If this PR adds or edits a dataset or pipeline, it was reviewed and approved by the Google Cloud Public Datasets team beforehand.
[ ] If this PR adds or edits a dataset or pipeline, I put all my code inside  idc/migrate and nothing outside of that directory.
[ ] This PR is appropriately labeled.

@adlersantos  This is not ready yet.  Please do not review at this time.  Thanks!


Reland "Split DisplayListBuilder into DlCanvas optimizer and DlOp recorder classes".

This patch (https://github.com/flutter/engine/pull/44718) was reverted in https://github.com/flutter/engine/pull/44968 due to issues discovered in internal testing. This issue tracks relanding it.

I believe @flar is already working on it.


[iOS] Undefined symbols for architecture armv7 Error

While following the iOS readme installation instructions, the framework didn't compile for iOS. Below are the details.
Operating System: OS X El Capitan 10.11.5
pip package: Mac OS X, CPU only, Python 2.7
TensorFlow version: 0.9.0rc0
Steps

sh tensorflow/contrib/makefile/download_dependencies.sh

cd tensorflow/contrib/makefile/downloads/protobuf/
./autogen.sh
./configure
make
sudo make install
cd ../../../../..

sh tensorflow/contrib/makefile/compile_ios_protobuf.sh
sh tensorflow/contrib/makefile/compile_ios_tensorflow.sh

Log showing error
Undefined symbols for architecture armv7:
  "tensorflow::shape_inference::UnchangedShape(tensorflow::shape_inference::InferenceContext*)", referenced from:
      ___cxx_global_var_init.17 in libtensorflow-core-armv7.a(math_ops.o)
      ___cxx_global_var_init.24 in libtensorflow-core-armv7.a(math_ops.o)
      ___cxx_global_var_init.27 in libtensorflow-core-armv7.a(math_ops.o)
      ___cxx_global_var_init.31 in libtensorflow-core-armv7.a(math_ops.o)
      ___cxx_global_var_init.37 in libtensorflow-core-armv7.a(math_ops.o)
      ___cxx_global_var_init.41 in libtensorflow-core-armv7.a(math_ops.o)
      ___cxx_global_var_init.44 in libtensorflow-core-armv7.a(math_ops.o)
      ...
ld: symbol(s) not found for architecture armv7
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [/Users/Main/Documents/tensorflow/tensorflow/contrib/makefile/gen/bin/benchmark] Error 1
armv7 compilation failed.

I'm also experiencing exactly the same error.   The CameraExample sample app won't compile due to this missing reference.

Sorry about the recent issues with iOS building. I've added the missing file, along with an Eigen patch, in #3075. Can you give this a try and let me know if you're still having issues?

Thanks. Do I need to reinstall tensorflow from master?

I would do a git clone https://github.com/tensorflow/tensorflow into a clean directory, and then try the tensorflow/contrib/makefile/build_all_ios.sh script again.

new error while building the framework:
gcc --std=c++11 -DIS_SLIM_BUILD  -miphoneos-version-min=9.2 -arch armv7 -D__thread= -Wno-c++11-narrowing -mno-thumb -DTF_LEAN_BINARY -D__ANDROID_TYPES_SLIM__ -DMIN_LOG_LEVEL=0 -fno-exceptions -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS9.3.sdk -I/usr/local/include -I. -I/Users/Main/Documents/tensorflow/tensorflow/contrib/makefile/downloads/ -I/Users/Main/Documents/tensorflow/tensorflow/contrib/makefile/downloads/eigen-eigen-334b1d428283 -I/Users/Main/Documents/tensorflow/tensorflow/contrib/makefile/gen/proto/ -I/Users/Main/Documents/tensorflow/tensorflow/contrib/makefile/gen/proto_text/ -I/Users/Main/Documents/tensorflow/tensorflow/contrib/makefile/gen/protobuf-host/include -c tensorflow/core/kernels/xent_op.cc -o /Users/Main/Documents/tensorflow/tensorflow/contrib/makefile/gen/obj/tensorflow/core/kernels/xent_op.o
In file included from tensorflow/core/kernels/xent_op.cc:22:
In file included from ./tensorflow/core/framework/op_kernel.h:22:
In file included from ./tensorflow/core/framework/allocator.h:25:
In file included from ./tensorflow/core/framework/type_traits.h:22:
./tensorflow/core/framework/types.h:31:10: fatal error: 'tensorflow/core/framework/types.pb.h'
      file not found
#include "tensorflow/core/framework/types.pb.h"
         ^
1 error generated.
make: *** [/Users/Main/Documents/tensorflow/tensorflow/contrib/makefile/gen/obj/tensorflow/core/kernels/xent_op.o] Error 1
armv7 compilation failed.

before running the make command, running compile_ios_protobuf.sh took quite a while and seemed to have succeeded.

This is usually an error when running parallel builds (e.g. make -j 8), because the makefile dependencies weren't set up quite right. I've added the right dependencies to #3104 so once that's in this should be fixed.

Worked! Thanks @petewarden.

Awesome to see, thanks for the update!

hi, @petewarden @sitefeng
I met a similar problem with the latest code, the error message is
Undefined symbols for architecture x86_64:
  "google::protobuf::io::CodedInputStream::ReadVarintSizeAsIntFallback()", referenced from:
      google::protobuf::io::CodedInputStream::ReadVarintSizeAsInt(int*) in test_log.pb.o
      google::protobuf::io::CodedInputStream::ReadVarintSizeAsInt(int*) in saved_tensor_slice.pb.o
      google::protobuf::io::CodedInputStream::ReadVarintSizeAsInt(int*) in event.pb.o
      google::protobuf::io::CodedInputStream::ReadVarintSizeAsInt(int*) in tensorflow_server.pb.o
      google::protobuf::io::CodedInputStream::ReadVarintSizeAsInt(int*) in named_tensor.pb.o
      google::protobuf::io::CodedInputStream::ReadVarintSizeAsInt(int*) in meta_graph.pb.o
      google::protobuf::io::CodedInputStream::ReadVarintSizeAsInt(int*) in config.pb.o
      ...
  "google::protobuf::MessageLite::InternalSerializeWithCachedSizesToArray(bool, unsigned char*) const", referenced from:
      vtable for google::protobuf::internal::MapEntryBase in test_log.pb.o
      vtable for google::protobuf::internal::MapEntryBase in tensorflow_server.pb.o
      vtable for google::protobuf::internal::MapEntryBase in meta_graph.pb.o
      vtable for google::protobuf::internal::MapEntryBase in config.pb.o
      vtable for google::protobuf::internal::MapEntryBase in graph.pb.o
      vtable for google::protobuf::internal::MapEntryBase in function.pb.o
      vtable for google::protobuf::internal::MapEntryBase in attr_value.pb.o
      ...
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [/Users/fengjian/my-work/machine-learning/tensorflow/tensorflow/contrib/makefile/gen/host_bin/proto_text] Error 1
+ '[' 2 -ne 0 ']'
+ echo 'armv7 compilation failed.'
armv7 compilation failed.
+ exit 1

any suggestion?

@petewarden Any clue about this last issue posted by @fengjian0106

No, but I'm hoping that the changes we've made to the build_all_ios.sh script since July have fixed this.


Bar Chart component

Create bar chart component #27
Sample:

Bar chart Component created as required using chart.js
NOTE: Data can be mapped with JSON file.
Author: @rohitgupta274509


Why juicefs client communicate with object store with https protocol instead of s3

as the title says, since s3 is a standard protocol for object store, why use https protocol to communicate between juicefs client and object store?

S3 is an API built on top of HTTP or HTTPS.

S3 is an API built on top of HTTP or HTTPS.

S3 is an API built on top of HTTP or HTTPS.

Thanks for the quick response:)

S3 is an API built on top of HTTP or HTTPS.

Thanks for the quick response:)


Hydra: aarch64 builds aborting due to host key errors

A lot of tasks seem to be randomly aborting, for instance linux. It seems like there is an issue with the build host. Hydra is reporting the builds as aborted with the following status.
Aborted: [31;1merror:[0m[34;1m --- Error --- hydra-queue-runner[0m cannot connect to
<EMAIL_ADDRESS>[33;1mHost key verification failed.[0m

The actual build logs don't seem to indicate a failure, so the actual derivation seems to be build normally sometimes.

This hasn't been an issue recently, closing this for now.


ExportToTiff now logs warning and finishes instead of failing.

If the ExportToTiff task is requested to create a map for a feature
that is not present in the EOPatch it will exit without an error and
log a warning message instead of exiting with an exception.
This is useful for workflows where we want to export multiple features
over a set of EOPatches. In the previous version the workflow would
fail and stop processing other features once it encountered one that
was not present in the EOPatch. This fix changes the behaviour so that
encountering a missing feature does not stop the execution for that
eopatch.

Codecov Report

Merging #158 into develop will decrease coverage by 0.03%.
The diff coverage is 57.14%.

@@             Coverage Diff             @@
##           develop     #158      +/-   ##
===========================================
- Coverage    78.61%   78.57%   -0.04%
===========================================
  Files           42       42
  Lines         4507     4513       +6
===========================================
+ Hits          3543     3546       +3
- Misses         964      967       +3

Impacted Files
Coverage Δ

io/eolearn/io/local_io.py
90% <57.14%> (-1.8%)
:arrow_down:

Continue to review full report at Codecov.

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

Codecov Report

Merging #158 into develop will decrease coverage by 0.03%.
The diff coverage is 57.14%.

@@             Coverage Diff             @@
##           develop     #158      +/-   ##
===========================================
- Coverage    78.61%   78.57%   -0.04%
===========================================
  Files           42       42
  Lines         4507     4513       +6
===========================================
+ Hits          3543     3546       +3
- Misses         964      967       +3

Impacted Files 	Coverage Δ
io/eolearn/io/local_io.py 90% <57.14%> (-1.8%) 	arrow_down
Continue to review full report at Codecov.

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

could we add a simple test here to check the expected behaviour ?


Uploader connects to Mongo instance using HOST_IP and PORT

I see no point in getting the port explicitly.
Why would you need this? How this help with DX? Or with anything else?


[bugfix] Change Bash regex for engine labels

It is now capable of capturing a profiler name with dashes in the middle of the string - e.g. rt-trace-bpf.

Something is wrong with the new regex/logic. Need more debugging...


🐛 [firebase_messaging] version solving failed

Bug report
Describe the bug
The documentation clearly said

I get the following error, when I run flutter pub get
Because firebase_messaging >=7.0.3 <8.0.0-dev.7 depends on firebase_core ^0.5.0+1 and app depends on firebase_core ^0.7.0, firebase_messaging >=7.0.3 <8.0.0-dev.7 is forbidden.
So, because app depends on firebase_messaging ^7.0.3, version solving failed.
pub get failed (1; So, because app depends on firebase_messaging ^7.0.3, version solving failed.)

Steps to reproduce
Steps to reproduce the behavior:

add firebase_core: "^0.7.0" and firebase_messaging: "^7.0.3" to pubspec.yaml
run flutter pub get

Expected behavior
Obviously it must works

Additional context
Add any other context about the problem here.

Flutter doctor
Run flutter doctor and paste the output below:
Click To Expand
[√] Flutter (Channel stable, 1.22.6, on Microsoft Windows [Version 10.0.18363.1379], locale en-US)
[√] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
[!] Android Studio (version 4.1.0)
    X Flutter plugin not installed; this adds Flutter specific functionality.
    X Dart plugin not installed; this adds Dart specific functionality.
[√] Connected device (1 available)

! Doctor found issues in 1 category.

Flutter dependencies
Run flutter pub deps -- --style=compact and paste the output below:
Click To Expand
The pubspec.yaml file has changed since the pubspec.lock file was generated, please run "pub get" again.
pub finished with exit code 65

Click To Expand
PASTE OUTPUT INSIDE HERE

---

That's some sort of an issue I've veen experiencing. And ios couldn't build if I bring down firebase_messaging down to 6.0.16 as I've explained here

Hi @sm2017
Please upgrade to the latest non-nullsafety version firebase_messaging: ^8.0.0-dev.14.
There is already an issue to track that the wrong version is mentioned in the documentation https://github.com/FirebaseExtended/flutterfire/issues/4955.
Closing since the newest version of firebase_core is incompatible with older versions of all of the plugins due to a bump in the underlying iOS native SDK and this is not an issue with the plugins themselves.
Thank you


Migration to latest feature of Dagger Android

Removed AppInjector
Using DaggerApplication, DaggerAppCompatActivity, DaggerFragment
Updated AppComponent extend base AndroidInjector

I signed it!


Cleanup documentation on readthedocs

This PR brings will move the documentation from the Github's README to readthedocs.
➤ Built documentation for this PR: https://spinalcordtoolbox.readthedocs.io/en/jca-1656-rtd
This PR includes the following changes:

[x] Display SCT logo on top left of RTD
[ ] ~Automatically fetch the latest version (currently hard-coded in the conf.py)~ --> not urgent
[x] Create spinalcordtoolbox.com domain on NameCheap and create ALIAS for readthedocs.io. For the records, the working config on NameCheap is:

Remaining issues not addressed here:

Display Changelog in the RTD documentation #2822
Transfer the remaining documentation from sourceforge #2829

@Drulex I will now go through the API section. I was wondering: do we need to keep the term "API" for each of the sub-headings? It makes it "heavy to look" on the left tab to have all these API terms, which I think is not necessary because it's pretty clear we are in the API section:

do we need to keep the term "API" for each of the sub-headings?

Not at all, the previous doc used this nomenclature so I just followed. I agree with you.

My browser is showing that "part of this page are note secure" on the index page.

I suspect it has to do with the forum badge which points to a domain (spinalcordmri.org) that doesn't use SSL.

It looks like the automodule did not generate the docs for the API code: https://spinalcordtoolbox.com/en/jca-1656-rtd/dev_section/api.html

It looks like the automodule did not generate the docs for the API code: https://spinalcordtoolbox.com/en/jca-1656-rtd/dev_section/api.html

It probably has to do with this setting on readthedocs website:

which doesn't match the new path in .readthedocs.yaml.
Will see what happens if I just remove it.

It looks like the automodule did not generate the docs for the API code: https://spinalcordtoolbox.com/en/jca-1656-rtd/dev_section/api.html

weird. it was working 2-3 commits ago on RTD. i suspect it is linked to the added recommark extension which i added to render changes.md

My browser is showing that "parts of this page are note secure" on the index page.

I suspect it has to do with the forum badge which points to a domain (spinalcordmri.org) that doesn't use SSL.

good catch-- issue opened https://github.com/neuropoly/spinalcordtoolbox/issues/2830

Following on https://github.com/neuropoly/spinalcordtoolbox/pull/2814#issuecomment-669168870:

Tried to add .md in source_suffix in conf.py 16af99d --> didn't work


Error in documentation

In the getting-started page /metrics/docs/source/getting-started.rst
The mainClass in the mvn command is incorrect.
mvn package exec:java -Dexec.mainClass=sample.First
It should be
mvn package exec:java -Dexec.mainClass=sample.GetStarted

@shreejay Please feel free to open a pull request to get this fixed!


Implement trigram similarity to reduce search results

Implement trigram similarity to reduce search results
Make sure single letter searches work as expected

#2334  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @nickgraz and the rest of your teammates on  Graphite


Include URLs to 24h Event YouTube Videos

Add URLs from the videos in the 24-Hour Human Reference Atlas Event 2022 YouTube playlist to their respective hourly segments on https://humanatlas.io/events/2022-24h/.
Please place the URL under the segment title. See red arrow below for placement.

Added URLs in PR #67


docs: typo updated for import

This pr has typo fix for import in nepali translation

thanks @samir-byte !


fix: Process exit at script end

Coverage remained the same at 85.462% when pulling ecaadb0dd1fddc907e38010320031c89e1bf2dea on fix/process_exit_at_script_end into 16f30af512766834286001da6d7ce8654b6ab78c on main.

Coverage remained the same at 85.462% when pulling ecaadb0dd1fddc907e38010320031c89e1bf2dea on fix/process_exit_at_script_end into 16f30af512766834286001da6d7ce8654b6ab78c on main.


Replace custom structs (like PdfPoint) with .NetStandard ones (like Vector2)

The System.Numerics.Vector2 is completely suited as a replacement of PdfPoint. As this is a .NetStandard library, it will be used with other libraries that use Vector2 as primary point structure. Not having to make conversion from PdfPoint to Vector2 and vice versa every time will reduce time, and will look nice.

I am willing to contribute and implement it if this issue is considered.

I'd considered something similar in the past, but I think it's potentially more valuable to be able to specify points (X/Y pairs) with separate measurement units.  While odd, it could be very useful to locate a point on a page like so:
var point = new PdfPoint(
    new PdfMeasurement(1.0, PdfMeasurementType.Inch),
    new PdfMeasurement(2.0, PdfMeasurementType.Mm));

If I adopted Vector2 then that ability to specify different units would be lost.


Change layout of mountpoints and mounts

Added info about MountPoints to config.md.
Filled after discuss in opencontainers/runc#242
I noticed that MountPoints still has json tag mounts, should I rename it to mountPoints?

ping @philips @mrunalp @crosbymichael

On Wed, Sep 02, 2015 at 08:47:03AM -0700, Alexander Morozov wrote:

I noticed that MountPoints still has json tag mounts, should I
rename it to mountPoints?

I don't think so.  We need different Go names because we're putting
all these types in one package, but the JSON is clearly namespaced by
the file it's in (config.json vs. runtime.json), so there's no need to
disambiguate there.

Actually we don't need different go name too.

On Wed, Sep 02, 2015 at 09:45:00AM -0700, Alexander Morozov wrote:

Actually we don't need different go name too.

We don't?  They're both in the specs package in the same directory.
If they were both Mount, how would you access one or the other?

@wking It's type name, have nothing in common with field name.

On Wed, Sep 02, 2015 at 09:51:08AM -0700, Alexander Morozov wrote:

@wking It's type name, have nothing in common with field name.

Ah, right.  +1 to making both field names Mounts to match the JSON
keys.

@wking @mrunalp I think I addressed comments.

On Wed, Sep 02, 2015 at 11:21:13AM -0700, Alexander Morozov wrote:

@wking @mrunalp I think I addressed comments.

Matching examples for mounts and mount-points is still open 1.  But
“it's fine the way it is” is a valid response ;).

@wking I actually added example of runtime.conf entry below that line.

On Wed, Sep 02, 2015 at 11:43:07AM -0700, Alexander Morozov wrote:

@wking I actually added example of runtime.conf entry below that line.

But it only lists ‘proc’, while the config.json example lists proc,
dev, devpts, and data.  I'm suggesting we either list all those names
in both examples, or only proc in both examples.

On Wed, Sep 02, 2015 at 11:50:11AM -0700, W. Trevor King wrote:

On Wed, Sep 02, 2015 at 11:43:07AM -0700, Alexander Morozov wrote:

@wking I actually added example of runtime.conf entry below that line.

But it only lists ‘proc’…

I've been explaining this poorly, so here's a PR with my suggested
fixup: LK4D4/specs#1.  Feel free to squash into your commit if it
makes sense to you.

LGTM

LGTM

I think the mount order should be clearly defined in the spec.
Alternative definitions in my mind:

The mount order are exactly the same as this mount points array. The config file MUST list them in reasonable order.
The mount order are mostly the same as this mount points array. But the longer path will be altered downward and be placed after the shorter path which is the ancestor of the longer path.

Any thoughts?

On Wed, Sep 02, 2015 at 04:53:54PM -0700, Lai Jiangshan wrote:

The mount order are exactly the same as this mount points
array. The config file MUST list them in reasonable order.

This is how I'd do it.

This is how I'd do it.

Wait until full discussion?

On Wed, Sep 02, 2015 at 05:30:18PM -0700, Lai Jiangshan wrote:

This is how I'd do it.

Wait until full discussion?

Probably wise ;).  One thing to consider for auto-ordering, is what
would happen if you did:

Bind mount /a/b/c to /d
Mount $x over /a/b

I'm not actually sure ;), but it's possible that /d still looks into
the original /a/b/c, and not into $x/c.  If so, that means
auto-ordering could be problematic, because it would see that (1)'s
/a/b/c seemingly depends on (2), when in fact the bundle-author
preferred (1) to happen first.

I prefer the strict/exact order. But it needs to be documented in the Spec.

LGTM (c18c283)

On Wed, Sep 02, 2015 at 09:25:54PM -0700, Lai Jiangshan wrote:

LGTM (c18c283)

Looks good to me too.  I'm fine punting explicit ordering statements
(and my other comment cleanups [1,2]) to follow-up PRs, if that helps
this one land faster.

I think we have enough LGTMs here and I want to fix spec for now. Feel free to post your suggestions as another PR.


OCM-4675 | fix: remove technology preview from command help

Forgotten in https://github.com/openshift/rosa/pull/1592

LGTM

lgtm thanks!

/lgtm


Error marker does not appear if an error occurs past the script's last line in the script editor

Tested versions

Reproducible in: 4.3.beta 5833f5978

System information
Godot v4.3.beta (5833f5978) - Fedora Linux 39 (KDE Plasma) - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4090 (nvidia; 550.78) - 13th Gen Intel(R) Core(TM) i9-13900K (32 Threads)
Issue description
I discovered this while reporting https://github.com/godotengine/godot/issues/92998. The error marker does not appear if an error occurs past the script's last line in the script editor:
https://github.com/godotengine/godot/assets/180032/4ce85526-f04d-4e56-9579-d8f3f498dd6c
This can look confusing at first, as some users may be looking for the error for a while if they don't see a red marker line. We should do one of the following:

Clamp the error line to always be located somewhere within the script. This might help with third-party tools and the LSP too.
Clamp the error marker position to always be located somewhere within the script.
Perhaps both, as a defensive measure for issues in the future?

Steps to reproduce

Create a new script with the default template. Remove the _process() method entirely (including its comment).
Remove the pass keyword in _ready(), which will cause a script error to occur on line 7 (even though the script only has 6 lines, including its final trailing newline).
Notice how the error gutter has a message at the bottom, but there's no red error marker on the script editor itself.

Minimal reproduction project (MRP)
N/A

somewhat fixed by https://github.com/godotengine/godot/pull/85488

The error in the example now happens on a different line in bounds.
I'm not sure if any other kinds of errors can be out of bounds though.

I'm not sure if any other kinds of errors can be out of bounds though.

In some cases, an error is possible on the line zero (if we did not provide a correct data) or on the EOF token, but the latter is probably fixed, since after #85488 the error is produced on the previous token. It is also possible that there is a bug in the tokenizer/parser.
So I think we could add a CLAMP on the Script Editor side. Note that we should not change the number in the error message (to fix the bug in GDScript), only for the red line marker. Say, if GDScript reports an error on line zero, then Script Editor displays the error message as is, but highlights the first line. What do you think about it?


Test using latest importlib

Depdendabot does not automatically upgrade these due to the env markers

bors merge

bors merge


Can't seem to connect to DFM 22BUC03-ML on Ubuntu 20.04

Hardware:

DFM 22BUC03-ML

Software:

Ubuntu 20.04

What I've tried:

Git clone tiscamera repository and built the repo from source
Tried issuing tcam-ctrl --list but doesn't see the camera
Tried two different USB cables, still doesn't list the camera
dmesg seems to be able to list the device, so I don't think it is a physical connection issue:

[  863.849015] usb 2-2: new high-speed USB device number 9 using xhci_hcd
[  863.998247] usb 2-2: New USB device found, idVendor=199e, idProduct=8202, bcdDevice= 8.13
[  863.998261] usb 2-2: New USB device strings: Mfr=2, Product=1, SerialNumber=3
[  863.998267] usb 2-2: Product: DFM 22BUC03-ML
[  863.998272] usb 2-2: Manufacturer: The Imaging Source Europe GmbH
[  863.998276] usb 2-2: SerialNumber: 19220363

Thank you very much, updating the camera's firmware with dfk22uc03_3017.euvc seems to have worked!
Thanks for the prompt reply :)


Vault Reference to VaultList Vice Contract

Right now Vault Objects carry a reference to their Contract Object. With the introduction of the VaultList class, I think it makes more sense that an individual vault carry a reference to its VaultList.
 Closing


Update CHANGELOG.md

IMPORTANT: Please do not create a Pull Request without creating an issue first.
Any change needs to be discussed before proceeding. Failure to do so may result in the rejection of the pull request.
Proposed Changes

...
...
...

Relevant issues
Closes #...
Closes #...
Closes #...
Related #...

Pada Isn, 12 Apr 2021 5:50 PG Matīss @.***> menulis:

Closed #569 https://github.com/fluid-player/fluid-player/pull/569.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/fluid-player/fluid-player/pull/569#event-4579030058,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ATQWFZ523SHK3CB2WQZ7673TIIKQ7ANCNFSM42X62PPQ
.


Call center refund methods allow manually typing/adding and Saving of cash payments.

[As per Microsoft documentation, Call center refund methods do not allow CASH payments or show it in the dropdown. But if we type the number for cash payment in the Retail payment field and SAVE it, it saves ok and does not throw an error]

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

ID: c3c9ff31-6d72-a2cf-9b6c-0d43cd654ccc
Version Independent ID: cd9b6f87-4be4-f46b-a32d-36f41bbf7318
Content: Refund payment processing in call centers - Commerce | Dynamics 365
Content Source: articles/commerce/call-center-refund-payments.md
Service: dynamics-365-commerce
Product: ****
Technology: ****
GitHub Login: @hhainesms
Microsoft Alias: hhaines

@thedynamicsgirl, thanks for providing this feedback.
@hhainesms, please considering updating the content based on this feedback.

Created bug 620269 to track this issue.

@thedynamicsgirl, this issue has been fixed.  Thanks for reporting this!


FZF is broken on fish 3.4.0 w/ Termux...

Updated my fish on termux after that FZF don't work, when type 'fzf' i get this error
[Command failed: set -o pipefail; command find -L . -mindepth 1 ( -path '/.' -o -fstype 'sysfs' -o -fstype 'devfs' -o -fstype 'devtmpfs' -o -fstype 'proc' ) -prune -o -type f -print -o -type l -print 2> /dev/null | cut -b3-]
Edit: updated for correct code without " ".

Broken for me aswell with same error as above on termux.

OP's command looks wrong to me ( parentheses are not escaped ).
Regardless, it would be good to know whether the problem also occurs without termux or with FZF_DEFAULT_COMMAND unset.

OP's command looks wrong to me ( parentheses are not escaped ).
Regardless, it would be good to know whether the problem also occurs without termux or with FZF_DEFAULT_COMMAND unset.

I haven't set the default command to anything. This is right out of the box. In bash, it worked as intended but not in Fish shell.

hmm. Well, I also run fish (git/ pre-3.5) and don't run termux, so I suppose I could check that.
At the moment bin/fzf-tmux line 186 looks suspicious, I suspect 'printf %q' is a bash extension which quotes a string in a way appropriate to the bash shell. I think bash doesn't interpret ' ( ', but fish does. Adding some sed s/ to this line to ensure that parentheses are single-quoted might be what is needed.

See if this works:
bash -c "set -o pipefail; command find -L . -mindepth 1 \( -path '*/\.*' -o -fstype 'sysfs' -o -fstype 'devfs' -o -fstype 'devtmpfs' -o -fstype 'proc' \) -prune -o -type f -print -o -type l -print 2> /dev/null | cut -b3-"

See if this works under fish.
bash -c "set -o pipefail; command find -L . -mindepth 1 \( -path '*/\.*' -o -fstype 'sysfs' -o -fstype 'devfs' -o -fstype 'devtmpfs' -o -fstype 'proc' \) -prune -o -type f -print -o -type l -print 2> /dev/null | cut -b3-"

No luck unfortunately.

Works fine in just fish ( no termux, git 3e5284aaf) - returns a list of files as expected.
Unless I am misreading the screenshot above, that attempt also succeeded, but returned no files. It's unclear whether that would be wrong, as there is no indication of what the PWD is and what, if anything, it might contain.

I'm able to reproduce this issue with bash under Termux. If I run the command above without the stderr redirection:
$> bash -c "set -o pipefail; command find -L . -mindepth 1 \( -path '*/\.*' -o -fstype 'sysfs' -o -fstype 'devfs' -o -fstype 'devtmpfs' -o -fstype 'proc' \) -prune -o -type f -print -o -type l -print | cut -b3-"
find: Cannot read mounted file system list

If I remove the -fstype flags from the command it works as intended.

ok, that's clearer.
What does find -fstype devfs do? It is noted in find man page that valid values for -fstype vary between systems, but it's unclear exactly what specifying an invalid one results in when -O levels is 0 or 1 (1 is default).

ok, that's clearer.
What does find -fstype devfs do on your system? It is noted in find man page that valid values for -fstype vary between systems, but it's unclear exactly what specifying an invalid one results in when -O level is 0 or 1 (1 is default).

On my Android phone, i assume it trying to look up all mounted systems but I'm no genius.
All i do know is that FZF worked great on termux app before the fish update. After update i got this wired error message. But it must be something with termux/fish because it works well in bash.

I'm able to reproduce this issue with bash under Termux. If I run the command above without the stderr redirection:

I just noticed, this might not be appropriate. It looks like you are running this from bash ( hence BASH_VERSION being set) and not fish. OP only has a problem within fish.
The answer to what find -fstype SOMETHINGINVALID does seems to be 'just matches no files, but doesn't return an error' on a normal Linux. By my reasoning the next thing is to find out if it does something different in Termux+Fish, and also whether its behaviour in those circumstances is provably different from it's behaviour under Termux+BASH.

I get the same error, but with different dynamics. The issue occurs after performing an update of all installed packages (even with a fresh installation). I managed to narrow it down to the package 'findutils' that, after updating to version 4.9.0 from 4.8.0, generates the error... ( [Command failed: set -o pipefail; command find -L . -mindepth 1 ( -path '/.' -o -fstype 'sysfs' -o -fstype 'devfs' -o -fstype 'devtmpfs' -o -fstype 'pr..).
Could it be the same problem? The package, even with the latest termux app, still needs updating along with 29 others...

I get the same error, but with different dynamics. The issue occurs after performing an update of all installed packages (even with a fresh installation). I managed to narrow it down to the package 'findutils' that, after updating to version 4.9.0 from 4.8.0, generates the error... ( [Command failed: set -o pipefail; command find -L . -mindepth 1 ( -path '/.' -o -fstype 'sysfs' -o -fstype 'devfs' -o -fstype 'devtmpfs' -o -fstype 'pr..).
Could it be the same problem? The package, even with the latest termux app, still needs updating along with 29 others...

I can't see that i have it installed, so i don't know it this is the case?
Trying findutils and command -v findutils with no results.

I can't see that i have it installed, so i don't know it this is the case?
Trying findutils and command -v findutils with no results.

It's not a command... I think the package contains the "utilities" for the find command which is used in fzf. Maybe the update changed a parameter of the command that breaks the fzf search. The dev probably needs to update the code... I really don't know.
If you want, just to be sure, try running pkg search findutils and see which version is installed. Even if it says 4.9.0, as of know I couldn't find an easy way to rollback, other then reinstalling termux. It could be possible to install it from source...

I can confirm that downgrading from findutils 4.9.0 to 4.8.0 fixes the issue for me.

Can I ask you how? Both pkg and apt can't find the package... I am trying to do it from the source tarball put it's really painful, there are lots of problems.

I found it in a backup of my APT cache:
/data/data/com.termux/cache/apt/archives/findutils_4.8.0_aarch64.deb
It's unfortunate that the termux package archive doesn't keep old package versions.

FYI: I opened a termux-packages findutils issue:
termux/termux-packages#9506

I've tried to make the default command as portable as possible, but it may not work on some versions of find.
You should note that you can always change the default via $FZF_DEFAULT_COMMAND.

I've tried to make the default command as portable as possible, but it may not work on some versions of find.
You should note that you can always change the default via $FZF_DEFAULT_COMMAND.

That is true, but always nice that thing works out-of-the-box without edits.
But what would I need to type to get this working for now (also for others who might have this issue and need an answer) ? Also what to type to change it back if an update comes?
Would really be appreciated.

what would I need to type to get this working for now

Setting the environment variable to a working command. You don't have to use find (FYI, I don't. See https://github.com/junegunn/fzf#respecting-gitignore)

what to type to change it back if an update comes

Unsetting the variable.

what would I need to type to get this working for now

Setting the environment variable to a working command. You don't have to use find (FYI, I don't. See https://github.com/junegunn/fzf#respecting-gitignore)

what to type to change it back if an update comes

Unsetting the variable.

Yes that is true. Thank you for the links. Been playing around with that and .bashed / config.fish.
So you know why i get numbers to the left when pressing CTRL+R in bash but not in Fish? I would like to remove the numbers an just have the history command but i can't seem to find where the issue are or what the original export FZF_CTRL_R_OPTS should be.

bash -c "set -o pipefail; command find -L . -mindepth 1 ( -path '/.' ) -prune -o -type f -print -o -type l -print 2> /dev/null | cut -b3-"

The Termux findutils package has now been fixed to work with -fstype. Please upgrade to 4.9.0-1 and retest.
This solved the issue for me. 🎉

The Termux findutils package has now been fixed to work with -fstype. Please upgrade to 4.9.0-1 and retest.
This solved the issue for me. 🎉

Can confirm, FZF is now working in fish again, thanks for the heads-up!

Can confirm, FZF is now working in fish again with default settings. Thanks for the heads-up about the 4.9.0-1 update.

Great! Maybe the issue title should be updated to reflect that this was an issue with Termux findutils package 4.9.0 and not related to the shell?

Can confirm, FZF is now working in fish again with default settings. Thanks for the heads-up about the 4.9.0-1 update.

Great! Maybe the issue title should be updated to reflect that this was an issue with Termux findutils package 4.9.0 and not related to the shell?

Sorry, my mistake but yes of course.


Fading?

Mine looks good after I run it, but several minutes later, some of the dates in E show 280 or 360 contributions instead of the expected 180.  This makes the earlier letters blend in with the lighter green from other commits.

Maybe I ran it too many times testing PRs and got a stale cache.  I didn't notice it before I tried #8.
Anybody else seeing this problem?

Looks like a glitch from Github to me.
Looking at the actual commits per day looks fine (lists 180 for each pixel in that repo). Thus the patch in #8 itself seems to work as expected.
Maybe contact support and ask them what could be causing this.
And maybe while at it also to abolish ICE. ;-)

mine isn't faded but after force reverting a branch then pushing again with much higher commit counts, only the two most recent days show counts greater than the previous value and the second most recent day is only registering about a quarter of the commits.

I've updated to the latest and now I have the same issue

I noticed the git log is showing my current timezone
Date:   Sat Jun 6 12:00:40 2020 -0700

    40 on 2020-06-06

but the github doc mentions Contributions are timestamped according to Coordinated Universal Time (UTC) rather than your local time zone.

switched default branch away and back and now it looks right :frowning_face:

Mine starts well and then degrades, but usually within an hour.  Yours still looks good after four. :crossed_fingers:


Don't allow anything to be assignable to string within string mappings like Uppercase/Lowercase

Fixes #52731

@typescript-bot test this
@typescript-bot test top100
@typescript-bot user test this
@typescript-bot user test tsserver
@typescript-bot test tsserver top100
@typescript-bot run dt
@typescript-bot perf test this
@typescript-bot pack this

This PR isn't correct (note the test breaks), as it looks like some things only worked because of this return true.
But, given no real world code broke, I don't think I'm going to get any feedback for this besides unit testing.

@typescript-bot test this
@typescript-bot test top100
@typescript-bot user test this
@typescript-bot run dt
@typescript-bot perf test this


Feature Request: Emotes

I would like it if Emotes could be shown when a message with an emote is sent. I'm not honestly sure how possible that is, so my apologies for wasting your time if it is impossible!

I wanted to implement that, but I'm honestly absolutely clueless on how to render custom content in chat in Minecraft, although it should be possible, I remember seeing some mods do that :)

I'll give it a try, but no promises, as Java is not my main language and I might just have not enough knowledge for this

@mk26710 That makes sense, good luck and thank you for trying! And again my sorry if I just end up wasting your time and you can't get it.

It's alright, nothing bad in trying something new


Ability to not generate certain routers

Problem
Some of the models created in Prisma schema are not meant to be touched by the frontend at all. As an example, VerificationToken from the NextAuth is not something I want to be able to interact with from the client-side - I want to leave it to NextAuth to deal with it.
Suggested solution
It would be great to be able to disable the generation of a router for the Prisma model by using a simple comment, something like following:
// @trpc-ignore
model VerificationToken {
  ...
}

I understand that it's not as straightforward as just ignoring the model, since other models might reference the ignored one. In this case, the other model's router should also not include the ignored model, so the property that references it should be removed.
Alternatives
If this feature already exists, would be nice to have it documented in README

@omar-dulaimi Seems to work for me. Maybe it would also be useful to add a relation to the hidden "Map" model in the example schema? This would test the hiding of the parameter when it's referenced from somewhere? This would test  Something like this:
model Post {
  id        Int      @id @default(autoincrement())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
  title     String
  content   String?
  published Boolean  @default(false)
  viewCount Int      @default(0)
  author    User?    @relation(fields: [authorId], references: [id])
  authorId  Int?
  likes     BigInt

  books Map[]
}

/// @@tRPCGen.model(hide: true)
model Map {
  key    String @id
  value  String
  Post   Post?  @relation(fields: [postId], references: [id])
  postId Int?
}

Released in https://github.com/omar-dulaimi/prisma-trpc-generator/releases/tag/0.7.0