Be a crypto hero in the market by logging in
Don't you have an account? Sign in
Market trends report
We have a few development updates this week; our new logging tool will greatly improve debugging, and we’re getting some crates ready for the move from Rust nightly builds to Rust beta. We also have important information for DNA developers who have had some version conflicts and want to learn how to make all their development components work in harmony. There’s also a new feature to our Dev Pulse, the Summary by Dev Team shows what our teams are working toward in the current development cycle.
1.How to Handle and Prevent Holochain Version Conflicts when Developing a DNA
2. New, Faster Logger with Filtering Capability for Core and lib3h
3. Bump Dependent Crate Versions in Preparation for Shift to Rust 1.38.0 Beta
4. Dev Team Progress Update
We’ve gotten reports from several DNA developers who have experienced failing builds when updating to new Holochain versions. This is typically due to mismatches in the versions of the different components used in building DNAs — the Rust compiler for DNA development, the Rust compiler for the Conductor, the HDK, hc binaries, and Conductor. In this Dev Pulse, we’ll provide you some more context as to what these pieces do, how they work together, how to figure out when something’s wrong, and what you can do to fix it.
It may seem daunting to remember all these potential version conflicts, but remember that they only arise if you are directly downloading the binaries from the Holochain-Rust repository.
If you use Holonix, which we recommend, you’ll already have compiled binaries of all these components in the latest versions. Then, the only thing you would need to do is ensure that you update the target HDK version updated to the same version as the binaries in your existing Holonix environment.
You can find this in your zomes’ Cargo.toml files. If a new version of the HDK introduces any breaking changes, you’ll also need to update your source code.
Of course, Holonix itself isn’t free of version conflicts. We had an issue with the 0.0.23-alpha1 release; Holonix and its endpoint (https://holochain.love) progressed to a new Rust nightly version, but 0.0.23-alpha1 was still using the old version. As we mention below, we are working toward moving from nightly builds of Rust to Rust beta, which will eliminate these concerns. In the meantime, you can make sure that you are using the right version of Holonix by using the command hc — version to check the release tag of Holochain-Rust and the exact same nix-shell that we use for development.
https://holochain.love is great for hacking and messing around on the “latest” version, but for serious versioning, a project should always implement a default.nix file that can pin Holonix under the hood — just as the Holochain-Rust repository does.
The first two pieces you’ll need to keep in sync are:
Each instance needs to be the same (or at least compatible) because we are using Rust nightly due to needed features that haven’t yet landed in Rust beta. Generally speaking, no two different Rust nightly versions are compatible. When the nightly builds for Rust are distributed, the Conductor and the HDK are updated, and both the DNA compiler and the Conductor compiler rely on the HDK. Therefore, every part needs to be aligned in order for them to work correctly.
Note: We are planning to switch from the nightly Rust builds to Rust beta for the next beta release (at least for the HDK), which should make things much easier.
The HDK that you reference as a dependency in your DNA’s Cargo.toml file needs to match the Conductor that runs your DNA after compiling. This makes sense, since the HDK acts as a Rust-based wrapper around a bunch of low-level functions that implement the API, connecting the Conductor to the DNA. If the HDK and the Conductor don’t match — for example, by updating the HDK to the newest version, but your Conductor is running the old version — you’re likely to get an error message.
Similarly, if you run an old DNA build in the new conductor, it won’t work anymore; you’ll need to update the HDK version in the Cargo.toml file and rebuild your DNA.
Here’s an example of the error you would see:
thread ‘main’ panicked at ‘Failed to instantiate module: Function(“host module doesn\’t export function with name hc_sign”)’, src/libcore/result.rs:997:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
It means that your DNA was compiled against an HDK version that assumed an API function (here hc_sign) to be there in the conductor run-time, but it’s not. This could be because we added it in a newer version, and though you’ve updated the HDK to that new version; you’re still trying to run it in an old conductor. Alternatively, it could mean that we removed or renamed the function, such that it is not there anymore, as in this case.
It’s important to remember that the hc command-line tools run some of your DNA’s code after compiling it. Our define_zome! macro in the HDK, or the procedural macros in the new proc-macro HDK, build meta-information from your declarations into a function that generates JSON to be included in the DNA. hc retrieves this information by instantiating the WASM module, loading your DNA, and calling that function. This saves you from having to hand write all the JSON that defines public functions, validators, and entry types. You do have to make sure that hc is the same version as the HDK; otherwise, you may get the same error messages you receive when you try to run a DNA with a mismatched Conductor.
Whether you’re a developer for Core, lib3h, or an app, you’ve likely had difficulty debugging due to not knowing what is happening “under the hood.” We initially came up with a logging solution in Core, but it didn’t cross crate boundaries, which limited how much you could actually see your code in operation. We’ve now revamped our logger to use idiomatic Rust conventions and allow for attaching logging to any context we choose — this means we’re able to bring in logging from lib3h, or any other crate, in which we’re interested.
We can also turn logging on or off as needed. Even better, the logger has configurable tagging and colors that let you filter information easily.
Aside from the obvious benefits to Core and lib3h developers, app developers will now better understand what’s going on within Holochain Core and see where networking signals are coming from and where they’re going.
The other big benefit to this change is that it standardizes how we are doing things across different crate developers.
Because the features on which we rely are not yet available in the beta version, we’ve been using the nightly builds of Rust in core development. However, the next beta release of Rust (1.38.0) is coming soon and we will soon be moving over to beta. A more stable version means that we won’t need to race to update Rust every night to make sure all of our components are compatible with one another. We’ll also be less likely to deal with code breaking, due to changes upstream. We may even be able to get rid of some of unneeded dependencies, which will make for a smoother experience for developers starting out on Holochain.
In preparation for the switch to Rust beta, we’ve changed the versions in the holochain_persistence (0.0.7), holochain_serialization (0.0.7) and lib3h (0.0.10) crates so that, when the switch comes, we’ll be ready.
In our recent post on moving toward a Closed Alpha Testnet for Holo, we discussed how we intend to release in a series of waves, allowing us to gradually add new functionality while widening our testing community.
We are introducing a new feature in our Dev Pulse, shown below, which describes what each of our dev teams is working on at a high level, and how their work is progressing in relation to established milestones. In the future, it will align with our development sprint cycle.
Summary by Dev Team
For all changes related to this release, please see the changelog.
Handling and Preventing Version Conflicts in DNA Development, New Logger, and Prep for Rust Beta was originally published in Holochain on Medium, where people are continuing the conversation by highlighting and responding to this story.
안녕하세요. 고객님 입금하시려는 토큰이 토큰뱅크에서 아직 입금을 지원하지 않는 토큰일 경우에는 입금이 어렵습니다. 어떤 토큰 입금하시려고 하신건가요?
Community | 입금은 어떻게 하나요?
고객님 케이스타라이브는 거래소로 바로 입금하시면 안되시고 루니버스 메인넷 기반으로 스왑하신 후 이동하셔야 합니다. 해당 문의는 케이스타라이브 담당자에게 문의 부탁드립니다. https://open.kakao.com/o/sepSJr4
Community | 케이스타라이브
고객님 현재 델리오는 토큰 관련하여 확인할 사항이 있어 출금이 중단된 상태입니다. 추후 출금에 대해 재지원할 예정입니다. 재지원시까지 기다려주시면 감사하겠습니다.
Community | 델리오 아이닥스에 상장된 코인
안녕하세요. 토큰뱅크에서 지원하지 않는 토큰을 입금하신 경우, 1-2달 정도 처리기간이 소요됩니다. 또한 처리를 위한 수수료가 발생되는 점 양해 부탁드립니다. 오입금 토큰 입금 처리를 위해서 email@example.com로 오입금된 토큰명과 TxID, 고객님의 토큰뱅크 ID를 적어 보내주시기 바랍니다.
Community | 오입금된 코인 어떻게 처리해야하나요?
안녕하세요. 토큰뱅크입니다. 고객님 락업이 설정된 토큰은 락업 해제 시점에 출금 지원될 에정입니다. 케이스타라이브 지갑으로 출금 후 스왑 지원받으시면 됩니다. 감사합니다.
Community | 케이스타라이브 락업수량 출금신청방법
fastest rising posts
Write a post
Are you sure you want to delete this post?
Are you sure you want to delete this comment?
Purchase has been completed.
닉네임을 설정 후 작성해주세요.