Page 1 of 2

Using "real(" Functions

Posted: Wed 11 Jul, 2007 10:58 pm
by JoostinOnline
:cry: Why, oh why did you have to make xlib use real(00 through real(30 ?
Whenever I run something that uses xlib, first I have to disable both Omnicalc and Symbolic, which makes Pretty Print just about worthless. I love those apps since I only do Basic programming. Without Omnicalc I can't restore my ram if my calc crashes (that happens alot b/c of all the testing I do on it :( ). I am forced to use your old buggy version of xlib that was an asm program, so I am missing a bunch of features. Is it not possible to change the real( function to somthing else :?:

Posted: Thu 12 Jul, 2007 12:48 am
by merthsoft
It's not that it's the real functions, it's that it's a parser hook. And the ram recovery still works fine for me. Someone is working on a hook manager that should make all that work better soon.

Posted: Thu 12 Jul, 2007 1:57 am
by tr1p1ea
Indeed it has nothing to do with the real( token, its the parser hook. I could change it to anything, like int( for example and it would still conflict with omnicalc.

Andy_J is making a hook manager for SoC, this will enable a range of hooks to be run concurrently.

Posted: Thu 12 Jul, 2007 2:09 am
by Andy_J
Except it won't work if you have apps that use the same numbers in real( -- one of you is going to have to change your numbers, which would break all preexisting programs using it. =\

How am I supposed to know if you mean real(10 from Omnicalc or from xLIB? I just can't do anything about something like that, sorry. :(

Posted: Thu 12 Jul, 2007 5:49 am
by tr1p1ea
Indeed that is a problem. I call dibs on not changing!

Posted: Thu 12 Jul, 2007 3:30 pm
by merthsoft
I think you and Michael should have a fight to the death.

Posted: Thu 12 Jul, 2007 5:47 pm
by JoostinOnline
What if you and Michael found a way for the apps to chain like symbolic and omnicalc (which I know is just about imposible :x ) do, and then made a special version that used different tokens. That way, the all previous programs would not have to change their format.

Posted: Thu 12 Jul, 2007 11:49 pm
by tr1p1ea
I think backwards compatibility is more useful to people than breaking it just for omnicalc. I might be able to make a 'run omnicalc function' function though.

Posted: Fri 13 Jul, 2007 10:16 pm
by JoostinOnline
tr1p1ea wrote:I think backwards compatibility is more useful to people than breaking it just for omnicalc.
But Omnicalc and Symbolic are the only apps that seem to have a big problem with it :? . Besides, the only people who need it to run at the same time are programmers.
tr1plea wrote: I might be able to make a 'run omnicalc function' function though.
I assume this would still disable symbolic's functions, as well as all of Omnicalc's non-programming options :? . Still, that would be really nice :D !

Posted: Sat 14 Jul, 2007 2:13 am
by Andy_J
There's no reason for all of Omnicalc's other options to be forcibly disabled. Install Omnicalc, then install xLIB, and the only thing that shouldn't work in Omnicalc is its parser hook. Its key hooks and memory protection and all that jazz should still work.

Posted: Sat 14 Jul, 2007 5:59 pm
by JoostinOnline
Andy_J wrote:There's no reason for all of Omnicalc's other options to be forcibly disabled.
Hmm.. :? .
It's actually been awhile since I even tried installing both, and that was when I used TI-OS v2.41, which had about 3 million bugs, so the ram clears and all that other crap may have just been TI's fault :lol: . Also, I used your previous version of xlib. Would that make a difference :?:

Posted: Sat 14 Jul, 2007 6:03 pm
by JoostinOnline
Just tried it with the new version and it works :)

Posted: Mon 16 Jul, 2007 7:10 am
by magicdanw
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 hook, it directly calls Symbolic's functions (I think), so both Symbolic and Omnicalc would have to be altered.

So, I think the one solution is for xLIB to have an option that switches between using the old numbers and using a new set of numbers compatible with Omnicalc and Symbolic. Then you'd choose whether you're interested in playing existing xLIB games or if you're interested in the new, compatible functions.

Another solution is for xLIB to determine whether the user wants to use it's function or Symbolic's function based on the number and type of parameters (for functions that have different parameters), and then passes on to Symbolic if necessary.

I'd say the first version is simpler to implement, but the second version could potentially be more compatible overall. If my post is hard to understand or is inaccurate, please let me know.

Posted: Mon 16 Jul, 2007 3:32 pm
by merthsoft
magicdanw wrote:If I recall, xLIB did chain properly with Omnicalc, and the problem was just that it used the same function numbers as Symbolic.
tr1p1ea wrote:Indeed it has nothing to do with the real( token, its the parser hook. I could change it to anything, like int( for example and it would still conflict with omnicalc.
When tr1p says it's so, it's so.

Posted: Mon 16 Jul, 2007 6:45 pm
by King Harold
Merthsoft has a point, and iirc there wasn't a very much spare room in xLIB so uber cool omnicalc-detection might not even fit..
The hook chaining project is interesting though, would xLIB still conflict with omnicalc when the hook chainer is used? (where is that project by the way?)