Possibly relevant to the group: Are there any tricks for debugging on mainnet?
Join us today at 7 pm CET (GMT+2) for a new session of the Developer Tooling WG. We have the following items on the agenda:
- @dfx-json will present a new Developer Experience Initiative
- @stopak will give an update on his progress on the light replica project
See you later!
Thank you. Very nice.
Super exciting demo from @stopak
The first version of the npm package should be dropped in about 2 weeks.
Here are the recording and the updated meeting notes.
Hey everybody,
a new session of the Developer Tooling WG is happening later today at 7pm CEST.
- @stopak just finished his grant on lightic and will give an update.
- @dsd from the foundation will give us an intro/update to Pocket IC, a project to create a more powerful emulator of the IC.
- @AdamS will provide a postmortem on why Windows support for DFX through WSL was not possible
Looking forward seeing you!
Here are the recording and updated meeting notes of yesterdayâs session.
Hi everyone.
This is Linwei from SDK team. In the upcoming group session (8/3), Iâd like to discuss about candid generation.
Context
Every canister should have a interface definition in Candid. For how do developers get the Candid, there are two approaches.
- Write the Candid by hand, then implement the canister to confront the interface.
- Implement the canister and let the CDK generate Candid definition automatically.
There are a few projects dealing with similar problem, e.g. Protobuf, Thrift, WIT. All of them provides the support for the first approach. But there is barely no official support for the second approach. Because the build tools of most programming languages are not flexible enough for the task.
Motoko CDK supports the second approach by default.
Rust CDK recently refreshed its support for the second approach. The feature was implemented in a hacky way. It defines an extra WASI entry point function which print out the Candid definition to stdout.
Users execute the WASI binary in wasmtime
to get the Candid.
Problem
Should SDK provides support for both approaches? Or one of them?
My thoughts
I gathered opinions from SDK teammates. We agree that the first approach is more viable for most programming languages. So for community contributed CDKs, the first approach is a must-have support.
Meanwhile, we are aware that supporting candid auto-generation would lower the barrier of onboarding new developers to IC ecosystem since learning a new IDL (Candid) wonât be required before writing canister code.
If itâs possible to support the second approach in some language, itâs great to have it. Thatâs a bonus CDK feature.
dfx
support?
dfx
can support the first approach naturally.
As mentioned before, Rust CDK export_candid
workflow requires wasmtime
. Itâs controversial whether we should bundle a wasmtime
copy with dfx
.
Discuss in group session
We value community opinions. If you want to share your idea, please join the discussion in the upcoming group session (8/3).
Hey everybody, weâll have a Developer Tooling Working Group session today at 10 am PST. We will discuss Candid code generation. @tolga could we possibly get an update on DFX Dashboard? Meeting Link Hope to see you there!
The second approach I believe to be absolutely the best developer experience, and I think we should aim to make that the first-class experience for all CDKs.
The first approach can be used if the developer desires it by providing a path to a Candid file or through some other toggle mechanism.
The Motoko CDK really got this right in my opinion, and thus far the Rust Candid generation itself is very good (with some caveats).
Whatever hacks dfx needs to do to make this work, I would love to see done. Please donât make canister or CDK developers deal with this complexity, it has caused a lot of headaches while developing Azle and Kybra. The fact that the canister must be executed to get the Candid is the most difficult part to deal with.
Hey everybody,
Tomorrow Sept 7th 7pm CEST (5pm UTC), weâll have a new session of the Developer Tooling Working Group with an exciting agenda:
- @benji will present his ETH/OpenZepplin-inspired Rust CDK rustic (Announcement post)
- @fxgst will present canister testing in Python with PocketIC (Announcement post)
Zoom Link
Recording incl. Transcript
Update: Due to low participation, we didnât cover the 2nd point of the agenda.
Looking forward to the presentation and discussions!
Can we add ICRC-26 to the agenda for Oct 5th?
Oh, I missed this message. Would you be still around today?
Couldnât make the meeting due to work
Hey,
Weâll have a Developer Tooling WG session later today at 6 pm UTC.
Let us know if you have any additional topics that youâd like to bring up.
Zoom Link: Launch Meeting - Zoom
P.S. Send me a DM with your email if youâd like to get an invitation for this Working Group directly.
Hi everyone. We have a Developer Tooling Working Group taking place today. See you there! Redirecting
Hi everyone. We have a Developer Tooling Working Group taking place today. See you there! Redirecting
Hi everyone!
Iâd like to work on a feature equivalent to ethereum emit events on ICP.
Iâm building Ping (https://h7jna-pqaaa-aaaak-afgiq-cai.icp0.io/), a notification delivery system for dapps on ICP.
Whatâs the best place for having further discussions about this?
yes, feel free to drop in today and start the discussion.