Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.advocacy > #456403 > unrolled thread

linking sc to libgmp

Back to article view | Back to comp.os.linux.advocacy

Contents

  linking sc to libgmp owl <owl@rooftop.invalid> - 2018-06-25 14:55 +0000
    Re: linking sc to libgmp Steve Carroll <fretwizzer@gmail.com> - 2018-06-25 13:10 -0700
      Re: linking sc to libgmp owl <owl@rooftop.invalid> - 2018-06-25 21:20 +0000
        Re: linking sc to libgmp Steve Carroll <fretwizzer@gmail.com> - 2018-06-25 14:33 -0700
          Re: linking sc to libgmp owl <owl@rooftop.invalid> - 2018-06-25 21:48 +0000
            Re: linking sc to libgmp Steve Carroll <fretwizzer@gmail.com> - 2018-06-25 14:56 -0700
              Re: linking sc to libgmp owl <owl@rooftop.invalid> - 2018-06-25 22:17 +0000
                Re: linking sc to libgmp Steve Carroll <fretwizzer@gmail.com> - 2018-06-25 15:23 -0700
                  Re: linking sc to libgmp owl <owl@rooftop.invalid> - 2018-06-25 22:48 +0000
                    Re: linking sc to libgmp Steve Carroll <fretwizzer@gmail.com> - 2018-06-26 08:11 -0700

#456403 — linking sc to libgmp

Finally figured out how to create a built-in arbitrary precision
addition function for sc.  This first attempt simply adds two cells.

https://pewtube.com/user/owl/pdscsXX?autoplay=off

Because sc's internal floating-point representation is a double, and
therefore limited to that precision, the numbers for arbitrary precision
math must entered as strings, with the function returning a string.

The function itself was easy enough, but figuring out how to get
sc to save it took a lot of digging through the code.  Damn.

I still need to get it working for a range.  At some point, I may
switch from libgmp to libmpfr, since that has "correct rounding"
and will hopefully eliminate the need to specify the number of zeros 
in the output.

https://gmplib.org/
https://www.mpfr.org/

[toc] | [next] | [standalone]

#456416

On Monday, June 25, 2018 at 8:55:24 AM UTC-6, owl wrote:
> Finally figured out how to create a built-in arbitrary precision
> addition function for sc.  This first attempt simply adds two cells.
> 
> https://pewtube.com/user/owl/pdscsXX?autoplay=off
> 
> Because sc's internal floating-point representation is a double, and
> therefore limited to that precision, the numbers for arbitrary precision
> math must entered as strings, with the function returning a string.
> 
> The function itself was easy enough, but figuring out how to get
> sc to save it took a lot of digging through the code. 

Why?

> Damn.
> 
> I still need to get it working for a range.  At some point, I may
> switch from libgmp to libmpfr, since that has "correct rounding"
> and will hopefully eliminate the need to specify the number of zeros 
> in the output.
> 
> https://gmplib.org/
> https://www.mpfr.org/

[toc] | [prev] | [next] | [standalone]

#456421

Steve Carroll <fretwizzer@gmail.com> wrote:
> On Monday, June 25, 2018 at 8:55:24 AM UTC-6, owl wrote:
>> Finally figured out how to create a built-in arbitrary precision
>> addition function for sc.  This first attempt simply adds two cells.
>> 
>> https://pewtube.com/user/owl/pdscsXX?autoplay=off
>> 
>> Because sc's internal floating-point representation is a double, and
>> therefore limited to that precision, the numbers for arbitrary precision
>> math must entered as strings, with the function returning a string.
>> 
>> The function itself was easy enough, but figuring out how to get
>> sc to save it took a lot of digging through the code. 
> 
> Why?
> 

Because it was buried in a non-obvious (to me) place.  The code that
causes the function to appear in the info line at the top when the
cursor is over a cell containing a function, as in the image below where
it shows:

A2 (78 2 0) <{@sadd(A0,A1)}

https://imgur.com/a/Z9f2Fsz

is also responsible for having the function written to a saved file.
This is the code (in interp.c):

void
decompile(register struct enode *e, int priority)
{
    register char *s;
    if (e) {
        int mypriority;
        switch (e->op) {
...
         case SADD:      two_arg("@sadd(", e); break;
...
}

Without that case statement, the function, even though working correctly,
displays as:

A2 (78 2 0) <{A0M(A1)}

and is written to a saved file as:

leftstring A2 = AOM(A1) 

When written that way, the function of course does not work when the file
is reloaded.  After adding that case statement, the function gets properly 
displayed as

A2 (78 2 0) <{@sadd(A0,A1)}

and written to the file as:

leftstring A2 = @sadd(A0,A1)

And now it works.  :)

[toc] | [prev] | [next] | [standalone]

#456423

On Monday, June 25, 2018 at 3:20:02 PM UTC-6, owl wrote:
> Steve Carroll <fretwizzer@gmail.com> wrote:
> > On Monday, June 25, 2018 at 8:55:24 AM UTC-6, owl wrote:
> >> Finally figured out how to create a built-in arbitrary precision
> >> addition function for sc.  This first attempt simply adds two cells.
> >> 
> >> https://pewtube.com/user/owl/pdscsXX?autoplay=off
> >> 
> >> Because sc's internal floating-point representation is a double, and
> >> therefore limited to that precision, the numbers for arbitrary precision
> >> math must entered as strings, with the function returning a string.
> >> 
> >> The function itself was easy enough, but figuring out how to get
> >> sc to save it took a lot of digging through the code. 
> > 
> > Why?
> > 
> 
> Because it was buried in a non-obvious (to me) place.  The code that
> causes the function to appear in the info line at the top when the
> cursor is over a cell containing a function, as in the image below where
> it shows:
> 
> A2 (78 2 0) <{@sadd(A0,A1)}
> 
> https://imgur.com/a/Z9f2Fsz
> 
> is also responsible for having the function written to a saved file.
> This is the code (in interp.c):
> 
> void
> decompile(register struct enode *e, int priority)
> {
>     register char *s;
>     if (e) {
>         int mypriority;
>         switch (e->op) {
> ...
>          case SADD:      two_arg("@sadd(", e); break;
> ...
> }
> 
> Without that case statement, the function, even though working correctly,
> displays as:
> 
> A2 (78 2 0) <{A0M(A1)}
> 
> and is written to a saved file as:
> 
> leftstring A2 = AOM(A1) 
> 
> When written that way, the function of course does not work when the file
> is reloaded.  After adding that case statement, the function gets properly 
> displayed as
> 
> A2 (78 2 0) <{@sadd(A0,A1)}
> 
> and written to the file as:
> 
> leftstring A2 = @sadd(A0,A1)
> 
> And now it works.  :)

This doesn't strictly apply here but it's always fun with no errors thrown 
where you wish they would be if that thing is going to end up being the 
eventual culprit. Yours is a bizarre situation but it's one of those little
'learning experiences' you treasure... until you forget it next time.

[toc] | [prev] | [next] | [standalone]

#456424

Steve Carroll <fretwizzer@gmail.com> wrote:
> On Monday, June 25, 2018 at 3:20:02 PM UTC-6, owl wrote:
>> Steve Carroll <fretwizzer@gmail.com> wrote:
>> > On Monday, June 25, 2018 at 8:55:24 AM UTC-6, owl wrote:
>> >> Finally figured out how to create a built-in arbitrary precision
>> >> addition function for sc.  This first attempt simply adds two cells.
>> >> 
>> >> https://pewtube.com/user/owl/pdscsXX?autoplay=off
>> >> 
>> >> Because sc's internal floating-point representation is a double, and
>> >> therefore limited to that precision, the numbers for arbitrary precision
>> >> math must entered as strings, with the function returning a string.
>> >> 
>> >> The function itself was easy enough, but figuring out how to get
>> >> sc to save it took a lot of digging through the code. 
>> > 
>> > Why?
>> > 
>> 
>> Because it was buried in a non-obvious (to me) place.  The code that
>> causes the function to appear in the info line at the top when the
>> cursor is over a cell containing a function, as in the image below where
>> it shows:
>> 
>> A2 (78 2 0) <{@sadd(A0,A1)}
>> 
>> https://imgur.com/a/Z9f2Fsz
>> 
>> is also responsible for having the function written to a saved file.
>> This is the code (in interp.c):
>> 
>> void
>> decompile(register struct enode *e, int priority)
>> {
>>     register char *s;
>>     if (e) {
>>         int mypriority;
>>         switch (e->op) {
>> ...
>>          case SADD:      two_arg("@sadd(", e); break;
>> ...
>> }
>> 
>> Without that case statement, the function, even though working correctly,
>> displays as:
>> 
>> A2 (78 2 0) <{A0M(A1)}
>> 
>> and is written to a saved file as:
>> 
>> leftstring A2 = AOM(A1) 
>> 
>> When written that way, the function of course does not work when the file
>> is reloaded.  After adding that case statement, the function gets properly 
>> displayed as
>> 
>> A2 (78 2 0) <{@sadd(A0,A1)}
>> 
>> and written to the file as:
>> 
>> leftstring A2 = @sadd(A0,A1)
>> 
>> And now it works.  :)
> 
> This doesn't strictly apply here but it's always fun with no errors thrown 
> where you wish they would be if that thing is going to end up being the 
> eventual culprit. Yours is a bizarre situation but it's one of those little
> 'learning experiences' you treasure... until you forget it next time.

The main difficulty here was that the text is in a variable called "line"
(:O) that is printed by an ncurses function addstr() that is called by the
update() function in screen.c, and I could not for the life of me find
where it was supposed to be getting the correct string.  I ran tests
an was able append to it manually, but that was it.  Basically, it's
just a pain in the ass trying to navigate somebody else's complex code.

[toc] | [prev] | [next] | [standalone]

#456425

On Monday, June 25, 2018 at 3:48:35 PM UTC-6, owl wrote:
> Steve Carroll <fretwizzer@gmail.com> wrote:
> > On Monday, June 25, 2018 at 3:20:02 PM UTC-6, owl wrote:
> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >> > On Monday, June 25, 2018 at 8:55:24 AM UTC-6, owl wrote:
> >> >> Finally figured out how to create a built-in arbitrary precision
> >> >> addition function for sc.  This first attempt simply adds two cells.
> >> >> 
> >> >> https://pewtube.com/user/owl/pdscsXX?autoplay=off
> >> >> 
> >> >> Because sc's internal floating-point representation is a double, and
> >> >> therefore limited to that precision, the numbers for arbitrary precision
> >> >> math must entered as strings, with the function returning a string.
> >> >> 
> >> >> The function itself was easy enough, but figuring out how to get
> >> >> sc to save it took a lot of digging through the code. 
> >> > 
> >> > Why?
> >> > 
> >> 
> >> Because it was buried in a non-obvious (to me) place.  The code that
> >> causes the function to appear in the info line at the top when the
> >> cursor is over a cell containing a function, as in the image below where
> >> it shows:
> >> 
> >> A2 (78 2 0) <{@sadd(A0,A1)}
> >> 
> >> https://imgur.com/a/Z9f2Fsz
> >> 
> >> is also responsible for having the function written to a saved file.
> >> This is the code (in interp.c):
> >> 
> >> void
> >> decompile(register struct enode *e, int priority)
> >> {
> >>     register char *s;
> >>     if (e) {
> >>         int mypriority;
> >>         switch (e->op) {
> >> ...
> >>          case SADD:      two_arg("@sadd(", e); break;
> >> ...
> >> }
> >> 
> >> Without that case statement, the function, even though working correctly,
> >> displays as:
> >> 
> >> A2 (78 2 0) <{A0M(A1)}
> >> 
> >> and is written to a saved file as:
> >> 
> >> leftstring A2 = AOM(A1) 
> >> 
> >> When written that way, the function of course does not work when the file
> >> is reloaded.  After adding that case statement, the function gets properly 
> >> displayed as
> >> 
> >> A2 (78 2 0) <{@sadd(A0,A1)}
> >> 
> >> and written to the file as:
> >> 
> >> leftstring A2 = @sadd(A0,A1)
> >> 
> >> And now it works.  :)
> > 
> > This doesn't strictly apply here but it's always fun with no errors thrown 
> > where you wish they would be if that thing is going to end up being the 
> > eventual culprit. Yours is a bizarre situation but it's one of those little
> > 'learning experiences' you treasure... until you forget it next time.
> 
> The main difficulty here was that the text is in a variable called "line"
> (:O) that is printed by an ncurses function addstr() that is called by the
> update() function in screen.c, and I could not for the life of me find
> where it was supposed to be getting the correct string.  I ran tests
> an was able append to it manually, but that was it.  Basically, it's
> just a pain in the ass trying to navigate somebody else's complex code.

It doesn't help that you're doing the kind of thing you're not likely to find 
any kind of documentation for. I was wondering what you meant earlier by 
"digging through the code", this clears it up. If not via the tests, how did 
you figure it out?

[toc] | [prev] | [next] | [standalone]

#456428

Steve Carroll <fretwizzer@gmail.com> wrote:
> On Monday, June 25, 2018 at 3:48:35 PM UTC-6, owl wrote:
>> Steve Carroll <fretwizzer@gmail.com> wrote:
>> > On Monday, June 25, 2018 at 3:20:02 PM UTC-6, owl wrote:
>> >> Steve Carroll <fretwizzer@gmail.com> wrote:
>> >> > On Monday, June 25, 2018 at 8:55:24 AM UTC-6, owl wrote:
>> >> >> Finally figured out how to create a built-in arbitrary precision
>> >> >> addition function for sc.  This first attempt simply adds two cells.
>> >> >> 
>> >> >> https://pewtube.com/user/owl/pdscsXX?autoplay=off
>> >> >> 
>> >> >> Because sc's internal floating-point representation is a double, and
>> >> >> therefore limited to that precision, the numbers for arbitrary precision
>> >> >> math must entered as strings, with the function returning a string.
>> >> >> 
>> >> >> The function itself was easy enough, but figuring out how to get
>> >> >> sc to save it took a lot of digging through the code. 
>> >> > 
>> >> > Why?
>> >> > 
>> >> 
>> >> Because it was buried in a non-obvious (to me) place.  The code that
>> >> causes the function to appear in the info line at the top when the
>> >> cursor is over a cell containing a function, as in the image below where
>> >> it shows:
>> >> 
>> >> A2 (78 2 0) <{@sadd(A0,A1)}
>> >> 
>> >> https://imgur.com/a/Z9f2Fsz
>> >> 
>> >> is also responsible for having the function written to a saved file.
>> >> This is the code (in interp.c):
>> >> 
>> >> void
>> >> decompile(register struct enode *e, int priority)
>> >> {
>> >>     register char *s;
>> >>     if (e) {
>> >>         int mypriority;
>> >>         switch (e->op) {
>> >> ...
>> >>          case SADD:      two_arg("@sadd(", e); break;
>> >> ...
>> >> }
>> >> 
>> >> Without that case statement, the function, even though working correctly,
>> >> displays as:
>> >> 
>> >> A2 (78 2 0) <{A0M(A1)}
>> >> 
>> >> and is written to a saved file as:
>> >> 
>> >> leftstring A2 = AOM(A1) 
>> >> 
>> >> When written that way, the function of course does not work when the file
>> >> is reloaded.  After adding that case statement, the function gets properly 
>> >> displayed as
>> >> 
>> >> A2 (78 2 0) <{@sadd(A0,A1)}
>> >> 
>> >> and written to the file as:
>> >> 
>> >> leftstring A2 = @sadd(A0,A1)
>> >> 
>> >> And now it works.  :)
>> > 
>> > This doesn't strictly apply here but it's always fun with no errors thrown 
>> > where you wish they would be if that thing is going to end up being the 
>> > eventual culprit. Yours is a bizarre situation but it's one of those little
>> > 'learning experiences' you treasure... until you forget it next time.
>> 
>> The main difficulty here was that the text is in a variable called "line"
>> (:O) that is printed by an ncurses function addstr() that is called by the
>> update() function in screen.c, and I could not for the life of me find
>> where it was supposed to be getting the correct string.  I ran tests
>> an was able append to it manually, but that was it.  Basically, it's
>> just a pain in the ass trying to navigate somebody else's complex code.
> 
> It doesn't help that you're doing the kind of thing you're not likely to find 
> any kind of documentation for. I was wondering what you meant earlier by 
> "digging through the code", this clears it up. If not via the tests, how did 
> you figure it out?

I went back to square one and grep'ed for various '@functionnames'.
I had missed it.  It didn't help that there are other places where such
strings appear similarly, such as with

ins_string("@sum("); 

appearing in an ironically unrelated function called write_line().
It also didn't help that the "line" variable is global.

[toc] | [prev] | [next] | [standalone]

#456429

On Monday, June 25, 2018 at 4:17:38 PM UTC-6, owl wrote:
> Steve Carroll <fretwizzer@gmail.com> wrote:
> > On Monday, June 25, 2018 at 3:48:35 PM UTC-6, owl wrote:
> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >> > On Monday, June 25, 2018 at 3:20:02 PM UTC-6, owl wrote:
> >> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >> >> > On Monday, June 25, 2018 at 8:55:24 AM UTC-6, owl wrote:
> >> >> >> Finally figured out how to create a built-in arbitrary precision
> >> >> >> addition function for sc.  This first attempt simply adds two cells.
> >> >> >> 
> >> >> >> https://pewtube.com/user/owl/pdscsXX?autoplay=off
> >> >> >> 
> >> >> >> Because sc's internal floating-point representation is a double, and
> >> >> >> therefore limited to that precision, the numbers for arbitrary precision
> >> >> >> math must entered as strings, with the function returning a string.
> >> >> >> 
> >> >> >> The function itself was easy enough, but figuring out how to get
> >> >> >> sc to save it took a lot of digging through the code. 
> >> >> > 
> >> >> > Why?
> >> >> > 
> >> >> 
> >> >> Because it was buried in a non-obvious (to me) place.  The code that
> >> >> causes the function to appear in the info line at the top when the
> >> >> cursor is over a cell containing a function, as in the image below where
> >> >> it shows:
> >> >> 
> >> >> A2 (78 2 0) <{@sadd(A0,A1)}
> >> >> 
> >> >> https://imgur.com/a/Z9f2Fsz
> >> >> 
> >> >> is also responsible for having the function written to a saved file.
> >> >> This is the code (in interp.c):
> >> >> 
> >> >> void
> >> >> decompile(register struct enode *e, int priority)
> >> >> {
> >> >>     register char *s;
> >> >>     if (e) {
> >> >>         int mypriority;
> >> >>         switch (e->op) {
> >> >> ...
> >> >>          case SADD:      two_arg("@sadd(", e); break;
> >> >> ...
> >> >> }
> >> >> 
> >> >> Without that case statement, the function, even though working correctly,
> >> >> displays as:
> >> >> 
> >> >> A2 (78 2 0) <{A0M(A1)}
> >> >> 
> >> >> and is written to a saved file as:
> >> >> 
> >> >> leftstring A2 = AOM(A1) 
> >> >> 
> >> >> When written that way, the function of course does not work when the file
> >> >> is reloaded.  After adding that case statement, the function gets properly 
> >> >> displayed as
> >> >> 
> >> >> A2 (78 2 0) <{@sadd(A0,A1)}
> >> >> 
> >> >> and written to the file as:
> >> >> 
> >> >> leftstring A2 = @sadd(A0,A1)
> >> >> 
> >> >> And now it works.  :)
> >> > 
> >> > This doesn't strictly apply here but it's always fun with no errors thrown 
> >> > where you wish they would be if that thing is going to end up being the 
> >> > eventual culprit. Yours is a bizarre situation but it's one of those little
> >> > 'learning experiences' you treasure... until you forget it next time.
> >> 
> >> The main difficulty here was that the text is in a variable called "line"
> >> (:O) that is printed by an ncurses function addstr() that is called by the
> >> update() function in screen.c, and I could not for the life of me find
> >> where it was supposed to be getting the correct string.  I ran tests
> >> an was able append to it manually, but that was it.  Basically, it's
> >> just a pain in the ass trying to navigate somebody else's complex code.
> > 
> > It doesn't help that you're doing the kind of thing you're not likely to find 
> > any kind of documentation for. I was wondering what you meant earlier by 
> > "digging through the code", this clears it up. If not via the tests, how did 
> > you figure it out?
> 
> I went back to square one and grep'ed for various '@functionnames'.
> I had missed it.  It didn't help that there are other places where such
> strings appear similarly, such as with
> 
> ins_string("@sum("); 
> 
> appearing in an ironically unrelated function called write_line().
> It also didn't help that the "line" variable is global.

Makes things a lot more 'fun'. Are you doing this just to do it or
is there a reason behind it?

[toc] | [prev] | [next] | [standalone]

#456432

Steve Carroll <fretwizzer@gmail.com> wrote:
> On Monday, June 25, 2018 at 4:17:38 PM UTC-6, owl wrote:
>> Steve Carroll <fretwizzer@gmail.com> wrote:
>> > On Monday, June 25, 2018 at 3:48:35 PM UTC-6, owl wrote:
>> >> Steve Carroll <fretwizzer@gmail.com> wrote:
>> >> > On Monday, June 25, 2018 at 3:20:02 PM UTC-6, owl wrote:
>> >> >> Steve Carroll <fretwizzer@gmail.com> wrote:
>> >> >> > On Monday, June 25, 2018 at 8:55:24 AM UTC-6, owl wrote:
>> >> >> >> Finally figured out how to create a built-in arbitrary precision
>> >> >> >> addition function for sc.  This first attempt simply adds two cells.
>> >> >> >> 
>> >> >> >> https://pewtube.com/user/owl/pdscsXX?autoplay=off
>> >> >> >> 
>> >> >> >> Because sc's internal floating-point representation is a double, and
>> >> >> >> therefore limited to that precision, the numbers for arbitrary precision
>> >> >> >> math must entered as strings, with the function returning a string.
>> >> >> >> 
>> >> >> >> The function itself was easy enough, but figuring out how to get
>> >> >> >> sc to save it took a lot of digging through the code. 
>> >> >> > 
>> >> >> > Why?
>> >> >> > 
>> >> >> 
>> >> >> Because it was buried in a non-obvious (to me) place.  The code that
>> >> >> causes the function to appear in the info line at the top when the
>> >> >> cursor is over a cell containing a function, as in the image below where
>> >> >> it shows:
>> >> >> 
>> >> >> A2 (78 2 0) <{@sadd(A0,A1)}
>> >> >> 
>> >> >> https://imgur.com/a/Z9f2Fsz
>> >> >> 
>> >> >> is also responsible for having the function written to a saved file.
>> >> >> This is the code (in interp.c):
>> >> >> 
>> >> >> void
>> >> >> decompile(register struct enode *e, int priority)
>> >> >> {
>> >> >>     register char *s;
>> >> >>     if (e) {
>> >> >>         int mypriority;
>> >> >>         switch (e->op) {
>> >> >> ...
>> >> >>          case SADD:      two_arg("@sadd(", e); break;
>> >> >> ...
>> >> >> }
>> >> >> 
>> >> >> Without that case statement, the function, even though working correctly,
>> >> >> displays as:
>> >> >> 
>> >> >> A2 (78 2 0) <{A0M(A1)}
>> >> >> 
>> >> >> and is written to a saved file as:
>> >> >> 
>> >> >> leftstring A2 = AOM(A1) 
>> >> >> 
>> >> >> When written that way, the function of course does not work when the file
>> >> >> is reloaded.  After adding that case statement, the function gets properly 
>> >> >> displayed as
>> >> >> 
>> >> >> A2 (78 2 0) <{@sadd(A0,A1)}
>> >> >> 
>> >> >> and written to the file as:
>> >> >> 
>> >> >> leftstring A2 = @sadd(A0,A1)
>> >> >> 
>> >> >> And now it works.  :)
>> >> > 
>> >> > This doesn't strictly apply here but it's always fun with no errors thrown 
>> >> > where you wish they would be if that thing is going to end up being the 
>> >> > eventual culprit. Yours is a bizarre situation but it's one of those little
>> >> > 'learning experiences' you treasure... until you forget it next time.
>> >> 
>> >> The main difficulty here was that the text is in a variable called "line"
>> >> (:O) that is printed by an ncurses function addstr() that is called by the
>> >> update() function in screen.c, and I could not for the life of me find
>> >> where it was supposed to be getting the correct string.  I ran tests
>> >> an was able append to it manually, but that was it.  Basically, it's
>> >> just a pain in the ass trying to navigate somebody else's complex code.
>> > 
>> > It doesn't help that you're doing the kind of thing you're not likely to find 
>> > any kind of documentation for. I was wondering what you meant earlier by 
>> > "digging through the code", this clears it up. If not via the tests, how did 
>> > you figure it out?
>> 
>> I went back to square one and grep'ed for various '@functionnames'.
>> I had missed it.  It didn't help that there are other places where such
>> strings appear similarly, such as with
>> 
>> ins_string("@sum("); 
>> 
>> appearing in an ironically unrelated function called write_line().
>> It also didn't help that the "line" variable is global.
> 
> Makes things a lot more 'fun'. Are you doing this just to do it or
> is there a reason behind it?

A variety of reasons.  A big part of it is that it gives me greater 
understanding of how SC works.  But in this particular case, once I get
it working with ranges, it will lead to a more efficient way to do this
sort of function.  It would be nice if @ext() worked with ranges, but
no joy there.  So you have to use "fkey" and "merge" with an external
function calling bc or whatever.  Unfortunately, that requires tapping
a function key to update.  A builtin updates automatically, so that's
the goal.

[toc] | [prev] | [next] | [standalone]

#456455

On Monday, June 25, 2018 at 4:48:08 PM UTC-6, owl wrote:
> Steve Carroll <fretwizzer@gmail.com> wrote:
> > On Monday, June 25, 2018 at 4:17:38 PM UTC-6, owl wrote:
> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >> > On Monday, June 25, 2018 at 3:48:35 PM UTC-6, owl wrote:
> >> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >> >> > On Monday, June 25, 2018 at 3:20:02 PM UTC-6, owl wrote:
> >> >> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >> >> >> > On Monday, June 25, 2018 at 8:55:24 AM UTC-6, owl wrote:
> >> >> >> >> Finally figured out how to create a built-in arbitrary precision
> >> >> >> >> addition function for sc.  This first attempt simply adds two cells.
> >> >> >> >> 
> >> >> >> >> https://pewtube.com/user/owl/pdscsXX?autoplay=off
> >> >> >> >> 
> >> >> >> >> Because sc's internal floating-point representation is a double, and
> >> >> >> >> therefore limited to that precision, the numbers for arbitrary precision
> >> >> >> >> math must entered as strings, with the function returning a string.
> >> >> >> >> 
> >> >> >> >> The function itself was easy enough, but figuring out how to get
> >> >> >> >> sc to save it took a lot of digging through the code. 
> >> >> >> > 
> >> >> >> > Why?
> >> >> >> > 
> >> >> >> 
> >> >> >> Because it was buried in a non-obvious (to me) place.  The code that
> >> >> >> causes the function to appear in the info line at the top when the
> >> >> >> cursor is over a cell containing a function, as in the image below where
> >> >> >> it shows:
> >> >> >> 
> >> >> >> A2 (78 2 0) <{@sadd(A0,A1)}
> >> >> >> 
> >> >> >> https://imgur.com/a/Z9f2Fsz
> >> >> >> 
> >> >> >> is also responsible for having the function written to a saved file.
> >> >> >> This is the code (in interp.c):
> >> >> >> 
> >> >> >> void
> >> >> >> decompile(register struct enode *e, int priority)
> >> >> >> {
> >> >> >>     register char *s;
> >> >> >>     if (e) {
> >> >> >>         int mypriority;
> >> >> >>         switch (e->op) {
> >> >> >> ...
> >> >> >>          case SADD:      two_arg("@sadd(", e); break;
> >> >> >> ...
> >> >> >> }
> >> >> >> 
> >> >> >> Without that case statement, the function, even though working correctly,
> >> >> >> displays as:
> >> >> >> 
> >> >> >> A2 (78 2 0) <{A0M(A1)}
> >> >> >> 
> >> >> >> and is written to a saved file as:
> >> >> >> 
> >> >> >> leftstring A2 = AOM(A1) 
> >> >> >> 
> >> >> >> When written that way, the function of course does not work when the file
> >> >> >> is reloaded.  After adding that case statement, the function gets properly 
> >> >> >> displayed as
> >> >> >> 
> >> >> >> A2 (78 2 0) <{@sadd(A0,A1)}
> >> >> >> 
> >> >> >> and written to the file as:
> >> >> >> 
> >> >> >> leftstring A2 = @sadd(A0,A1)
> >> >> >> 
> >> >> >> And now it works.  :)
> >> >> > 
> >> >> > This doesn't strictly apply here but it's always fun with no errors thrown 
> >> >> > where you wish they would be if that thing is going to end up being the 
> >> >> > eventual culprit. Yours is a bizarre situation but it's one of those little
> >> >> > 'learning experiences' you treasure... until you forget it next time.
> >> >> 
> >> >> The main difficulty here was that the text is in a variable called "line"
> >> >> (:O) that is printed by an ncurses function addstr() that is called by the
> >> >> update() function in screen.c, and I could not for the life of me find
> >> >> where it was supposed to be getting the correct string.  I ran tests
> >> >> an was able append to it manually, but that was it.  Basically, it's
> >> >> just a pain in the ass trying to navigate somebody else's complex code.
> >> > 
> >> > It doesn't help that you're doing the kind of thing you're not likely to find 
> >> > any kind of documentation for. I was wondering what you meant earlier by 
> >> > "digging through the code", this clears it up. If not via the tests, how did 
> >> > you figure it out?
> >> 
> >> I went back to square one and grep'ed for various '@functionnames'.
> >> I had missed it.  It didn't help that there are other places where such
> >> strings appear similarly, such as with
> >> 
> >> ins_string("@sum("); 
> >> 
> >> appearing in an ironically unrelated function called write_line().
> >> It also didn't help that the "line" variable is global.
> > 
> > Makes things a lot more 'fun'. Are you doing this just to do it or
> > is there a reason behind it?
> 
> A variety of reasons.  A big part of it is that it gives me greater 
> understanding of how SC works.  But in this particular case, once I get
> it working with ranges, it will lead to a more efficient way to do this
> sort of function.  It would be nice if @ext() worked with ranges, but
> no joy there.  So you have to use "fkey" and "merge" with an external
> function calling bc or whatever.  Unfortunately, that requires tapping
> a function key to update.  A builtin updates automatically, so that's
> the goal.

MGGA!
(make Geeks great again)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.advocacy

csiph-web