## Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
##### Activity
Peter Hoddie
@phoddie

I have a style question. For on you implement it this way...

on = (event: string, listener: Function) => this.addListener(event, listener)

...instead of the more common class function form:

on(event: string, listener: Function) {
}

There are some subtle differences between the two forms. What's the reason to use the arrow function for on but not elsewhere?

Daniel Ashcraft
@dashcraft

Good question, in my mind i was thinking about arrow functions auto binding to the function scope. So in this case I didn't want to
run into interesting edge cases around function scope, whereas the arrow function will always bind this from the enclosing scope.

I'm not sure if it's a solution in search of a problem, it's really just habit from dealing with bind in react js and handling higher order function scope issues.

Peter Hoddie
@phoddie

I don't know enough about React to understand its habits. ;) I don't see how on benefits from this approach over any other call, unless it is common to write:

const on = emitter.on;
on("click", () => ...);
on("key", () => ...);
on("sensor", () => ...);

Or, if there's some reason that developers commonly retarget this, as in emitter.on.call(somethingElse, "click", () =>...). But, if they do that, when on calls addListener it will throw on the attempt to read the private field #events.

Otherwise, it is more efficient (memory use and execution speed) to write it as a regular public class function. That avoids creating an arrow function at runtime for each instance of the emitter.

Daniel Ashcraft
@dashcraft
Yeah, i'm sure there are places we could identify, that this would be problematic, I think a class method would be fine here and I'll do that instead of this.
I'm sure as people start to use EventStream either via extension or direct usage, areas will popup that i can address at that time.
Daniel Ashcraft
@dashcraft
Also, thank you @phoddie for the code reviews! Hopefully I can get up to speed on best practices here shortly!
Peter Hoddie
@phoddie
Hey @bterlson, stepping through TypeScript generated code that uses private fields, I noticed that it is not generating code that uses ECMAScript private fields, but uses WeakMap. That works with XS (of course!) but isn't as efficient as our private fields implementation. Now that private fields are Stage 4, is this support in the plans for TypeScript? (I know it isn't your job.... but I thought you might know.)
Peter Hoddie
@phoddie

Since TypeScript generates inefficient code for private fields (for the moment) and since the implementation of EventEmitter doesn't use TypeScript features beyond type checking, you can use JavaScript for the implementation and have a parallel *.d.ts file with the type declarations. That seems to work.

declare module "event-emitter-mod" {
class EventEmitter {
on: (event: string, listener: Function) => Boolean | null | undefined;
emit: (event:string, args?: any) => Error | Boolean;
addListener: (event: string, listener: Function) => Boolean | null | undefined;
removeListener: (event:string, listener: Function) => Boolean | null | undefined;
}

export {EventEmitter as default};
}

And

export default class {
#events = new Map();
#maxListeners;
constructor(options) {
this.#maxListeners = options?.maxListeners ?? 10;
}

on(event, listener) {
}

emit(event, args) {
const listeners = this.#events.get(event);
if (!listeners) return false;
listeners.forEach(triggerCallback(args))
return true
}

const listeners = this.#events.get(event);

if (!listeners) {
this.#events.set(event, [listener]);
} else {
if ((listeners.length >= this.#maxListeners) || listeners.includes(listener))
return false;

listeners.push(listener)
}
return true
}

removeListener(event, listener) {
const listeners = this.#events.get(event);
if (!listeners)
return false;

const index = listeners.indexOf(listener);
if (index < 0)
return false;

listeners.splice(index, 1);
if (!listeners.length)
this.#events.delete(event);

return true
}
}

function triggerCallback(args) {
return cb => {
try {
cb(args)
} catch(err) {
throw new Error(err)
}
}
}
Daniel Ashcraft
@dashcraft
100000%
I need to get back and add file support to the express like package I made. I’d like to get a decently performant web server up here in the next 30 days.
Peter Hoddie
@phoddie
That would be excellent.
Andy Carle
For my fellow Windows users: I'm really happy with the Windows Terminal Preview that is available on the Microsoft Store. It (finally) incorporates tabs for Command Prompt. And it allows you to set up a custom profile for Command Prompt that uses the settings we need for ESP32 builds. It's quite nice.
Daniel Ashcraft
@dashcraft
Oooooh i was just commenting about how the multiple dev environments I have are starting to drive me a tad bonkers!
Andy Carle

The profile settings I'm using (taken from the settings.json file for the Terminal Preview app) are:

            {
"altGrAliasing": true,
"antialiasingMode": "grayscale",
"closeOnExit": "graceful",
"colorScheme": "Campbell",
"commandline": "%comspec% /k \"\"%ProgramFiles(x86)%\\Microsoft Visual Studio\\2019\\Community\\VC\\Auxiliary\\Build\\vcvars32.bat\" && pushd %IDF_PATH% && \"%IDF_TOOLS_PATH%\\idf_cmd_init.bat\" \"%LOCALAPPDATA%\\Programs\\Python\\Python37\\\" \"%ProgramFiles%\\Git\\cmd\\\" && popd\"",
"cursorShape": "bar",
"fontSize": 12,
"hidden": false,
"historySize": 9001,
"icon": "%MODDABLE%\\contributed\\window-display-moddable-one\\assets\\moddable-box.png",
"name": "Moddable Command Prompt",
"snapOnInput": true,
"startingDirectory": "%MODDABLE%",
"useAcrylic": false
}

Paths likely need some per-system tweaking.

Daniel Ashcraft
@dashcraft
I'll see what i can do!
Hopefully with minimal tweaking i can get it setup and try it out
Daniel Ashcraft
@dashcraft
Thanks for the shoutout on twitter!
Peter Hoddie
@phoddie
You're very welcome. Looking forward to having more to tweet about. ;)
Daniel Ashcraft
@dashcraft
you can now send resources using the
sendResource method such as:
let  app = new Express(Server)
app.get('/home', function(req,res) {
res.sendResource(new Resource("index.html"))
})
let port = 80 // 80 is the default port
app.listen(port)
Peter Hoddie
@phoddie
Nice. Resources are very convenient for bundling binary data into a project.
Daniel Ashcraft
@dashcraft
I'll need to clean and write tests for a lot but it works.
Peter Hoddie
@phoddie
The Resource constructor returns a Host Buffer which is very similar to a SharedArrayBuffer. Maybe sendResource should be a more general sendBuffer that could also accept an ArrayBuffer? Alternatively. sendResource could just accept a string ("index.html") and invoke new Resource for the caller to avoid every call to sendResource also including new Resource.
Daniel Ashcraft
@dashcraft
Yeah, i need to write some generalized functions for handling buffer/chunked data. That's one of the primary cleanup items I have,
same with parsers. I need to invest some type generalizing various parsers and investigating the body-parser libraries
that exist for web.
As of now, the server doesn't need to know what "kind" of buffer you're sending, you can dictate the content-type,
this was my attempt to start generalizing that behavior.
Peter Hoddie
@phoddie
Understood. I'm just reacting to your code snippet. I don't have a sense of what is good style for Express.
Daniel Ashcraft
@dashcraft
It's got a few features that are going to give me a headache, mostly around middleware and their router, for
separation of concerns. There are likely some performance shortcuts I'll need to make when it comes time.
It's been interesting learning some of the raw behaviors on top of TCP. I've never been this close to the metal
before on anything, I've been several layers abstracted. This has improved my understanding of the web,
I consider it a huge win. I wish I could motivate others to start getting involved.
Also, as a side note, it's always interesting how your spelling deteriorates when your keyboard starts reaching
it's end of life. I'm having to triple-check my messages until my new kb gets in.
Daniel Ashcraft
@dashcraft
C:\Users\daniel\Projects\moddable\build\tmp\esp32\debug\routing-test\makefile(218) : fatal error U1050: Detected ESP-IDF version v4.2.1. Expected ESP-IDF version v4.2.
Stop.
Tried to pull down for my esp32, and I got this error, I checked that I am currently on the correct esp-idf branch and that it's pointed to the correct location.
Daniel Ashcraft
@dashcraft
had to change esp32 nmake file, per a discussion, that's odd
Peter Hoddie
@phoddie
Yea, Espressif did something weird with the version numbering on the 4.2 branch. @PrototypingAndy_twitter has been doing some work to sort it out.
Andy Carle
@dashcraft That error you've got there sounds like your Moddable SDK is out of date. If you pull top-of-tree from GitHub it should take care of that.
Daniel Ashcraft
@dashcraft
@PrototypingAndy_twitter I’ll pull it down today! Thanks!
Daniel Ashcraft
@dashcraft
ERROR: Command errored out with exit status 1: 'C:\Users\danie\.espressif\python_env\idf4.2_py3.9_env\Scripts\python.exe' -u -c 'import io, os, sys, setuptools, tokenize; sys.argv[0] = '"'"'C:\\Users\\danie\\AppData\\Local\\Temp\\pip-install-u3zwbqf8\\gevent_5e0f45c907174cc48d47c8ff1a486656\\setup.py'"'"'; __file__='"'"'C:\\Users\\danie\\AppData\\Local\\Temp\\pip-install-u3zwbqf8\\gevent_5e0f45c907174cc48d47c8ff1a486656\\setup.py'"'"';f = getattr(tokenize, '"'"'open'"'"', open)(__file__) if os.path.exists(__file__) else io.StringIO('"'"'from setuptools import setup; setup()'"'"');code = f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' install --record 'C:\Users\danie\AppData\Local\Temp\pip-record-2n7b0252\install-record.txt' --single-version-externally-managed --compile --install-headers 'C:\Users\danie\.espressif\python_env\idf4.2_py3.9_env\include\site\python3.9\gevent' Check the logs for full command output.
Welp, I'm stuck, but only for the esp32 workflow
esp8266 still works and runs fine
if it helps, the 4.2 esp-idf installer installs 4.2.2 and latest moddable i pulled requires 4.2.1 so i went the github release route and it's causing this issue
Andy Carle
Interesting. Did you run %IDF_PATH%\install.bat after you pulled? And launch a new ESP-IDF/Moddable command prompt to get export.bat to run again? That looks like a python and ESP-IDF build issue moreso than something on the Moddable SDK side. I've seen similar issues when changing IDF versions and forgetting to re-run the export script.
Daniel Ashcraft
@dashcraft
I don't remember opening an esp-idf command prompt, let me do that and see what I've got.
different error,
esp-windows-curses; sys_platform == 'win32'
To install the missing packages, please run "C:\Users\danie\esp32\esp-idf\install.bat"
Diagnostic information:
IDF_PYTHON_ENV_PATH: C:\Users\danie\AppData\Local\Programs\Python\Python39\
Python interpreter used: C:\Users\danie\AppData\Local\Programs\Python\Python39\python.exe

ESP-IDF v4.2.1-141-g1e3638390-dirty
NMAKE : fatal error U1077: 'python' : return code '0x1'
Stop.
i ran the install.bat file, i'm not sure why it's not finding it
Andy Carle

When you start up the ESP-IDF command prompt, you should get some diagnostic information. Mine looks like this:

Using Python in C:\Users\andyc\AppData\Local\Programs\Python\Python37\
Python 3.7.3
Using Git in C:\Program Files\Git\cmd\
git version 2.24.1.windows.2
Setting IDF_PATH: C:\Users\andyc\esp32\esp-idf

Not using an unsupported version of tool xtensa-esp32-elf found in PATH: 1.22.0-80-g6c4433a5-5.2.0.
Not using an unsupported version of tool esp32ulp-elf found in PATH: 2.28.51.20170517.
Not using an unsupported version of tool cmake found in PATH: 3.17.0.
Not using an unsupported version of tool openocd-esp32 found in PATH: 0.10.0-dev.
Not using an unsupported version of tool ninja found in PATH: 1.8.2.
C:\Users\andyc\.espressif\tools\xtensa-esp32-elf\esp-2020r3-8.4.0\xtensa-esp32-elf\bin
C:\Users\andyc\.espressif\tools\xtensa-esp32s2-elf\esp-2020r3-8.4.0\xtensa-esp32s2-elf\bin
C:\Users\andyc\.espressif\tools\esp32ulp-elf\2.28.51-esp-20191205\esp32ulp-elf-binutils\bin
C:\Users\andyc\.espressif\tools\esp32s2ulp-elf\2.28.51-esp-20191205\esp32s2ulp-elf-binutils\bin
C:\Users\andyc\.espressif\tools\cmake\3.16.4\bin
C:\Users\andyc\.espressif\tools\openocd-esp32\v0.10.0-esp32-20200709\openocd-esp32\bin
C:\Users\andyc\.espressif\tools\ninja\1.10.0\
C:\Users\andyc\.espressif\tools\idf-exe\1.0.1\
C:\Users\andyc\.espressif\tools\ccache\3.7\
C:\Users\andyc\.espressif\tools\dfu-util\0.9\dfu-util-0.9-win64
C:\Users\andyc\.espressif\python_env\idf4.2_py3.7_env\Scripts

Checking if Python packages are up to date...
Python requirements from C:\Users\andyc\esp32\esp-idf\requirements.txt are satisfied.

Done! You can now compile ESP-IDF projects.
Go to the project directory and run:

idf.py build

Similar to what you're seeing?

Daniel Ashcraft
@dashcraft
I’ll print mine in just a few minutes to be sure, but that looks very similar yes
Daniel Ashcraft
@dashcraft
Setting PYTHONNOUSERSITE, was not set
Using Python in C:/Users/danie/.espressif/python_env/idf4.2_py3.8_env/Scripts
Python 3.8.7
Using Git in C:/Users/danie/.espressif/tools/idf-git/2.30.1/cmd
git version 2.30.1.windows.1
Setting IDF_PATH: C:\Users\danie\esp32

C:\Users\danie\.espressif\tools\xtensa-esp32-elf\esp-2020r3-8.4.0\xtensa-esp32-elf\bin
C:\Users\danie\.espressif\tools\xtensa-esp32s2-elf\esp-2020r3-8.4.0\xtensa-esp32s2-elf\bin
C:\Users\danie\.espressif\tools\esp32ulp-elf\2.28.51-esp-20191205\esp32ulp-elf-binutils\bin
C:\Users\danie\.espressif\tools\esp32s2ulp-elf\2.28.51-esp-20191205\esp32s2ulp-elf-binutils\bin
C:\Users\danie\.espressif\tools\cmake\3.16.4\bin
C:\Users\danie\.espressif\tools\openocd-esp32\v0.10.0-esp32-20200709\openocd-esp32\bin
C:\Users\danie\.espressif\tools\ninja\1.10.0\
C:\Users\danie\.espressif\tools\idf-exe\1.0.1\
C:\Users\danie\.espressif\tools\ccache\3.7\
C:\Users\danie\.espressif\tools\dfu-util\0.9\dfu-util-0.9-win64
C:\Users\danie\.espressif\python_env\idf4.2_py3.8_env\Scripts
C:\Users\danie\esp32\tools

Checking if Python packages are up to date...
Python requirements from C:\Users\danie\esp32\requirements.txt are satisfied.

Done! You can now compile ESP-IDF projects.
Go to the project directory and run:

idf.py build

C:\Users\danie\esp32>
Daniel Ashcraft
@dashcraft

Is anyone here using this docker image per chance?
https://hub.docker.com/r/horihiro/moddable-sdk-esp32/tags?page=1&ordering=last_updated

I'm still having issues only with the esp32, i try to avoid docker because it's a resource hog, but this may
create a more stable working environment

Peter Hoddie
@phoddie
I don't know anyone using that image. I recall @mkellner did some exploration with Docker a while back. The Espressif tools are a bit of a pain to set-up and something of a moving target, unfortunately.
Daniel Ashcraft
@dashcraft
Thank you so much for joining @PrototypingAndy_twitter @lprader, I do enjoy moddable sdk and hopefully I can inspire others to use it as well!
Daniel Ashcraft
@dashcraft
Here's the app we're building from the data gathered via these devices, for monitoring.
Andy Carle
@dashcraft Thank you for hosting the meetup! Always a delight to hear people talking about their work on our platform. And it's very cool stuff that you're working on; I really think we're on the leading edge of a new "right to repair" boom in consumer/agricultural/industrial/etc. electronics. I'll look forward to hearing more about your company's work as you grow!
Daniel Ashcraft
@dashcraft

ran into another small issue getting my MacBook working for the 32s so while im traveling I can work on embedded stuff.

A fatal error occurred: Failed to connect to ESP32-S2: Timed out waiting for packet header
CMake Error at run_cmd.cmake:14 (message):
esptool.py failed
Call Stack (most recent call first):
run_esptool.cmake:21 (include)

I am using a USB dongle if that makes a difference, the device port maps correctly and seems to show the correct USB port though.

Executing "ninja flash"...
ninja failed with exit code 1
make: *** [all] Error 2