mDNS is working with Bonjour

Ok, if you ask your self where those pinMode() calls are coming from, than check this code section

https://github.com/espruino/Espruino/blo­b/62e0ec9e0e85b0373bcc5ffcc48bdd99cabea7­cc/targets/esp32/jshardware.c#L131-L142

So dump() displays the code injected by jshPinDefaultPullup() plus your code.

Thanks for clarifying that 🙂. Still, do you know whats going on with the code being there twice? I just can't get my head around why the interpreter would hold the original code plus a copy (dump() docs states that the output is the "current state of" the interpreter) 🤔..

Its like "slightly modified code" + jshPinDefaultPullup() + "original code".

do you know whats going on with the code being there twice?

Espruino keeps its current state in RAM (even if the function code is stored in Flash). When you type dump() it dumps the current state of code in RAM (plus the hardware state), then if there's code saved in flash it writes // Code saved with E.setBootCode and dumps that.

Imagine what happens if you upload function f() { print("bar"); } setInterval(f,1000) to flash and then when its running you type function f() { print("foo"); } in the REPL.

It looks more complicated on ESP32 than it should because there hasn't been any work put in to exclude any pins that are in their normal bootup state - hence the pullup lines. On official boards dump() only writes pin states if the pins have actually had their states changed from the default

When you type dump() it dumps the current state of code in RAM (plus the hardware state), then if there's code saved in flash it writes // Code saved with E.setBootCode and dumps that.

That explains it completely, thanks 👌!

I think what confused me was the two statements in the docs

1. "Output current interpreter state in a text form" -- made me think "why would the interpreter keep the same code twice" and made me question what the interpreter even was then.
   
2. "such that it can be copied to a new device" -- made me think "why would one paste a bunch of code with repeated code blocks into a new device"
   
   

Nevertheless; case closed, thanks for your help and patience 🙂.

edit: BTW, may I suggest adding the quoted text to the docs (or is it something anyone can do via a PR on github?) 🙂? It's a very clear explanation IMO.

It'd be great if you could do a PR.

Best thing to do is go to the reference at http://www.espruino.com/Reference#l__glo­bal_dump, then click the ⇒ next to the title of the function (you may need to scroll down a bit to be able to click it).

That'll bring you to the exact place where the function and its docs are defined. All you need to do is edit the comment in the file at that point and send a PR for it and the docs will be updated on the next release :)

It looks more complicated on ESP32 than it should because there hasn't been any work put in to exclude any pins that are in their normal bootup state - hence the pullup lines. On official boards dump() only writes pin states if the pins have actually had their states changed from the default

I like to go for a pr for ESP32 and ESP8266. Where to start to improve this?

Done 👌.

There was a small difference between the docs and the git-repo. The line
"Note: This is not available in devices with low ... " was missing from git. But I think you'de need to be more experienced with git and how the docs are synchronized with it to understand why, I didn't add the missing line 🙂.

Thanks! The extra line is added automatically based on what's in the if part of the JSON above that description :)

Where to start to improve this?

It's jsiDumpHardwareInitialisation that creates the JS from pin state.

On all other boards the default pin state is JSHPINSTATE_GPIO_IN unless they're used for something else.

So:

• build_platform_config should set up IS_PIN_USED_INTERNALLY so that it returns true for any pins that are actually used for internal stuff (flash/xtal/etc)
  
• Ideally the default pin state should just be 'input' in order to match all the other Espruino devices. If that's not possible then adding a specific ESPxx hack to the end of jsiDumpHardwareInitialisation to check against JSHPINSTATE_GPIO_IN_PULLUP instead might do it
  

Just added issue https://github.com/espruino/Espruino/iss­ues/1930 to clarify if I got you properly with this.