Enhancement: Some control of protection "inheritance"

[kcrossen]

Is your feature request related to a problem? Please describe. "If B is a variable with positive status and assignment of B to A is permitted, execution of the assignment A = B adds to the protections of A all protections of B that A does not already have." (from calc help)

This could be understood as protection "inheritance", a very powerful feature, but not what some users might anticipate. Any assignment of pi or e to a variable "freezes" that variable.

Describe the solution you'd like More intuitive (for my application anyway) would be some default or initializable defense against protection "inheritance", in effect giving some variables the same no-inherited-protection as builtin functions. Like 512: A protections not inherited. In any case,

Describe alternatives you've considered My choices might be: a) forcing the user to understand pi and e as functions, b) remember to "protect(user_variable, 0);" at least after assignment from pi or e, or "define pi() { x = pi; protect(x, 0); return x};" which puts me back to square one.

Additional context /---------------------------------------------------------------------------------------------------------------------/ Add the following line after line 181 in your current value.h:

define V_PROTECTNOINHERIT 512 / protection status 512 /

/---------------------------------------------------------------------------------------------------------------------/ Add the following line after line 876 in your current opcodes.c: if (tmp.v_subtype & V_PROTECTNOINHERIT) var->v_subtype = 0; /---------------------------------------------------------------------------------------------------------------------/ Tested in my application & works well.

[lcn2]

We would like to explore this proposed feature, @kcrossen

Please consider attaching a diff -u patch that shows the changes needed to implement V_PROTECTNOINHERIT.

Please include a change to the appropriate help file that documents this change.

Please also add a proposed regress.cal test that shows this working.

If you need help in doing any of the above, please ask.

[kcrossen]

As you may see from my own github repositories, I use github about the way I used sourceforge. Y'all seem to think I'm operating at something approximating your level of understanding/competence with your tools. Maybe I've been too reticent on the subject, but this is a severe overestimation of my current competence.

Y'all appear to have a developed very sophisticated and efficient dev pipe, which I think quite an achievement in itself. However, I use Qt Creator/etc. which works really well to produce applications for macOS, Windows, Android, etc. while hiding all that command line complexity.

I've tried Android SDK/Java and Kivy/Python, both of which were unreliable. I settled on Qt which has worked reliably for several years. They have treated me well, possibly because I can submit code/pro library bundles that compile on everybody's hardware/OS for easy testing/bug demonstration.

I have implemented my fix in my modified library and the above two code addition lines will work equivalently in your posted latest release version. Here they are again, admittedly not in diff form, but the difference from diff seems essentially "sugar":

/---------------------------------------------------------------------------------------------------------------------/ Add the following line after line 181 in your current value.h:

define V_PROTECTNOINHERIT 512 /* protection status 512 /

/---------------------------------------------------------------------------------------------------------------------/ Add the following line after line 876 in your current opcodes.c: if (tmp.v_subtype & V_PROTECTNOINHERIT) var->v_subtype = 0; /---------------------------------------------------------------------------------------------------------------------/ Add the following line after line 32 in your https://github.com/lcn2/calc/blob/master/help/protect: 512 Protections not inherited. /---------------------------------------------------------------------------------------------------------------------/

Once again, I apologize for my shortcomings.

[kcrossen]

I've been through all of this w/ AWS C++ SDK folks. They cheerfully acknowledged that their SDK didn't compile at all under any circumstance/OS for Android. I produced a working Qt-compatible C++ library that compiled out-of-the-box on any Qt supported OS, cross-compiling apps that worked on Android. They declined to use or post it, even though they distribute their code about like I did on Sourceforge. They don't like Qt apparently.

The essential advantage of Qt is that you don't have to know anything about the underlying Android (or any OS) interface. Qt Creator automatically installs all of the required Android-interfacing components.

[kcrossen]

Not manly enough maybe.

[lcn2]

As you may see from my own github repositories, I use github about the way I used sourceforge. Y'all seem to think I'm operating at something approximating your level of understanding/competence with your tools. Maybe I've been too reticent on the subject, but this is a severe overestimation of my current competence.

Y'all appear to have a developed very sophisticated and efficient dev pipe, which I think quite an achievement in itself. However, I use Qt Creator/etc. which works really well to produce applications for macOS, Windows, Android, etc. while hiding all that command line complexity.

We must disagree with your implications that we are using some sort of "very sophisticated and efficient dev pipe".

The diff command has been around since the 1970's. The patch command since 1984. The git command dates back to about 2005. Neither is "sophisticated" nor esoteric. Using such tools has been common practice for many years.

GitHub has lots of documentation. including Creating a pull request and About pull requests, to just mention a few. You can look over that documentation, ask questions, and attempt to apply yourself.

GitHub is not SourceForge and is probably a mistake to assume that they are equivalent. Better would be to read the decimation and try to become familiar with platform you are using.

Even using Qt, one should seek to provide input to a GitHub repo that is consistent with what that repo does and uses. Calc is not Qt based, so the code base is NOT Qt aware. If you want to request something be considered in the calc code base for all users, you need to consider how it will impact the calc community. This means:

• creating a diff -u patch that reflect the minimal change you are requesting that all calc users might consider
• add code to regress.cal to test the new feature
• add or modify help file(s) to explain to others the new feature

Once again, I apologize for my shortcomings.

Apologizing does not help you overcome what you might call "shortcomings". Better would be to study, learn and try.

[lcn2]

As you may see from my own github repositories, I use github about the way I used sourceforge. Y'all seem to think I'm operating at something approximating your level of understanding/competence with your tools. Maybe I've been too reticent on the subject, but this is a severe overestimation of my current competence.

Y'all appear to have a developed very sophisticated and efficient dev pipe, which I think quite an achievement in itself. However, I use Qt Creator/etc. which works really well to produce applications for macOS, Windows, Android, etc. while hiding all that command line complexity.

I've tried Android SDK/Java and Kivy/Python, both of which were unreliable. I settled on Qt which has worked reliably for several years. They have treated me well, possibly because I can submit code/pro library bundles that compile on everybody's hardware/OS for easy testing/bug demonstration.

I have implemented my fix in my modified library and the above two code addition lines will work equivalently in your posted latest release version. Here they are again, admittedly not in diff form, but the difference from diff seems essentially "sugar":

/---------------------------------------------------------------------------------------------------------------------/ Add the following line after line 181 in your current value.h: #define V_PROTECTNOINHERIT 512 /* protection status 512 / /---------------------------------------------------------------------------------------------------------------------/ Add the following line after line 876 in your current opcodes.c: if (tmp.v_subtype & V_PROTECTNOINHERIT) var->vsubtype = 0; /---------------------------------------------------------------------------------------------------------------------/ Add the following line after line 32 in your https://github.com/lcn2/calc/blob/master/help/protect: 512 Protections not inherited. /---------------------------------------------------------------------------------------------------------------------_/

Once again, I apologize for my shortcomings.

See the above comment. Try looking a diff -u to build a patch file and the GitHub documentation to build a Pull Request.

There is no regress.cal test to show if this new feature is working. Saying "Tested in my application & works well" is not good enough. You need to show this via some regress.cal test line(s).

The MAXPROTECT value in value.h does not allow your V_PROTECTNOINHERIT value.

etc.

[lcn2]

You, @kcrossen wrote:

... Which I don't know how to use. My professional career started before punch cards (patch boards) and I'm afraid I haven't really kept up.

I am afraid I am going to have to call you on this for several reasons:

you wrote: "professional career started before punch cards":

Punch cards were patented in 1889 by Hollerith for the 1890 US Census. I doubt your career started before 1889.

The IBM punch cards were introduced in 1928. While it is possible your career dates back to the 1920's, the start date of your career is largely irrelevant to the fact that one needs to make an effort to learn a few things from time to time.

you wrote: "I'm afraid I haven't really kept up."

The base diff/patch technology you need to deal with dates back to the mid-1970's: nearly a half century ago. I put in the effort in the 1970's to learn that, and you can too.

The git tools have been around for 17+ years. I put in the effort in the mid 2000's to learn that, and you can too.

GitHub has lots of documentation such as Creating a pull request and About pull requests that you can read. Even more so, there are people you can ask who can answer questions about that documentation. I put the effort to learn that a few years ago, and you can too.

FYI: My career started in 1963, nearly 6 decades ago on plug board and punch card systems. However I don't care if my career started before or after your career. Career start dates are irrelevant in my opinion to the need to apply yourself, to learn a few simple things, and to ask for help in understanding from others when needed. I.e., you are not going to get any sympathy from me playing the "my career started too long ago" card.

With a mild bit of effort, I learned things over the years. I believe you can still learn things, if you want to.

If you do not know something, then take the opportunity to learn it!

If you cannot understand something, then take the opportunity to read about it and, if needed consider asking others questions to try and help you understand.

you wrote: "Once again, I apologize for my shortcomings."

You can clearly use Qt. You can modify calc code for Qt and compile it. You can use a computer to read and write text. Building a Pull Request is less complex than all that.

You can put the effort into learning a few things, if you want to.

[kcrossen]

Big ask.

Github, as you say may be easy to learn, but it's just the tip of a massive iceberg. To contribute usefully to calc in the desired manner, I'd have to understand quite a lot about your strategies and coding conventions.

Take "protection inheritance" as an example. After some hours of inspection, I resorted to tracing into opcodes.c o_assign function where I learned that subtype represents protection, at least in that function. Is this a general solution, useful to anyone other than myself?

Integrating hex float literals is an even stronger example. After a day of examining calc's parse/tokenize code, and realizing that tracing would be much harder in that code, I gave up. Perhaps I'm just not smart enough.

While calc's external documentation is fairly good, internally it's not comparable to the Qt code I'm used to reading. Drop in anywhere, scroll up to the function, start with the meta-comments, continue w/ the variable names and code comments, and I usually understand within minutes.

My schedule goes: day job, developing "missing" components for Qt/Android (e.g. file explorer, floating keyboard, etc.), somewhere down there, trying to package calc as a Qt class to extend its usefulness into cross-compiled GUI apps, APKs, etc. Not much time left for calc internals.

I had hoped to avoid hard feelings with my hex float example (my coding style) plus the follow-on comments and I'm saddened that you impugned my motives in your email. I've benefitted enormously from your talents and generousity.

Ken

On Thu, Mar 24, 2022, 3:25 AM Landon Curt Noll @.***> wrote:

You, @kcrossen https://github.com/kcrossen wrote:

... Which I don't know how to use. My professional career started before punch cards (patch boards) and I'm afraid I haven't really kept up.

I am afraid I am going to have to call you on this for several reasons: you wrote: "professional career started before punch cards":

Punch cards were patented in 1889 by Hollerith https://en.wikipedia.org/wiki/Herman_Hollerith for the 1890 US Census. I doubt your career started before 1889.

The IBM punch cards were introduced in 1928. While it is possible your career dates back to the 1920's, the start date of your career is largely irrelevant to the fact that one needs to make an effort to learn a few things from time to time. you wrote: "I'm afraid I haven't really kept up."

The base diff/patch technology you need to deal with dates back to the mid-1970's: nearly a half century ago. I put in the effort in the 1970's to learn that, you can too.

The git tools have been around for 17+ years. I put in the effort in the mid 2000's to learn that, you can too.

GitHub has lots of documentation such as Creating a pull request https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request and About pull requests https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request that you can read. Even more so, there are people you can ask who can answer questions about that documentation. I put the effort to learn that, you can too.

FYI: My career started in 1963, nearly 6 decades ago on plug board and punch card systems. However I don't care if my career started before or after your career. Career start dates are irrelevant in my opinion to the need to apply yourself, to learn a few simple things, and to ask for help in understanding from others when needed. I.e., you are not going to get any sympathy from me playing the "my career started too long ago" card.

With a mild bit of effort, I learned things over the years. I believe you can still learn things, if you want to.

If you do not know something, then take the opportunity to learn it!

If you cannot understand something, then take the opportunity to read about it and, if needed consider asking others questions to try and help you understand. you wrote: "Once again, I apologize for my shortcomings."

You can clearly use Qt. You can modify calc code for Qt and compile it. You can use a computer to read and write text. Building a Pull Request is less complex than all that.

Such apologies have the appearance of being passive-aggressive, in my opinion, and are not productive.

You can put the effort into learning a few things, if you want to. But to dump stuff on other people and then apologize about shortcomings you seem unwilling to address or even ask questions about isn't going to help you or anyone else.

— Reply to this email directly, view it on GitHub https://github.com/lcn2/calc/issues/52#issuecomment-1077316057, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAO4OEBT7XPYP5MHLIAL4VLVBQKG5ANCNFSM5PRIRIWA . You are receiving this because you were mentioned.Message ID: @.***>

[lcn2]

Take "protection inheritance" as an example. After some hours of inspection, I resorted to tracing into opcodes.c o_assign function where I learned that subtype represents protection, at least in that function. Is this a general solution, useful to anyone other than myself?

We can look at the "protection inheritance" problem. You can help us help you help others by creating a calc script that shows protection is working.

I.e., come up with a foo.cal example that shows the protection code is working. Show some simple calc script operation that would fail on calc that does not have "protection inheritance" and will work on calc does provide "protection inheritance".

This will be needed in order to us to create a regress.cal test line that "proves" "protection inheritance" is working. We do this just in case some future calc modification breaks it, we can prevent that modification from going into production and breaking your code.

So .. write us a foo.cal file that sets "protection inheritance" and then performs an operation / test that shows it is working. If needs to be something that when you do in calc:

read foo.cal

It performs a test and, perhaps prints "It works!" if calc has "protection inheritance", otherwise it prints "It fails!" if it does not.

We will convert it into a regress.cal line and add in the lines you suggested from your comment above, PLUS fix the issue of MAXPROTECT.

How about that?

[lcn2]

My schedule goes: day job, developing "missing" components for Qt/Android (e.g. file explorer, floating keyboard, etc.), somewhere down there, trying to package calc as a Qt class to extend its usefulness into cross-compiled GUI apps, APKs, etc. Not much time left for calc internals.

Our schedule is likewise impacted by other code, plus an issue of helping someone impacted by war escape their situation. So don't be alarmed if it takes us some time to get around to our suggestion above.

[lcn2]

I had hoped to avoid hard feelings with my hex float example (my coding style) plus the follow-on comments and I'm saddened that you impugned my motives in your email. I've benefitted enormously from your talents and generousity.

It was not the intent to hurt feelings with our comment above. That we hurt your feelings is something we regret and so, please consider accepting our apology.

We sometimes get the other end of the "haven't really kept up" line: people assuming that because my career started with punch cards and plug boards, we must not know anything current. We have to prove ourselves to some people because they assume we cannot keep up or won't have kept current. So when it appeared you were doing what we are sometimes accused of, it rubbed us the wrong way.

We did try to take some time to write our comment above in the hopes that it would inspire you to try. Obviously that didn't work and so we apologize.

So lets try our comment above and maybe that will work. If that goes well, then we can look at your hex float code.

[kcrossen]

One regrettable aspect is that my comment about punch cards/patch boards was meant as a figure of speech. My wife occasionally cautions me about my sense of humor.

We would appear to be roughly contemporary so I get the same "deprecation" at work (online education software). In fact, I don't keep up. Being skeptical about my intellect has kept me relevant.

I've never used cal files and must compile the original code, which I last did several years ago.

My question would be: is there any other code path via which a variable could "inherit protections"? This is where I'm in well over my head.

Ken

On Sat, Mar 26, 2022, 9:44 PM Landon Curt Noll @.***> wrote:

I had hoped to avoid hard feelings with my hex float example (my coding style) plus the follow-on comments and I'm saddened that you impugned my motives in your email. I've benefitted enormously from your talents and generousity.

It was not the intent to hurt feelings with our comment above https://github.com/lcn2/calc/issues/52#issuecomment-1077316057. That we hurt your feelings is something we regret and so, please consider accepting our apology.

We sometimes get the other end of the "haven't really kept up" line: people assuming that because my career started with punch cards and plug boards, we must not know anything current. We have to prove ourselves to some people because they assume we cannot keep up or won't have kept current. So when it appeared you were doing what we are sometimes accused of, it rubbed us the wrong way.

We did try to take some time to write our comment above https://github.com/lcn2/calc/issues/52#issuecomment-1077316057 in the hopes that it would inspire you to try. Obviously that didn't work and so we apologize.

So lets try our comment above https://github.com/lcn2/calc/issues/52#issuecomment-1077316057 and maybe that will work. If that goes well, then we can look at your hex float code https://github.com/lcn2/calc/issues/14#issuecomment-1055744857.

— Reply to this email directly, view it on GitHub https://github.com/lcn2/calc/issues/52#issuecomment-1079812383, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAO4OEH5GNR2EPBR5U2N5VTVB64RRANCNFSM5PRIRIWA . You are receiving this because you were mentioned.Message ID: @.***>

[kcrossen]

Q&D in Qt: ` QString test_protect_inheritance = "";

test_protect_inheritance += "/* At least two possible failure modes:\n";
test_protect_inheritance += " * 1) Defeats original functionality\n";
test_protect_inheritance += " * 2) Doesn't defeat 'inheritance' */\n";

test_protect_inheritance += "fail_mode_1_result=\"original functionality success\";\n";
test_protect_inheritance += "fail_mode_2_result=\"disinheritance functionality success\";\n";
test_protect_inheritance += "test_pi=pi();protect(test_pi, (512 + 7));\n";
test_protect_inheritance += "test_pi=123;if (test_pi==123) fail_mode_1_result=\"original functionality failed\";\n";
test_protect_inheritance += "tmp=test_pi;tmp=123;if (tmp==test_pi) fail_mode_2_result=\"disinheritance functionality failed\";\n";
RPN_Commands_Execute(test_protect_inheritance);

qDebug() << "/*--------------------*/";
qDebug() << Trim_Calc_Result(Calc_Evaluate("estr(fail_mode_1_result);"));
qDebug() << Trim_Calc_Result(Calc_Evaluate("estr(fail_mode_2_result);"));
qDebug() << "/*--------------------*/";

Yields: /--------------------/ "\"original functionality success\"" "\"disinheritance functionality success\"" /--------------------/ ` Equivalent (I hope) in your universe attached test_calc_disinheritance.cal.zip

[lcn2]

Q&D in Qt:

`

QString test_protect_inheritance = "";

test_protect_inheritance += "/* At least two possible failure modes:\n";

test_protect_inheritance += " * 1) Defeats original functionality\n";

test_protect_inheritance += " * 2) Doesn't defeat 'inheritance' */\n";

test_protect_inheritance += "fail_mode_1_result=\"original functionality success\";\n";

test_protect_inheritance += "fail_mode_2_result=\"disinheritance functionality success\";\n";

test_protect_inheritance += "test_pi=pi();protect(test_pi, (512 + 7));\n";

test_protect_inheritance += "test_pi=123;if (test_pi==123) fail_mode_1_result=\"original functionality failed\";\n";

test_protect_inheritance += "tmp=test_pi;tmp=123;if (tmp==test_pi) fail_mode_2_result=\"disinheritance functionality failed\";\n";

RPN_Commands_Execute(test_protect_inheritance);

qDebug() << "/*--------------------*/";

qDebug() << Trim_Calc_Result(Calc_Evaluate("estr(fail_mode_1_result);"));

qDebug() << Trim_Calc_Result(Calc_Evaluate("estr(fail_mode_2_result);"));

qDebug() << "/*--------------------*/";

`

Yields:

`

/--------------------/

"\"original functionality success\""

"\"disinheritance functionality success\""

/--------------------/

`

Equivalent (I hope) in your universe attached

test_calc_disinheritance.cal.zip

It may be a while before we get to this post, FYI.

[lcn2]

We hope to address this, perhaps sometime this month, in a 2.14.1.1 non-production release.

[lcn2]

This issue is now part of issue #103. We are closing this issue so that any further discussion can appear under issue #103 .