| Search Results |
Total results: 10 |
| 1 |
General Board
/ Re: Conforums Closing on April 15th |
on: Yesterday at 09:55am |
| Started by CryptoMan | Post by Richard Russell |
on Mar 30th, 2018, 9:37pm, CryptoMan wrote:| Do you have plans to move this board to an alternate location as CONFORUMS is closing? |
|
I'm unsure: my main concern is with the BBC BASIC forum (and wiki) which are more active and more important (to me!) so they are occupying most of my time. To prevent cybersquatting I reserved lbbooster.proboards.com yesterday but I may not activate it; at least it's there if we need it.
Activity at this forum is very low, particularly recently. Preservation of the wiki is probably more important than the forum, and with Wikispaces closing in a few months that's also a worry. I'm hoping - as was the case at Wikispaces latterly - that the LBB wiki may be able to hang on the coat-tails of the BBC BASIC wiki.
Richard.
|
  
|
| 4 |
General Board
/ (OT) BBC BASIC for Android and iOS |
on: Mar 28th, 2018, 5:56pm |
| Started by Richard Russell | Post by Richard Russell |
Since LBB works by translating the Liberty BASIC program to BBC BASIC, it may be of interest that both Android and iOS editions of BBC BASIC are now available. The recent release of the iOS edition completes the 'set' of supported Operating Systems: Windows, Linux (x86), Mac OS-X, Raspberry Pi (Raspbian), Android and iOS.
As noted previously, converting GUI-based Liberty BASIC programs to run on an OS other than Windows is problematical (at least, if a reasonable degree of compatibility is to be achieved) because LB/LBB simply provide a 'thin wrapper' around native Windows GUI features.
But non-GUI ('mainwin') LB programs should be relatively easily ported to any of the Operating Systems supported by BBC BASIC, so long as they don't use CALLDLL to access Windows APIs/DLLs which have no direct equivalent in the other OSes.
Richard.
|
|
|
| 5 |
Liberty BASIC language
/ Re: LBB Macro capability |
on: Mar 15th, 2018, 4:44pm |
| Started by k6dgw | Post by k6dgw |
OK. I'll have to rethink some plans, but I think I can make this work. Thanks
|
|
|
| 6 |
Liberty BASIC language
/ Re: LBB Macro capability |
on: Mar 15th, 2018, 09:53am |
| Started by k6dgw | Post by Richard Russell |
on Mar 14th, 2018, 10:07pm, k6dgw wrote:| Does LBB have a macro capability like the "define" statement often placed in header files in C? |
|
Not as such. The example you gave is not of a macro but of a constant declaration (#define can be used for both purposes).
Most BASICs (Liberty BASIC is no exception) don't have named constants, and variables must be used instead. You can adopt a naming convention (I tend to use all CAPITALS for constants) to remind you that the variable actually represents a constant and should not be altered - but unlike a true constant there's nothing stopping you.
Variables used this way will generally need to be GLOBAL, of course, so the closest approximation in LB/LBB to #define, when used to declare a constant, is:
Code: global NROWS, NCOLS
NROWS = 100
NCOLS = 7
Macros are another issue however; Liberty BASIC has no real equivalent to macros. In some limited circumstances you may be able to leverage the EVAL function to give a similar effect, but this is not ideal.
Richard.
|
|
|
| 7 |
Liberty BASIC language
/ Re: LBB Macro capability |
on: Mar 15th, 2018, 04:20am |
| Started by k6dgw | Post by RobM |
I'm not sure if it is the same idea but there is the "Let" command.
Code:
Let NROWS=100
Let NCOLS=7
dim datarec(NCOLS, NROWS)
for i=1 to NROWS
for j=1 to NCOLS
blah
blah
blah
next j
next i
|
|
|
| 8 |
Liberty BASIC language
/ LBB Macro capability |
on: Mar 14th, 2018, 10:07pm |
| Started by k6dgw | Post by k6dgw |
Does LBB have a macro capability like the "define" statement often placed in header files in C? Hypothetical example:
define NROWS=100
define NCOLS=7
dim datarec(NCOLS, NROWS)
for i=1 to NROWS
for j=1 to NCOLS
blah
blah
blah
next j
next i
Tks,
Fred
|
|
|
| 10 |
General Board
/ Re: Encryption |
on: Mar 11th, 2018, 11:30am |
| Started by PabloSl | Post by Richard Russell |
on Mar 11th, 2018, 05:40am, RobM wrote:| This is caused by have two structs with the same name but different data types. Change one of the names and it should work. |
|
Indeed. Two such similar structures, with the same name and the same member name, but one being unsigned and the other signed, seems unlikely to be deliberate:
Code:struct a, pDataLen as ulong
struct a, pDataLen as long
The original author should probably be informed of the anomaly in case it is a mistake.
Richard.
|
|
|
|
