sed missing in windows about akso HOT 6 OPEN

@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?

from akso.

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.

from akso.

@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.

from akso.

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.

from akso.

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.

from akso.

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 #3 because there's some demand for it. It's reasonably easy to fix. I can get you pointed in the right direction.

from akso.