Pass continuation for handling ledger events

Note
This works goes is complementary to the work done in cardanosolutions/cardano-node. In particular, the following pieces:

https://github.com/CardanoSolutions/cardano-node/blob/release/8.1.2/cardano-node/src/Cardano/Node/Run.hs#L176-L185
https://github.com/CardanoSolutions/cardano-node/blob/release/8.1.2/cardano-node/src/Cardano/Node/LedgerEvent.hs
https://github.com/CardanoSolutions/cardano-node/blob/release/8.1.2/cardano-node/test/Test/Cardano/Node/LedgerEvent.hs

See commit history for details.

Problem
The Cardano ledger rules are complex and aren't getting easier. This complexity stems from the rules themselves and the various patches that occurred during the development lifecycle (e.g. intra-era hard forks). Some of the information computed by the ledger is made readily available to client applications through the local-state-query protocol.
However, this comes with a few limitations:

The local-state query can only query information that the ledger has. Yet, the ledger can only rewind up to $\frac{3 \times k}{f}$ slots in the past. This pertains to the security of the consensus protocol and the need to roll back to some old state -- but not too old. Accessing historical data from the ledger is, therefore, not possible.

The information exposed via the local-state-query protocol is already aggregated in a way suitable for the ledger but not necessarily for client applications.

To cope with (1) and (2), the ledger eventually introduced Ledger Events into the small-steps semantic. For a couple of eras, the ledger emits them as it validates blocks. Events contain various kinds of useful information. However, at the moment, ledger events are only available to clients who have access to the entire ledger state in a fold-like Haskell API: foldBlocks. This is, in particular, used by cardano-db-sync.
Yet, this method is inconvenient for it requires client applications to hold a copy of the ledger state in memory and redo all calculations. This is rather inconvenient, even for Haskell applications, as it dramatically increases the resources needed by that application (as of today, the ledger-state(s) on mainnet requires 13-15GB of RAM!). Moreover, it is simply unusable outside of the Haskell landscape, for it is a Haskell-only interface.
Solution
Command-sourcing vs. Event-sourcing
From the point of view of software architecture, the Cardano ledger (and node) are designed as a Command-sourced system: What's persisted is a sequence of blocks which act as commands whereby each block applied on ledger state yields a new version of the ledger state. This works because the rules that govern application of blocks on ledger state are deterministic thus guaranteeing application of the same sequence of blocks on the same starting point will yield the same final state on any system running nodes with the same version.
This is great but is has one drawback: In order to compute the state-transition function, fully or partially, one has to know the exact set of rules to implement, eg. one has to run a ledger which is not a trivial thing to do as it requires a lot of resources (see above) and is not easily portable.
Events on the other hand, do not require such knowledge because they are its results: There's nothing more to compute, they are the direct result of the consensus and do not need to be verified. They are therefore intrinsically easier to understand, more portable, can be interpreted partially in any way the client sees fit, etc.
The proposed change combines the benefits of both approaches making Cardano even more flexible and open.
State of affairs
Since the ledger/node already calculates and emits those events -- since, by nature, it has access to the ledger state, our idea is to bubble up those events into a language-agnostic interface usable by local clients. We observed that events were currently discarded by the consensus layer, which remains the main driver of the block application. From the Abstract API of the consensus, we see the following:
https://github.com/input-output-hk/ouroboros-consensus/blob/49c7f76175b431ba4e9d16aa959db234cc6772bd/ouroboros-consensus/src/ouroboros-consensus/Ouroboros/Consensus/Ledger/Basics.hs#L71-L75
https://github.com/input-output-hk/ouroboros-consensus/blob/49c7f76175b431ba4e9d16aa959db234cc6772bd/ouroboros-consensus/src/ouroboros-consensus/Ouroboros/Consensus/Ledger/Abstract.hs#L80-L89
LedgerResult contains both the new ledger state (a, instantiated later) and a list of all events resulting from this block application. However, those events are, in fact, discarded by the actual implementation of the abstract interface:
https://github.com/input-output-hk/ouroboros-consensus/blob/49c7f76175b431ba4e9d16aa959db234cc6772bd/ouroboros-consensus/src/ouroboros-consensus/Ouroboros/Consensus/Storage/LedgerDB/Update.hs#L114-L127
https://github.com/input-output-hk/ouroboros-consensus/blob/49c7f76175b431ba4e9d16aa959db234cc6772bd/ouroboros-consensus/src/ouroboros-consensus/Ouroboros/Consensus/Ledger/Abstract.hs#L160-L166
Ledger events continuation
Using a continuation-passing style approach, we want to provide a handler which can be executed for each event. Using a continuation, we can easily turn off any event handling in situations where it does not matter or could even be harmful to performances (e.g. block producers). It also strikes the right balance between flexibility and intrusiveness as it only requires threading a simple function from the top-level of the call stack down to applyBlock.
So, we introduce the following continuation:
Monad m => AuxLedgerEvent l -> m ()

Where m is eventually IO and AuxLedgerEvent l a multi-era ledger event GADT from the cardano-ledger. From the consensus standpoint, this bubbles up to the NodeArgs record object into a new field:
rnHandleLedgerEvent :: AuxLedgerEvent (ExtLedgerState blk) -> m ()

The NodeArgs is ultimately created by the cardano-node wrapper, where the consensus, ledger, networking and plutus layers get stitched together.
Cardano-node event hook
From there, it becomes straightforward to expose the ledger events in the cardano-node directly by hooking into handleNodeWithTracers and runNode.
At the moment, our proof of concept mounts a superficial server listening on a TCP socket and streaming all events back to a client application. All events are indexed by the slot number and the header hash of the block which "produced" them. This index is necessary to allow clients to detect and deal with chain switches (a.k.a. rollbacks). With such an interface, filtering and aggregating events is thus the client's responsibility.
To make the event handler optional, we've integrated the handler up inside the cardano-node command line with a new optional flag, --ledger-event-handler TCP/PORT. When present, the option should point to a port that the cardano-node will bind to and stream events. If omitted, we fall back to the original behaviour of the node, which is to ignore all ledger events.
Ledger event serialization
We have to settle on a transport format to write events to a socket/file and stream them to a client. Hence, we've opted for CBOR, which is already pervasive across the Cardano interfaces and suitable for networking serialization. We have, therefore, added CBOR encoders and decoders for most ledger events. This currently lives in a fork of the cardano-node with the intention to eventually live in the cardano-ledger itself.

Note
To ease the manipulation of the ledger events, we map them into a custom, era-independent, LedgerEvent data-type. However, we preserve the era during serialization since it is known from the BlockType GADTs coming with each block.
https://github.com/CardanoSolutions/cardano-node/blob/a01ee644a8eb25ac027ca3a7b625ea9584fcd2f2/cardano-node/src/Cardano/Node/LedgerEvent.hs#L733-L742
The codec Version is determined from the block's era and serialized with the event to allow clients to deserialize events accordingly.

We have documented the on-the-wire format of all the mapped events using a CDDL specification. We've added descriptions and details from the (outdated) LedgerEvents.md document from the cardano-ledger, as well as from our understanding from reading the ledger rules and asking questions around. We invite the ledger team to review that document.
Use-cases
Explorers: historical rewards
Many tax jurisdictions require Ada holders to keep track of their rewards. As we explained earlier, this currently limits the options in tooling to cardano-db-sync, which introduces a massive cost in resources on any machine. Most commercial laptops cannot afford to run both the cardano-node and cardano-db-sync due to their resource usage. For 3rd party services which provide such access, the cost of running this infrastructure is also significant. It also adds complexity and increases the probability of faults. There have been several reports of bugs and inaccuracy in the past due to the logic duplication occurring between the cardano-ledger and cardano-db-sync.
By streaming events directly from the node, we reduce complexity, resource usage, and the risk of 'getting it wrong'. The Cardano Foundation is particularly interested in this feature to power its new explorer and a number of similar use cases to help onboard financial institutions.
Mithril: Stake distribution & more
The Mithril signature depends on the knowledge of the stake distribution, which is currently acquired through the cardano-cli relevant command. However, as a mithril-signer or aggregator needs access to a cardano-node anyway to know what data to sign, it would make sense for it to interact with the node in a more direct way, e.g using the mini-protocols.
Being notified of the stake distribution changes immediately, ideally through a mini-protocol delivering those events, would streamline the integration between mithril and Cardano.
Moreover, while mithril-signers currently sign the full node DB only, providing other data "certified" by a Mithril certificate, like Rewards, is certainly planned.
Long-term vision
With this first proof-of-concept, we've been able to stream events from the ledger to a file and re-compute the entire reward history of some stake credentials using only ledger events. This current proof-of-concept has a few limitations, which we acknowledge:

It only allows a single client connection.
It doesn't allow clients to resume synchronization from an arbitrary point. It continues where the ledger is at.
From (2) means that if the client loses the connection, it may miss events.

While it is sufficient to demonstrate the capabilities, we envision this becoming a more robust mini-protocol akin to the local-chain-sync protocol. Implementing such a protocol requires the node to store all ledger events and be able to rapidly search for them using chain points (block header hash + slot number). A chunk-based approach with indexes similar to the one used for the immutable and volatile db could work nicely.
This idea is similar to the one proposed in CIP-0078, though we propose to make an entirely new protocol for the following reasons:

It's decoupled from the local-chain-sync protocol, meaning we don't need to make any existing interface more complex. The added complexity can be segregated out.
It's nicely complementary to the local-chain-sync. Indeed, the latter is akin to a command-based interface (pushing to clients the outcome of observing an event), whereas the local-event-sync (or whatever it is called) would offer an event-based interface to let clients decide how they intend to process those events.

Note
The long-term vision is something up for discussion. The current PR has yet to intend to introduce any of this. Currently, we are solely interested in the continuation described earlier.

cc @abailly-iohk @koslambrou

@nfrisby Thanks a lot for such a quick review! The ship hasn't actually sailed and this is really preliminary work to gather feedback and insights from consensus and node experts. As pointed out by Matthias, the way to actually shovel that information towards clients through the node is an open space: We choose a very simple solution that works for a simple use case, there might be a lot of other options to consider and experiment with (have an EventsDB for example).

While it is sufficient to demonstrate the capabilities, we envision this becoming a more robust mini-protocol akin to the local-chain-sync protocol. Implementing such a protocol requires the node to store all ledger events[...]

Right, events must be stored if we want a design that does not involve clients computing them.
There's then two approaches to that:

make the node do it
have another client do it

The advantage of 1 is that it avoids ever having two copies of the ledger state (currently in memory, but in future on disk). The disadvantage of 1 is that it goes against one of the general design principles of the node: have the node only compute and store what it needs.
The advantage of 2 is that it does go with the existing node design principles, where the node provides the raw data but other clients provide the data in other ways that are more useful to applications. So that's things like db-sync, other indexers, ogmios and other event APIs.

@dcoutts I'd honestly be okay with that responsibility falling on a client if-and-only-if there are easy ways for a client to rollback the node to a specific state. This becomes necessary in rare situations where connections are lost and one need to recover some lost events.
At the moment, this is only achievable by manually removing .chunk files from the immutable/volatile databases (😶 ... ). This isn't the most convenient. I think it's reasonable to assume that a client storing events would know where it needs to starts over (as a chain point). All that's missing is the node to make it easy to restart from any given point.

@KtorZ if a dedicated client is doing it, i.e. storing all the events and making them available to other applications (e.g. something like Ogmios) then there's no need for any changes in the node at all. It is already possible to follow the chain with a ledger state, as cardano-db-sync demonstrates. (Yes, it should be easier to write such applications using the Cardano API, but that's another story.)
So imagine a client with a combo of features from db-sync and Ogmios:

it follows the chain itself, with its own copy of the ledger state (like db-sync)
it can start after the node, and catch up from being offline (like db-sync)
it serves other clients a chain and ledger events in a suitable format (like Ogmios)

This is possible today, without any node changes (though it could be easier with some Cardano API improvements).
There key thing is don't insist that there is only ever one copy of the ledger state. Allow this dedicated client to have its own copy. Then there's no tricky synchronisation problems or extra features needed from the node, or need to wind back or anything.

@dcoutts It is already possible to follow the chain with a ledger state, as cardano-db-sync demonstrates. (Yes, it should be easier to write such applications using the Cardano API, but that's another story.)

It is possible but unpractical (hence the current PR) as clients must hold on the ledger state and keep a (multiple GBs) copy of it in memory (surely UTxO on-disk storage will alleviate that resource constraint, but will come at a cost of much more implementation complexity).

@dcoutts This is possible today, without any node changes

It is, but the developer experience is atrocious. What you're describing is the current state of affairs which we deem unsatisfactory. The current situation (having a client follow the chain and replicate the ledger state) is precisely why we seek alternative solutions.

@dcoutts There key thing is don't insist that there is only ever one copy of the ledger state. Allow this dedicated client to have its own copy.

If it were easy to build such a copy without the cardano-ledger libraries, then I could hear the argument. Nevertheless, as it stands, the specs are insufficient to build another valid implementation. And even with complete and precise specs, this is a costly and cumbersome endeavor which we generally do not want to consider lightly.
So what you're describing is only possible for clients that would be written in Haskell, which excludes a large part of the ecosystem.
Rather than re-doing the ledger calculations (might it be in Haskell or not), it seems to me that working out an API to make ledger events accessible is a relatively low-hanging fruit. As demonstrated by this PR, a couple of days of work suffices. And allowing the node to rollback its volatile/immutable db should be quite straightforward as well.
Surely bundling that as a full mini-protocol is more work. But this isn't what we're asking here.

what you're describing is only possible for clients that would be written in Haskell, which excludes a large part of the ecosystem.

I think that's a key point here, thanks for emphasizing it @KtorZ! And all the other points of course :)
This proposed change is a first step, the beginning of a journey towards making the cardano data more open. It's a very minimal change to the consensus, which might or might not lead to changes in the mini-protocols, in the node, in specialised versions of the node, in clients...

So what you're describing is only possible for clients that would be written in Haskell, which excludes a large part of the ecosystem.

You're missing my point. I also agree that applications need to be in any language the author chooses.
The architecture is intended to look like this:
node -> api adaptor -> application
API adaptors here include things like db-sync and Ogmios. Yes it is intended that these adaptors be written in Haskell, and provide language neutral APIs to other applications.
So I'm not proposing you write all your applications in Haskell. I am proposing that this adaptor be written in Haskell (just as it would be if the feature were somehow integrated in the node).

This proposed change is a first step

Note that it does not get one any closer to the desired design, including the design proposed in this ticket.

While it is sufficient to demonstrate the capabilities, we envision this becoming a more robust mini-protocol akin to the local-chain-sync protocol. Implementing such a protocol requires the node to store all ledger events and be able to rapidly search for them using chain points (block header hash + slot number).

This design idea does not need this continuation PR, it needs something different and rather larger. Or the client based approach I propose needs no change in the node at all (but would benefit from improvements to the Cardano API instead).

@dcoutts API adaptors here include things like db-sync and Ogmios.

This echoes what I wrote in introduction of this PR, and why I think the current status quo isn't satisfactory:

@KtorZ: This currently limits the options in tooling to cardano-db-sync, which introduces a massive cost in resources on any machine. Most commercial laptops cannot afford to run both the cardano-node and cardano-db-sync due to their resource usage. For 3rd party services which provide such access, the cost of running this infrastructure is also significant. It also adds complexity and increases the probability of faults.

Surely we can write another adaptor trying to solve some of those problems, but I'd rather not to. Even cardano-db-sync is moving away from that with the recent introduction of a "no-ledger-state" mode.

@dcoutts: The architecture is intended to look like this: node -> api adaptor -> application

Perhaps then I am simply challenging that vision. I do see a world where we also have many: node -> application. This is actually happening. The node-to-node and node-to-client network interfaces have already been (partially) re-implemented:

In Rust: https://github.com/txpipe/pallas
In Go: https://github.com/blinklabs-io/gouroboros
In JavaScript: https://github.com/StricaHQ/ouroboros-network-js
In Java: https://github.com/bloxbean/yaci

Point being that people do not want to work with a middleware. It usually adds cost and complexity (more things can go wrong). Since the community of builders is already walking down that path, why not make it easier for people to harness what's currently available -- especially when they are relatively low hanging fruits.

@dcoutts: Note that it does not get one any closer to the desired design, including the design proposed in this ticket.

I concede that this doesn't get us closer to the "long-term vision" (which we should probably call an "alternative vision") from a design perspective. But it does one important thing: it makes ledger events available so that client applications can start relying on them.
Whether they get the events via an event stream from a socket or through a more sophisticated mini-protocol doesn't invalidate that. Clients can start thinking in terms of what's now possible to build with these instead of being forced into one particular design (i.e. cardano-db-sync).

@dcoutts: This design idea does not need this continuation PR

Correct. This PR is an intermediate solution that far easier to implement than the mini-protocol approach. It has the main benefit of being non-intrusive and easily turned off in the case of block producers. The reason this PR exists is because there are far less discussions needed to approve it than what it would take to design a complete mini-protocol. So its chances of being accepted are high(er).
Now, if we ever get to make a move on the mini-protocol idea, I am more than happy to come, remove and clean up whatever this PR introduces. Pinky promise.

Or the client based approach I propose needs no change in the node at all (but would benefit from improvements to the Cardano API instead).

But that requires the client to run a process with uses more that ~10GB of RAM. That's exactly what we're trying to avoid. If the counter argument is that we'll have the LedgerState computed stored on disk, then the question is: when? My guess is that it's going to take a while, and we need a solution now, and this solution provides a quick way to for clients to get the info.

The disadvantage of 1 is that it goes against one of the general design principles of the node: have the node only compute and store what it needs.

To clarify, are you referring only to cardano-node, or are you also including ouroboros-consensus? You can imagine users building their own nodes with different capabilities using what is provided by ouroboros-consensus. Then no changes would actually be required in cardano-node.

Lets try and classify designs here. There's three:

the "intermediate" one proposed in this PR where ledger events are streamed live to one client
the "node storage" one, where the node stores all ledger events and can provide them to any client
the "client storage" one where a dedicated node client stores ledger events and can provide them to any other client

Now I argue that design 1 is not something that people will actually want to use, and nor is is something the node team would want to support. It is not nearly as useful as it looks: there's no way to get events for old blocks, so a client cannot start late or reconnect. There's no sensible way to synchronise the client with the node. It also means the node is limited by the speed at which the slowest client can consume the events. This is different to how the local chain sync works which does not block the progress of the node growing its chain, irrespective of how slow or late clients consume blocks. Trying to run a node in this mode means it is really being run as a client, and cannot follow Ouroboros in timely manner.
More generally, these problems are not specific to the proposed intermediate design. As far as I can see any design that tries to have just a single copy of the ledger state is going to have these problems. It means the ledger state (and thus progress of the chain) has to be synchronised between the node and a client.
Yes it would be nice to avoid needing two copies of the ledger state, but I think that's inevitable for any kind of robust design.

But that requires the client to run a process which uses more that ~10GB of RAM. That's exactly what we're trying to avoid. If the counter argument is that we'll eventually have the LedgerState computed stored on disk, then the question is: when? My guess is that it's going to take a while, and we need a solution now, and this solution provides a quick way to for clients to get the info.

The on-disk storage project has a branch ready for the node that stores the UTxO on disk, and which passes benchmarks for the in-memory backend. We're waiting for system level benchmarks for the on-disk backend.

Point being that people do not want to work with a middleware. It usually adds cost and complexity (more things can go wrong). Since the community of builders is already walking down that path, why not make it easier for people to harness what's currently available -- especially when they are relatively low hanging fruits.

@KtorZ as I'm sure you know, the node is complex and has high maintenance costs. Without middleware we would have to integrate all those middleware features into the node itself. That's not a sustainable architecture, the complexity and resource costs would be unacceptable.
It's fine not to use middleware where what the node can sensibly provide natively is sufficient for applications (i.e. just block streaming), but for extra things like indexing, or indeed storing and providing ledger events, the sensible thing is to use middleware.
The real problem, imho, is that we've not put enough effort into making it easy to develop such middleware. It should be easy to write such things using the Cardano API, but it's currently much harder than it needs to be. We've got a proof of concept with foldBlocks, but we need support for snapshots and re-syncronising when a client starts up (i.e. what cardano-db-sync does, but with far too much extra code).

BTW, how does the intermediate design support switching forks? With local chain sync, that's built in, but with live streaming? :grimacing:

@dcoutts Thanks for enaging in the above discussion.
Regarding your latest question:

BTW, how does the intermediate design support switching forks? With local chain sync, that's built in, but with live streaming? 😬

This is something we did discuss during the Consensus Office Hours yesterday.
I have an action item to write the summary as comment on this PR, but I've been preparing for my flight to Paris that departs in a few hours, so that will hopefully happen before Monday.

My notes summarizing our Consensus Office Hours call on Oct 12 were far too big for a GitHub comment, and deserve review.
So I opened a dedicated Draft PR for them: https://github.com/input-output-hk/ouroboros-consensus/pull/440


bump to 16.0.0.rc2

@h-vetinari Sorry for the noob question but is there anyway to conda install from this (the rc) branch?

@h-vetinari Sorry for the noob question but is there anyway to conda install from this (the rc) branch?

No worries. You should be able to install it like:
conda install mlir -c conda-forge/label/llvm_rc -c conda-forge

You'll still have to wait for the builds after the merge to finish though (and make it through the CDN). Give it another ~3h (especially as the CI didn't trigger after merging #32, so there aren't even builds for rc1).

@h-vetinari Sorry for the noob question but is there anyway to conda install from this (the rc) branch?

No worries. You should be able to install it like:
conda install mlir -c conda-forge/label/llvm_rc -c conda-forge

ahh I tried conda-forge/label/mlir_rc because I saw that string somewhere in one of the CI test logs.

You'll still have to wait for the builds after the merge to finish though (and make it through the CDN). Give it another ~3h (especially as the CI didn't trigger after merging https://github.com/conda-forge/mlir-feedstock/pull/32, so there aren't even builds for rc1).

okay cool I'll give it a try tomorrow morning.
Anyway god bless you for putting this together - until now I've been relying on my own release builds of LLVM purely to get precompiled MLIR (and as you can surmise from the Actions tab, it's been brutal getting everything lined up).

ahh I tried conda-forge/label/mlir_rc because I saw that string somewhere in one of the CI test logs.

You're right actually, you'll also have to add -c conda-forge/label/mlir_rc; I forgot that mlir uses a different label than the rest of the LLVM rc's.

Anyway god bless you for putting this together - until now I've been relying on my own release builds of LLVM purely to get precompiled MLIR (and as you can surmise from the Actions tab, it's been brutal getting everything lined up).

This feedstock was mostly the work of @isuruf & @xhochy, but happy to help. LLVM is a big baby 😅

@h-vetinari no dice; I've tried a couple of different permutations of this
loopy) mlevental@maksims-MacBook-Pro py311 % conda install mlir -c conda-forge/label/llvm_rc -c conda-forge/label/mlir_rc -c conda-forge
Collecting package metadata (current_repodata.json): done
Solving environment: done

## Package Plan ##

  environment location: /Users/mlevental/miniforge3/envs/loopy

  added / updated specs:
    - mlir

The following NEW packages will be INSTALLED:

  llvm-tools         conda-forge/osx-arm64::llvm-tools-15.0.7-h62b9111_0
  llvmdev            conda-forge/osx-arm64::llvmdev-15.0.7-h62b9111_0
  mlir               conda-forge/osx-arm64::mlir-15.0.7-hcb86549_0

and I always get 15.0.7

I don't see how you can get the correct llvmdev dependency without also specifying -c conda-forge/label/llvm_rc. Normally the quotes shouldn't be necessary. In any case, happy to hear you're making progress

I don't see how you can get the correct llvmdev dependency without also specifying -c conda-forge/label/llvm_rc. Normally the quotes shouldn't be necessary. In any case, happy to hear you're making progress

You're correct that indeed I did need to include that channel as well - sorry I emphasized the wrong thing in that reply - I meant to put emphasis on mlir=16 because prior I was having trouble getting conda to see the 16.0.0.rc2 release and not the ~14.0 release.


timeref: Add support for --start "system"

For the plugin timeref the parameter --start has now a new predefined value "system". This value will read the system clock and uses it.

Hi @lars18th
Thank you for your last two contributions. I maintain a list of people who contributed to the project in a file named CONTRIBUTORS.txt. If you would like to add your name here (and you deserve it), please send me your name at<EMAIL_ADDRESS>Note that only real names are added.


Ensure CoinsPF2e objects have positive integer values

Also update add/remove coins popups to enforce the same

I can understand enforcing it at the dialog level, but currently that's the only way to subtract coins using that utility (and it might even be a good refactor to convert removeCoins into doing coin math then updating the actor's state to match). I'll have to double check if ItemPiles uses it soon.


The PDF download is not working, and sometimes the page does not save the changes.

Is there an existing issue for this?

[X] Yes, I have searched the existing issues and none of them match my problem.

Product Variant
Cloud (https://rxresu.me)
Current Behavior
The PDF download is not working, and sometimes the page does not save the changes.
Expected Behavior
No response
Steps To Reproduce
No response
What browsers are you seeing the problem on?
No response
What template are you using?
None
Anything else?
No response

When generating PDFs, headless Chrome needs to download and import fonts from the internet. If the network environment is poor and loading times out, it can cause the PDF export to fail. I think it might be better to store the font files as static files in MinIO or on a server.

I found a solution:

Open Sharing: toggle Public On, copy URL, open in new tab
Print to PDF: click Three-dot menu on top right, click Print, choose Save as PDF, Save. (Ctrl/Command + P)
Close Sharing: toggle Public Off !!!

PS: If we had a guide to a private preview page, it would be easy to indirectly solve this problem of exporting PDF and significantly reduce resource consumption.

@Br1Rol2
Did you find any solution?
I dont understand what to fill here
CHROME_PORT=8080
CHROME_TOKEN=chrome_token
CHROME_URL=ws://localhost:8080

i also have the problem. the export runs for some time and is then terminated with a server error.


Implement RenameProvider

https://code.visualstudio.com/docs/extensionAPI/vscode-api#RenameProvider

👍

👍

This is so important functionality that I wonder how it hasn't been implemented in VSCode core. I still use NetBeans PHP for this one, so I hope it gets implemented.
Thank you for this awesome extension!


can't receive notification in ios : sending FcmTokenRefreshed with no listeners registered

i send notification with fire-base, send notification success in firebase but in ios app i have this error : "sending FcmTokenRefreshed with no listeners registered"
if app opened receive notification but when app closed not receive and show error .
i use react-native-fcm.

excuse me for bad English!

"react": "16.4.1"
"react-native": "0.55.4"
"react-native-fcm": "^16.2.4",
"xcode 10.1"

1+


Parallelizable test

update tests to run parallel
update nunit
update webdriver
disable screenshot maker due firefox bug

@miyconst Could you please review? Does it work like you wanted https://github.com/StarcounterSamples/KitchenSink/pull/62 to work?

@warpech you never stop working, even at the airport :). Will check it as soon as I get home.

Yes. This is something I wanted. @KmaTTi89 could you please share numbers? How much time do we save by executing it in parallel? Unfortunately I don't have Selenium environment at my home PC to check.

@KmaTTi89 wrote me on Slack that it decreased testing time from 5 minutes to 50 seconds.

On my machine the running time is decreased from 6m15.711s to 3m52.919s.
Measured using time cmd //c "test.bat" in Git Bash.

Old build on TeamCity: about 5 minutes
New build on TeamCity with Parallel tests: about 1 and a half minute


Graphs section breaks responsive layout

The graphs section breaks the layout and needs style adjustment.
@mikiobraun What do you think if in the meanwhile we move this functionality on its own branch until is ready?

Can you be more specific what the issue is and what would be needed to fix it? I'd rather we try and fix it now. Now is as food as ever. Can't guarantee I'll have more time later.
----- Ursprüngliche Nachricht -----
Von: "Ruben Barilani"<EMAIL_ADDRESS>Gesendet: 12.09.2015 14:11
An: "zalando/zalando.github.io-dev"<EMAIL_ADDRESS>Cc: "Mikio L. Braun"<EMAIL_ADDRESS>Betreff: [zalando.github.io-dev] Graphs section breaks responsive layout (#16)
The graphs section breaks the layout and needs style adjustment.
@mikiobraun What do you think if in the meanwhile we move this functionality on its own branch until is ready?
—
Reply to this email directly or view it on GitHub.

@mikiobraun
Well First, I don't know if such "complex and detailed graph" fit the purpose of the organization page. It seems more interesting to put that in our internal page (in the tech wiki).
Second, as it is, it breaks the layout if you try to re-size the page.
Third, if you try to re-size the page the top navigation is broken because it was simply implemented to handle only two menu entry.

The graphs were specifically requested by Jan, so I guess you'd need to discuss with him whether it makes sense.
Concerning the resizing, I had set the flag in the configs and I remember that it also used to work. Maybe something happened there and it's broken? Resizing is a bit complicated because as the raph is based on d3, it is really just a fixed sized svg image. I had tried catching the event and explicitly resizing, but that didn't work.
Maybe there is a way to fix the top navigation?
In any case, I would hate to see these changes go, especially they were the only contribution on the frontend from our onboarding project. Maybe we can both find time to sit together for half an hour next week and try to fix it? I could definitely benefit from some support there.

Yep, of course, keep on touch for this week. I will try to start fixing the top navigation. Let's commit on this branch topic/graphs

Close this for now. We have to disable the plot until is fixed and approved. #19


Structure layout reuse does not enumerate structure member count

The following GLSL fails spvReflectCreateShaderModule when calling ParseDescriptorBlockVariableUsage on the second member "b":
#version 460 core
#extension GL_EXT_buffer_reference : require
#extension GL_EXT_shader_explicit_arithmetic_types_float32 : require
#extension GL_EXT_shader_explicit_arithmetic_types_int64 : require
#extension GL_EXT_shader_explicit_arithmetic_types_int32 : require

layout(local_size_x = 1, local_size_y = 1, local_size_z = 1) in;

layout(buffer_reference, buffer_reference_align = 4) readonly buffer ReadVecf
{
    float32_t values[];
};

layout(buffer_reference, buffer_reference_align = 4) writeonly buffer WriteVecf
{
    float32_t values[];
};

layout(push_constant, std430) uniform Parameters
{
    ReadVecf a;
    ReadVecf b;
    WriteVecf c;
    uint64_t n;
} params;

void main()
{
    uint32_t idx = gl_GlobalInvocationID.x;
    uint32_t stride = gl_NumWorkGroups.x * gl_WorkGroupSize.x;
    for (; idx < params.n; idx += stride) {
        params.c.values[idx] = params.a.values[idx] + params.b.values[idx];
    }
}

The following GLSL succeeds:
#version 460 core
#extension GL_EXT_buffer_reference : require
#extension GL_EXT_shader_explicit_arithmetic_types_float32 : require
#extension GL_EXT_shader_explicit_arithmetic_types_int64 : require
#extension GL_EXT_shader_explicit_arithmetic_types_int32 : require

layout(local_size_x = 1, local_size_y = 1, local_size_z = 1) in;

layout(buffer_reference, buffer_reference_align = 4) readonly buffer ReadVecf
{
    float32_t values[];
};

layout(buffer_reference, buffer_reference_align = 4) readonly buffer ReadVecf2
{
    float32_t values[];
};

layout(buffer_reference, buffer_reference_align = 4) writeonly buffer WriteVecf
{
    float32_t values[];
};

layout(push_constant, std430) uniform Parameters
{
    ReadVecf a;
    ReadVecf2 b;
    WriteVecf c;
    uint64_t n;
} params;

void main()
{
    uint32_t idx = gl_GlobalInvocationID.x;
    uint32_t stride = gl_NumWorkGroups.x * gl_WorkGroupSize.x;
    for (; idx < params.n; idx += stride) {
        params.c.values[idx] = params.a.values[idx] + params.b.values[idx];
    }
}

I haven't narrowed down exactly why this is the case yet, but I at least have a work around for now.

@muraj thanks for reporting! I can reproduce this crash, there has been some edge cases around GL_EXT_buffer_reference I see are not fixed. I can take a look later this week/weekend

so took a stab quick, the core issue is we added protection from going
layout(buffer_reference) buffer t1;
layout(buffer_reference) buffer t2;

layout(buffer_reference, std430) buffer t1 {
    t2 i_1;
};

layout(buffer_reference, std430) buffer t2 {
    t1 i_2;
};

and getting into a recursion for loop
Need to make that check smarter to realize that these are 2 are called from same struct, so if one is safe, the other is as well


Remove user: Internal server error (java.lang.NullPointException)

After updating to the latest Docker & yml files, I created some new users via the admin interface. When deleting them: Internal server error.

You have the wrong image, but it's our fault.
So, in the compose file app.yml (or app-single.yml) user this image:
arcadeanalytics/arcadeanalytics:1.0.0-RC1
instead of
arcadeanalytics/arcadeanalytics:latest
And check againg

That works. Thanks!


Dynamic slot name bound from v-for directive not working with scoped slots

Version
2.3.2
Reproduction link
https://jsfiddle.net/frctmhLd/3/
Steps to reproduce
Create a scoped slot using the
What is expected?
The slot is loaded and display correctly
What is actually happening?
Dynamic properties don't seem to work on the

Not sure how to label it so, labelling it as improvement and bug

@posva @sparamasivan   Am I missing something? There are two root elements in the parent compoent, so an error is reported.
Vue.component('parent', {
    template: '' +
    	'<child>' +
      	'<template :slot="test" scope="props">' +
        	'
{{props.text}}
' +
        '</template>' +
      '</child>' +
    	'<child>' +
      	'<template v-for="slotName in slotNames" :slot="slotName" scope="props">' +
        	'
{{props.text}}
' +
        '</template>' +
      '</child>',
    data: function () {
      return {
        slotNames: ["test", "test1", "test2"],
        test: 'test'
      }
    }
});

@defcc Oh, sorry, I forgot to update the repro, yeah, it's wrong, but adding a single root element still showcases the problem (https://jsfiddle.net/frctmhLd/3/)

I also updated the demo here.  https://jsfiddle.net/frctmhLd/4/
Seems to be a bug with scoped slots.

Thank you folks for fixing this.


HLS Adaptive Bitrate Files Not Generated

Summary
The manifest file under /opt/data/hls/<STREAM_NAME>/index.m3u8 does not include any information about resolutions or dimensions, preventing the browser hls player from requesting the appropriate encoded video as per resolution and network latency.
Reproduction

Clone repo
Run docker compose up
Open OBS --> Settings --> Use rtmp://localhost:1935/hls for Custom Server with stream key hello as shown below.

Request http://localhost:8080/live/hello/index.m3u8 from any HLS player  from the browser.
Throttle network speed in DevTools as shown below (Chrome browser)

Observe payload size of each .ts segment is the same, causing buffering
Inspect files in docker container under /opt/data/hls/hello. No adaptive resolution files found.

Video Walkthrough
screen-capture_960x720.webm

I figured it out, was not an issue after all, thanks.


Possibility to clear cache from custom memoize-function

I would need the possibility to clear the cache at a certain point of the application. In this particular situation lodash memoize is used.
Would be nice if you could expose the memoizedResultFunc

Resolved by #519 !


how to use the python script as module?

hey, i'm trying to write a python script and would really like to use your script in it,
how to use your script as module and what are the arguments i can pass?

In the beginning it was meant to be easy to use as package, but I slowly dropped that to just make it work as a complete app.
But, most of the arguments that can be passed are located in src/subsearch/data, the modules constants and data_classes.
src/subsearch/utils io_app has some paths and the default config values that gets loaded if there is no config file or something is missing
There used to be documentation all the classes and functions, in version 2.38.0 and below, but never kept it up to date, but might help you to understand the code better.


Load the list of supported regions

Load the list of supported regions from the encryptor AMI endpoint,
instead of hardcoding.

LGTM


fix OrderedMap copy constructor

Issue details
Despite the recent fixes to the maps copy constructors, the OrderedMap copy constructor was still broken. This is due to the fact that all it did was call the super copy constructor from ObjectMap and initialized the keys array to an empty array instead of filling it with actual values.
Reproduction code
public class MapTest {

	public static void main(String[] args) {
		OrderedMap<String, Integer> map = new OrderedMap<String, Integer>();
		map.put("a", 1);
		map.put("b", 2);
		map.put("c", 3);
		System.out.println("map: " + map);

		OrderedMap<String, Integer> copy = new OrderedMap<String, Integer>(map);
		System.out.println("copy: " + copy);
	}
}

Ouput:
map: {a=1, b=2, c=3}
copy: {}

Solutions
I saw 3 solutions to solve this:

Change the copy constructor from OrderedMap(ObjectMap) to OrderedMap(OrderedMap). This allows to copy the keys array as well. The downside is that this is an API change, but based on the fact that this bug only came up now, I'm not sure many people are actually creating OrderedMaps from ObjectMaps.

Do a call to putAll from the copy constructor. This will fill the keys array properly. It doesn't break the API but it's not very efficient.

Have both constructors.

I went for the first solution, but let me know if it's not a good idea. I also added an iteration test to the CollectionTest to properly catch this issue.

Can you fix up the merge conflicts? @NathanSweet can you give this a look?

Done. Also, I found another bug with OrderedMap when performing an iterate and remove loop (with Iterator.remove). I know that one pull = one fix, but it'd be great that this 2nd bug get merged at the same time. Can I add the commit here (it's a one line fix) or should I make another pull request?

Added the fix for the OrderedMap.remove function. Here is the reproduction code of the issue:
public class MapTest {

	public static void main(String[] args) {
		OrderedMap<String, Integer> map = new OrderedMap<String, Integer>();
		map.put("a", 1);
		map.put("b", 2);
		map.put("c", 3);
		map.put("d", 4);

		Iterator<Entry<String, Integer>> it = map.iterator();
		while (it.hasNext()) {
			Entry<String, Integer> entry = it.next();
			if (entry.key.equals("c")) {
				it.remove();
			}
		}

		System.out.println("map: " + map);
	}
}

Before the fix, this would throw an IndexOutOfBoundsException

@badlogic @NathanSweet could someone give this a look? I'm using a workaround meanwhile but it'd be nice to have both fixes merged at some point.


spike: explore options for schema on a Topic resource

as part of this effort, we should evaluate whether the Spring Cloud Stream schema (and registry) approach is also relevant for riff (would facilitate interop with Spring Cloud Data Flow):
https://docs.spring.io/spring-cloud-stream/docs/current/reference/htmlsingle/#schema-evolution

This issue has gone stale, we're on Knative now! Please reopen if still relevant.


[java] create CI Tool classes instead of using a map of constants

One-line summary
Allow user-defined build name and number as well as better GitHub default
Description
Instead of a complicated map of environment variables, this creates a new class for each CI Tool.
As for GitHub, GITHUB_JOB for this repo is e.g., main, junit5, junit4 (https://github.com/saucelabs/sauce_bindings/blob/main/.github/workflows/java.yml#L62), which isn't super helpful on Sauce —  Automated / Builds/ main: 149 (https://app.saucelabs.com/builds/vdc/c9e1a2beb1b03686b0c248e4dc73921b)
This PR adds GITHUB_WORKFLOW, so it will look like: Java / main: 149. It might be even better to add project? so saucebindings / Java / main: 149?
Also, user can now adjust it to be whatever they want:
System.setProperty("sauce.build.name", System.getenv("GITHUB_WORKFLOW") + " -  " +  System.getenv("GITHUB_JOB"))

SystemManager class also now checks for screaming snake case in environment variables and lowercase dot separated in system properties
Types of Changes

New feature (non-breaking change which adds functionality)

I am unsure if breaking the CI tools apart like this will be helpful in the future,

The main reason I went through this additional trouble is that GitHub doesn't give me sufficiently useful values based on individual environment variables, so I wanted a way to combine several of them.
At the point we do that, we can (should?) allow a user to override the defaults and specify exactly what they want.
As a history note: we no longer want people to use Sauce Bindings without one of the Test Runner libraries. There just aren't good enough benefits to make it worth it. So things you used to be able to do (set custom test names or build names) with Bindings directly, can't be done when using it with a Test Runner library. This makes previous design choices more limiting than originally intended.
So for documenting this... it didn't used to matter, because it's a good default that is much better than nothing if you didn't pass something in. Now it matters a little because we effectively removed the user ability to customize these values directly.

This has been updated based on provided feedback


Prepare to migrate to the new versioning system - part 2

Requirements

[x] Have you ran tests against this code?

Description of the Change
@confused-Techie This is the second part of #64. It contains #62  and #65. Main test is failing on GET package endpoint. The weird thing is that database tests are all passing.

@Digitalone1 I've found the issue that's causing tests to fail.
It's right here (Line 68-73 of utils.js) on the changes to how constructPackageObjectFull functions.
Right here you assign pack.versions as latestVer to newPack but then below you assign newPack.releases.latest to latestVer
Which ends up (Which using language-css as an example giving an object structure like so.
 <ref *1> {
      meta: {
        name: 'language-css',
        keywords: [ 'tree-sitter' ],
        description: 'CSS Support in Atom',
        license: 'MIT',
        engine: { atom: '*', node: '*' },
        dist: {
          tarball: 'https://api.pulsar-edit.dev/api/packages/language-css/versions/0.46.0/tarball'
        }
      },
      engine: { atom: '*', node: '*' },
      semver: '0.46.0',
      license: 'MIT',
      name: 'language-css',
      downloads: '400004',
      stargazers_count: '77',
      versions: {
        '0.46.0': {
          name: 'language-css',
          keywords: [Array],
          description: 'CSS Support in Atom',
          license: 'MIT',
          engine: [Object],
          dist: [Object]
        },
        '0.45.7': {
          name: 'language-css',
          keywords: [Array],
          description: 'CSS Support in Atom',
          tarball_url: 'https://github.com/pulsar-edit/language-css',
          license: 'MIT',
          engine: [Object],
          dist: [Object]
        },
        '0.45.0': {
          name: 'language-css',
          keywords: [Array],
          description: 'CSS Support in Atom',
          license: 'MIT',
          engine: [Object],
          dist: [Object]
        }
      },
      releases: { latest: [Circular *1] }
    }

Essentially this creates an object where the head reference to the object is the same as the releases.latest. Looks like ExpressJS tries to parse the file when it's handed to res.status(200).json(pack) and presumably continues parsing down the circular tree trying to turn it into JSON, which can't be done with a Circular Reference inside it, so stalls out until stopped.
I can't tell exactly what the intention was here, but changing the way the package is handled in utils.constructObjectFull() should resolve the failing tests.

Thanks @confused-Techie for the tip.
What you said made me think and I started to check other parts of the code. I figured out that in git.createPackage we pass the same pack reference to metadataAppendTarballInfo and this leads to appending the tarball data to the same object, overwriting what was store before. So we have to copy the pack object with structuredClone before appending the tarball stuff.
The point of these last changes is to deprecate the use of package.data because we already carry the same information in the meta column of the versions table. The column is still there and is set, but for the moment it's not used, nor selected. In the future we will drop it completely.
Using structuredClone also on the latest version metadata is needed to avoid issues with JSON stringify.
All tests are passing. Switch to ready for review.

@Digitalone1 Looks like our CI is failing, I have a feeling this relates to the use of structuredClone.
The CI tests are using the same version we are in prod with is NodeJS 16.x so the CI itself won't support a Node bump just yet.
If you'd like I can go ahead and author something when I get the chance that bumps Node versions and you can update that here if/when merged.

@confused-Techie CI test passed on v18.
v16 not supported unfortunately.

I think the only thing I'd really love to see (On this PR or another) could be difinitive objects documented somewhere on what some of the DB functions expect. Since they have strayed far away from just expecting a Package Object Full or Package Object Full, so if maybe some JSON files could be added to the docs/resources section that'd be amazing.

Maybe better to take care of this step in the git refactoring.

Yeah good point @Digitalone1 sounds like a plan to me.
In that case let me give your open PR's a second review through and get them merged. Then check of the checklist and get prod updated.


add text gradient to category title.

Use 3 color gradient.
Gradient should be modern and futuristic.

Can you assign this issue to me?

@singhnitin77 Kindly assign me this issue.


App sometimes hanging for me on "loading messages..." on startup

Sometimes when I open the app, it just hangs on "loading messages" and I can't access anything.  One needs to logout and login again to fix the issue.
I bet this shows up in crashlytics, but I can collect a manual log trace if need be.  I bet the issue has to do with get_events not working properly after the event queue has timed out.

in progress


Add instructions to home page

Exactly what the title says.
Need to explain the game controls, as well as the color matching requirement.
Might also want to add some backstory (intergalactic warfare!!) though that could be overkill...

I worked on this during a cheeky lunch break :D
making PR now

lol, woops i didnt add info about the color matching requirements!

[ ] Color matching
[ ] Backstory?


[Fix-13156] [Master] Trigger timing workflow with global variables failed

Purpose of the pull request
this pr closes: #13156
Brief change log
Bug fixed

@caishunfeng PTAL, thx

Please review @caishunfeng

This problem has been fixed in version 3.1.1
#12419

I will close this PR, if you still have problems, you can open it again.


Integration with Open Food Facts

Open Food Facts collects food products from around the world, using mobile crowdsourcing.
It's open data and opensource.
We have barcode data, and product data, including multilingual ingredient lists, multilingual ingredient taxonomies.
github.com/openfoodfacts
world.openfoodfacts.org
We also have a Slack with a Vegan/Vegetarian channel (self invitation at https://slack-ssl-openfoodfacts.herokuapp.com/ )

That's awesome have a nice idea how to do that!

It would be great if we could add more products from users as a result (photos+data)

@teolemon I subscribed to the mailing list. However, can we speak about your api? Is there any documentation?

Can you join the Slack ? That will be easier to chat there.
The API is at : en.wiki.openfoodfacts.org/API

@hmontazeri https://slack-openfoodfacts.herokuapp.com/
url to self invite
also, I'd think there would be a string case for the repo in becoming a core OFF component if you're up for it.


Segue out of RevealViewController

App Structure:
I have a home screen as my frontViewController (currently embedded in a navigation controller) and a menu screen as my rearViewController in the form of a TableViewController.
Pressing different menu items segues the user to different view controllers.

What I Want:
Upon pressing a menu item in the rearViewController, we segue OUT OF the revealViewController with the destination view controller having a back button to "go back" to the home screen. This is different to pushing the frontViewController like in this issue: https://github.com/John-Lluch/SWRevealViewController/issues/644 because I want the new view controller to be "independent"  of the revealViewController -  e.g. swiping left doesn't bring up the menu (I know it could be disabled but seems less elegant).
My problem:
I understand in the image I am not segueing from a navigation controller - but If I were to embed the rearViewController in one segueing from it will only change the rearViewController rather than the whole screen. Similarly If I segue from the frontViewController (have pointer via therevealViewController) I have to ALSO call revealToggle to hide the rearViewController to cover the whole screen.
What I've done:
The above is one particularly non-elegant solution.
Another solution is putting the revealViewController inside a navigationController but I'm not sure I like this, not only is there nested navigation controllers but if we were to hide the interior one the rearViewController doesn't push across the whole screen including the navigation bar.
Apologies for the length, thanks very much!

 UINavigationController
        nc.delegate = self

        nc.pushViewController(controller, animated:true)

        nc.setNavigationBarHidden(false, animated: false)
    }

    // MARK: - UINavigationController Delegate

    func navigationController(_ navigationController: UINavigationController, willShow viewController: UIViewController, animated: Bool)
    {
        if viewController is SWRevealViewController == true {
            navigationController.setNavigationBarHidden(true, animated: true)
        }
    }

    func navigationController(_ navigationController: UINavigationController, didShow viewController: UIViewController, animated: Bool)
    {
        if viewController is SWRevealViewController == false {
            revealViewController().setFrontViewPosition(.left, animated: false)
        }
    }

Thanks very much for the "swift" response ;)
I've put this into the app and it does indeed have the desired behaviour that I'm looking for!
Just a few minor concerns:

With
[self.revealViewController setFrontViewPosition:FrontViewPositionLeft animated:NO];
I find it to be "stuttery" upon returning home after pressing back - animating does reduce the stutter but I'd prefer for there to be no left view at all (i.e. just the home screen if possible...)

An annoying bug - panning the left edge in newly pushed viewController (to go back) only halfway makes this viewController take over the entire screen and seems to get rid of the navigation bar. Perhaps just disabling this pan will suffice.

Is nesting the navigation bars like this definitely OK? That was an original concern.

Instead of:
UINavigationController *nc = (UINavigationController *)[UIApplication sharedApplication].keyWindow.rootViewController
could we just use:
UINavigationController *nc = self.revealViewController.navigationController

Thanks again! Very very useful.

Sorry for Swift version, this is a sample written in Objective-c. We have to play with animated: YES or NO and find the best way.
SWPushOutObjc.zip

That's amazing! Works perfectly. Thanks so much for all your help! :)


[2024] Update Sponsors section

What should be updated?
I would like to jump on this?

hey @mosespace sure, first up you need to get the branch bump-2024-0-0 and open the pr towards that branch.
let me know incase you need anything

for sponsors, we need to have a placeholder as we havent confirmed them yet...happy to guide through


remove secret volume mount from sidecar injector when sds is enabled

https://github.com/istio/istio/issues/9035
when sds is enabled, secret volume mount(to sidecar container's path /etc/certs/) could be removed.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: quanjielin
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: morvencao
If they are not already assigned, you can assign the PR to them by writing /assign @morvencao in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

install/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@quanjielin: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
91e182707afd1474f3b43bc3d60b59618e5476af
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@quanjielin: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
91e182707afd1474f3b43bc3d60b59618e5476af
link
/test istio-unit-tests

prow/istio-presubmit.sh
91e182707afd1474f3b43bc3d60b59618e5476af
link
/test istio-presubmit

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@quanjielin: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-presubmit.sh
91e182707afd1474f3b43bc3d60b59618e5476af
link
/test istio-presubmit

prow/istio-unit-tests.sh
60447c295be26d1459f454897b750efd81efbbff
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@quanjielin: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
60447c295be26d1459f454897b750efd81efbbff
link
/test istio-unit-tests

prow/istio-presubmit.sh
60447c295be26d1459f454897b750efd81efbbff
link
/test istio-presubmit

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@quanjielin: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-presubmit.sh
60447c295be26d1459f454897b750efd81efbbff
link
/test istio-presubmit

prow/istio-unit-tests.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@quanjielin: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test istio-unit-tests

prow/e2e-simpleTests-minProfile.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-simpleTestsMinProfile

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@quanjielin: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test istio-unit-tests

prow/e2e-simpleTests-minProfile.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-simpleTestsMinProfile

prow/e2e-bookInfoTests-v1alpha3.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-bookInfoTests-envoyv2-v1alpha3

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@quanjielin: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test istio-unit-tests

prow/e2e-simpleTests-minProfile.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-simpleTestsMinProfile

prow/e2e-bookInfoTests-v1alpha3.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-bookInfoTests-envoyv2-v1alpha3

prow/e2e-simpleTests.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-simpleTests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@quanjielin: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test istio-unit-tests

prow/e2e-simpleTests-minProfile.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-simpleTestsMinProfile

prow/e2e-bookInfoTests-v1alpha3.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-bookInfoTests-envoyv2-v1alpha3

prow/e2e-simpleTests.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-simpleTests

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test istio-pilot-e2e-envoyv2-v1alpha3

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@quanjielin: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test istio-unit-tests

prow/e2e-simpleTests-minProfile.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-simpleTestsMinProfile

prow/e2e-bookInfoTests-v1alpha3.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-bookInfoTests-envoyv2-v1alpha3

prow/e2e-simpleTests.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-simpleTests

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test istio-pilot-e2e-envoyv2-v1alpha3

prow/e2e-dashboard.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-dashboard

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@quanjielin: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test istio-unit-tests

prow/e2e-simpleTests-minProfile.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-simpleTestsMinProfile

prow/e2e-bookInfoTests-v1alpha3.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-bookInfoTests-envoyv2-v1alpha3

prow/e2e-simpleTests.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-simpleTests

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test istio-pilot-e2e-envoyv2-v1alpha3

prow/e2e-dashboard.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-dashboard

prow/e2e-mixer-no_auth.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-mixer-no_auth

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@quanjielin: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test istio-unit-tests

prow/e2e-simpleTests-minProfile.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-simpleTestsMinProfile

prow/e2e-bookInfoTests-v1alpha3.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-bookInfoTests-envoyv2-v1alpha3

prow/e2e-simpleTests.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-simpleTests

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test istio-pilot-e2e-envoyv2-v1alpha3

prow/e2e-dashboard.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-dashboard

prow/e2e-mixer-no_auth.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-mixer-no_auth

prow/istio-pilot-multicluster-e2e.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test istio-pilot-multicluster-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@quanjielin: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-simpleTests-minProfile.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-simpleTestsMinProfile

prow/e2e-bookInfoTests-v1alpha3.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-bookInfoTests-envoyv2-v1alpha3

prow/e2e-simpleTests.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-simpleTests

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test istio-pilot-e2e-envoyv2-v1alpha3

prow/e2e-dashboard.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-dashboard

prow/e2e-mixer-no_auth.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-mixer-no_auth

prow/istio-pilot-multicluster-e2e.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test istio-pilot-multicluster-e2e

prow/istio-unit-tests.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@quanjielin: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-simpleTests-minProfile.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-simpleTestsMinProfile

prow/e2e-bookInfoTests-v1alpha3.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-bookInfoTests-envoyv2-v1alpha3

prow/e2e-simpleTests.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-simpleTests

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test istio-pilot-e2e-envoyv2-v1alpha3

prow/e2e-dashboard.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-dashboard

prow/e2e-mixer-no_auth.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test e2e-mixer-no_auth

prow/istio-pilot-multicluster-e2e.sh
318afdefae417a2ceb29a086a1d978349923b754
link
/test istio-pilot-multicluster-e2e

prow/istio-unit-tests.sh
c43d6a6be27bbac2acebc5fb0d285f2d7c1c6ab8
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@quanjielin: PR needs rebase.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: costinm, quanjielin
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

install/OWNERS [costinm]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@quanjielin: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-multicluster-e2e.sh
7673ad60ecdabb4c6b44828adc7f51e5d9a69048
link
/test istio-pilot-multicluster-e2e

prow/istio-unit-tests.sh
a10deec1290c783e331d7d9520c500c2eb3d6fdd
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@quanjielin: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
a10deec1290c783e331d7d9520c500c2eb3d6fdd
link
/test istio-unit-tests

prow/istio-pilot-multicluster-e2e.sh
a10deec1290c783e331d7d9520c500c2eb3d6fdd
link
/test istio-pilot-multicluster-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@quanjielin: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-multicluster-e2e.sh
a10deec1290c783e331d7d9520c500c2eb3d6fdd
link
/test istio-pilot-multicluster-e2e

prow/istio-unit-tests.sh
7f2cb65eb5717ee5e1adcadff693d6a9e2326f4e
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test istio-unit-tests


Cant seem to fix this error 405

Getting this error. Cant seem to fix it, gives requests has failed in chat when trying to imagine.
Ignoring exception in on_connect Traceback (most recent call last):   File "C:\Python310\lib\site-packages\discord\client.py", line 352, in _run_event     await coro(*args, **kwargs)   File "C:\Python310\lib\site-packages\discord\bot.py", line 793, in on_connect     await self.register_commands()   File "C:\Python310\lib\site-packages\discord\bot.py", line 460, in register_commands     await self.http.bulk_upsert_command_permissions(   File "C:\Python310\lib\site-packages\discord\http.py", line 338, in request     raise HTTPException(response, data) discord.errors.HTTPException: 405 Method Not Allowed (error code: 0): 405: Method Not Allowed

Seems like a pycord problem. Did you install pycord version specified in requirements? Are you using a virtual environment?
I found an issue in pycord github page which is exactly yours, take a look on it.
If it still does not work, try changing pycord version to match master branch in their repository. Tell me if the problem is solved.

i originally installed the version from req.txt, uninstalling that and upgrading to the newest from the master branch fixed the 405 error. I'm still getting the "Request has failed; please try later"
I've put everything correctly into Globals as far as I can tell. Should i worry about changing session id in Salai?

Added a print to see what the response is, in discord network its sending the post request with 204 code but in powershell i see it responding with 400. Not sure why, everything seems correct

Okay now the first issue is solved. You have a second issue with the account sending request to MidJourney.
Did you already activated that account for MidJourney, I mean going to write manually /imagine from this account and accepting rules and terms of use. But I'm pretty sure you already did.
For the session id I think it's a random number generated each session, you can use just one without problem I think.
I'm going to try to get what's the origin of the issue.

Yeah i use midjourney already, works fine in their server and in dm's with the bot. Super odd why its giving 400 error, i honestly have no idea why its giving a 400 error

I think it's due to application_id, it's user dependent even though I thought it was related to midjourney bot, I'm going to see if that's true and make a commit fixing this.

My application_id is the same as the one you put in, i checked all those values already to see if theres a mismatch but they are all the same in the post request from the normal midjourney request

No I was wrong sorry application id is midjourney id.

`<Response [400]>
{'authorization': 'my midjourney token'}
{'type': 2, 'application_id': '936929561302675456', 'guild_id': 'my server id', 'channel_id': 'my channel id', 'session_id': 'EDCwWeQaKTt8iHRX8DUIFinQFlgUM2ra', 'data': {'version': '994261739745050686', 'id': '938956540159881230', 'name': 'imagine', 'type': 1, 'options': [{'type': 3, 'name': 'prompt', 'value': 'testing'}], 'application_command': {'id': '938956540159881230', 'application_id': '936929561302675456', 'version': '994261739745050686', 'default_permission': True, 'default_member_permissions': None, 'type': 1, 'name': 'imagine', 'description': 'There are endless possibilities...', 'dm_permission': True, 'options': [{'type': 3, 'name': 'prompt', 'description': 'The prompt to imagine', 'required': True}]}, 'attachments': []}}`
sessionID = "".join(random.choice(string.ascii_letters + string.digits) for _ in range(32))
i have it random generating session ID's too just in case it was the issue. I dont see what i am missing, it sends the post request in the discord traffic but 400's on my end. Right now skipping the discord bot part and just sending the request in cmd.

To simulate your experience. I put the first function in salai.py in a separate file and tried it on two different servers with two different accounts. It worked correctly. So it's sure that the issue is either from your network or account (I don't really know how does networking work precisely here). I remember that during some tests I had problems because of an account which wasn't verified in discord. Is this the case of your account? If this does not solve the problem I don't see why it is working for my accounts but not in your case...

Also double (triple?) check Salai Token

I dont have a number or 2factor enabled on my discord account but its been verified for many years now. Will add those two and see if it fixes anything. I've checked the Salai token so many times expecting to have an error there but its correct.

OKAY so i got it working, its generating the image but it does not embed it into my server chat. I get the "your image is being prepared" never updates past that

Never mind fixed everything. thanks for the help!

How did you fix it?


Reconsider invariant-stype type guard

I hate to pile onto this extremely lengthy discussion, but I feel like I need to.
I realize this is a duplicate of https://github.com/Microsoft/TypeScript/issues/19066 and apropos of https://github.com/microsoft/TypeScript/issues/10421.
For context, I'm working at Salesforce Quip (https://github.com/quip) on what will likely end up being a near year-long effort to transform roughly 500K lines of code of globally namespaced, Google Closure type-annotated JS to TypeScript -- using a custom transformation pipeline.
We've already converted the global namespace to ES6 modules and we've gotten the TSC error rate down below 10k.
The lack of something like flow's invariant or GCC's debug.assert is a problem. We have O(1000s) of calls to debug.assert() and the existing code was written such that GCC uses it as a type-refinement condition.
The thing that something like invariant accomplishes that #10421 would not (if I'm misunderstanding, please tell me) is that invariant allows you to run code.
This is important, because we have a system of diagnostic reporting in which client side errors are captured and submitted to tracking infrastructure on the server. Simply throwing isn't really an option. It's also the case, that in production, we actively do not want to stop execution when the condition fails. In many cases, the failed assertion wouldn't have resulted in user-visible failures.
I could imagine using the never type as workaround here, but it doesn't seem to cause type refinement in the same way that throw Error() does. e.g.
function foo(a: string | number): number {
  if (typeof a === "string") {
    unreached(); // Replace me with "throw new Error();" and this compiles
  }
  return a;
}

function unreached(): never {
  throw new Error();
}

Just write:
throw unreached();

And yes, it's a duplicate of #10421, which you are aware of already.

@MartinJohns, I realize that throw unreached() or return unreached() will cause the type refinement, but it also stops execution along the existing code path and throws, neither of which we want (in particular in production).
That was the new (I think) part of this discussion which I was attempting to note.

I want to concretely convey that this is something we want to have, but have not yet found a palatable solution which delivers the intended effects without having unacceptable performance impact.

I appreciate that, @RyanCavanaugh.
a) Do you have any suggestions for how to transform our existing debug.assert calls which results in type refinement such that we can control whether an exception is thrown at runtime?
b) I had a hard time wading through the lengthy existing discussions of this issue. Can you point me into the any relevant discussion outlining the design constraints that you are grappling with?
I'd be interested to know what you think the "right" solution is, absent performance considerations.

Re (A): Honestly the use case baffles me and I don't have any proposals. If the type guard fails, you're either going to crash shortly, or corrupt data in a very difficult-to-manage way. If you really want to proceed down that road, why not just write this? A type assertion is extremely correct in terms of expressing your intent to do something that is very possibly false.
function foo(a: string | number): number {
  if (typeof a === "string") {
    unreached(); // Replace me with "throw new Error();" and this compiles
  }
  return a as number;
}

Re (B): Probably best to start at #8655
The "right" solution if computers were infinitely fast is obvious - put every function call in the control flow graph and add a type guard return type for "throws if T is (not?) U"

https://github.com/microsoft/TypeScript/issues/31512#issuecomment-494889184

There's probably not much use to debating the legitimacy of the feature. I totally understand your view (and to be honest, it's more akin to my own sensibilities than not). That doesn't change the fact that we have a quite complex codebase and part of what makes a one-shot transform from GCC to TS possible is that the type systems (modulo enums) largely have no impact on runtime semantics.
With regard to feasibility, I'm way out of my depth here, but FWIW, it seems to me that Flow's original and still current (https://github.com/facebook/flow/issues/112) solution is quite a good trade off. I have no idea how it's actually implemented, but my mental model is that it's a very effective hack.
Effectively anywhere
invariant(condition); is encountered, logically re-write the AST to be
if (!condition) { throw Error(); } before you do flow & type analysis.
This would also address the request in #31512, albeit in a pretty low-tech way.

TypeScript is insanely awesome (thus me investing the past year of my work life trying to move the Quip team to it). Thanks for all your hard work.


Please support win32^5.0.0

Because bitsdojo_window >=0.1.5 depends on bitsdojo_window_windows ^0.1.5 which depends on win32 ^3.0.0, bitsdojo_window >=0.1.5 requires win32 ^3.0.0.
So, because creative_production_desktop depends on both bitsdojo_window ^0.1.5 and win32 ^5.0.3, version solving failed.

This is true

Same issue is happening with share_plus version 7.0.1.

You can always fork and make the change yourself while waiting for the update. Then you can install the dependency using git in pubspec.yaml.

This issue blocked me. Because file_picker 5.3.2 depends on win32 ^5.0.2

You can always fork and make the change yourself while waiting for the update. Then you can install the dependency using git in pubspec.yaml.

Can you explain how to do it?

You can always fork and make the change yourself while waiting for the update. Then you can install the dependency using git in pubspec.yaml.

Can you explain how to do it?

Below is the guide from Flutter official site.
https://docs.flutter.dev/packages-and-plugins/using-packages#dependencies-on-unpublished-packages

I will push a new version soon so that this won't be neeeded.
Just need to find some time for it.
Will reply here once I  push the update.
Bit

I will push a new version soon so that this won't be neeeded.
Just need to find some time for it.
Will reply here once I push the update.
Bit

I just glanced at #216 , which looks like it is solving a lot of issues. Just needs a little version bumb from 5.0.0. to 5.0.5

Or using overrides on pubspec.yaml:
dependency_overrides:
  win32: ^5.0.5

I will push a new version soon so that this won't be neeeded.
Just need to find some time for it.
Will reply here once I push the update.
Bit

Much appreciated @bitsdojo

Again the package install "super_drag_and_drop" is forbidden due to lower requirements on win32.
Use BitsDojo in your project become very discouraged due that :(
@bitsdojo all the community needs you !

Thank you for the heads-up!
Just need to finish something on macOS and I will get back with a new version.
Thank you for your patience.

Please try updating to the latest bitsdojo_window version.


allow submitting documents by hash (no file needed)

@maraoz Hi !
This issue is important because sensitive documents should not be indiscriminately uploaded.
Wrote a bash script for users: https://github.com/rsvp/victor/blob/master/bin/proofexist
If you think it belongs in your repo, tell me where, and I would be happy to push.

@rsvp nice avatar :)
Don't worry, documents are not uploaded even if you use the web interface!
Your tool seems useful though, feel free to make a pull request. Thanks!


chore(gulp-paeckchen): releases 0.1.0

feat(gulp-paeckchen): initial version of gulp plugin (#182)

Coverage remained the same at 100.0% when pulling 861b9692a1e71ecf7ae6869ee75fe806f04c2e5d on gulp/release-0.1.0 into 8d7185a33c77feac353b4b71c00c6a03e63906eb on master.


Re-apply .map() on main thread-refactor

Fixed the incompatibility with async for foo.map() (without .aio()) incompatibility of the previous version, which broke integration tests (and would have broken any such user code).
Related synchronicity note:
I think it might be a good idea to always require an explicit .aio in the future when running async iterators (synchronicity-wrapped or not). This would have some not-obvious annoying implications in for types that are iterable themselves though (adding a .aio property, and making it somehow consistent with how .aio() on methods work). Something to think about for synchronicity 2.0...
Changelog

Iterators passed to Function.map() and similar parallel execution primitives are now executed on the main thread, preventing blocking iterators from possibly locking up background Modal API calls, and risking task shutdowns.

@prbot approve


Document how to manually specify dist. col. to shard mapping

How does this work?
Citus has a internal logic to map each value to specific shard. Although we do all this mapping behind the scenes, some power users want to know which value maps to which shard (generally for maintanence purposes) With out new UDF get_shard_id_for_distribution_column we address this request.
Lots of examples which are self-explaining mostly: https://github.com/citusdata/citus/pull/1048/files#diff-5242c7ad7ecd61a82eec5e268a7717d3
Corner cases, gotchas

Hash distributed tables, range distributed tables and reference tables are supported but not append distributed tables.

Are there relevant blog posts or outside documentation about the concept/feature?

https://github.com/citusdata/citus/issues/827
https://github.com/citusdata/citus/issues/879

Link to relevant commits and regression tests if applicable

Overall discussion: https://github.com/citusdata/citus/issues/872

The main PR: https://github.com/citusdata/citus/pull/1048

Came up in customer conversation, so bumping up priority.

@saicitus can you give me more background on why people want to know the exact shard id that distribution column values map to? That will help me put the information in the right place within docs.


Make logging work better with multiprocessing

vdirsyncer currently synchronizes all collections at once, mixing logging messages of all processes together.
In theory this means that two messages could interfere with each other in a way that makes both of them unreadable. While we could simply eliminate the race conditions by locking output for each message, the output would still look ugly, as each message would have to be prefixed with some sort of identifier for each process. There's the option of locking for the duration of one synchronization, but this would cause unresponsiveness of the UI if one process hangs. I'd like to see how other programs have designed their UI, and ideally just use a library.

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/3759487-make-logging-work-better-with-multiprocessing?utm_campaign=plugin&utm_content=tracker%2F574345&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F574345&utm_medium=issues&utm_source=github).

This train of thought isn't going anywhere. Concrete proposals such as #210 help more.


Include series in harvest API (and improve lots of other stuff)

Also see commit messages. Main open questions:

Is the addition to the SeriesSerivce (and related stuff) ok like this? Will this be accepted in the community?
Do I really need to implement that method for the remote impl? Like... can we just say Tobira is only on the admin? Or sth like that? We decided for now that we will just throw an exception and care about this later.
Are you happy with the new code and logic in the Tobira module?

The only things left, as far as I can tell, before calling this initial API finished:

[ ] Adding good REST docs to it
[ ] Adding more fields to the reply. Currently, hardly any useful information is given for event and series. That has to be more. But adding that should be very straight forward.
[x] Renaming and correctly describing the limit parameter to clarify it's just a guideline and the API can return however many.
[ ] DB migrations
[ ] Index for deletion_date?

We discusses that all remaining points can be addressed later. So I will merge as soon as CI is green.


Get full text of initial tweet

Now that we're including the text of the initial tweet in the text output (per #32), we need to make an additional call to twitter to get the full text of that tweet.
The Tweet Data Dictionary includes a truncated boolean. This means we should only have to make the additional API call when we need to.

This issue was handled as part of the shift from flask to django.


Move caching to Contour.Caching

Added extension features needed for moving caching to Contour.Caching:

config sections extensions
decorating outgoing message filters
removing code responsible for caching

@andrey-prokopyev ,
could you please provide description of the intent and changes of this pull request?

@semion-akimtsev, done

Where Contour.Caching and corresponding tests are located?

@semion-akimtsev, configuration types must be public because of their extensibility. Side projects should be able to read ExtensionProperties and ExtensionConfigurations. Other internal config elements became public because of their visibility as types of public properties.

@semion-akimtsev, LambdaDependencyResolver became public beacuse of it's use in Contour.Caching

@semion-akimtsev, System.Xml is used in ExtensibleConfigurationElement

@semion-akimtsev, JsonNetPayloadConverter is used in message hasher of Contour.Caching

@semion-akimtsev , Contour.Caching is located at our internal new.git.dev

@andrey-prokopyev , @mzabolotko ,
I see that we have a couple of changes (types accessibility levels etc.) in Contour which should affect the behavior of some other library which is currently "private". These changes cannot be validated now and we cant justify them because the "other" library is not part of the solution. I suggest that we move Contour.Caching to this repository (not assembly) and make it build-able because despite it should be detached from Contour itself it is still a part of it as a framework. Or rename the library to something_cool_not_referencing_contour.Caching and make it dependent on the branch of Contour project.

@mzabolotko, so Contour.Caching should be separate repository or separate project in Contour repo?


TOTP and HOTP, Base 32 Standard

Google Authenticator Supports both TOTP and HOTP! Why don't you Implement both.
Base32 function should be separated and use this repo https://github.com/ChristianRiesen/base32
(as that is a standard by required RFC)

+1

I guess TOTP is used much more often than HOTP...
A Pull Request with a HOTP implementation would be awesome!
The built-in _base32Decode() function works fine, I'm not sure why to add a dependency to this project, just to get the same result. I don't see an advantage.
Currently you can just copy the file PHPGangsta/GoogleAuthenticator.php and start your work, if you don't like composer for example. With an external dependency it gets more complicated.


Add load and sample methods to trainer class

Slightly modifies trainer to split sampling method from training loop to make it available after training.  Also adds method to load state dict from checkpoint to trainer so training can now be done in multiple stages.
Loading & Sampling looks like this:
from rectified_flow_pytorch import (
    Unet,
    RectifiedFlow,
    ImageDataset,
    Trainer,
)

checkpoint = "checkpoint.45000.pt"

# Initialize Unet & Load State Dict
model = Unet(dim = 64)
rectified_flow = RectifiedFlow(model)

img_dataset = ImageDataset(
    folder = 'oxford_flowers/jpg',
    image_size = 256
)

trainer = Trainer(
    rectified_flow,
    dataset = img_dataset,
    num_train_steps = 70_000,
    checkpoints_folder = "checkpoints",
    results_folder = 'RFM_oxford_flowers'   # samples will be saved periodically to this folder
)

trainer.load(checkpoint)
# Sample from Model & Save Images
filename = "45k_ema"
trainer.sample(fname=str(trainer.results_folder / f'results.{filename}.png'))

@benearnthof looks great! thank you for this PR!


Write the 'Technology Used' for the project in the Readme

Technology Used

Closing this because I have created a separate issue only for README. There seem to be a lot of README issues. So amalgamated all of them into one. You can find the new issue here: https://github.com/rohitgeddam/CSC510_PROJECT1/issues/86


[DC-3116] Bug Fix add_hpo script.

Bug fix updates.

I checked this work and it looks good to me.  @ratuagga, I see you updated unit tests too.  Good catch!