rippled VS orchest

The bug occurred when a multi-path payment interacted with an AMM synthetic offer, and the synthetic offer required to fulfill the payment exceeded the AMM pool size. In this case, the payment engine attempted to use the single-path strategy to back-out the maximum liquidity available to swap against the pool. Although this condition was properly detected, there was an error on how the payment engine resized the synthetic offer to consume liquidity only up to the AMM size. Instead of using the actual swap rate, which represents the cost of fully swapping one side of an AMM pool, the new synthetic offer’s exchange rate was incorrectly set to the spot exchange rate of the AMM (that is, the rate it takes to execute an infinitesimally sized order). Consequently, an AMM operation that should have been expensive became relatively cheap, effectively violating the constant-product invariant of the pool. In this state, another user could deposit funds into the drained side of the pool, generating a large number of LP tokens and taking ownership of the pool. Now that the fix amendment is active, the team has opened a PR with a unit test demonstrating this behavior.

Explore the XRPL Developers Discord, the XRP Ledger Learning Portal, and the extensive documentation available on XRPL.org. You can also participate in XRPL Community Events and Hackathons to engage with like-minded individuals and stay abreast of the latest developments in the XRPL ecosystem.

fixDisallowIncomingV1: Fixes an issue that occurs with authorized trustlines and the “lsfDisallowIncomingTrustline” flag.

It’s good news for the builders who have been working round the clock. Tools such as AI chatbots will enable developers to quickly receive answers to their queries, speeding up the process from concept to application. AI Chatbots have already become a part of RippleX’s commitment to making blockchain development on the XRP Ledger more accessible and less time-consuming, especially for those new to the field. This approach will not only foster increased innovation on blockchains but could also enhance financial inclusion, making tools more accessible globally.

Currently Rippled 2.0.0 is scheduled to release December 18th, 2023: https://github.com/XRPLF/rippled/milestone/8

The XRPL Accelerator, a program dedicated to nurturing innovation and development on the XRP Ledger, is back with its second cohort of groundbreaking projects. After the success of the inaugural cohort, the Accelerator continues to support entrepreneurs and builders looking to scale their projects on the XRP Ledger.

The third annual Apex Developer Summit was the biggest yet. Held in collaboration with the XRP Ledger Foundation, this event brought together an impressive gathering of over 400 blockchain developers, validators, and XRPL community members in the heart of Amsterdam at the Leonardo Royal Hotel.

Explore the XRPL Developers Discord, the XRP Ledger Learning Portal, and the extensive documentation available on xrpl.org. You can also participate in XRPL Community Events and Hackathons to engage with like-minded individuals and stay abreast of the latest developments in the XRPL ecosystem.

As developers and contributors to the decentralized, open-source XRP Ledger (XRPL), the RippleX engineering team is excited to announce a major breakthrough in the XRPL ecosystem that will revolutionize the way developers build decentralized applications (dApps).

You can check out our OSS https://github.com/orchest/orchest

The code example is part of our ELT/data pipeline tool called Orchest: https://github.com/orchest/orchest/

First want to say congrats to the Patterns team for creating a gorgeous looking tool. Very minimal and approachable. Massive kudos!

Disclaimer: we're building something very similar and I'm curious about a couple of things.

One of the questions our users have asked us often is how to minimize the dependence on "product specific" components/nodes/steps. For example, if you write CI for GitHub Actions you may use a bunch of GitHub Action references.

Looking at the `graph.yml` in some of the examples you shared you use a similar approach (e.g. patterns/openai-completion@v4). That means that whenever you depend on such components your automation/data pipeline becomes more tied to the specific tool (GitHub Actions/Patterns), effectively locking in users.

How are you helping users feel comfortable with that problem (I don't want to invest in something that's not portable)? It's something we've struggled with ourselves as we're expanding the "out of the box" capabilities you get.

Furthermore, would have loved to see this as an open source project. But I guess the second best thing to open source is some open source contributions and `dcp` and `common-model` look quite interesting!

For those who are curious, I'm one of the authors of https://github.com/orchest/orchest

Haven't tried it. In its favor, Argo is vendor neutral and is really easy to set up in a local k8s environment like docker for desktop or minikube. If you already use k8s for configuration, service discovery, secret management, etc, it's dead simple to set up and use (avoiding configuration having to learn a whole new workflow configuration language in addition to k8s). The big downside is that it doesn't have a visual DAG editor (although that might be a positive for engineers having to fix workflows written by non-programmers), but the relatively bare-metal nature of Argo means that it's fairly easy to use it as an underlying engine for a more opinionated or lower-code framework (orchest is a notable one out now).

If you’d like to try something for you data workflows that’s vendor agnostic (k8s based) and open source you can check out our project: https://github.com/orchest/orchest

You can find it here: https://github.com/orchest/orchest Convenience install script: https://github.com/orchest/orchest#installation

We automatically provide container level parallelism in Orchest: https://github.com/orchest/orchest

For people in this thread interested in what this tool is an alternative to: Airflow, Luigi, Kubeflow, Kedro, Flyte, Metaflow, Sagemaker Pipelines, GCP Vertex Workbench, Azure Data Factory, Azure ML, Dagster, DVC, ClearML, Prefect, Pachyderm, and Orchest.

Disclaimer: author of Orchest https://github.com/orchest/orchest