as I see

cmd := sdk.EspTool(ctx, "--port", port, "chip-id")

is what is being run, which I think results in the command above?

so adding a

println(err.Error())

is what we need to add to figure out why it's not working.

The

cmd :=

is already after.

In the meantime you can work around it by using

--chip=esp32c6

(or whatever your chip is). Then it skips the probing.

Fix is out for review. https://github.com/toitlang/jaguar/pull/649

message has been deleted

I'm pretty confident this release finally fixes the probing issue.

Forgive me if this is very elementary but I'm missing it: is there a mechanism for copying objects? Like make one instance of a class and then make a copy that is a new instance?

No. That doesn't exist. Some classes provide their own copy methods. For containers it's typically called

copy

and for other objects it's often

with

(and then optional parameters to modify some properties)

https://libs.toit.io/core/collections/class-Set#copy(0%2C0%2C0%2C)

https://libs.toit.io/core/time/class-TimeInfo#with(8%2C0%2C0%2Cday%2Cdst%2Ch%2Cm%2Cmonth%2Cns%2Cs%2Cyear)

As examples

Weekly update: - fixed Jaguar (see new release above). - continued the new UART driver. We are seeing bytes, but needs more testing.

Hi, I would like to know if there is an easy method to communicate with ESPHome. I am currently using MQTT but would like to remove the need for a Broker/Server ..Thanks

message has been deleted

I don't think anyone has done it yet, but ESPHome has a "Native API": https://esphome.io/components/api/ That uses protobuf. I don't think anyone has used it yet, but it's supposed to be a simple protocol, so maybe it's not too hard.

set(LINARO_URL "https://releases.linaro.org/components/toolchain/binaries/4.9-2017.01/arm-linux-gnueabi/gcc-linaro-4.9.4-2017.01-x86_64_arm-linux-gnueabi.tar.xz")
set(LINARO_TARBALL "${CMAKE_BINARY_DIR}/gcc-linaro-4.9.4-2017.01-x86_64_arm-linux-gnueabi.tar.xz")
set(LINARO_DIR "${CMAKE_BINARY_DIR}/linaro/src/linaro_toolchain")
set(LINARO_BIN "${LINARO_DIR}/bin")

# =====================================================
# 2. Download & extract the toolchain using ExternalProject
# =====================================================
ExternalProject_Add(
    linaro_toolchain
    PREFIX ${CMAKE_BINARY_DIR}/linaro
    URL ${LINARO_URL}
    DOWNLOAD_DIR ${CMAKE_BINARY_DIR}
    CONFIGURE_COMMAND ""   # no configure step
    BUILD_COMMAND ""       # no build step
    INSTALL_COMMAND ""     # no install step
    UPDATE_DISCONNECTED 1
)


set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(CMAKE_C_COMPILER ${LINARO_BIN}/arm-linux-gnueabi-gcc)
set(CMAKE_FIND_ROOT_PATH ${LINARO_DIR}/arm-linux-gnueabi/libc)
set(CMAKE_SYSROOT ${CMAKE_FIND_ROOT_PATH})

# Optional: Add flags, sysroot, etc.
set(COMMON_COMPILE_FLAGS
    --sysroot=${CMAKE_SYSROOT}
    -march=armv7-a
    -std=c99
)

^^I want to try to cross-compile Toit for arm7, running a very old Linux kernel, arm-linux-gnueabi-gcc, with linaro. what do you think the chances of this working are? then, I could run toit programs with -d host on this older linux system

There is already a Toit version for that (on the release page)

It might need a relatively recent glibc, though.

If you want to compile from scratch, I think linaro would work too.

this one? https://github.com/toitlang/toit/releases/download/v2.0.0-alpha.189/toit-linux-armv7.tar.gz?

Yes

is the bin/toit executable enough on its own? this is an embedded device which has only 20MB of storage free on its flash

or are the libraries also necessary

root@02AA01AC171401XF# ./toit
FATAL: kernel too old

alas, might need to come back to this

There are different use cases. If you want to be able to run

.toit

programs on the device, you would need the libraries as well. Otherwise you could compile the

.toit

to an executable and just run that. Basically

toit compile -o  ...

. That would also work for cross-compilation, as long as you have the vessel built (which is an automatic step of building for a platform).

in "toit-conventions.md" you nominate `- Use

SNAKE_CASE

for constants.` whereas in https://docs.toit.io/language/style/#classes you nominate

Constants are written in all-caps with dashes:

.... the latter is correct ?

Yes. Kebab case is correct now. I will update the conventions document.

Fixed.

Weekly status update: - some minor cleanups. Specifically, the AI instructions at https://github.com/toitlang/ai-instructions were updated to state that constants should use

KEBAB-CASE

. Thanks to @addshore for pointing that out. I also found another places in our docs.toit.io pages. - updated all our CIs to use the new checkout action. Not sexy, but given the number of repositories we have, that took some time. - some reviews of PRs. Thanks to @exklibur and @milkmansson for subjecting themselves to that procedure. - made some good progress on the UART driver. I think it passes all existing tests now. I intend to write a few additional tests (especially latency and on other platforms than just ESP32), but there isn't much left.