Release before start of semester.

[Matthew-McRaven]

Since we've made several changes to the Pep/9 system, do we want to do another full release before the semester starts?

[StanWarford]

Yes, now is a good time at the start of a new semester.

[Matthew-McRaven]

Pending your review of the pull request regarding Pep9Term improvements, I will prepare a full release on Windows/Linux/Mac on Monday.

Tentatively, I want to version it 9.3.0 since there are new features.

I want the “.0” because we might discover bugs this semester. I don’t want to be forced to bump version numbers to 9.4 if all we have is bug fixes.

On Fri, Jan 3, 2020 at 17:49 Stan Warford notifications@github.com wrote:

Yes, now is a good time at the start of a new semester.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/StanWarford/pep9suite/issues/88?email_source=notifications&email_token=AIPV3AMFFQQ3UTJ5N5PMAM3Q37FIPA5CNFSM4KCSMKU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEICK6MQ#issuecomment-570732338, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIPV3ANMNDAHUZMC6K5RMA3Q37FIPANCNFSM4KCSMKUQ .

[StanWarford]

OK. I am trying to build origin/new-tui, but get:

Project ERROR: Could not resolve SDK SDKVersion for 'macosx10.14' using --show-sdk-version make: *** [sub-pep9asm-qmake_all] Error 3 15:59:57: The process "/usr/bin/make" exited with code 2. Error while building/deploying project BUILD-ALL (kit: Desktop Qt 5.13.2 clang 64bit) When executing step "qmake"

[Matthew-McRaven]

Hello, check new-tui again, I removed the spurious version check in the QMake files.

On Fri, Jan 3, 2020 at 18:07 Stan Warford notifications@github.com wrote:

OK. I am trying to build origin/new-tui, but get:

Project ERROR: Could not resolve SDK SDKVersion for 'macosx10.14' using --show-sdk-version make: *** [sub-pep9asm-qmake_all] Error 3 15:59:57: The process "/usr/bin/make" exited with code 2. Error while building/deploying project BUILD-ALL (kit: Desktop Qt 5.13.2 clang 64bit) When executing step "qmake"

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/StanWarford/pep9suite/issues/88?email_source=notifications&email_token=AIPV3ANNW3O2HRCSZY4QI3LQ37HMZA5CNFSM4KCSMKU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEICLWPY#issuecomment-570735423, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIPV3AI5JIZVATBX2ATU7KDQ37HMZANCNFSM4KCSMKUQ .

[StanWarford]

Built. Will test term.

[Matthew-McRaven]

Your scripts should work identically before the patch as after, otherwise log a defect!

On Fri, Jan 3, 2020 at 18:19 Stan Warford notifications@github.com wrote:

Built. Will test term.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/StanWarford/pep9suite/issues/88?email_source=notifications&email_token=AIPV3AOUKLFUYZFMCXPPYLTQ37IZ5A5CNFSM4KCSMKU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEICMDNI#issuecomment-570737077, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIPV3AORFAZRXLRVBSSDYSLQ37IZ5ANCNFSM4KCSMKUQ .

[Matthew-McRaven]

Other than the two defects you’ve reported, how do you like the new terminal help?

On Fri, Jan 3, 2020 at 18:35 Matthew McRaven mkm302@georgetown.edu wrote:

Your scripts should work identically before the patch as after, otherwise log a defect!

On Fri, Jan 3, 2020 at 18:19 Stan Warford notifications@github.com wrote:

Built. Will test term.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/StanWarford/pep9suite/issues/88?email_source=notifications&email_token=AIPV3AOUKLFUYZFMCXPPYLTQ37IZ5A5CNFSM4KCSMKU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEICMDNI#issuecomment-570737077, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIPV3AORFAZRXLRVBSSDYSLQ37IZ5ANCNFSM4KCSMKUQ .

[StanWarford]

I just did a big revision. I did "man cp" and modeled the help text after the Unix style for that command. After using pep9term for a while, I decided the help options were too complicated. I think there should be only one help option for the whole thing. See attached. This is also going to change some flags. I think -s should be the same flag for all source files. Also, --d2 should be -d2 for consistency. The Unix style is to have the options before the files, as in cp. Not sure if pep9term allows this order. If not, it should. The help text needed to specify the name of the default error log file. For simplicity, I also eliminated some unnecessary default flags. Let me know what you think. pep9term-help.txt

[Matthew-McRaven]

In terms of argument ordering, any order is possible. We use optional arguments rather than positional ones, and optional arguments are order-insensitive.

I modeled the help flags after programs like tar, which use double dashes to indicate that a flag is multiple characters long. The GNU Assembler and GCC both use the scheme you describe, and as such are a better model for our program that tar. It will be easy to change from two dashes to one.

We can remove the unused/default command-line flags, and I can incorporate the new descriptions. I think changing --mc to -s is a good idea in terms of consistency.

I initially chose a two-tiered help system to avoid overloading the user with details. I think the current system lets let's you break down learning how to use Pep9Term into two steps. Initially, the application tells you what it can do (asm, run, etc) by providing a brief description of each mode. Upon choosing a mode, you can invoke -help again, and be provided with all relevant flags for that particular mode

What are your thoughts?

[StanWarford]

I still think that the benefit a two-tiered help system is not worth the cost of the complexity. Most users access the --help text few times if any. I can post the text of a single --help on the book's site as a single document. It would take more effort explaining how to use a two-tiered system and then display them in separate documents. Another benefit of a single --help output is the exposure it gives of the cpuasm and cpurun modes to users of the asm and run modes. There are far more users of Pep/9 than Pep/9 CPU. Having the documentation of the cpuasm and cpurun modes in the same --help text might nudge some users to consider adopting Pep/9 CPU.

This actually brings up another whole consideration of splitting pep9term into two apps -- pep9term with asm and run modes, and pep9CPUterm with asm and run modes. What do you think about that? Either way is fine with me.

Or, how about three apps -- pep9term, pep9CPUterm, pep9microterm -- each with asm and run modes. That way we have one term app for each GUI app. Conceptually clean, I think. But at the expense of releasing 3 x 2 x 3 = 18 apps across the three platforms. Your automated build system would really pay off for that!

Now that I think about it, if we keep a single pep9term app there should be six modes instead of four -- asm, run, cpuasm, cpurun, microasm, microrun. Current setup is to have the micro mode be an option of the cpu modes, which is confusing. With this setup, each pair of modes corresponds to a GUI app. Also, I was wondering does the microrun mode need -i and -o options? Also, is the source file for microrun a .pepo file produced by asm mode, and a micro source file produced by microasm? This all needs to be specified in --help.

[Matthew-McRaven]

Are you available to skype at all today? I'm in the process of implementing the help system, and it feels very lengthy for command-line documentation.

I don't think the cost of deploying three terminal applications is worthwhile. We would have triple the number of command-line applications to maintain, script against, and install. It's already difficult keeping Pep9Term and Pep10Term in synch and adding new applications into the mix would only make the matter worse.

Here is the output of the help documentation, it is still a work in progress. log.pdf

[StanWarford]

Yes, I can Skype today any time.

[Matthew-McRaven]

Better late than never I guess. Now 9.3 is out, I think we can close this issue.