QB64.Net Homepage QB/QB64 Keywords QB Graphics Forum Homework Policy
now that it's being fixed (it is, isn't it?) - to anyone that may care about itby mn (no login)
i wasn't the first person to mention chr$(0) not working the way it's supposed to. it's intrinsic to qb compatibility and string-handling that it not choke on any character. it's just as intrinsic to qb compatibility that string-handling be able to treat chr$(0) properly as it is for math functions to treat 0 properly. it's not a "minor annoyance," "nuance," or unimportant bug at all. (quotes used for emphasis, not to attribute them to anyone.)
in the context of a shortcut function like strcpy (or whatever the name is/will be,) it's problematic if string-handling doesn't work consistently. but when the shortcut function is being written by the primary maintainer of the current qb version, it's more serious. if it's "not a bug" in this context, isn't it a problem in general if string-handling is broken?
if i was the first person to be dismissed, you could easily point to the demanding tone of my post as the rationale for a dismissive response. except that's not how it happened at all.
do-ocracy has limits in how much it benefits a project (rather than destroying it.) clearly in a do-ocracy, the person doing the most work should have the most say. but it's not a pissing match where whichever individual contributes the most gets to tell everyone else who has worked on the project (i'm not referring to myself, it's not my project) to basically go screw when there's a real problem. (it's not that bad, actually. it's not a whole lot better, though.)
do-ocracies make sense, up to a point. but the worst (and most common) kind is where whoever adds the most new features to a project that exists for the sake of a community, the community gets quickly displaced by whoever does the most that month, or that year. if this is seen as an attack on steve, steve is not the worst part of this. although cracks are starting to show, steve is probably the least arrogant and least abusive of any new project maintainer to make this kind of mistake. put any other person in his place, and it might be worse.
but no one should be in his place. no one should have the job of telling people "if you don't like it, don't use it," when it's part of a project that people already use. that's not how bug reports should be treated. absolutely you can't force people to fix bugs or take reports seriously, but no matter how substantial the contribution, no one with the job of handling bug reports should dismiss them as a first course of action.
steve has shown a lot of patience with clippy, and me, but i'd rather he be worse to me and more fair to people that report bugs that are serious (before i even get into why i support them.) the naming thing... that's nitpicking. it can be useful, in a community where choosing names is important (but not the most important thing, because it isn't.) but it's nitpicking even if it's useful nitpicking.
an ascii string is just a collection of values ranging from 0 to 255. qbasic and qb45 (and the original basic) don't just stop working when they encounter a 0, and neither should a project that touts compatibility. that's a serious bug, and it should have been treated like one before i mentioned it (because i wasn't the first.)
in a do-ocracy, the person that contributes the MOST should have the MOST say, of the individuals. but in a project that has a community, as i wish qb64 did, the community should be able to speak up against bad decisions made even by the most senior maintainer. that doesn't mean the project leader (even the de-facto temporary leader) should be a slave to bad technical decisions. but legitimate bugs should not be hastily dismisssed, even by someone in the lead.
i'm glad it's being fixed, but the attitude shown doesn't inspire any faith. it's a little too familiar, and it isn't easily explained as far as i can tell. this is a problem if qb64 is going to go forward. but what do i care? i'm not sure i do, or don't care about this.
but this is definitely a problem for countless do-ocracies, which is clearly the model being followed with qb64. it's not a necessary bi-product of the do-ocracy idea, it's just a common side effect that could be mitigated, if it mattered to anyone else.
steve... if you weren't so flippant about people's concerns, you wouldn't even be a side note in this. but like i said, this is what people usually do in your situation, and they're usually worse about it than you've been. that doesn't mean it won't drag down qb64 faster if your standard response is "features matter, bugs don't." obviously if the bugs didn't matter, you wouldn't bother to fix them. so whatever standards you'd like to see for the community to address their concerns, you're the (public-facing, at least) leader of a do-ocracy, and the community is at the mercy of your whims. how would you like to see them keep you honest?
it's not like you have to answer the question. i just wanted to ask it to make a point. i hope i don't stay around long enough to see the history of gw-basic turn into the future of wg-basic. who gives a basic? who even knows?
if people kept in mind that they're preserving and extending a legacy, they might treat it that way. it can't do everything, let alone do everything the best way possible, but it doesn't have to give up and just be a collection of half-working features, either. add all the functions you want, but any feature worth adding is worth adding in a reasonably consistent way, that works the way qb ought to, with as few bugs as possible. ignoring them and fixing them both make unreasonable people more quiet (except for me...) but ignoring them and fixing them are still opposite things.
even if something can't/won't be fixed, at least a message can be sent that (thoughtful) participation won't be actively discouraged. aim for *that*. it'll make everyone happier, including you i believe.
you're right, i like to rant. but that's not really all, steve. that should be pretty obvious.
New Forum Policy: All posts must be completed in two words or less.by Pete (no login)
OK, sorry, I made that way too easy for ya. :)
Well you found another reason why I divorced myself from that community. QB64 was a one-man project that was coming along nicely. Slow and steady. It eventually reached suitable QB45 compatibility, even for my "simple" 80,000 line program needs. Only hundreds of hours or conversion work, instead of thousands with a product like FreeBASIC or PowerBASIC, neither of which would have performed as well, were needed for my program conversion. But then as often happens in life, things changed, around the time the developer changed occupations, and had a new addition to his family. The effects were like changing the tempo of a good golf swing, the ball never flue straight again. Having kids and switching careers to something you presumably enjoy more both trump QB64. I just did not appreciate a tone that the project is still moving forward. It isn't, it is moving sideways at best.
I really don't know why anyone users the term "developers" for that site. Contributors would be far better terminology. Steve is not a C programmer, and you can tell by the simple manipulations of existing code he dabbles in. A few other real C programmers who visit that site are simply not interested in contributing. Why? Well I have read posts it is because the source code is far too convoluted to delve into. Gee, if you thought you might ever need other people's help in the future, maybe it would have been a good idea to make it open source and group oriented to begin with. In that regard, Galleon reminds me of Daffy Duck. When Daffy needed Bugs, he'd be right there digging behind him every step of the way. When Daffy and Bugs found the gold, Daffy went all, "Down, down, down! Mine, mine, mine! Back, back back!"
So what good is a one-man open source project to a community, and what good is a miniscule resource deficient community to a one-man developer? That's the QB64-million dollar question.
Re: New Forum Policy: All posts must be completed in two words or less.by SMcNeill (no login)
"Steve is not a C programmer, and you can tell by the simple manipulations of existing code he dabbles in."
Ain't that the truth!! C is something completely new for me to learn, and let's be honest: QB64 source isn't the easiest place in the world to start learning. ;D
BUT, I'm still learning it in bits and pieces. Give me another year or two to get more practice in with the language, and THEN maybe I'd say I was a C programmer. At this point, I'm just more of a C- dabbler instead of a C++ programmer. ;)
Re: New Forum Policy: All posts must be completed in two words or less.by Pete (no login)
That's another jumping ship point... years. The older I get, the more I want done, now. I still use the SDL version, because I consider it more stable. I still use the QB45 IDE for some projects that do not requite underscore statements, because it is better organized, faster, and has an interpreter. Otherwise, I code in Notepad. I'm learning mobile app programming, which QB64 is useless for. I dabbled in C a few years back, but the language is insufferably boring compared to BASIC. I like speaking English when I code. Which reminds me, me64 has a good point about keeping the names for new statements more within the boundaries of BASIC nomenclature.
You're a really smart guy. and if C fascinates you enough, you will learn it well, in time. Unseen Machine started here with us, learning QBasic and wanted more gaming ability, so he started C courses and in about 5 years or so became what appears to be a pretty knowledgeable C programmer.
It would be nice to have the QB64 SDL version packaged as the official finished QB45 compatible programming language for now. The future with GL, who knows. All that I know is the timeline looks horrendous. I see talk of going over established code, redoing everything, adding new commands, adding new features, and C new comers talking OOP and realize that in time maybe, but there is a lot more interesting things to do in life than just wait around for forever to get here. Mega projects are exponentially hard to add to, and even harder to unravel and put back together.
For those who are patient and stick with the QB64 project, even if those aforementioned elements are made good on, other program languages with their teams of well qualified developers will be miles ahead of whatever progress is made in QB64. So while the QB64 community may wish to talk state-of-the-art improvements, if they ever became a reality, they would also be yesterday's news.
Too many new things to learnby Solitaire (no login)
and I'm getting too old. I'm still stuck on the original QB. That's why I'm still using Windows XP, which is able to run QB in full screen for me. I'm also stuck with visual Basic 2010, which I've been teaching, and am not moving on to the 2012 or 2013 editions for now, since neither of them can be installed on Windows XP, and I never use the advanced features anyway.
Python has recently been promoted as a language for beginners. If you take a look at it, you will see some resemblance to Basic. For example, it uses the "print" command. It also doesn't require variable type declaration. Downloads are free and available in many different variations. Don't know if I'll be getting into it though, as I have too many other things that need my attention.
And just wait for the battle of the underscores, it's coming.by Pete (no login)
Soon, if not already, there will be more underscored keywords than not. Two or three newbies, the bulk of the community, will be asking why do I have to keep typing underscores to plain English keywords? I'd state that would kill the premise of backwards compatibility, but the rub is for some keywords, that underscore is all that is different. It would break all new program compatibility to lose the underscores, even if the IDE did it for you.
The solution is do what PowerBASIC did. Wrap up the QB45 compatible version in SDL, market it that way, and start off on a new foot, now.
Oh, and Solitaire, my hats off to you for learning and teaching .Net at an advanced age. Although a bit ironic that a BASIC dialect would become the cumbersome language to learn.
Re: And just wait for the battle of the underscores, it's coming.by SMcNeill (Login SMcNeill)
Soon, if not already, there will be more underscored keywords than not.
Sorry, that battle was lost about 2 years ago. Have you ever took a look at the _gl keywords? I'm thinking they outnumber the regular words and the other underscore ones as well.
In QB64, the underscores have outnumber the non-underscored keywords ever since SDL obsoleted.
who knows anything about SDL2by STxAxTIC (no login)
I know SDL is no longer a thing for QB64, officially, but I wonder... SDL2 came out recently, right? Is it any good? A sufficiently skilled and interested person could start with the 2012 SDL version and QB64 and beef it up seriously with SDL2.
I know something about SDL2by Pete (no login)
Read the last paragraph of my previous post, about knowing Steve has ears. Galleon knows it has been out for awhile, too, but simply sees the SDL project a garbage. Funny, he picked it for his project in the first place, isn't it?
Re: now that it's being fixed (it is, isn't it?) - to anyone that may care about itby SMcNeill (no login)
"steve... if you weren't so flippant about people's concerns, you wouldn't even be a side note in this. but like i said, this is what people usually do in your situation, and they're usually worse about it than you've been. that doesn't mean it won't drag down qb64 faster if your standard response is "features matter, bugs don't." obviously if the bugs didn't matter, you wouldn't bother to fix them. so whatever standards you'd like to see for the community to address their concerns, you're the (public-facing, at least) leader of a do-ocracy, and the community is at the mercy of your whims. how would you like to see them keep you honest?"
^ This seems to be the misunderstanding. I wasn't being flippant about your concern; in fact we've been working all morning to correct the underlying issue in QB64 itself with the way it handles string comparisons.
Where I was being "flippant" was with the comment about "bloatware". The issue of the language bloating has been mentioned, addressed, rolled around, and decided upon. It seems a bit silly to me that someone would mention such a thing every time there's something new to add. As you said, I seem to be doing a lot of the changes here lately, and what do I end up adding? 1 or 2 new commands per month on average maybe. And 90% of those are already in the source; I'm just working on making access to them for people on the BASIC side of thing and not just the C side.
And yet, each time one of these new commands is put in the language, there seems to be an explosion of how it's no longer BASIC. It's almost like BASIC stopped back in the 90s and there can't be any addition to things anymore. Some people want to preserve it like a dead language. (Latin anyone?) Personally, I'd like to see it grow so that we can use it for more and better things than we did back in the stone age.
Add something that adds 1kb to the QB64.exe and it's the end of the world!! Of course, clean things up, optimize things, and make the QB64.exe shrink by 70kb and no one notices or blinks an eye. (http://www.qb64.net/forum/index.php?topic=12201.0 )
And ^ that's why I don't pay any attention to the talk of bloatware. The topics been addressed. Galleon decided how he wanted to deal with "bloat", and the issue has been settled. No need for people to keep beating a dead horse with a stick....
As for the new command not working with CHR$(0); I really don't see it as being that big a deal. It's a tool for sorting lists alphabetically; I don't see it as having to deal with every ASCII code out there. or (Unicode)... Let it do what it can do, as FAST as it can do it -- as long as the users know the restrictions. When we have to wrap a ton of IF conditions around a native C command, each one slows things down. If we slow it down enough, then what's even the point to that command??
The choice is:
We can work up a string compare that works with the existing limits of C -- and make it almost as fast as direct C.
We can work up that routine, add several IF checks in there, toss in a separate subroutine to deal with the limitations -- and slow it down to almost the point where UCASE$(s1$) > UCASE$(s2$) is of comparable speed.
Which is why I said it's one of those cases where people might just have to live with it. "Take it or leave it." Do we want something that's blazingly fast in a limited scope, or something that's no faster than existing methods with an untethered scope??
Personally I like the idea of being able to swap over to a routine that runs faster in limited conditions than I do the idea of something that runs at the same speed as what we have now and only saves typing a few letters... ;)
But as for the underlying problem in QB64 itself: <, >, =, and all those commands definitely *NEED* to work for all strings and ASCII codes. The fact that they aren't returning the proper answer now to "dog" < "dog" + CHR$(0) needs to be addressed. It's not "optional"; it's necessary.
Add something new, and the restrictions on it can be as extreme as you like. All it does is offer an optional command in the proper situations. But "core functionality"?? That has to work no matter what!!
Which is why I've worked my poor little hiney off to completely strip out the old string compare routines and write up a new set. We've also went in while messing with all that and gutted the heck out of the original UCASE$ and LCASE$ commands and replaced them. They're now about half the previous size and run at the same speed -- or up to TWICE as fast as previously in some situations. (Say you have 1000 uppercase As and then a lowercase a.... The new routines will run those MUCH faster than before.)
I take error reports seriously. It's just sometimes (like in the case of _STRCMP, which I think will be the new command name when it gets added) the fix isn't worth the hit to performance. It's actually better to just put a caveat out and let people know when NOT to use the feature. ;)
BUT, when the core is broke, it has to be fixed. No getting around that -- which is why you should see an update in the next day or so to fix how <,>,=,<=,>=,<> all work for us. I *still* don't know if I'm going to end up altering the _STRCMP routine to work with CHR$(0) or not. (And that's really not me just being stubborn, which I can be sometimes....) It'll all depend on how much of a hit to performance it'll take to correct the issue, and how much it can be optimized to minimize differences.
If I can get it speedy enough, I'll alter the routine. If not, and it's still a nice improvement over the UCASE$ vs UCASE$ method (which should get a performance boost with that next update as well), I'll probably just add the command with the warning "Not for use with CHR$(0)." If it ends up that the changes to UCASE$ make it where _STRCMP doesn't have that large of a speed increase either way, I'll just end up tossing it probably.
So, I don't make any promises as to what the final result will end up being yet. It all depends on what and how I can get things to perform for us. ;)
don't be afraid to name me personally, Steveby STxAxTIC (no login)
I'm the "someone" that said bloatware, and for this reason: it is.
I'm really excited for you to start learning C. The more you see it contains, the more you will realize "oh, QB64 doesn't have THIS yet!"... and feel compelled to add it.
This is fine, PROVIDED you take seriously my suggestion on being able to optionally #/$INCLUDE any new bloat that is hooked onto the original QB45-era syntax.
That would shut me up, and Pete, and mn, and everyone else. It might even cause some of us to return. Until then, if you haven't noticed, I'm out. Deal?
Re: don't be afraid to name me personally, Steveby SMcNeill (no login)
"This is fine, PROVIDED you take seriously my suggestion on being able to optionally #/$INCLUDE any new bloat that is hooked onto the original QB45-era syntax.
That would shut me up, and Pete, and mn, and everyone else. It might even cause some of us to return. Until then, if you haven't noticed, I'm out. Deal?"
Hate to see you go Bill, but that's your choice. I don't know what happened to make you decide to leave all at once; one day you're spamming the chat channel working on your bot, the next you just disappear. And all before I bother to try and work in a better way to compare strings alphabetically...
Whatever the problem, you have to realize exactly how silly it sounds to expect people to #INCLUDE every keyword since the days of QB45.
For starters, such an approach isn't backwards compatible at all. All the code that people have written under the current system would have to be altered to add all those includes with each and every one of them.
Then there's simply the added hassle which anyone wanting access to the new commands would have to deal with. Is such a method *really* going to encourage people to look to the future, or just stay in the past??
How about someone goes in and develops the option to #EXCLUDE any command which offends you?? Then you could make a whole list of them and copy/paste that into your own code. Of course, IF for some ungodly reason, you decided that you needed something QB64 specific like _PRINTMODE _KEEPBACKGROUND which your calculator uses, then you'd have to go into your #INCLUDE:'excluded_commands.bi', and remove those words so you wouldn't exclude them when you wanted them.....
But do you want to know the largest reason why I find such discussion about bloat completely silly??
Grab the latest dirty build. http://www.qb64.net/
Now go back and GL when it was just being written, before anyone but Galleon ever worked with developing things: http://www.qb64.net/forum/index.php?topic=6575.0 (v2 is the earliest I can find so you can compare)
Notice that QB64.exe has grown a bit since those days. (From 5.4MB EXE size to 6.0MB EXE size.) I guess if we look at THAT as our milestone, then it's bloated up some. (The x64 EXE is 5.7MB in size btw, in case you're curious.)
So, since July 03, 2012 to the current date, we've seen QB64.EXE grow by 600kb or so!!
Let's put it to the test why don't we??
PRINT "Hello World". Copy this into both versions and compile.
The v2, July 03, 2012 version makes us a Hello World program that is: 1,779kb in size!
Today's dirty build makes us a Hello World program that is: 1,419kb in size!!
(And the x64 version makes a Hello World that is: 1,614kb in size.)
For all this talk of "bloating" the language, the files we create today are SMALLER than the files GL was creating a year and a half ago.
People complain about the "bloat" taking over. Does that *REALLY* seem to be the case?? Or are we actually going in the OTHER direction??
No one ever notices when something is cleaned up, tightened up, or optimized. They never say, "WOAH!! This is getting BETTER!" All you ever hear is, "Make it the way I want it! Rahr! Rahr! Rahr!! Until then, if you haven't noticed, I'm out."
Since 2012, QB64 has seen improvements in hardware acceleration, CONST support for math functions added, new math commands brought into the language, many old keywords reestablished and expanded. Syntax checking has expanded, error catching has improved, and many bugs have been squashed and removed from the language...
And the EXE files it produces?? SMALLER than the ones from all that time ago.
Does that sound like it's BLOATING to unreasonable proportions to you??
Don't worry. Nobody truly "leaves".by STxAxTIC (no login)
By "go" I simply mean that I'm finished chiming in on the dev stuff. I admire the time you spend debating all this, and I frankly don't have the minutes to spare to indulge in ripping apart the points you made above, so I'll only mention are they quite vulnerable for the ripping.
My attention (as far as programming goes) is now purely on C++ (again). (It handles strings much more naturally than raw C which is reason enough to prefer it.)
Back to BASICsby Pete (no login)
Bill. with an exception for your wanting to venture into C++ for strings, I find it interesting that people more interested in BASIC are showing signs of disinterest in QB64, while people more involved with C/C++ are maintaining hope in the project. The project was better off when that was the other way around.
I suck at making names for things, but I would even feel better with _COMPSTRING than most of what Steve has come up with. But that is for a name. BASIC is about building what you want, mostly off of existing keywords, like SWAP. That is not absolute, as INSTR$ is a function that a BASIC programmer could write. INSTR is amazingly useful for a lot of things, but just making an alphabetical list is a job for a written, simple bubble-sort function.
Pete's Theory of Ideas. Step one, have an idea. Step two, make sure it's a good one.
BASIC is a beginners language. Sure you can make thousands of statements, even name them well, but what beginner should be faced with a document that looks like a grad students thesis?
So Bill, I think we both see bloat, but from a bit of a different perspective. If Galleon can't push the project forward anymore, we have others who will fiddle with existing elements, just to feel something is being done.
QB64 Semantics: I'm not drowning, I'm just in the middle of the Pacific, no boats in sight, happily treading water.
Re: Back to BASICsby SMcNeill (Login SMcNeill)
"BASIC is about building what you want, mostly off of existing keywords, like SWAP. That is not absolute, as INSTR$ is a function that a BASIC programmer could write. "
Now see, here's where I get lost. Build what you want off of exising words like SWAP....
Why even have a swap command?
Temp = var1
Var1 = var2
Var2 = temp
^ There we go! Var1 and var2 just changed values with no need for SWAP. Guess a TRUE basic programmer doesn't need that command......
So what's its purpose then??
To make the process simpler and faster.
In BASIC you could do:
X = (UCASE$(var1$) < UCASE$(var2$))
IF X = 0 THEN X = -(UCASE$(var1)>UCASE$(var2))
This will compare 2 strings, irregardless of case, and return us a -1,0,1 result for less than, equal, greater....
The new X = _STRCMP(var1$,var2$) can tell us the same thing with half the typing and in less than 1/16th the time....
When I go to put a tire on my tractor, I don't head out to the quarry with my chisel and hammer and carve one. I use one someone else made in a factory somewhere and put it on my rim....
Do you guys really think BASIC would have stayed the same and never added new commands or functions, had someone bothered to keep producing and marketing it?
The way it seems to me is simple: IF all someone wants is QB45 code ran on a modern OS, use the SDL or an older GL version. No one is making anyone upgrade to a newer model and deal with any changes or additions. If you LIKE coding multiple lines of code to do something slowly, no one's going to stop you. Chisel out your own tires if you like.
But why complain and say it isn't BASIC when the rest of us are just looking for a simpler way of doing the same thing quicker and more efficiently? We don't need to swap values with a temp variable with the SWAP command, and we don't need multiple lines of code to compare 2 strings by non-case with _STRCMP...
But we still need the BASIC knowledge afterwards to actually DO something with that information, like sort a list alphabetically...
It's not breaking BASIC. It's just making one small process quicker and more efficient for us. What's the harm in that??
And, as an aside, INSTR returns a numeric location of where a substring is found inside another string. As a numeric function, it doesn't have a $ with it. Those are reserved for functions that return string values to us....
You can't get any more BASIC than a rule like that. :D
The problem is the disagreements...by Pete (no login)
In a small community, disagreements lead to, yes, you guessed it... an even smaller community. You talk about the Stone Age while you are actively carving out an existence in one. Unless real change for the good happen, QB64 will forever be behind in everything it is trying to become, and too small to count or have any impact in the field, mulch like your broken tractor. As I stated, INSTR is highly useful, your string compare function is not. In other words, just because we can, doesn't mean we should. I could make a _POPUP command that expands PCOPY and other statements to make a positional popup window to save time, but I would also be making the project more and more OOP like in the process, not BASIC. If I wanted to do such things, I would simply call what I was creating a different language, like Python.
Re: The problem is the disagreements...by SMcNeill (Login SMcNeill)
As I stated, INSTR is highly useful, your string compare function is not.
Now see, there's the rub. Useful is relative and subjective. A knife isn't very useful if all you do is eat soup, but it'd be dang hard to be a butcher with just a spoon...
The more tools I have in my workshop, the happier I am when I go to build something....
And WTH can't I call it BASIC?? Basic, All-Steve Inclusive Code is a lovely name. Stick to your Pete Yodels The Harmonics Over Noodles if you want, but I'll still be playing around with Quitcha Bitchin 64 for a long time to come, and that's no Overly Oderious Poop. :P
then it's settledby STxAxTIC (no login)
Sorry if I came off as oh, I dunno, emotional lately. Standing back, I guess it's a completely minute point. Here are the real facts: you are extremely careful, open to input, and when you see an error in your ways, you rush to fix it. I mean RUSH. In this sense, the project is safest in your hands.
I denounce my old position on this. Hell, speaking of bloatware, even my wife hasn't lost her baby weight yet, and it's been 5 months! But I find her completely beautiful. So deep down I actually have a loving for ... gulp ... bloat. Haha enough of that.
Now, Pete... let us both come to our goddamn senses on this. All of the new QB64 machinery is COMPLETELY invisible at the IDE level. You can copy and paste code from 1988 right into QB64, and boom, it works. Steve and company have not slipped on maintaining this at all. Let's consider the dev team *sufficiently* warned that WE, the self-proclaimed community power users with 10000+ line programs, are assured that QB45 compatibility will be maintained. I dunno about you, but I make sure my work (if its BASIC then LET it be BASIC) works on everything back to QB45 (up to stack space limits, but I'm talking compilability here). It would be devastating to one day lose QB64. Equally devastating however would be to "lose" QB64 to the Q-NON-B-64 eventuality. Ya know what though, that ain't happening. If Steve lets it happen, I *basically* know where he lives. :-)
So Pete. Consider my bloody (literally, not the English "bloody") hand extended. As one teetering on the edge, spill back into QB64 with me. You know you miss it.
(This doesn't mean I'm going to be there on the forums, I'm branching inward to create my own QB hall of records of code I appreciate. It's brand new: http://people.umass.edu/wfbarnes/indexcodelib.html)
Re: then it's settledby Pete (no login)
I have absolutely no interest in the project at the present time. Steve as a developer? Is that a joke, because it should be. That project is a C/C++ related project, and needs people already skilled in those languages to further it's development in any significant way.
It's a FUBAR project as it stands, so no, I certainly won't be going back to it. I do still enjoy the SDL version, that was some really good stuff, and all by Galleon, back in the days when he actually had time for the project.
Just as you are exploring C++, I am exploring mobile. If my kid gets interested in coding, I'll teach him Python. He already has had some experience learning to code HTML and CSS. He doesn't need to have older programs run on newer systems, so I rather him have something mainstream.
It bothers me too much that the SDL version is no longer supported. No bug fixes, basically trashed.
I know you have ears...by Pete (no login)
But unfortunately, they are the ones attached to your corn stalks. I have ears, too, as in ears of experience in BASIC. In that regard, a lot more ears than you'll ever have.
Now farm puns aside, let me plow right through your feeble tool analogy. More tools don;t mean squat. Having the right tools is all that matters. INSTR is a valuable tool because it has a multitude of uses in building programs. I probably use that keyword in 80 percent or more of everything I build. If you can come up with a new keyword that is as good of a tool as INSTR, then I'll change my tune. Right now, you're raising a field of bloats.
I think the SDL version is the best the QB64 project will be in terms of a real modern BASIC language that users who love BASIC can use. Whatever this GL version is turning into just screams off changing BASIC into something else, and trying to make everybody believe that isn't happening. PowerBASIC really handled this so much better. They still support PB for DOS, fully. Unfortunately, everything Galleon has abandoned becomes labeled as crap by his standards. That just tells me whatever he is working on now will be considered the same some day, he just hasn't figured out it's crap, yet. I'm not a farmer. I don't have to put up with crap, but you are free to play around in it all you like.
for posterityby mn (no login)
i can understand if someone thinks this is somehow underhanded. (it's not.) i just think it's one of the most relevant things ever said about BASIC, and one of the most relevant things that will ever be said about qb64.
certainly if the author requests it be deleted i will not take issue with the mods doing so. i ask them to consider leaving it here until the day that happens. i am not trying to take it out of context and i don't feel like discussing it. but i am sure going to post it, and also this is a one time thing. the following is unedited (i can't help with the emoticons.)
Quote from: STxAxTIC on September 19, 2014, 08:45:28 pm
Backlash warning over at N54. Read all about it.
Some people just like to rant. It's all good. :)
We've already had the discussion over "Bloatware". Galleon made his decision quite public on the "bloating" of the language. http://www.qb64.net/forum/index.php?topic=11920.0
Everybody has a different opinion about what QB64 can/should be. But unless we make it what the individuals in our community want it to be then we all lose. So even if we personally don't want/need things like...
- A suite of string commands
My new philosophy is to let QB64 be what the community want it to be. Even if we end up with 1000s of commands that barely get used by the majority, it is better than QB64 not being used at all.
The decision was made, and I'm not going to let talk about "bloatware" concern me one bit anymore. This is something that I *can use* and *will use*. If no one else needs it, that's OK... I just find it hard to believe that I'm the only person out there who would like a fast, efficient way to compare strings ALPHABETICALLY and not by ASCII code.
Alphabetically "DOG" is the same as "dog". In ASCII, they're not.
As for not liking the name (which was a nice long post or two on the other forums), that's why I put it up for suggestions. Don't like it, fine. Just don't tell me how bad my naming sense is; show us how much better yours is. ;)
And the fact that you have to be careful with CHR$(0) with it?
This really doesn't seem like a big deal to me. If your strings have CHR$(0) in them, doing a non-case comparison of them probably isn't the best idea. Chances are you're dealing with something more complex than simple alphabetical comparison between strings, such as a binary data file, which I think you'd probably want a custom routine for.
It's another case of "don't like it, don't use it." No one is going to force anyone to start adding the command into their code. Heck, look at the whole list of _gl... keywords out there. How many pieces of code have you seen with any of them in it??
I feel like it's better to have it here for the people who might need it and make use of it, than it is to not have it just because someone else doesn't need such a feature.
Hey, maybe I could call it _QB64BLOATWARE_ADDITON_NUMBER_00000001! :D ;D
alternative QB45-compatible compilersby STxAxTIC (no login)
In order of their date of projected deaths, whether it has occurred yet or not, the QB45-compatible systems on which I have relied are:
FreeBASIC #lang "qb"
QB45 stuck in DosBox
QB45 in Win XP and below
Something that myself and others want to know:
What are the other QB45-compatible compilers out there? I've heard of DarkBasic and BlitzBasic, but haven't tried them. Are these fully compatible?
i think it would be shabby not to reply at allby mn (no login)
but i don't have much to say about this. if pete stops giggling (or guffawing, he seems like more of a guffawer to me) i'm totally serious.
you're absolutely right about the "around the edges" business, and i'm so sorry. the worst part is, they're not even smooth edges. it's vandalism over restoration, and that's where i get off. since i don't use microsoftware anymore, and there's nothing else to follow/reply about regarding this other issue, i think it will be the other subforums from now on. at least until everyone's tired of hearing about... well, wrong subforum for that. take care.
Re: alternative QB45-compatible compilersby Pete (no login)
DarkBASIC was made for primarily for gaming. It is not that QBASIC compatible, from my limited exposure to it. People who use it seem to speak highly of it. I've never heard of BlitzBasic. It sounds like some Third Reich software that could easily be used to take over France, but then so could FORTRAN if you threatened to throw the cards at them.
PowerBASIC has a DOS version that is very compatible to QBasic.
PS If you see Myst, tell him I'm sorry, and I accept his surrender. :)
A whole swarm of them at:by SMcNeill (no login)
Give those a try and see if any of them work for your needs.
thanks for your responsesby STxAxTIC (no login)
I've been spying on that BASIC compilers list over at freecountry for a while now. I've even tried a few of them. Conclusion: everything sucks except QB64 and FreeBASIC.
I get the sense that people praise things like DarkBasic because *it* does most of the work FOR them. I've never heard anyone praise these high-level general-purpose languages who can properly define the word "vector", or has heard of the "cross product". (If tricking people into thinking you're an awesome 3D game programmer is your style, then sure... but I'm not talking about FluffRabbit here.)
Looking again at that list, it seems that every person or dev team that accomplishes QB45 compatibility with their C-family project INEVITABLY jumps the shark by (i) adding too much junk and cornering the "basic" part into some slow-moving side caboose of the language, or (ii) breaking QB45 compatibility by adding "new features".
We can swear up and down that QB64 will never minimalize the original BASIC component, or even break compatibility, but who knows - five years from now, once the dev team has turned over once or twice, or even 15 years from now... someone will be clever enough to trick the rest of the community into jumping the shark. Then it's over.
It's therefore our job to tighten the bolts on this titanic, not build the deck higher.
In case I get accused of being abstract, I am NOT dissing Steve's contributions in any veiled way. It's just that seeing the list of dead projects over at freecountry sent a shiver down my spine.
for those of you coming over (hattip to STxAxTIC)by mn64? (no login)
i don't care (that much) if people want to make functions with stupid names. i advise against it, already explained it. i wrote three (or is it "Three?" need a function...) posts about it.
not my beef. yes, i wrote a criticial post. i also tried really hard to be reasonable and (mostly) friendly.
this nul business is another matter entirely. it's exactly the kind of problem i NEVER thought i'd see here.
and pete and i have had our differences, but he REALLY shouldn't be bored with the project (because you guys should make it cooler than that.) not a good sign. doesn't matter, once qb64 breaks qb-like string handling, i'm using/endorsing old versions or forks exclusively. does it matter? nah. it's been a year since i've coded anything in basic. but it's still good for teaching.
i'm not in this one for the long haul. qb64 was qb like UNTIL just that point. there's still time to repent. the end seems nigh, though. sorry pete. i feel your pain, and (it looks like) you feel mine. see you on the other languages forums, perhaps.
NUL NUL NUL, that's not how you do it!by don't make me compare it to another dialect (no login)
"I'm not certain one would call it a bug; it's more just a nuance of the command. ;)
CHR$(0) is just that null-string terminator. If those are part of the strings you're comparing, you'll probably need a different method for 100% certainty of results. "
stop right there.
there was another dialect that got this wrong, and i think they even fixed it
BASIC IS NOT C.
basic did not have nul-terminated strings!
basic had cobol strings, where it tracked the length, not giving up on NUL.
i proved this to the devs of another language and they said they already knew. it was pure laziness because c drops a string at the nul. well, open up qbasic and see.
this function is already redundant and unnecessary. if qb64 can't even handle strings with nuls, PACK IT UP and close shop.
not joking. if qb64 can't handle nuls in strings like any other character, you might as well quit right there.
(and i'll join you.)
i wasn't going to issue any ultimatims (because who cares?) but if this goes wrong, i'm just done. i don't even code in basic anymore, a quarter of a century is enough time to focus on one language.
>>> q = "hey" + chr(0) + "there"
>>> b = "hey" + chr(0) + "are we good?"
>>> print q < b
>>> print q > b
now THAT'S what qbasic would do (except it says -1 instead of true and 0 instead of false)
your function is already (barely) a shortcut for code that works properly in qbasic.
your function (that saves typing how many characters? 3?) doesn't even work as well as the qbasic compatible code it's a shortcut for.
""I'm not certain one would call it a bug; it's more just a nuance of the command. ;)"
if that's a joke, i apologize. really.
if it's not a joke, fix it or resign. qb64 doesn't need that kind of "i'm gonna break it because this is how c++ works" attitude. go work for the other guys if that's how you really feel, they pull that all the time.
that's all i have to say about it. (try me.)
steve, this is how NOT to name a qb64 commandby mn64 (no login)
PRINT _NCSTRCMP("Dog","dog") ----> This would print 0 (Dog is dog)
okay, i know, even before qbasic (i predate dos 5) there were exceptions to the rule: VARPTR$ sounds like something you would catch on a cruise ship. (for the moment, antibiotics still help in most cases.)
but NCSTRCMP? please don't expose c++esque names to BASIC when you can help it. they're absolutely FINE names for c++ users. BASIC is supposed to literal when possible. MID$ isn't english, but it is the first three letters of an english word. it's not STRMDL$ after all.
oh you can say it won't matter this time, until your entire language is like vomiting alphabet soup. but if you're going to keep naming builtins like this, please include a bucket.
now i know you're practically in charge of development these days, so i'm really not intending this to rude so much as colorful. (technicolor yawn colorful, but i think that's fair right now.) it's not that i don't respect the work that you put in. it's just that it's a hideous terrible name, and making a habit of that will contribute to wrecking one of the best computer language dialects of all time. please take some care. and let's not debate this too much. you hear me, and that's good- or you don't, which would be too bad.
*AROSE$ by any other name would be BASIC? BUT, could thou any longer tell by reading it?by william shakespeare gates iii (no login)
and now for the constructive versionby mn64 (no login)
i really think the criticism in this case is more important than the suggestion. but there's still an opportunity here. obviously you have this construct, which i'm in favor of:
if x$ = y$ then print "match"
and for case insensitive checking, this still works:
if lcase$(x$) = lcase$(y$) then print "match"
but for some that's too messy, (but it's still pretty obvious what it does,) then you have this illegible thing:
if _NSTRCMP(x$, y$)
which is harder to read, redundant, and trades in compatible qbasic code for what? it barely saves typing...
but IF we're going to add a superfluous statement that's only a shortcut, at least let's make it a good one. i propose:
if match(x, y) then print "match" ' yeah you don't need this, it's same as if x = y then 'etc
if match$(x$, y$) then print "match" ' yeah you don't need this either. let's see steve's function:
if imatch$(x$, y$) ' i is a common way of saying "case-insensitive," but i welcome any obvious letter
or just call it match$ because the other forms of it (case sensitive, numeric) really are redundant and simply throwing away compatible code for qb64-only code, just to do so.
HERE'S A FUNCTION I WISH EXISTED
if _HOWBASICLIKE("_match$()") > _HOWBASICLIKE("_nstrcmp$()") then print "if the name fits, you must fix it!"
i do question how necessary this function is (shortcuts are not worthless, but they should be weighed against using compatible code. in other words, to be incompatible they should be really GOOD shortcuts, or not be added) but let's assume it must be added. i think the decision has been made. let's hope there is time to change the name (you know, before it's 6 months old and breaking existing programs.)
this one's for you pete. now i'll sit back and wait for jokes about "my ascii and your face," etc.-- don't let me down, pete. this forum is so tame, i think it might have been shot with a dart (and steve's to blame... don't give a function, A BAD NAME!)
woah, woah, woah. (i can't stand bon jovi, so i'm literally torturing myself to try to make a point here.)
How about _STRBEANS? That way, Steve can compare produce.by Pete (no login)
BASIC is also about building comparison routines yourself. One of the many reasons I lost interest in the project itself, besides the growing number of dullards at the forum.
Re: steve, this is how NOT to name a qb64 commandby SMcNeill (no login)
Which is why I threw it out there as a suggestion before making any pushes into the code. ;)
It's easy to say it's bad naming, but honestly any name will work. I'm more than content to go with whatever people like. I'm glad you don't mind telling me how poor it is, but why not suggest what you consider a viable alternative as well?
CHR$(0) is just that null-string terminator. If those are part of the strings you're comparing, you'll probably need a different method for 100% certainty of results. "
stop right there.
Not every command is suitable for every task. It's up to the programmer to pick and choose what suits their needs the most. Why else would we open files for INPUT, RANDOM, and BINARY all, when one could use BINARY to just do it all??
I'm certain we could check the string for CHR$(0), see if it's present, and then create a custom comparison routine checking byte vs byte and giving a result -- but by the time we did all that we'd be giving up a lot of the speed which we'd normally be looking for. It BASIC, it's all but impossible to generate a null terminated string, unless someone manually tacks that CHR$(0) on there. INPUT doesn't give us CHR$(0) line endings, neither does DATA, nor LINE INPUT #, INPUT #, INKEY$, or _KEYHIT.
For BASIC, how exactly would someone get CHR$(0) into a string to begin with?? None of your normal input or print routines work with it. The only way we get it is if we GET information from a BINARY file and it's in there, or if we place it in the string manually and on purpose.
If it's a binary file, we really don't need to be doing a non-case string comparison of things. Byte 65 probably shouldn't be counted the same as byte 94 ("A" vs "a") in a binary file. It's not really a suitable command for comparing those values; we'd be better off checking _UNSIGNED _BYTE vs _UNSIGNED _BYTE.
IF someone is putting CHR$(0) into their strings manually, those aren't standard BASIC strings; is there any reason to think that our commands must support custom syntax checking for them??
>>> q = "hey" + chr(0) + "there"
>>> b = "hey" + chr(0) + "are we good?"
>>> print q < b
>>> print q > b
now THAT'S what qbasic would do (except it says -1 instead of true and 0 instead of false)
your function is already (barely) a shortcut for code that works properly in qbasic.
your function (that saves typing how many characters? 3?) doesn't even work as well as the qbasic compatible code it's a shortcut for.
Except it's something completely different than the existing QBASIC code.
>>> print "dog" = "DOG"
_NCSTRCMP (name pending) is a non-case string comparison routine. "dog" is in fact graded equal to "Dog"...
The use?? So we can sort all our words of a list into alphabetical order, efficiently.
If we were to try to sort that using the basic < or > comparison results in QBASIC, we'd get all the Capitalized letters and then all the lowercase letters. We're not really sorting alphabetically in QBASIC, we sort by ASCII-code...
_NCSTRCMP gives us the alphabetical sorting of words and numbers, and it should work on the majority of QB64 text and strings. If you need to compare things like your example above, you'll need to write up your own compare routine. UCASE$(q) < UCASE$(b) would work for you -- but it'd be slower. A *LOT* slower, which could affect performance if you're comparing a whole swarm of strings at once, such as for sort routines.
QBASIC has a nice INPUT # routine which we can use to read text files. It doesn't work well with every ASCII character out there. quotes, commas, chr$(13), chr$(10), chr$(0) -- NONE of these work well with INPUT # or LINE INPUT#. In QB45, it'll even strip off extra spaces from the beginning or end of a line for you from what I remember....
It's part of the nuance of the command. It does what it does. If it's not suitable for what you need, then use a different method.
It's the same with the _NCSTRCMP. If you can use it, then do so. If not, then don't. There's nothing forcing anyone to try and use the command, and it's not going to replace the old standard <,>,= routines which we've always had. They'll still be there, same as always.
The difference is we'll now also have another tool at our disposal which works quite efficiently when we need it to. It may not be the hammer used to drive all nails, or the axe used to split all trees, but a hatchet can still be a useful tool to have in the right situations. ;)
this is a reasonable and thoughtful response, which is > i deserve, but there's 1 thing...by mn64v0954 (no login)
it's also wrong.
this is the "agree to disagree" stage. who knew we'd get there so quickly? good luck steve, it's still better than the other leading compiler. heck, it's the best basic compiler ever (i'm not even being sarcastic.) but we just reached my stop.
Re: this is a reasonable and thoughtful response, which is > i deserve, but there's 1 thing...by SMcNeill (no login)
It's never hard to "agree to disagree". That's what people do when they're confident in their opinion and someone else's varies from that opinion. ;)
I don't think every tool has to work for every job. By making something that's more versatile, it's often slower or bulkier than a tool made specifically for one job. Compare the Swiss army knife (http://theawesomer.com/wenger-giant-swiss-army-knife/65362/ ) to a pair of finger nail clippers... Sure, those nail clippers only work for a limited purpose, but I bet they're used for that purposes a million times more often than the other is!
Still though, I was going in and playing around to see what a custom routine would take to make and use to check for CHR$(0) properly for us, and guess what I found out?
QB64 has apparently NEVER properly checked for CHR$(0) terminated strings!!
"dog" < "dog" + chr$(0) returns a FALSE(0) to us. Other methods of comparing also can generate these same errors... >, <=.....
Apparently people don't compare strings with CHR$(0) in it enough to even notice and report a bug from the existing process; they're just not used a lot in BASIC. It's a glitch that's been around in the language since day one, and it takes the scrutiny of adding a new command to highlight the flaws in the existing ones. ;)
Sometimes though I got to admit I feel like I'm fighting an uphill battle with the language. Go to fix one thing and POOF!!!, first you have to go and fix something else first that no one even noticed was broken...
It's two steps forward and one step back it seems. :P
qb64: a situation where _OS$ might not work the way it is nowby mn64 (no login)
i'm basically agreeing with clippy on something here.
i can see how in most cases, the way _OS$ works now is fine and makes sense.
but the way it works now is (partially) based on a false assumption, and that assumption is this:
a. if it works on the version of [windows/gnulinux/mac?] that it was compiled for,
b. that it's running,
c. therefore, the version it was compiiled on is compatible with the current system it's running on
32 vs 64 bit is no measure of compatibility by itself...
there are certainly other differences among windows versions (95, nt, and vista all have 32 bit versions) that need to be coded around sometimes.
although i'm not offended by the current _OS$ implementation, i do think in the long run a statement that dynamically returns information about the running os is worth much more than one that knows what it was compiled on.
but maybe the reason the statement is so limited is that it just returns version info (which is static information from the compiler.) in that case it's a whole lot more work to make _OS$ work the way clippy and i probably agree it should...
in that case, it's not an unreasonable statement, just a statement that extremely limited. but fwiw, i agree that hindsight being what it is, _ver probably would have been a better name for the function as-it-is.
*don't worry steve, i'm not asking you to break anything years oldby mn64 (no login)
* I didn't think so. You aren't Clippy after all. ;)by SMcNeill (Login SMcNeill)
Re: qb64: a situation where _OS$ might not work the way it is nowby SMcNeill (Login SMcNeill)
"a. if it works on the version of [windows/gnulinux/mac?] that it was compiled for,
b. that it's running,
c. therefore, the version it was compiiled on is compatible with the current system it's running on"
The version it was compiled on has to be compatible with the current system it's running on. You can't compile MAC executables and run them on Windows after all. At least not without some emulator which gives you the Mac environment on Windows.
When you go into a store and buy a piece of software, you look on the package for "WINDOWS 32-bit" or "WINDOWS 64-bit" or "Runs on Linux!".... That's basically what _OS$ tells you in QB64; what you'll run on once compiled in the current version of QB64.
It's a shame that _OS$ can't make some sort of magical file that runs across all platforms, but honestly it's more of an #ifdef type statement than anything else. Write code using _OS$ as a toggle for calls between windows or Linux, and once it's compiled it's only ever going to work with one set of conditions; and that depends on what was used to compile it.
_VER may have been a better name, but it's a little late now to suggest changing it, I'd think. _OS$ has been in use for several years, and people are used to seeing it and using it. Who knows how much existing code would need to be altered to run in the future just for semantics sake?
I'm all for discussing and altering commands (even their names if added recently), but to change a name after it's been in use for an extended period of time just because something else sounds better? Honestly, I wouldn't advocate that even if it was called _HORSEDROPPING$. :D
all i was saying is that os$ will probably create false positivesby mn64 (no login)
you might be able to create a program that does actually run on 2k, despite being compiled for vista 32bit, and _os$ will be happy as a clam. this is a false positive as far as _os$ goes, because it's running and it's doing it vista style, but it's running in an environment where some assumptions CANNOT be made.
so i make a program that uses _os$ and it says it's compiled on vista. so how am i supposed to make my program routines win2k compatible if os$ won't even tell me it's win2k?
the thing is that on a binary level, 2k and vista might be compatible, but on a finer level, they might be very far apart. this makes os$ very half-assed for what you would reasonably expect it to do. i will give it that it probably does everything it was designed for.
so it's at least more than just a nitpick that the user/coder might really want to know what o.s. the program is running on, and it's too bad that os$ wont help them there. that's why clippy should have named the routine (_ver$ would have been perfect actually.) then we could make _os$ do what it ideally should.
incidentally, qb64 is built on the idea that breaking existing programs is one of the worst things you can do. you and i agree, and it is definitely too late to take functionality away from _os$ or rename it. if there's some other way this can be improved without breaking existing programs... could _os$ be further overloaded somehow? that's all i have to say about it. i'm more concerned about (hypothetical) non-optional OOP extentions coming in... if they're optional, i don't care unless all future (optional) extentions are OOP style: "yes all old qb64 routines are procedural, but we don't approve of procedural coding..." etc. so long as we're not headed for that dystopia, i'm okay. thanks steve.
Re: all i was saying is that os$ will probably create false positivesby SMcNeill (Login SMcNeill)
"i'm more concerned about (hypothetical) non-optional OOP extentions coming in... if they're optional, i don't care unless all future (optional) extentions are OOP style: "yes all old qb64 routines are procedural, but we don't approve of procedural coding..." etc. so long as we're not headed for that dystopia, i'm okay. thanks steve."
I'm certain if OOP is ever added to the language it'll be an optional addition. I don't think anything will ever be required. It's all about adding choices for the user, not taking them away -- like with the x64 version. It's not meant to force people to use x64 and drop x32 support, just give them the choice to decide what works best for themselves. When OOP enters (if ever) the language, I'm certain it'll work the same way.
Add to existing functionality, not destroy/replace it.
my (second) favorite language (ever) is 100% OOPby mn64 (no login)
... fsv of "100%"
no non-basic language is closer to basic than python (although fortran and cobol are obviously cousins.) i once went on a pilgrimage to the campus (and i think, the building / floor) where basic was invented. out of every hobby i've ever had, programming has been the most rewarding. i love logo, but basic (since age 5 a least)) was always cooler.
when i found python, i had given up on waiting for qb64 to live up to its original promises. (note: it did live up to them, and then some, within a year or two.) if they're not teaching basic at m.i.t. and as part of olpc, it's good that they're doing python. remember the classic "qbasic o.s.?" sugar almost is that for python.
everything is an object. everything. note that i don't care for oop concepts at all. they have their strengths, they have their place, and there is a subset of projects they really lend themselves to. but i don't like oop. the great thing about python is that someone who strongly prefers procedural coding can pretty much stick to it. if you're using someone else's code you can generally work around it your own way.
last time i tried qb64 (about a year ago) i didn't put it down until i was satisfied it was in fact, qb. it's basic, it is qb, it earns the name. underneath qb 4.5, everything is asm (more or less,) and underneath my python scripts, everything is oop. but i don't have to worry about oop-- it's there if i want it. if the python guys can create a modern basic-like language accidentally, i know you guys can do it on purpose. it's perfect so far... fsv of perfect, but it's the last really-basic out there (unless you're british, then there are two?) take good care of it. i still want to understand why pete's unhappy.
Re: my (second) favorite language (ever) is 100% OOPby SMcNeill (Login SMcNeill)
Pete can correct me if I'm wrong, but I think:
He's a simple guy with simple needs. SCREEN 0 does all he needs, and SDL was a "finished product" for what he wanted for his own use. Then Galleon decided to split the language over to GL-based; and even now, over a year later, not all the old functionality has been restored.
Sure, there's been improvements in graphics and hardware support, but he doesn't need those. What he could use is Android support, but that was delayed getting GL back to where it is now....
Then discussion about the future direction of QB64 was brought up. Galleon opened up his stance and said, "Hey guys, if you can add it, I won't stop you! GUI, OOP, X64 support.... Knock yourselves out! Just don't break the existing commands...."
And Pete said, "OOP?? What happened to Android??", and he basically got tired of waiting for the language to develop in the direction he wanted.
As it currently stands, I don't think Galleon has ever said his next step was OOP support. He said if someone wanted to add it, he wouldn't stop them... But I don't know of anyone who pushes to the repository who has actually shown any interest or direction in trying to work it in. NO ONE has said, "I'm going to introduce OOP by XX date..." At this point, I really don't see it entering the language anytime soon.
Currently Galleon is working for GWAN support, and then he'll probably go back to hardware acceleration routines for graphics. There's still a lot of bugs in what he's added so far, and a lot more to be added.
The rest of us are working on bug fixes as much as possible, and trying to fill in those last remaining gaps between SDL and GL functionality, with an occasional new command added as we need them personally. (Like I just needed the _CONTROLCHR returned to me for a library routine, so I added in a function to get its state back for us.)
I don't think Pete's really upset over OOP, as it's not really even on the foreseeable horizon of QB64's future ATM. I think he's just upset other things are being developed over the Android support which he could personally make use of.
*thanks for this great response. i won't take up more of your time... for now ;)by mn64 (no login)
Have you considered...by Luke (no login)
...that QB64 programs don't run on old versions of Windows? That there is a function to check the Windows version anyway? http://msdn.microsoft.com/en-us/library/windows/desktop/ms724439%28v=vs.85%29.aspx
no to the first one, yes to the second oneby mn64 (no login)
the version thing is a true tempest in a teacup. it's not ideal, it's probably stuck like it is, it doesn't raelly matter unless perfection is a goal. i mean it more than likely does everything it sets out to do and is simple. two out of two.
the past version thing is a fair point, the future version thing is hard to predict. some of clippy's points were valid, i think. there were a lot of points... (i should know...)
if i wanted to look things up on the msdn site, i wouldn't be using basic. kind of a pithy, silly answer but i suppose os$ is a compromise. it could be worse.
and given the rest of what's going on, i forgot about the _os$ command. it's kind of a shame that it doesn't run on all versions of nt at least, but i guess sdl (and gl) had requirements going in that... i always thought sdl was the perfect compromise because that's exactly what dosbox requires to run qbasic anyway. i've never tried running dosbox on early versions of nt, for example.
whogab64... possible dialects of nearly-basic and suchby mn64 (no login)
(it stands for who-gives-a-basic)
i spent a few years getting pissed off that the project to create a free version of basic, didn't.
finally, galleon did it. qb64 really is qb. it's free (either way,) it's not by microsoft, it's compatible, it bends over backwards to run old programs. (out is a nice touch. i remember the plans for out, as far as i can tell they're where they should be.)
now that qb won't die, i wonder what qb would look like if it were MORE basic. in my tutorial i tried to cover only things that were easy to teach and easy to learn. some were things i struggled to learn when i was in kindergarten, for example...
now i see handles for dealing with images. i can't really say that dealing with images has gotten worse, because in qb it was never good. but still, the more features that get added to qb64, the harder (not impossible) it's going to be to maintain as a simple language.
so i think it would be ideal if there were a qb64 derivative that was NOT called qb, didn't necessarily have "basic" in the name, etc. etc. etc. maybe it could claim to be a basic "inspired" language.
i don't need this language, and i'm not requesting it. but i think the idea of a basic-inspired computer language has potential. in fact i think there is room in this century for a COLLECTION of basic-inspired languages.
i wouldn't start from scratch. i would (if i really meant it, which i don't...) take qb64 and actually REMOVE features. (this is exactly why i wouldn't call it "qb" anything. nor "basic.") i like the name "whogab," but i think it would suffice as a working title (you know, the way "linux" was a working title.)
i would remove features that were too unfriendly-- starting with handles-- to make this new "basic-inspired" dialect.
note it isn't the *use* of handles i would get rid of, it's the syntax.
what would i replace qb64 "backwards-compatible" syntax with to make this other dialect? i would replace it with duck typing, a concept from python.
here's a string: "hi."
here's a string: 'hi.'
here's a string: """one
here's a string: "onentwonthree"
here's an integer: 5
here's a float: float(5)
here's an integer: int(5.0)
here's an array: ['one', 'two', 'three']
here's an array element: ['one', 'two', 'three']
here's a function call: import math ; print 4 * math.atan(1)
alternatively, here's a function call: from math import atan ; print 4 * atan(1)
(you only have to import once per program. it's a very smooth interface for external libraries.)
type syntax is messy$ and there are too many types. duck-typing is basic-like in a way that basic itself just isn't.
so that's one feature this hypothetical more-basic dialect would have.
i'm not trying to splinter an existing language. i'm trying to talk about a hypothetical language... to make a point? not even that. i'm just talking about a hypothetical language. it's so hypothetical, i don't even know why i'm talking about it yet.
and no, python is not really the most basic-like language there is. i really think it's somewhere between qb64 and most other basic dialects. you can't make a language more basic just by copying python, but i think python has at least one idea (this one) that could make a language like basic even easier to get started with.
the thing about python is that it's easy to learn, and by the time you think you're almost done with a task, you realize you're done sooner than expected. that's one thing i noticed about basic: you could lose yourself in the fun of it and be done before you expected to be: that "oh, wait-- it's actually ready to run" moment.
but the main thing that makes python more like basic is that they aim it at young children (through pippy, part of the sugar learning environment) and mit is using it for teaching (because it's a great introductory language for all ages) and it's ubiquitous: it's on every macbook, practically every gnu/linux system, and available for windows and dos. basic doesn't have the ubiquity it did in the 80s and 90s, where if you could see a computer it was more likely than not that it had a copy of basic on it, or at least sitting on the install cd. it's used on websites, and for games, it's used in almost every niche java is, (there's no python-os yet) but it's much more inviting.
i don't think whogab or more-basic will ever exist, and i don't mind. but even if most of them didn't make it through the year, i think it would be awesome to see a sudden proliferation of basic-inspired dialects of any language.
failing that, it would be awesome to see a proliferation of interpreted "languages" where the interpreter itself is written in qb64. they might be simple languages, but if you have enough people inventing simple languages of their own, two things happen: more than ever, people are really thinking like programmers. also, you're going to see some neat ideas that way. that would be pretty cool.
if you want a cheap, pathetic excuse for a way to implement duck typing in your own interpreted language and you don't know how to make a good interpreter, try this for typing: handle just strings and integers... for starters. maybe then add an array OR a string that handles n or even chr(10)
but just strings and integers:
1. take your value as a string and convert it, see if it's zero. if it is, convert it to integer 0.
2. any other value, convert to an integer. if it turns to zero or errors, it's a string. else, it's an integer.
so that's poorman's duck typing. it's not what i'm suggesting for whogab, i'd suggest proper-quality duck-typing routines for that. but the great thing about making a toy interpreter for a toy dialect (i have done this once or twice) is that you can have a toy type-manager. it doesn't have to use $ for strings or & for handles. it just has to be light enough on features to be manageable.
just a thought.
btw, "such" would be a great name for a toy computer language, but only if you don't mind its detractors noticing how close the k and h keys are.
A dynamically typed BASIC is an interesting ideaby qbguy (no login)
Since QB64 generates C++ code and C++ is a staticly typed language, modifying QB64 to compile this language instead of QBASIC would require some work since you would need to make a tagged union variant type and then make helper functions on top of the libQB functions that take this variant type; unless you mean a staticly typed language in which variables' types are assigned automatically by first usage?
I implemented an interpter for Scheme (which is dynamically typed):
It only supports symbols, lists, and numbers (which are currently just BASIC integers (or floats if you change the types of some variables), not arbitrary precision integers) -- nowhere near the complete Scheme feature set, but it demonstrates closures, nested functions, dynamic typing, stop and copy garbage collection, etc.
obviously whether a language is static type doesn't determine dynamic type supportby mn64 (no login)
apart from your own example, i gave a description of how to implement a small degree of dynamic typing from the ground up. it's not like dynamic typing is magical, strict typing is just there for security and formality (depending on the application, it's even there for convenience, but not if you're just trying to make fun scripts. python has plenty of serious applications despite duck typing.)
the python interpreter is implemented multiple times in multiple languages, but the most popular implementation is the "cython" interpreter, which is written in c. it implements a duck-typed interpreter just fine. i'm sure i missed the point here, and i'm not blaming you. i just missed it (unless i got it here.)
incredible program, by the wayby mn64 (no login)
how come you never add license info anymore? the way you've posted it i can run it or download it, but nothing else. i ask because i thought you used to include at least a public domain dedication. was that another guy?
you could give (or imply) permission to do other things, but without a license it can't be reused very far without being entirely rewritten. it's a pretty awesome project, even if you're finished with it. philosophical shift?
There's no conceptual difficultyby qbguy (no login)
I thought it might be difficult to implement a compiler (rather than an interpreter) for a dynamically typed BASIC just by tweaking the QB64 code because QB64 translates to C++ in a relatively straightforward way, but you probably wouldn't need to change the compiler's code generation very much, just wrap functions in the libQB runtime to take the variant type.
For an interpreter, dynamic vs static typing doesn't change the implementation difficulty much, but for a compiler it might. e.g. automatically translating a program in Lisp to Python would be easier than trying to translate it to C.
Even the most elementary programmer should understand data types.
I think the convenience factor of dynamic typing is negligible. At least for the fundamental types.
For more complex classes, there might be an argument for a certain amount of dynamicness. For example, I think that's the one of the arguments for Component Object Model.
C++ has RTTI, but I've never needed it, never used it, and haven't really looked into it much.
But the idea of BASIC inspired language is perhaps a good one.
that's surprising, when you break it down into what it really entailsby mn64 (no login)
you totally strike me as the type of person that would prefer a strongly typed language, too.
but you're not actually, are you?
you like dos, which is great when it's doing cnc (and you don't want duck typing then!) but i've used debian with a realtime kernel before. (it's not that exciting, and i only assume it could handle cnc. the distro had a realtime kernel for the sake of music processing. it's probably the closest thing i've used to dos in terms of cnc usability, other than dos i mean.)
but dos is 16 bit, and how much precision can you get out of that environment? myst knows strong typing better than anyone (mr ada) but 16bit and 640k and paging and basic isn't even as type-strict as it could be. are you SURE you'd never be comfortable? because here's what i'm really getting at:
you're a systems guy, you like to know how things work. in my opinion it's really just about whether duck typing is more predictable than the less-predictable parts of c++, or more predictable. because c++ may have very good typing (i wouldn't know, it wouldn't surprise me) but in the end, strict typing is about predictability. if c++ is predictable enough when you understand the exceptions, i bet duck typing on a well-supported all-purpose language interpreter would be predictable enough, too. but i'm not trying to tell you anything. i'm only guessing i'm right, and it isn't with a strong-type conviction. i could be way off.
in any case, there's an easy to have the best of both worldsby mn64 (no login)
a language that uses duck typing in general could make an exception for any variable that you bothered to declare with a type.
in other words, you could say a = "5" ; a = int(a) to convert string a into integer a, but NOT if you declared a with a type beforehand. once you declare with a type (which is always optional,) it doesn't let the type change. so that's per-variable (optional) strict typing.
if that's not enough, you could have a statement like noducks(0) that only allowed declared variables throughout the program. noducks(1) could allow duck typing only in libraries and code includes (libraries), and noducks(2) would only disallow duck typing for the current scope (inside main, but other functions could use ducks; inside the current function, but other functions could use ducks.) 0 would be absolute and any other number would be less strict as you moved further from 0.
but duck typing by default, yes! i understand the advantages of strict typing, and the situations where they can actually make some things *easier.*
i just want to be able to sacrifice those advantages for fun and quick-and-dirtyness. basic's all about it!
Do you mean predictable as in the amount of time it would take, as in this code takes so many microseconds, or predictable as in the results, what the program does?
If the latter:
a = 5
b = "3"
c = a + b
Is c 8, or "53"?
If the former:
The realtime issue wasn't my main concern. As it is, most high level programers are not concerned with *exactly* how many clock cycles a particular piece of code will take, though many would prefer it to be as few as possible. So, I don't usually need to know if my function will take 20 cycles or 30 cycles, but I would, of course, prefer that it take 20 rather than 30.
I assume that that's what you were talking about, since you brought up real time operating systems, and paging, which would be completely irrelevant if you had meant the other kind of predictability.
Generally, dynamic typing would require code at runtime to figure out which data type a variable actually is, and act appropriately.
So, for example:
c = a + b
The plus operator needs to have some logic:
IF they are strings THEN
ELSEIF they are integers THEN
which takes time. As I don't write realtime code, I don't need to know how much time it adds, just that it adds time and space.
I as a programmer know whether I want to add or concatenate, and static typing allows me to just say it. It also allows the compiler to generate the right code at compile time, and not require a run time check.
I'm not condemning dynamic typing. There might be situations where it would be useful. But for most programming tasks, including elementary ones, I think that static is better.
duck typing = "reasonably" predictable typingby mn64 (no login)
If the latter:
a = 5
b = "3"
c = a + b
Is c 8, or "53"?
in python, that actually gives you a type-related error as most languages (including basic) would. in a language that took duck typing a step further, you'd have to rank types.
for example, i would personally make strings king (it would be "53") but dynamic doesn't mean striving for chaos. chaos can enter strictly typed things too, it just loses frequency of circumstance and leaves you slightly more surprised if it happens. strictly typed != bug free, after all. it's bug resistance.
with today's attention span, i suspect strict typing is like anti-bacterial hand soap: "kills 99% of bugs!" (small print: "33% of the time...") but i'm just trying to say something obnoxious enough to summon myst.
whatever type outranks the other is the one that could combine into, if throwing a type error isn't "dynamic" enough. in python lists (arrays) can mix types: ['5', 5.0, True, -7] but then the list is a type. is ranking types so unreasonable? not if you don't have too many types. then it's really just an order of operations. you could make it so that + always adds mathematically unless EVERY type is a string, only then does it concatenate.
since it's hypothetical, what do YOU think the most intuitive answer to your question would be? that could be the answer, because even a dynamic interpreter doesn't "guess." it still follows rules.
>> Generally, dynamic typing would require code at runtime to figure out which data type a variable actually is, and act appropriately.
i'm sure it's much easier in an interpreter (bytecode or otherwise) than a compiler.
So, for example:
IF they are strings THEN
ELSEIF they are integers THEN
-- just pick one, language designer. try to make it one that will trip up people the least. --
>> I'm not condemning dynamic typing. There might be situations where it would be useful. But for most programming tasks, including elementary ones, I think that static is better.
yours is a legitimate view, one that many share. of course i'm not alone in thinking duck typing has merits, too. that's why it's in a language that has so many non-hypothetical uses.
still, i'm not trying to prove it would be a cool feature. i just think it would be fun, and there's some time-tested examples of it being tolerable to code with in the context of a beginners (and serious) language.
That makes sense. The language designer would have to pick an action. It would be like an order of operations, as you said.
I also agree that static typing doesn't eliminate errors.
By the way, do you use exception handling in Python, and if so, what do you think of it?
it's way better than error handling in qbasic (but i think msft never finished it anyway)by mn64 (no login)
there was a typo in the documentation for on error, which lead you to beleive it had slightly more features than it did.
originally windows was going to have window stacking, like it did in versions 2 and 3. but in 1.01, it was tiling only. i suspect they had more plans for qb, but they had to ship sometime.
my only gripe with error handling in python (the errors have names instead of numbers, that's an improvement by itself) is that python is case-sensitive (which usually doesn't matter, because you can do virtually everything in all-lower case) but alas, i think some of the errors are camelCase.
that one aspect of error handling is probably one of the most annoying things about python... which is to say that you have to really try, if you want to find an annoying thing about python. there's also too much boilerplate needed to do graphics with pygame, which is to say about twice as much as qb64 requires (qb64 is pretty good about that, qbasic was just amazing, python is half as good as qb64 about it.)
quickly: re: "I think the convenience factor of dynamic typing is negligible."by mn64 (no login)
i respect and admire you as a coder. i respect and admire your code. and i think you're insightful and thoughtful, and good at seeing things for what they are (generally speaking.)
that said, you're the last person i would go to if i wanted someone to define "convenience!" lol, if it helps, i don't do everything "the easy way" either. i sympathize. but the point stands. :)
I can understand the convenience of static typing with implicit declaration in BASIC, (not using the DIM), for short programs.
imagine what it would be like to NEVER need to worry about typing againby mn64 (no login)
now change NEVER to "you pretty much generally don't have to, unless there's a bug, which is generally easy to figure out."
it's not a nightmare scenario in practice. but this phrase pretty much sums up duck typing for most of the things you'd use python for:
"one less thing to worry about."
it's probably not one less, it's probably 0.75 less, but in duck typing there's no difference between 1 and 0.75 anyway (ha! only joking... type humor.)
so take any 20 lines of code and imagine what it would be like if type didn't matter, if it just worked anyway. that's not what it's like (it's slightly more involved and a lot more predictable and less mysterious,) but it's definitely getting closer to the point of it.
*if it really makes things easier & everything doesnt turn stupid,it's probably a ducktypeby mn64 (no login)
In practice, are you talking about changing a variable's type during its lifetime, or just implicitly guessing a variable's type from the first assignment?
Changing during lifetime:
a = "Hello"
a = 5 + 3 - 1
a = "Hello"
b = 5 + 3 - 1
In the latter example, the only difference from QBASIC is that I didn't have to use $. It reminds me of the new "auto" keyword in C++11.
In either of the above examples, it is obvious what the code should do, and a smart compiler could turn it into static types.
But in this case:
DO UNTIL EOF
PRINT a + b
It could be an integer or a string, or a combination, and the compiler doesn't know, because it doesn't know the file that will be read. This is where dynamic typing would be consequential.
The compiler could turn it into something that would act like this:
DO UNTIL EOF
if isnumber(a$) THEN
IF NOT isnumber(b$) THEN raise exception
PRINT VAL(a$) + val(b$)
IF isnumber(b$) THEN raise exception
PRINT a$ + b$
If that's the result that you want, then it is obvious that the 5 line example is more convenient than the expanded example.
(isnumber could be a cached value, so that the data wouldn't have to be analyzed each time. In OOP, it could be a member of a class.)
bothby mn64 (no login)
functions have more or less identical scope to functions in qbasic, and their modular aspect makes code work without worrying what types are going into what functions. again, it's not the free-for-all you might imagine, it's a "conservative" level of chaos which is mitigated further by any level of code organization at all.
python is fully but optionally oop, so i have to think classes do even more to mitigate the willy-nilly nature of duck typing. (but since i have no class, i have to guess how useful it is.) either way, if it were such a crazy thing to do to a language, it would be a different sort of inconvenience to have the freedom of duck typing over the strictness of real typing. it's not a different sort of inconvenience though, it's just a different sort of convenience (as is strict typing.)
Your mention of function parameters reminded me of templates in C++. I have limited knowledge of them, but my understanding is that it's like writing a function once, and then letting the compiler duplicate it (as needed) for multiple data types.
Clean up on isle 5. Someone OOPed on the forum.by Pete (no login)
And a duck is a camel an OOP programmer put together. It may walk, and it may quack, but it will never fly in my world.
BASIC = Procedural + Static
there's so little to do to convert a qbasic program to a python programby mn64 (no login)
for some poorly designed basic dialects, this is all in a day's work.
for python it's very extraordinary, because it has been around for decades and wasn't even directly inspired by basic (it doesn't try, or claim to be basic. but it's CLOSER to it than most modern "basic" dialects.) --> and i don't do oop code.
nothing is more irritating than hearing how little it's going to take to "convert" your program from one dialect to another. unless you're converting it to another computer language entirely, and it's easier-- then it's pretty cool!
also basic may be static, but it's looser about variables than python is, not stricter. in python (like basic) you don't have to declare variables with a type, but in python you do have to set the variable with a value before you refer to it. using it on the left of a for loop luckily counts as setting it: for p in range(0, 5): pass
not telling people to switch from qb to python. just saying that basic has a wealthy (though bastard) cousin, which has some fun ideas. if i were going to preach that people should use oop, i'd do it on the "programs you should be ashamed of" subforum. we're not preaching, and we're talking about basic-- but if it gets too far from that, we can always use the all-computing subforum. i don't think it will hurt to make it look like this forum is active though. this is still where people post first (when and if they post.)
Maybe with plenty of pixie dust...by Pete (no login)
Program language conversion is never easy, unless you only make SIMPLE programs, like Steve. "Hello Crops" comes to mind, but I digress...
I even had to take an FNexorbitant amount of time to convert my modular QB programs to QB64.
Python has virtually replaced BASIC as a starter language for students, so the Hello World is turning OOP-side down, no stopping that.
Oh, and in regard to forum activity, this place just keeps on plugging away, especially when you consider the time that has past since QB went unsupported. It is just in its Karma. As for where things get posted, this is after-all the main discussion forum, and all talk regarding and related to BASIC programming for either QB or QB64 is welcome here; but simply put, other than contrasting differences, this is not the place to discuss OOP as an unrelated topic.
if it helps, we were mostly talking about duck-typing in (SOME) basic context. duck !=oopby mn64 (no login)
i realize you probably don't give a duck... and that's just ducky!
(if we really get out of hand let us know and we'll "duck" off, i mean, duck out to the other forums...)
* I'm working on my 4" Android keyboard, so I have my "i" on "u".by Pete (no login)
*had another subtle retort 4 that, but you can only be subtle for so long before youre notby mn64 (no login)
* Glad it's subtled.by Pete (no login)
Somebody has posted a few of them here and in other forums here. They go to N54 Search and cannot be found.
Like I told Solitaire, just delete the part of the URL after the message id and slash:
input in qb and pythonby mn64 (no login)
the best advice you can give someone who wants to use the INPUT statement in qb is: DON'T. it's garbage.
use line input or input$, and convert strings to numerics (if you want float or int, convert string input to float or int.) that's how you do it in basic, unless you prefer it to be a mess.
same in python. i don't know if it has the equivalent of INPUT but input tends to work in strings.
p = raw_input("this works like line input: ") ; print p
g-wan, eh?by mn64 (no login)
in case someone may think i have something against g-wan, i have absolutely nothing against it. if i say it "isn't needed," i do NOT mean "it's useless and no one should bother with it." or anything like that. it might be really freaking awesome.
i'm not here to diss the g-wan idea. i'm sure i don't even understand the g-wan idea.
i'm not here to ask for anything. i'm here to explain something as simply as possible (but not more simply than that.)
i'd like to see qb64 be better for cgi scripts. that's the only reason i even bring up g-wan (it seems to have something to do with that.) maybe everyone understands what g-wan is about, it seems to have some things about it i don't follow (that's ok, they might be there for good reason. i have no idea.)
if i mention how "necessary" g-wan is or not, i mean this and only this: IT WOULD NOT TAKE VERY MUCH to make qb64 better for cgi/webservers. it would not take very much at all!
what makes qb64 (and i mean the last version i tried, which was a while ago) not-really-great for cgi is all the graphical overhead. i know the g-wan author mentions something like this. i'm not trying to take any credit for anything matt (same matt?) or galleon are already working on. i'm just here to talk about the minimum qb64 would need to be good for cgi scripting.
the minimum is this: there should be a (hopefully trivial) way to print to stdout. i know i managed it before (i'd actually have to look up how i did it on the other forum.) but when i did it, i had to run a fake version of the xserver or qb64 programs would complain that x wasn't running. in other words it was trying to open a window. that's the main thing that has to be changed, right there (there needs to be an option for this in qb64, if there isn't one already.)
main thing you need to do cgi scripting and run a nice qb64 server is be able to PRINT "content: text/html" + CHR$(10) + CHR$(10) ' (i'm pretty sure it's 10...) and also read input.
a long time ago, i used to talk about reading from stdin and/or POST using qb45. did i use command$ or did i use input$(1) or inkey$? env$? maybe env$, don't know. i do know that matt (same matt? don't know) did it before i did. so qb64 may have pretty much everything it needs ALREADY.
i'm not against an extra (superfluous) library to make it more friendly to interface with cgi. i don't think qb64 needs its own server (i'm fine with it as long as it's optional, and opt-in) because running a known server is better for real use. (the builtin python server for example, is better for testing something than running production.)
so to recap:
1. make it easy to turn off the window / make it so it doesn't open in the first place (as an option! don't change the default behavior which is to open one)
2. make it easy to PRINT to stdout (i think it is already)
3. make it easy to read the environment variables / POST requests (i think it is already)
4. (optional... perhaps this is the point of g-wan) make it easy to receive GET requests (may be it is already. it would be a plus, for sure.)
qb64 may have all these features already, so long as you're willing to work around the 1st point like i did.
if i figure out g-wan i'll talk about it, until then i'm not 100% certain that any item on the above list isn't already possible with qb64. i think a couple could probably use tweak-level improvement to make qb64 GOOD for cgi.
lastly of course, (and credit where credit is due) galleon and g-wan i think both mentioned making qb64 more modular. as far as i can GUESS, this means that if you compiled a qb64 program to be used for cgi, it would compile minus some of the stuff you don't need running (like opengl or sdl, whatever it uses now.) if it doesn't do that already, that would certainly *help* in this context. it certainly wouldn't need to be another "flavor" of qb64, above all it wouldn't need to change ANYTHING for someone who isn't doing cgi or running a qb server.
what g-wan does beyond these items, i claim ignorance. i'm not trying to discourage g-wan, i'm trying to outline the minimal number of changes (if any) that would make qb64 good for cgi / server use. beyond the fairly simple points here, i've got nothing in that race. it could do twice as much already, and i wouldn't know.
INPUT$(1) worksby qbguy (no login)
CONST plain = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"
CONST cipher = "NOPQRSTUVWXYZABCDEFGHIJKLMnopqrstuvwxyzabcdefghijklm"
PRINT "Content-type: text/html; charset=utf-8"
PRINT "<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Strict//EN'"
PRINT "<html xmlns='http://www.w3.org/1999/xhtml'>"
PRINT "<head><title>Online ROT-13</title></head>"
PRINT "<body><h1>Online QBASIC ROT-13</h1>"
PRINT "<form method='post' action='/cgi-bin/rot13.exe'><p>"
PRINT "<textarea name='string' cols='80' rows='12'>"
' string= is 7 characters, skip it
IF VAL(ENVIRON$("CONTENT_LENGTH")) < 7 THEN 1
z$ = INPUT$(7)
FOR i = 1 TO VAL(ENVIRON$("CONTENT_LENGTH")) - 7
x$ = INPUT$(1)
IF x$ = "+" THEN
x$ = " "
ELSEIF x$ = "%" THEN
x$ = CHR$(VAL("&H" + INPUT$(2)))
i = i + 2
x$ = x$
z = INSTR(plain, x$)
IF z THEN PRINT MID$(cipher, z, 1); ELSE PRINT x$;
PRINT "<input type='submit' /></p>"
PRINT "<p>ROT-13: A simple cryptography system that substitutes each letter"
PRINT "with the 13th letter down the alphabet, rotating back to the beginning."
PRINT "The algorithm that encodes also decodes, because there are 26 letters in the alphabet.</p>"
PRINT "<a href='http://validator.w3.org/check?uri=referer'>"
PRINT "<img src='http://www.w3.org/Icons/valid-xhtml10-blue'"
PRINT "alt='Valid XHTML 1.0 Strict' height='31' width='88' /></a>"
This worked when compiled with QuickBASIC in an older version of Apache on Windows which supported 16-bit CGI, but QBASIC inserted extra hard line breaks when printing long strings. The double line break here is accomplished using a PRINT statement to create a blank line (documented in QB7.1 help but not QBASIC help). It seems to work now when compiled with FreeBASIC (-lang qb). QB64's exes depend on X and using the actual stdin/stdout is a bit more complicated.
fun!by mn64 (no login)
any idea what this g-wan stuff is about? or who "matt" (its author?) is? it's not our old matt, from the chat room is it? (he did cgi stuff in qb, so it would be appropriate, but i figure he's given up basic and moved on to perl or something. just a guess, of course.)
Re: fun!by SMcNeill (Login SMcNeill)
Matt is DSMAN12345 (or whatever that number sequence is at the end of DSMAN). He's the nice fellow who created the #qb64 chat channel on irc which we all still hang around in and chat on. Right now he's finishing up his college studies, working as an intern somewhere (it's a requirement for school before graduation), and just swamped with life stuff.
Lots of spam has been posted here,by Solitaire (Login Solitaire1)
most of it in foreign languages. I deleted all of it.
We keep getting flooded with spam in foreign languages.by Solitaire (Login Solitaire1)
I've been deleting them, but is there any way to prevent this?
The posts have been in French, Chinese, Russian, and who knows what.
pete must knowby mn64 (no login)
you can stop people from posting without registering, although at that point you might as well put the forum in archive mode. n54 will never get more features to help with this.
maybe there is a captcha, i don't know if you can apply a captcha to every post. it won't stop people from spamming by hand, only bots (it might make no difference at all.)
they focus on the popular subforums, like this one. if n54 is active, it needs to be handled by at least two people. preferably you and pete. i've left him a number of messages here (the original in response to a concern he had about qb64) but it's only been a day or two. i'm sure he'll get around to to them. he doesn't come here once a day from what i can tell.
but pete would know all the options. you guys talk on the qb64 forum, right? i'd ask him. thanks for deleting the product spam (knockoff clothing, etc.) if you didn't, i think it would accelerate.
also an offer, with caveatby mn64 (no login)
i'd be happy to mark spam for you, with *SPAM (asterisked, but no content in the post for real this time) but this could possibly make things worse. it would enable you to find spam from the index with just ctrl-f, at which point you'd still have to manually delete it (i wouldn't have it any other way) but:
even for this purpose, it is possible that marking it *SPAM would only encourage the bots. if they're bots, they might post more regularly when replied to. n54 has been static of new features for a long time, it's abused heavily (i would say the entire n54 website is mostly spam on forums. real content is the exception.) it's not silly to think that there are bots doing this, and marking it might make it worse. just sayin'. i'm happy to do it if you think it will help.
i can see the flaw with this planby mn64 (no login)
the flaw is it leaves twice as many posts to delete.
perhaps then the solution for anyone helping to find spam is that they only mark a spam post which is N hours old. 12? 5? your call. ultimately if it's not helping the moderator(s), (you) it's not worth marking them.
It's not an issue of there being twice as many posts to delete, as deleting the parent deletes the child. But it does seem a little like a waste of effort, as the mods should be able to recognize spam themselves.
My suggestion is that if you see any spam that isn't on the top page, that you mark it. For example, sometimes the bots will reply with spam on a thread somewhere on page 10 or 20. It is visible from the index, because it is the latest post. But if anyone posts anything new, then it won't be recognized. That is where I could see posting "*SPAM" might be useful in allowing them to be searched for later.
Did you read them? Use Google Translate?by Clippy (no login)
*Several were posted using Russian or Chinese characters.by Solitaire (Login Solitaire1)
I deleted several more.by Solitaire (Login Solitaire1)
One was in Italian, one in Polish (I think), with dozens of links. Another one was in broken English with several links. It appeared to be some radical political message -- wonder if it's some terrorist group looking to recruit sympathizers.
Some of the posts could not be accessed ("not found"). They were listed under a legitimate post, which I had to delete in order to remove the rest.
whoa, is deleting legitimate posts the new policy?by mn64 (no login)
if legitmate posts are going to start being deleted to get at spam, there's not much point in posting here.
there's very little point in posting here as it is (meaning only: there is so little activity here to call it "participation") and if spammers can get legit posts deleted now, you might as well lock the forum. i hope i misunderstood your post.
It wasn't important, or I wouldn't have deleted it.by Solitaire (Login Solitaire1)
It was someone saying he needed to change his forum status. It had been taken care of, so the post was no longer needed.
*ok, cool, thanksby mn64 (no login)
You don't have to delete the parent posts. Just manually modify the URL.
For example, the URL to your post is:
But it can be accessed as:
So, if there is something in the URL that Network54 chokes up on, just delete everything after the message ID and the slash. Then go to that URL, and you can delete the post. I've had to do that a few times in the last week or so.
And, yes, I did run one of the spam Cyrillic posts through Google translate. It seems to be spam for some travel agency or something.
qb64 vs. q-nb-64by mn64 (no login)
hi pete. as a fan of procedural programming too, i am genuinely concerned about your post suggesting that qb64 is straying from this.
i am less concerned that oop features will be *available.* i am more concerned that qb64 would bolt on oop features that are foolish (i'd be even more concerned if it were anyone but galleon or myst doing it...) and then try to drag users towards them... the favorite word of the group-that-will-not-be-mentioned (OOPs!) was "deprecated..." i certainly do not want to see procedural basic "deprecated." (they defe, i mean deprecated all over it the last time.)
again i can't stress enough that if someone can do this without screwing it up, it's galleon and (hopefully through emailed suggestions if not actual code) myst. though to be fair to your concerns, i've seen galleon get a little syntax-happy before, and it's not always as good as it could be (the syntax, i mean.) but new syntaxes are almost impossible to get right, i bet it could be loads worse.
all the more reason to be wary of too many changes at once. can you direct me to a link or two where i might read about these changes? or if you don't want to google it for me, could you tell me more about your concerns? i still consider qb64 the language/dialect i would recommend to anyone that absolutely must code something in basic. it's done a much better job of preserving (and extending) a legacy than anything else, i'd hate to see it abandon that direction. i hope you're wrong, but given who this is, i wouldn't dare ignore a critique that a dialect is getting too "not-basic." it should be taken seriously...
one more thing...by not steve jobs (no login)
on the qbzips html page (the downloads page for this forum) it lists my tutorial under the peculiar heading "clippy's tutorials."
considering that i put practically everything in the public domain, i'm much less concerned that someone might think clippy wrote my tutorial. but the thought that someone might confuse me with him... you can see how one might lose sleep over such a thing. at any rate, i thought i'd mention this as long as i'm in the neighborhood.
hey there mr calkins!by mn64 (no login)
see you on the index. always a pleasure. if you know what pete's concerns about the progression of qb64 are about, i'd like to hear more from you, too.
don't worry, i'm not here to try to convince anyone to change it. if i see something truly heinous i'll make a case against it. i still think the most BASIC language of the 21st century is python, but it's qb64 immediately after that. (note i sometimes say the same thing with the names in the opposite order.)
It's nice to see you again.
I haven't been doing much programming lately, and I haven't been following QB64 for about a year or so.
Actually, I've been spending a lot of my time watching TV. We have some new digital broadcast subchannels, (both are subchannels of the local Univision station), specifically: 41.2 GetTV (1930s thru 1960s films, mostly Columbia) and 41.3 Grit (westerns, war films, such as john wayne, clint eastwood, audie murphy).
So, I have become obsessed with watching old films on those two channels.
The family bought an Acer tablet running Android, but I haven't tried programming anything for it yet.
I've seen Windows 8 and 8.1 on laptops that I work on.
I think that most of my future programming will be in C++.
A cool front blew in a few days ago, bringing the temperature down to mild, and bringing the dew point down also. I look forward to October, for the better weather, the baseball post season, pumpkin pie, deer hunting season, etc... (P.S. Also, the local peanut festival.)
How are things going with you? I understand that you moved from D.C. to the west coast some time back?
I'm still in Wilson County, Texas. But I'm finally out of the rat filled mobile home. My parents had a garage built, and it has an attached apartment that I'm staying in. In exchange, I'm supposed to do ranch work for my dad on Saturdays. I burned up the engine on my jeep a few months ago. I'm wanting to buy a bicycle at some point.
I've been disfellowshipped from Jehovah's Witnesses for 2 years now.
I've been trying to learn other languages. Specifically, I want to learn German and Hebrew. I had been using duolingo.com to try to learn German, but I don't have internet access at the apartment. I have audio recordings of Genesis 1 in both German and Hebrew that I can listen to. I'm still a noob at both. English remains my only conversational language.
west coast, you say?by mn64 (no login)
i've been to the west, never the coast. i don't live in dc anymore, that much is correct. don't know where you got west coast but it's certainly no problem.
what's your status other than disfellowshipped? still interested? skeptical? i don't know why i ever truly *cared* what your beliefs are, other than for conversation's sake (in other words i'm interested, but i can't imagine it makes a difference which way you lean now.) i'm still agnostic, so it's still *possible* that j.w.'s will be right about everything (but given how exclusive that makes salvation, i kind of hope they're not.)
windows 8... i've been helping people avoid windows 8. i've actually gotten some older members of the human community (greying hair and all) away from windows long enough that when they get windows back, they don't want it, or they prefer gnu/linux to even windows 7. granted there are plenty of cases where people aren't going to be convinced. i've gotten some average-aged adults to give it a real chance also, but in a world where everyday people are willing to throw good money at e-books designed to self-destruct (scholastic is evil) it's uphill all the way. the easiest way to install windows 8 on most machines is to turn uefi off, but uefi and secure moot are not the most disturbing new hw features.
systemd looks like it's going to be very ugly for a while, if not as long as it's foisted on people. i definitely prefer sysvinit, but i'm trying to stay open-minded (the systemd devs certainly aren't.) this isn't on principle or anything, i'm just trying to figure out how much of my time it's worth.
i've never had anything against c++ because i've never had to use it. most likely the browser i'm using to type this was done in c++ so i guess i can't say too much bad about it. it seems like a lot of burden to put on the user, but so does a plow. i'm pretty sure i would take c++ over asm, too.
*that is, "install something OVER windows 8"by mn64 (no login)
dualbooting requires uefi, but dualbooting is ideal for a group of people that don't exist.
i'm not against dualbooting, it's just the only people who think they want to dual boot probably either want to switch or stay where they are. yep, this is an asterisked post.
just to let you know that I read it.
NOTE to mn64: Do not begin post title with an asterisk*by Solitaire (Login Solitaire1)
In this forum, it means that there is no content in the post, so no one will bother opening it to read it.
it's a joke/tradition of sorts, like an easter egg (easterisk)by mn64 (no login)
you/most use an asterisk to say "there's no thread, just this title"
i use it to say "there's nothing important in this thread, just the title matters."
identical syntax, very similar routine.
i never put much in an asterisked post... been doing it for years, michael always(close enough...) reads the posts inside. i think pete actually started it, but who knows?
we only use it for mischief, and never for real evil. glad you're still here.
*i never counted on itby mn64 (no login)
I assumed west coast, because I remember you saying something about being closer to Pete, although "closer" is relative.
I still agree with major Witness doctrine, and believe that they are the correct religion. But I have been unable to live up to the moral requirements. Specifically, I have struggled with pornography addiction, which has been something that can result in disfellowshipping since 2006. (My addiction goes back further than that.) I was not discovered and "turned in", but confessed. I don't wish to discuss the details publicly.
I don't know the details of UEFI, but I do think that some form of secure boot is a good idea, to prevent root kits. I disable secure boot to boot to Memtest86+, then reenable it.
C++ is a high level language, and is much less tedious than asm. C++ has two main disadvantages compared to QBASIC:
- It is unsafe, largely due to undefined behavior. (Compiler warnings can mitigate that.)
- Its standard library doesn't have anything for graphics, sound, or even color text. You have to learn and use 3rd party libraries like OpenGL, or operating system APIs.
My own computer is still Windows XP, despite the end of updates.
I like Windows 7. I don't have any major complaints about its usability.
Windows 8.1's desktop mode is basically the same as Windows 7, except for the start menu.
no it's ok, that's enough detail alreadyby mn64 (no login)
i have the same "addiction," i'm just not interested in curing it. best of luck, although it really is stacked against you (i suppose not having net access in your apt helps.) you could always try thinking of margaret thatcher. even if you had a thing for old ladies, she's fairly repulsive. (martha stewart's pretty hot though!)
secure boot won't save you from rootkits, nor will any kind of hardware signing. having locks on your hardware means that when you do get infected with something truly insidious, it will be harder for you to access the system to remove it. (windows, for example.) i realize that secure boot can be touted as an imperfect solution anyway, but i would say it's perfect, people just don't know what problem it actually solves.
i'm glad your windows xp machine isn't on the net. i can't imagine what horrors...
you can have uefi without secure boot as you probably know, uefi is just this century's bios. bios is on the way out, now we have uefi. but until i have to use it, i'm probably happy with legacy support. it works more reliably than uefi (so far.)
windows 8.1 brings the start menu back iirc, and 9 is scheduled for april or something. the real problem with 7 (and vista for that matter) isn't the gui, it's that each version of windows dials up the restrictions and other anti-features. for example, i'm not at all cool using an os that tries to integrate a media player that reports what i listen to to the authors. nor am i cool with an update system that updates even when i turn it off (turning off windows updates is like setting up privacy on facebook; it's the act of fooling yourself.) but without an internet connection i can see how it might be tolerable in an extremely hypothetical way.
No, my XP is on the net. It's what I'm using now... :-P
8.1 has a start button. Left clicking toggles between the desktop and metro. Right clicking brings up a menu, with links like control panel, and cmd, but it's not the same.
I don't know all of what Media Player does. I know that on my XP, it modifies the ratings within my files, and screws up the modify date, even though I thought I told it not to. ('Maintain my stars as global ratings within files' is unchecked.)
I usually uncheck the thing about autodownloading usage rights, and also about filling in missing information.
*you are either very brave or slightly crazyby mn64 (no login)
only pete knows which for sure.
Major Headrush - ACCOUNT ACTIVATEDby Walter Whitman - The QB64 Edition (no login)
Major Headrush, your account has been activated on The QB64 Edition (www.TheJoyfulProgrammer.com)
The Joyful Programmer
The QB64 Edition
QB64 x64by SMcNeill (Login SMcNeill)
I know not everyone here visits the QB64 forums everyday, so I wanted to share something I'm quite pleased with: QB64 x64!
Basically, we've finally sorted out the last pieces necessary to make QB64 compile 64-bit EXE files for Windows users. Faster programs, smaller exe sizes, no 2GB memory limitations...
The only drawback? Your programs will no longer run on 32-bit machines...
But, if you're like me and on a 64-bit OS, you might want to give it a try.
*That's good news. Thanks!by TheBOB (Login qb432l)
wait, so is 32-bit mode GONE?by mn64 (no login)
or is this an option?
because there are quite a few machines that are 32-bit that were already supported and uh, there's no reason i can think of to arbitrarily (yeah, it would be pretty arbitrary to) drop support all of a sudden. will 32-bit users have to use an old version of qb64?
Re: wait, so is 32-bit mode GONE?by SMcNeill (Login SMcNeill)
I'm certain 32-bit QB64 will continue to grow and develop. It's just now people can have a choice in which they want/need to use. No one's suggesting we drop x32 QB64; we just want to help open up the x64 option for those that are interested in it.
thank goodnessby mn64 (no login)
considering that people here still use dos, it would be a tragedy to just cut the number of compatible machines in half (even for the sake of true 64bit executables.)
i woke up to this news, so many thanks for providing relief! and it's a good option, i mean in a situation where only 64bit mode is available (i think that can happen, i've never been in that situation) you just added to the machines/environments it works on. cool! thanks.
Add the fact that your programs can no longer be run on 32 bit machines and use it wisely!
Re: The 64 bit version will seldom be necessary for most QB64 programsby SMcNeill (Login SMcNeill)
If you have a 64 bit machine, you want to run 64-bit files as much as possible.
"Under Windows 64-bit, 32-bit applications run on top of an emulation of a 32-bit operating system that is called Windows 32-bit on Windows 64-bit, or WOW64 for short. WOW64 intercepts all operating system calls made by a 32-bit application.
For each operating system call made, WOW64 generates native 64-bit system calls, converting 32-bit data structures into 64-bit aligned structures. The appropriate native 64-bit system call is passed to the operating system kernel, and any output data from the 64-bit system call is converted into a format appropriate for the calling application before being passed back."
So if you have a 64-bit version of Windows, you don't REALLY run those files as they exist. First WOW64 basically reads the EXE and translates it to 64-bit code to be run on your system: all at an increase in memory usage, slower speeds, and with more overhead.
If you're writing code exclusively for yourself or for others that only use x64 machines, you want to compile x64 EXE files. It's not just a case of "do I have to"; it should really be a case of "do I really need NOT to." Compile in x32 if necessary, otherwise use x64.
how hard would it be to ask it to compile both?by mn64 (no login)
one with _32 (or i386 or whatever) .exe, and one with _x64 (or whatever again.)
remember in qb 4.5 when you had more cryptic options? it (the ide) could offer 32, 64, or "both" (in two separate exe's. it would take twice as long to compile because it's really just compiling one file, then the other.)
this is a "wouldn't it be nice" feature. it only makes a difference if it's implemented. (if it's not, it makes no difference.)
assuming of course, that it's even possible. i assume it is, but i can imagine a scenario where there's too much overhead (guess it depends how different the two versions of qb64 are.)
Re: how hard would it be to ask it to compile both?by SMcNeill (Login SMcNeill)
For QB64 itself, it's only about 3 changes needed to toggle between 64-bit and 32-bit EXE creation.
The main thing one would need is to download both the 32-bit MINGW compiler (40MB download before extraction), and the 64-bit MINGW compiler (50MB download before extracting), as well as the QB64 core (20 MB download)... QB64 would become quite a large file to store and download, and probably more than what most people would want/need.
Honestly, it'd probably be best for the future of the language if it'd offer two separate QB64 versions for people to choose from, but if someone wanted to make an "all-inclusive" version, it'd take very few changes now. I suppose we'll have to wait and see how Galleon wants to move forward with the x64 version of QB64; it is his final decision after all.
I'd agree with that, but...by SMcNeill (Login SMcNeill)
It's getting harder and harder all to time to buy new PCs with less than 4GB RAM and 64-bit OSes. And if one has and uses x64 machines exclusively (and a lot of BASIC programming is hobbyist level personal use), then they really should compile with a 64 bit compiler.
If your OS is x64, you should try and get your programs to match if possible. But if you have an older or lower-end machine with an x32 OS, then you'll HAVE to stick with a 32-bit compiler.
It's all about having the choice for whichever suits you needs the most.
Screen 0 "blinky" colorsby Nthrill (no login)
I have a question about the "blinky" colors in screen 0. Colors 17-31 to be exact. Is there a way to to make them stop blinking at will? perhaps some sort of OUT command or weird ASM subroutine? I'm just curious. I'm making an ASCII graphics maker from scratch for an ASCII graphics game that I'm working on. A bit...extremely outdated. I have a fondness for nostalgia, I suppose. It'd be neat to have 31 colors to work with in qbasic. At some point, I'll be moving this over to QB64, but for now (and fun) i'm working in old qbasic through a DOS emulator on a Mac. Never could have imagined that.
Re: Screen 0 "blinky" colorsby SMcNeill (Login SMcNeill)
Just use SCREEN 12.
No blink colors, and you don't have 31 of them, but 256 to choose from!
Re: Screen 0 "blinky" colorsby STxAxTIC (no login)
I thought that in the old QB, screen 12 has colors 0-15, whereas screen 13 is the one with 256...?