Home
JAQForum Ver 20.06
Log In or Join  
Active Topics
Local Time 21:41 17 May 2024 Privacy Policy
Jump to

Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.

Forum Index : Microcontroller and PC projects : CMM2 5.05.06 beta

     Page 3 of 12    
Author Message
vegipete

Guru

Joined: 29/01/2013
Location: Canada
Posts: 1085
Posted: 04:17pm 11 Sep 2020
Copy link to clipboard 
Print this post

Minor unexpected behaviour:
pixel 100,100)
doesn't generate an error, despite the extra ")"
Visit Vegipete's *Mite Library for cool programs.
 
mkopack73
Senior Member

Joined: 03/07/2020
Location: United States
Posts: 261
Posted: 09:04pm 11 Sep 2020
Copy link to clipboard 
Print this post

Ugh ok now with OPTION ANGLE and OPTION Y_AXIS this is going to once again cause problems for anyone trying to write reusable code/functions/libraries.  

How would one know which way they are set so as to do the proper thing??? There was a work around for OPTION MODE to find which way it was set, but how would one be able to check and determine which way these new options are set by the calling program?
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8604
Posted: 09:32pm 11 Sep 2020
Copy link to clipboard 
Print this post

  Quote  How would one know which way they are set so as to do the proper thing???


Same approach as thwill's. A simple function to test the setting
 
vegipete

Guru

Joined: 29/01/2013
Location: Canada
Posts: 1085
Posted: 09:36pm 11 Sep 2020
Copy link to clipboard 
Print this post

  mkopack73 said  How would one know which way they are set so as to do the proper thing???

page write 0
cls
pixel 0,0,rgb(white)
if peek(byte MM.INFO(PAGE ADDRESS 0)) then <y-down> else <y-up>


if sin(30) = 0.5 then <degree mode> else <radian mode>

(untested)
Visit Vegipete's *Mite Library for cool programs.
 
TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 5923
Posted: 09:46pm 11 Sep 2020
Copy link to clipboard 
Print this post

'option angle radians
option angle degrees

if sin(90) = 1 then print "Degrees" else print "Radians"


Peter,
If OPTION ANGLE DEGREES is set in a program, the option is not cleared when a new program is loaded.
This will cause problems!

It IS cleared with NEW, but should be reset to RADIANS at the start of any program, not just with NEW.

Jim

edit:
it is also cleared if your programs ends with END
Edited 2020-09-12 07:53 by TassyJim
VK7JH
MMedit   MMBasic Help
 
mkopack73
Senior Member

Joined: 03/07/2020
Location: United States
Posts: 261
Posted: 10:26pm 11 Sep 2020
Copy link to clipboard 
Print this post

  vegipete said  
  mkopack73 said  How would one know which way they are set so as to do the proper thing???

page write 0
cls
pixel 0,0,rgb(white)
if peek(byte MM.INFO(PAGE ADDRESS 0)) then <y-down> else <y-up>


if sin(30) = 0.5 then <degree mode> else <radian mode>

(untested)


Great, so now every reusable library I write I'm going to have to include all of these checker functions (because it's not like I can call an include inside of an include..).

There really needs to be a STANDARD consistent way to query the current setting of every option... I really wish you (matherp) would consider doing this. It's only going to get more and more of a headache as new options get added in... I know it's not sexy, and it doesn't seem like it's all that important, but as this community grows and tries to write more and more software it will make things a LOT easier in the long run for everyone.
 
TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 5923
Posted: 10:59pm 11 Sep 2020
Copy link to clipboard 
Print this post

OPTION ANGLE and OPTION Y_AXIS are specific to the education area and it would be reasonable to assume that they are not used for 'normal' use.

Students will learn (the hard way) that it is worth learning the standards.

Jim
VK7JH
MMedit   MMBasic Help
 
mkopack73
Senior Member

Joined: 03/07/2020
Location: United States
Posts: 261
Posted: 11:43pm 11 Sep 2020
Copy link to clipboard 
Print this post

  TassyJim said  OPTION ANGLE and OPTION Y_AXIS are specific to the education area and it would be reasonable to assume that they are not used for 'normal' use.

Students will learn (the hard way) that it is worth learning the standards.

Jim


See, I normally would agree with you Jim, but in general the CMM2 being built around BASIC means it's intended for newbies and newbies will naturally pick up bad habits or work in a way that makes sense to them... (really no different than your kids do...)  They start sharing code snippets and examples and then next thing you know we have a jumbled mess.

I'm not against adding these sorts of flexibilities (although I worry about it causing a headache later) but there should also be ways to know which way its set so you can write code that can handle whichever way those things are set properly.

99% of the time it won't matter, but for somebody like me who wants to make and produce reusable code libraries to help folks build bigger apps faster, I have no way of knowing in advance which way the users of my libraries will set things up (how they like to work) so I really need to be able to detect and adjust how I do things in my library code to be sure I don't break, or worse, expect them to change how THEY like to work to use my library (which means they might not use it at all...)

For example, I shouldn't write my library code in a way that requires them to use OPTION MODE 1, or break if they use OPTION MODE 0... If they set the OPTION Y_AXIS one way and I do drawing to the screen in my library expecting it the other way, wacky behavior happens... etc. If I can determine which way they have it set in advance of doing any work in my library, then I can do things in ways that will work regardless of how they set those OPTIONS.
Edited 2020-09-12 09:48 by mkopack73
 
vegipete

Guru

Joined: 29/01/2013
Location: Canada
Posts: 1085
Posted: 01:26am 12 Sep 2020
Copy link to clipboard 
Print this post

Not a bug, but font #5 appears to have 1 pixel vertical alignment issue. Lower case letters are one pixel lower than everything else.

cls
for i = 33 to 126
 text (i-33)*8, 200, chr$(i), "LT",5,1,rgb(white),-1
next i
? @(0,300)
end

Visit Vegipete's *Mite Library for cool programs.
 
TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 5923
Posted: 02:32am 12 Sep 2020
Copy link to clipboard 
Print this post

  vegipete said  Not a bug, but font #5 appears to have 1 pixel vertical alignment issue. Lower case letters are one pixel lower than everything else.

cls
for i = 33 to 126
 text (i-33)*8, 200, chr$(i), "LT",5,1,rgb(white),-1
next i
? @(0,300)
end


I will send Peter an updated font with the lowercase shifted up one pixel.

Jim
VK7JH
MMedit   MMBasic Help
 
vegipete

Guru

Joined: 29/01/2013
Location: Canada
Posts: 1085
Posted: 03:11am 12 Sep 2020
Copy link to clipboard 
Print this post

Look at the characters closely and decide what is best. I think the lower case letters are already 'at the top'. Compare the characters to the various bracket styles too. I would almost say the lower case letters could shrink one pixel down (bottom stays the same) and the upper case, digits, etc shift 1 pixel down. ()[]{}| stay as is.

I'm happy to work on it if you like...
Visit Vegipete's *Mite Library for cool programs.
 
TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 5923
Posted: 03:24am 12 Sep 2020
Copy link to clipboard 
Print this post

  vegipete said  Look at the characters closely and decide what is best. I think the lower case letters are already 'at the top'. Compare the characters to the various bracket styles too. I would almost say the lower case letters could shrink one pixel down (bottom stays the same) and the upper case, digits, etc shift 1 pixel down. ()[]{}| stay as is.

I'm happy to work on it if you like...

Already done...
VK7JH
MMedit   MMBasic Help
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8604
Posted: 10:54am 12 Sep 2020
Copy link to clipboard 
Print this post

  Quote  There really needs to be a STANDARD consistent way to query the current setting of every option..


I genuinely believe you are overthinking this. If you are writing re-usable routines then it is perfectly reasonable for you to define the settings that are required for them to work and in general these should always be the defaults.

So your code should have a comment at the top that states

  Quote  This routine requires the following settings which are defaults in MMBasic:
OPTION BASE 0
OPTION ANGLE RADIANS
OPTION Y_AXIS DOWN
etc.


Then if someone wants to use your code it is up to them to conform to your requirements.
Edited 2020-09-12 20:55 by matherp
 
thwill

Guru

Joined: 16/09/2019
Location: United Kingdom
Posts: 3865
Posted: 11:01am 12 Sep 2020
Copy link to clipboard 
Print this post

  matherp said  Then if someone wants to use your code it is up to them to conform to your requirements.


Except when your requirements conflict with their requirements and/or they wish to write code that uses multiple different libraries with conflicting sets of requirements.

It's not an unreasonable enhancement request, which of course is not the same as it being possible to fulfill.

Best wishes,

Tom
Game*Mite, CMM2 Welcome Tape, Creaky old text adventures
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8604
Posted: 11:08am 12 Sep 2020
Copy link to clipboard 
Print this post

  Quote  and in general these should always be the defaults.


If you use defaults then it is perfectly reasonable to expect users to follow them IMHO There is absolutely no valid reason to use non default settings. Personally I would remove OPTION BASE entirely but left it there for compatibility. The other two options are specifically there for educational use
 
Tinine
Guru

Joined: 30/03/2016
Location: United Kingdom
Posts: 1646
Posted: 12:04pm 12 Sep 2020
Copy link to clipboard 
Print this post

  matherp said  I genuinely believe you are overthinking this.

Then if someone wants to use your code it is up to them to conform to your requirements.


+1

I was starting to think that I wasn't grasping the problem.

Using 3rd party code libraries, one needs to be aware of what to pass to subs/functions, etc. What's the difference?


Craig
 
thwill

Guru

Joined: 16/09/2019
Location: United Kingdom
Posts: 3865
Posted: 12:24pm 12 Sep 2020
Copy link to clipboard 
Print this post

  Tinine said  Using 3rd party code libraries, one needs to be aware of what to pass to subs/functions, etc. What's the difference?


The difference is that the CMM2 provides (at least) 3 pieces of global state that significantly alter the behaviour of parts of the BASIC language. This state can be set, but it cannot be read (except by looking for its side-effects), and this makes it more difficult than it should be to write reusable code.

A reason for not providing read methods for this state that I could accept is "I don't want to", or "It isn't actually possible", but arguments that there isn't a problem with the current situation I find to be spurious. I suggest a uniform manner (presumably using Mm.Info) that all  options are readable, whether it makes "sense" or not, thus avoiding this debate if another option is added. However if Peter doesn't want to do it and nobody else wishes to step up then that is kind of the end of it.

Best wishes,

Tom
Game*Mite, CMM2 Welcome Tape, Creaky old text adventures
 
thwill

Guru

Joined: 16/09/2019
Location: United Kingdom
Posts: 3865
Posted: 12:28pm 12 Sep 2020
Copy link to clipboard 
Print this post

  matherp said  If you use defaults then it is perfectly reasonable to expect users to follow them IMHO There is absolutely no valid reason to use non default settings. Personally I would remove OPTION BASE entirely but left it there for compatibility.


Yeah ... either OPTION BASE fixed permanently at 0 or 1 and array declarations giving the size of the array and not its highest index would have made things easier. However that is understandably not where we are at.

  Quote  The other two options are specifically there for educational use


So we have to write different versions of resuable code for "education use" ?

However kudos and for responding to a user adding these features even if they do turn out to be a nuisance in the future.

Best wishes,

Tom
Game*Mite, CMM2 Welcome Tape, Creaky old text adventures
 
mkopack73
Senior Member

Joined: 03/07/2020
Location: United States
Posts: 261
Posted: 12:33pm 12 Sep 2020
Copy link to clipboard 
Print this post

  matherp said  
  Quote  and in general these should always be the defaults.


If you use defaults then it is perfectly reasonable to expect users to follow them IMHO There is absolutely no valid reason to use non default settings. Personally I would remove OPTION BASE entirely but left it there for compatibility. The other two options are specifically there for educational use


If the options exist, people WILL use them, plain and simple... As thwill stated, if you are wanting to make use of multiple libraries in your program how do you deal with one library expecting things one way and the next wanting completely opposite settings? The only way to remove this possibility is to write your library to  detect and work properly no matter which way the settings are configured. It puts the burden on the library author but ensures the library works no matter what the user wants.  

Otherwise we can pretty much forget the code base on the CMM2 to ever really grow beyond small toy programs and smallish games, Mauro’s ports will likely end up being the exception rather than the norm. The whole point of having the ability to use includes is to allow for code reuse and not force everyone to reinvent the wheel in every program after all..

I know it seems like I’m harping on this, and I’m not trying to be a pain, but I want to see this platform grow and mature beyond just simple example code and to do that we have to consider what tools are needed to allow that to happen. All the various OPTIONS you provided were put i for very good reasons, and I don’t really have a problem with them being there - they can help the programmer write code they understand or port code in from other dialects. But that same flexibility also adds in the potential for a lot of confusion - “I did exactly what this other guys code did, why doesn’t it work??!” (Not realizing he didn’t have option XYZ set and you did, etc.) The various options provided modify the syntax of the language itself and can very quickly lead to confusion and mismatched code - “but it’s from another CMM2 program!?!?”.

See what I’m getting at? Flexibility is great but it comes at a (unintended) price...

Look if you don’t want to add it, fine I’ll live. But I state this as a warning - the more of these options that get added in in the attempt to make things simpler for the newbie, the more complex it actually will be for them in the long run. And the more Fragmented the code base will become.
 
mkopack73
Senior Member

Joined: 03/07/2020
Location: United States
Posts: 261
Posted: 12:47pm 12 Sep 2020
Copy link to clipboard 
Print this post

  thwill said  
  Tinine said  Using 3rd party code libraries, one needs to be aware of what to pass to subs/functions, etc. What's the difference?


The difference is that the CMM2 provides (at least) 3 pieces of global state that significantly alter the behaviour of parts of the BASIC language. This state can be set, but it cannot be read (except by looking for its side-effects), and this makes it more difficult than it should be to write reusable code.

A reason for not providing read methods for this state that I could accept is "I don't want to", or "It isn't actually possible", but arguments that there isn't a problem with the current situation I find to be spurious. I suggest a uniform manner (presumably using Mm.Info) that all  options are readable, whether it makes "sense" or not, thus avoiding this debate if another option is added. However if Peter doesn't want to do it and nobody else wishes to step up then that is kind of the end of it.

Best wishes,

Tom


Exactly.  Let’s look at the following example.  Let’s say I want to write a flight simulator program (ala something like the old Flight Simulator 2 for the C64). Not an easy task - you have 3D graphics, physics, a bunch of 2D graphics for the instrument panel, and maybe some drop down menus/windows on a UI to build.

Ah, but wait, if there were libraries that somebody already wrote that do the 3D graphics that makes my job easier. Oh, and somebody else wrote a great physics library, awesome. Oh and this other person wrote a nice GUI toolkit library that does windows and menus. My job just got a LOT easier!  

Oh but wait, those authors were lazy and used competing OPTION settings. BALLZ! I could either spend a ton of time trying to figure out their code and fix it to use all the same option settings, or I could just start from scratch... ugh.  Maybe I’ll just go do something else.  Program never gets written...

Understanding how to call functions and use an APi is quite a bit different than having to conform to a given language syntax only to have that syntax change and be modified by each library you want to use. No other language I’ve ever seen (and I’m up to something like 40 or 50 if you include all the various dialects at this point) has ever allowed this sort of syntactic modification that can have such code breaking results and still be considered the same language/dialect/version.
 
     Page 3 of 12    
Print this page
© JAQ Software 2024