MaxCoderz

Appvar is not good, because searching for an appvar each time will slow things down and defeat the purpose. I know, because my app CalcUtil used to look up an appvar each time the parser hook fired, and it slowed execution speed to about 1/3 normal. But three or four bytes of ram, maybe at the begin...

I'll trust your judgment since you're the author, but I think that parsing three real numbers every other line of execution has to take some toll on speed. As for the issue of getting overwritten, you could tell the person to re-establish the parameters after running asm libraries.

No, I'm saying that I don't like the idea of an entire function-recalling system. It's overly complicated, it would slow down command execution, and you've pointed out a logic flaw that could lead to problems (though I think that the stack would overflow and a ram clear would occur before batteries ...

A recalled command, that lets you repeat any possible function, would be slower than the command originally was. However, a command to recall one particular function, like real(50 that calls real(30,aa,bb,cc,dd,ee,ff, would be muhc faster, if done properly (shouldn't be too hard to do). I'm not sugg...

Ok. Well, it'd still be faster and smaller if you could store the data as single-byte numbers and call a function with one parameter. I'll leave it up to the author to decide if the function is worth adding. I think it is.

Oh, sorry. I guess I didn't read the guide as closely as I should have. Still, how many arguments are needed for the xLIB rclpic command? I maintain that it is still faster for a function to be called with one argument than 8, it is still faster for an assembly program to read a byte out of ram than...

Hmm. Well, there are something like 255 possible strings on the calculator. What if there were an assembly program that could store to and retrieve from each string, using a variable to specify which string you wanted. Then, you could use Strings 1 through 0 (10) as normal strings, and Strings 11 th...

Well, that would be more difficult that what I suggested. This would involve dynamically creating some way of looking up functions and parameters, which might even be slower than originally, I'm not sure. At any rate the data would probably have to be written to an appvar for storage, and accessing ...

According to a basic grayscale guide I found on ticalc.org, every other line you need to use a command like "real(20,8,0,0,96,62,0,0" to flip the bits. What I'm saying is, there should be one command that tells xLIB that you want to use the parameters 8,0,0,96,62,0,0, and then you call rea...

I've got an idea for a feature. It might not make sense, since I haven't done any grayscale programs, but I think it might make sense. Every other line, you need to call a function to cycle the grayscale bits. What if there was a function to load a list of bits to cycle, or a list of functions to ru...

I once had a dream in which Rube from the TV show Dead Like Me was teaching a class. I and the other characters from DLM were in the class. The class was about how, since (according to Rube in the dream) the government mostly used computers based on z80 cpus, and z80s have poor security features, it...

Well, that's once example of how the hooks can interact improperly if they all act on the same input. However, I guess it won't be such a big deal if users are smart enough to not use completely conflicting apps. Also, sorry for the post about your project. I just realized what happened. I was reply...

Sorry if I didn't make myself clear, but that's what I meant. When I said it calls each hook, I meant it calls each application's ________ hook. It calls each application through the hook, passing the same data in the registers, simulating the OS's call, so that way each app has a chance to do what ...

I don't think much information has been released about the hook manager yet, but when it is released it will probably be at Detached Solutions. I'd assume that it will call each hook in succession with the same keypress or function or whatever, so it should let xLIB work with Omnicalc. Of course, xL...

If I recall, xLIB did chain properly with Omnicalc, and the problem was just that it used the same function numbers as Symbolic. Someone could change the numbers that Symbolic uses, but the problem is that Omnicalc doesn't properly chain with Symbolic. Instead of passing the numbers to it's parser h...