Date   

Re: SQLite For BBC Basic

Richard Russell
 

I disagree, but it won't achieve anything to argue the point.

I've uploaded an initial attempt at a library (ODBCLIB.BBC), and a test/demonstration program (ODBCTEST.BBC), to the Files area of this group as odbclib.zip.  I should say that two days ago I had not the slightest idea about databases and how to access them, so these have been cobbled together in a very short time from information gleaned from the web (which luckily is extensive).  Literally anybody could have done this.

Richard.

Re: SQLite For BBC Basic

 

Richard,

It's a shame you didn't choose to write your own ODBC library .....

It was not so much a matter of choice. The idea of using a database approach to solve my problem never came out of the conceptual stage. I seem to remember that I searched for SQLLite, found some bits and pieces but no (clear) documentation and/or programming examples. Pls. don't take this all too literally, this is already a distant memory. But bottom line : at the time this potential solution, that never came to fruition,  was way above my programming skills and I resorted to a simpler solution being a file reading/writing approach in conjunction with Excel with the help of COMLIB. And it worked fine.

would you (or somebody else) be prepared to test it?
Short answer : Yes
Long answer : 

I have never worked with SQL, databases (yes, once, but it was not a success), ODBC and the likes. I wouldn't know where to start. I occasionally use a saw and a screwdriver. That doesn't make me a carpenter. The same goes for my programming skills. Sometimes I surprise myself by writing a really nice program. But all in all you would be horrified looking at my code. On the bright side :  I'm having fun.
All the above just to make you aware  that, while I'm prepared to help out in testing the ODBC library, you may end up disappointed. Therefore others better participate to come to useful test results.


FYI :  I have Excel 2007 and LibreOffice Base on my PC. No Oracle or other sofisticated databases.

Eddy

Re: SQLite For BBC Basic

 

Sure. Just sling it across and I shall try and fit in some time to test it.
Cheers,
Chandra

Re: SQLite For BBC Basic

Richard Russell
 

On Mon, Oct 16, 2017 at 01:30 am, Edja wrote:
A year or so ago I had a need for it but had to find a simpler, less flexible/less powerfull solution
It's a shame you didn't choose to write your own ODBC library, which you could have shared with the rest of us!  From the experimentation I've done so far, ODBC is perfectly straightforward to interface with in BBC BASIC (no pesky COM/OOP functions or anything like that, just ordinary C-style functions which can be trivially converted to SYS statements).  There's lots of code examples on the web that can be translated to BBC BASIC 'methodically' without needing any understanding.

Anyway, if I write a simple ODBC library - even though anybody else could do it - would you (or somebody else) be prepared to test it?  I have no personal experience of working with databases so although I can translate the code I can't devise test routines to exercise it thoroughly.

Richard.

Re: SQLite For BBC Basic

 

Richard,

though at this moment I have no immediate use for the ODBC library, I definitely would have used it in the past. A year or so ago I had a need for it but had to find a simpler, less flexible/less powerfull solution to deal with my data.

I think the ODBC library really would be an asset to the BB4W programming environment in general (and for my own future programming needs)

regards,
Eddy


On Sunday, October 15, 2017, 11:26:50 PM GMT+2, Richard Russell <news@...> wrote:


On Fri, Oct 13, 2017 at 05:50 am, Richard Russell wrote:
Can you confirm that an ODBC library would meet your needs?
Well?  I have confirmed that an ODBC library would be able to access a SQLite database, but if there is no interest I won't pursue it any further.

Richard.

Re: SQLite For BBC Basic

 

Many thanks Richard for chipping in on this thread.
For me yes indeed. An ODBC library would be ideal indeed.
Many thanks for the offer.

Re: SQLite For BBC Basic

Richard Russell
 

On Fri, Oct 13, 2017 at 05:50 am, Richard Russell wrote:
Can you confirm that an ODBC library would meet your needs?
Well?  I have confirmed that an ODBC library would be able to access a SQLite database, but if there is no interest I won't pursue it any further.

Richard.

Re: SQLite For BBC Basic

Richard Russell
 

I expect Jon's library simply provided a wrapper around the SQLite function calls to present a rather more 'BASIC-like' interface, so whilst its loss may be an inconvenience it's not something that actually prevents the use of SQLite with BBC BASIC.

Assuming that SQLite is ODBC-compliant, which I'm pretty confident it is with the right drivers, my suggestion would be to go the ODBC route rather than to write any code which is specific to one particular database manager.  For a long time an ODBC library for BBC BASIC has been on the 'wish list' and it should not be difficult to write.  If somebody would like to volunteer to do that it would be useful, but if not I'll do it myself!

Can you confirm that an ODBC library would meet your needs?

Richard.

Re: SQLite For BBC Basic

 

Same issue from me too!
I guess there is nobody at home on this subject matter.

Re: BBCSDL poll #poll

J.G.Harston
 

I've downloaded the Linux version, but haven't had the chance to reboot my PC into Linux yet. I'm planning on testing the Raspberry Pi version, but my Pi is currently being a PiTube and I don't have a minitor for it.

BBCSDL poll #poll

Richard Russell
 

Have you tried 'BBC BASIC for SDL 2.0' (BBCSDL) and if so on what platform(s)?  You can select more than one answer.

Results

See Who Responded

Re: Stripping LF's from end-of-record

Martin G0HDB
 

Hi again Richard, thanks for the reminder that when using GET$#file TO &A the resulting string will still contain a CR as its last character.  I had realised this and wondered what the effect might be, but it doesn't seem to have any because the rest of my program only reads up to byte 290 in the string that's now 291 bytes long, including the final CR.

Nevertheless, to be on the safe side I might adopt the remedy of using LEFT$(GET$#file TO &A) to strip off the final CR so that the input string will only ever be 290bytes long and won't contain any control characters; I'll have a play with it to see what happens and if it makes any difference to the rest of my program.

Thanks again,

--
Martin

Re: Stripping LF's from end-of-record

J.G.Harston
 

Richard Russell wrote:
It would perhaps be appropriate to remind people of the FNREADLINE()
function listed at the Wiki [1] which will correctly read a record
Catching up on this, some time ago I used the agnostic readline function in code to translate the end-of-line characters in a text file into whatever I specified. The core code is:


REM in$=input file
REM out$=output file
REM eol%: 1=CRLF, 2=LFCR, 3=CR, 4=LF
in%=OPENIN(in$):IF in%=0:PRINT"File '"in$"' not found":PROCexit(214)
out%=OPENOUT(out$):IF out%=0:PRINT"Can't save '"out$"'":PROCexit(192)
REPEAT
BPUT#out%,FNrd(in%);
IF eol% AND 1:BPUT#out%,13
IF eol% AND 6:BPUT#out%,10
IF eol%=2:BPUT#out%,13
UNTIL EOF#in%
CLOSE#out%:out%=0
CLOSE#in%:in%=0
PROCexit(0)


DEFFNrd(I%):LOCAL A$
A$=GET$#I%:IFA$="":IFPTR#I%>1:PTR#I%=PTR#I%-2:IFBGET#I%<>BGET#I%:A$=GET$#I%
=A$

--
J.G.Harston - jgh@... - mdfs.net/jgh

Re: Stripping LF's from end-of-record

Richard Russell
 

On Sun, Oct 8, 2017 at 03:17 am, Martin G0HDB wrote:
I'm pleased to report that using the GET$# function works beautifully in my program
Hopefully this is obvious, but if you use GET$#file TO &A with a file having CRLF terminations, the resulting string will contain a CR as its last character (since you have told it to read everything up to, but excluding, the LF).  This can easily be remedied using, for example, LEFT$(GET$#file TO &A) which strips off the last character - a useful special case of LEFT$ - but is something to be borne in mind.

Richard.

Re: Stripping LF's from end-of-record

Martin G0HDB
 

Hi folks, just a quick update and to say thank you again for the advice and guidance provided, especially by Richard.

I'm pleased to report that using the GET$# function works beautifully in my program, which no longer creates a blank ADIF record for the final LF in the input file.

I haven't tried the FNreadline() function; I might have a play with it sometime for future reference!

Also, thanks to Neil for the reminder that a file edited with eg. Notepad must include a final CR/LF.  I don't envisage ever having a need to edit any of the input files that my program uses, but if ever I do I'll bear in mind the need to hit 'Enter' at the end of the final line in the file.

--
Martin

Re: Upgrade BBC Windows #upgrade

Richard Russell
 

On Sat, Oct 7, 2017 at 03:11 am, Horst Dieter wrote:
What is the different between full version and trial ? With my version (6.02 a) I can compile my basic programs.
That and the memory limit - in the trial version only a maximum of 32 Kbytes are available for the BASIC program, heap and stack (compared with 512 Mbytes in the full version).

I can think of only one possible explanation for the strange symptom you are experiencing.  Both the BB4W IDE and the Upgrade program first check for the Serial Number in HKLM (HKEY_Local_Machine) and if not found there they check for it in HKCU (HKEY_Current_User).  However they perform this two-stage check slightly differently: the Upgrade program only checks in HKCU if the HKLM key is missing, but the BB4W IDE will check in HKCU additionally if the HKLM key is present but empty.

So, although this is unlikely, if your machine has a valid Serial Number in HKCU but an empty value in HKLM it could result in what you are reporting.  I don't know how that situation could arise, but I suggest you check the registry contents yourself to see if that is indeed the case.  Re-installing the full version ought to update the registry anyway, but  believe you have already tried that?

Richard.

Re: Upgrade BBC Windows #upgrade

 

What is the different between full version and trial ? With my version (6.02 a) I can compile my basic programs.

Horst


Am 06.10.2017 um 23:10 schrieb Richard Russell:
On Fri, Oct 6, 2017 at 12:07 pm, Horst Dieter wrote:
the return code is 2. How do I see that the trial version is installed?
It's OK to have both trial (free) and full (paid for) versions installed: I used to do that - with two different desktop shortcuts - so that I could easily test programs with either of them.  If you reinstall the full version it will create the registry entry that seems to be missing.

What I can't understand, however, is that without the Serial Number being present in the registry the full version should not run, yet you said it was running OK.  Something doesn't add up.

Richard.

-- 
Mit freundlichen Grüßen
 
SBL Büro- und Industriebedarf
Katharina Lehra
Maschweg 36
32479 Hille
 
Telefon: 05734/512036
Fax:   05734/6377
Email: SBL@...
Steuernummer: 335/5984/6288
Finanzamt Minden
 

Re: Upgrade BBC Windows #upgrade

Richard Russell
 

On Fri, Oct 6, 2017 at 12:07 pm, Horst Dieter wrote:
the return code is 2. How do I see that the trial version is installed?
It's OK to have both trial (free) and full (paid for) versions installed: I used to do that - with two different desktop shortcuts - so that I could easily test programs with either of them.  If you reinstall the full version it will create the registry entry that seems to be missing.

What I can't understand, however, is that without the Serial Number being present in the registry the full version should not run, yet you said it was running OK.  Something doesn't add up.

Richard.

Re: Upgrade BBC Windows #upgrade

 

Thank you Richard,

the return code is 2. How do I see that the trial version is installed?


Horst



Am 06.10.2017 um 13:49 schrieb Richard Russell:
On Fri, Oct 6, 2017 at 04:08 am, Horst Dieter wrote:
First I got the message
and then
Blank and blank?  Not terribly helpful!

If the upgrade fails, it should display a message box saying "Unable to perform upgrade (n)" where the number in parentheses indicates the cause of the failure as follows:

  1. The key 'HKCU\Software\R T Russell\BBC BASIC for Windows' is missing from the registry.
  2. The registry sub-key 'Serial' is missing, this is likely to mean that the trial version is installed rather than the full version.
  3. The Serial Number / Registration Key is not valid.  This should not be possible if the full version runs.
  4. The run-time engine BBCWRUN6.EXE cannot be opened; it has possibly been deleted or quarantined by a virus scanner.
  5. The run-time engine BBCWRUN6.EXE cannot be read; the file is perhaps empty or truncated.
  6. The run-time engine BBCWRUN.EXE appears to be corrupted.
  7. The upgrade program UPGRADE.EXE itself cannot be opened, possibly it has been deleted or quarantined. 
  8. The file BBCWIN.NEW cannot be created; this may mean you are not running 'as administrator'.
  9. The file BBCWRUN.NEW cannot be created; this may mean you are not running 'as administrator'.
I have not published this list before on the grounds that it provides information that may be useful to a hacker.  Please do not distribute or publish it outside this forum.

Richard.

-- 
Mit freundlichen Grüßen
 
SBL Büro- und Industriebedarf
Katharina Lehra
Maschweg 36
32479 Hille
 
Telefon: 05734/512036
Fax:   05734/6377
Email: SBL@...
Steuernummer: 335/5984/6288
Finanzamt Minden
 

Speed comparison x86 versus ARM

Richard Russell
 

I have recently acquired a new smartphone, which is one of the fastest currently available (the OnePlus 5, using a Snapdragon 835 CPU). I thought it would be interesting to compare the speed of BBCSDL running on that with it running on an Intel Core i7 clocked at about 2.8 GHz.

I should add that of course the comparison here is not just between CPUs but between an interpreter written in hand-crafted assembler code (x86) and one compiled from C source (ARM). That is why the speed ratios are so variable depending on the nature of the operation performed.

It's also important to appreciate that the ARM has no 80-bit floats (BBCSDL uses 64-bit floats instead) so figures listed as being for that data type cannot be meaningfully compared.

As you will see from the linked results, the ARM is typically between 2 and 4 times slower than the x86, but really such a relatively small factor is remarkable in the circumstances. Not only that, but a few of the timing tests actually show the ARM running at a comparable speed to the x86, and in one case (NEXT N#) actually faster!!

I must say I find the results surprising and it really shows how ARM performance has improved, even though it is still a relatively low-power CPU. It also suggests the C compiler is doing a good job. I could speed up the ARM version even more by stripping out all the code which handles 80-bit floats, but I don't want to do that.

Richard.