Next version number

[chrisws]

One of the many podcasts I like to listen to is "This Week in Linux".

https://tuxdigital.com/thisweekinlinux/

In the past couple of episodes, he mentions long term projects that are stuck with a 0.n.n version number.

So instead of calling the next version of SmallBASIC 0.12.19, I'm considering making the first digit > 0.

Calling it 1.0 doesn't seem right. But then I thought, how about 20.0, is that too pretentious? The project has been around for about that many years.

What do you think?

[bplus]

? "SmallBASIC " + (right("0.12.19", 5))

i.e. just drop the "0.", that will keep continuity with the older versions.

[chrisws]

? "SmallBASIC " + (right("0.12.19", 5))

i.e. just drop the "0.", that will keep continuity with the older versions.

I like

I've been (very) slowly working from this list: https://github.com/smallbasic/SmallBASIC/issues

Hopefully I've captured everything that's been discussed in this forum.

Cheers,
Chris

[bplus]

@chisws

Man, If you can get 64 bit working through the Tabbed Editor... 

(Here I just vent, if you don't need that don't worry about it, but it is feedback from one user / fan)
Very frustrating for me personally is the complete closing of SmallBASIC when I hit the top right X box.
I am in habit of writing a line testing editing or writing the next. In QB64, I have to close the Run \ "Output window" before (well not actually, it's just that I don't need 10 different versions running at same time...) before going back to editor. I know the way back for SB is just a right mouse click and then another (with built in editor), it's just not habit. It is handy to have output window there while making edits. What makes it super frustrating is when I accidentally X out of a run the code hasn't been saved, sometimes I might get a warning about save but I have lost so much that I have to go back and write again ugggh. Do that twice in a row and well... it's not fun! Sure it's my problem, it's also my choice which Basic I pick to work and thank goodness there are still good choices one can make, none are perfect. When I first started SB you had tabbed file editor and I dropped my search for better Basic but I wonder if I encountered SB later with the built-in editor? Would I even be here now? probably not.

[Aurel]

Very frustrating for me personally
oh no 

[chrisws]

@chisws

Man, If you can get 64 bit working through the Tabbed Editor... 

(Here I just vent, if you don't need that don't worry about it, but it is feedback from one user / fan)
Very frustrating for me personally is the complete closing of SmallBASIC when I hit the top right X box.
I am in habit of writing a line testing editing or writing the next. In QB64, I have to close the Run \ "Output window" before (well not actually, it's just that I don't need 10 different versions running at same time...) before going back to editor. I know the way back for SB is just a right mouse click and then another (with built in editor), it's just not habit. It is handy to have output window there while making edits. What makes it super frustrating is when I accidentally X out of a run the code hasn't been saved, sometimes I might get a warning about save but I have lost so much that I have to go back and write again ugggh. Do that twice in a row and well... it's not fun! Sure it's my problem, it's also my choice which Basic I pick to work and thank goodness there are still good choices one can make, none are perfect. When I first started SB you had tabbed file editor and I dropped my search for better Basic but I wonder if I encountered SB later with the built-in editor? Would I even be here now? probably not.

Are you talking about the fltk version or the sdl version?

In the sdl version clicking [X] does function the same as typing Control + b

I'll try to include a 64 bit build of the fltk version in the next release.

Cheers,
Chris

[bplus]

Are you talking about the fltk version or the sdl version?

I am really talking about editors.
I was talking favorably for/about the FLTK version editor from 2014 when I first discovered SB, with the tabbed editor that you have brought back and whining about the built-in editor with Sdl? of later year. Sdl probably had many graphics advantages and the built-in editor was certainly an interesting novelty but...

A 64 bit version would mean not only a return but an advancement from FLTK of 2014. With that, you could edit and run by tabbing the window along with tabbing to help, it was/is again nice! One less hurdle for newbies as well.

Yeah, sorta see myself as defender of newbies, seems to me as a programming language that it is Basic's niche, after all the B in Basic does stand for Beginner's. Add all the bells and whistles you like in your Basic but keep it easy for Beginners to Edit and Run their novice programs. That is where, IMO, JB/LB blew it with beginners, there is steep learning curve to just setup a graphics Window or eventually understand all nuances or options made with Template setup for graphics window and syntax for those graphics windows isn't as easy as QB was/is and SB was/is. With JB/LB without window setup, you can only run a B&W very long scrolling "console" screen called mainwin but no color, lines, boxes or circles and no INKEY$ (but you can run multiple windows in one program, I think that was the trade off decision Carl made long ago with his Basic branch). Does Python (a supposedly beginner's PL) have that? no, another hurdle to setup graphics.

[lettersquash]

That's Numberwang!

...For those who don't get the reference ... https://www.youtube.com/watch?v=ZH-cXBhkl-E

I just got round to reading this thread - congratulations on going from 0 to 12! I wondered why the odd change. Quite right too.

I agree with bplus, sB is quite a treasure, not only among BASICS, but among several other common languages. As well as the short learning curve for newbies, the ease of syntax and the power of its structures (maps in particular) makes it a great way to prototype things that I might later port to another language.

As you suggest, bplus, simplicity is often underrated. Adding features is great if they don't cause confusion. My language of choice for some Windows-integrated, more API-dependent programs is AutoHotkey, and I've just started porting my incomplete current sB project to it, but the syntax is more than a little awkward, and using the equivalent of a map in SmallBASIC is an Object, which is also much more compicated to use. I also have to use GDI+ functions to create a graphics screen, and that's a bit of a nightmare too, even though there's a module with all the functions to include. It has too many hangovers from when it started as purely a Windows automation tool. My other sometimes useful option is BBC BASIC for Windows, which also suffers from a hangover, not reinventing itself enough to fit with Windows programming, although not a BBC BASIC emulator either. A simple oddity makes graphics strangely annoying - it has graphics units that are half the size of actual graphics pixels, or the other way round, and I'm endlessly doubling or halving and then getting it backwards.

I had some struggles early on with sB, like my confusion over POINT values, but once learned they make sense. I've just been plumbing the depths of what maps can do, how to address different levels, etc., which was a challenge too, but the logic is fine once you get it. And of course there's the fact that you can run it on Linux and Android too.

[Aurel]

I also have to use GDI+ functions to create a graphics screen, and that's a bit of a nightmare too,

are you sure is GDI+ or just GDI
because GDI is freakin simple also GDI+ is juat little bit more resource hungry and is simple too.
i use both in Oxygen

[lettersquash]

I also have to use GDI+ functions to create a graphics screen, and that's a bit of a nightmare too,

are you sure is GDI+ or just GDI
because GDI is freakin simple also GDI+ is juat little bit more resource hungry and is simple too.
i use both in Oxygen

GDIplus
Well, of course, something simple for you might be difficult for me. I haven't done a lot with it, because the examples I found were a bit baffling, but I recently got some help and it's become a little less obscure. However, what I obviously meant is in comparison to SmallBASIC, which gives you a graphics output screen without doing anything, AutoHotkey requires you to define one, which takes a number of steps. Let's compare, something like drawing a yellow line and printing some white text on the graphics screen:

In SmallBASIC, it might be something like:

Code: [Select]

line x, y, x1, y1, rgb(255,255,0)
at x2, y2:? "Hello"That's it (apart from defining x, x1, y and y1. Run it and it's there, done. (Also, if you want the logical colours, you can just use 14 instead of the rgb.)

In AHK, first we have to start GDI+

Code: [Select]

pToken := Gdip_StartUp()...assuming it's on our system, or we have to check first if we don't know. Then, we create a bitmap and get its pointer:

Code: [Select]

pBitmap := Gdip_CreateBitmap(W, H)
Then, we get a pointer to the graphics thingumajig :

Code: [Select]

G := Gdip_GraphicsFromImage(pBitmap)
To draw a line, we need a pen, defining its color:

Code: [Select]

pen := Gdip_CreatePen("0xFFFFFF00", 1)
(We do have ARGB and width, however.)

And then we draw with it, yay!

Code: [Select]

Gdip_DrawLine(G, pen, x, y, x1, y1)
The text routine does allow us to define a few more options:

Code: [Select]

Options = x%x% y%y% cFFffFFff r4 s20 Underline ItalicAnd then we plug those into our text_to_graphics routine:

Code: [Select]

Gdip_TextToGraphics(G, "Hello", Options, "Arial")
We should also remember to do a good amount of deletion (pens, brushes, etc.) to manage the memory, and have an Exit subroutine that closes GDIp before exiting the app.

Other than that, it's a piece of cake.

Some of the additional options could be imitated in sB with more programming, like I think someone wrote a routine to do italic text and/or rotate and size it. But "out of the box", sB is quick and easy to write most things. Admittedly, as you've pointed out, it doesn't have (much? any?) access to Window APIs, and the graphics environment isn't as refined (angular lines are a little more blocky, etc., from my experiments, unless I'm not using the right antialiasing setting).

[chrisws]

I also have to use GDI+ functions to create a graphics screen, and that's a bit of a nightmare too,

are you sure is GDI+ or just GDI
because GDI is freakin simple also GDI+ is juat little bit more resource hungry and is simple too.
i use both in Oxygen

GDIplus
Well, of course, something simple for you might be difficult for me. I haven't done a lot with it, because the examples I found were a bit baffling, but I recently got some help and it's become a little less obscure. However, what I obviously meant is in comparison to SmallBASIC, which gives you a graphics output screen without doing anything, AutoHotkey requires you to define one, which takes a number of steps. Let's compare, something like drawing a yellow line and printing some white text on the graphics screen:

In SmallBASIC, it might be something like:

Code: [Select]

line x, y, x1, y1, rgb(255,255,0)
at x2, y2:? "Hello"That's it (apart from defining x, x1, y and y1. Run it and it's there, done. (Also, if you want the logical colours, you can just use 14 instead of the rgb.)

In AHK, first we have to start GDI+

Code: [Select]

pToken := Gdip_StartUp()...assuming it's on our system, or we have to check first if we don't know. Then, we create a bitmap and get its pointer:

Code: [Select]

pBitmap := Gdip_CreateBitmap(W, H)
Then, we get a pointer to the graphics thingumajig :

Code: [Select]

G := Gdip_GraphicsFromImage(pBitmap)
....

This could all be wrapped into a SmallBASIC module (as per raylib etc) by someone suitably motivated.