[futurebasic] Re: [FB] Re: New FOR behavior

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : March 2008 : Group Archive : Group : All Groups

From: Rich Love <richlove@...>
Date: Sun, 30 Mar 2008 09:31:45 -0500
Ken,

Thanks, I needed a humor break this morning :-)

Yes, I know that keeping customers happy is worth the extra work.
That is why I have spent the last 7 months converting MacWise to a  
universal app.
I am still in the process of working out all the bugs that were  
created during the conversion.
I am hoping to be able to return to a mode where I can concentrate on  
making general improvements and adding new desired features instead of  
worrying about fixing newly broken code due to rule changes.

How about this option in our FB code?

#if def _OldOutdatedCrappyIncorrectFBCodeSupported
LetUsHaveOurOldOutdatedCrappyIncorrectFBCode = 1
#endif



Rich


On Mar 30, 2008, at 8:29 AM, Ken Shmidheiser wrote:

> *** Re: New FOR behavior
>
> HHhhhhmmmmmm, let's see:
>
> FBtoC already gives us:
>
> 1. Straight path to FSRefs since FSSpecs are broken with long file  
> names.
>
>  OH NO! It's going to break all my old code that uses FSSpecs and I  
> have thousands of them!
>
>
> 2. A new syntax that allows us to add directly to a bundle resources  
> of theorectically unlimited size and available to all the current  
> CFBundle Toolbox, thus  bypassing Classic Resources-- and their  
> cumbersome limitations: limitations on size, destruction of  
> application when moving cross platform, locking and unlocking memory  
> when they're moved, opening and disposing them without crashing,  
> adding and subtracting them without crashing or disrupting the order  
> of, say, the stringlists, etc.
>
>  OH NO! It's going to break all my old code that uses resources and  
> I have thousands of them!
>
>
> 3. Ability to compile directly with either a C or ObjectiveC  
> compiler into fully Carbon-compatible code.
>
> OH NO! It's going to break all my old code that uses Program  
> Generator and I have thousands of lines of PG code! I also have  
> thousands of customers all running Leopard on quad-core Intel  
> machines to support with my 1992 codebase!
>
>
> local fn IsMyCustomerWorthIt( numCustomers as long, linesOfCode as  
> long, howManyLinesIsMyCustomerWorth as double ) as Boolean
> '~'1
> dim as Double linesOfCodePerCustomerToTranslate
> dim as Boolean worthIt
>
> linesOfCodePerCustomerToTranslate = linesOfCode \ numCustomers
>
> long if ( linesOfCodePerCustomerToTranslate >  
> howManyLinesIsMyCustomerWorth )
> worthIt = _true
> xelse
> worthIt = _false
> end if
>
> end fn = worthIt
>
> dim as Long    customers, codeLines
> dim as Double  linesPerCustomer
> dim as Str255  s
> dim as Boolean worthIt
>
> window 1
>
> customers = 2059
> codeLines = 30417
> linesPerCustomer = 12.0
>
> long if ( fn IsMyCustomerWorthIt( customers, codeLines,  
> linesPerCustomer ) )
> s  = "Heck yes my customer is worth translating"
> s += Str$( linesPerCustomer )
> s += " lines of code for."
> print s
> xelse
> s  = "No way is my customer worth translating"
> s += Str$( linesPerCustomer )
> s += " lines of code for. Don't need them anyway."
> print s
> end if
>
> do
> handleevents
> until gFBQuit
> end
>
> 4. Ability to generate fast, stable Universal Binaries.
>
> OH NO! It's going to break all my old code that generates flat CFM  
> executables because I don't understand how to create a plist or use  
> a bundle.
>
>
> 5. Ability to localize in foreign languages.
>
>  OH NO! I don't know any foreign languages. Anyway, who cares. If  
> they don't speak English, they don't need my program.
>
>
>
> And Robert Purves has already outlined benefits of doing 'for' loops  
> like everyone else in the world:
>
> [1] No more tiresome workarounds.
>
> [2] Standard C 'for' loops are easier (for humans) to read than 'do   
> {...} while' in the translated code.
>
>  [QUESTION: How many of you have attemped to translate Apple's  
> sample source code and had to replace each 'for' loop with an FB 'do/ 
> while' loops to get things to work? Speaking from long experience,  
> it's not fun.]
>
> [3] OpenMP is coming to OS X soon (available in beta now). It is an   
> extension to C that allows parallel threaded computation, as on   
> supercomputers. OpenMP requires standard C 'for' loops, which it  
> can  speed up by a factor equal to the number of processor cores.  
> Every FB  programmer will want his FBtoC-built apps to be OpenMP- 
> savvy, making  use of the previously comatose 7 cores of a Mac Pro.
>
> And there are questions about what direction we should take?!?!
>
> Wow.
>
> Ken
>
> --
> To unsubscribe, send ANY message to: futurebasic-unsubscribe@...
>