Technical Working Group: Developer Tooling

Possibly relevant to the group: Are there any tricks for debugging on mainnet?

1 Like

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!

3 Likes

Thank you. Very nice.

Super exciting demo from @stopak :rocket:
The first version of the npm package should be dropped in about 2 weeks.

Here are the recording and the updated meeting notes.

4 Likes

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!

3 Likes

Here are the recording and updated meeting notes of yesterday’s session.

1 Like

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.

  1. Write the Candid by hand, then implement the canister to confront the interface.
  2. 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).

4 Likes

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.

3 Likes

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:

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!

3 Likes

Can we add ICRC-26 to the agenda for Oct 5th?

1 Like

Oh, I missed this message. Would you be still around today?

Couldn’t make the meeting due to work :confused:

Hey,

We’ll have a Developer Tooling WG session later today at 6 pm UTC.

  • @Severin will do a demo of PocketIC
  • @kpeacock will demo React Native <> Agent support

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?

1 Like
1 Like

yes, feel free to drop in today and start the discussion.

1 Like