User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Mon Dec 10, 2018 1:35 pm

Heater wrote:
Mon Dec 10, 2018 9:55 am
I created a github repository to hold solutions to the fibo(4784969) challenge.

https://github.com/ZiCog/fibo_4784969

Having spent so much messing with this I thought it was time to make it a project.

It's a bit of a mess at the moment. Probably has some junk in it. I'd like to include all the solutions presented here if that is OK with everyone. Plus other interesting bits of code that have popped up in this thread.

So far we only have working solutions in Python, Javascript, and C.

Still waiting on my sorting out my C++ solution (or someone else perhaps) and which ever BASIC dialect DavidS is working on.
That works now. As of last month RISC OS now has a git client, so those that wish to look at the BASIC versions will be able to.

May I recommend putting the BBC BASIC V/BBC BASIC VI versions in there correct format, instead of text conversions, please. While on the forum we have to convert to text the tokenized versions can be put on github making it less hasle to run/compile for anyone that looks at them.

The JS conversion I am doing in BASIC is BBC BASIC VI as that has 64-bit floats, and uses the VFP/NEON.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

jahboater
Posts: 4598
Joined: Wed Feb 04, 2015 6:38 pm

Re: Why Avoid BASIC on RPi?

Mon Dec 10, 2018 2:03 pm

Visual Basic is on the up ...
https://www.tiobe.com/tiobe-index//

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Mon Dec 10, 2018 2:13 pm

jahboater wrote:
Mon Dec 10, 2018 2:03 pm
Visual Basic is on the up ...
https://www.tiobe.com/tiobe-index//
It frustrates me when people point at VB and call the moddern usage BASIC.

It is true that VB is capable of using BASIC code, though it is also capable of not using BASIC code at all and only using its extensions (other than operators, which do not find a language much). The majority that program in VB produce code that has as much in common with BASIC as BASIC has in common with Delphi. As such I would not call the way VB is used almost universally BASIC in any way shape or form.

It is possible to produce code in VB using only those features that it shares with BASIC PDS 7.1 (the last extension of QuickBasic), then it would be BASIC. Though the way VB is used it is not BASIC.

It is more interesting that Assembly language is number 12 on the list, would expect it to be higher.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Heater
Posts: 13080
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Mon Dec 10, 2018 2:47 pm

DavidS,
That works now. As of last month RISC OS now has a git client, so those that wish to look at the BASIC versions will be able to.
I don't believe that BASIC is exclusive to RISC OS.

Users without git can always look at the source on the github site. And download it as individual files or a zip archive.

Glad to hear RISC OS has caught up with 2005!
May I recommend putting the BBC BASIC V/BBC BASIC VI versions in there correct format, instead of text conversions, please. While on the forum we have to convert to text the tokenized versions can be put on github making it less hasle to run/compile for anyone that looks at them.
I have read that over a few times and I still don't understand what you are saying.

Git and github are for source code. Source code is plain text in ASCII or perhaps some unicode encoding today, typically utf-8. You know, the stuff humans read and write. The stuff we post to forums.

Whatever tokenizing ones BASIC may do is implementation dependent. Like the various binaries one can get by compiling C code for whatever machine.

As such BASIC tokens and such have no place in a source code repository.

Besides, anyone that wants such tokenized code will already have the BASIC system required to run it. So what is the point?

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Mon Dec 10, 2018 2:58 pm

Heater wrote:
Mon Dec 10, 2018 2:47 pm
DavidS,
That works now. As of last month RISC OS now has a git client, so those that wish to look at the BASIC versions will be able to.
I don't believe that BASIC is exclusive to RISC OS.

Users without git can always look at the source on the github site. And download it as individual files or a zip archive.

Glad to hear RISC OS has caught up with 2005!
May I recommend putting the BBC BASIC V/BBC BASIC VI versions in there correct format, instead of text conversions, please. While on the forum we have to convert to text the tokenized versions can be put on github making it less hasle to run/compile for anyone that looks at them.
I have read that over a few times and I still don't understand what you are saying.

Git and github are for source code. Source code is plain text in ASCII or perhaps some unicode encoding today, typically utf-8. You know, the stuff humans read and write. The stuff we post to forums.

Whatever tokenizing ones BASIC may do is implementation dependent. Like the various binaries one can get by compiling C code for whatever machine.
Nope.

In BBC BASIC V on RISC OS, Brandy BASIC on other systems, Other BBC BASIC implementations, anything that is compatible with BBC BASIC at all the source code is tokenized the same way, and is the way the source is distributed even between platforms.
As such BASIC tokens and such have no place in a source code repository.

Besides, anyone that wants such tokenized code will already have the BASIC system required to run it. So what is the point?
It is the standard way to distribute the source for any BBC BASIC V compatible interpreter or compiler for any platform, that is the point.

In BBC BASIC V on RISC OS, Brandy BASIC on other systems, Other BBC BASIC implementations, anything that is compatible with BBC BASIC at all the source code is tokenized the same way, and is the way the source is distributed even between platforms.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Heater
Posts: 13080
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Mon Dec 10, 2018 3:37 pm

DavidS,
Nope.

In BBC BASIC V on RISC OS, Brandy BASIC on other systems, Other BBC BASIC implementations, anything that is compatible with BBC BASIC at all the source code is tokenized the same way, and is the way the source is distributed even between platforms.
...
It is the standard way to distribute the source for any BBC BASIC V compatible interpreter or compiler for any platform, that is the point.

In BBC BASIC V on RISC OS, Brandy BASIC on other systems, Other BBC BASIC implementations, anything that is compatible with BBC BASIC at all the source code is tokenized the same way, and is the way the source is distributed even between platforms.
Sorry I still don't get it.

I've done BASIC. Back in 1972. The source was what we typed into an ASR 33 teletype. It was saved in ASCII on paper tape. Loaded from those paper tapes. That ASCII on paper tape was shared around between us as the only way to share files we had !

I've done BASIC. On the ATARI ST in 1985. By this time things had advanced. BASIC source was shared around on floppy discs. Again in ASCII.

If BASIC source cannot be published and shared between coders in plain text, then what was all that happening in the 1980's? Computer magazines were full of it.

Whatever, there will be no non-human readable content in my git repo. It needs to be readable by anyone passing by who most likely won't have the particular machine or the particular BASIC engine.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Mon Dec 10, 2018 3:47 pm

Heater wrote:
Mon Dec 10, 2018 3:37 pm
DavidS,
Nope.

In BBC BASIC V on RISC OS, Brandy BASIC on other systems, Other BBC BASIC implementations, anything that is compatible with BBC BASIC at all the source code is tokenized the same way, and is the way the source is distributed even between platforms.
...
It is the standard way to distribute the source for any BBC BASIC V compatible interpreter or compiler for any platform, that is the point.

In BBC BASIC V on RISC OS, Brandy BASIC on other systems, Other BBC BASIC implementations, anything that is compatible with BBC BASIC at all the source code is tokenized the same way, and is the way the source is distributed even between platforms.
Sorry I still don't get it.

I've done BASIC. Back in 1972. The source was what we typed into an ASR 33 teletype. It was saved in ASCII on paper tape. Loaded from those paper tapes. That ASCII on paper tape was shared around between us as the only way to share files we had !

I've done BASIC. On the ATARI ST in 1985. By this time things had advanced. BASIC source was shared around on floppy discs. Again in ASCII.
Not in ASCII for Atari BASIC, it was tokenized on floppy. Also for most 8-bitters.
If BASIC source cannot be published and shared between coders in plain text, then what was all that happening in the 1980's? Computer magazines were full of it.
You are talking about the difference between sharing the source file (eg. github) versus publishing it in print form (like the listings on the forums). Even in the 1980's the on disk versions were tokenized for the kind of BASIC they worked with, the print versions you had to type in.

The trouble comes in that when you do a TEXTLOAD in BASIC it is often that the text file contains some characters that BASIC does not like (this goes for just about any BASIC that uses a traditional style interpreter). This can cause very frustrating issues.

Now if you make sure that the text files are saved from the BASIC prompt using TEXTSAVE I would not see a problem, though something tells me that you are not doing that.
Whatever, there will be no non-human readable content in my git repo. It needs to be readable by anyone passing by who most likely won't have the particular machine or the particular BASIC engine.
ASCII is not human readable without something to convert it.

If they are looking at BBC BASIC V code on ANY system it is human readable for them.

As I stated if you want it in ASCII format then make sure you generate the ASCII by using the TEXTSAVE command at the basic prompt. Then it will be usable universally and be in ASCII.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Mon Dec 10, 2018 3:57 pm

@Heater:
Does your lack of human readable form mean that you will not track the results of the game creation challenge made by ejolson?

As his challenge specifically specifies that it be graphical, mouse driven and modernized. This will show the differences between OS's and implementations on a significant scale.

This will also require the use of data-files that are most defiinitely not human readable, and never had a human readable form (like window templates, and OS native graphics files, etc).

So I am guessing you avoid anything that is GUI driven going into your repo, unless it can be done completely in ASCII (sometimes possible, often not)?


Again using TEXTSAVE is a solution for BBC BASIC source.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Heater
Posts: 13080
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Mon Dec 10, 2018 4:18 pm

DavidS,
Not in ASCII for Atari BASIC, it was tokenized on floppy. Also for most 8-bitters.
Well, I have never used any BASIC program that did not arrive as human readable text.
You are talking about the difference between sharing the source file (eg. github) versus publishing it in print form (like the listings on the forums).
What difference?

It may have escaped your notice but the overwhelming majority of humans have been exchanging text in ASCII, and now some kind of unicode for many decades. Even before the was a BASIC.
Even in the 1980's the on disk versions were tokenized for the kind of BASIC they worked with, the print versions you had to type in.
Excactly. Tokenized BASIC programs were distributed. They are not source. If you don't have the BASIC engine to decode it you cannot read it.
The trouble comes in that when you do a TEXTLOAD in BASIC it is often that the text file contains some characters that BASIC does not like (this goes for just about any BASIC that uses a traditional style interpreter). This can cause very frustrating issues.
That is not a problem. If you don't post any BASIC source with such troublesome characters in it then they won't be there. Git/github is not going to add them. What you write is what you get.
Now if you make sure that the text files are saved from the BASIC prompt using TEXTSAVE I would not see a problem, though something tells me that you are not doing that.
What is telling you that? I haven't done anything in BASIC for decades.
ASCII is not human readable without something to convert it.
Hmmm....interesting point...

You know what, I think it is. Given a lot of ASCII text, as holes punched in tape, or dots printed on a page, I bet one would be able to understand it, given an ASCII look up table.

Soon one would learn all the patterns and not need the lookup table. Just read the holes/dots.

It's a bit like saying Morse code is not human readable or those brail dots the blind can read are not human readable. For sure they are.

But anyway, so what? We all have something to present ASCII such that we can read it. Just read on the github web page or open it in your favorite editor.
As I stated if you want it in ASCII format then make sure you generate the ASCII by using the TEXTSAVE command at the basic prompt. Then it will be usable universally and be in ASCII.
I will bear that in mind. However, I'm not doing this fibo in BASIC, you are!

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Mon Dec 10, 2018 4:26 pm

Or if you are using the !Zap text editor in RISC OS to enter the source you can just do a dump to text from the menu to convert to a working ASCII text listing that can be loaded with TEXTLOAD. Dumping to text from !Zap is how I provided the text to save into the posts where I have posted BASIC source code on the forums.

It is frustrating that text editors on other systems do not directly deal with the tokenized forms of BASIC available on the systems. This should be something standard for a text editor, as people write BASIC programs in text editors, and has been standard on RISC OS for a long time (I think that the standard GUI based text editor did this all the way back to Arthur OS if memory serves, been a long time [Authur OS was the name for RISC OS before RISC OS 2]).

The GUI based text editor built into the OS ROM (from RISC OS 3.1 on) has this ability, it is called !Edit. Every text editor on RISC OS has been able to do this.

Why are other OS's so far behind, that they can not even have the simplest of things for there standard utilities? There are only 4 tokenized BASIC's still in common use and available for most of the modern systems, so it would not be difficult to support this.

It is as bad as the fact that most OS's still rely on file extension for file type, and some rely on knowledge of the content of the file (unix magic numbers) to determine the file type. This was a good way back in the 1960's and 1970's though we moved on to filesystems that include FileType metadata (like RISC OS, Macintosh System Software, and others). Then there is the lack of a reasonable way for most systems to keep the resources of a program orginized (Resource sections of NE/PE exes, files scattered all over, or in dirrectories shared among many apps for things specific to only one app) that is lacking in most modern systems, at least Macintosh System Software had the Resource fork, and RISC OS has the Application type directory (filetype 0x2000) that normally runs the application contained within, requiring a modified open to get at the contents (holding down shift). I do note that ROX Desktop copied the idea of the application directory as did macOS X though neither of thos are really modern OS's in all ways (they have modern applications though old concepts of the OS underneath, and ROX is just a desktop environment).

So why is it that the advance concepts of OS's like RISC OS and others are left behind in favor of the worse less usable ways that predate the personal computer?

Sorry you got me on a bit of a RANT. Next time maybe it will be about EBCD vs ATSCI vs ASCII vs PETSCII vs UTF-8 vs UniCode.
Last edited by DavidS on Mon Dec 10, 2018 4:36 pm, edited 1 time in total.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Mon Dec 10, 2018 4:32 pm

Heater wrote: That is not a problem. If you don't post any BASIC source with such troublesome characters in it then they won't be there. Git/github is not going to add them. What you write is what you get.
Just posting it into the forum adds some of these troublesome charactors, unfortunately.

I guess I could post a copy of the ASCII source in a Zip file to get around the issue?
Hmmm....interesting point...

You know what, I think it is. Given a lot of ASCII text, as holes punched in tape, or dots printed on a page, I bet one would be able to understand it, given an ASCII look up table.

Soon one would learn all the patterns and not need the lookup table. Just read the holes/dots.

It's a bit like saying Morse code is not human readable or those brail dots the blind can read are not human readable. For sure they are.
Brail is human readable, so is morse code (I use both regularly, I am an amature radio operator, and I have some blind freinds). They are both designed to be human readable.

Though as to automatically decoding the binary form, as your example with ASCII I could make the same argument for tokenized BASIC source code.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Mon Dec 10, 2018 4:34 pm

So again is it acceptable to post Zip files to keep the forum from adding characters that BASIC does not like while presenting it in ASCII form?
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Heater
Posts: 13080
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Mon Dec 10, 2018 4:45 pm

No ZIP files required. Or even desirable

I'm sure the source is short enough it can be posted here without having to bother with compression.

Plus it's nice if people can just read the code in a code box in a forum post. As has been done with other fibo solutions here.

Now that there is git for RISC OS there is a better way:

Just clone the fibo_4784969 challenge repository, add you code to it and make a pull request via github. Then I can pull it to my repo. No text will get damaged by git along the way.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Mon Dec 10, 2018 5:02 pm

Heater wrote:
Mon Dec 10, 2018 4:45 pm
No ZIP files required. Or even desirable

I'm sure the source is short enough it can be posted here without having to bother with compression.

Plus it's nice if people can just read the code in a code box in a forum post. As has been done with other fibo solutions here.

Now that there is git for RISC OS there is a better way:

Just clone the fibo_4784969 challenge repository, add you code to it and make a pull request via github. Then I can pull it to my repo. No text will get damaged by git along the way.
Let me be more specific, when posting on the forum I feel it would be better to include both the inline text and a zip so that the non-mangled by the forum version is still available along with the readable listing.

Also it will be needed for the challeng by ejolson in order to include any OS native graphics and other non-ASCII text content that is required for that challenge to be met.

Though I am seriously considering just using a BASIC that does not care, like FreeBASIC and thus making it less expressive and more convoluted than I could in ARM BASIC.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Heater
Posts: 13080
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Mon Dec 10, 2018 5:06 pm

DavidS,
Or if you are using the !Zap text editor in RISC OS to enter the source ...
I see a problem here. A vanishingly small number of people are doing that or even know what it is.
It is frustrating that text editors on other systems do not directly deal with the tokenized forms of BASIC available on the systems....
Why are other OS's so far behind, that they can not even have the simplest of things for there standard utilities?
This cannot be a serious question, can it?

You want every ones text editor and all kind of other programs to support an encoding that nobody uses?
It is as bad as the fact that most OS's still rely on file extension for file type, and some rely on knowledge of the content of the file (unix magic numbers) to determine the file type. This was a good way back in the 1960's and 1970's though we moved on to filesystems that include FileType metadata (like RISC OS, Macintosh System Software, and others). Then there is the lack of a reasonable way for most systems to keep the resources of a program orginized (Resource sections of NE/PE exes, files scattered all over, or in dirrectories
I of course have to differ on that.

File type meta data and resource forks are silly.

How are you ever going to post that to a forum post or a git repo or anywhere else? The meta data gets lost.

A file that is an executable on your machine may just be a binary blob on mine. Can't execute ARM binaries on x86, can not run RISC OS apps on Windows. (Emulation and virtualization aside)

A file name is meta data. It's not the data itself, its a name attached to it. Ergo putting the file type, ".txt", ".exe", ".sh" into a file name extension is reasonable.

Similarly, having a file describe itself, with magic numbers or such is also quite reasonable. Perhaps better, that self-meta data always goes wherever the file goes.
Last edited by Heater on Mon Dec 10, 2018 5:09 pm, edited 1 time in total.

Heater
Posts: 13080
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Mon Dec 10, 2018 5:09 pm

DavidS,
Let me be more specific, when posting on the forum I feel it would be better to include both the inline text and a zip so that the non-mangled by the forum version is still available along with the readable listing.
Sounds good.

It would be nice to end up with something that can go into github as something to show for all this discussion.

Meanwhile, I'm back to my C++ solution....

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Mon Dec 10, 2018 5:17 pm

WOW:
Filetype metadata does not get lost over the net, even without extensions. So long as the server is setup up correctly this is the reason for MIME types that are a standard accross all OS's for use over the net.

Unfortunately most OS's do not have a way to store this metadata, so it is the OS and its FS implementations that are backwards not the abiltiy to share the type online, there is a system in place for that.

And as to OS's that do that correctly:
  • RISC OS uses a filetype number in its metadata.
  • Macintosh System Software uses a 4 byte filetype in its metadata.
  • BeOS/Haiku OS use the MIME type in there metadata.
There are others. Though all the filetypes can be represented as a MIME type over the net, so no loss for sharing.

As to Resource forks I agree with you, to a point on sharability. This is why I also mentioned the Application Directory as used by RISC OS and copied by others. The application directory is a good way of keeping resources together and orginized, without requiring any special tools for dealing with them. N*x just says do not orginize reasonably, Win* just says put many in the NE/PE requiring many tools, put others in random places without good sense, and stuff some stuff in the reg that does not belong there. The application directory is a good solution, it takes care of the issues of orginizing resources, as well as the issue of keeping everything sharable.

Resource forks were a good idea, though ahead of there time (now we can share multi stream files without issue).
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Heater
Posts: 13080
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Mon Dec 10, 2018 5:41 pm

DavidS,
WOW:
Filetype metadata does not get lost over the net, even without extensions. So long as the server is setup up correctly this is the reason for MIME types that are a standard accross all OS's for use over the net.
You mean these MIME types: https://developer.mozilla.org/en-US/doc ... MIME_types

Clearly the file extension is just a short hand for the MIME type. Kind of pointless really. Except when delivering content that perhaps did not even come from a file and has no file name or extension. Like a live video stream for example. Then telling the receiver what to do with it using a MIME type is required.

For sure MIME types can get lost and confused or deliberately set wrongly for malicious purposes.
And as to OS's that do that correctly:
RISC OS uses a filetype number in its metadata.
Macintosh System Software uses a 4 byte filetype in its metadata.
BeOS/Haiku OS use the MIME type in there metadata.
Hmmm.. if that is all you are talking about, may as well just add those few bytes to the file name. For example:

myTextFile.txt.2348

Where ".txt" tells humans what it is. ".2348" is whatever number or characters your proposed system uses as a file type.

Oh, wait, we could use the MIME type instead of some OS specific number:

myTextFile.txt.text/plain

Oh wait, MIME types have a slash in them, can't have that in a file name. How about:

myTextFile.txt.text-plain

Oh wait now we have "txt" and "text" that is silly. What about just:

myTextFile.text-plain

Hmm... that is a bit long winded. What about just:

myTextFile.txt.

Hmmm... Much nicer.

:)

ejolson
Posts: 3399
Joined: Tue Mar 18, 2014 11:47 am

Re: Why Avoid BASIC on RPi?

Mon Dec 10, 2018 6:43 pm

Heater wrote:
Mon Dec 10, 2018 9:55 am
I created a github repository to hold solutions to the fibo(4784969) challenge.
It is fine with me to include my fibonacci.c program written in ANSI C and my fibo.bas program written in FreeBASIC. If new versions of those codes get posted on this forum I would appreciate if you also update the repository as I will not be using anything like a pull request. Woohoo! My code will be preserved for all eternity.

Another thing that the Karatsuba and Fibonacci experts posting to this thread might enjoy is solving some of the relevant programming contest questions on the Sphere Online Judge.

User avatar
rpdom
Posts: 14985
Joined: Sun May 06, 2012 5:17 am
Location: Chelmsford, Essex, UK

Re: Why Avoid BASIC on RPi?

Mon Dec 10, 2018 7:18 pm

DavidS wrote:
Mon Dec 10, 2018 4:26 pm
The GUI based text editor built into the OS ROM (from RISC OS 3.1 on) has this ability, it is called !Edit. Every text editor on RISC OS has been able to do this.
Even TWIN? That's the editor I used to start with with ARM based systems. It didn't (AFAIK) tokenise anything. BASIC files were just text and were simply imported into BBC BASIC which handled the tokenisation.

timrowledge
Posts: 1273
Joined: Mon Oct 29, 2012 8:12 pm
Location: Vancouver Island
Contact: Website

Re: Why Avoid BASIC on RPi?

Mon Dec 10, 2018 7:32 pm

Aaaaaaargh! Nightmare triggers! No Twin, no Twin, please noooooooooh.
I had to use that until we got the first Smalltalk running and made a decent editor possible. Apparently my brain still has the bruises. After more than 30 years...
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

ejolson
Posts: 3399
Joined: Tue Mar 18, 2014 11:47 am

Re: Why Avoid BASIC on RPi?

Mon Dec 10, 2018 7:44 pm

The claim made by a programmer that text files are human readable is similar to the claim made by a Christian that nothing can be done without God. In both cases words have been omitted that make it necessary for the listener to ignore the literal meaning and infer the real meaning. The real meaning of these expressions can be made clear by putting the omitted words back in. For example, "nothing can be done without God" means "nothing of eternally lasting value can be done without God." Similarly, "text files are human readable" actually means "text files are human readable using standard general-purpose tools." The question remains, however, whether being able to read text files using general-purpose tools has eternal value.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Mon Dec 10, 2018 9:42 pm

Heater wrote:
Mon Dec 10, 2018 5:41 pm
DavidS,
WOW:
Filetype metadata does not get lost over the net, even without extensions. So long as the server is setup up correctly this is the reason for MIME types that are a standard accross all OS's for use over the net.
You mean these MIME types: https://developer.mozilla.org/en-US/doc ... MIME_types

Clearly the file extension is just a short hand for the MIME type. Kind of pointless really. Except when delivering content that perhaps did not even come from a file and has no file name or extension. Like a live video stream for example. Then telling the receiver what to do with it using a MIME type is required.

For sure MIME types can get lost and confused or deliberately set wrongly for malicious purposes.
And as to OS's that do that correctly:
RISC OS uses a filetype number in its metadata.
Macintosh System Software uses a 4 byte filetype in its metadata.
BeOS/Haiku OS use the MIME type in there metadata.
Hmmm.. if that is all you are talking about, may as well just add those few bytes to the file name. For example:

myTextFile.txt.2348

Where ".txt" tells humans what it is. ".2348" is whatever number or characters your proposed system uses as a file type.

Oh, wait, we could use the MIME type instead of some OS specific number:

myTextFile.txt.text/plain

Oh wait, MIME types have a slash in them, can't have that in a file name. How about:

myTextFile.txt.text-plain

Oh wait now we have "txt" and "text" that is silly. What about just:

myTextFile.text-plain

Hmm... that is a bit long winded. What about just:

myTextFile.txt.

Hmmm... Much nicer.

:)
Point missed. The point is no need to use file extensions at all when that metadata can be stored in the filesystem directly, especially nice when you have a GUI with Icons for the types and/or a nice color display in the console then you just have:

myTextFile

No need to have that whole .txt clutter on the end, and its type is visually obvious (as well as easy for programs to determine). We do not live in the 1960's or early 1970's here, so why should we have clutter from that ancient history that serves us no purpose since the introduction of filetype information stored by the FS seperate from the filename (I think it was in the late 1970's that that began at a level that could be useful).

Or should we all go back to using RT/11 for our operating system, and Mini Computers that take up the entire corner of a room consuming more power than the rest of the house and capable of up to 10MIPS using only 16-bit integer operations? That is the timeframe of using extensions to identify the file type.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Mon Dec 10, 2018 9:47 pm

rpdom wrote:
Mon Dec 10, 2018 7:18 pm
DavidS wrote:
Mon Dec 10, 2018 4:26 pm
The GUI based text editor built into the OS ROM (from RISC OS 3.1 on) has this ability, it is called !Edit. Every text editor on RISC OS has been able to do this.
Even TWIN? That's the editor I used to start with with ARM based systems. It didn't (AFAIK) tokenise anything. BASIC files were just text and were simply imported into BBC BASIC which handled the tokenisation.
TWIN is not GUI based. So no not TWIN. And to run TWIN on newer version of RISC OS requires using !GraphTask to support the old screen mode.

I did say GUI based text editors.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
rpdom
Posts: 14985
Joined: Sun May 06, 2012 5:17 am
Location: Chelmsford, Essex, UK

Re: Why Avoid BASIC on RPi?

Mon Dec 10, 2018 9:58 pm

DavidS wrote:
Mon Dec 10, 2018 9:47 pm
TWIN is not GUI based. So no not TWIN. And to run TWIN on newer version of RISC OS requires using !GraphTask to support the old screen mode.

I did say GUI based text editors.
My first ARM system didn't have a GUI. Also I didn't see a need for that overloaded bloat. ;-)

Return to “Off topic discussion”