Dfx 0.9.3 is promoted

Release notes: Highlights of what’s new in 0.9.3 :: Internet Computer

The main changes were to update these dependencies:

  • Replica to blessed commit d004accc3904e24dddb13a11d93451523e1a8a5f
  • Motoko to 0.6.25
  • icx-proxy, which is now static-linked
6 Likes

Is there a change log for motoko?

1 Like

does this mean I need to change my implementation of my streaming strategy or will it just start streaming chunks again? I am using an implementation similar to this non-fungible-token/http.mo at main · DepartureLabsIC/non-fungible-token · GitHub and are replicas currently running these changes

1 Like

Unfortunately, when I upgrade and run dfx start in 0.9.3, it now no longer respects the networks.local.bind IP address + port combo that I specify in my dfx.json, and instead picks a random port…

In fact, the first line of dfx start is now:

binding to: 192.168.1.67:51869

My dfx.json contains this:

  "dfx": "0.9.3",
  "networks": {
    "local": {
      "bind": "192.168.1.67:8000",
      "type": "ephemeral"
    }
  },

Another issue is when I ctrl+C in a terminal with a running dfx start. It takes more than a minute to stop the replica and return control back to the user. I don’t know why it takes so long…

1 Like

That’s the dfx internal webserver, which is only used to serve candid interfaces.

Later on, you should see something like this, which corresponds to your bind address:

 Mar 24 10:17:01.427 INFO Log Level: INFO
 Mar 24 10:17:01.428 INFO Starting server. Listening on http://127.0.0.1:8000/

I just ran that, and then edited dfx.json to change the port to 8003, after which:

 Mar 24 10:17:25.716 INFO Log Level: INFO
 Mar 24 10:17:25.717 INFO Starting server. Listening on http://127.0.0.1:8003/
1 Like

Ah the issue was that I didn’t run dfx start --clean. Sorry for the trouble.

1 Like