if you are gonna write an "ed" can you make it like the calculator and allow non-interactive use (ie an "ed" thats also a "sed") ? I would highly recommend you keep the current editor, (especially) while "developing" , because of that _HEX_ ability. you could extend it to allow disk sectors (or block) and memory chunks BTW I woke up because you started having problems near the end :)
Sorry to wake you up, I can work on compressor settings or getting a better radio voice ;) Yes, can have it be flexible for input, where no args is interactive input getting keypresses, a string argument starting with a double quote is a "script" passed from command line, and otherwise an argument is assumed to be a file path where the file contains a script to run. And then iterating through the input args would run each script in turn, strings or files. Those hex changes would be good, I'd like to make that more of an interactive 'xxd' type of utility, where it can print memory contents or disk contents and change the values in memory/on disk. Some far off future would be a sort of interactive debugging/hot reloading of running processes should their bytes change.
@@QuesoFuego No your presentation style is good, and your voice is not monotonous - I was listening while I was asleep, and I woke up because some of the things you were saying didn't sound right, and as you eventually found out, it was a relatively simple fix in the key handling routine - problems like that have to be expected when developing a "proper" OS, plus you moved your build context _AND_ move to PIE some some issues were bound to happen.
@@QuesoFuego My comment about your editor impiled that you done have to do things the way they are already done. to add an ED and XXD is not a bad thing (useful even) but that does not mean you need to discard your functioning editor that does have HEX uses (even if somewhat limited ATM), especially while in the middel of a development process (where HEX _and_ ASCII can be usefult to validate values)
That's true, and I do agree with you, can always leave them as is or extend the hex functionality and not remove it, at least in the interim so it's still useful. It's more so that it is easier to start with a clean slate and have a smaller thing that can be functional and scriptable earlier, than trying to update the editor in its current state. Though I might clean it up off-screen to fix lingering page fault bugs and work with the newer abstractions and syscalls that have been made.
keep going❤❤
You are too smart... everyone nowadays calls themselves "programmers"...
Nah, I'm just stubborn and read a lot.
But my job title does have 'programmer' in it, so technically and legally I am one :D
good job
Thanks!
finally, 32 Bit Series!
finally,❤
if you are gonna write an "ed" can you make it like the calculator and allow non-interactive use (ie an "ed" thats also a "sed") ?
I would highly recommend you keep the current editor, (especially) while "developing" , because of that _HEX_ ability. you could extend it to allow disk sectors (or block) and memory chunks
BTW I woke up because you started having problems near the end :)
Sorry to wake you up, I can work on compressor settings or getting a better radio voice ;)
Yes, can have it be flexible for input, where no args is interactive input getting keypresses, a string argument starting with a double quote is a "script" passed from command line, and otherwise an argument is assumed to be a file path where the file contains a script to run. And then iterating through the input args would run each script in turn, strings or files.
Those hex changes would be good, I'd like to make that more of an interactive 'xxd' type of utility, where it can print memory contents or disk contents and change the values in memory/on disk. Some far off future would be a sort of interactive debugging/hot reloading of running processes should their bytes change.
@@QuesoFuego No your presentation style is good, and your voice is not monotonous - I was listening while I was asleep, and I woke up because some of the things you were saying didn't sound right, and as you eventually found out, it was a relatively simple fix in the key handling routine - problems like that have to be expected when developing a "proper" OS, plus you moved your build context _AND_ move to PIE some some issues were bound to happen.
@@QuesoFuego My comment about your editor impiled that you done have to do things the way they are already done. to add an ED and XXD is not a bad thing (useful even) but that does not mean you need to discard your functioning editor that does have HEX uses (even if somewhat limited ATM), especially while in the middel of a development process (where HEX _and_ ASCII can be usefult to validate values)
That's true, and I do agree with you, can always leave them as is or extend the hex functionality and not remove it, at least in the interim so it's still useful.
It's more so that it is easier to start with a clean slate and have a smaller thing that can be functional and scriptable earlier, than trying to update the editor in its current state. Though I might clean it up off-screen to fix lingering page fault bugs and work with the newer abstractions and syscalls that have been made.