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 | 스포와이드공지 잘 확인하세요
Community | 토큰뱅크 리워드 시스템 우올~
Community | 스포츠 코인 순 매수왕이 되어 보시렵니까?
와... 이거슨 ..아니지
Community | 레아 프로토콜 이벤트 당첨금이 바뀌었네요 ㅠㅡㅠ
안녕하세요. 토큰뱅크 운영팀입니다. 해당 팀과의 가격 변동에 따라 지급 시점에 맞춘 당첨금액을 지급하는 것으로 변경되어 혼란을 드린 점에 대해 죄송합니다. 기존에 이벤트 공지드렸던 내용에 해당 수량은 해당 팀의 정책으로 인해 시세 변동 및 수량 변동될 수 있다는 점 안내드렸습니다. 현재 레아 프로토콜의 당첨금액 수량인 320 RHEA는 8000원 상당의 시세로 측정되어 산정되었던 수량이며, 해당 수량은 지급 시점에 맞춰 8000원 상당의 RHEA로 지급될 예정입니다. 추후 이와 같은 이벤트 진행 시 변동사항 없이 고객님들에게 충분히 안내된 상태에서 진행할 수 있도록 개선하겠습니다.
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.
닉네임을 설정 후 작성해주세요.