Make eosc easier to use #203
Comments
Add CLI11 library and begin porting commands from the old mechanism to the new one.
|
Since I had a hand in both of those conditions, please let me know if there is anything I can do to help out. Or maybe just to explain why something was done the way it was. |
|
Thanks, Phil! Mostly I want to make sure I don't leave behind any use cases it currently supports. I think that probably means the batch processing mode, which I don't fully understand the purpose or effect of. What is that feature for, and why do we need it? |
|
As I was starting to make some scripted tests that would exercise the p2p network code, I found myself wanting to feed commands to it via more traditional unix streaming services, with the command line arguments being reserved for traditional command line options. Just like you are not fond of virtual inheritance, I'm not fond of unnecessarily starting serial copies of a program. In fact, batch mode isn't operational. I couldn't come up with a use case, so I stopped short of having to test and document it. The streaming feature is line-oriented, although multi-line commands are supported though the use of quoted strings. I also preserved the original behavior as well. The major refactoring I did was to move the command processing out of main to make it easier to deal with alternate input sources. Given your concern about usability I think it would be reasonable to take what I did and make a differently named program. maybe eosst? |
|
FYI: I will be doing a pull request soon with changes to the "transactions" command in eosc. |
Add CLI11 library and begin porting commands from the old mechanism to the new one.
Update `eosc push-trx` to `eosc push transaction`
Add Contract command to replace old setcode Rename Exec command to Push Fix some API naming compatibility with current eosd
Remove all the cruft and old code TODO: Fix massive use-after-free bugs in stack-allocated CLI parameter storage
|
OK, this should be pretty much complete at this point, thought there may be other docs to update that I don't know about. |
|
Preq #221 |
Add CLI11 library and begin porting commands from the old mechanism to the new one.
Update `eosc push-trx` to `eosc push transaction`
Add Contract command to replace old setcode Rename Exec command to Push Fix some API naming compatibility with current eosd
Remove all the cruft and old code TODO: Fix massive use-after-free bugs in stack-allocated CLI parameter storage
- Put all CLI variables in full scope of main() so they live long enough to get used - Update CLI11.hpp to fix a bug that was affecting us: https:// github.com/CLIUtils/CLI11/issues/23
Fix a slippery little bug in the new eosc, which was causing messages' data payloads to be a serialized Bytes object rather than merely the bytes contained by the object. The difference was just one length byte at the beginning of the message data payload, but of course that was enough to break parsing.
Add CLI11 library and begin porting commands from the old mechanism to the new one.
Update `eosc push-trx` to `eosc push transaction`
Add Contract command to replace old setcode Rename Exec command to Push Fix some API naming compatibility with current eosd
Remove all the cruft and old code TODO: Fix massive use-after-free bugs in stack-allocated CLI parameter storage
- Put all CLI variables in full scope of main() so they live long enough to get used - Update CLI11.hpp to fix a bug that was affecting us: https:// github.com/CLIUtils/CLI11/issues/23
Fix a slippery little bug in the new eosc, which was causing messages' data payloads to be a serialized Bytes object rather than merely the bytes contained by the object. The difference was just one length byte at the beginning of the message data payload, but of course that was enough to break parsing.
|
I'm looking for the most appropriate way to override the default host/port to which eosc sends the messages. I've thought of: in each case, an omitted host or port value is defaulted. In the case of streaming mode, I'd like this value to be changeable @nathanhourt are you still actively refactoring eosc? |
programs/eosc/main.cpp was invasively merged ref #203
|
cleaning up old assignments |
|
This was merged, closing. |
OK, so eosc is really rough right now, both from an architecture perspective, and from a usability perspective. The former isn't super critical, but it's still nice to improve; however, the latter is a showstopper.
Improve eosc usability by making clear and complete help information available.
The text was updated successfully, but these errors were encountered: