Peter - I'm trying to reduce all the warnings I get from the linker on preload. Many I understand, but I'm struggling with a few. One in particular are typescript enums. I've been able to take an enum and freeze it (and will have a CDV update to support this), such as:
enum MyEnum {
someValue = 1
}
(<unknown>MyEnum) = Object.freeze(MyEnum);
This appears to successfully freeze the enum, and the warnings for it go away.
However when I use the enum, such as:
if (myValue == MyEnum.someValue)
...
I get the linker warning:
MyEnum: no const
It's not a big deal from a slot perspective, but I'm getting so many warnings that it's hard to find the important ones.
MyEnum
is not const. It isn't the object that the warning is for, but the variable the object is assigned to. Recall that in compileDataView we allow the original variable the enum is assigned to (which is not const) get garbage collected and export a reference to it, so this C enum:
#pragma language(typescript)
enum Foo {
one = 1,
two = 2
};
outputs this TypeScript:
enum Foo {
one = 1,
two = 2,
}
export { Foo };
That was the second solution, as you didn't like the first one because it confused TypeScript in some way. It used an extra variable to get to const
since there is no way to do that directly in TypeScript:
enum Foo_ {...};
const Foo = Object.freeze(Foo_);
enum
with altered name, and then create a new const
for it), but the new element is a value and not a type, so usage of the enum
fails with TypeScript errors (Foo.one
reports 'Foo' refers to a value, but is being used as a type here. Did you mean 'typeof MessageType'?
).
Good news - I've got preload now working on my unit tests so they now get the majority of their work done during preload! Reduced slots by around 20K bytes for a typical test suite. I separated all members that need to be writable at runtime into a writable
object within each class, and then got the combination of preload array order and preload code execution to work so I then do a recursive scan on the objects (that define all test suites, test cases, etc) and freeze the non-writable objects.
The side effect is I get hundreds of linker warnings, as all writable members warn (per test case) and tests themselves have unfrozen elements. Makes the enum issue seem trivial!
Getting close on preload (wow it's been a ton of work). I've had to eliminate use of Mocking until that proxy WeakMap
bug is resolved, but that's let me get closer to getting things working (even though many tests can't be done). Soon I should be able to see if I'm out of the woods on slots / chunks or not...!
The Modules
module currently does not work with preload. Is it possible (and not difficult) to enable Modules
to work at preload and locate all modules (using host
) and use Modules.importNow
to import them (which would then pull them into preload)? Basically a runtime way to define preload.
The problem I'm trying to solve for isn't so much the runtime control over preload (though I thought that was potentially an elegant solution to multiple problems), but that with preload I've lost the ability to know the name of the module that is being loaded when module-scope code executes (before, I could locate a unit test module using Modules.host
, track it's module name, and importNow
which would cause the Jest module scope code to execute and register tests mapped to the module name). Now, understandably, modules load outside of my runtime control and therefore all module-scope code executes without any ability to track the module that is executing.
Modules
module is one of those.
Modules
module is not an option here. The only native code that runs is XS built-ins, of course, since XS can guarantee that it provides the same functions at build time and execution time. Dynamic import isn't an option because it is asynchronous and modules loaded at preload are synchronous. It might be possible to use importNow
on a Compartment instance to synchronously load a module during preload. I don't have time to try it this morning.
Promise
:Promise.resolve().then(() => {
// this code runs after all preloads complete but before lockdown of the firmware image
});
it was listed as
but should be
still doesn't fix the issue though
section
attributes are necessary on ESP8266 but I think on ESP32 they aren't really necessary (different versions of GCC, different CPU capabilities). The attribute
is still relevant. Maybe you can eliminate the section
attribute for your target (maybe we can do that for ESP32 in general?).
I'm still getting error: conflicting types for 'size_t' typedef __SIZE_TYPE__ size_t;
feeling kind of stuck.
https://github.com/juniper-garden/moddable/tree/testing_tag3
testing_tag3
branch... at line 112 in xs/includes/xs.h change from #if defined(__ets__)
to #if defined(__ets__) && !ESP32
. And in xs/platforms/esp/xsHost.h, change the vPortEnter/ExitCritical
to portENTER_/portEXIT_CRITICAL
to get past the next hurdle.
Hi @mtoko, welcome to our Gitter! Most of the Chapter 3 examples use a two-step process: first you install the host
application and then you use mcrun
to install the example mods. Have you worked through any of the examples that work this way in earlier chapters? If not, it may be worth briefly going back to Chapter 1 to familiarize yourself with the process.
I'm guessing that we're not in the same time zone, so I'll provide some additional instructions here to keep you moving if you return to this while I'm offline. Basically, you want to go to the ch3-network
folder in your terminal and then do something like:
cd host
mcconfig -d -m -p esp
then when the host app has successfully launched, use control-c to break out of the debugger connection, then do:
cd ..
cd http-get
mcrun -d -m -p esp