PBCC Shock and Outrage 
Author Message
 PBCC Shock and Outrage

Well, I'm starting to work in PBCC now, and I'm shocked and outraged
that the authors have chosen to delete PRINT USING. Have they lost
their minds? PRINT USING is one of the best reasons for programming in
BASIC. How the hell are we supposed to format reports now... use a
mixture of string functions and FORMAT$ ? As long as they had the
formidable PRINT USING code in PB3.2, and the CC compiler is,
apparently, still 16-bit x86 assembly, why did they throw it away?

I can live without INPUT, but this is crazy. I may as well learn C and
use printf now.

Have they lost their minds? (am I repeating myself?)

John

-----------------

"If anybody ever marries you, it will be for the pleasure
 of hearing you talk piffle," said Harriet, severely.



Thu, 13 Jun 2002 03:00:00 GMT  
 PBCC Shock and Outrage
On Sun, 26 Dec 1999 16:34:06 -0800, John Larkin

Quote:

>Well, I'm starting to work in PBCC now, and I'm shocked and outraged
>that the authors have chosen to delete PRINT USING. Have they lost
>their minds? PRINT USING is one of the best reasons for programming in
>BASIC. How the hell are we supposed to format reports now... use a
>mixture of string functions and FORMAT$ ? As long as they had the
>formidable PRINT USING code in PB3.2, and the CC compiler is,
>apparently, still 16-bit x86 assembly, why did they throw it away?

>I can live without INPUT, but this is crazy. I may as well learn C and
>use printf now.

>Have they lost their minds? (am I repeating myself?)

You're also panicing unnecessarily. Take a look at FORMAT$().


Anything here that looks like an opinion is mine and not the company which vastly underpays me.



Fri, 14 Jun 2002 03:00:00 GMT  
 PBCC Shock and Outrage


Quote:
>On Sun, 26 Dec 1999 16:34:06 -0800, John Larkin

>>Well, I'm starting to work in PBCC now, and I'm shocked and outraged
>>that the authors have chosen to delete PRINT USING. Have they lost
>>their minds? PRINT USING is one of the best reasons for programming in
>>BASIC. How the hell are we supposed to format reports now... use a
>>mixture of string functions and FORMAT$ ? As long as they had the
>>formidable PRINT USING code in PB3.2, and the CC compiler is,
>>apparently, still 16-bit x86 assembly, why did they throw it away?

>>I can live without INPUT, but this is crazy. I may as well learn C and
>>use printf now.

>>Have they lost their minds? (am I repeating myself?)

>You're also panicing unnecessarily. Take a look at FORMAT$().


>Anything here that looks like an opinion is mine and not the company which

vastly underpays me.

Gary,

I think my panic is entirely appropriate. FORMAT$ only does numerics, and only
one at a time. The cool thing about PRINT USING is that you can build a picture
of a formatted line all at once, and get just what you see.*

So instead of

U$ = "###   \    \  !  ####.##  \               \"

PRINT #3, USING U$; SEQNO; BCLASS$; VSTAT$;  PENALTY!; DUMBEXCUSE$

you would have to...to... no, I can't bear to think about it! YOU try it!

This is one small stumble for man, one great blunder for mankind.

John

* except for the dumb way it handles numeric oversizes. Even FOCAL did this
right.



Fri, 14 Jun 2002 03:00:00 GMT  
 PBCC Shock and Outrage

Quote:

>I think my panic is entirely appropriate. FORMAT$ only does numerics, and
only
>one at a time. The cool thing about PRINT USING is that you can build a
picture
>of a formatted line all at once, and get just what you see.*

>So instead of

>U$ = "###   \    \  !  ####.##  \               \"

>PRINT #3, USING U$; SEQNO; BCLASS$; VSTAT$;  PENALTY!; DUMBEXCUSE$

>you would have to...to... no, I can't bear to think about it! YOU try it!

1. Bob Zale giveth, and Bob Zale taketh away.

2. Look at this as a blessing in diguise: instead of those messy, cryptic
format strings and the need to count embedded spaces, here is a golden
opportunity to move into the 1990's (OK, so it's just in time for the '90s
to leave) using UDTs to align your output lines.

3. If you were *really* ambitious, you could write a function to parse the
format strings in your (PB/DOS) programs and convert them to UDT's. Then the
parser could write the BASIC code to move the FORMAT$ equivalents of the
multiple-variable PRINT USING statements to the appropriate UDT member.

4. Sticking with the "precompiler" theory, yet eschewing the move to UDT's,
why not just parse out the format strings and write BASIC code to PRINT#
whatever, FORMAT$( parsedformat, dataname) & ";"   for these statements? (In
the new source file, keep the replaced line, but commented out so you can
tinker more easily).

If you have lots of this kind code to migrate, writing your own source code
converter may be a really good use of your migration time budget. (Unless
you have a real junior programmer type to whom you can assign the exciting
and challenging opportunity of finding each PRINT USING and changing it).

MCM



Fri, 14 Jun 2002 03:00:00 GMT  
 PBCC Shock and Outrage


Quote:
> Well, I'm starting to work in PBCC now, and I'm shocked and outraged
> that the authors have chosen to delete PRINT USING. Have they lost
> their minds? PRINT USING is one of the best reasons for programming in
> BASIC. How the hell are we supposed to format reports now... use a
> mixture of string functions and FORMAT$ ? As long as they had the
> formidable PRINT USING code in PB3.2, and the CC compiler is,
> apparently, still 16-bit x86 assembly, why did they throw it away?

Don't you hate it when people don't bother to read the documentation?

If you look up "USING" in the help file, you'll be taken to FORMAT$.

The syntax was changed, but the functionality remains the same.

--Dave



Fri, 14 Jun 2002 03:00:00 GMT  
 PBCC Shock and Outrage


Quote:


>> Well, I'm starting to work in PBCC now, and I'm shocked and outraged
>> that the authors have chosen to delete PRINT USING. Have they lost
>> their minds? PRINT USING is one of the best reasons for programming in
>> BASIC. How the hell are we supposed to format reports now... use a
>> mixture of string functions and FORMAT$ ? As long as they had the
>> formidable PRINT USING code in PB3.2, and the CC compiler is,
>> apparently, still 16-bit x86 assembly, why did they throw it away?

>Don't you hate it when people don't bother to read the documentation?

>If you look up "USING" in the help file, you'll be taken to FORMAT$.

>.

>--Dave

Dave,

this is pasted directly from the PBCC help section that relates to converting
from DOS:

==============================

USING/USING$

PRINT USING and LPRINT USING are not supported.  See FORMAT$.  FORMAT$ does not
support strings, only numeric values.

USING$ is not supported.  To mimic USING$ you can use the following code:

FUNCTION USING$(BYVAL mask$, BYVAL value##)
  FUNCTION = FORMAT$(value##, mask$)
END FUNCTION

==============================

This helpful code example is, well, absurd. Sorry.

Hey, I'm actually a nice person. And I read the $29 PBCC manual from cover to
cover before I  started programming. I thought that my original post made it
clear that I know about FORMAT$, and consider it to be a very poor substitute
for PRING USING.

I don't understand how  "The syntax was changed, but the functionality remains
the same" .  FORMAT$ handles only numerics, and only one at a time. So to
format a line of mixed types, I've now got to hack many lines of code, with
mixed FORMAT$ and string functions, and I've got to pull out my old fortran
coding sheets and start counting spaces, just like in the bad old days.

PRINT USING lets me draw a picture of what I want in a single statement.

(So why *was* PRINT USING removed? Hit the 640K limit?)

When a company gets around to feeling that its customers are stupid
irritations, the problem generally fixes itself pretty quick.

John



Fri, 14 Jun 2002 03:00:00 GMT  
 PBCC Shock and Outrage


Quote:

>1. Bob Zale giveth, and Bob Zale taketh away.

Amen.

Quote:
>2. Look at this as a blessing in diguise: instead of those messy, cryptic
>format strings and the need to count embedded spaces, here is a golden
>opportunity to move into the 1990's (OK, so it's just in time for the '90s
>to leave) using UDTs to align your output lines.

Hey, they weren't cryptic... they looked almost like the actual output.

And please, what's a UDT? Will it hurt?

Quote:

>3. If you were *really* ambitious, you could write a function to parse the
>format strings in your (PB/DOS) programs and convert them to UDT's. Then the
>parser could write the BASIC code to move the FORMAT$ equivalents of the
>multiple-variable PRINT USING statements to the appropriate UDT member.

If I were *really* ambitious, I would learn Java, or become a lawyer. I thought
compilers existed to make lazy people productive.

Quote:

>4. Sticking with the "precompiler" theory, yet eschewing the move to UDT's,
>why not just parse out the format strings and write BASIC code to PRINT#
>whatever, FORMAT$( parsedformat, dataname) & ";"   for these statements? (In
>the new source file, keep the replaced line, but commented out so you can
>tinker more easily).

I thought of writing my own equivalent of PRINT USING (until, fortunately, that
particular burst of ambition faded) but there's no decent way to pass mixed
numeric/string argument types... is there?

Quote:

>If you have lots of this kind code to migrate, writing your own source code
>converter may be a really good use of your migration time budget. (Unless
>you have a real junior programmer type to whom you can assign the exciting
>and challenging opportunity of finding each PRINT USING and changing it).

Migration time? Do I look like a pelican? (don't answer that, please)

John

(who is apparently being pummeled by people who never have to print strings)



Fri, 14 Jun 2002 03:00:00 GMT  
 PBCC Shock and Outrage
Quote:

>On Mon, 27 Dec 1999 19:39:37 GMT, "Michael Mattias"


Quote:

>And please, what's a UDT? Will it hurt?

User defined type.
UsingPrintUsing:
U$ = "&  #######-  #####.##  ######.##-"
PRINT USING U$;PartNo$;Qty!;Price!;Extension!

UsingUDTs:
TYPE OutputLine
  PartNo    AS STRING * 12
  Fill0        AS STRING *2
  Quantity  AS STRING * 8
  Fill1        AS STRING * 2
  Price       AS STRING * 9
  Fill2         AS STRING * 2
  Extension AS STRING * 10
END TYPE
...
DIM OL AS OuputLine
LSET OL = SPACE$(LEN(OL))
OL.PartNo = PartNo$
RSET OL.Quantity = FORMAT$(Qty!, "#######-")
RSET OL.Price     = FORMAT$(Price!, "#####.##")
RSET OL.Extension = FORMAT$(Extension!,"######.##-")
PRINT #1, OL

Quote:

>I thought of writing my own equivalent of PRINT USING (until, fortunately,
that
>particular burst of ambition faded) but there's no decent way to pass mixed
>numeric/string argument types... is there?

See above. I was thinking of something which takes your own "raw" source
code and converts instances of PRINT USING into UDT-based code, not a PRINT
USING.

However, using optional parameters for all variables after the first to be
printed, no reason you couldn't create something like..

  FUNCTION PrintUsing (FormatString AS STRING, Varcount AS INTEGER, Arg1 AS
SINGLE, [Arg2, Arg3, Arg4 ])

You'd probably have to pass the Args not as singles or doubles or strings,
but as addresses (DWORDs) and use pointers to match the second and
subsequent arguments to the type of format string specified.....

Or, maybe - better - you could pass a 'vartype string' to help, as in:

X% = PrintUsing (U$, "!$&%", BYVAL VARPTR(Arg1), (Optional BYVAL VARPTR of
each additional argument))
This might mean there are four variables coming in: a single!, a string$, a
Long& and an Integer%

so in your case:
X% = PrintUsing (U$, "$!!!", BYVAL VARPTR(PartNo$), BYVAL VARPTR(Qty!),
BYVAL VARPTR(Price!), BYVAL VARPTR(Extension!))

( Yeah, I could do this; so can you)

MCM



Sat, 15 Jun 2002 03:00:00 GMT  
 PBCC Shock and Outrage
On Mon, 27 Dec 1999 10:32:32 -0800, John Larkin

Quote:

>So instead of

>U$ = "###   \    \  !  ####.##  \               \"

>PRINT #3, USING U$; SEQNO; BCLASS$; VSTAT$;  PENALTY!; DUMBEXCUSE$

>you would have to...to... no, I can't bear to think about it! YOU try it!

>This is one small stumble for man, one great blunder for mankind.

My personal preference is to format variables one at a time. The code
stays more readable IMO. I'm not saying that you're wrong, just that
that's not the way I do it. FORMAT$() has not been a problem for me.


Anything here that looks like an opinion is mine and not the company which vastly underpays me.



Sat, 15 Jun 2002 03:00:00 GMT  
 PBCC Shock and Outrage


Quote:

>>On Mon, 27 Dec 1999 19:39:37 GMT, "Michael Mattias"


>>And please, what's a UDT? Will it hurt?

>User defined type.
>UsingPrintUsing:
>U$ = "&  #######-  #####.##  ######.##-"
>PRINT USING U$;PartNo$;Qty!;Price!;Extension!

>UsingUDTs:
>TYPE OutputLine
>  PartNo    AS STRING * 12
>  Fill0        AS STRING *2
>  Quantity  AS STRING * 8
>  Fill1        AS STRING * 2
>  Price       AS STRING * 9
>  Fill2         AS STRING * 2
>  Extension AS STRING * 10
>END TYPE
>...
>DIM OL AS OuputLine
>LSET OL = SPACE$(LEN(OL))
>OL.PartNo = PartNo$
>RSET OL.Quantity = FORMAT$(Qty!, "#######-")
>RSET OL.Price     = FORMAT$(Price!, "#####.##")
>RSET OL.Extension = FORMAT$(Extension!,"######.##-")
>PRINT #1, OL

So, we conclude: yes, it hurts a good deal. Two rather nice, perfectly obvious
lines of code have become 16 lines of tangle. Progress!

- Show quoted text -

Quote:
>>I thought of writing my own equivalent of PRINT USING (until, fortunately,
>that
>>particular burst of ambition faded) but there's no decent way to pass mixed
>>numeric/string argument types... is there?

>See above. I was thinking of something which takes your own "raw" source
>code and converts instances of PRINT USING into UDT-based code, not a PRINT
>USING.

>However, using optional parameters for all variables after the first to be
>printed, no reason you couldn't create something like..

>  FUNCTION PrintUsing (FormatString AS STRING, Varcount AS INTEGER, Arg1 AS
>SINGLE, [Arg2, Arg3, Arg4 ])

>You'd probably have to pass the Args not as singles or doubles or strings,
>but as addresses (DWORDs) and use pointers to match the second and
>subsequent arguments to the type of format string specified.....

>Or, maybe - better - you could pass a 'vartype string' to help, as in:

>X% = PrintUsing (U$, "!$&%", BYVAL VARPTR(Arg1), (Optional BYVAL VARPTR of
>each additional argument))
>This might mean there are four variables coming in: a single!, a string$, a
>Long& and an Integer%

>so in your case:
>X% = PrintUsing (U$, "$!!!", BYVAL VARPTR(PartNo$), BYVAL VARPTR(Qty!),
>BYVAL VARPTR(Price!), BYVAL VARPTR(Extension!))

>( Yeah, I could do this; so can you)

I thought the reason we sent money to Mr Zale is so that his compiler would do
the {*filter*} stuff for us. Instead, it now purchases us a license to do it
ourselves.

John



Sat, 15 Jun 2002 03:00:00 GMT  
 PBCC Shock and Outrage


Quote:
> I thought the reason we sent money to Mr Zale is so that his compiler would do
> the {*filter*} stuff for us. Instead, it now purchases us a license to do it
> ourselves.

John,

If you are within 30 days, you can always return it for a refund.  We've
got thousands and thousands of very satisfied customers.  If you're not
one of them, we're happy to refund your money so that you can find
something else.

--Dave



Sat, 15 Jun 2002 03:00:00 GMT  
 PBCC Shock and Outrage


Quote:


>> I thought the reason we sent money to Mr Zale is so that his compiler would
do
>> the {*filter*} stuff for us. Instead, it now purchases us a license to do it
>> ourselves.

>John,

>If you are within 30 days, you can always return it for a refund.  We've
>got thousands and thousands of very satisfied customers.  If you're not
>one of them, we're happy to refund your money so that you can find
>something else.

>--Dave

Dave,

With what an engineer's time is worth these days, the money just doesn't
matter. I'd gladly pay five times as much as the current price for PB or PBCC.
What matters to me is productivity. I was hoping to migrate all my apps to PBCC
(and buy a few more copies of it: I never cheat on the license for PB
products), but it looks like some things are still easier in PB3.2 than PBCC,
and direct program migration is out of the question in lots of cases... see
Michael's horrible (no offense, Michael!) examples above.

So, why *was* PRINT USING removed?

John



Sat, 15 Jun 2002 03:00:00 GMT  
 PBCC Shock and Outrage


Quote:
> With what an engineer's time is worth these days, the money just doesn't
> matter. I'd gladly pay five times as much as the current price for PB or PBCC.
> What matters to me is productivity. I was hoping to migrate all my apps to PBCC
> (and buy a few more copies of it: I never cheat on the license for PB
> products), but it looks like some things are still easier in PB3.2 than PBCC,
> and direct program migration is out of the question in lots of cases... see
> Michael's horrible (no offense, Michael!) examples above.

> So, why *was* PRINT USING removed?

I honestly don't know why PRINT USING in particular was removed.  I do
know that many things were removed or modified because of differences in
the operating systems.

What a lot of people seem to keep forgetting is that DOS and Windows are
two seperate operating systems.  Some things simply don't work in
Windows, while others require LOTs of work to make compatible with
Windows.

I personally found the missing USING and USING$ to be a pain in
converting a number of my programs.  But not enough to go around telling
everyone that PB/CC was total garbage just because one or two things were
missing or different.

After using PB/CC for a couple of years now, I have learned to live
without it and I can honestly say that *today*, I personally don't miss
it.  Does that mean I wouldn't welcome its return?  No, I'd love to have
it back.  But I'm not gonna lose any sleep over not having it.

--Dave



Sat, 15 Jun 2002 03:00:00 GMT  
 PBCC Shock and Outrage
Gosh, Dave

I didn't say that any PB products were garbage. In fact, I love PB/DOS
( and have written at least 100 programs in it) and I'm just starting
to get familiar with PBCC. I just finished a ROM builder program that
combines a Motorola S28 hex file with multiple Xilinx FPGA config
files, using a monstrous rom-image array; it runs *really* fast, but
the lack of Print Using makes the log file 1) hard to code or 2) ugly.

Print Using was my complaint. It was one of my favorite things about
PB, and I miss it. I can't understand why it disappeared.

John

-----------------

"If anybody ever marries you, it will be for the pleasure
 of hearing you talk piffle," said Harriet, severely.



Sat, 15 Jun 2002 03:00:00 GMT  
 PBCC Shock and Outrage
On Wed, 29 Dec 1999 02:03:03 GMT, "Michael Mattias"

|>On Tue, 28 Dec 1999 12:15:09 GMT, "Michael Mattias"


|>
|>
|>So, we conclude: yes, it hurts a good deal. Two rather nice, perfectly
|obvious
|>lines of code have become 16 lines of tangle. Progress!
|>
|
|
|Thou misunderstandeth.
|
|I was suggesting writing a PROGRAM to parse the existing source code and
|create the 16 lines in a new source file.
|
|What, no sense of adventure?
|
|BTW, I kind of like the idea about PrintUsing% with the optional parameters.
|I may give that a shot just for the fun of it.
|
|MCM
|
|
|

Michael,

well, that sort of thing *is* an adventure if you have time on your
hands, not much else to do, and somebody regularly pays your salary
without much in the way of direct supervision. But for those of us who
employ ourselves, poverty is another kind of adventure.

Hey, how about

U0 "  #####  ####.##  \      \    etc, you know...   "

then...

UI varib1% :  UF floater2! :  US string3$... etc

where Ux are function calls, and U0 just initializes things, and the
other U-functions feed stuff into the print routines. This at least
simplifies the mixed-arg problem without a lot of pointer stuff.

Better? But still ugly and way too much trouble. Gotta handle device
selection, too. Somebody stop me! I have WORK to do!

John

-----------------

"If anybody ever marries you, it will be for the pleasure
 of hearing you talk piffle," said Harriet, severely.



Sat, 15 Jun 2002 03:00:00 GMT  
 
 [ 27 post ]  Go to page: [1] [2]

 Relevant Pages 

1. EiffelStudio 5 outrage

2. Shock Response Spectrum for LV?

3. Only 20K expressions, I'm shocked!

4. 1d shock tube stuff

5. Perl Documentation SHOCK!

6. MS 5.1 shock? The old ways still work

7. How to start app minimized or hidden in PBCC 3.0

8. Windows API calls and pbcc

9. how can I make functions in PBCC ?

10. PBCC - DATA OVERLAYS

11. PBCC graphics

12. PBCC question

 

 
Powered by phpBB® Forum Software