Author |
Topic: The future of LBB - please read (Read 3264 times) |
|
Richard Russell
Administrator
member is offline
 
Posts: 1348
|
 |
The future of LBB - please read
« Thread started on: Jan 8th, 2014, 4:14pm » |
|
LB Booster has reached something of a milestone, in that it is now being used 'seriously' rather than being just a novelty. Two large commercial applications (one of around 14,000 lines of Liberty BASIC code and the other consisting of over 100,000 lines of code in three modules) have recently been ported to LBB.
I am now starting to think about how LBB should be developed (if at all), and I would greatly value some feedback on the subject. It seems to me that there are five directions in which I might consider extending it:
Additions to the Liberty BASIC language. For example it ought to be possible to support 3-dimensional arrays, e.g. array(x,y,z), or arrays of structures.
Extensions to the Graphical User Interface, for example new controls such as a List View / Grid control or native toolbars and status bars.
Aids to debugging (currently almost totally absent in LBB, although TRACE is partially implemented). For example Run to Cursor, Single Step or the ability to list variable values at run time.
New compiler directives, such as conditional compilation (e.g. %if, %endif) or 'compiler constants' (e.g. %define) to allow different versions of a program to be built.
Improvements to the IDE, such as syntax colouring, automatic indentation or aids to navigation. To an extent 'LB Workshop' (which integrates well with LBB) can already satisfy this need.
Of course I'm not suggesting that these are 'mutually exclusive' - in an ideal world they could all be addressed - but realistically I need to know which would be most valuable to users so I can prioritise the work.
What do you think? Which, if any, of these options would you prefer me to concentrate on? Or are there things I haven't thought about which ought to be added to the list?
Richard.
|
|
 Logged
|
|
|
|
Phineas Freak
New Member
member is offline
Gender: 
Posts: 18
|
|
Re: The future of LBB - please read
« Reply #1 on: Jan 8th, 2014, 5:29pm » |
|
I hope that you will implement everything from that list, especially the additions and/or extensions. Compiler directives should be next.
IDE improvements and debugging tools can be postponed until later since it's possible to write the code with an external editor and debug it via LB (at least for LB-compatible code).
Unfortunately you mentioned everything that i would like the most from LBB and i don't have enough imagination to suggest possible additions to these ideas. So i will just give it a huge "thumbs up" and wish you luck! 
|
|
Logged
|
|
|
|
Richey
New Member
member is offline
Posts: 14
|
|
Re: The future of LBB - please read
« Reply #2 on: Jan 8th, 2014, 11:28pm » |
|
Richard, I'm not knowledgeable enough to give a totally informed opinion but what PreciseTiming has suggested seems reasonable to me.
|
|
Logged
|
|
|
|
CirothUngol
New Member
member is offline
Odie, Odie, cha cha cha.
Gender:
Posts: 44
|
|
Re: The future of LBB - please read
« Reply #3 on: Jan 9th, 2014, 02:13am » |
|
Well, this is certainly fun!
I've been writing my programs to be LBB compatible ever since I found this app over a year ago. Now with the recent inclusion of really-large-string support any remaining incompatibilities should be fairly minor bugs, and I'm glad you're thinking about expanding your Booster's capabilities.
Let' see...
I would expect most users to vote for 1 and 2, because either would directly expand the language itself and everyone likes new toys! Additional or improved GUI widgets would probably bring the most interest from current Liberty BASIC users who have yet to move over to LB Booster (but of course, 3+ dimensional arrays\structs would also be nice).
However, if explicit changes or additions are made to the language itself, then items 3 and 5 go from the "nice convenience" category to the "nearly necessary" category because there won't be any other software\IDE that one could use to properly display or debug the new code. So it's rather like a double-whammy... if you do either 1 or 2, it drastically increases the need for 3 and 5.
Now with all that said, I would have to admit that item 4, New Compiler Directives, might actually be the best choice in a "time vs. effort", bang-for-your-buck sorta way. It wouldn't really require an IDE or debugger, so it could easily be fashioned to appear as a comment in other IDEs allowing you to provide this exclusive functionality without breaking syntax.
Finally, my vote is for item 3. Even without other IDE enhancements, a -D command-line option for a debugger would allow for the use of LibertyBASIC Workshop for the rest of the IDE. The inclusion of a proper debugger for LBBooster would probably be the option that I personally would use the most. It may also be a logical first-step to expanding the language itself... it would be needed.
|
|
Logged
|
LB Booster + LB Workshop + LB Builder = My Programs on Google Drive
|
|
|
tsh73
Full Member
member is offline
Gender:
Posts: 210
|
|
Re: The future of LBB - please read
« Reply #4 on: Jan 9th, 2014, 04:34am » |
|
I have an idea that looks like small thing in (1), but as always may prove to be huge 
(and of course I have no idea if it is big or small)
It is extending EVAL to
1) support user-defined functions
2) somehow allow to ASSIGN thing named in a string.
Just my 0.02$ 
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: The future of LBB - please read
« Reply #5 on: Jan 9th, 2014, 09:45am » |
|
on Jan 9th, 2014, 04:34am, tsh73 wrote:It is extending EVAL to
1) support user-defined functions |
|
As you know, the compatibility of LBB's EVAL with LB is in any case limited, and there's not a great deal I can do about that.
However you can actually take advantage of the incompatibility in this case: if you prefix the name of the user-defined function with FN (this tells LBB that it's a function call rather than a reference to an array) it will actually work! For example:
Code: a = 1.2345
print Secant(a)
print eval("FNSecant(a)")
end
function Secant(a)
Secant = 1 / COS(a)
end function
Quote:| 2) somehow allow to ASSIGN thing named in a string. |
|
You can take advantage of the same 'feature' to achieve that now as well:
Code: var$ = "abc"
num = 5.4321
dummy = eval("FNassign(";var$;",";num;")")
print abc
end
function assign(byref n, v)
n = v
end function
These are hardly 'extensions' to LBB, they are just 'accidental' functionality, but they work!
Richard.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: The future of LBB - please read
« Reply #6 on: Jan 9th, 2014, 10:54am » |
|
on Jan 9th, 2014, 02:13am, CirothUngol wrote:| I would expect most users to vote for 1 and 2, because either would directly expand the language itself and everyone likes new toys! |
|
In practice they haven't, perhaps because, like you, they worry about the debugging implications if their code becomes incompatible with LB.
Whilst I certainly recognise the validity of that concern, I don't personally feel that implementing (1) or (2) necessarily implies implementing (3) as well. Although LBB lacks a debugger, run-time error messages often include the line number, and of course adding temporary debugging code to the program itself (such as printing variable values to the mainwin) can be very helpful in locating a fault.
Quote:| Now with all that said, I would have to admit that item 4, New Compiler Directives, might actually be the best choice |
|
That is looking to be the consensus, both here and on the Yahoo group. What directives would be most valuable?
Quote:| it could easily be fashioned to appear as a comment in other IDEs allowing you to provide this exclusive functionality without breaking syntax. |
|
I had anticipated extending the syntax used for the existing %mode directive, so it wouldn't be compatible with LB, but then I assume the directives (e.g. conditional compilation) will usually be essential for creating a valid program anyway so if LB ignored them the code still wouldn't run.
Quote:| a -D command-line option for a debugger would allow for the use of LibertyBASIC Workshop for the rest of the IDE. |
|
LBB does recognise the -D command line switch, for compatibility with LBW, but currently it just loads the program and waits, so you can take advantage of the limited 'manual' debugging facilities currently available.
Richard.
|
|
Logged
|
|
|
|
David P
Guest
|
|
Re: The future of LBB - please read
« Reply #7 on: Jan 20th, 2014, 10:51pm » |
|
Hi,
Will LB Booster's editor be as powerful as BBC Basic for Windows' editor in the future?
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: The future of LBB - please read
« Reply #8 on: Jan 20th, 2014, 11:24pm » |
|
on Jan 20th, 2014, 10:51pm, Guest-David P wrote:| Will LB Booster's editor be as powerful as BBC Basic for Windows' editor in the future? |
|
The two editors are very different: the BB4W editor is entirely custom code, which allows for things like 'live' indentation, whereas the LBB editor is a standard Windows RichEdit control, which means it supports more mouse commands, a wider range of fonts etc.
So depending on what particular features you are interested in you may consider the BB4W editor to be more, or less, powerful than the LBB editor! Because of their incompatible implementations, they are bound to remain quite different.
I might have been interested in using Scintilla for the LBB editor (rather as LB Workshop does) but I particularly want to retain support for bi-directional text (e.g. Arabic or Hebrew strings) and, as I understand it, Scintilla doesn't do that.
Richard.
|
|
Logged
|
|
|
|
bluatigro
Full Member
member is offline
Gender:
Posts: 111
|
|
Re: The future of LBB - please read
« Reply #9 on: Jan 28th, 2015, 09:51am » |
|
i wood like :
- OOP : operator overloading
- %ifnotdefined
- %define
- %endif
- nested 'include
- pi , true , false as global consts [ whit diferent color ]
- open gl + consts [ whit diferend color ]
- 4 axel joystick reading + more buttens
- wireles com [ bluetooth or wifi ]
- sprites :
- "spriteimage? spr img$"
- "spritescalexy spr x y"
- "spritescalexy? spr x y"
- "spritehit? spr whitspr bool"
- "spriterotate spr deg"
- "spriterotate? spr deg"
- numbers in diferent color
- &hff type numbers
|
| « Last Edit: Jan 28th, 2015, 10:07am by bluatigro » |
Logged
|
|
|
|
cbrescia
New Member
member is offline
Gender:
Posts: 1
|
|
Re: The future of LBB - please read
« Reply #10 on: Jan 28th, 2015, 5:31pm » |
|
I think that compatibility with LB4 should be kept, however, on the other hand, LBB could add and enhance the language and tools.
Add new GUI components could create added value for the product.
For example having a "RealNumber, realvar" component could be a big difference with any compiler I knew.
I think Microsoft considers subclassing and filtering the edit component one of the most natural things to do, but since I work daily with real numbers, not "numbers" with alphanumerics from 0...9, to me is not. And I never saw a language with a GUI for real numbers input. Think of it as a small 1x1 Grid. That's why my first choice for rapid programs calculations is a spreadsheet!
A LBB with this option would be my first choice.
It is just an idea.
|
|
Logged
|
|
|
|
Jack Kelly
Full Member
member is offline
Gender:
Posts: 106
|
|
Re: The future of LBB - please read
« Reply #11 on: Feb 7th, 2015, 06:25am » |
|
I vote for #5, improvements to the IDE. That is where we spend most of our time. I have looked at LB Workshop, but have not embraced it yet. I really don't want to add another layer to my working environment.
|
|
Logged
|
|
|
|
SarmedNafi
Junior Member
member is offline
Posts: 93
|
|
Re: The future of LBB - please read
« Reply #12 on: Feb 7th, 2015, 5:58pm » |
|
> Extensions to the Graphical User Interface, for example new controls such as a List View / Grid control or native toolbars and status bars.
I prefer to insert this extensions indeed, it will be a big jump over LB, I will leave LB behind me and go faster with LBB.
Each time Richard say that then he fold back for some reasons.
I hope this time will be the big band of LBB.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: The future of LBB - please read
« Reply #13 on: Feb 7th, 2015, 9:03pm » |
|
on Feb 7th, 2015, 5:58pm, SarmedNafi wrote:| > Extensions to the Graphical User Interface, for example new controls such as a List View / Grid control or native toolbars and status bars. |
|
This thread is very old; there is a gap of more than a year between reply #8 and reply #9! So whilst it is interesting to get responses after such a long time, bear in mind that a lot of water has passed under the bridge since then. In particular see the thread Winding down LBB for a change of direction.
So, although one should never say never, I think it's now very unlikely that LBB will ever be extended to incorporate native List View or Grid controls.
Richard.
|
|
Logged
|
|
|
|
SarmedNafi
Junior Member
member is offline
Posts: 93
|
|
Re: The future of LBB - please read
« Reply #14 on: Feb 8th, 2015, 02:40am » |
|
Well,
Richard are they available on BBC?
|
|
Logged
|
|
|
|
|
