Cool. I'm sick of the beta version.

But I'm sure this one won't be any better ;-)

Pardon my stupidity, but why would a firewall block sending programs to a calculator?

some firewalls block all different kinds of traffic, and even stop programs from launching other programs
i use Kerio Personal Firewall(to lazy to link, just google it), and it works great, anytime a program tries to do something outside of itself its asks you to permit or deny it, it hasnt slipped up yet and i definitly recommend it

-jordan

Hey! I've seen Morgan say b*tch!

Um... didnt get it.... Did I miss something?

45MB? How on EARTH can a linking package grow to 45MB?
Gah *returns to FastLink*

That was exactly my reaction.

45mb? wow, I guess those USB drivers require alot of coding. :-)

more like it needs absolute flexibility to work with the inevitable 73 versions of SP2 :)
which reminds me... anyone else install it yet? I was impatient, so i downloaded it from fileplanet. the new IE blocks those "do you want to install and run" dialogs. which is good because i spent 2 hours yesterday looking for a cs key.

Because it's great.

-Scanning of every port on the computer for any sort of TI calculator

-Expandable while in operation. You can even use different calculators on the same link cable.

-Screenshots while programs are running

-Links to other TI programs on the computer

-Intuitive extension of Windows Explorer interface to TI calculator, like it's a drive

-Interface without hidden or unnecessary features that's obvious to any person familiar with calculators

-Advanced device information without the TIGCC bugs

-Updates of TI programs and calculator OSs

-Calculator backup and restore with an editor to retrieve specific files from the backup

-Data editor, which isn't too useful but if you use a lot of numbers in databases, they can be edited on a larger screen

-Only one bug: you can't click on the TI Connect tab in the taskbar to minimize it, like other windows, and this might have nothing to do with the program itself

>-Advanced device information without the TIGCC bugs
What in the world does TIGCC have to do with TI-Connect? TIGCC is a compiler, not link software.

I know. TIGCC's FL_getHardwareParmBlock returns a list that doesn't make any sense on TI-89Ti (hardware version 9, etc.).

Try AB_getGateArrayVersion()

Yes, but it doesn't return HARDWARE_PARM_BLOCK, which is what I was trying to get.

Well, you've got the right idea, but you're completely wrong. TIGCC does return the correct values.
The hardware ID is 9 on the Titanium, the hardware revision is 2, and the other interesting change is that the Gate Array is now 3.

On the TI-89Ti, the gate array *is* 9 according to FL_getHardwareParmBlock.

lol, well that is most definately incorrect. Get command post plus (note that the crash protection doesn't work on the titanium because the titanium is wierd...), and press F4: 5 ...

either your test program is broken, or TIGCC has a real problem. Are you using the latest beta of TIGCC? (the latest beta is the only version that actually supports the Titanium)

I have Command Post Plus, and I'll try that in a few days.

I am using 0.94 beta 19, which is not the latest version and I should upgrade. Thanks.

WOW. That's all I have to say seeing as how it's on v0.95 Beta 16.

So that adds up to I'd estimate about 20 MB (the OS updates being the biggest part).

Without the OS updates, it'd have to be only a couple MB or less (it doesn't take many megs of space to do all that).

Effective error handling on even a small program is compilcated. Just look at AutoClBr.

Effective error handling doesn't take many megabytes of disk space. I looked at the source of AutoClBr, and it doesn't have any "complicated" error handling out of the ordinary. It has just basic error checking and handling; without ANY error checking the program would be about 10-15% smaller (that includes all the error reporting too). It's really not that much. It might even be much less than that.

Look at Firefox as an example. It takes less than 20 MB of disk space, fully installed, and it does MUCH more than a calculator linking program does. There's really no excuse for using so much space for how little the program has to do.

I didn't say it had complicated error handling. I said it had effective error handling.

The more complicated the program (as measured by the number of defined function calls and nested loops), the more complicated the error handling because you have to trap errors, not redirect correct statements, and handle errors properly. The more interrelated things that a program does, the bigger and more complicated it gets. If you look closely at what the program does, you'll see what I mean. It matters less the number of features than how the program works. Often, optimization comes at the cost of complex layout. Try it yourself.

My bad. I misquoted you slightly, but the conclusion is the same.

Most complicated error handling I deal with is to return error codes to different threads of execution. That's not writing multi-threaded programs but the multi-threader itself. It also involves saving the registers, being careful not to touch the stack while it's changing, and restoring the registers properly. The error handling is the simplest part.

A simple layout helps to optimise a program (global optimisations have a bigger payoff than local optimisations), because it shows what can be moved or removed more easily than a more complex layout.

Also, to keep a program from getting complicated from doing interrelated things, make the program data-centric (rather than code-centric) and have a clean and consistent interface for each function. A function should be a black box; you don't know how it works, but you know how to invoke it. If a function encounters an error, it just returns an error code, and depending on how "fatal" it is, the caller can pass it up to its caller, and so on until the error handler for that particular error can report it.

What I get from what you wrote, you use a language which uses "exceptions" (such as TI-68k BASIC or Java). Exception are "invisible GOTO"s, and GOTO's are considered harmful. In the case of exceptions, the code usually needs to know what caused the error (what "threw the exception"), and that can complicate a program's error handling. What you said may be true but mostly for languages which use exceptions to catch errors.

By the way, where in AutoClBr is the effective error handling which you say is complicated? All I see is pretty standard error handling. Point out the file(s) and line number(s) so I can look more closely at it.

>>Most complicated error handling I deal with is to return error codes to different threads of execution.

Yes, that's what I was referring to. in a major program, that is a major problem and perhaps is why it's so large. I know there's TI programmers out there laughing at us...

>>By the way, where in AutoClBr is the effective error handling which you say is complicated?

AutoClBr is relatively simple in objectives. It uses only the standard error handling that you mentioned. I did not mean to mislead you to believe that AutoClBr's error handling was complicated, however, if you had to apply that to a complex program with interrelated objectives like TI Connect, it would balloon.

Does it matter? The program is released, and it looks good. If you're so sure it could be written more efficiently and smaller, than try to do it yourself. Then you'll see making a program smaller is really a lot of work, especially when it is complicated. Plus, writing the program in the first place must have taken a lot of work.

It would've been quite a bit of work to make the program that big in the first place, unless it has a lot of fluff like videos.

Compare it to similar programs like TiLP; even if they don't have exactly the same features as TI-Connect, they still are similar enough for a reasonable size comparison.

I would even say that it does matter. Think of all those people who still use dial-up. They'd be able to download it in ten minutes if it weren't bloated like it is.

Please know something about the program and try it yourself before badmouthing it. The TI programmers did a very good job and I don't think that it serves the community to prejudge their work.

-Only one bug: you can't click on the TI Connect tab in the taskbar to minimize it, like other windows, and this might have nothing to do with the program itself
i havent tried the new version, but in the beta it was because it was a simulated window made in flash.

This so is not great. Whenever I try to run it, my monitor display messes up.

How much was it before?

My 'TI Education folder is 59.8, so this would actually be an improvement.

Well maybe you have alot of backups and stuff like that bcuz mine is 23.8 Mb. And I have two calulator drivers 83+ and 83+ silver edition (I dont know if that makes a difference) By the way I just checked for updates on ti-connect and there are no updates. I have version 1.5.3 is that the newest. Ive had it for about a month. So if thats the case then srry ticalc.org but you guys are behind.

I use TI Connect 1.5 Beta and I have no backups in 'TI Education.'