sed missing in windows

[dbosnyak]

part of the make process uses sed on lines 98/99 of Makefile.patch (and other places) but windows does not have a native sed. So you get this, say by going live with tutorial 1:

Connected to device. Firmware version on attached device: 3.0.1.0, crc=0x9922E990 Loading path: Z:\music_programming\akso-3.0.1\objects Loading path: Z:\music_programming\akso-3.0.1\akso-community\objects Object libraries loaded successfully. Generate code complete Compiling patch. 'sed' is not recognized as an internal or external command, operable program or batch file. process_begin: CreateProcess(NULL, sed -n s/^//$MODULES=(.)/\1/gp ../build/xpatch.cpp, ...) failed. Makefile.patch:98: pipe: No such file or directory process_begin: CreateProcess(NULL, sed -n s/^//$MODULE_DIRS=(.)/\1/gp ../build/xpatch.cpp, ...) failed. Makefile.patch:99: pipe: No such file or directory Memory region Used Size Region Size %age Used SRAM: 5820 B 384 KB 1.48% SRAM2: 0 GB 8 KB 0.00% SRAM3: 1776 B 118 KB 1.47% CCMSRAM: 1452 B 116 KB 1.22% SDRAM: 0 GB 32 MB 0.00% done ../build/xpatch Done compiling patch.

Well this is ok I guess ince the patch loads, I havent figured out why the makefile wants to s(tream)ed(it) the first lines of xpatch.cpp. So I went ahead and added my bin directory from msys64, which DOES have sed to the path so now it can execute those lines, so now you get:

Compiling patch. FIND: Parameter format not correct sed: -e expression #1, char 6: unknown option to s' sed: -e expression #1, char 6: unknown option to s' /usr/bin/sh: line 1: Z:music_programmingakso-3.0.1external/gcc-arm/win/gcc-arm-none-eabi-8-2019-q3-update/bin/arm-none-eabi-g++.exe: No such file or directory make: *** [Makefile.patch:105: ../build/xpatch.o] Error 127 shell task failed, exit value: 1 Compiling patch failed. axoloti.shell.ExecutionFailedException axoloti.shell.ExecutionFailedException at axoloti.shell.ShellTask.run(ShellTask.java:120) at axoloti.shell.ShellTask.lambda$getJob$0(ShellTask.java:37) at axoloti.shell.CompilePatch.lambda$run$0(CompilePatch.java:67) at java.base/java.lang.Thread.run(Thread.java:834)

axoloti.shell.ExecutionFailedException axoloti.shell.ExecutionFailedException at axoloti.shell.CompilePatch.run(CompilePatch.java:75) at axoloti.live.patch.PatchViewLive.lambda$goLive$7(PatchViewLive.java:275) at axoloti.job.JobProcessor.lambda$exec$0(JobProcessor.java:21) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:834)

This is not good because the compile fails completely. I will look into why the sed command is messing up and report back, unless someone tells me that the entire process of doing this thing is unnecessary. I think this error is appearing because now line 77 of Makefile.patch executes with some error and now fails to properly add all the slashes to the path to the arm compiler.

The sed commands inside of the makefile are:

%.o: %.cpp ${MODULE_LIBS} ${BDIR}/xpatch.h.gch $(eval MODULES := $(shell sed -n 's/^//$$MODULES=(.)/\1/gp' $<)) $(eval MODULE_DIRS := $(shell sed -n 's/^//$$MODULE_DIRS=(.)/\1/gp' $<))

Sorry I am not a makefile expert so if anyone can chime in we could probably figure this out easily

[zrnsm]

@dbosnyak This isn't ringing a bell for me at first glance. It's confusing that /usr/bin/sh is showing up in the log at all on a Windows machine. Can you give me more information about your environment?

I agree that we clearly shouldn't be depending on sed in a Windows environment. It almost seems like somehow something is going awry with the OS detection inside of the Java app itself.

Do you use WSL on this machine by chance? Git bash? How are you launching the executable?

[dbosnyak]

In the second error dump it is invoking bash from msys64 which has sed as a part of it - I just did that to see what would be different if I actually had sed installed. The first error dump is what a typical windows install would see, which is that there is no sed. It appears that sed is just invoked to change one line in the xpatch.h file? There must be some way to do it with an environment variable or something instead.

[zrnsm]

@dbosnyak I was misreading this the first time through as being a completely showstopping issue. It sounds like the compilation does indeed succeed despite getting the errors, right? It's not actually load-bearing in general.

I need to refresh my memory on exactly why sed is invoked there. My recollection is that it's specific to the MODULE notion mentioned in the Makefile there which is not fully baked; it's a feature that existed way back when and was partially modified but not completed in work done between Axoloti 1.0.12 and Akso. In other words, it's a wart that needs to be removed.

I really want to find time to get back to active development on Akso, but I've had day job stuff eating up tons of my time. Just getting hardware shipped has been unbelievably taxing having to do everything alone. It's looking like I will soon have a pick and place machine at my disposal though which should free me from some of the manual hardware work.

[dbosnyak]

yes it is a minor issue insofar as it seems to compile without the sed getting invoked; it is possible the issue could be resolved just by removing sed completely. My concern was that when I allowed it to actually execute the sed command then it crashed completely, I think because of some windows confusion with backwards and forwards slashes. If I comment out lines 98,99 of the Makefile.patch two of the errors go away but there is one more reference to sed somewhere that I havent found - there are 38 times in 28 files where sed appears but none of them look like they should be called. Here is the output with 98,99 commented:

Connected to device. Firmware version on attached device: 3.0.1.0, crc=0x9922E990 Generate code complete Compiling patch. 'sed' is not recognized as an internal or external command, operable program or batch file. Memory region Used Size Region Size %age Used SRAM: 5820 B 384 KB 1.48% SRAM2: 0 GB 8 KB 0.00% SRAM3: 1776 B 118 KB 1.47% CCMSRAM: 1452 B 116 KB 1.22% SDRAM: 0 GB 32 MB 0.00% done ../build/xpatch Done compiling patch.

[zrnsm]

Much better. Even depending on make is annoying (especially on Windows), and there's little there that is really helping us much. It's more an historical artifact than a technical necessity. I'll look at pulling patch compilation into the app itself, i.e. we'd directly invoke the compiler without needing make or sed at all.

[zrnsm]

By the way @dbosnyak, I absolutely need development help on this project. I simply cannot do everything by myself; just getting us this far has bordered on being dangerous to my health. If you're feeling adventurous, you should take a look at this issue https://github.com/zrna-research/akso/issues/3 because there's some demand for it. It's reasonably easy to fix. I can get you pointed in the right direction.