Further demo of P6 ppm file creation

[Chris Iverson]

I see both sides here; I do actually agree that it's ambiguous syntax, but the way LB currently resolves it is a bit more intuitive, to me.

<first command> : <second command> seems straightforward enough to me, but as I said in my previous post, IF is also a command.

IF <condition> THEN <command> : <second command> is ambiguous, because the separator could apply to either the IF statement itself(which is the first statement on the line), OR the command executed by the IF statement, in which case it's considered as part of the IF statement's commands.

Personally, it makes sense to me that the : is attached to the closest statement to it, which is the result of the IF statement, not the IF statement itself.

That said, I almost never use the : anyway, and I especially would never use it in conjunction with an IF statement. Personally, I just don't like the way the code reads like that. If you have multiple commands to conditionally execute, just make it an IF block. It reads much easier and neater that way.

[Carl Gundel]

Nov 20, 2020 21:02:49 GMT -5 Chris Iverson said:

I see both sides here; I do actually agree that it's ambiguous syntax, but the way LB currently resolves it is a bit more intuitive, to me.

<first command> : <second command> seems straightforward enough to me, but as I said in my previous post, IF is also a command.

IF <condition> THEN <command> : <second command> is ambiguous, because the separator could apply to either the IF statement itself(which is the first statement on the line), OR the command executed by the IF statement, in which case it's considered as part of the IF statement's commands.

Personally, it makes sense to me that the : is attached to the closest statement to it, which is the result of the IF statement, not the IF statement itself.

That said, I almost never use the : anyway, and I especially would never use it in conjunction with an IF statement. Personally, I just don't like the way the code reads like that. If you have multiple commands to conditionally execute, just make it an IF block. It reads much easier and neater that way.

I have never seen another BASIC that does it differently.  There may be a few examples, but I think they would be considered unorthodox by the overwhelming majority of BASIC programmers.

[grimblefritz]

Irrational, in that in BASIC (at least, in all that I've encountered other than LB) the ":" is used to create multiple commands on a single line. As such:

if a=2 print "two" : print "hello"

Should always output "hello". What happens in the first statement should not impact the second. (OMG, can you imagine the vast number of old BASIC of one-liners that would have never been possible otherwise!)

Instead, LB treats ":" as if it were the equivalent of:


if a=2 then print "two" && print "hello"

'or, put another way
'(since the above && in most languages would apply to the print and not the if)

if a=2 then
   print "two"
   print "hello"
end if


It's just odd. And as with all languages, a lot of the challenges are just getting used to the oddities. And, having just dived back into other people's LB code, this one is an oddity that I see some others have adapted to, leveraging the conditional aspect, while others treat it like the traditional multiple command separator and ignore or don't realize the conditional aspect. That duality caused a few head scratches for me (and others) at first, but now (when looking at LB code) my brain is rewired to not interpret : as multiple commands but as an odd conditional.

And where I have the option, I refactor the code into something less ambiguous. Over the decades I've learned that compact code that is full of syntactic sugar is really tasty... until years later when you have to maintain it after having not been day-to-day with it for most of those years. Give me verbosity and clarity any day!

Anyway, as it is, the LB : is something more akin to a partial implementation of the common ternary operator (condition ? iftrue : iffalse) - except it is backwards sort of (if condition then statement : iftrue) and there's no iffalse. It's not really BASIC-like.

But, it's a minor thing once you're used to it. I certainly wouldn't want you to change it! I'd rather see things like b()=a() array assignment or passing entire arrays as arguments (especially byref) or dynamic parameter lists.

Or LB5.

I'll gladly take a wonky : (that I ignore anyway) in exchange lol

[Carl Gundel]

Nov 21, 2020 10:45:51 GMT -5 grimblefritz said:

Irrational, in that in BASIC (at least, in all that I've encountered other than LB) the ":" is used to create multiple commands on a single line. As such:

if a=2 print "two" : print "hello"

Should always output "hello". What happens in the first statement should not impact the second. (OMG, can you imagine the vast number of old BASIC of one-liners that would have never been possible otherwise!)

Instead, LB treats ":" as if it were the equivalent of:


if a=2 then print "two" && print "hello"

'or, put another way
'(since the above && in most languages would apply to the print and not the if)

if a=2 then
   print "two"
   print "hello"
end if

Well, I'll take your word for it, and I'd be interested if you can give me a list of BASIC dialects that work differently. Without exception every version of BASIC I have ever used does it the same way as Liberty BASIC, and you are the very first person in thirty years to say anything like this, to me anyways.

EDIT: Perhaps this has something to do with the dominance of Microsoft dialects (and the many compatible dialects) of BASIC, which really is the de facto standard in my opinion.  These all use : to group statements after THEN to be executed together, in my experience.  I'm not sure how this way of doing things can be considered irrational when the most mainstream BASICs do it this way.

[Carl Gundel]

I've chased down the bug you pointed out to me where input$(#handle, len) was not working when called in a SUB.

The following now works in LB5 build 352.


   'write a file
   open "testlof.txt" for output as #fOut
       print #fOut, "this is a test of the"
       print #fOut, "emergency broadcast system."
   close #fOut

   'read it back in
   open "testlof.txt" for input as #fIn
       text$ = input$( #fIn, lof(#fIn))
       print text$
   close #fIn

   call readFileInASub "test"
   print "Done!"
   wait

   sub readFileInASub n$
       open "testlof.txt" for input as #fIn
           text$ = input$( #fIn, lof(#fIn))
           print text$
       close #fIn
   end sub

[tenochtitlanuk]

This is code to produce a 24 bit BMP programmatically at your choice of size. I'll add the line drawing/circles/fill/etc soon- they all write to the bmp-file as an array in memory, so it just needs dumping to file after any operations you do. Here I use a calculated fill as an excuse to put up a colourful output!

Impressively fast in LB- once I realised the first version was taking ridiculously long. I was assembling the string of triad pixels as a data$ to send to file in one go. Too much claiming and releasing memory really hung things up. Memo to self- send calculated bytes to file as they are calculated!

It also pointed out that LB5 regards 'data' as a reserved word, unlike LB4. And is a bit picky on whether you use '#file,' or just '#file' or 'print #file' to send data to a file.
.



nomainwin                                       '   NB data is stored 'little-endian', ie lsb first, as unsigned integers of 16 or 32 bits

open "test6.bmp" for output as #bmp

filetype$   ="BM"
reserved$   =FourByteString$(  0)
offset$     =FourByteString$( 54)
bmpheader$  =FourByteString$( 40)
width       = 512
height      = 512
width$      =FourByteString$( width)
height$     =FourByteString$( height)
last        =( width *3) mod 4                  '   find how many of the last 4 bytes are already used
pad         =4 -last                            '       and thus how many to add
filesize    =54 +( width +pad) *3 *height       '   ie header ( 54 bytes) +bitmapdata ( calculated).
filesize$   =FourByteString$( filesize)

#bmp filetype$ +filesize$ +reserved$ +offset$;                                             '   <<<<<<


planes$     =chr$(  1) +chr$( 0)
bits$       =chr$( 24) +chr$( 0)                '   data stored in triple-bytes, 8 bits per colour.
compression$=FourByteString$( 0)
ignore$     =FourByteString$( 0) +FourByteString$( 0) +FourByteString$( 0) +FourByteString$( 0)

bmpsize$    =FourByteString$( filesize)

o$ = bmpheader$ +width$ +height$ +planes$ +bits$ +compression$ +bmpsize$ +ignore$ +datt$  '   <<<<<<
#bmp o$;

for count =1 to height
   N       =int( count /height *255)
   bytes   =0

   for count2 =1 to width                      '   data is R B G pixels.
       O       =int( 255 *count2 /width)       '   colour order is BGR.
       #bmp chr$( O) +chr$( 255 -O) +chr$( N);                                            '   <<<<<<
       bytes   =bytes +3
   next count2

   '   however each row has to be represented by multiples of four bytes, so add as necessary.
   if ( bytes mod 4) <>0 then b =4 -( bytes mod 4)
   for k =1 to b
       #bmp chr$( 0);  '   could be any byte as padding....                               '   <<<<<<

       bytes   =bytes +1
   next k

next count

[tenochtitlanuk]

See diga.me.uk/inMemoryImageMethod2.html for examples of how to implement fast getpixel and set pixel. Much faster than reading/wring pixels to an image in a graphics window.

[swedmarton]

To make a ppm record from some other configuration utilizing Irfanview: From the File menu, go to the Batch transformation/Rename decision, pick the Output arrangement of PPM-Portable Pixelmap, on the Options button close to that, pick ASCII encoding. Pick anything that yield registry you need for your outcome records.

[tenochtitlanuk]

Of course any decent 'painting' type of program will convert between file types. In the Linux world the standard is GIMP. But for LB computer-generated art the slow stage is the on-screen drawing pixel by pixef- hence the point that it is much quicker to write directly to a ppm file and convert it separately afterwards.

[smithwalgons]

If the PPM magic identifier is "P6" then the image data is stored in byte docs format, one byte per colour component (r,g,b). Comments can only occur before the last field of the header and only one byte may appear after the last header field, normally a carriage return or line feed.

[newyorklimo234]

I'm happy to see the considerable subtle element here!. Deleted spam link