Larger Project-submissions

Hi MGA & Chris & all,

There are projects in the works, which are larger and consist of multiple files. Separate DATA files, and Help-Doc-Manual resources. Image files. CALLs.

I'm doing Flashcards! They're awesome! They're 'smart'! But turns out, there's more to it than shuffling a deck of 3x5s.

Are multi-file and larger code projects appropriate for Forum submissions? Specifically, how would we manage Image files? Is it Ok that Help & Document files are going to run-on for (quite) a long ways?

I *often* miss that SmallBASIC Library Codes and Forum submissions offer little or nothing in the way of an explanation, background or Docs. Would it be constructive, to write-up material to address these gaps? Should such stuff be appended as a 'Comment' ... or would be better to paste it as a CODE block (.txt)?

(I see the nice SB Doc materials on Github ... and that those pages are 'scraping' comment-submissions off the Sourceforge site. Are we 'going' with this, or is it maybe a transient thing of some kind? Do you want more content added to the SF pages, via Comments, so that it shows up on Github? Is that good, or not?)

It was common, back in the BASIC Day, that a zip-file would unfold a number of files associated with a Program. Can we do that sort of thing here at SmallBASIC?

Ted Clayton

We haven't had many large projects here at this forum.

On the few occasions when image file or sound file was needed to go with a program, a link was provided, eg Johnno gave us a link to sound files for the Bowling project evolved here a few months ago.

Zip files are pretty much standard procedure on all other forums I've attended except Just Basic which has some sort of Wiki thing for members who sign up. I think zip-file system is as good as it gets until Windows XX outright forbids any files not approved by MS to be run on Windows.

This issue has been brushed on before when discussing this forum's limitations. I suspect Chris would like us all to sign up for github. ;-))

Thanks MGA,

1.) Github, CVS, Subversion, Debian, others in the wings and their relatives are all great things, a big advance for Computerdom. They are especially valuable for Developers, and Communities of Developers (better support for whom is key to the success of an Open movement). For BASIC beginners, for low-level longer-term users ... who normally are not 'dedicated' computer-people, Github et al is yet-another challenge. This is an issue not just with BASIC, but with great swaths of Open Source now gravitating to Repos ... which ends up discouraging those who might otherwise pursue the software the developers are developing ... but who come to perceive the overall scene as more-about the experts, and less-about themselves.

2.) It is a Classic Paradox, that the typical BASIC tyro starts out drawing a pretty picture today ... and then tomorrow is demanding the freedom & tools to write & compile an OS. Doom. The smart response is to gloss over the folly, and harness the interest & drive. And among the over-sized expectations are some that happen to be strategic blockbuster fits, for BASIC. Flashcards, eg. Classroom roles, other than How To Program. A great deal of the world's bread-and-butter computer-applications need no more than what BASIC already had, 60 or 30 years ago.

3.) The status of BASIC has long intersected with large-scale Industrial, Institutional, and Political-Global goals & forces from outside itself. And suddenly (unexpectedly, shockingly), it's a New Day, on all those points. Silicon Valley et al hiring & immigration practises worked on multiple levels and diverse angles ... until they didn't. Projects like SmallBASIC could now find themselves oxygenated & turbocharged.

SmallBASIC is perfectly well-suited to many uses that will definitely not fit tidily into a Forum Post. Or ... that fact that "We haven't had many large projects here at this forum", reflects the limitations of the forum, not SB. :)

Ted Clayton

Ok. I maybe a little slow on the up take... But, are we talking about size limitations for a project or size limitations for the SB site?

If memory serves correctly, the site limitations, are usually restricted by the ISP. eg: If hosting is "free" then there may be a limit of 10-50mb per month uploads to a maximum storage determined by the ISP. Usually, the higher the fees, the greater the storage and speed.

Project size limitations. I would imagine both yes and no. If the site has storage limitations, then yes, there maybe limit. In the 'old days', when machines were slower and had memory limits, large projects were not as popular as the more efficient smaller ones. Those days are gone. Machines are WAY faster and have greater memory and storage facilities. So, the project limitations would be limited by our PC hardware. Assuming SB can handle anything our machines can throw at it, and it doesn't impact on site limitations then no, the size limitations for the project would only be restricted by one's imagination. I hope I am making sense. It's 1:30am in Melbourne of Oz and I am running on caffeine fumes....

J

Hi Johnno56,

The limitation that I'm talking about, is simply that sharing a program or SB project within a Forum Post (here on the Sourceforge SmallBASIC website) requires that the submission be restricted to '(overly) simplistic' examples, merely on account of the limitations of the Forum.

A common, traditional 'example-program' will be a Magazine Article, with the Code included. It is assumed in such a presentation that the Article is available, to make sense of the Code. What we end up seeing here, is the bare Code, without the explanatory Article-text, so-to-speak. At the most basic, we would have a README.TXT file included with a small program. More-involved BASIC programs would have structured HELP, MANUAL and DOCUMENTATION files, in addition to the .BAS file ... which is typically all that we see in a SmallBASIC Forum-submission post.

DATA files also become crucial, past about Week #1 with BASIC. The use of DATA-Statements in-code is fine, in certain settings, but it very rapidly becomes highly desirable to have DATA in separate files. Often, typically, numerous or many separate files.

One BASIC code can CALL another BASIC code ... in a separate file. This is a very good & pragmatically effective practice.

It's normal, and proper, that even a simple BASIC Program does & should consist of multiple files; sub-Directories of Resources and assets. If I create an educational Flashcards Deck for Presidents of the USA, or say Antarctic Explorers of Australia - a fascinating topic in which I also have an interest - there should be Images, and quite a substantial collection of them. This array of Code & support files will not fit in a Forum Post.

Forums were meant for other roles, and do not support code-sharing, beyond trivial examples. How do we get beyond the trivial here? :)

Ted Clayton

There is another factor to consider when discussing large projects and SmallBASIC.

Considering SmallBASIC's start and directions Chris is taking with it, I would have to say SmallBASIC's niche or target users are device oriented and not geared for computer programmers. It explains the move from IDE to a built-in editor. Think about the small in SmallBASIC's name.

Some months ago, Shian a serious programmer started some things here in attempts to think big or bigger... I don't know what happened to him, if he gave up in frustration or suffered terrible consequences from time and place he was living. But thanks to him, I learned that SmallBASIC has a thing called units that helps develop reusable code in task specific modules for large projects. And SmallBASIC can do a form of importing. I did these things with old versions of VB and VB for DOS, big projects for work. There you needed an IDE that gives access to modules and procedures at a click, after a certain size it is a nightmare to scroll or page through 1000's of line to correct or test a bug. I have to say, as far as handling big projects go, SB doesn't match what was available back in 1995 let alone for today's developers even if hobbiest. Plus, this is interpreter only stuff.

If SB were a motor vehicle I'd liken it to a sporty little 2 seater Sprite or even motorcycle, certainly not a caddy or semi-truck for fancy show or heavy hauling.

The Palm handheld programmable computers became ubiquitous in airplane cockpits, yacht pilothouses, astronomical observatories and stock exchange floors, etc. They were the ultimate mobile-computing environment. Tens of thousands of often-serious Applications were written, shared and sold. But, Palm made several big mistakes, of varying technical, business and social nature, and this would ultimately cost them & their user-base, dearly.

Nicholas Christopoulos, in initiating the SmallBASIC project, both piggy-backed on the intense practical programming interest surrounding the Palm platform, and attempted to address certain of Palm's missteps. He wrote TinyBASIC, in SmallBASIC, 'To show what SmallBASIC could (or might) do'. Write an Interpreter, in an Interpreter? Not trivial. No, TinyBASIC did not get far. Yes, it does clearly show that Christopoulos was thinking about & working on more-robust & demanding applications & roles.

Christopoulos (or accomplices) then ported the SmallBASIC Palm-app to Windows, but Christopoulos soon appeared to regret it. All anybody seemingly wanted to hear or talk about, was running his Mobile Marvel ... on their (eww) desktop.

There is a broad-spectrum push to advance & promote Mobile. Matt Mullenweg, Mr. WordPress, says perhaps his biggest mistake, was to misjudge the Mobile juggernaught. He has since rededicated the world's #1 website platform to favor mobile, at the expense of the desktop. Mobile has indeed popularized digital technology far beyond what the desktop ever could ... but at the cost of a steep intrinsic reduction of more-serious functionality.

However, the bottom line in this still-ongoing societal drama, is that fully-robust computational workstations (ie, desktops) remain and will remain non-negotiable ... for everyday business needs; for heavy-duty usage of the Internet, and for Development & Developers, upon whom Open Source and citizen computing (Nicholas' driving vision) remains critically dependent.

But, there appears to be little grounds for concern that SmallBASIC will abandon the desktop: the developers already port it to every significant platform available ... and if the Klingons & Romulans pull into orbit, it will no doubt be ported to their systems. (The tools & resources to assist in performing ports has advanced spectacularly, since Christopoulos struggled with the challenges.)

It's always a problem & challenge, how to run the website that supports a software Product & Community. Sourceforge has been a godsend ... and it has had it's problems. Forums do great things ... in some contexts. It remains an unresolved matter, how to best implement the vision of Project Leaders, and their community.

The Debian Repository, and its interface with Ubuntu and many others, is a beautiful example. Still, Ubuntu felt constrained to repackage Debian as their Software Center. Partly, this may have been a self-serving business-decision, but partly it was in response to user-feedback, that Debian and the tools to access seemed 'too hard'.

Certainly, Palm applications - even of a simple nature - commonly came as multi-file assemblages of assorted resources. And the same will be true of contemporary Mobile Apps.

And SmallBASIC itself continues to become more - not less - sophisticated & capable. ;)

Ted Clayton

i bet walt would be happy to host such projects at his qb64 forum. thejoyfulprogrammer.com/qb64/forum

its currently expanding into things like python and "other," not only qb64.

Hi figosdev,

If I'm ever able to quit doing manual labor to pay the bills, yeah, I would be involved in ... well, I would no doubt be involved in as many things as I have time for, and then some, just as I am now! QB64, FreeBASIC, Gambas ... Python, PHP ... a homebased LAMP and my own T1 (which - oooh - comes more within reach all the time), sure.

I think Nicholas Christopoulos hit a real sweet-spot with SB, and Chris has largely kept it within the envelop. I prefer to see BASIC aimed mainly at the part of the population that 'really' has too many other demands on their time, attention & energy. SmallBASIC has been and continues to be an exemplar of the type.

The other BASICs are cool & very cool! The SB-philosophy fits the 99%.

As I highlighted above, in BASIC as elsewhere, once someone has a new hammer, everything starts to look like a nail. This should be facilitated & encouraged, 'within bounds'. SmallBASIC does not need any changes, it's fine as it is. The "presentation" of Code Library examples, and what Christopoulos called "Applications" just need some garden-variety upgrades.

It's a website issue, not a language issue. SB is where it should be. Supporting things like a READ.ME, a DATA file, nice HELP write-ups ... these are not radical suggestions, or indicative of a need to graduate to hearvier-duty platforms. This is all completely appropriate to a simple, accessible, friendly BASIC.

Ted Clayton

ted!

you didnt read my reply-- i said nothing about using qb64... i said that the site i was pointing to was mostly a qb64 site, but other basics (read: smallbasic) are probably welcome.

he hosts zip files you know...

in other words, i answered the original post to the letter-- and you missed it because i mentioned qb64.

(i dont even code in qb64 anymore.)

regards,

figosdev

Just a minor misinterpretation figosdev! I had no idea who you are (and still don't), but I did a quick search and see you've been busy. I've looked at SB64, and liked a lot about what I saw. And ditto with others.

I only say 'zip', cause it is an easy way to keep a set of files together. It's tidy. Sometimes, there can be sub-dirs. But the different pieces of a multipart SB program would not have to be compressed. They can just be BAS and TXT etc files. Would that make it easier for Chris?

For now, I have to quit for the day; maybe work tomorrow, and up early in case. Will only have a moment in the morning, then gone if the call comes.

Thanks! - Ted

no problem. im the guy that originally created pcopy! smallbasic.sourceforge.net/?q=node/851

although im not sure what i had to do with issues after 10 or 20. i know mga and aurel from other sites-- i also used this forum fairly briefly, but i went back 8 years before i found my old handle :) i gave pcopy! its name. if you havent heard of it dont feel bad-- i dont. cheers.

Thejoyfulprogrammer/qb64/forum looks to be into allot stuff I am. Wasn't qb64 forum discontinued?

figosdev, thanks for bringing to my attention! It's cool to see you with your own Linux site too!
Oh, and there's Aurel, I will have to stay tuned! Wonder of wonders!!!

I can see how it would be useful to simply share zip files for larger projects, but I'm not keen to offer file sharing on this site.

I hear what you are saying about Github being a challenge. Git has a very large feature set, but you really only need to know a few basic concepts to get started.

There are plenty of advantages of using github:

- Designed for sharing code and collaborating on large projects.
- Individual code lines can become comment sections including email notifications
- History of changes readily available showing who changed what, when why...
- Ability to switch back to an earlier version to help track down bugs

If you are willing to give it a try, we could start by attempting to work on some large SmallBASIC project, maybe a game. A couple of years ago someone posted an adventure game written in one of the other BASICs, (might be have yabasic). It could be fun to port this to SB, but would be too much work for one person.

Sounds like fun!

I used to play Adventure Games back when basic had line number, goto's and gosub's. I have tried Interactive Fiction programs (Inform, Twine etc) which are relative easy to use, but they are NOT Basic... I like the old Text Adventures. A lot of work, yes, but so worth it when the game runs to completion without errors! Keeping track of where you are using pencil and paper; Using the best visuals available - the imagination; Being able to add or edit content; Knowing that the game that you create is unique. Sorry... too much waffling...

I'm not very good at programming, but I am willing to help, in whatever capacity that you deem necessary.

J

as far as i know the qb64 forum is still running.

it had some issues for a few days and should be back up.

i vastly prefer the alternative forum.

i hope the op figures out i wasnt suggesting a switch from sb to qb64-- i was suggesting that site could likely be used for what he wants, even for sb.