[futurebasic] Re: [FB] FBII->3 Source Conversions Success!

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : September 1999 : Group Archive : Group : All Groups

From: Chris Stasny <staz@...>
Date: Mon, 20 Sep 1999 11:25:01 -0500
>    FBII App                  FB3 App
>Size : 203,652            Size : 330,552
>
>The FB3 compiled app runs....slower. But only during the display
>portion of the program. Ie. drawing a bunch of data text lines to a
>window. FBII is significantly faster. Perhaps the inline asm code
>slows it down slightly (anyone got a native PPC TRUNCSTRING laying
>around?).
>
>So how do I cut 126,900K from the finished FB3 application?

I doubt that you can cut it. FBII's runtime was a hand tooled, inaccessible
CODE 5 resource. FB^3 is in source code. If you find FBII to be faster,
then you still have some work to do on the conversion. I can tell from your
comments that you did not turn on the "no redimmed vars" pref our you would
have gotten errors on the record thing. You should also work towards
putting info in registers instead of memory variables (2-3 times faster).

Given the 4 meg minimum runtimes of our competitors, I'm not really upset
about program size. You can look at the mini-app example on the disk to see
how to generate a small program. It's only 39K. And keep in mind that you
now have the power to bypass the FB runtime. This was something that could
not be done in FBII.

>
>FB3 took it on itself to change the "suggested memory size" to a
>number I didn't put in my size resource. Matter of fact I don't know
>where it found the number but its almost twice the suggested size
>FBII used. So why put a size in a resource if the compiler is going
>to make its own suggestions? Odd bird this one.

FB^3 automatically grows the heap to handle dimensioned arrays. It also
grows the heap if you use a DIM SYSTEM statement. I think it's a good
thing. Saves a lot of crashes when folks don't allow for large arrays.

>
>I know there's a lot of beta users here, so how do you get the
>references to your functions like the old project manager did? i.e.
>click on a function name and the next reference to it pops up in the
>editor window.
>

We haven't done that yet.

>Do you actually "need" all that extra function stuff in the FBIIrntm
>header file?

Yes. That's how it's always worked. It just used to be in a pre-compiled
resource.

>Or do you just need the library references?

If you want, you can build your own runtime with nothing but toolbox calls
and no interference whatsoever from FB.

>Whats the difference between the lite, regular or fat free run time?

Why don't you make a simple PRINT "Hello" file and see?


>Is there a list of what ToolBox commands the compiler supports (help
>only has a few)?

Yes. It's in the header files. They are called TOOLBOX, and TBALIAS

>How come in a compiled PPC app only, the main part of the code
>doesn't end up in the datafork as other compiled languages do? And
>does anyone see this as a problem?

We translate into a resource called an FCOD. Only the startup code has to
be in the data fork.

>If the compiler is going to write in its own resources, can we get a
>list of them so we don't try and create the same ones?

Look at the runtimes. (Path: FBExtensions/Compiler/Runitmes) That's what FB
starts with.

>Is there a way to get rid of that blue background in the editor
>window but keep the styled text?

Yes. Change the background color in the prefs.

>How come window names can't be longer than about 6 or 7 characters?
>Mine all get chopped off. And it changed something in my OS since ALL
>my windows won't go beyond 6 or 7 characters now. I hope restarting
>will fix it.
>

I have not seen this. We do not use custom window defs.



Best,

-STAZ  ~)~

800.348.2623 Orders  http://www.stazsoftware.com
228.255.7086 FAX     mailto:staz@...