Somewhat inconsistent limitations…

#1
I was showing off Take Command to a friend (I’m somewhat of an evangelizer for Take Command (with little success so far, sadly)) and I was demonstrating Take Command’s high-precision arithmetic and sadly ran into that inconsistency with maximum (environment) variable and possibly command-line length (a little less than 4K on my system as far as I can tell) and @Eval’s maximum precision (1 place for sign plus 10,000 digits to the left of the decimal point plus the decimal point plus 10,000 digits after the decimal point yields 20002 characters – almost 5 times larger than what an environment variable can contain). @Eval’s maximum precision is almost meaningless given these “external” limitations – and, after a lot of experimentation (like writing the result to a file and trying to read that file) came to nothing. I don’t quite know what my suggested solution would be – making the maximum length of an environment variable/command line 20K characters seems to be a little excessive – maybe the best solution is something to do with @ExecStr – although I don’t really know what the “command” would be….
 

rconn

Administrator
Staff member
May 14, 2008
10,415
95
#2
Somewhat inconsistent limitations.

> I was showing off Take Command to a friend (I'm somewhat of an
> evangelizer for Take Command (with little success so far, sadly)) and I
> was demonstrating Take Command's high-precision arithmetic and sadly
> ran into that inconsistency with maximum (environment) variable and
> possibly command-line length (a little less than 4K on my system as far
> as I can tell) and @Eval's maximum precision (1 place for sign plus
> 10,000 digits to the left of the decimal point plus the decimal point
> plus 10,000 digits after the decimal point yields 20002 characters -
> almost 5 times larger than what an environment variable can contain).
The maximum line input size in TCC is 32K characters; the maximum expanded
line size is 64K characters. What you're seeing is the maximum single
argument size, which is 4K characters. If you actually *need* to display a
20K variable, there are ways to do it (though AFAIK nobody's really needed
it thus far).

I could easily boost the max argument size, but it substantially increases
the memory requirements (roughly geometrically), and would probably require
everybody to switch to an x64 version of Windows and add a lot of RAM.

Rex Conn
JP Software
 
#3
Re: Somewhat inconsistent limitations.

If you actually *need* to display a 20K variable, there are ways to do it (though AFAIK nobody's really neededI could easily boost the max argument size, but it substantially increases the memory requirements (roughly geometrically), and would probably require everybody to switch to an x64 version of Windows and add a lot of RAM.

I could easily boost the max argument size, but it substantially increases the memory requirements (roughly geometrically), and would probably require everybody to switch to an x64 version of Windows and add a lot of RAM.
Simply put, I'd like to know at least one of the ways to do it. The inability to pass a large (>4k in length) result of one calculation to a subsequent calculation is a noticable limitation in my opinion. And I agree with you that it's not important enough to make (most) existing buffers in TCC that much larger. (I believe I made a comment in my original e-mail to that effect.)
 

rconn

Administrator
Staff member
May 14, 2008
10,415
95
#4
Re: Somewhat inconsistent limitations.

> Simply put, I'd like to know at least one of the ways to do it. The
> inability to pass a large (>4k in length) result of one calculation to
> a subsequent calculation is a noticable limitation in my opinion. And I
> agree with you that it's not important enough to make (most) existing
> buffers in TCC that much larger. (I believe I made a comment in my
> original e-mail to that effect.)
Before I do, I'm interested in knowing just *why* you need this. (This also
affects which approach to use.)

Also, I should warn you that when you create environment variables this
large, you're going to have real problems starting other apps from TCC. A
LOT of apps will crash when they inherit a big environment and/or big
variables.

Rex Conn
JP Software
 
#5
Re: Somewhat inconsistent limitations.

Before I do, I'm interested in knowing just *why* you need this. (This also affects which approach to use.)
Rex, it's quite simply that I'm in love with your product(s), so to speak (and I’m not completely sure I could live without them at this point in time), and I evangelize them (again, sadly, to no great effect) at every opportunity (I did so again today, again to no great effect. And I quote: “I don’t use or need a command processor.”). So it's bad news when something doesn’t work quite like one would expect it to (why bother to go to that many digits of precision if there’s no way to store them?). But then, I do agree that this is not terribly important. (And again, I just need this to do "good" demos, so I don't think it matters a lot which approach to take; I would just make the general statement that "simpler is better".)<O:p</O:p