locked
Bugs and Suggestions (v0.5 to v0.6) RRS feed

  • General discussion

  • This discussion is here to group the bugs discoveries and suggestions for Small Basic. Please feel free to contribute ;-)

    BUGS : (current version)
    * [FIXED 0.6] When you call a *.sb file "S0.5 - Test 1.sb", the name of the generated *.exe is "S0.exe". It would be better to use a "lastIndexOf" to have the full name of the file.
    * [FIXED 0.6] It's possible to modify the source file when the program is runing simply by typing letters (focus is not deleted correctly by the overlay)
    * [FIXED 0.6] Non inited variables (null) are not equals to "" while they're displayed "".
          If nonExist = "" Then
              nonExist = ""
              TextWindow.WriteLine("OK !")
          Else
              TextWindow.WriteLine("???")
          EndIf

    SUGGESTIONS : (possibly for next versions)
    * Would it be possible to have the following functions about arrays :
    --> [DONE 0.6, Array.GetAllIndices] getAllIndexes(arr) -> returns an array containing all indexes of an array
    --> concat(arr1, arr2) -> returns an array that merge the two other arrays (should work only when indexes are numbers).
    --> isArray(var) -> returns 'True' if var is a (non-empty) array, 'False' otherwhise
    * (seen at another place of the forum) Having a 'function list' as panel that allow navigating eseayly in larger documents


    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension

     

    • Changed type Vijaye Raji Wednesday, June 17, 2009 4:49 PM
    • Edited by FremyCompany [MSFT] Thursday, August 20, 2009 3:03 PM Update for 0.6
    • Edited by Vijaye Raji Thursday, August 20, 2009 4:01 PM We have another thread for 0.6
    Wednesday, June 17, 2009 3:33 PM

All replies

  • As I already have found a (very small) bug about v0.5, I said myself it would be better to post all bugs and suggestions in one single post rather than in thousands of it. And I don't want to polluate the announcement post either.

    So, I created this post. If you have suggestions to make for next version of Small Basic, here is the better place.

    Here's my first list of bugs (I'll probably edit in the next few days) :

    * When you call a *.sb file "S0.5 - Test 1.sb", the name of the generated *.exe is "S0.exe". It would be better to use a "lastIndexOf" to have the full name of the file.
    * It's possible to modify the source file when the program is runing simply by typing letters (focus is not deleted correctly by the overlay)
    * Not a bug, just a remark :

    a[0] = 0
    
    a[1] = 1
    
    
    
    b = a
    
    
    
    b[0] = 1
    
    
    
    TextWindow.WriteLine(a)
    
    TextWindow.WriteLine(a[0])
    
    TextWindow.WriteLine(a[1])
    
    
    
    TextWindow.WriteLine(b)
    
    TextWindow.WriteLine(b[0])
    
    TextWindow.WriteLine(b[1])
    produce

    0=0;1=1;
    
    0
    
    1
    
    
    
    0=1;1=1;
    
    1
    
    1
    
    
    
    Press any key to continue...
    
    

    So, arrays are copied only regarding value, not reference. It's logical since Primitive is a value type. At start I was thinking that the arrays would be linked by the reference to the _arrayMap but it finally seems that you catched up the problem and fixed it, so that the arrays are not linked to each others.

    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension
    Just to clarify, was it ever broken?
    Wednesday, June 17, 2009 4:48 PM
  • Just to clarify, was it ever broken?

    I don't know :) I never read your private release :) But when I read the implementation on reflector, I've immediately thought it may be a possible bug (because if you send the string by value and the arrayMap by reference, you can end up by having mismatch between the two). But you seems to have done the job really good, so the problem doesn't occur. It's what I wanted to say with this sentence. (I know I've a poor vocabulary in English, so it can end up by making sentences that don't reflect exaclty what I'm really thinking). I'll do the edit in my original message.

    BTW, can you reproduce the other bugs ?
    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension
    Wednesday, June 17, 2009 5:04 PM
  • Yes Fremy,

    The other bugs are confirmed.  I'll get them into our bug database to fix for next releases.

    Wednesday, June 17, 2009 7:02 PM
  • Another thing that would be great (suggestion) is an isArray function :
    --> isArray(var) -> Returns 'True' if var is a (non-empty) array, 'False' otherwhise

    Currently, we can check that by doing "Array.GetCountItem(var) <> 0" but it's unusual for a beginner because we then assume the variable IS an array (which all variables can be in Small Basic)

    Please note that here's a variant of the null <> "" problem :

         newArray[nonExist] = "..."
         TextWindow.WriteLine(newArray) // seems newArray[""] is defined
         TextWindow.WriteLine(newArray[""]) // return that it's not defined
         nonExist = ""


    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension
    Wednesday, June 17, 2009 7:20 PM
  • New "bug" discovered :

    *  When you type "Timer." whithout using the Intellisense, the Intellisense don't display the properties of Timer but become gray as no object begins with "Timer."

    Old problem still alive :

    *  [FIXED 0.6] Mouse.HideCursor often fails (on WinXP at least)
    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension
    Thursday, June 18, 2009 6:15 PM
  • On my Vista, the Timer works OK with intellisense.  The Mouse.HideCursor() doesn't remove the mouse pointer, assuming this is the intention.
    Thursday, June 18, 2009 7:27 PM
  • Suggestion:

      Mouse.InBounds(x1,y1,x2,y2)
      
    and 
      GraphicsWindow.MouseInBounds(x1,y1,x2,y2)

      returns "True" if MouseX and MouseY are inside Rect(x1,y1,x2,y2)

      this would be easier than

      If (GraphicsWindow.MouseX >= x1 and GraphicsWindow.MouseY >= y1 and GraphicsWindow.MouseX <= x2 and GraphicsWindow.MouseY <= y2) Then

    Friday, June 19, 2009 3:10 AM
  • Having lots of convenient functions is to me a problem that plagues modern compilers, and simply gets in the way of productivity in the end.  I may be biased because I've seen how great & simple things were in the past.  Assembly code of 20 years ago is way easier than .net today.  Rant rant rant...
    Friday, June 19, 2009 4:56 AM
  • I tend to agree with bigdaddyo that as a learining tool SB really benefits from a limited number of commands.  Also much of the learning is about using these small set of commands to do more complex things and hence leading to writing subroutines (e.g. subroutine for InBounds could be written).  We have seen the fantastic results that can be achieved with asteroids and stargates for example.

    With this in mind the issues about subroutine arguments and variable scope arises.  I am swinging towards the idea that this may be helpful if it can be done in such a way that it doesn't complicate things for the beginner before they have to worry about such things.  More thought needed.
    Friday, June 19, 2009 8:40 AM
  • I think small basic should be essentially left as-is given it's purpose, with maybe a function list on the right side of the editor, and a debugger would be a god-send.  It isn't going to be a go-to language for the typical programmer/hobbiest, at least I think that's the intent, it seems to be more of one for experimentation in programming without getting a headache.  Any program of significant size is hindered by the use of global variables and lack of passable parameters, and the speed of the language will prevent it from doing significant real-time stuff.  That's mostly just the tradeoff of keeping things simple for new programmers.

    I myself would like to see it or a derivative become a bit more full & fast language that I could use everyday, but that probably wouldn't be in a new programmers best interest.  It's a bit hard to hold yourself back from wanting more, since probably most of us have been at it for many years.

    Friday, June 19, 2009 7:28 PM
  • I wanted to chime in with bigdaddyo and litdev. Back in the early days of list servers, I used to monitor one dealing with Visual Basic. Most of the questions that would come across would be along the lines of "How do I make this obscure function do what I want". In nearly every case, I could provided a code snippet of 10 lines or less that would do exactly what the person wanted and make the obscure function pointless. I would then follow up the answer with the tag line: "Your not a programmer unless you actually program".

    Resist the urge to add the helper routines. In the long run they do not provide much actual help. You are better off writing your own subroutine.


    With that idea in mind, I wanted to reinterate a previous suggestion of mine. Single scope subroutine paramters.

    Example: Defnition: Sub myRoutine(x, y)     Usage: myroutine(a, b)

    When called, the values of a and b would be simply copied to x and y. All in the same scope. You get the idea of how subroutines are used, you save the trouble of having to set variables before calling a routine (something that really irritates me), and the whole idea of subroutines becomes a much more teachable topic
    .
    Friday, June 19, 2009 8:11 PM
    Answerer
  • ^- I do like that idea, except you can still clobber other global x & y variables, unless I misunderstood.  But the programmer could always use names like xobscurename, yobscurename in their function to keep it unlikely.  This way programmers can do whatever they want I suppose, like any other language with global variables.

    Side rant, Cat's comment on "your not a programmer unless you actually program" - I feel like i'm not programming everytime I see or try using some gigantic library/class object.  It's just a bunch of memorizing &/or looking up myriads of methods, protocols, formats, & steps and figuring out why the darn thing doesn't work the way you want it to.  It is unfortunate that most of today's languages take forever to figure out a 'hello world', when it can be as simple as 'print 'hello world''.  Sorry if this turned into a fat language complaints column!
    Friday, June 19, 2009 10:09 PM
  • Just to clarify a little from bigdaddyo's comment: Yes, you can still "clobber" global variables with the parameters. Everything is in a single scope and every variable is a global variable. I actually love this about SmallBasic. From a newbie's point of view, having all variables be global makes a lot more sense then trying to figure out what "Scope" is and what is valid in each part of a program.

    The parameters would be there for convenience (a great convenience in my humble opinion) and would more closely match other languages. 
    Friday, June 19, 2009 10:23 PM
    Answerer
  • Coding Cat,

    A tricky one.  For example if we have global scope variables and subroutine arguments, say:

    Sub Add(x, y, z)
      z = x+y
    EndSub


    Add(i, j, k)


    Inside the subroutine this would set x = i, y = j and z = x+y, then return k = z.

    If x, y or z are used elsewhere this would create chaos. 

    In this case the user would have to be very careful not to use a variable name inside a subroutine that is used elsewhere.  Why not: take this responsibility away from the user and say: the only variables a subroutine can change are the arguments to the subroutine .

    Therefore it is reasonable that if we explicitly pass arguments (j, j, k) then x, y and z (since these are just copies of i, j, k) should only have scope within the subroutine.  Additionally, I would say all variables not passed as arguments should be local to the subroutine.

    I agree the concept of scope and subroutines is a hurdle. 

    However, to have arguments to a subroutine implies these are copies from the calling code to variables within the subroutine, and that the only variables that are changed by the subroutine on its return should be these argument variables.

    In summary, I think we either have global scope and no subroutine arguments OR non-global scope and subroutine arguments.  A mix would be the worst option.

    I presume developers of SB realised this and chose the former, but I see an increasing argument for the second option.  A dilemma!

    PS. The disadvantage of the latter option is that all global variables required in a subroutine would have to be passed as arguments so I am not sure?

    • Edited by litdev Friday, June 19, 2009 11:36 PM PS added
    Friday, June 19, 2009 11:32 PM
  • My meaning is that Small Basic should not add lot of new functions to the libraries.
    Beginners should instead gain the habbit of writing subs theirself.

    My proposal for subs is the following :

    Sub X(a, b, c)
       a = a + b + c
    EndSub

    Sub Math.Y(a, b, c)
       Y = (a * b) + (c / a)
    EndSub

    i = 1
    j = 2
    k = 3

    X(i, j, k) ' i = 6
    i = Math.Y(i, j, k) ' i = ...

    My proposal would be compiled into functions who should have an primitive as 'byref' arguments.
    The only technical problem is the SmallBasicCallBack that would not represent all kind of Small Basic Functions. But is it really a problem ?

    Maybe we can transform SmallBasicCallback into Func(ParamArray args() as Primitive) as Primitve. But we then loose the 'byref' possibility. But maybe it's better. What do you think of it ? This last solution have two major advantage : it's simple to implement and it will make clear the difference between parameters and global variables.


    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension
    Saturday, June 20, 2009 10:20 AM
  • Litdev, I think this may be over stating the issue a little. What you are describing as chaos is the problem that eventually arises with any single scope language; as the programs get larger the chance of stepping on a value by reusing a variable becomes more likely.
       
    If the target audience of SmallBasic is the newbie, then there are no preconceived notions or expectations. They won't be expecting variables to be local to a subroutine because they have had no experience suggesting that should be the case.

    The goal is for the users to have some fun and learn the basics of programming along the way. Keep it simple, and when they are feeling crowded, encourage them to move on to another language.

    My suggestion of the single scope parameters will actually simplify the language while giving the users some experience with how routines are used in other languages. Let's take another look:

    Current usage:
        Definition:
            Sub myRoutine
                If x > y Then
                    x = z
                Else
                    y = z
                EndIf
            EndSub
        Usage:
            x = a
            y = b
            z = c
            myRoutine()

    My Suggestoin:
        Definition:
            Sub myRoutine(x, y, z)
                '… same code as above
        Usage:
            myRoutine(a, b, c)

    The need to do the variable assignments before the subroutine call greatly diminishes its usefulness. The two main reasons for using subroutines are: 1) to save space with code reuse, and 2) to cut down on errors by standardizing code in one place.

    The idea of code standardization, putting common code in one place so changes only have to be made once, doesn't even occur to newbies. It is the first idea, saving typing by reusing code, that will push someone new to programming to use sub routines. And the need to set the parameters in the main code kills this idea.

    Why would you write a five line sub routine, if it takes four lines of code to call it? You wouldn't. You would instead just make copies of the needed code inline. This is why there are not very many subroutines in the SmallBasic code I write. This is also why I have a hard time explaining the need for subroutines to my Intro students. 

    Think of the parameter list of a subroutine call as a helper macro that does the value assignment for you. All of the other bells and whistles of subroutines (such as return values, passing by reference and local variables) should be left for other languages.
     
    Saturday, June 20, 2009 3:15 PM
    Answerer
  • Why would you write a five line sub routine, if it takes four lines of code to call it? You wouldn't. You would instead just make copies of the needed code inline. This is why there are not very many subroutines in the SmallBasic code I write. This is also why I have a hard time explaining the need for subroutines to my Intro students. 

    Think of the parameter list of a subroutine call as a helper macro that does the value assignment for you. All of the other bells and whistles of subroutines (such as return values, passing by reference and local variables) should be left for other languages.
     

    I strongly agree with the first sentence. Not by the second one.

    Functions wrotten "by Small Basic" can return value. Why should we prevent beginners to do so ? It's a limitation that's non-sense. Because you would have the same problem as with params.

       Double_result = 0 
       Sub Double(x)
           Double_result = 2 * x
       EndSub
       
       Double(1)
       a = Double_result
       Double(2)
       b = Double_result
       Double(3)
       c = Double_result
       TextWindow.WriteLine(a + b + c)

    vs 

       Sub Double(x)
           Double = 2 * x
       EndSub
       
       TextWindow.WriteLine(Double(1) + Double(2) + Double(3))

    Params should be local variables (to allow recursivity and same params name across multiple functions without risk of problems), but I agree that other kinds of variable shouldn't be local. Beginners don't need that. Referenced variables are not needed. It's just a question we can ask ourself. Should ALL params be 'byref' or ALL params be 'byval'. It's a question we need to envisage before making SB 'param-ready'.
    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension
    Saturday, June 20, 2009 4:12 PM
  • I agree it is possible to have just the subroutine arguments only as local variables, allowing other global variables to be accessed inside the sub.

    This reduces the assignment overhead (pre and post the sub call) and I think it makes sense that the sub can return a result (more like a Function) as Fremy suggests.

    This could keep things logical and consistent.  Whether these concepts will make SB more complex or easier to use for the beginner is unclear to me and I would tend to go with what those teaching it feel.

    Saturday, June 20, 2009 5:05 PM
  • Whether these concepts will make SB more complex or easier to use for the beginner is unclear to me and I would tend to go with what those teaching it feel.
    Since you already must to explain what a parameter is and that a function can return a value (b=Math.Sin(a)), I don't think it would be a problem.

    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension
    Saturday, June 20, 2009 7:51 PM
  • I believe that single scope parameters would be imencely help for and a more realistic first language. Almost all languages have some sort of scoping to them and the abilty to return a value is more inline too. From what i read Small Basic is a steping stone language. put all params BYVAL, no need to clutter the head of someone just learning. BYREF is a beautiful, but advanced topic. Let a variable in the local scope with the same name as the sub be a retval an poof, Small Basic is 10X more powerful 100X more useful, 1.00001x harder to learn, but will help a budding programer.

    but do not make globals in the sub go away, just for backward compatability. I actualy like something like this
    A new Keyword might be a posibility "My" so that we can make a local scope Var.

    These changes are still basic, but a very common theme in programing language.


    Sub MyNewFun
      'Outputs a list of functions
      TextWindows.WriteLine(prams)
      MyNewFun = "OhMy"
    EndSub

    Sunday, June 21, 2009 11:07 PM
  • It is my humble opinion that adding any secondary scope or local variables is a bad idea. I make this statement remembering my first days with MS Basic back in the early 80's and watching my Intro students struggle with programming concepts now. The idea that some variables are available at certain times and not others time is seriously confusing to a student that is struggling with the idea of what a variable and a subroutine is in the first place.

    Keep it simple; all the variables in one pool, parameters passed by value.

    Your eye should on how a beginner will view things, not on the effects a concept will have on larger programs. Remember, there are Java, C, Flash and Visual Basic waiting for users who get the idea of recursion in their heads; and a stack structure for those who insist on recursing in Small Basic.

    With that said, I have to say that I like Fremy's idea for return values. I was thinking "skip it" because I couldn't image a simple enough syntax for the idea. The concept of using the subroutine name for the return variable is brilliant.

    Here is an example with the idea of return values:
        Definition:
            Sub myRoutine(x, y)
                If x > y Then
                    myRoutine = x
                Else
                    myRoutine = y
                EndIf
            EndSub
        Usage:
            c = myRoutine(a, b)
    Monday, June 22, 2009 12:08 AM
    Answerer
  • Hello!

    1. Do constants True and False still exist? If not (it looks like there's no such keywords) what I have to do i.e. with GraphicsWindow.CanResize ? TextWindow.WriteLine(GraphicsWindow.CanResize) returns True and False.

    2. Maybe it's good idea to add Clock.Ticks or similar property. I know I asked about it already but it may be really useful for calculating time elapsed.  I know I can count my own ticks based on Timer, but Ticks seems to be easier to use.

    3. What does 'Esc' key do in editor? Now this behavior looks strange especially if I find something. It will be nice to use Esc to de-select found text instead of replacing it with '?'.

    4. Maybe you can add some nice keyboard shortcut (like F3 for Find Next) for switching edit windows? Ctrl+Tab, Ctrl+F6? I don't know.

    That's all for now. 0.5 seems to be really nice! :)


    Grzesio
    Monday, June 22, 2009 9:47 AM
  • Hello!

    1. Do constants True and False still exist? If not (it looks like there's no such keywords) what I have to do i.e. with GraphicsWindow.CanResize ? TextWindow.WriteLine(GraphicsWindow.CanResize) returns True and False.


    You should use "True" or "False", even if I agree with you that True, False and Nothing should be constants.

    2. Maybe it's good idea to add Clock.Ticks or similar property. I know I asked about it already but it may be really useful for calculating time elapsed.  I know I can count my own ticks based on Timer, but Ticks seems to be easier to use.

    3. What does 'Esc' key do in editor? Now this behavior looks strange especially if I find something. It will be nice to use Esc to de-select found text instead of replacing it with '?'.
    Never tested it, but if I also think Esc should deselect the text

    4. Maybe you can add some nice keyboard shortcut (like F3 for Find Next) for switching edit windows? Ctrl+Tab, Ctrl+F6? I don't know.

    That's all for now. 0.5 seems to be really nice! :)


    Grzesio
    Another new request :
    When we open several scripts, the window are each time opened 15*15px later (first is opened at 0*0, second at 15*15, ...) The problem is that the counter never reset, and windows finish to open beside the info sidebar.... You should reset the counter to 0 after 5*15px
    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension
    Monday, June 22, 2009 10:54 AM
  • Another new request :
    When we open several scripts, the window are each time opened 15*15px later (first is opened at 0*0, second at 15*15, ...) The problem is that the counter never reset, and windows finish to open beside the info sidebar.... You should reset the counter to 0 after 5*15px

    Now it is reset when top left goes off-window. I think it's better to detect right-bottom corner or reset as you suggest after 5 incrementations.

    Yet another thing:
    "Maximize" button for editing windows or making entire Small Basic GUI more MDI-like. Maximizing editor seems to be useful feature. Current GUI is really nice, so please do not convert it into flat, well known MDI. :)
    Grzesio
    Monday, June 22, 2009 11:24 AM
  • Another reason why you should use "Custom Events" or, at least modify the event behaviour : http://social.msdn.microsoft.com/Forums/en-US/smallbasic/thread/5a5d942a-ee34-4825-a42d-d26ea587a230
    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension
    Sunday, June 28, 2009 11:47 AM
  • This code crashes the program since it requested more characters than are in the string:

    a = "abcd"
    b = Text.GetSubText(a, 1, 5)

    A few other things.  Text.Endswith and Text.Startswith is an unnecessary feature.  This language must have a Text.GetValue("123") feature that returns "" if the first characters of the string are non-numeric.  If a non-numeric character is found, take only numerics preceeding them and return the number.

    Also divide by zero still crashes the program.  I suggest a message box comes up indicating the issue, then maybe close the program, or replace the result with a number like 99999.

    Sunday, June 28, 2009 5:05 PM
  • Another reason why you should use "Custom Events" or, at least modify the event behaviour : http://social.msdn.microsoft.com/Forums/en-US/smallbasic/thread/5a5d942a-ee34-4825-a42d-d26ea587a230
    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension

    What do you mean by "Custom Events", Fremy?
    Sunday, June 28, 2009 8:27 PM
  • I would strongly suggest not have events prempt code execution, maybe he's referring to that and all it's potential problems.  Premption is an advanced topic, that will confuse everytime.  Just make a note of the event, and process them during something like Program.DoEvents(), visual basic did things well that way.
    Sunday, June 28, 2009 8:41 PM
  • What do you mean by "Custom Events", Fremy?

    Here is a sample of Custom Event (must be located in a class/module, as any event) :

        Public Custom Event CustomTimeStampEvent As TimeStampEventDelegate

            AddHandler(ByVal value As TimeStampEventDelegate)

    ' Do something to replace the default action when an handler is added to the event
            End AddHandler

            RemoveHandler(ByVal value As TimeStampEventDelegate)

    ' Do something to replace the default action when an handler is remover to the event
            End RemoveHandler

            RaiseEvent(ByVal sender AsObject, ByVal e As TimestampEventArgs)

    ' Do something to replace the default action when an event is raised
    End RaiseEvent

       End Event

    I don't know how you can perform that in C#. I never decompiled a "Custom Event" to see how it works in C#.

    The main idea is that it works the same way as a normal event, but you define yourself the "handling" process. It's cool feature of VB.NET.

    In this case, you should use it because in Small Basic, adding an event handler use the "=" symbol. So, people use the event as a "variable" and think that they can modify the event handler by in fact adding a new handler. (+= in C#).

    You so can use Custom Events to replace the adding handler process so that only one handler is available at a time... Do you follow me ?
    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension
    Monday, June 29, 2009 7:32 AM
  • I don't agree here. It's counter intuitive.

    If you want this behaviour, you can emulate it yourself :

    O.Event = O_Event
    Sub O_Event
        O_Event_Occured = "True"
    EndSub

    While "True"
        ' Process code
        DoEvents()
    EndWhile

    Sub DoEvents
        If O_Event_Occured Then
            O_Event_Occured = "False"
            ' What to do...
        EndIf
    EndSub


    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension
    Monday, June 29, 2009 7:37 AM
  • @Fremy,

    If I understood your point, you want event assignments to replace existing subscribers.  I think I agree with you - and I can't see any problems with that.  I'll add it to the list of things to explore for v0.6.
    Monday, June 29, 2009 3:48 PM
  • If I try to read a line beyond the end of a file, the error status does not seem to be set.

    Data=File.ReadLine(filename,100)
    TextWindow.WriteLine(File.LastError)


    This has File.LastError = "" for a file with only 3 lines in it.  I am fairly sure this worked in v0.4 and could be used to check reading beyond the end of a file.

    Also Data=File.ReadLine(filename,-100) gives no error in File.LastError .
    Monday, June 29, 2009 6:09 PM
  • A small question : Is the Arguments object really needed ?
    Nearly all application I've seen using Small Basic doesn't use it. Maybe you should consider removing it, and locate it into an extension.

    What do you think of it ? Maybe you can search in your code database to find how many upload applications are using it. If the telemetry data confirm that the Arguments object is not often used, you should consider remove it, as it can seems strange for beginners (arguments are normally sent to a function, not to a program, and there's no way to send arguments to a SB's programm until using the console, what beginners never do).
    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension
    Monday, June 29, 2009 7:44 PM
  • A small question : Is the Arguments object really needed ?
    Nearly all application I've seen using Small Basic doesn't use it. Maybe you should consider removing it, and locate it into an extension.
    I agree that "command line arguments" is not a strong enough concept for its own object. It is still very handy to have access to the command line, so I would suggest moving the functionality to the "Program" object.

    Program.getargumentCount()
    Program.getArugment(index)



    Monday, June 29, 2009 8:26 PM
    Answerer
  • I like Coding Cat's suggestion. 
    Monday, June 29, 2009 9:40 PM
  • This might seem like a silly request, but how about a low resolution graphics mode, so people can actually see the pixels they set allowing feedback if they did it correctly?  How dinosaur does this program look QKN903
    Monday, June 29, 2009 11:59 PM
  • This might seem like a silly request, but how about a low resolution graphics mode, so people can actually see the pixels they set allowing feedback if they did it correctly?  How dinosaur does this program look QKN903

    Why to use lowres?
    Maybe it's better to think "how to convert my console app to graphics one" than "how to port my old app to SmallBasic""?

    We learned programming in text mode... But I think if you just show SmallBasic to newbies - 90% of them choose GraphicsWindow :)

    Do not except too much... It's _Small_ Basic and it have to be easy and very limited.
    Grzesio
    Tuesday, June 30, 2009 5:12 AM
  • I bring it up because using blocky graphics, although a bit ugly, is much easier to program in a graphics window for collision detection or mazes for the most basic games.  It could be a simple mode like GraphicsWindow.LowRes().  I don't have any old programs that'd use it, but there are benefits to a young beginner.
    Tuesday, June 30, 2009 5:29 AM
  • I bring it up because using blocky graphics, although a bit ugly, is much easier to program in a graphics window for collision detection or mazes for the most basic games.  It could be a simple mode like GraphicsWindow.LowRes().  I don't have any old programs that'd use it, but there are benefits to a young beginner.

    You may do the same thing with GraphicsWindow. Of couse it takes more lines of code but it makes sense.
    Collision detection is possible same way you do it in text window.
    Grzesio
    Tuesday, June 30, 2009 6:32 AM
  • I don't really like doing anything in the text window, I wish there wasn't one really.  Having two things you can work with for output is a little bit confusing to the first time programmer.  I don't see why everything couldn't be done in the graphics window, just like VB partially was (is?).  Cursor position could just as easily apply to the graphics window.  You will want to use fixed pitch fonts though only, that don't resize with your windows desktop settings.  And only show the text cursor when asking for input.  Compact & simple is the key.

    With the advent of eliminating the text window, you could get rid of the use of the GraphicsWindow object, which I already know kids are completely turned off from having to type even though intellisense helps alot.  It's just remembering the first few letters that are the most difficult thing.  Things like GraphicsWindow.Top could be Program.Top instead.  Another suggestion is the use of the words DrawText & DrawBoundText for printing text really should just be simply Print & PrintBound, unless you plan on having a printer object someday (might be very nice to have).  I'm having issues teaching because of the wording isn't quite natural, the point of BASIC.  The text window's use of Write believe it or not is sometimes a word that is difficult to spell (silent W).  Older basics could have optional parameters, which would be great for Print, where you could either simply enter Print("hello") and each time would automatically do a carriage return, or Print("hello", x, y).  The latter wouldn't do a carriage return.  Printed characters and other graphics parts appear to be separately maintained compiler objects, so it shouldn't be too difficult for the compiler to scroll text up the display (graphics could hold stationary) if they print & carriage return more times than there are possible text rows on the display.

    It's these little things that make the difference to a young learner.

    For blocky graphics, your 'player' could be one block that moves around a maze for example, and all you would have to do for collision detection is do a GetPixel() above, below, left, or right depending on the direction you want to move, to see if you hit a wall, or maybe an enemy if they are specific colors.  It's extremely simple coding, works, and isn't really possible in full resolution because nobody would want to move a single full res pixel around on the screen.

    If anyone likes/dislikes the sound of all this, you'll need to reply otherwise it'll fall through the cracks.
    • Edited by bigdaddyo Tuesday, June 30, 2009 5:10 PM
    Tuesday, June 30, 2009 5:03 PM
  • K I S S  = Keep it simple (4d) Stupied (ie.me)

    turn programing into a game i.e.

    start with making turtle apear-  print " congrats you now reached leavel 2" " this is how to make turtle move (..........)

    for next leavel move turtle to postion  ( a,b) when turtle =  (a,b) print " you now reached leval 3" and this adds a button on the tool bar, now we have 2 buttons that will right the code into the script and just needs to add points. ect ect ect.






    ' whats the code to get a text box to run inside a box in the graphics window? there must be a sub for it sumwhere.
    Tuesday, June 30, 2009 7:08 PM
  • bigdadio,

    For me the TextWindow allows 3 main features:
    1. easy text input/output
    2. scrolling text to handle more than 1 page of text
    3. a second window
    The first two of these could be implemented within the GraphicsWindow as you suggest, or in fact coded using SB into the current GraphicsWindow (with a bit of work).  Personally I find having two windows (1 graphics and 1 text) helpful - for example using the TextWindow to output debug statements while running something in the GraphicsWindow - with a debugger this would be less of an issue.

    I tend to think text and graphics are distict ideas and worth preserving two windows - they would be separate dialogues in most languages.  Perhaps TextWindow(s) could be optionally embedded within the GraphicsWindow like dialogues with their coordinates and size set by the user, although I wouldn't.

    One other point is that it is not helpful to beginners using SB or those teaching it to radically change it too often - backwards compatibility issues and a new learning curve every release is not helpful unless there is a very good reason (e.g. arrays).  I agree every keyword may not be absolutely intuative first time you see them, but this is true of all languages.  If there aren't too many of them, there is an underlying logic and they don't keep changing I reckon the exact keywords or syntax isn't that important?  So far SB scores on all three of these for me.  After some period of use, then whatever the syntax, it becomes second nature (1.3 billion Chinese seem to cope).

    For the user that is interested in various dialogue controls, I would suggest using VB 2008 Express - it is set up for this.

    For the user wanting a small set of commands that allow rapid programming learning (rather than struggling with syntax) I recommend SB.  Ultimately however, everyone should want something more and move on when the limitations are felt - by that time SB has served its purpose as Sinclair Spectrum Basic did for me and countless others of growing up in the 80s.

    I still think more documentation and examples would be helpful and are the key to getting the most out of SB.

    A debugger and print feature would be nice - kids love printing stuff!
    Tuesday, June 30, 2009 7:58 PM
  • bigdadio,

    For me the TextWindow allows 3 main features:
    1. easy text input/output
    2. scrolling text to handle more than 1 page of text
    3. a second window
    The first two of these could be implemented within the GraphicsWindow as you suggest, or in fact coded using SB into the current GraphicsWindow (with a bit of work).  Personally I find having two windows (1 graphics and 1 text) helpful - for example using the TextWindow to output debug statements while running something in the GraphicsWindow - with a debugger this would be less of an issue.

    I tend to think text and graphics are distict ideas and worth preserving two windows - they would be separate dialogues in most languages.  Perhaps TextWindow(s) could be optionally embedded within the GraphicsWindow like dialogues with their coordinates and size set by the user, although I wouldn't.

    One other point is that it is not helpful to beginners using SB or those teaching it to radically change it too often - backwards compatibility issues and a new learning curve every release is not helpful unless there is a very good reason (e.g. arrays).  I agree every keyword may not be absolutely intuative first time you see them, but this is true of all languages.  If there aren't too many of them, there is an underlying logic and they don't keep changing I reckon the exact keywords or syntax isn't that important?  So far SB scores on all three of these for me.  After some period of use, then whatever the syntax, it becomes second nature (1.3 billion Chinese seem to cope).

    For the user that is interested in various dialogue controls, I would suggest using VB 2008 Express - it is set up for this.

    For the user wanting a small set of commands that allow rapid programming learning (rather than struggling with syntax) I recommend SB.  Ultimately however, everyone should want something more and move on when the limitations are felt - by that time SB has served its purpose as Sinclair Spectrum Basic did for me and countless others of growing up in the 80s.

    I still think more documentation and examples would be helpful and are the key to getting the most out of SB.

    A debugger and print feature would be nice - kids love printing stuff!

    -"INsted of printting stuff {save paper please} why not try and make a 3d printer availbe in each town where by they can devlope there own toys, it will also get them out the house for sum fresh air and excize""
    now i forgoten wot i was gona say, - call scenario - rewind.
    Tuesday, June 30, 2009 8:15 PM
  • bigdadio,

    For me the TextWindow allows 3 main features:
    1. easy text input/output
    2. scrolling text to handle more than 1 page of text
    3. a second window
    The first two of these could be implemented within the GraphicsWindow as you suggest, or in fact coded using SB into the current GraphicsWindow (with a bit of work).  Personally I find having two windows (1 graphics and 1 text) helpful - for example using the TextWindow to output debug statements while running something in the GraphicsWindow - with a debugger this would be less of an issue.

    I tend to think text and graphics are distict ideas and worth preserving two windows - they would be separate dialogues in most languages.  Perhaps TextWindow(s) could be optionally embedded within the GraphicsWindow like dialogues with their coordinates and size set by the user, although I wouldn't.

    One other point is that it is not helpful to beginners using SB or those teaching it to radically change it too often - backwards compatibility issues and a new learning curve every release is not helpful unless there is a very good reason (e.g. arrays).  I agree every keyword may not be absolutely intuative first time you see them, but this is true of all languages.  If there aren't too many of them, there is an underlying logic and they don't keep changing I reckon the exact keywords or syntax isn't that important?  So far SB scores on all three of these for me.  After some period of use, then whatever the syntax, it becomes second nature (1.3 billion Chinese seem to cope).

    For the user that is interested in various dialogue controls, I would suggest using VB 2008 Express - it is set up for this.

    For the user wanting a small set of commands that allow rapid programming learning (rather than struggling with syntax) I recommend SB.  Ultimately however, everyone should want something more and move on when the limitations are felt - by that time SB has served its purpose as Sinclair Spectrum Basic did for me and countless others of growing up in the 80s.

    I still think more documentation and examples would be helpful and are the key to getting the most out of SB.

    A debugger and print feature would be nice - kids love printing stuff!

    -"INsted of printting stuff {save paper please} why not try and make a 3d printer availbe in each town where by they can devlope there own toys, it will also get them out the house for sum fresh air and excize""
    now i forgoten wot i was gona say, - call scenario - rewind.

    Bingo-
    10 let os = .sb
    let bob make scenarios.
    fill scenario69 with astonmartin.N E 1
    'make skool of life = .sb fourms each admin learns with 1 - 78 copys sort of like soul mate learning if u wana go all new agey,
    call end rewind wb

    Tuesday, June 30, 2009 8:33 PM
  • A debugger and print feature would be nice - kids love printing stuff!

    Debugger is nice but it complicates entire environment. If it's really necessary - it's possible to play with textwindow or messageboxes etc.

    Printing...? And what about ecology? ;)
    From my own point of view something like GraphicsWindow.SaveToFile should be enough.
    Grzesio
    Tuesday, June 30, 2009 8:39 PM
  • I'm suggesting fewer features by reducing complexity/possibly redundant objects.  I realize it'll be difficult with significant changes for those using this already in a classroom, but it is only ver 0.5.  Once you hit 1.0, you really gotta keep core things essentially the same, i'm obviously an idealist...  Having two windows is kinda cool, didn't think of using it for debugging although it'll scroll like mad for what might often be done in code.  I know it won't be what I would want for myself to do most things I can think of, but I'd like to see it having a good chance of being ideal for 11ish year olds, but maybe that's not the target though I think something should be.  I'm a bit torn between this and phrogram for instance, but at the moment not willing to pay $50 for that one and not sure I want the extra language complexity.

    If you give something kids will love to use, you've got a good chance they'll be using that brand professionally, at least that's what happened to me.

    Kids really do like to print out paper.
    Wednesday, July 1, 2009 4:38 AM
  • a few ideas ,

    How about  .v that can be theamed fo eg. a barry trotter one where by all the fuctions are in the form of spells or a disney one where by all the fuctions are cartoon names could even make a barney one.

    and kids realy do like printting they also like pulling the legs off spiders and pickking thier nose.

    how about thinkking along the lines of t shirt printting or thermall reuseable paper?

    Wednesday, July 1, 2009 2:49 PM
  • Debugger is nice but it complicates entire environment. If it's really necessary - it's possible to play with textwindow or messageboxes etc.


    Grzesio

    It could be very simple.
    For example, you could have the debuger compiled in the application (automatically, by Small Basic Compiler) !


    Number = 0
    Number2 = 1/Number
    Program.End()

    >>> Compiled as (pseudo-VB.NET code) >>>

    Sub _Main()
        Dim __Line as Integer = 0
        Try
            line_1:
                __Line = 1
                Number = 0
            line_2:
                __Line = 2
                Number2 = 1/Number
            line_3:
                 __Line = 3
                Library.Program.End()
        Catch ex as Exception
            Dim DAction as DebugAction = Library.Internal.Debug.ShowDebugWindowForLine(__Line, ex) '__Line is by reference (ByRef)
            ' Show the value of all variables, show the code and the line where the error occus, give the possibilty to execute code (as SmallBasic.Eval of my extension allow, for example)
            ' Give four buttons : Redo same line (as you can modify variables "by hand", it can be useful) - Continue to next line (as if no error occured) - Continue to any line (set next instruction) - Exit program
            Select Case DAction.Type
               Case DActionType.Close
                  Program.End()
               Case DActionType.Resume
                  Select Case __Line
                      Case 1
                          Goto line_1
                      Case 2
                          Goto line_2
                      Case 3
                          Goto line_3
            End Select
        EndTry
    EndSub
    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension
    Wednesday, July 1, 2009 5:04 PM
  • a few ideas ,

    How about  .v that can be theamed fo eg. a barry trotter one where by all the fuctions are in the form of spells or a disney one where by all the fuctions are cartoon names could even make a barney one.

    and kids realy do like printting they also like pulling the legs off spiders and pickking thier nose.

    how about thinkking along the lines of t shirt printting or thermall reuseable paper?


    how about rice paper and food dye? they could eat stuff.
    Thursday, July 2, 2009 12:01 AM
  • Maybe this is posted elsewhere, but doing a ImageList.LoadImage("somepath") will crash SB if the path/filename is invalid/doesn't exist.

    Thursday, July 2, 2009 6:23 PM

  • Bingo-
    10 let os = .sb
    let bob make scenarios.
    fill scenario666 with meatloaf
    'make skool of life = .sb fourms each admin learns with 1 - 78 copys sort of like soul mate learning if u wana go all new agey,
    call end rewind wb

    if when a new pc was turned on mr turtle was center , and the arrow keys moved him till stop. and thats it.
    !box 1 should= HELoL WORLD .

    then the user would at sumtime make a box when that happens if the box when clicked made mr turtles "house"where we could make a tv to view our pics, a draw to keep our files  a desk to write at ect.and next to it there were sum numbers they could change to change the house /

    Thursday, July 2, 2009 10:24 PM
  • Following shraddhak99's question I wonder if image = GraphicsWindow.ImageCapture(x,y,width,height) might be useful if we also have a File.SaveImage(image,file) , as a bitmap.  I know this is feature creep but would allow image manipulation and provide a gateway to printing.
    Friday, July 3, 2009 6:11 PM
  • I would really like the kids to be able to step through a program and see the values of the variable as they do so.  It would make it so much easier to demonstrate and debug their errors.  When I teach VB that is one of the strongest tools I have for showing them what they think the program is doing compared to what the program is actually doing.

    I do not want a lot of built in functions, I want them to build their own.
    Friday, July 3, 2009 7:23 PM
  • Following shraddhak99's question I wonder if image = GraphicsWindow.ImageCapture(x,y,width,height) might be useful if we also have a File.SaveImage(image,file) , as a bitmap.  I know this is feature creep but would allow image manipulation and provide a gateway to printing.
    I don't think this feature would be useful to be "included" in Small Basic itself. You already can do that using an extension (my extension do the job, but it's possible to do the same thing with other extensions too).

    Maybe it would be great to have a "search" feature that allow to search "how to do" something. This search engine would return result from the SB's Refrence API or for any registered extension [an extension that has provided a download link and a documentation file]. Extensions would then be installable easily from Small Basic and will not be reserved to users that uses the forum and perform a search on it.



    Small question to Vijaye about that : It it possible for an extension to have localized help ?
    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension
    Friday, July 3, 2009 7:36 PM
  • I like the interactive help - if the content is good and properly maintained this can only be helpful.  I'm not sure what you have there, but perhaps it can link to a net resource that can be centrally maintained, updated and provide access to simple explanatory examples, step-by-step guides etc.

    An API is one thing, but more examples, guides and descriptive help is required and these haven't been written yet as far as I know.

    Many users don't use extensions, certainly not before they know about them or would have any use for them (by which time they are progressing to something else or writing their own) so I am most interested in getting the core SB as easy to use as possible.

    So the main point is writing and maintaining the content of quality help for the beginner - a help button is a good access point to this when it exists.
    Friday, July 3, 2009 8:00 PM
  • I like the interactive help - if the content is good and properly maintained this can only be helpful.  I'm not sure what you have there, but perhaps it can link to a net resource that can be centrally maintained, updated and provide access to simple explanatory examples, step-by-step guides etc.

    An API is one thing, but more examples, guides and descriptive help is required and these haven't been written yet as far as I know.

    Many users don't use extensions, certainly not before they know about them or would have any use for them (by which time they are progressing to something else or writing their own) so I am most interested in getting the core SB as easy to use as possible.

    So the main point is writing and maintaining the content of quality help for the beginner - a help button is a good access point to this when it exists.
    The content would be easily accessible on the small basic website.
    I don't know if you already have made an application on DotNet, but the comments are automatically compiled into an "help file". This help file is used in small basic to provide the API reference.

    If you look at the API reference I made for my extension (using the same system) you can see that it's possible to include samples. Thus, the system would entirely rely on the "help file" hosted on the Small Basic server. Currently, there's only "definition" of functions, but it would be possible for the dev team to include sample in the help file, so that they can be shown on the site.

    Here's a screen capture of the reference of my API (I built the site using SandCastle (I've made the Syntax Highlight for Small Basic myself as the language is not natively supported, I know the current result is imperfect, and I'll work on it to make it better, but you already can have a look of what can be a generated document based on a DotNet help file)) :





    BTW, I don't say the users need a big button "Install extensions here". I'm in favor of a very simple Small Basic for the beginner. But if the user search using the "Help" dialog, the search should also return results from extensions, if they exists. And if the user clicks on the result, it should be easy for them to install the extension needed to run the samples.

    For example, Small Basic don't let you to open two Graphics Windows, to maintain settings file, to use the clipboard, ... This is why my extension exists. I think it's a good thing that not all functions are included by default on Small Basic, so that beginners don't get disturbed by functions they don't want to use. I also think it's a good thing that extensions exits for users that want to use it. Both point of view are not incompatible :-)
    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension
    Friday, July 3, 2009 8:28 PM
  • I see what you are doing and agree that any extensions should naturally fall into whatever framework is adopted - easy for extension developers to maintain and users to activate help for whatever they are doing.

    I also agree that extensions are good (yours especially!), but not the core business of SB.

    My only issue is that, as I understand your model, the 'help resources' whatever form they take (samples, guides etc) are then integral to the installation and not a 'community resource' that can be continually updated and improved by those who want to add and improve it.  I assume that there are many people teaching and learning SB who could contribute to a structured knowledge base.  I guess I envisage some kind of documentation that has more structured content than we have currently, something more than an API, but maintained by the community at large.

    Perhaps the main idea is structured teaching content.

    How do I use arrays? - lots of explanation and examples.
    How do I use event? - lot of explanation and examples.
    My program crashes? - where do I start.
    My program doesn't do what I want? - where do I start.
    How do I start learning Small Basic? - some step-by-step tutorials.
    What is a subroutine?
    Recursion?
    When to and when not to use GoTo?
    .
    .
    .
    Friday, July 3, 2009 9:10 PM
  • My only issue is that, as I understand your model, the 'help resources' whatever form they take (samples, guides etc) are then integral to the installation and not a 'community resource' that can be continually updated and improved by those who want to add and improve it.  I assume that there are many people teaching and learning SB who could contribute to a structured knowledge base.  I guess I envisage some kind of documentation that has more structured content than we have currently, something more than an API, but maintained by the community at large.
    One thing doesn't exclude the other.

    You can look at the MSDN Library. You can download it, but most of us use it online. And they are now possibility for users to add comments, samples & ... to the (online) library. In the case of Small Basic, it could be possible for users to create responses to specifs questions, too.

    It's clear that "What is a subroutine ?" can't be resolved by an API search. The search engine should look both at the API and at the "user-constructed" help. And, give in priority results from the "constructed" help (even if the user should be able to filter content (users content: yes/no)). Both should be located on smallbasic.com. The search should use local files ONLY if there's no internet connection.
    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension
    Friday, July 3, 2009 9:30 PM
  • 1] Could we have comments a different colour than the commands (both green currently) - low priority.

    2] a = GraphicsWindow.GetPixel(-1,1) crashes - the idea was to see if I could store pixels outside the GraphicsWindow for image manipulation - low priority.
    • Edited by litdev Saturday, July 4, 2009 8:43 PM addition
    Saturday, July 4, 2009 3:25 PM
  • how about a function so the new programer can print out onto disk and then be able to take his or hers "program" / game and play it on the x box or sum other format.
    Tuesday, July 7, 2009 6:47 PM
  • Discussion about a proposal to allow Extensions in Small Basic :
    http://social.msdn.microsoft.com/Forums/en-US/smallbasic/thread/012d1ad9-b9fe-4ad9-9782-fbe6d6e40bc8/


    This would allow to create "libs"
    > The beginner can read to code of the lib, adapt it to its needs, if it's needed
    > This would be in the same language as its program, which is intuitive
    > It would allow to create objects
    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension
    Wednesday, July 8, 2009 2:52 PM
  • Then aren't you going to need to have parameter passing & local variables?
    Wednesday, July 8, 2009 7:34 PM
  • Then aren't you going to need to have parameter passing & local variables?
    Parameters : yes
    Local variables : no (at least, no other local variables than parameters)

    But we can have isolated Variables Pool. The variables declared in the extension "Extension.sb" would not be accessible in "MainProgram.sb"
    To make the two communicate, you should then use the objects's methode and functions (=declared subs) exposed by the Extension.

    ' Extension.sb

        X = 0
        Sub Extension.GetX()
          GetX = X
        EndSub
        Sub Extension.SetX(newX)
          X = NewX
        EndSub

    ' MainProg.sb

        Use "Extension.sb"    
        ' Load the Extension code
        ' Call the Extension._Main() sub

        Extension.SetX(Extension.GetX() + 1)
        ' X is not defined in this program

    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension
    Wednesday, July 8, 2009 7:44 PM
  • Another bug found:


    Shapes.AddImage("http://does.not.crash/")

    GraphicsWindow.ShowMessage("crash me","")

    Shapes.AddImage("http://crashes.immediately\")


    Backslash character in URL seems to be crashing SB app.


    Grzesio
    Thursday, July 16, 2009 4:29 PM
  • V0.6 enhancement idea:
    I would really appreciate that exceptions are displayed to the user. Nothing fancy, just a box showing the message and waiting for a button.
    My son got really confused when his program just vanished from screen and nobody was able to read anything.

    On the other hand this is a wonderul app to teach children programming! Keep up the good work!
    Friday, July 17, 2009 7:56 AM
  • V0.6 enhancement idea:
    I would really appreciate that exceptions are displayed to the user. Nothing fancy, just a box showing the message and waiting for a button.
    My son got really confused when his program just vanished from screen and nobody was able to read anything.

    On the other hand this is a wonderul app to teach children programming! Keep up the good work!
    Yes, it would be great to have a debugger.

    =====================================================
    Another thing that would be great is to have a MSI-Creator, so that people can
    generate an installer for their application. This could be very simple :
      - AppName (C:\ProgramFiles\{AppName})
      - Needed files (images, ...)
      - And... it's enough to create the installer ;-)

    I don't think this can be done for v0.6, but it could be great for a further release...

    =====================================================
    Also, please note I sometimes use Small Basic as 'batch language', as it's very easy
    to create a small programs (no need of references, no need of classes, no need of
    main sub, just revelant code).
    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension
    Friday, July 17, 2009 8:36 AM
  • I agree totally with litdev and bigdaddyo: Keep the language simple!

    I will repost what I have written before under the thread on ideas for SB 0.5:

    "There is a problem, though, with adding more advanced features to SB. There is a risk that the people that SB are intended for - young people and beginners - will be split into two groups; one group understand and use the advanced features and another group find the advanced features (like 2D-arrays) difficult and therefore discard them. A third group using the advanced features is the pros.

    Now, suddenly the second group that find the advanced features difficult is left behind. Suddenly they will see code on the net or written by their class mates that they find difficult and off putting, they might even feel intimidated. So by keeping SB simple there is a bigger chance that more people will enjoy SB. I certainly enjoy SB as it is, the simplicity simply fuels my imagination.

    Well, all this is of course speculations, I do not know what goes on in a beginners head. Maybe it is best to keep SB simple in the beginning and then see how it works for those the language is intended for."
    Monday, July 20, 2009 7:15 AM
  • I agree totally with litdev and bigdaddyo: Keep the language simple!




    YES!

    And allow to write extensions in more powerful (and dificult) languages. SB should be used by beginners. If they reach the limits - they can use extensions. Finally they _have_ to discover that this language is limited and try to switch to something more advanced.
    Grzesio
    Monday, July 20, 2009 7:40 AM
  • I agree totally with litdev and bigdaddyo: Keep the language simple!


    YES!

    And allow to write extensions in more powerful (and dificult) languages. SB should be used by beginners. If they reach the limits - they can use extensions. Finally they _have_ to discover that this language is limited and try to switch to something more advanced.
    I agree with you that beginners should not 'stay' on Small Basic. Small Basic is for learning programmation and batching (I use frequently Small Basic to permform small tasks, like rename file or folder using a special method).

    But I don't agree with you when you say that it would make Small Basic more difficult or more "advanced" if we allow to write "extension" in Small Basic.
    Basicly, you aren't introducing any new concept (parameters are already used in Small Basic, and even qBasic was supporting writing subs with parameters) nor new functionnalities (an extension written in Small Basic is only a way for the beginner to learn to REUSE code and to organise it into 'modules'/'objects'/'namespaces' (Small Basic have something that seems a middle way between all this). Currently, when you have to create a button in Small Basic, it's nearly impossible to do it easily withouth any extension.

    An SB plugin would be a good way to create a 'Button' object that would be simple to use, like Button.Add(...), but that would be written in Small Basic (onMouseMove event handling, finding the position of the cursor, comparing to the position of the button, ...). This is not as powerful as a .NET extension, but it learns to the beginners to write their own code, to use a code in more than one program, easily and withouth to have conflicts, and to make good use of parameters. My extension do the 'Button' job pretty good, as it allows to write 'normal' user interface with textboxes, checkboxes, buttons ..., but it 'hides' the arcanes to the user. It's not the intent of Small Basic to be just a 'Mashup' language. It can be a Mashup language, but it should provide a way for the user to 'write from scratch', and property.
    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension
    Monday, July 20, 2009 8:40 AM
  • It seems that extensions serve 3 purposes, I hadn't really appreciated point 2 below before Fremy's post.

    1] Allow users to use extension functionality provided by others such as buttons, music, extended shapes etc.

    2] Allow users to write their own library of functionality to then perform tasks using SB as an interface to dll functionality.

    3] As a steeping stone to VB, C# or C++, by writing simple extensions to SB.

    All of these are valuable, especially when users write their own or want more from SB and get interested in how more complex structured tasks may be achieved using bigger languages.  Extensions help to suggest what else is possible.

    However, the main SB environment benefits hugely from its simplicity and it is this that should be kept simple (pretty much as it is in terms of commands - perhaps debugging and more documentation as has been discussed before - additions that help new programmers with what there is rather than extend the language).  I think extensions on top of SB are a good way to encourage the next step when the basics are mastered and the limitations of SB become apparent, or to use SB as an interface to your own extensions.
    Monday, July 20, 2009 7:38 PM
  • I have been thinking about SB arrays a little.

    Since SB arrays are really dictionaries, if we want to loop through the elements in array we need to set the first dimension as an index.

    For i = 1 To 10
      balls[i] = Shapes.AddEllipse(20,20)
    EndFor

    We can then loop:

    For i = 1 To Array.GetItemCount(balls)
      ball =
    balls[i]
      Shapes.Move(ball,20+i*20,50)
    EndFor


    However this casues difficulties when we delete an item:

    Shapes.Remove(balls[5])
    balls[5] = ""
    For i = 1 To Array.GetItemCount(balls)
      ball = balls[i]
      Shapes.Move(ball,20+i*20,50)
    EndFor

    To handle this we have to 'shuffle up' the indexes to be contiguous - e.g. the discussion on Asteroids.

    Perhaps we should have some sort of iterator to access all of the elements of a list in a loop. 

    There are lots of ways this could be done, but it seems to me that perhaps the best is to distinguish between an array (always indexed) and a list (not indexed but can be looped through using iterators).

    Combining both concepts as it is at present has a reduced command syntax (good) and can achieve everything we might want for arrays or lists (good), but does cause problems as described above (bad) - conceptually lists and arrays are different ideas and combining these into one command can lead to confusion and ugly code.

    Just a discussion point - not a request of any sort.
    • Edited by litdev Sunday, August 2, 2009 1:10 PM
    Sunday, August 2, 2009 12:51 PM
  • Another option is to have a Array.GetValues(array) function that returns the values of the array, with the 0...Count-1 as indexes. To help beginners, we could have an alias of GetValues that do the same thing but that we can call Array.Reindex(array).

    Samples :

    ==

       Arr["Hello"] = 0
       Arr["Test"] = 1

       Arr = Array.GetValues(arr)
       ' Arr: {'0':0, '1':1}

    ==

       Arr[0] = 0
       Arr[1] = 0
       Arr[2] = 1
       Arr[1] = Null ' (delete the item)

       Arr = Array.GetValues(Arr)
       ' Arr: {'0':0, '1':1}

    ==
    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension
    Sunday, August 2, 2009 1:01 PM
  • BTW a List (Object+Type) is a great suggestion. But maybe too complex to have in v0.6.
    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension
    Sunday, August 2, 2009 1:03 PM
  • Can someone confirm this bug :

        TextWindow.WriteLine("'"+Text.GetSubText("abcd", 0, 3)+"'")
        is showing nothing, instead of 'abc'.

    If this bug is confirmed, this is a major bug to fix for v0.6.
    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension
    Tuesday, August 4, 2009 4:18 PM
  • Tried this on smallbais 0.51 and the output is ' '.

    If I change the 0 to 1 then output is 'abc'.
    Tuesday, August 4, 2009 5:18 PM
  • Tried this on smallbais 0.51 and the output is ' '.

    If I change the 0 to 1 then output is 'abc'.

    Ok, thanks. In DotNet, strings are 0-indexed. So it seemed to me normal using 0 as 'since start' flag. It seems that Small Basic perform a '-1' operation, so that 0-1 -> -1, which is not a valid index. This throws an error, the error is recovered silently by returning "". This seems logical.
    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension
    Tuesday, August 4, 2009 5:21 PM
  • I have been thinking about SB arrays a little.

    Since SB arrays are really dictionaries, if we want to loop through the elements in array we need to set the first dimension as an index.

    For i = 1 To 10
      balls[i] = Shapes.AddEllipse(20,20)
    EndFor

    We can then loop:

    For i = 1 To Array.GetItemCount(balls)
      ball =
    balls[i]
      Shapes.Move(ball,20+i*20,50)
    EndFor


    However this casues difficulties when we delete an item:

    Shapes.Remove(balls[5])
    balls[5] = ""
    For i = 1 To Array.GetItemCount(balls)
      ball = balls[i]
      Shapes.Move(ball,20+i*20,50)
    EndFor

    To handle this we have to 'shuffle up' the indexes to be contiguous - e.g. the discussion on Asteroids.

    Perhaps we should have some sort of iterator to access all of the elements of a list in a loop. 

    There are lots of ways this could be done, but it seems to me that perhaps the best is to distinguish between an array (always indexed) and a list (not indexed but can be looped through using iterators).

    Combining both concepts as it is at present has a reduced command syntax (good) and can achieve everything we might want for arrays or lists (good), but does cause problems as described above (bad) - conceptually lists and arrays are different ideas and combining these into one command can lead to confusion and ugly code.

    Just a discussion point - not a request of any sort.

    litdev,  I've added a new operation GetAllIndices, that returns all the keys in another packed array.  Hopefully that'll help the case in discussion.
    Wednesday, August 5, 2009 12:54 AM
  • litdev,  I've added a new operation GetAllIndices, that returns all the keys in another packed array.  Hopefully that'll help the case in discussion.
    It is a solution, but it's not very intuitive. This also has the problem that the indices may be in a random number, not a numerically sorted order.

    Fremy - Developer in VB.NET, C# and JScript ... - Feel free to try my extension
    Wednesday, August 5, 2009 9:11 AM
  • Thanks,

    If this allows us to loop through a non-indexed (key) array I think that should help - a key array has no order so the order returned by GetAllIndeces doesn't matter as long as we can access them all within a For i = 1 To ... loop.

    I guess the objective is to be intuitive and with limited commands - I also think not changing anything too much is good.  Every language has ways of doing things and if this SB's then fine.  With a few examples people will soon use it easily.

    Wednesday, August 5, 2009 6:09 PM
  • Consider this excerpt:

     

    TextWindow.Write("Please enter your age: ")
    
    age = TextWindow.ReadNumber()

     

    Every Small Basic user who understands this code understands procedures, but they are being held back by not letting them define their own.

    The goto and label statements should be dropped.  They take away from the language.  Including these concepts as "easier" only makes sense if you don't have built-in functions and subroutines, but Small Basic does have them.  The users already have to learn the concepts of passing arguments and returning results from functions. Allowing users to define their own parameters and include return statements just explains what has been going on with built-in functions.  It doesn't introduce any new concepts or require any more of them than before.

    Goto and label statements should be dropped for three big reasons.  1) They encourage bad programming habits that have little to do with modern coding practices.  2) They are hard to manage and introduce bugs--which is why they have little to do with modern programming practices.  3) They actually INTRODUCE additional complexity into small basic. Right now, we have built-in procedures, labels and goto statements, and subroutines that fit somewhere in the middle.  Allowing full strength subroutines would eliminate the need for goto entirely, simplify the language, and also make it more powerful.

    Here is my proposal:

    1) Drop goto and label

    2) Add lexically scoped arguments (replaces label) -- remember, they are already using arguments for built-ins (e.g. TextWindow.WriteLine)

    3) Add return statements (replaces goto) - remember, they are already returning values for built-in functions (e.g. TextWindow.ReadNumber)

     

    I think this would make the language better and also more likely for current programmers to reccommend it when people ask what language to teach newcomers


    Clay

     

    Monday, October 11, 2010 11:24 AM