A programming problem, met in OS 3.2 only

[Jim Fullerenex]

Hi everyone,

So here's a problem that's quite hard to explain. I never met this situation in OS 3.1; the error appears only in 3.2

I have a library document called DiffCalc. In the DiffCalc, I wrote a program:

Define LibPub cut() =

Prgm

//creates library shortcut

Disp "Shortcut please enter d."

libShortcut("diffcalc","d")

DelVar d.cut

EndPrgm

When I actually want to do math, I work with another document, outside MyLib folder, called "MathWorkshop", which contains all of the shortcuts to my various libraries.

In MathWorkshop, I defined a program load(), to update any changes I make to my libraries.

Define load() =

Prgm

DelVar d.

diffcalc\cut()

EndPrgm

In OS 3.1, each time I change the contents of DiffCalc, i will run load() in MathWorkshop to update the changes. Everything goes well until 3.2

First I refresh the library. 

Then I run load(), an error appears "Invalid Program Reference".

Then I run load() again, the error disappears and everything goes OK as in 3.1. 

I run load() yet again, the error reappears.

I don't understand at all. What has happened in the update? Could anyone shed some light on the situation?

Thanks!

Best,

Jim

[Joe]

Hi Jim. I havn't tried it but some posts on Omnimagna indicate that
you can down grade back to os 3.1. Then you can wait for TI to
generate another os to fix the problems generated by this os. It
would seem likely that the next os will of course generate new
problems but if you are lucky the present problem you are having will
be fixed. Good luck.

[Lionel Debroux]

Hi,

The fact that it works on and off seems like quite a weird, erratic
behaviour...

The "Invalid Program Reference" message is well-known on TI-68k
calculators: that's how an artificial restriction of AMS 2.xx and 3.xx
(i.e. everything since 1999) shows up when using ASM programs in
expressions, e.g. storing the result laid out on the EStack by the ASM
program.
Needless to say, both of the most obnoxious artificial limitations in
AMS, namely "Invalid Program Reference" and "ASAP or Exec string too
long", were quickly nullified.


Lionel.

[Jim Fullerenex]

Hi Lionel, so how can I express the problem? Why is it in 3.2 but not in 3.1? Which part of the update could possibly produce such an erratic behavior?

I find it hard even to describe the bug in a few lines... So I hope any TI guys here can understand what's really going wrong and fix it asap.

FYI, I checked against my friend's not-yet-upgraded handheld. Not only the loops, but also everything in TI BASIC seems to slow down significantly. ;(

I have quite a number of programs that exceed 60 lines.
Now in OS 3.2, operations like opening them up, making a few edits, or closing the Prgm editor can take much more time than 3.1.
What's more, the 3.2 Note page also slows down more than 3.1 when the text gets longer.

For most of the time my friends and I don't have access to a software; so on-calc editing is essential and the slower processing is unacceptable.

I hope the issue gets enough attention it deserves.

PS, just tried Joe's suggestion. Yes I can downgrade and I did. I guess i have to stick around with 3.1 a bit longer.

Best,

Jim

> --
> To post to this group, send email to tins...@googlegroups.com
> To unsubscribe send email to tinspire+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com.au/group/tinspire?hl=en-GB?hl=en-GB
> The tns documents shared by group members are archived at
> https://sites.google.com/site/tinspiregroup/classroom-news/welcome-abouttime

[Adriweb]

I'll report the problem on the first post since this is quite weird...

About the slowness in Notes, it's because TI updated their xml format to a .... worse one.

Before, it was very bad, and now it's even worse.

Just so you know, on a Notes page, the content is saved as xml and as a "tree".

Each node has several leafs, which are for ... *each word*. Yes, each word. And these leafs have a lot of parameters.

(like, hundred formatting chars are made for each word !)

There are a lot of unneeded fiels for each xml leaf, which just need to be deleted, so I'll report that too.


Anyway, yes, if you can't stand the bugs, do downgrade :)

Maybe they actually left that choice for this kind of things....

On Saturday, June 9, 2012 11:47:58 AM UTC+2, Nspire MasterMind wrote:

Hi Lionel, so how can I express the problem? Why is it in 3.2 but not in 3.1? Which part of the update could possibly produce such an erratic behavior?

I find it hard even to describe the bug in a few lines... So I hope any TI guys here can understand what's really going wrong and fix it asap.

FYI, I checked against my friend's not-yet-upgraded handheld. Not only the loops, but also everything in TI BASIC seems to slow down significantly. ;(

I have quite a number of programs that exceed 60 lines.
Now in OS 3.2, operations like opening them up, making a few edits, or closing the Prgm editor can take much more time than 3.1.
What's more, the 3.2 Note page also slows down more than 3.1 when the text gets longer.

For most of the time my friends and I don't have access to a software; so on-calc editing is essential and the slower processing is unacceptable.

I hope the issue gets enough attention it deserves.

PS, just tried Joe's suggestion. Yes I can downgrade and I did. I guess i have to stick around with 3.1 a bit longer.

Best,

Jim

> To unsubscribe send email to tinspire+unsubscribe@googlegroups.com

[Levak Borok]

Before (3.0.1, 3.0.2, 3.1) : 

        <r2dtotree>

          <node name="1doc">

            <node name="1para">

              <node name="1rtline">

                <leaf name="1word">

                  <cursor index="0"/>

                </leaf>

                <leaf name="1word">Hello</leaf>

                <leaf name="1word">World</leaf>

              </node>

            </node>

        </r2dtotree>

Now (3.2) : 

    <r2dtotree>

      <node name="1doc">

        <node name="1para">

          <node name="1rtline">

            <leaf name="1word" fi="1" np="1" tc0="0" fc0="268435199" fn0="TI-Nspire Sans" fs0="11" fst0="0" fest0="0" feun0="0" fesub0="0" fesup0="0" cc0="0" pp0="5">Hello </leaf>

            <leaf name="1word" fi="1" np="1" tc0="0" fc0="268435199" fn0="TI-Nspire Sans" fs0="11" fst0="0" fest0="0" feun0="0" fesub0="0" fesup0="0" cc0="0" pp0="5">world

              <cursor index="0"/>

            </leaf>

          </node>

        </node>

      </node>

    </r2dtotree>

2012/6/9 Adriweb <bertran...@gmail.com>

To unsubscribe send email to tinspire+u...@googlegroups.com

[Jim Fullerenex]

Thanks for all the explanation... But Why? Why would they ever bother to update something to even worse? Rewriting any code must have taken up a lot of efforts...

Best,

Jim

To unsubscribe send email to tinspire+u...@googlegroups.com

[Lionel Debroux]

Hi Jim,

> Hi Lionel, so how can I express the problem? Why is it in 3.2 but not
> in 3.1?

Some unwanted changes occurred in the CAS between 2.1.0.631 and
3.0.1.1753; I guess that other unwanted changes went in between
3.1.0.392 and 3.2.0.1212...

> Which part of the update could possibly produce such an erratic
> behavior?

Maybe the undocumented library system, or the undocumented virtual
filesystem stuff for storing variables into documents.
Those parts are different enough from TI-68k/AMS, which didn't have the
concept of documents and libraries, that third parties like me cannot
provide accurate guesses :)

> I find it hard even to describe the bug in a few lines... So I hope
> any TI guys here can understand what's really going wrong and fix
> it asap.

I just hope they'll be able to reproduce the problem.

> FYI, I checked against my friend's not-yet-upgraded handheld. Not
> only the loops, but also everything in TI BASIC seems to slow down
> significantly. ;(

That's even more annoying. Did they pessimize the core as well, for
instance next_expression_index, which was already no speed daemon in
TI-68k/AMS ?
The code that tries to find definition domains for functions must have
some cost, but I can't see why it would have an impact on the TI-BASIC
interpretation.

> I have quite a number of programs that exceed 60 lines.
> Now in OS 3.2, operations like opening them up, making a few edits,
> or closing the Prgm editor can take much more time than 3.1.
> What's more, the 3.2 Note page also slows down more than 3.1 when
> the text gets longer.

As Adriweb wrote, that's probably due to the new document format being
even more brain-damaged than the previous one. A disgusting abuse of
XML, resulting in heavyweight processing, especially unsuitable for
embedded platforms...
Among various markup formats suitable for embedded platforms that TI
could have chosen, years before the Nspire even existed, on TI-68k
calculators, third parties provided formatted text documents with
multiple font size, underlined, bold, images, etc. Lots of people know
the markup supported by the old and unstable txtrider tool, and its
newer successors Hib-View & uView.
But TI reinvented a wheel, and did it badly...

> For most of the time my friends and I don't have access to a
> software; so on-calc editing is essential and the slower processing
> is unacceptable.

That's understandable. Users are under no obligation to withstand newer
versions that are worse than the older versions...

> I hope the issue gets enough attention it deserves.

Don't set your hopes too high: history is full of examples showing that
TI seldom takes performance / size issues seriously, on the TI-Z80,
TI-68k and Nspire platforms alike.
Just several examples, I've already mentioned some (if not all ^^) of
them on this list over time:
* TI-Z80: "everybody" knows that older TI-Z80 models can execute simple
loops containing "Disp" instructions faster than newer models do.
There's a pretty enlightening video to that effect (which shows the
Nspire losing to the two TI-Z80 and the TI-68k, BTW). I'm not even
talking about 84+ OS 2.53MP;

* TI-68k:
* AMS 2.xx (in 1999) making DrawChar, DrawStr and friends 3x slower,
due to the very rarely used, and very badly implemented, capability of
redefining the system font;
* AMS 2.xx making command tokenization and interpretation slower
through the silly (badly implemented) language localization support,
which, as a bonus, creates spurious incompatibilities between languages
(the only way to write some constructs in a portable way is to handle
each possible language specifially !!);
* in 2002-2003, AMS 2.08 and 2.09 using a worse toolchain that
generates even worse code, resulting in the binary spilling over to
another sector of Flash memory for a hair (several hundreds of bytes),
depriving users from 64 KB (10% !) of usable archive memory...
* in 2004, AMS 3.xx using an even worse toolchain that generates
even worse code than for AMS 2.08 / 2.09.

(the three first items are alleviated / fixed by my tiosmod + amspatch,
by removing the capability to redefine fonts, removing the capability to
change languages, and moving data from the end of the OS to a huge
unused area near the beginning of the Flash memory)


The release of the pessimized AMS 2.08 & 2.09 for 89 and 92+ was done in
the same timeframe (2002-2003) as the introduction of the newer V200,
and some time before the introduction of the 89T;
The release of the 89T, and the pessimized AMS 3.xx, was done in 2004,
i.e. two years before the Nspire CAS+, and three years before the
prototype & production Clickpad Nspire.
Who knows, maybe TI has a new series of calculators in mind for 2014 or
2015, and feels like starting to artificially pessimize the Nspire, so
that the next model feels like even more of an improvement ? :D

> PS, just tried Joe's suggestion. Yes I can downgrade and I did.
> I guess i have to stick around with 3.1 a bit longer.

That's a wise choice ;)


Bye,
Lionel.

[Levak Borok]

As you can see, they added multi-formats per words, based on their already heavy XML tree.

In html, it would have been <b>H</b>ello <b>W</b>orld. In TI-Nspire 3.2 it is : 

<r2dtotree>

      <node name="1doc">

        <node name="1para">

          <node name="1rtline">

            <leaf name="1word" fi="1" np="2" tc0="0" fc0="268435199" fn0="TI-Nspire Sans" fs0="11" fst0="1" fest0="0" feun0="0" fesub0="0" fesup0="0" cc0="0" pp0="1" tc1="0" fc1="268435199" fn1="TI-Nspire Sans" fs1="11" fst1="0" fest1="0" feun1="0" fesub1="0" fesup1="0" cc1="0" pp1="5" ucf="1" ucfa="1">Hello </leaf>

            <leaf name="1word" fi="1" np="2" tc0="0" fc0="268435199" fn0="TI-Nspire Sans" fs0="11" fst0="1" fest0="0" feun0="0" fesub0="0" fesup0="0" cc0="0" pp0="1" tc1="0" fc1="268435199" fn1="TI-Nspire Sans" fs1="11" fst1="0" fest1="0" feun1="0" fesub1="0" fesup1="0" cc1="0" pp1="5" ucf="1" ucfa="1">

              <cursor index="0"/>

              W

              <cursor index="1"/>

              orld</leaf>

          </node>

        </node>

      </node>

    </r2dtotree>

2012/6/9 Jim Fullerenex <smoa...@gmail.com>

[Lionel Debroux]

Heh, aren't Levak's examples cute ? :)

> Anyway, yes, if you can't stand the bugs, do downgrade :)
> Maybe they actually left that choice for this kind of things....

-Maybe +Clearly, IMO.
Letting users the choice to downgrade is not at all for letting them
access native code for a little bit longer. It's for letting them escape
the bugs and performance regressions of the new OS version...

Either they knew that the product is defective and released it no matter
what (and letting users downgrade was the only sane thing to do), or
they didn't know and their testing procedures are, once more, inadequate
(and letting users downgrade was a sane thing to do anyway, should any
important bugs not detected in testing spring up)...
Sadly, I think it's the former, because there have been just too many
problem reports in too few days for TI being unaware of the fact that
their new OS version stinks...


Lionel.

[Levak Borok]

A smart example of that same situation : OS 2.1 

Indeed, OS 2.1 overclocks the Nspires but the performances are quite the same.

Experiments have been made showing that OS 2.1 uses overclocking to hide performances problems in maths, doc browser and notes.

2012/6/9 Lionel Debroux <debroux...@gmail.com>

Lionel.

--
To post to this group, send email to tins...@googlegroups.com

To unsubscribe send email to tinspire+u...@googlegroups.com

[Jim Fullerenex]

I see. I don't understand XML so didn't quite get through it last time. 

As Adrien pointed out, TI's latest algorithm acts so poorly that it must be improved. ;)

Thanks to all who explained the issue. For those who have to do on-calc editing from time to time, I'd suggest you remain in 3.1 for a while. Only for your handhelds; the software update is nice anyway.

Best,

Jim

On 2012-6-9, at 23:28, Levak Borok <lev...@gmail.com> wrote:

As you can see, they added multi-formats per words, based on their already heavy XML tree.

In html, it would have been <b>H</b>ello <b>W</b>orld. In TI-Nspire 3.2 it is : 

<r2dtotree>

      <node name="1doc">

        <node name="1para">

          <node name="1rtline">

            <leaf name="1word" fi="1" np="2" tc0="0" fc0="268435199" fn0="TI-Nspire Sans" fs0="11" fst0="1" fest0="0" feun0="0" fesub0="0" fesup0="0" cc0="0" pp0="1" tc1="0" fc1="268435199" fn1="TI-Nspire Sans" fs1="11" fst1="0" fest1="0" feun1="0" fesub1="0" fesup1="0" cc1="0" pp1="5" ucf="1" ucfa="1">Hello </leaf>

            <leaf name="1word" fi="1" np="2" tc0="0" fc0="268435199" fn0="TI-Nspire Sans" fs0="11" fst0="1" fest0="0" feun0="0" fesub0="0" fesup0="0" cc0="0" pp0="1" tc1="0" fc="268435199" fn1="TI-Nspire Sans" fs1="11" fst1="0" fest1="0" feun1="0" fesub1="0" fesup1="0" cc1="0" pp1="5" ucf="1" ucfa="1">