QBasic and QB64 Discussion Board

[QB Forum Archives (1999-2009)/ ] [QB FAQ] [QB Links and Downloads] [Subforums and Chat Room] [Search]

QB64.Net Homepage   QB/QB64 Keywords   QB Graphics Forum   Homework Policy



This forum. Maybe not our present dilemma, but a very possible choice for the future.

by Pete (no login)

Menn got me thinking when he posted in jest about renaming this forum. We should consider what our future participation will be if Q-no-longer-B64 is the future.

We can continue to keep the forum open as is, but Solitaire summed it up really well when she posted she already sees too many new statements and functions for her to care to keep up with. After all, this has always been not only an information forum, but a help forum. It is hard to teach what you don't know. (I have until 12-midnight to get that one back to menn, before he charges me or a second day rental.)

I know the saying goes that you attract more flies with honey, but my bug zapper begs to differ. We are working with bees here, anyway, not flies. You need FreeBASIC or that.

So I'm about done zapping away. I think I made plenty of my points known as to why I'm no longer supportive of the perceived future of the QB64 project. I won't be learning any of the new GL statements, and I'm probably less than half up on the new statements added to SDL, as I just don't need them or my apps. I'm not up on linking to c libraries, either. I actually wouldn't mind learning some new things, but the rub is to keep up over time, you have to commit to continued learning and at some point you look back and discover, wow, I had to learn four times as much as I needed to know just to help others, and I only needed a fourth of it to code with. That is just unrealistic by nature.

I want that community to make the SDL version and the early GL version debugged and set aside as the finished QB64 project. Hey, the original goal was just that, then just like PowerBASIC, name this newer more modern language adaptation something else. Some type of BASIC hybrid. How about _QB64? happy.gif

This forum has been a good source of support for people who have visited and asked questions as of the final SDL version, and could continue to be such or said versions. Beyond that, the veteran users here don't seem to have much interest in the IDE, oop, I love Lucy, and Lucy loves C. That fork in the road takes us too far away from our BASIC roots.

Pete

Posted on Sep 30, 2014, 9:15 AM

Respond to this message   

Return to Index


Re: This forum. Maybe not our present dilemma, but a very possible choice for the future.

by SMcNeill (no login)

< I won't be learning any of the new GL statements, and I'm probably less than half up on the new statements added to SDL, as I just don't need them or my apps. I'm not up on linking to c libraries, either. I actually wouldn't mind learning some new things, but the rub is to keep up over time, you have to commit to continued learning and at some point you look back and discover, wow, I had to learn four times as much as I needed to know just to help others, and I only needed a fourth of it to code with. That is just unrealistic by nature.


By this line of thinking, there should be nothing in the language that YOU don't personally use. TCP/IP commands? BAH!! What use are those, as Pete doesn't need them? Sound commands? Bah! BEEP should be good enough for anyone; Pete doesn't need it! 32-bit graphics? Hardware accelerated graphics? BAH! SCREEN 0 is enough for anyone! Fonts? Who needs those?? You have a default one that works just fine.... _BITS? _FLOATS? _MEM?? We can code without those things!!

The whole point of a programming language is for people to use it to suit THEIR needs; not Pete's. Maybe Pete only uses a fourth of the commands available for his programs, but other folks need other things. And there's no reason for one person to have to learn 100% of everything or be able to use every command. That's why there's a COMMUNITY of people to answer questions and help each other and not just a "Ask Pete" forum for the solution to all basic problems.

I find it so odd for people to talk about BASIC in the past sense. As if it's came and gone and the best that can accomplished is to simply make something which emulates the past commands. Take a moment and read the history of BASIC (http://en.wikipedia.org/wiki/BASIC ); the language didn't start development with QB45 and it didn't stop there. Originally it was basically nothing but a math processing language. Then it slowly added string support. Then some graphical support. Then file support. It's been the nature of the language to grow and evolve; why should we expect that to stop??

Take SDL and rename it OldBASIC95 if you want. Each day it becomes a little more obsolete and a little more outdated. Except for those error corrections and patches that I've posted in the SDL-Steves version, it hasn't seen an update in over 2 years; and we all know no real programmer would use anything maintained by anyone other than Galleon... :P

I find it funny: Pete wants a "finished" version of SDL -- SDL *IS* finished. Does it have bugs in it? Sure it does!! Could someone correct those? Sure they could! But as we find and correct more of the flaws in GL, SDL's issues would become more and more apparent over time... Even if it caught up 100% to the bug fixes we've applied to GL today, it'd still need more patches tomorrow.

Pete has managed to convince me of one important thing though as I've had to rationalize and defend the direction GL is heading: SDL really *IS* a product of the past. I honestly see no reason why anyone wouldn't swap over to GL at this point as GL functionality has caught up and surpassed SDL. Galleon saw the future two years ago and dropped SDL support completely to focus solely on GL development. SDL *was* a "finished product" to him. I see it as the same thing anymore. It's "finished", and I honestly don't think they'll be any more attempts to update it or keep its functionality up with GL's on my part.

Pete wants SDL "finished"; well, I can honestly say I'm finished with it. GL has 64-bit support now, which is something I've always wanted and needed for my personal use. I can't see me ever going back to SDL. If someone else wants to take over updating and maintaining the version, feel free. I'm going to focus my time and effort on GL exclusively from now on.

As far as I'm concerned, SDL is as finished and dead as QB45. Those are the *past* versions of BASIC. I don't want to live in the past, so I'm going to embrace the future. :P

Posted on Sep 30, 2014, 10:07 AM

Respond to this message   

Return to Index


Pete's always been a SCREEN 0 Hero,so if you have a good back then...

by Clippy (Login burger2227)
R

pay no attention to the quack behind the curtain!

[linked image]

Posted on Sep 30, 2014, 10:39 AM

Respond to this message   

Return to Index


My view

by Solitaire (Login Solitaire1)
S

I have hundreds of programs written in the original QB45 (in SCREEN 0), and that is the only version I plan to use for the time being. It's the main reason I haven't upgraded from Windows XP.

All I need is a version of QB64 that will run on newer versions of Windows and that will accept the original QB45 code. That way I am able to demo my old programs to my students at school.*

If I need anything newer, I will be using Visual Basic.NET 2010.
(Unfortunately, VB.NET 2012 and 2013 can't be installed on Windows XP.)


*For example, I have an elaborate program called a BINARY LED COUNTER AND CONVERTER that translates between binary, octal, decimal, and hexadecimal, showing them all at once. It illustrates and animates each byte, and counts up and down either manually or automatically so the user can see how the numbers line up. It includes a number of options to make it useful and interesting - speed control, forward or reverse, screen color, LED color, save or recall a number, and lots more. It uses a couple thousand lines of code and would be a major undertaking to translate to a newer language.

It's probably hiding away somewhere in the archives, but if anyone is interested, I will try to post the code here.

Posted on Sep 30, 2014, 10:50 AM

Respond to this message   

Return to Index


Start batch file for music playlist

by Andy P (no login)

Hi there .... trying to add a few lines of text to an old program i use.

Just want it to close wmplayer and then open up a specific playlist.

i created a batch file as below which works fine when i double click it in windows - but when using shell command in qbasic it errors on the start line saying "BAD COMMAND OR FILENAME"

not used dos / shell much before so am a little stuck ??? any ideas ???


Batchfile is ....

taskkill /f /im wmplayer.exe
start /min wmplayer "c:\playlist.wpl"
exit

Posted on Sep 30, 2014, 4:20 AM

Respond to this message   

Return to Index


cmd vs. command

by mn (no login)

i don't remember whether your version of windows uses cmd or command (or both,) only that they work differently.

one supports long filenames and spaces (but only if the pathname is in quotes) and the other might not.

your batch file is (probably) fine, the first thing to try is fixing your basic code. can we see the SHELL line where you call the batch file?

i would also try adding "start " before you call the batch file from qbasic, and try putting the batch file in your path.

it's possible someone who still uses windows and qb will come along, either way sorry, it's been a long time since i've tried to make windows and qb work together. if you figure it out, remind me what the solution is. advice like that used to be offered here weekly.

Posted on Sep 30, 2014, 7:29 AM

Respond to this message   

Return to Index


Re: Start batch file for music playlist

by Pete (no login)

It depends on your operating system...

Windows 98, maybe ME, I don't recall, and before...

SHELL "COMMAND /C START your .bat name goes here"

For Vista and XP:

SHELL "CMD /C START your .bat name goes here"

If you want to use QB64:

SHELL _dointwait "your .bat name goes here"

----------------

Pete

Posted on Sep 30, 2014, 7:33 AM

Respond to this message   

Return to Index


* Posted at the same time. I thought the night shift was over.

by Pete (no login)

Posted on Sep 30, 2014, 7:35 AM

Respond to this message   

Return to Index


If I had made QB64...

by Pete (no login)

And, no, unlike O.J., I didn't... but if I had.

1) FTC, finish the compiler #1 priority. No time wasted on a stupid slow functioning IDE, especially since this would be no time to include an interpreter. Considering time management being equal, this would have resulted in a larger support community instead of letting FB take the lead in that department.

2) Freeware. No open source, but free to download and use.

3) No Linux or Apple x-platform. Windows only. Another time waster. Let others port it later, sure, just let them call it something slightly different and let them support it.

4) Either stayed and grew with SDL and now SDL2, or started with GL from the beginning but that would put a strain on my no open source objective.

5) No stupid wiki, straight up documentation, and not from Clippy. I don't have enough room on my server for all those damn exclamation points!!!!

6) Would look into the possibility of DirectX support for X-Box, and possibly Steam overlays. (As long as they could be written in SCREEN 0) happy.gif

7) After finishing QB compatibility, call it finished, name it, and move on if so desired to include other functions with emphasis on all BASIC keywords no matter what the function.

8) If I ever decided to make the language a higher level language, I would call it a BASIC hybrid.

9) Go mobile and fast. That is the future, and where a great deal of interest will be. Android platform.

10) Kept this forum, and started a separate project forum. That forum would have included a moderated off-topic sub-forum, much like the one at PowerBASIC. A few simple rules to keep heated discussion from getting too obnoxious is needed on a professional project. They do pretty well at PB in that regard.

-----------------------------

So this gives others with a different point of view an opportunity to try and punch some holes in what would have been my objectives if I were doing the project. I can take harsh criticism as well as dish it out, so I posted this with that in mind.

Pete

P.S. I should probably add this is not 20.20 hindsight. Everything mentioned above was thought out in real time back in the early days of the project and throughout the development phases.

Posted on Sep 28, 2014, 9:34 PM

Respond to this message   

Return to Index


Re: If I had made QB64...

by SMcNeill (Login SMcNeill)
R

1) Compiler over IDE. I'd agree with that.

2) No open source means 100% of the development burden falls on you. You'd spend all your time either chasing bugs and not developing, or else developing and ignoring bugs. (Like Galleon has done a lot of. He's left major bugs in place since... Well, forever... Just so he could move on to adding the next thing he needed.)

3) Limited user base would drop interest in the project. And you want others to develop it, but still keep it closed source? How would they do that??

4) SDL required you to include your source code.


Yes! However, for SDL 1.2 you will either need to publish the source code of your program if you're statically linking, or provide tools and object files required to link against another version of SDL.

As for GL, to be honest I still have no clue what it requires. And going the GL route you'll need a sound library, clipboard library, font library..... Each with their own licensing requirements.

Unless you want to do all that stuff yourself, chances are something's going to require you to open source the code.

5) So you're going to develop it, bug fix it, AND document it all --- in your spare time and for free?? With no help from anyone?? Good luck with that!

6) I don't think you'd have to worry about it. By this point you've stalled out, burned out, and the community interest has given out........


You like to talk about Clippy and his pipe dreams; this vision is as delusional as any he's ever had. :P


You say, "Galleon's taking too long to get anywhere! Progress is too slow!!", and then claim you'd take on even more of the burden with the project than he already does, if it would have been yours.... Who's sniffing fairy dust now??


There needs to be MORE people developing the language, not one lone guy who's got to try and do everything himself with no compensation in his free time.... Develop, bug fix, document.... When would you find time to do anything else??

Posted on Sep 28, 2014, 10:21 PM

Respond to this message   

Return to Index


So Clippy is bad at math and you can't read.

by Pete (no login)

The two of you should team up and post the worst scores ever on an SAT exam.

Well, I'm working with another dullard, so what should I expect. You're smart but too full of yourself to understand things out of your level of experience.

Time being all relative, duh, Rob did most of that stuff himself, not through other developers. Take the time he spent on the IDE, x-platform, etc. and yes all things being relative, I certainly could have done everything I posted.

I wouldn't mind the source code being released, as long as it was a closed project. If that is not possible, it makes me glad I don't have to be involved in projects like this.

There would be a bigger community, because that opportunity was time sensitive, and the faster the compiler got finished, the better. There is little community additions for the development part.

Learn to read better Steve. There is a lot out there to learn, even for us smart people.

Pete

Posted on Sep 28, 2014, 10:35 PM

Respond to this message   

Return to Index


he can read, it's just

by mn (no login)

it's difficult to tell a nul from nothing at all, and "nothing at all" happens an infinite number of times between the beginning and end of a post, so sometimes he thinks he's encountering a nul and just terminates before he's actually read your post.

happens to me all the time. i've heard custom routines can help, but obviously your custom routines haven't taught him anything. i doubt customs routines would help either.

"sir, do you have any libraries to declare and pay taxes?"
"no, but i've got some string routines that people find taxing!"

"i'm sorry sir, we can't let those into the country."
"is it because they're foreign to basic?"

"no, it's just part of our job to keep out weapons of ascii destruction."

Posted on Sep 29, 2014, 7:50 AM

Respond to this message   

Return to Index


Well, at least a farmer has plenty of straw to keep building his straw men.

by Pete (no login)

and LOL @ weapons o ascii destruction.

Steve's a smart guy, a good coder, but a bit of a dullard when it comes to understanding where anyone else, but Steve, is coming from.

It is also apparent that the more Steve learns C, more C-like additions will get pushed up the repository. Again, too much of a dullard to get that _STRCMP is less BASIC than say _scompare, _strcompare, or _stringcomp. I'm glad Steve drives a tractor, because they are notoriously slow. He has a few helpers running behind him, who will sooner or later get stuck in one o his ruts.

QB64 never got the needed traction to attract real developers. It was a confused project from the start, trying to opt to be too many things and staying on the fence a lot to keep options open, but then someone with better managerial skills probably wouldn't be able to code it. I don;t have mad C skills, so I sure wasn't going to tackle it, but I do have pretty good managerial skills, which kept me from starting something like give me two or three years, I will learn C, and code it. Why? lack of experience slows people down + the 2-3 years and the product comes out so late the audience has left the building.

I just wish Rob would debug the final SDL version, finalize and debug an earlier GL version, and call them both QB64 replacements or QuickBASIC with some added features. Then since he doesn't have the time or it, let the others come up with hybrids o their own.

Another thing I ind weird is a really accomplished C coder like Rob wants to use QB6 to write professional applications with. Now that astounds me almost enough to go install those emoticons on this forum.

Pete

Posted on Sep 29, 2014, 8:52 AM

Respond to this message   

Return to Index


* QB64 News Flash: DEF FN abandoned. Replaced with DEF EARS.

by Pete (no login)

Posted on Sep 29, 2014, 9:28 AM

Respond to this message   

Return to Index


"No open source, but free to download and use. "

by mn (no login)

i'm astounded you still don't get the thing about that.

the reason qb is dead is because we'll never have the source to fix up. if you're thinking being proprietary would stop people from bastardizing the language, look how well that has worked for qb. there's tons of alternatives, and mostly they suck.

if qb64 didn't have the source, no one could fix it (ever.) as long as the source is up, it could be forked in a direction that helped it be everything it should be. yeah, that's not going to happen, but the difference is that your way it's impossible instead of unlikely.

even you would like the memory limits and platform incompatibility removed from qbasic. that would have been done YEARS AGO if it had been open source. so why, why pete? why on earth do you think that would help anything?

not that it matters, i mean, you're not going to make a basic interpreter/compiler anyway. but remember when i stopped working with basic? it wasn't the fb licensing that got in my way, it was the fact that galleon had promised to make qb64 public domain (gpl or lgpl is definitely close enough) and there was such a long gap between its release and the floss licensing that i decided it was a lie and just stopped coding in basic instead. i'd had enough with broken promises from the other qb alternative, i wasn't having more.

later on i tried qb64 again when it was licensed to be anything other than blitzbasic 2 (a forgotten relic that will never be updated or bugfixed again,) when galleon finally licensed it more or less how he said he would (definitely close enough for my tastes. in some ways gpl or lgpl is actually better.)

qb is historical and not in use because it's proprietary. why would you want your project or galleon's to ever work better, only to have to have some poor slob repeat the process all over again in 5-10 years? it absolutely defies reason, it's literally like making a project disposable after 1000 uses. you can't build a lasting legacy for that, which is certainly the ideal for a basic-like language.

i don't expect you to agree, but i'd like to know how you can actually manage not to. i'd actually LIKE to see people coding in basic who haven't before, without having the same problems years down the road.

Posted on Sep 29, 2014, 6:27 AM

Respond to this message   

Return to Index


*i obviously like #8 though

by mn (no login)

Posted on Sep 29, 2014, 6:29 AM

Respond to this message   

Return to Index


You need to visit TheBOB's Forum to be astounded...

by Pete (no login)

He has that "shocked" emoticon, we don't. Oh, and the graphic examples are pretty astounding, too, even without hardware acceleration, but I digress...

OK, good point on issues with abandonware. It would have been great if MS would have made QB open source before they dropped support for it. I do wonder in this day and age off deep pockets law suits if that might have been a determining factor. Shakespeare was right about what to do with lawyers.

I would still want the project closed. SDL2 seems ideal for that at first glance, because it is because of zlib, making it freely available for static linking in commercial closed-source projects. I will agree that wasn't the case in the earlier versions. Didn't Rob use SDL from the start? If so, he didn't open source the project until much later.

But letting others in to work on the project, no. All to often you wind up getting out of it that old joke involving a committee. You now, a HORSE is a BEE a committee tried to put together. I'd dodge that bullet. Partners, maybe, but it would take the right individuals, not just fiddlers. A fiddler belongs on the shelf, not the roof.

Legal issues not a consequence, I would prefer the project released as open source if I abandoned it. What I would want is actual finished packaged products before that point.

Pete

Posted on Sep 29, 2014, 8:23 AM

Respond to this message   

Return to Index


this conversation...

by STxAxTIC (no login)

...is entertaining as ever, but it's starting to resemble what I imagine to be a civil war in a leper colony. If Steve and Luke stop weighing in, then that's exactly what this conversation has reduced to.

Posted on Sep 29, 2014, 8:42 AM

Respond to this message   

Return to Index


A civil war in a leper colony, really Bob? At least their won't be a build up of arms.

by Pete (Premier Login iorr5t)
Forum Owner

But an arms race aside, it's good to stir pot in life. It lets you see whats beneath the surface. No Steve, not that kind of pot! No Luke, not what you're smoking either.

Pete

Posted on Sep 29, 2014, 8:58 AM

Respond to this message   

Return to Index


didn mean to imply we are all lepers

by STxAxTIC (no login)

..but it's an "ordinary" war when Steve and Luke chime in, but when they pull out, we turn inwards, hence the "civil" war.

Posted on Sep 29, 2014, 7:18 PM

Respond to this message   

Return to Index


good, that means

by mn (no login)

at least this place is getting back to normal

Posted on Sep 29, 2014, 10:58 AM

Respond to this message   

Return to Index


Regarding point #3

by Michael Calkins (Login MCalkins)
Moderator

If you intend your software to be cross-platform, it's probably best to make it cross platform from the start. If you write platform dependence all over your code, then porting it could be a big challenge.

I'm pretty sure that the android port benefited from the work done on the Linux side.

Regards,
Michael

Posted on Sep 29, 2014, 6:19 PM

Respond to this message   

Return to Index


Re: Regarding point #3

by Pete (no login)

I would not have bothered going x-platform at all. Once a version was finished, I would be happy to make it available or others to port it and support it, i so desired.

SDL2 supports Android, so I would need to ind out if writing it as a Windows only version would work or not. O course there are other Windows options, like Windows phone and some tablets, but I haven;t kept up on how MS is marketing them in regards to allowing apps to be written or them.

Pete

Posted on Sep 29, 2014, 9:08 PM

Respond to this message   

Return to Index


What did the coroner say when the QB64 Project arrived in his lab?

by Pete (no login)



"This is the first project I've had to work on that came with the embalming fluid pre-installed."



The SDL version was a milestone. This GL concoction is more like a gallstone. It needs to be removed before it kills the patient.

Had to switch horses in the middle of the stream did we? Well, the other horse, SDL, got a pretty good update, while all this was going on. So the only time you need to be patient when involved with QB64 is apparently when there is insufficient manpower to get anything done, otherwise, rash decisions and utopian ideologies just abound from that place.

"Wake up Pete QB64 already works on Android." ROFL. I'll keep sleeping, at least in a dream state it has a chance. In reality it isn't any bit useful. When that gets mentioned, the reply is to give it more time, and someone else to work on it. Might as well add in some ferry dust and poof, it just might actually run on Android systems by the time Captain Kirk takes command of the Enterprise.

Of course there is fixing GL. How about a modern IDE? Interpreter anyone? GWAN = Gee WANt it? Go code it! and several other wish list items that would be interesting if the project wasn't looking more and more like an episode of the Carol Burnett Show when Tim Conway played that lovable character "Mr. Tudball" and who a "modern" version now apparently exists as a Q.....B........6..........4.......d....e........vel......o.......per.

Pete

ASCII-pirins, they're not just for breakfast anymore.


Posted on Sep 28, 2014, 3:13 PM

Respond to this message   

Return to Index


* Take that up with Galleon insead of moaning about it here

by Luke (Login flukiluke)
R

Posted on Sep 28, 2014, 8:29 PM

Respond to this message   

Return to Index


No, you take it up with him...

by Pete (no login)

Same stupid comments FB developers used to come here with. And, in case you haven't figured it out yet, Rob is only a great worker. He is a lousy communicator. But tenacity requires time, and I doubt these days he has much of that to spare on the project. Even so, he should have never made it Open Source, another one of my complaints. He defined it very well as a QuickBASIC replacement in the beginning, but that is about as far as it went on a managerial level. Sure, if he is going to involve others, he needs C/C++ coders, but the chances of finding ones that initially shared his commitment to BASIC are slim to none. Two years of going sideways, and apparently one or two more years of the same. He needs to have an intelligent way for the project to continue, not a train to a QB compatible compiler that requires a short bus to C to make it the rest of the way.

Pete

Posted on Sep 28, 2014, 8:48 PM

Respond to this message   

Return to Index


i've spent a day or two figuring out a new name for the forum. it wasn't easy

by mn (no login)

i thought about having you change it to "basic discussion board" but that's a terrible idea., inviting exactly the sort of "you need x for that" nonsense we used to endure here.

i thought about having you change it back to just "the qbasic forum" like it was for years.

then it came to me:

"qbasic and moaning about qb64 discussion board"

you gotta admit it's got a ring to it...

Posted on Sep 29, 2014, 8:05 AM

Respond to this message   

Return to Index


You know I actually thought about doing that the minute Luke posted.

by Pete (Premier Login iorr5t)
Forum Owner

But this place holds a lot of karmic traditionalism I'm not about to fool with.

It is still QB64 discussion, just the negative side at the moment. Imagine if I got on everybody's case here the times they posted N54 message boards suck. They are certainly outdated, they do suck for posting code, but aside from the obvious, imagine if I insisted everyone shut up about that, and just go code. Suppress the truth, abandon free speech, get in line with the rest of the sheep kind of stuff. We just need to avoid the sticks and stones part, which changing the name of the forum would do. Besides, do you really want to get in a sticks and stones match with Steve. He has acres off ammunition!

Pete

Posted on Sep 29, 2014, 9:05 AM

Respond to this message   

Return to Index


Re: You know I actually thought about doing that the minute Luke posted.

by SMcNeill (Login SMcNeill)
R




Dang it!!

NOW Pete wants people to avoid the sticks and stones part, AFTER I plowed "PETE, MN, N54 SUXS!" into the corn field's back 40.....

/sigh


Guess I got more plowing to do now... :P

Posted on Sep 29, 2014, 11:37 AM

Respond to this message   

Return to Index


Re: You know I actually thought about doing that the minute Luke posted.

by Pete (no login)

Oops, you left out the "and" in your sentence. I guess you're operating out of a Common Core corn field these days. Oh, and in BASIC, we spell it "SUCK" as in Pete, mn, and N54 suck! Now that I spelled it out for you do I have to repeat it? Really? Pete, mn, and N54 suck! Don't make me go all Clippy caps on your ASCII, but whatever it takes to get you to stop using c-like nomenclature like SUX, is all I'm asking.

Seriously, if you get the hang of C well enough to actually move that project out of the doldrums of the past couple of years then keep in mind, it may be the last real BASIC language that can be used to code a variety of applications but that means nothing if the nomenclature is debased and the functions prefabricated rather than left as building blocks. Adding libraries is an obvious way around the second pitfall, and besides, migrating it away from BASIC just leaves it as some ugly C stepchild with no roots in history and no more uniqueness than the horse next door.

Pete

Posted on Sep 29, 2014, 9:24 PM

Respond to this message   

Return to Index


"the last real BASIC language"

by mn (no login)

...more or less the truth. it's amazing how people changing it don't think that's a big deal or anything, or wonder why anyone would make such a big deal about it.

languages change, that's ok, but it's going to take more to preserve basic than underscores.

they were a compatibility thing, and a way to tell old from new. they're not an idiot proof way to make sure the language doesn't turn into the horse next door, they're more like a latex barrier which can stretch and if sufficiently stressed, break (what? ...gloves count as barriers.)

a project takes sufficent care with this sort of thing or it just plows forward. plowing might be good for the earth and for future crops, but it turns everything in its path into mulch. i'm sorry that this is the "path" that it's going in, and it's not enough to have two or three people that care about this, when everyone else is cheering on its demise.

among them, steve is not even the worst. when the community itself is demanding and encouraging a hasty exodus from a legacy, steve isn't even leading the horde but being pushed ahead. steve's attitude was almost the very last straw; but the community is what actually clinches it and makes it hopeless, and what makes me content to criticize without offering anything remotely constructive. you can criticize someone/something lost to history, but you can't simultaneously kid yourself about it changing anything.

Posted on Sep 30, 2014, 7:55 AM

Respond to this message   

Return to Index


they have xm radio here

by mn (no login)

just as i finished that post, "turn! turn! turn!" came on, like an episode of the wonder years.

perfect.

Posted on Sep 30, 2014, 7:58 AM

Respond to this message   

Return to Index


Don't leave yourself open like that...

by Pete (no login)

State you are listening to XM radio, instead. Stating "they have it here" invites snarky farmers to reply with messages like: I'm glad they let you listen to music, but doesn't the sound get depreciated when it reverberates off the padded walls? Oh, there's another sign, the word "depreciated" just got used.

Well, I have to go construct another new post for a possible future dilemma QB64 may create, and then my other personalities have to get on with their work. Oh, and if Steve gives you any zingers, just kick him in some other area that also needs latex protection. Remember, the only thing that stands between funny farmers and funny farms is the "er."

Pete

Posted on Sep 30, 2014, 8:28 AM

Respond to this message   

Return to Index


thanks for looking out

by mn (no login)

actually i was saying they have xm here in the padded cell, but your point is well taken.

Posted on Sep 30, 2014, 9:29 AM

Respond to this message   

Return to Index


* Pete knows all about CORONERS! He killed enough patients...QUACK!

by Clippy (Login burger2227)
R

Posted on Sep 30, 2014, 8:24 AM

Respond to this message   

Return to Index


for bill: namespaces

by mn (no login)

this is not for basic... this is so you understand the argument being made (you had your own argument, this one is different.)

one of qbasic's faults was its syntax for including code. it reaaaaaaally sucked. i'm not saying that people shouldn't support that syntax, only that i'd never want to use it. fine. next.

i understand way more than i'm ever going to get credit for. the automagic thing is something galleon talked about a long, long time ago. it's a great idea, provided that his projects only have basic commands.

one thing that wasn't anticipated was an ocean of commands being added. that ocean isn't here yet, and i hope it won't be (only because it won't be any good. otherwise, great!)

a qb-sized language benefits from an automagic library solution, like the one galleon talked about (and like the one you talk about.) twice that size, and it still benefits. beyond that, i'm really not sure. but it's not really about this library thing, it's about something more fundamental. basic matters to a language, or it doesn't. you show me a langauge where basic came second and survived, and i'll show you hope for your defense of recent events. but even if you don't agree, we're cool because the damage is already done and it's not your doing. no problem.

Posted on Sep 28, 2014, 6:52 AM

Respond to this message   

Return to Index


the mennonite test for basicness

by mn (no login)

1. "it's basic if i say it is."

this isn't a scientific test, it's cultural. there are alternative cultures, where c coders tell you what is and isn't basic, and sometimes people code in basic and then get into other languages, and they try to make the language more like their favorite language...

and sometimes, that works really well.

but personnally, i try to make other languages more like basic, not the other way around.

do i expect anyone to take my word for it? nope.

i already know who knows what basic is. galleon knows what basic is. myst knows what basic is. pete knows what basic is. they all pass the test (see 1.)

all this proves nothing. you can't prove a quality to someone with entirely different values. but pete and i can have a debate about what is and isn't basic, disagree, and still we both know what basic is. we can change our minds and decide we agree on things after all, and we both still know what basic is.

some languages start out as being very basic, and they usually fail. adding features isn't the problem. adding non-basic-like features is the problem. what's a non-basic-like feature? well, when you have people working on a basic language in c, it takes an awful lot to not have that bleeding into the language.

most people can't do both and keep them apart, galleon was a true wizard. pete at least knows what went wrong. myst could come here and have an intelligent debate with both of us if he wanted/cared.

it's not that we're older or wiser (if we were wiser, we'd have better things to talk about.) it's that the love is old, and the basic is not forgotten.

how do you know if music is salsa music? the same way you know if it's basic. if you play it on a midi harmonica, and mix it with a church organ is it still salsa?

perhaps (see 1.) of course there's a test that just slightly less subjective than "it's basic if i say it is." it's not as reliable a test, but it's still fairly reliable and a lot easier to generalize:

1."it's basic if you really take sufficient care that it is."

that's a tricky one, because people might think they care when they really don't. they care about getting credit for it being basic, but they don't really care about whether something is really basic or not.

you can't prove if people really care or not, but you can sometimes prove how ham-fisted their vandalism is. we're not saying it so you can fix it, we're saying it because it's broken and that's unfortunately the only thing about it that can matter now. it's not going to be fixed (give it 5 years, but really don't.)

pete, myst and i don't need proof: we have pudding. and now i'm pudding the keyboard down and leaving it at that.

but no, no you don't pass either test. and it isn't.

Posted on Sep 27, 2014, 8:49 PM

Respond to this message   

Return to Index


*too bad you don't have a test for spelling errors!

by spelling police (no login)

Posted on Sep 27, 2014, 8:56 PM

Respond to this message   

Return to Index


* :P

by mn (no login)

Posted on Sep 27, 2014, 8:57 PM

Respond to this message   

Return to Index


guess what oop is an anagram for

by mn (no login)

POO!

now you can't wash your hands (though should, after you OOP backwards) of qb64 without a song, so even if it makes me a big-fat-liar, here's the song you knew was coming anyway: (bum, bum-da-dum, bum-bum, bum-da-dum...)


when i get older, i just won't care
if the window's blue
type in any editor, i don't mind
semicolon, run it is fine

after eight years i'm ready to leave
i can find the door
i just don't need it, i just won't feed it,
when it's 64

ooh ooh-ooh ooh-ooh ooh-ooh OOPS...
you're all older too, (ah-ah-ah-ah ah-ah-ah-ah)
basic meant all the world
but those days are through

i could be handy, don't ask me how
i'm already done
you can make a calculator i.d.e.,
(but i won't translate it from c)

doing qb in, digging a hole
don't want anymore
i just don't need it, i just won't feed it,
when it's 64

every summer you can integrate it with more tractor parts
it could grow some ears

we shall run and scream (AAAAAAAAH! AAAAAAAAH!)
g.m.o. lobster-shrimp-carrot-basic-beans

send me a postcard, drop me a line,
from where it may go
i'll expect a picture of a garden gnome
with your project on his iphone

just save your answer, this is outworn
it's a thumping bore
i just don't need it, i just won't feed it,
when it's 64

Posted on Sep 27, 2014, 6:11 PM

Respond to this message   

Return to Index


deporting qb64

by mn (no login)

qb64 is barred from entering my country. the stuff that's going on anyway is bad enough, but after all the nonsense with strings not working and finally some committment to fixing them, clippy wants it broken again.

let's talk about priorities:

.[]. new features are good, but not as good or important as compatibility.

you don't have to choose, but people that choose features first "tend to" abandon compatibility (read as: "every time.") features have to be well thought out to be "basic."

under old management, (only) qb64 got that right; now they have it backwards, and that's done.

let's talk about priorities:

.[]. basic-like names matter, though not all qbasic names were good (but we are/should be stuck with those.)

"we" (that is, you all) shouldn't have names inspired by c when avoidable, because they're really not basic like.

but having things that work like c (and not basic) is worse. so what's less basic?

a. works like basic, looks like c

b. looks like c AND acts like c

inline compilation aside, b is worse. but that's what clippy is going to advocate, that it be LESS basic like so at least it fits the name. (no link, i'm sure you've seen it at the other qb64 forum.)

i'm sorry, i wash my hands of this. you guys go make another c-basic, i'll contend with the fact that basic just became entirely historical again. you're a bunch of vandals who wouldn't know basic if it poked you in the bottom, AND THAT'S FINE, UNLESS

unless you call it basic.

you know i think we have a name for your language we can all agree on:

call it clippy64. it will make him happy, it will suit the direction it's taking, and when people complain you can point at him.

everyone wins.

also, shut up steve. dev or no dev, this is mostly your doing. you want to blame clippy for the last point? be my guest.

if you want to teach languages to grade-school level beginners, there is always logo. given the state of basic, that's pretty much what i recommend at this point.

logo. thanks!

it's not qb64 anymore, it's just "64"

i don't still need it, and i won't still feed it.

you know what rhymes with qb64?

"isn't basic anymore"

that's it!

Posted on Sep 27, 2014, 5:08 PM

Respond to this message   

Return to Index


* feel free to stick to QB64--QB45v2. It's more "BASIC" than any other QB64 out there,...

by SMcNeill (Login SMcNeill)
R

And it'll never change, become more powerful or versatile, or get updated/altered again.

It should suit your needs for the future, especially since you don't even program in the language anymore. It's not hard to build a compiler to NOT compile for people who don't use it......

Posted on Sep 27, 2014, 5:50 PM

Respond to this message   

Return to Index


right, qb45v2: qb64's answer to -lanq qb

by mn (no login)

-lang qb was the proof that fb was abandoning its original goal, too (a compatible language doesn't need a compatibility MODE.)

history usually doesn't have such hard-to-debate, clear turning points, thanks for providing demarcation.

Posted on Sep 27, 2014, 6:21 PM

Respond to this message   

Return to Index


It's not a compatible mode

by Luke (no login)

You seem to be under some kind of illusion that QB64v2 was in any way a official release. It was more on par with an April Fool's joke, and to hopefully pacify a few of the complainers here.

You also make this assumption that the new features break compatibility with older programs. I challenge you to find one QBasic program that ran on an older version, but not on the most recent ones.

As for naming, I never saw you suggesting better names. You clearly don't want to use the function, so be it. Don't use it, and move along! I really don't see what the problem is with adding functions (whose use is completely optional) that could very well be useful to someone. And don't give me the "it's too much like C" argument again, that's rubbish. The functions support strings better than the native < > operators did up until recently, and there was no complaining about that. If you have a complaint about the implementation, please provide a solid technical argument why they should not take advantage of a similar C routine.


No one is stiffling your ability to avoid underscored commands like the plague, nor is anyone breaking the QBasic commands (they are getting more compatible). It seems to me that what you really can't handle is a changing language. I think I understand that; in general, it's difficult for humans to accept change.

Posted on Sep 27, 2014, 7:09 PM

Respond to this message   

Return to Index


"It was more on par with an April Fool's joke"

by mn (no login)

i know, it wasn't that funny.

look luke, don't know you, don't expect you to get it. but i'm here, you're there. that's why you don't have any idea what i do or don't know already.

don't try to tell me though, i've been following qb64 since before galleon told anyone else on this forum about it, when it was just email-- let alone before your phpbb forum was up and running. and i used to post there, but i don't bother anymore.

thanks for the tip, but, since you haven't been around for the context of anything i've said, i really can't blame you for taking everything i'm saying out of context. you are, though. that's fine, there's nothing we need to talk about anyway.

Posted on Sep 27, 2014, 7:29 PM

Respond to this message   

Return to Index


*one more thing: i never said it was a compat mode. i said it was like -lang qb (which is)

by mn (no login)

Posted on Sep 27, 2014, 7:33 PM

Respond to this message   

Return to Index


Re: "It was more on par with an April Fool's joke"

by SMcNeill (Login SMcNeill)
R

I think Luke's points are quite valid.

Can you point to an existing QB45 program that ran in QB64, and show us a single example of how the new keywords make it incompatible?

Can you point to a single reason WHY someone couldn't simply learn, use, or teach the old words without having to expand upon the underscore commands? Can you show one illustration of how the new keywords make a tutorial, code, or teaching plan written in 1995 fail to function or be valid?

You say "BASIC is dead." WHY?? Does the code that compiled last year fail to compile this year? Can you show anywhere where you have to add additional Non-BASIC syntax, flags, or toggles to make your code work. FB may have a -lang command to set for QB45 compatibility mode, but can you show a single example of such a thing being needed in QB64?

Apparently you don't want to see the language expand and become more flexible. WHY?? You're right: I don't have a clue and I don't get it. It continues to do what it's always did -- just better and in fact, with less errors. Pete likes to say SDL was a complete package, but the truth is QB64-SDL has a ton of bugs in it. GL has probably had over 100 bug fixes to make it more QB45-compatible since SDL was retired. Can you come up with a single example of code that runs in SDL and not in GL??

SDL did what QB45 did (though with several little bugs and glitches to work around). GL now does what SDL did, which is what QB45 did, though without as many errors; PLUS a whole lot more! Hardware graphics, better string handling, mem commands, support for math routines in CONSTs, additional math commands....

And all without breaking a single QB45 compatible command.


Still I find it funny: A guy who says he hasn't used the language for "over a year or more", NOW decides he doesn't need to use the language because........ whatever reason he finds. Sounds to me like you're just looking for an excuse to step away from the language and anything will do. It's just grasping at straws to claim an additional keyword will somehow magically destroy all the old commands, but hey; all to their own!!

If you need to blame ME for ruining a language you don't even use, feel free. I'll accept the blame and won't lose a seconds sleep over it. QB64 does everything it used to do. NOTHING has been broken. It just also happens to do MORE now than it used to; and I'm not going to apologize for that.

Posted on Sep 27, 2014, 8:06 PM

Respond to this message   

Return to Index


steve, you know literally nothing about this

by mn (no login)

> If you need to blame ME for ruining a language you don't even use, feel free. I'll accept the blame and won't lose a seconds sleep over it.

depends on what you mean by "use." what i "used" qb64 for was to have something to point to when someone said "but ok, what is the most modern, most basic-like language?" if i needed to teach someone basic, i could "use" qb64 for that. now you're probably thinking "so use an old version." yeah... NO.

i don't expect you to lose sleep, i don't expect you to understand what you're doing. why feel guilty when you think you're doing the project a favor? so that's obvious.

> And all without breaking a single QB45 compatible command.

when people make little points, you dismiss them as little points.

when people make big points, you dismiss them as little points.

the rest of the time, you just miss the point. galleon has already washed his hands of keeping the project as something that resembles basic, and you're making promises to screw it up (which you're breaking, but it's too tiring to try to steer you.)

galleon didn't need help. you do. you get clippy and luke instead. i realize that doesn't prove anything to you, but it tells me what i need to know.

i don't care if you get it, steve. i already made my peace with the fact that you won't.

and pete, pete got it, before i did. that's all YOU have to know.

1985: we have basic
1995: we still have basic
2005: not-basic takes over
2010: we have basic again!
2014: steve takes over

it's not a debate, it's just how it is. years from now, you still won't get it, and hey, that's life.

but i don't use basic for decades (or have it as my favorite hobby for decades) without talking about where basic was and where it is. this is where it is now, that's an important update.

the idea that i'm going to try to prove it to a group of people who are oblivious... steve, i don't have psychic powers. i can't make you understand things by uploading them to your skull, i'm sorry.

the reason you're confused is because you have an entirely different point of view. if we're being politically correct, it's because everybody has a different point of view and that's fine.

i will settle for the fact that you're just wrong. i don't need you to figure it out, your point of view is just too different. but there's still one or two people here that follow this, and i'm saying it for them--

not for you.

Posted on Sep 27, 2014, 8:20 PM

Respond to this message   

Return to Index


Re: steve, you know literally nothing about this

by SMcNeill (Login SMcNeill)
R

> if i needed to teach someone basic, i could "use" qb64 for that. now you're probably thinking "so use an old version." yeah... NO.


WHY would you need to use an old version??

Exactly WHAT in the old version is in there -- or NOT in there -- that you can't do EXACTLY the same in a newer version??

If you could use QB64 to teach your idea of BASIC in the past, how has that changed?? Show me an example of ANYTHING you coded back in 2010 "when we had BASIC again", that doesn't work today. QB64 hasn't broke a single drop of BASIC compatibility over the last few years; it's only built upon it and become a more flexible and powerful language.


Maybe you guys should take up SmallBASIC -- it only has 16 keywords. It might be simple enough to qualify as "basic" by your definition.

Posted on Sep 27, 2014, 8:46 PM

Respond to this message   

Return to Index


maybe you should take up freebasic

by mn (no login)

it is much more suitable for what you're doing, but i suppose there is one reason to do it your way: it hadn't been done yet.

why hadn't it been done yet? because it's not what you should be doing.

you don't get the point of my latest rants, so here's one last clue:

yes, what you're doing is your fault. yes, what you're doing is troubling. no, it's not all your fault. your community is starting to make it worse, and there is no way for either of us to stop your community. now if it were galleon, it could be done. i'm not galleon, pete's not galleon, myst isn't galleon (but he talks a good game,) but galleon is the only person who could stop this.

you definitely started it though, that part is your fault. the rest you can blame on whoever. blame it on me, that's actually happened before, i'm expecting it anyway. it's all good, have fun.

Posted on Sep 27, 2014, 8:55 PM

Respond to this message   

Return to Index


A discourse on language design

by Luke (Login flukiluke)
R

You're right, I don't have all the context. And, in some ways, I think I am better off that way. I don't want to be weighed down by antique views that are no longer as important today as they were back in 2007. I appreciate that when QB32 was first launched, everyone was still using QBasic. Compatibility was the watchword, and while that is still important today, it's just as important 7 years down the track to actually have a language that people can and want to use. Thus, I believe our focus should be on what makes it easier for the programmer to create a program that is correct and efficient (in that order!)

On this matter, there are clearly two extremes of view: some believe that in order to remain easy to learn and manageable, the core should remain small and tight, sticking to a well-defined set of primitives for the programmer to build upon, i.e., the QB command set. Seemingly diametrically opposed (I love that phrase!) is the belief that the language should expand freely, providing a wide range of functions.

A quick look at other languages shows that the latter approach tends to be more common, especially in more recent languages. Java, Python, C++ all provide high-level standard libraries, covering a wide range of tasks. However, a language such as C provides only low-level primitives, expecting the programmer to manage far more themselves. This is one of the reasons C has endured as a systems language: it doesn't do anything behind your back, and it lets you have full control over your code.

QB64 strikes me as a curious mishmash of these two extremes. On one hand, it makes loading graphics and sound resources almost trivial, it has a pretty darn input system, and the networking is so much easier than sockets programming in C it's almost laughable. On the other hand, it provides them only as a set of primitives: whereas C++ would give you hash tables, QB64 gives you arrays and primitives to implement your own hashing function. Whereas Python would give you a http and ftp class, QB64 gives you the primitives to open connections and parse the protocol.

So, should QB64 be a language of small, symmetrical and efficient primitives, or should it give higher-level functions, that give general implementations of useful features? What do you actually want to happen? Can you articulate, without falling into a rant, what you want done?

Posted on Sep 28, 2014, 5:04 AM

Respond to this message   

Return to Index


a discourse on common sense

by mn (no login)

historical value doesn't stop "all the way back" at 2007.

the value of basic working like basic probably doesn't stop ever.

the value of this conversation never started.

it's not enough to destroy a language, people have to come here and "justify" it.

you're basically asking me to not know things i know. i'm not bringing myself down to your level, so why bring yourself down to mine? go destroy a perfectly good language and be happy. it may seem like too much to ask, but honestly. it's not. you stick to injuring things and we'll stick to insults. i don't know why you can't see the fairness in that, why should you people be entitled to both? think about it.

Posted on Sep 28, 2014, 5:16 AM

Respond to this message   

Return to Index


The value of argument

by Luke (Login flukiluke)
R

> it's not enough to destroy a language, people have to come here and "justify" it.

At least I'm justifying something, which is more than can be said on your part. If you're going to argue a point, do it properly. Otherwise, you stick to the insults and I'll stick to the programming. However, I hope you realise that your insults have little value beyond my entertainment.

Posted on Sep 28, 2014, 5:24 AM

Respond to this message   

Return to Index


your entertainment proves my point

by mn (no login)

your project went from caring about compatibility to its new architects delighting in screwing things up and being a huge disappointment.

that's entertaining to you. someday you may realize that if you expect people to have rational arguments with you, you're going to have to show a certain amount of honesty and integrity. hey, i'm not interested in debating that with you, i'll respond to it when i see it. (that's what i do with honest people, i play things their way.)

until then, be entertained. laugh. ruin and ridicule. i'm sure at the end of the day, we're really all entertained over here. but don't think you're not proving my point.

why would i try to convince someone who isn't honest when it's much easier to get them to do that work for me?

it's already done, and you were great. have a nice day.

Posted on Sep 28, 2014, 5:36 AM

Respond to this message   

Return to Index


It's not my project

by Luke (Login flukiluke)
R

It's good to see you're enjoying this spat as much as I am. I also notice that you still haven't addressed the earnest questions I put to you earlier.

I'm just fixing the occasional hole, but at least I don't actually have to worry about you making any more. After all, all you do is sit around and condemn people who don't follow your idea, right?

Posted on Sep 28, 2014, 5:42 AM

Respond to this message   

Return to Index


no one has to follow my idea. i still condemn sabotage

by mn (no login)

the only "hole" i ever added to qb64 was demanding string compatibility.

you and clippy have added two holes just by being there.

i wouldn't worry about anything i've "done" to the language, it will be reverse in the next version (as if steve's ever going to fix it properly in the first place.)

i'm just going to sit here and have an opinion. you know what they say, opinions are like holes, everybody's got one.

Posted on Sep 28, 2014, 5:51 AM

Respond to this message   

Return to Index


I refuse to be equated to Clippy

by Luke (Login flukiluke)
R

In fact, I'd say he's more like you than me. Just complains about any attempts to actually improve the language.

Posted on Sep 28, 2014, 6:01 AM

Respond to this message   

Return to Index


*still, galleon could handle both of you. even me.

by mn (no login)

Posted on Sep 28, 2014, 6:17 AM

Respond to this message   

Return to Index


Refuse to be equated to Clippy? Too late! Steve's new comparison tool >>>

by Pete (no login)

DIM l AS STRING * 4
DIM c AS STRING * 6
_LET l = "Luke"
_LET c = "Clippy"
PRINT l == c

---------------------

Output: Luke and Clippy are the same, they just can't stand each other.

Like Steve's amazing new double equals sign addition? Is it basiC enough for everybody? No, well then check out the best Steve can do, reinventing the LET statement with _LET. It still doesn't accomplish a damn thing, but it is now modernized to piss off people living in the Stone Age.

Kidding aside, The SDL version should be debugged to a finished working version, and referred to as the BASIC version of the language. PowerBASIC saw the need for that in their project. Their development team strives to be professional.

Pete



Posted on Sep 28, 2014, 9:02 AM

Respond to this message   

Return to Index


Re: Reuse to be equated to Clippy? Too late! Steve's new comparison tool >>>

by SMcNeill (no login)

Actually I'd like to see a new, more powerful version of LET enter the language.

Something like:

_LET array(10) = {0,1,2,3,4,5,6,7,8,9,10}

Isn't that nice and quick to write, and simple enough to follow along with what it'd do??

_LET x(2 to 4) = {-1}

And look, we just set x(2), x(3), x(4) to all being TRUE...


There's a lot of potential for a new, expanded _LET command in the modern language! Thanks for bring it to my attention Pete! I'll start working on it now and see how quickly I can add it to the language for you. ;)

Posted on Sep 28, 2014, 9:16 AM

Respond to this message   

Return to Index


You should just go write libraries...

by Pete (no login)

Maybe call it: Steve's Amazing WHOGAS Library, but then I'm not great at names.

Your mentality seems to approximate anti-BASIC learning principles. You really should code in something else. A BASIC approach to learning is giving the user a sparse amount of tools, that a user could mix and build functions, libraries, etc. That was one of the things I loved about BASIC. Building blocks are preferred over prefabricated designs, because they require ingenuity. They also allow for a tremendous amount of customization, instead of the "my size better fit all" BS that never works. That's a stumbling block you are headed for. Good thing you wear boots, what troubles me is they have 6" spike heels.

Pete

Posted on Sep 28, 2014, 10:57 AM

Respond to this message   

Return to Index


i will tell you the turning point though. here's what you guys did

by mn (no login)

the last time someone made a version of "basic" where basic stopped being important, the change was when the project was held to lower standards than the criticism of it.

suddenly anyone offering bug reports or critiques were held to this craaaaaazy standard of proof, while completely gutting the ideas that guided the project in the first place didn't even need defending, because "code! eat it!"

this is a chronicle, nothing more. it's just a little ahead of the game is all.

pete's way ahead, but last time this happened there were signs. critque being held to higher standards than project goals is one of the most important ones, but this is almost a 1:1 match of what happened before in practically every way. no idea what i'm talking about? no problem.

i've been all over the internet looking for programming, and do you know where i've seen freebasic? mentioned in passing once or twice (in 5 years.) i've seen way more people talk about how much they loved qb when they started out with computers, so suck it. qb64 was a project that could have kept that going. oh well. galleon's got a kid, do you think s/he's going to code in basic? i don't, but you guys have fun figuring out why. (here's a hint: you can't teach what you don't know.)

Posted on Sep 28, 2014, 6:16 AM

Respond to this message   

Return to Index


my less dogmatic-than-usual take

by STxAxTIC (no login)

I've been reading a lot of Doug Crockford lately. He's the guy who re-validated the JavaScript language by simply ignoring the "bad" parts, stripping it down to a robust subset of the language, and publishing a book on that. Nowadays you can port nearly ANYTHING to a browser through JavaScript. His idea about using only "good" parts of a language obviously works. The lesson I'm getting from Doug is that you don't need the unneeded parts to be deleted, just ignored.

Now - given Crockford... and given that Luke's description of the "automagic" inclusion of components is working how I think it does, then this discussion must end completely, right now. Not for philosophical reasons at all, but for technical ones, which is better! Luke, I know you aren't a 1000 degree firebrand in terms of your overall hostility toward people, but you must spell out this "automagic" thing for stubborn asses like myself and mn. Do it with some bite. MAKE people realize!!! (For the moment I take it on faith, and I do trust you, but not everyone does yet.)

And everyone needs to team together to stop publicly shit talking QB64 for a few minutes. We should contain the bad publicity to IRC channels, for the sake of Google only finding only the BAD things that we've all said over the last month. I've been prowling on lots of obscure forums lately, and certain parties are *gleeful* that QB64 is having this kind of trouble.

The whole project is suffering in terms of popularity, and the QB64 forums are full of... well, lately, nothing... No good samples (sorry to anyone who has tried.)

Steve's OBVIOUS JOKE release was just that - a sarcastic joke. Whether this was intent or not, he surely made the point that that QB64v2 is completely non-viable unless, as I pointed out, it can self compile. Steve deleted too much for this to happen, so that idea will need to be more carefully implemented if it's to work. You have to , at the very least, be able to compile the QBXXX/x.bas file using its own EXE.


Summary of everything, bullet point style:

* Commands added to the language don't seem to bog down your program if you don't use the command. (If this isn't true, then burn this whole message.)

* The subset of all _NEW-FANGLED commands can be ignored, and QB64 to this day is backwards compatible way into the early 90's. Nothing is lost yet.

* Steve and co.'s "language-transforming" ambitions are not fundamentally-transformative to the project. Only Galleon can royally screw it up. We are all safe under Steve while our General is absent.



Posted on Sep 28, 2014, 6:06 AM

Respond to this message   

Return to Index


i'll let pete have the obvious pun if he shows up

by mn (no login)

* Commands added to the language don't seem to bog down your program if you don't use the command. (If this isn't true, then burn this whole message.)

you might as well say the ocean will stay contained IF the sandbags hold, but i appreciate your message. and while slippery slopes "prooove" nothing, there's still a good reason people don't stand around on slippery slopes (except luke, he thinks it's a water slide.)


* The subset of all _NEW-FANGLED commands can be ignored, and QB64 to this day is backwards compatible way into the early 90's. Nothing is lost yet.

but the subset of all _this (and personally i'd like to see galleon's commands with an underscore and everyone else's with two, because the less basic-like the commands are, the harder they should be to type. NO CLIPPY I'M JOKING... ugggggh, too late, sorry.)


* Steve and co.'s "language-transforming" ambitions are not fundamentally-transformative to the project. Only Galleon can royally screw it up.

unless of course he abandons it and deletes all the old versions (i'm not serious about the old versions. please don't come explain to me why they were deleted, i know already.)


i don't lump you in with anyone else there bill, but if you ignore the parts of javascript that suck, you end up with plain old html. that's no good either, because plain old html doesn't exist anymore. css and qb64 are (becoming) hopeless implementations of good ideas. and while a kid could program in qbasic or make sites in html, css would have most scientists scratching their heads.

for you and you only, i ask you this one honest question: is the learning curve of qb64 increasing? it never had to. that wasn't a goal or a necessary evil.

IF it is, you're screwed.

if it's not, i'm wrong.

answer, wait a year, answer again.

thanks.


"everyone needs to team together to stop publicly shit talking QB64 for a few minutes."

i appreciate the human touch behind this, but it is actually one more sign, sorry.

Posted on Sep 28, 2014, 6:37 AM

Respond to this message   

Return to Index


thanks for responding

by STxAxTIC (no login)

Thanks for your reply mn, everyone knows I have a foot in both camps, so to speak, haha...

I will very seriously address and counter-address the points above to the best of my ability.

* We really need Luke (or someone) to properly spell out how the "automagic" mechanism works. Until then, your sandbag analogy is accurate, but realize you've set up the pins to be knocked down. Suppose that a QB64 program IS safe from the unused commands? Then what? The sandbags hold. End of that argument.

* You make a fair enough point about perhaps a double underscore system for new commands. Perhaps Galleon and only Galleon can have the "power" to convert a double underscore command into a single underscore command. I don't care much about this one.

* The old versions are gone and gone, and we need to accept that. There's nothing inherently wrong with the GL edition or its latest variations. The fact that it performs comparably, if not better than, FreeBASIC is a GIANT testament to the maintenance of this project. If we have nothing to compare to, then fine... But there IS some competition out there, and frankly, QB64 is all-around better than FB.

I mean, QB64 has such a good foundation, I can see it STILL it outcompeting Python for simple things. (It's already won in the area of stand-alone EXEs.) And no, I don't mean programming for kids. I mean programming for men (and women) who want to get something done with small time spent coding.

Now, I know GL a buggy edition still. My advice to Steve is concentrate on what needs fixing. Oh, and Steve, you NEED Linux on your machine. Get it done!

...

Let me answer the question about the learning curve. Presumably you mean the beginning of the curve? In that case, the learning curve is COMPLETELY static. That is, it was no harder or easier to learn 1990's BASIC than it is to learn 2014's "good parts" of QB64.

Enter the learning curve on a higher position, aka, not a beginner - and it becomes even MORE trivial. QB64 looks like trivial scripting compared to the low-level complexities that a C programmer endures.

By every single measure, the learning curve is not the issue, I think. I really think the ACTUAL issue here is: we are all bored. Everyone shut up and code something. Post your code some place, and we can talk about each other's work and all improve in that way.



Posted on Sep 28, 2014, 7:04 AM

Respond to this message   

Return to Index


there's nothing wrong with the mechanism

by mn (no login)

think about the language on paper for a moment. that's what i do, it helps make these things clearer.

think about why underscores really exist. i'm in favor of them, and i was going to propose a way to get rid of them anyway.

(it's complicated. basically i believe pete when he says that they will eventually be abandoned anyway, and i wanted to come up with a way to to do it that he was ok with.) note neither of us wanted to see them go away.

but this isn't about underscores or no underscores. if you can guess why they're there (and i swear i'm not talking down to you right now, but it's still important) you can figure out why you don't (once it reaches a certain size) want the language to lump all commands together. whoops, gave you the answer.

the mechanism is fine.

Posted on Sep 28, 2014, 7:18 AM

Respond to this message   

Return to Index


Re: thanks for responding

by SMcNeill (Login SMcNeill)
R

I've basically decided there's no point in debating anything with mn; he proved he suffered from an overbearing God-complex when he declared, "it's basic only if I say it is.... RAHR!!" He can go away now;his blind self-obsession now just bores me instead of amuses me, as I don't like to take amusement from the delusion ally challenged.

But, in regards to Bill saying: "* The old versions are gone and gone, and we need to accept that. "....

^ This is incorrect. Go to the google repository for QB64, and you can download the language from as far back as the start of GL almost. SDL unfortunately was never put into the repo, but there's over 100 versions of GL there, each which highlights what code was altered with each change. Should someone wish, it'd be a trivial matter to do, undo, revert, or exclude whichever alterations they personally disliked.

Those old versions aren't gone. They're safely stored in google code repo, along with a historical roadmap of what each version added or addressed.

Posted on Sep 28, 2014, 7:38 AM

Respond to this message   

Return to Index


* by "gone" I mean "out of order", duh :-)

by STxAxTIC (no login)

Posted on Sep 28, 2014, 7:50 AM

Respond to this message   

Return to Index


* 7

by mn (no login)

Posted on Sep 28, 2014, 7:52 AM

Respond to this message   

Return to Index


your other points

by mn (no login)

* You make a fair enough point about perhaps a double underscore system for new commands.

please, please, please don't implement that. i said it was a joke the first time. it would make everything much more difficult. i was making a point that was illustrated with underscores, but the point was NOT about the underscores. point to the moon and people look at the finger and not the moon? please, don't add to the underscores. don't let clippy add to the underscores. (feel free to add an underscore to clippy.)


* The old versions are gone and gone, and we need to accept that.

the sooner you realize we don't have to "accept" anything, the better you'll get it. you don't have to get it, and i think you do get it, but this is a minor thing you should try to get in addition to the rest.


* There's nothing inherently wrong with the GL edition or its latest variations.
The fact that it performs comparably, if not better than, FreeBASIC is a GIANT testament to the maintenance of this project.

it does? (i'm incredulous.) did it a year ago? (if it's gotten 10x faster, okay, you win that one.)


* QB64 is all-around better than FB.

you're taunting me, but i'm going to let this one pass.


* QB64 has such a good foundation, I can see it STILL it outcompeting Python for simple things. (It's already won in the area of stand-alone EXEs.) And no, I don't mean programming for kids. I mean programming for men (and women) who want to get something done with small time spent coding.

i'm not at all interested in a pissing match (nor accusing you of one) between the two. qb64 SHOULD be better, at least for beginners and intermediate coders.

rather this is a pissing match between dialects of the same language (as it should be.) the only reason that's not in the past tense is because you're the one that's talking right now (that won't change the trajectory but it changes the tone.)


* Let me answer the question about the learning curve. Presumably you mean the beginning of the curve? In that case, the learning curve is COMPLETELY static. That is, it was no harder or easier to learn 1990's BASIC than it is to learn 2014's "good parts" of QB64.

that is a copout. the initial features are the more important part of the language. they're not there just for streed cred. (they provide cred, but they shouldn't fall back on that every time someone questions the direction things are headed in.)


* Enter the learning curve on a higher position, aka, not a beginner - and it becomes even MORE trivial.
QB64 looks like trivial scripting compared to the low-level complexities that a C programmer endures.

yes, i can think of another dialect that could be said about. the fact that you're comparing it to c and not basic means the bar has been moved, but it's been lowered-- if it must be moved, it should be raised.


* By every single measure, the learning curve is not the issue, I think. I really think the ACTUAL issue here is: we are all bored. Everyone shut up and code something.

you're much more polite and thoughtful about this, but then you go and whip something out from the old fb vs qb playbook (i don't think you realize this, or that it's on purpose.) seriously, if i had only 25 checkboxes i could get 2 from you, 6 from steve and at least 3 or 4 from luke before we even talk about where the project itself is headed. it *will* take the shape of the community, that's what such projects do.

i'm just watching. don't let the fact that i'm commenting fool you, this is more predictable than you know and it's not going back now.

Posted on Sep 28, 2014, 7:51 AM

Respond to this message   

Return to Index


then it ain't so bad

by STxAxTIC (no login)

Yeah, there are certain "classical" arguments to make when talking modern QBasic - one such argument is similar implementations of the same thing in other places. Unfortunately, FreeBASIC is just about the ONLY viable enterprise that compares to QB64. LOL! how is it "impolite" to mention FreeBASIC here?

I don't think my response to the learning curve question is a copout. I agree that too many C-level or C-imitation constructs could be a silly thing to add to the language, but at the level they're at now, they are merely Steve's occult objects. If you just sit down with the QB64 IDE and you haven't programmed since 1992, you will never (i) know, or (ii) need to know about new commands. You already agreed that the mechanism is not the problem, and it already emulates QB45. I see no room for your points from a *technical* standpoint, maybe a philosophical one only.

So please, from a technical standpoint, and taking into account the great description given by Luke, what precisely is the problem now?

Posted on Sep 28, 2014, 7:59 AM

Respond to this message   

Return to Index


another classic

by mn (no login)

* Yeah, there are certain "classical" arguments to make when talking modern QBasic - one such argument is similar implementations of the same thing in other places.

* Unfortunately, FreeBASIC is just about the ONLY viable enterprise that compares to QB64. LOL! how is it "impolite" to mention FreeBASIC here?

simple forum etiquette. but that's pete's department (it's obviously not mine.) if we do it long enough he will say something. there are reasons. were you here then? not a challenge, just a question.

if it's going to be reduced to technical arguments, it's not going to work. i don't mean our conversation, i mean the project. i can make technical arguments all day. you know what trumps technical arguments? people that are predisposed to not getting them. i don't mean you. but the matter of bug reports and criticism having a higher standard of proof than (buggy, saboteurish) code?

that's a non-technical argument that puts any technical arguments right to bed. also it's like saying "let's talk about everything EXCEPT what's wrong, then i'm sure you will realize everything is fine." people have got to be stupid to fall for that, even if it's just temporary stupidity. pete is always smarter than that, and i at least try.

Posted on Sep 28, 2014, 8:30 AM

Respond to this message   

Return to Index


actually bill, THIS:

by mn (no login)

"it was no harder or easier to learn 1990's BASIC than it is to learn 2014's "good parts" of QB64."

there are obvious reasons (e.g. humans are involved) that no language can be 100% "good parts.'

but everyone's falling back on the good parts to justify the other parts.

you've really nailed the problem, while defending it.

can't it be MOSTLY good parts? including the new parts? NO. that's more or less it, and start the countdown until the foundation fails to hold up the rest of it. why stop with a good foundation? budget cuts, changes in management, and worst of all, a community that doesn't get it. i want a divorce, and pete already filed. you can keep the 64, but we want BASIC. they can't give us that much, but you can. this just isn't working, after all.

Posted on Sep 28, 2014, 8:03 AM

Respond to this message   

Return to Index


how about a special case

by STxAxTIC (no login)

I much appreciate your responses mn - and nothing personal or hard feelings whatsoever, of course.

But I believe you are cornering the argument into higher levels of abstraction, so let's bring the rubber back to the road for a second. (I accuse you of wimping out, not me, in other words.)

We agree that the plain BASIC command subset is arguably a "good" part of the language. Further, there is the argument that any new STRCMP stuff belongs in the "bad" subset. So far so good?

Let's talk about _PRINTSTRING for a second. With the old LOCATE command, you are stuck on a course-grained 80*25-or-so coordinate system for placement of text. With _PRINTSTRING, you can locate text by the pixel. Much finer placement is possible. BUT! If you are a good programmer, and you have a few more minutes to spend on it, you can achieve the same functionality with pure QB45 era code. You can place text at fine resolution, its just more work. Therefore, for the sake of this philosophical box, lets call _PRINTSTRING a "bad" command. It's redundant in a sense.

But what about something not redundant (to my knowledge)? What about the TCP/IP stuff? Correct me if I'm wrong, but I don't know at all how to get a pure QB45 implementation to connect to an IRC room as a chatbot, for instance. I need QB64's _OPENHOST (I think) for that. Thus, I classify file all TCP/IP stuff as "good" parts. You can't (again, to my knowledge) achieve this the old way.

My question to you: And this gets right to the heart of the matter... Do you consider features that are not redundant - ie, things that were impossible the "old" way, to be completely bad and useless? We are on the same footing that they are not original "BASIC", but do you consider Anything outside of that sphere to be useful? Would you agree that TCP/IP commands are a good thing in QB64?

Posted on Sep 28, 2014, 8:26 AM

Respond to this message   

Return to Index


sorry about this one

by mn (no login)

if you really want me to get to it, i will. unfortunately, i was replying to it and put the laptop down and the battery eventually went out.

and i'm sorry, if that seems incredible, you'd have a harder time believing why i put it down. i'm not ignoring you, but you have me right when you say i'm wimping out as this goes on. i really wanted to say my piece, and it's not realistic to think i can say what i said and not get replies, but i have steve right where i want him... over there, and not bothering/with me. the rest of them can go too. you can stay, and if you insist, i will get around to answering you as well.

they can think i'm backpedaling or whatever it takes.

but in the meantime i'll skip to the end of your post: how many times do i have to say i'm not against new features? that's something people put on me. i never said that, and over and over i've said the opposite, in no uncertain terms. where to go from there we may totally disagree on, but this isn't about that anymore. for you we can make it about that, but only until you're satisfied you've gotten a real answer.

Posted on Sep 28, 2014, 2:18 PM

Respond to this message   

Return to Index


thanks

by STxAxTIC (no login)

Thanks sir, your answer is clear.

We both raise our internet voices over concern for the project, not to be trolls, that, I think, EVERYONE can agree that we all do mutually here. Everyone cares. The thing to do is let time run its course. In the meantime, I'm a non-unhappy QB64 user. Dare I say, hopeful?

Posted on Sep 28, 2014, 2:50 PM

Respond to this message   

Return to Index


Re: how about a special case

by SMcNeill (Login SMcNeill)
R

< Do you consider features that are not redundant - ie, things that were impossible the "old" way, to be completely bad and useless?

And here's the point of contention. _STRCMP seems redundant to you since it could be done using an old method, but to me it doesn't. Let's compare a few simple strings...

String 1 is 100,000 bytes in length.
String 2 is 100,000 bytes in length.

Let's compare these with the old method:

FUNCTION STRCMP (s1$, s2$)
IF LCASE$(s1$) = LCASE$(s2$) THEN
STRCMP = 0
ELSE
IF LCASE$(s1$) < LCASE$(s2$) THEN
STRCMP = -1
ELSE
STRCMP = 1
END IF
END IF
END FUNCTION

Now, how efficient is this method?

First we take 100,000 byte string and we make it a temporary 100,000 byte lowercase string.
Then we take the 2nd 100,000 byte string and make it into a temp 100,000 byte lowercase string.
Then we compare. If equal we return 0 and free the temp strings.
If not, then we repeat the process and check once again.....

**********************

Now, this will work, but how much overhead and delay is such a process going to bring into your program? (Picture this as part of your math program with multiple recursive calls if you want.)

***********************

Now, the new command:

Result = _STRICMP(s1$,s2$)


This checks byte 1 of string 1, ignores case, checks byte 2 of string 2, ignores case.... If those 2 bytes are diferent, it returns a result at this point....

Single byte compare vs single byte compare, no need for temp strings with LCASE$ over each string and no need to generate multiple lines of code, increase memory requirements, or introduce that lag into the system.

*****************************

It's a cross-platform function with a speed and efficiency that we just can't generate with the old commands. And it seems sad to me that when someone wants speed and efficiency that they more or less have to give up writing code in BAS and convert it to C++ like you're having to do with your calculator.

Since QB64 translates to C/C++ code, WHY would someone need to translate their routines to C to make them faster?? Why can't we access the same C routines natively for their speed and optimization??

Simply because people will then say, "IT'S KILLING BASIC!!!"

.............


Which is going to kill it more: Having access to routines that run on a comparable efficiency level and translate directly to C code, or having serious programmers be told "don't bother with QB64, write your work in C instead: it's the only way you'll ever optimize it."

If your calculator ran as fast in QB64 as it can in C, would you feel the need to learn, struggle, and translate to a different language??

Posted on Sep 28, 2014, 3:08 PM

Respond to this message   

Return to Index


I'm a bad person to ask this question

by STxAaxTIC (no login)

First off, just to be clear, I don't find C++ a struggle, and my translation has been a breeze. But that's because I write smart QB code and C++ is easy to understand, which is an entirely different story. Plus I've been dealing with CERN Root for years, so I'm sorta cheating on being "new" to C++. That ain't the case.

To QB64's credit, I will still want to use it as a graphics layer temporarily, and maybe take advantage of the "new" stuff that it does, like TCP/IP things, but if you haven't noticed, that's all I want it for. (And frankly I could use Python or FB for the same non-QB45-era things. I could continue on tomorrow no problem if QB64 died today.)

But more to the point, I don't care how close QB64 gets to C under the hood, because to me it's still a middleman. Hate to say it, but I agree with Pete's "shortbus to C" comment. BASIC is BASIC, C is C... Any overlap between the two is unneeded by me, regardless of the performance improvements under the hood. I'm perhaps a bad person to ask because I consider BASIC and all its dialects to be a prototyping language. Stand-alone EXEs were a nice advance into making final products with it, and maybe QB64 is all the amateur needs, but I have strong inclination to NOT let a middleman stand between me and C-family code. So yes, I was destined to put my greater works into a stronger language than QB64, no matter how close to C you can make it. Long buses only for me.




Posted on Sep 28, 2014, 3:55 PM

Respond to this message   

Return to Index


there's definitely a way to have it all

by mn (no login)

steve says i have a god complex, because of my opening line about how "it's basic if i say it is." there was another way, of course.

but it's like this: for every non-basic-like feature you add to basic, to you have to try that much harder to keep the whole thing basic-like.

they're not even slightly concerned with that. it's pretty much a free for all (if you write the code that makes you special, if the code isn't basic it's still part of a basic project so whee, helping. critics, not helping.)

you CAN'T add non-basic features and keep the thing "basic" unless you balance that out with EQUAL OR GREATER care that the whole thing be basic-like. and that's a full time job, not something you can work back in little piece by piece, after turning it into a language for people that want c-basic, by people who only know c-basic (these days.)

but he who writes the code, carries the weight (what rhymes with load?) and yet, most people (the community, the coders too) only have time for one or the othar. that's the ONLY reason they can't have both. and you will see which one they care more about, with time. anwyay from now on, steve can run all my points through his new "basic" function, _STRMAN. it's all good. it makes arguing much less complicated when we all just throw our hands up and say "forget it."

galleon put basic in the front seat. now it's in the back seat.

it doesn't matter if steve even turns around and "gets it," because he'll have other people who don't pushing for it to stay in the back seat.

but for you, bill, let me tell you: you can do ANYTHING, ANYTHING in basic and have it basic like, with or without my approval.

so long as you care more about basic than c, basic than new features, basic than what people who don't care about basic want.

it's about nothing but priorities, about nothing but what comes first. so long as basic comes first, you can have all that other stuff. all of it.

there's even a way to have a broken string compare function which exposes a c-like name with or without underscores AND STILL BE BASIC.

but then it's all uphill, and mark my words, basic has been given up on already.

the only people who care about basic more than this other crap are me, you, pete, and a couple people who aren't here.

you know what a community of people who don't care about basic do with a basic language that only three people care is basic (only one of whom actually uses it regularly?)

qb64.

it's not up to me, i don't want it up to me.

i want it to go back to being in the hands of people who put basic first, so i don't even have to think about it.

that's how it should be, and it was doing fine without me.

do you get me yet bill? beacuse i think you can. no, i'm not messing with you, i'm only trying to tell you this because i think you ACTUALLY get it.

and since you're the last person who does, i figure "why not?"

but it's cool if you don't see it my way. it's cool if you think the project has more time left.

i'd rather not be proven right, but it's not up to me.

either you will come to see this as pete and i do, or as steve and luke do, or you will find your own way.

for now anyway, you might as well be correct. tell me again in a year though.

back when i used to have the kind of concerns i've voiced (to a lesser degree) in earlier versions, galleon always had a smart answer. we didn't talk directly, mostly thorugh myst.

myst was smart. galleon was a genius.

i hear he's still working on it. fine, maybe galleon can prove me wrong again. i'd LOVE it.

not this time. even galleon had people that cared about it being basic-like when he was working on it.

don't fall for the arguments they and i exchange. they aren't serious, and i see no need to prove anything to them.

in the current state of things, they can't have c AND basic. they could have anything if basic mattered more. it doesn't, so they can't. which means you're right, but only because of circumstances.

you'd think these guys never heard "the devil's in the details." i defy you to find someone around here who has time for that. those who did, aren't interested anymore. why would they be? even you (in an innocent way) have made it clear that isn't necessary. what's necessary? we should all shut up. tell me when you're ready. no you're great, just tell me when you want to talk about something other than qb64. we'll put an end to it whenever you like.

Posted on Sep 28, 2014, 5:44 PM

Respond to this message   

Return to Index


equally solemn but a tad shorter

by STxAxTIC (no login)

I think we've all come to some sort of peaceful stasis about this, kindof like that moment being in the same room with an ex-girlfriend no longer creeps you out. Know what I'm sayin? It's a scarred but relieved feeling.

Speaking of knowing who's saying what, I completely see your and Pete's side of this whole thing, and am perhaps 51% on that side of the fence, plus or minus 49% given my Ping-Pong-ball-like mood about this whole thing. Sometimes, I say to myself "QB64 is the ONLY alternative, and dare I say potentially BETTER option than Python, despite the popularity asymmetry. We better help this stay possible." ... Other times, it's "I had better jump ship, and port all of my good stuff over to C++. I can handle SDL2 myself." Truth is...

I have become not only comfortable in this duality, but I find it to be a *necessary* struggle. It's the ONLY factor that keeps me programming in many languages simultaneously, each with the deserved fury due unto it. It's the factor that keeps my QB code clean as a whistle's ass. To translate: because of the fact that QB64 feels like a leaky boat at times, it keeps me on my toes as a programmer. The other extreme is to become too relaxed and attached and in-rooted into QB64. I see the pitfalls of doing that in ANY language, just falling head-over-heels for all of its constructs and edge cases and whatever... It's a "let the coder beware" thing... and to wrap this whole thing up, finally once and for all, I point out the immutable fact that remains: QB64, right now, is still 99.9% QB45 compatible. It's not broken yet.

Posted on Sep 28, 2014, 6:38 PM

Respond to this message   

Return to Index


Oh come on Bill, do the math!

by Pete (no login)

How did you arrive at 99.9%? QB64 can't handle multi-modualr programming, it doesn't support DEF FN, ON PEN, ON PLAY, FRE, it doesn't support CALL ABSOLUTE routines, and a handful of other stuff. I actually had a considerable amount of work to do to get my large apps running on QB64, and they are all in SCREEN 0. Lucky for me, I used the CALL INTERRUPT mouse routine, which was supported.

Maybe 98% compatible would be a better guess, but that's all it is , a guess.

Anyway, it is the most compatible, even though 100% compatibility was abandoned. It was supposed to be 100%, but oh well. You think it would remain BASIC, but i that follows pattens, it will be like "modern" milk, 2% BASIC.

And get the hell off the fence Bill. You're blocking my view of what that fiddling farmer is dong over on the other side! :)

Pete

Posted on Sep 28, 2014, 7:35 PM

Respond to this message   

Return to Index


you caught me

by STxAxTIC (no login)

...being inexact. Fine, 99.9% was pulled out of my hat. I should have said 100% for my own case... but this is because maybe I had a shallow view of BASIC in the first place. I don't think I've ever used a low-level QB command before, so my code just tends to go. Nor did I deal with the mouse. Somehow I knew not to "go there" in my old QB days. Seems like I could at least done that one...

Although it's a crotch splitter, I'm gonna stay here on the fence. It's a tall fence, and fir that reason avails a fence-sitter a comfort in both perspectives of this argument. Maybe more people should join me up here on the fence. There's lots of room, it's quite sturdy, and you can see quite far from up here.

Posted on Sep 28, 2014, 7:50 PM

Respond to this message   

Return to Index


Well at least you're leaning in the right direction.

by Pete (no login)

But then Rome wasn't built by people sitting on fences. Actually, it was built by people good at knocking down other people's fences, but I digress.

I do agree with your philosophy of not being dependent on any given language. The only reason I was motivated to stick with QB6 was it was a C translator, and I knew C would be one of the most stable languages in the industry.

Frankly, it was pretty amazing to have a proficient C/C++ coder who was more interested in BASIC to do the project. That is what the community sorely lacks at this juncture in time.

Pete




Posted on Sep 28, 2014, 8:02 PM

Respond to this message   

Return to Index


The old versions of qb64 are actually still there just not linked anywhere

by qbguy (no login)

On the internet archive:

https://web.archive.org/web/20121016235903/http://www.qb64.net/forum/index.php?board=2.0

In fact, many of the files still hosted on QB64.net, just not linked anywhere (at least until Galleon deletes them) ; for example, I can type

wget http://www.qb64.net/qb64v0942-lnx32-lnx64.tar.gz

to download version 0.942 for Linux

The old Linux versions are even GPL compliant as they do not actually ship any libraries but require the user to install the libraries on his system.

Here are the URLS for some ancient versions of QB64:

http://www.qb64.net/history/qb64v01.zip
http://www.qb64.net/history/qb64v02.zip
http://www.qb64.net/history/qb64v03.zip
http://www.qb64.net/history/qb64v04.zip
http://www.qb64.net/history/qb64v05.zip
http://www.qb64.net/history/qb64v06.zip
http://www.qb64.net/history/qb64v061sc.zip
http://www.qb64.net/history/qb64v062sc.zip
http://www.qb64.net/history/qb64v063sc.zip
http://www.qb64.net/history/qb64v07.zip
http://www.qb64.net/history/qb64v079.zip
http://www.qb64.net/history/qb64v079r.zip
http://www.qb64.net/qb64v08.zip
http://www.qb64.net/qb64v081.zip
http://www.qb64.net/qb64v081x-win.zip
http://www.qb64.net/qb64v0873-win.zip

Posted on Sep 28, 2014, 7:02 AM

Respond to this message   

Return to Index


*bonus. thanks.

by mn (no login)

Posted on Sep 28, 2014, 7:28 AM

Respond to this message   

Return to Index


Re: my less dogmatic-than-usual take

by Luke (Login flukiluke)
R

Getting back to the technical stuff sounds like a wonderful idea. To address STxAxTIC's bullet points, they are: mostly and soon to be fully true; true but I don't know why you'd want to; true.


So, here's how the 'parts' system currently works:
When QB64 compiles your program, certain commands have special 'flags' attached to them. This flag alerts the compiler that extra code, a.k.a a 'part' is required to make the program work. When it comes time to call g++ to compile the C++ code, QB64 compiles each part separately, then links those code objects into the main program.

Of course, there is some caching going on, so each part is precompiled. Do not confuse compilation with linking though; the compiled code exists as a .o file in the internal/ folder only; it will only be linked into your code if its flag is set.

The parts system is still relatively new, and as a result, there is still much code that remains in the core. As it stands, the only things that are parts are libraries written by others, such as TrueType for fonts, the image and sound decoders, and gamepad support (it's not finished yet, by the looks of it). However, there is a network/ folder which suggests to me that the networking commands at least will one day also become a part. Recently I've been looking at more aggressively modularising the compiler - the big areas I've been exploring are the graphics commands at the INP/OUT/CALL ABSOLUTE support (no point including a 16 emulation or graphics commands in a modern SCREEN 0 program). Hopefully I'll have something to propose to Galleon soon, and although it's probably a little different from his original idea of the parts system, I think he'll look on it as within his vision for the language.

Of course, that is the future, and we must not neglect the now. As it stands, added keywords are tiny; in terms of line of code, they total to around 100. For comparison, the windows-specific code in the SHELL command totals to around 180 lines. I appreciate that this is still an impact, and is at a risk of growing over time, ao I am also looking at extending the current "User Mods" interface (the current method of adding routines to QB64) to adding parts. As mentioned above, this would reduce their footprint to 0 when they are not used.

As STxAxTIC mentioned, only Galleon really has the power to crash this into a wall from a technical angle. He's the one calling the shots on the big design decisions, and anyway, the hg repository means he can erase contributions with a few clicks if he doesn't like them.

All in all, I feel QB64 is at a good place in terms of technical development. Quite a few of the annoying little bugs are being fixed, and Galleon is actively working on fixing the bigger issues like GL performance on some Windows systems. It's still in beta, but I feel in the next year or so, the way things are going, we should have a pretty decent language.

Posted on Sep 28, 2014, 7:06 AM

Respond to this message   

Return to Index


ROFL at modern SCREEN 0.

by Pete (no login)

Can't wait to screw that up too? Maybe it needs hardware acceleration! Already I see signs the community can't even support users for business applications adequately. It's OK if it wants to support a bunch of lamers, SWAP L, G, but I see while this is happening the same thing I saw happen in FB, anyone who wants something that is not within the new direction of flow gets trivialized.

Pete

Posted on Sep 28, 2014, 11:08 AM

Respond to this message   

Return to Index


"nyone who wants something that is not within the new direction of flow gets trivialized"

by MN (no login)

yes, but can you put that in technical terms, though?

if not encapsulated in functional ansi-c, could you at least form a coherent, rational argument in backus-naur form? if that much can't be done i see no reason to take a word of it seriously. in fact, how are we supposed to even understand what you're saying otherwise?

also more importantly (and in the voice of steve martin)

NUH-UH!

Posted on Sep 28, 2014, 2:41 PM

Respond to this message   

Return to Index


OK fine

by E.W. Dijkstra (no login)

Consider the grammar:

F := ⊥ (falsum) | ⊤ (verum) | A | ¬F | (F ∧ F) | (F ∨ F) | F → F | F ↔ F | ∀ X F | ∃ X F

A := T(X) | F(X) | W(X,X) | P(X) | B(X) | X | X = X

X := [a-z]X | ε

with the following semantics:

T(X) is the predicate "X becomes trivialized", F(X) is the predicate "X is in the new direction of flow", P(X) is the predicate "X is a person", and W(X,Y) is the predicate "X wants Y", B(X) is the predicate "X is an animal"

∧ means et, ∨ means vel, ¬ means non, x → y is the same as y ∨ ¬x, x ↔ y is the same as (x → y) ∧ (y
→ x), ∀ means omnis, and ∃ means quoddam

For example, "∀x P(x) → B(x)" means "omnis homo est animal".

The statement in question is " ∀ x ∀ y (P(x) ∧ W(x,y) ∧ ¬F(y)) → T(x)"

Is everything clear now?

Posted on Sep 28, 2014, 3:24 PM

Respond to this message   

Return to Index


* You left out (i)nfluence = BS ^ 2. :)

by Pete (no login)

Posted on Sep 28, 2014, 3:29 PM

Respond to this message   

Return to Index


use _X$ with _A% and concatenate the IOCTL MEMCPY

by mn (no login)

_A$ = MV AX &H1200 IOCTL MEMCPY(:= T(X) | F(X) | W(X,X) | P(X) | B(X) | X | X = X) + _X$ := [a-z]X | ε

it's so much easier with the new syntax, why would you even use the OLD backus-naur form?

Posted on Sep 29, 2014, 6:52 AM

Respond to this message   

Return to Index


QB --> C++ Translation

by STxAxTIC (no login)

Hello folks,

My usual habit for working on a big project is to get really excited about a particular update, and then go and post on one forum or another as if it's my personal dev blog. That junk is over with. This new endeavor is too big.

What I'm doing now is carefully translating my largenum calculator from QB to C++, where the central library is 7200+ lines of QB45 code. This figure doesn't count any gui, graphics, or input layers. Over 7k lines of pure math.

I want to share my progress to interested parties *somehow*, so I will quietly updating a little website I just made:

http://people.umass.edu/wfbarnes/STxAxTICMathTranslation.html

What you'll find there now is a handful of QB functions - some keywords and some custom - translated into C++. As I cranks these functions out, they are tested to their limit to make sure they compare to the QB original. This has actually been easy to do, and as a result I've so far been able to code largenum addition, subtraction, and multiplication. Division is half done.

It will take several months to get this done, so check out the above page casually. I'll only update forums with vey significant updates.

Posted on Sep 25, 2014, 12:10 PM

Respond to this message   

Return to Index


who has heard of asm.js?

by STxAxTIC (no login)

I may be digging up old news, but if you haven't seen it yet, sit though this talk:

http://www.youtube.com/watch?v=tMEH9OMYmsQ

... I'm completely fascinated (for some reason) with running C++ code in a browser, and it appears that the following utility will let ordinary guys like us do it:

http://kripken.github.io/emscripten-site/docs/introducing_emscripten/about_emscripten.html

I plan on getting into this (probably) today. Makes me wonder (my stupid question of the day) - can the C++ code generated by the QB64 compiler be cranked through this thing? Imagine that...!

Posted on Sep 26, 2014, 11:28 AM

Respond to this message   

Return to Index


* it works awesomely, C buffs must try

by STxAxTIC (no login)

Posted on Sep 26, 2014, 11:59 AM

Respond to this message   

Return to Index


*you need (MMFMFMMM) for that

by mn (no login)

Posted on Sep 27, 2014, 6:30 PM

Respond to this message   

Return to Index


* does that mean male-male-female-male-...etc?

by STxAxTIC (no login)

Posted on Sep 28, 2014, 6:36 AM

Respond to this message   

Return to Index


i can't make a pun about that on this forum. pete is braver than i am

by mn (no login)

it's a good interpretation, but it was just supposed to be forced mumbling. like me talking with my hand over my mouth.

it's too late, i've already summoned them. they haven't been here in years but it's only a matter of time.

Posted on Sep 28, 2014, 7:27 AM

Respond to this message   

Return to Index


Testing...

by Pete (no login)

CLS
 PRINT "This is a test using non-breaking spaces in HTML to indent code."
  PRINT "Each line should be indented one space more than the next."
   PRINT "This line should be indented 3 spaces to the right."

Posted on Sep 24, 2014, 12:47 PM

Respond to this message   

Return to Index


Pete - please quit breaking my forum.

by gopus (no login)

I will forgive you just this once.

Posted on Sep 24, 2014, 8:49 PM

Respond to this message   

Return to Index


Re: Pete - please quit breaking my forum.

by Pete (no login)

S   O  R    R      Y    !

Posted on Sep 24, 2014, 8:56 PM

Respond to this message   

Return to Index


The Photobucket program does not work correctly either

by Clippy (Login burger2227)
R

It no longer allows me to select one of the other pictures listed in Windows 7, just the first one.

[linked image]

You can hit Zoom to get the links of other ones. I HATE WINDOWS 7!!!!!!!!!

Posted on Sep 25, 2014, 8:43 AM

Respond to this message   

Return to Index


image didn't properly show

by STxAxTIC (no login)

If that was supposed to be the guy "killed" two or three years ago, the image looks scrambled. To me, it looks like a guy who has been dead for 10+ years and held up as a dead puppet.

Body or it didn't happen.

Posted on Sep 25, 2014, 9:42 AM

Respond to this message   

Return to Index


That's all you are is STATIC!

by Clippy (Login burger2227)
R

[linked image]

Posted on Sep 25, 2014, 9:52 AM

Respond to this message   

Return to Index


* the second image is a bit more clear

by STxAxTIC (no login)

Posted on Sep 25, 2014, 11:49 AM

Respond to this message   

Return to Index


For STxAxTIC: SDL 2.0 from a link I looked up last year...

by Pete (no login)

http://forums.libsdl.org/viewtopic.php?t=9375

Notice the 3D and Android OS support. Supports OpenGL, too. While it is true that SDL was never as popular a choice as OpenGL, which makes me wonder why Galleon decided on it in the first place, last year we could have used it, and the project would probably been further ahead instead of dirty build bug ridden. I'm glad Steve wasted his time stripping out the underscore commands in the GL version. At least it should work!

Too bad I don't have either the time or inclination to work on an SDL 2.0 version. While Steve spent his day being an ACII, I spent my day working mine off making improvements on one of my properties.

Pete





Posted on Sep 22, 2014, 10:01 PM

Respond to this message   

Return to Index


cool link, here's one in return

by STxAxTIC (no login)

For those interested (or who insist upon) doing (subjectively) everything by themselves, the guy over at LazyFoo productions has made an awesome set of tutorials on all this stuff - SDL, SDL2, OpenGL, and so on. I won't lie - this is the set of tutorials I used when tinkering with the original SDL last year (I made it as far as plotting points and lines, which was effectively all I needed to 3D projects. However, it was enough for me to penetrate the subject, and I'll say the tutorials are actually helpful.

http://lazyfoo.net/SDL_tutorials/

Posted on Sep 23, 2014, 8:05 AM

Respond to this message   

Return to Index


Re: cool link, here's one in return

by Pete (no login)

Well put together. It almost makes it tempting to create a custom fork of QB64 replacing SDL with version 2. Wouldn't it be nice if all that took was updating the SDL package for existing QB64 on SDL programs. Of course anything less than install and run would put me through additional time learning (C)rap to get it working, and of course there are the non-fixed bug issues that would need to be addressed over time.

Well, I don;t have time to fork around with it anyway, other commitments these days, but it was nice to be just finished with a big summer project, and come back here to find all this stuff to discuss. reminded me of the good old days, when QB was taught in schools and had several active communities.

Pete

Posted on Sep 23, 2014, 11:41 AM

Respond to this message   

Return to Index


QB64 --- errr QB45v2

by SMcNeill (no login)

Well, I decided to make Pete and everyone else happy.

BEHOLD!!!!!

http://www.qb64.net/forum/index.php?topic=12214.msg105547#new


QB45v2... Errrrr.... QB64, the QB45v2 edition.... Errrr... Whatever you want to call it. Let's name it WXVZYTPD!!

Anyway, XWZBVYPL is the latest version of QB64 with all the up to date bug fixes and corrections -- but WITHOUT any cumbersome BASIC keywords. All gl commands were removed. All underscore commands removed. All user added commands removed. Unless it's a standard BASIC keyword, it's gone and unusable!!

No bloat here. Just good old fashioned QB45 and nothing more. No 32 bit images, no loading images, no fonts, none of that non-basic jazz. All underscore commands are gone, and only the ones that were part of the original language remain.

Enjoy guys! Now QB45 can have the timeless monument to its perfection preserved and there's no reason for anyone to ever worry with how QB64 expands or changes in the future. I promise, I'll never meddle or add anything new to QB64.45... It's BASIC, the way it used to be!! :P

Posted on Sep 22, 2014, 1:28 PM

Respond to this message   

Return to Index


totally brilliant

by mn (no login)

even if you're just being sarcastic and missing the point, this is probably the most clever such a retort can be. i find it hard not to admire that.

*hattip*

plus it could be useful!

Posted on Sep 22, 2014, 2:31 PM

Respond to this message   

Return to Index


* And it truly runs, compiles, and ONLY supports QB45 keywords. ;)

by SMcNeill (Login SMcNeill)
R

Posted on Sep 22, 2014, 2:40 PM

Respond to this message   

Return to Index


*no matter how i interpret that, it's hilarious

by mn (no login)

Posted on Sep 22, 2014, 2:42 PM

Respond to this message   

Return to Index


i notice it does not work out of the box "no compiler" etc.

by mn64 (no login)

comedy gold.

steve, you're so full of surprises it's hard to keep being surprised. just when i think you don't get it, you fix it. just when i think maybe you get it, you do stuff like this. how do you remain so spontaneous and unpredictable? i look forward to your next trick.

also pete thinks it's funny that we think you're the project leader now. it's a simple test, the leader is whomever makes the most excuses and understands the users the least. wouldn't that make it you? but damn if you haven't been responsive. at least you're not a recluse, at least you answer to this stuff. well, sort of.

Posted on Sep 22, 2014, 2:53 PM

Respond to this message   

Return to Index


Re: i notice it does not work out of the box "no compiler" etc.

by SMcNeill (Login SMcNeill)
R

You can't have it both ways! Do you want a non-bloat version or not?? I tried to make it as small as possible for you guys!

MINGW is completely optional. Plug the x64 version in and make 64-bit EXE files. Plug the i386 version in and get 32-bit EXE files. Or use a different C-compiler completely.

But THAT's C and not BASIC. Do you think it'd be OK if I included it? I don't know that much about what people would find suitable C compilers, and which versions of THOSE might be considered "bloated", so I thought it'd be best to leave that choice entirely up to the end user to decide for themselves. wink.gif

Posted on Sep 22, 2014, 3:06 PM

Respond to this message   

Return to Index


if that's what you consider "putting c in basic," then it's really about where you put it

by mn (no login)

i think i speak for a couple of people here when i say that right now, i can tell you where to put it.

you're doing some important things right now. when they're done i really don't know wtf you'll be doing. but "haha," i get it. because it needs c to compile, right? yuk yuk yuk.

Posted on Sep 22, 2014, 3:28 PM

Respond to this message   

Return to Index


Re: if that's what you consider "putting c in basic," then it's really about where you put

by SMcNeill (Login SMcNeill)
R

Do you want to know the honest reason why I stripped out the compiler??

It had nothing to do with C or just making a point about us having to use C(even if it does do that; LOL!). The whole reason was I was going to upload it to the QB64 forums, and it needed to be smaller than the 30MB file limit. MINGW is something like 2-300MB in size, and even compressing 90% down it still gives an addition 20-30MB to the download....

Which puts the overall size larger than the QB64 forums allows.

So it was removed as all existing QB64 users already have a version they can just copy/paste and move into that folder.

And the file size zipped down to 14MB!!

Which is STILL too large to upload in 30 seconds to the website with my bandwidth! Stupid timeout limits...... /grumble


So I ended up hosting it in my Dropbox, and I was just too lazy to move the compiler back into the 7z file. :D

Posted on Sep 22, 2014, 3:46 PM

Respond to this message   

Return to Index


some of us just want to get on with our lives

by mn (no login)

maybe we're too stuck in our ways. but those who aren't probably wouldn't need qb64 in the first place.

qb64 is a great compiler as it is. i hope someone picks it up some day and fixes it up. thanks to galleon for the source. thanks for fixing ascii in strings. thanks for a fun time, honestly.

Posted on Sep 22, 2014, 3:53 PM

Respond to this message   

Return to Index


* I was nice enough to even upload the standalone version for those interested now. Enjoy!

by SMcNeill (no login)

Posted on Sep 22, 2014, 4:40 PM

Respond to this message   

Return to Index


this is an excellent tool for the use and study of QB64, thanks!

by STxAxTIC (no login)

One question remains... any chance on repeating the same exercise on the SDL version?


:-)

Posted on Sep 22, 2014, 6:02 PM

Respond to this message   

Return to Index


*Probably not. I don't do much messing around with SDL that often anymore.

by SMcNeill (no login)

Posted on Sep 22, 2014, 6:34 PM

Respond to this message   

Return to Index


i noticed...

by STxAxTIC (no login)

...that when I delete qb64.exe and compile again it from the BAS file, the new EXE shows up in the original c:\qb64 folder, and not at the new location. Jus thought folks might wanna know.

Posted on Sep 22, 2014, 6:51 PM

Respond to this message   

Return to Index


NEVERMIND! * (dont be an idiot like me)

by STxAxTIC (no login)

Posted on Sep 22, 2014, 6:53 PM

Respond to this message   

Return to Index


*but i am having trouble with self-compile

by STxAxTIC (no login)

Posted on Sep 22, 2014, 6:59 PM

Respond to this message   

Return to Index


Re: *but i am having trouble with self-compile

by SMcNeill (no login)

With the normal QB64, or with the QB64 --QB45v2 without any of the new keywords?

I'm afraid QB45v2 won't compile itself. QB64 needs access to the extended command set to compile itself.

If you look in the source, you'll quickly see things such as:

DIM SHARED AltSpecial AS _BYTE

_BYTE, _FLOAT, _BIT, any of the _UNSIGNED variable types weren't supported in QB45, and yet the QB64 source is riddled with them. You can't compile the QB45v2 without having and using a regular copy of the bloated old QB64. QB64's internals are too complex to run with QB45 support alone.

Sorry.

It's a drawback that comes from deciding that one doesn't need any support more than what we had back in the 90s for their modern programs.

Posted on Sep 22, 2014, 8:32 PM

Respond to this message   

Return to Index


well, nice effort, but...

by STxAxTIC (no login)

if it's COMPLETELY unmaintainable, then... well, you know... I'm not sure who wants it. If we want an immutable EXE, then QB45.EXE works fine already.

Posted on Sep 22, 2014, 8:55 PM

Respond to this message   

Return to Index


Re: well, nice effort, but...

by SMcNeill (no login)

You can maintain it. You just have to use a full version of QB64 to do so.

From what I remember, you couldn't compile QB45 from its source either. You got the program, and you used it. Lots of people were happy with that, and it seems that's what a lot of people want from QB64 -- nothing more than the same base level of programming that QB45 used years ago while BASIC was still basic.

Really, I think it's a great little exercise for people to try and use. It'll help quickly highlight just how many of those non-basic underscore words we've grown accustomed to and rely on.

I honestly couldn't go back. I rely on 32-bit colors, _RGB32, _PRINTSTRING, and countless other commands too much to even try and code QB45 compatible programs.

Posted on Sep 22, 2014, 9:16 PM

Respond to this message   

Return to Index


very well

by STxAxTIC (no login)

... and sorry for giving you so much shit. I'm really really really gonna stop now.

But after all, a room of screaming men is a sign of a functioning democracy.

As for my particular choice of software(s), I'm going to stick with QB64 and keep up with all the dirty builds.

My secondary prong of investigation is now implementing SDL2 in C++ myself, which isn't hard at all.

Primarily though, I'm buried in the C++ translation of my Sxript calculator, which is going exceedingly well (Luke: got largenum addition/subtraction finished last night). It required translating a few BASIC keywords to C++, etc. etc. etc., but it's going exceedingly well. This is perhaps a testament to writing clean, function-based, non-spaghetti QB45-era code. I find translation to other languages a breeze (up to graphics, of course).

It makes me eyeball the prospect (in the distant future) of doing my own very crappy attempt at Galleon's original effort, except it will be sitting on SDL2. Because I proceed carefully on projects, I will try this in say, 10 years.


Posted on Sep 23, 2014, 6:04 AM

Respond to this message   

Return to Index


the idea of a calculator that does other things

by mn (no login)

is really, really cool. it's not like i haven't heard of the ti-83, but now that i can afford one it's more like a ti-phone.

what i haven't heard of is a calculator *program* that has other features. you say you're translating it (at least, you said it's a "translation.") i'd like to see the source code if it's online, even if it's in a language i don't like (that's really only fair, i dislike most.)

Posted on Sep 24, 2014, 4:23 AM

Respond to this message   

Return to Index


I thought nobody would ever ask...

by STxAxTIC (no login)

Hello,

Since every project in the world is a little bit misnamed, it's hard to call this a largenum "calculator" as much as I call it a "mini programming language"... It's hard to explain, so I'll stop interrupting and let the work speak for itself. The main writeup is at:

http://people.umass.edu/wfbarnes/STxAxTICMathWriteup.html

... And if you wanna jump instantly to the nitty gritty, the backbone library file is (just a few links down on the page above, but for completeness, here it is again):

http://people.umass.edu/wfbarnes/webstxmth/STxAxTICMthLib_FB64.bm

Posted on Sep 24, 2014, 5:49 AM

Respond to this message   

Return to Index


Wow, a website that doesn't suck. It's actually put together really well.

by Pete (no login)

And I thought about starting with only the complement part, but after years of opening links to "look I have a website" posts and instantly becoming the model for that shocked face emoticon, wow, nice surprise. Now I didn't expect the horror show in your case but on the contrary, you could professionally set up sites if you wanted to.

You have a lot of content, great continuity, a well though out scheme, simple to understand indexing and navigation, and a good balance between examples, graphics, and discussion.

Give me some time and I will link your site from here.

Pete

Posted on Sep 24, 2014, 6:36 AM

Respond to this message   

Return to Index


made entirely in notepad

by STxAxTIC (no login)

Thanks for the kind words from what otherwise seems like a tough crowd!

Now the pressure's on for me to fix the grammatical blunders and finish the index of keywords...

In other news, I just used Walt's site as a blog basically, but I posted some code examples having to do with the C++ translation of the library:

http://thejoyfulprogrammer.com/qb64/forum/showthread.php?tid=173

Posted on Sep 24, 2014, 10:03 AM

Respond to this message   

Return to Index


Tough crowd? Tough gathering maybe...

by Pete (no login)

I suppose we were a crowd back in the day. As for tough, I'm glad to be part of a community here that is outspoken. PCism is all about accepting. I saw a woman today crossing against a light that turned red less than her traversing half-way through the intersection of a busy highway. She was pushing a baby carriage... and here's the worst part... talking on her damn cell phone. In PC land if anyone hit her, he would be at fault because. OMG she has a baby! /Rant

Anyway, it is an awesome site and I plan to visit it regularly to embarrass myself about how much math I've forgotten over the years. Luckily, I can still help my kid in Algebra II, but I think that is about as competent as I am these days.

So we've learned that Pete is vocal about things he likes, as well as things he doesn't like. And all without using any analogies to farm equipment.

Pete

Posted on Sep 24, 2014, 11:13 AM

Respond to this message   

Return to Index


i had less luck with his site. probably because i had 150 tabs open

by mn (no login)

that's 150 tabs with only 1g of ram. you get a lot better performance without javascript on

still, i had trouble with the site. i saw it, it looks cool, i mentioned the calculator in my song. that's why i wanted to ask bill if there's a qb(any "qb") version of the calculator he can post somewhere, so i can see the code.

yeah, i got a lot of boxes with code in them. it's not that i don't like the design. but i'd like to look at the code for the calculator if possible, and the code for the library (if needed) if possible. can those be posted to the forum, at all?

Posted on Sep 27, 2014, 6:41 PM

Respond to this message   

Return to Index


* (its full of typos still, just look at the pictures, haha)

by STxAxTIC (no login)

Posted on Sep 24, 2014, 6:22 AM

Respond to this message   

Return to Index


Re: QB64 --- errr QB45v2

by Ben (no login)

The cool thing about QB was that to do a litte more advanced things, for example mouse routines, you had to go beyond and resort to assembly language (call absolute), POKE around memory and hardware ports or registers. It was really inspiring and made you learn about the inner workings of the OS and computers. To do something like load bmp image files youd have to write your own routines and bsave/bload were really simple and basic. In qb64 you have a lot of that stuff built in adding bloat and spoiling the prpgrammers learning experience. Freebasic is really where its at when it comes to modern basic but I understand its despised here for some religious reasons. I dont even believe you guys understand what OOP even is the way you talk about it. Anyways, the BASIC experience does not exist with qb64 and it will always be a petty toy language and compiler. At this point in my prpgramming, the language and syntax barely matters. The skills and algorithms are more abstract and carry over to any language and environment which a prpgrammer should be able to pick up in a week or so anyways. These days I mainly use C and Matlab for most of my work
I still mess around with the qbasic interpretter on DOS and may port something to qb64 if I want to share something here with my many names.

Posted on Sep 23, 2014, 11:59 AM

Respond to this message   

Return to Index


Qb45v2

by Ben (no login)

I think the idea is pretty cool. The only thing a modern QB45 really needs for modern expansion is the syntax to work with the modern hardware and os features such as accessing the vast 32/64 bit memory, gfx framebuffer and higher graphics resolution modes. Thats it. The rest should be left to the programmer.

Posted on Sep 23, 2014, 12:05 PM

Respond to this message   

Return to Index


* Not religious reasons, comedic ones.

by Pete (no login)

Posted on Sep 23, 2014, 12:31 PM

Respond to this message   

Return to Index


on the contrary (concerning FreeBASIC)

by STxAxTIC (no login)

I think I wear the tightest straight jacket of them all. My easy steps for coding in QB:

I) Think very hard.
II) Open notepad.exe and write down the answer as FOO.BAS
III) Open FOO.BAS in QB64 and let it indent the code for me.
IV) Write #lang "qb" at the top, ignore syntax error made by QB64.
V) Compile in FreeBASIC
VI) Compile in QB45 <-- if ( fail ) { manage array sizes; goto II; } else { code next program; }

Posted on Sep 23, 2014, 6:36 PM

Respond to this message   

Return to Index


I suspect there are several FreeBASIC users...

by Pete (no login)

...running around in straightjackets. Well maybe not running, try bouncing off of well padded walls, instead. That project was a fail in the beginning. It may work better now, but it would have been a horrible journey at the ground floor level. Of course when failed promise after failed promise kept hitting the fan, the community pretty much went in the direction that FB was superior to QB, and why would anyone want what they promised in the first place? The first thing the project was supposed to do is compile your QB programs, The first thing the project should have done was buy you dinner. It became more of a short bus to C than a BASIC programming language. I never even got simple SCREEN 0 programs running on it. Later it included that -lang QB switch.

PowerBASIC for DOS was always better. QB64 was the only real compatible alternative, and it is a shame it didn't come along about year earlier, ditch the IDE part, and finish the compiler about 3 years sooner. That would have made for a much larger community. The unfortunate timing saw a lot of people drift away from QB syntax and into other languages. The most appreciated component of QB6 is probably the ability to compile and run older programs people don't want to take the time to convert, but would still like to use. Unfortunately, a lot of the stuff was just school projects I'm sure most users could care less about.

All that is really important in the end is that the programmer is happy with whatever language they have chosen to code in. In that regard, it is wonderful to have choices... even bad ones. :)

Pete

Posted on Sep 23, 2014, 7:48 PM

Respond to this message   

Return to Index


...shortbus to C.... LOL!

by STxAxTIC (no login)

Have I ever paid due compliment to your better-than-mine punning skills? You are a funny guy sir!

I'm in the same headspace as you are on that issue - I tend to disenjoy floating around in language constructs that are a substitute for the real thing. ((Want C/C++? Get a MAN's compiler, not a software suite to hold your hand.))

... which is why I only use FreeBASIC in compatibility mode with #lang "qb" at the top. Beyond that, I have no clue in the world what FB is good for. For plenty of things (particularly plotting graphics in SCREEN 12), FB is... can I borrow Luke's word, which then passed to Steve?... "oodles" smoother than QB64.

I know SCREEN 12 is not SCREEN 0, but it's reason enough for me to make sure my code can squeeze through FB. Any chance on giving it another shot?

Posted on Sep 24, 2014, 6:42 AM

Respond to this message   

Return to Index


Re: ...shortbus to C.... LOL!

by Pete (no login)

I would be very surprised if my 80,000 lines of "simple" stuff... I suppose the only reason that word bothers me is Steve used it, and at his level, referring to someone else's stuff as simple would be akin to understanding the meaning of life from the perspective of a microorganism, but I digress.

We interrupt this message reply for QB64 HEADLINES: Steve's Amazing new _CLS command. It clears the screen 10% faster, without streaking.

And now, back to our message...

I would be interested in reading your reply on how FB operates smoother than QB64.

I also totally agree about the man up and learn C part. One of the problems I see QB64 facing is fewer of the "old guard," as mn would put it, influencing the project. Galleon was the best C programmer with regard for keeping it BASIC the project ever had. Now I think the influence has shifted to a handful of C-eolites hell bent on going down that FB path. I think it's called C-questration, but I've been too isolated in BASIC to know for sure.

Pete





Posted on Sep 24, 2014, 7:27 AM

Respond to this message   

Return to Index


oops, forgot to respond

by STxAxTIC (no login)

About the FreeBASIC > QB64 thing:

I don't necessarily have a lot of "measured" evidence of this, more phenomenological evidence / observations... The main things (two or three of them) that make me say FB is smoother than QB64 are:

1) Animation in SCREEN 12 3D Worlds - When plotting particles and panels in 3D (all software, no hardware cheats), FB is more responsive when you really push the system. It hides its flaws a little better, flickering less, more instantaneous PAINT command, stuff like that.

2) Largenum calculations are more stable in FB. On Windows at least, QB64 gave me (perhaps) memory problems that amounted to a crash when computing giant numbers, like 3000-factorial. In FB, the same calculation with the same code churned out answers, no problem. To QB64's credit, the calculation WAS stable in Linux. If memory serves, Luke was able to compute 2000-factorial (and I believe he runs the SDL version). (I'll test this on my own Linux build in time.)

3) Executables made by FreeBASIC are generated instantly. I play my operating system like a first person shooter. Right hand on the mouse, left on WSAD. So if *I'm* going to act quickly, *everything* better be just as quick. The way I compile a FB program is to drag and drop the BAS file onto a shortcut to FBC.EXE, and boom, it's finished. Compare that with the minute-long process to do the equivalent in QB64, well, there is no comparison. (My patience is too short!)

Posted on Sep 25, 2014, 2:01 PM

Respond to this message   

Return to Index


SDL compiles faster than GL

by Pete (no login)

That was my experience. Dirty Builds I suspect suck, I won't even try them. SDL compiles fst enough for my needs. GL didn't. Thanks for reminding me about another reason I'm not good with the direction that project took.

Also, thanks for the reply explaining what you meant by smoother.

Pete

Posted on Sep 25, 2014, 6:18 PM

Respond to this message   

Return to Index


Bignum arithmetic tips

by qbguy (no login)

I looked at your bignum multiplication code, and it appears that it creates its output by builting temporary string by concatenation. I am not too familiar with the QB64 internals, but it appears that QB64 may be copying the temporary strings when building the output. i.e. concatenating foo$ = "0" + foo$ performs a copy of foo.

Your factorial function might be sped up if the output string is preallocated:

' s1$ and s2$ are natural numbers
DEFINT A-Z
FUNCTION mul$(s1$, s2$)

' preallocate output
last1 = LEN(s1$)
last2 = LEN(s2$)
last = last1 + last2
out$ = SPACE$(last)

product& = 0

FOR i = 0 TO last - 1

K = last1 - i
sj = 1 - K: IF sj < 0 THEN sj = 0
ej = last1 - K: IF ej > last2 - 1 THEN ej = last2 - 1
FOR j = sj TO ej
product& = product& + VAL(MID$(s1$, K + j, 1)) * VAL(MID$(s2$, last2 - j, 1))
NEXT

MID$(out$, last - i, 1) = CHR$(48 + CINT(product& MOD 10&)) ' set digit in the 10^i place
product& = product& \ 10& 'carry the next digit
NEXT

IF product& THEN out$ = LTRIM$(STR$(product&)) + out$
mul$ = out$
END FUNCTION

This could be sped up further by multiplying multiple digits at a time.

Factorial of 20000 calculates instantly in Python or MIT Scheme; these implementations also use binary instead of decimal in their internal representations.

Posted on Sep 25, 2014, 6:50 PM

Respond to this message   

Return to Index


I stand corrected Luke & thx qbguy

by STxAxTIC (no login)

For some reason I assumed what I did... oops.

As for largenum calculations, I'm open to all suggestions (up to a limit of course, I'll implement what I can learn, not what I can just plug in - the next person who says "just use Matlab" is gonna lose their head on account of missing the point entirely).

There are in fact three independent largenum multiplication functions in the library - some better than others for certain things - the one I threw online is the most naïve "single digit" version. My more sophisticated (no longer aptly named) "multiplication prototype" does just what you said by breaking the calculation into chunks. I'll be translating and posting that... eventually...

For factorials, I've become very impressed with Python 3's "divide and conquer" method. In time, I'll be implementing a similar algorithm. For the moment though, I'll have a good look at what you posted above. I'm completely open to new and faster math functions - you're already in the credits for past pi: http://people.umass.edu/wfbarnes/STxAxTICMathWriteup.html#credits

Posted on Sep 25, 2014, 8:39 PM

Respond to this message   

Return to Index


* No, I use the latest version of GL from the repo

by Luke (Login flukiluke)
R

Posted on Sep 25, 2014, 7:35 PM

Respond to this message   

Return to Index


* I'm glad you like 'oodles'

by Luke (Login flukiluke)
R

Posted on Sep 24, 2014, 5:40 PM

Respond to this message   

Return to Index


"c" is for crusading, that's good enough for me

by menn (no login)

it's ironic that you think we've got a religion, because the charge we're always having thrown at us is that we're stubbornly refusing to convert. it's been a long time since someone came here and told us we don't understand oop, but it used to be every day that people stopped by explain how backwards we are, when all we wanted to do was use the tools we enjoyed using. we're still painted as zealots for resisting assimilation.

what you see people here protest the most is not oop or any other new features, but having stuff shoved down our throats. that's happened enough times that there are a few ways to see a foot in the door, but it's definitely been a while.

every missionary thinks that if people don't accept jesus, it's because they don't understand how great he is, or how important it is to be part of the congregation. the problem is i don't see a congregation, i just see a con. as for steve, he just doesn't get it. qb64 was our refuge from years of condescension, and for a few years, it stood up. if that's starting again, steve's takeover is complete.

"new" isn't the real problem. i used gwbasic for years and i was pretty excited when i tried qb40 and qb45. much more recently, qb64 was the closest thing i've had to that experience since then. but now that we have an opportunity to learn about objects, maybe this time we'll finally give in. i guess that's what reasonable people would do in our situation, so i suppose it's lucky we don't have to worry about a reputation for being reasonable.

Posted on Sep 24, 2014, 3:24 AM

Respond to this message   

Return to Index


I thought "C" was for cookie...

by Pete (no login)

And I don't give a Fig Newton of why people who pursue new stuff cannot understand why others prefer older stuff over double stuffed.

I have never needed a more "modern" programming language to get what I wanted done. I enjoy building applications at a BASIC level. I don't need or want the option of OOP. RealBASIC had that, an it really, really sucked. What I can do is appreciate the speed which the use of libraries, objects, despite the bloat which CPU speeds mitigate anyway, bring to users who don't so much care how to program a function, but rather want to use functionality to make an application in less time.

"B" is for BASIC, that's good enough for me.

Pete

Posted on Sep 24, 2014, 7:48 AM

Respond to this message   

Return to Index


* Dammit. Now I can't get that cookie song out of my head!

by Pete (no login)

Posted on Sep 24, 2014, 7:49 AM

Respond to this message   

Return to Index


if your tractor breaks, at least you have a place to sit

by written in sections, so (no login)

maintaining a foss computer language is more like flying a plane. if you pull up too steep, it stalls and dives. if you pull up a little and you're going too fast, it stalls and dives. every time you turn it loses some altitude, so don't be surprised when the community tells you to adjust (but not to climb too fast.)

if you can keep it away from the ground, there's not usually much to run into. but if people are strapping on parachutes and leaping out, consider that THEY'RE not being obtuse. (i won't speak for me.) maybe they simply noticed that the engine is on fire.

Posted on Sep 22, 2014, 10:11 AM

Respond to this message   

Return to Index


don't think i'm all metaphors and no concrete reasons

by posted in sections (no login)

take ascii-gate for example. (if you don't think calling it that is hilarious, i won't use it again.) because of qb64v0945, i think galleon is the most amazing basic coder of all time. as much as anyone from dartmouth, he belongs in the BASIC hall of fame, if they ever build one. but strings are fundamental.

need a real-life scenario? take any binary file (a raw image from a camera, an iso file,) load it into a file handle or string. in qb64, a huge binary string isn't unlikely, esoteric, or even super-geeky. you don't want core string commands to stop working, just "because c." we're not stretching the language here, this is how it's supposed to work.

in the case of an image file, i've written basic programs to do this very thing, you might want to compare two images in raw file format. you might compare three-byte sections (each pixel.) there's just no reason for a string (or compare) function to break more than it has to.

what's it do? compare strings? so if the behavior is something else, it's broken. it's fixable, and should be fixed unless it's broken for compatibility with year-old programs. if functions are added, great. hopefully they will be functions that a. work as proposed or b. get fixed or c. don't get added at all. (easy mnemonic: "c doesn't get added at all.") anything else is probably a bug, and we don't *need* bugs.

don't worry that there's too much talk going on. a lot of talk < a lot of code contribution, but a lot of talk > a lot of breaking things and leaving them that way. talk is cheap, but work that gets done without gaining any feedback is only worth so much.

even hypothetically, it's not unreasonable to expect working functions. so thank you again for working on fixing string handling. it could prove to be the biggest problem galleon left in qb64, you should feel pretty accomplished if you fix/ed it. (no lie.)

if this mundane sort of progress was *common,* galleon wouldn't have needed to write qb64 in the first place; the other options would have sufficed. qb64 has made it much farther because these things mattered. don't break what works, and don't make a habit of adding things that are broken compared to what works.

Posted on Sep 22, 2014, 10:13 AM

Respond to this message   

Return to Index


we desperately need a new word for "bloat"

by mn (no login)

...because the side (related) points are much more vital than the "bloat" matter itself. we need a new word because *nothing* i have to say about it negates anything that galleon has said. what galleon said is 100% fine by me.

it's not about megabytes (we're fine mb-wise,) it's about the learning curve that's created (exponentially) when you have an unlimited number of commands being added to the global namespace of a language.

that's a real (if upcoming) issue that could be mitigated by appending the _ prefix. yes, appending to it. so instead of _ for every gl command, it would be _gl for every gl command. if you're not very careful, this would end up c-ifying the language further.

it's important that qb64 not expose c to the user (in the source it's no problem.) basic should not emulate c, but the other way around. the reason is that if qb64 emulates c, then it *will* become another useless un-basic-like dialect. you can be for that or against it, and people being for it is exactly why galleon had to create qb64, so that at least qb64 did not have that problem.

before you mention that basic catered to asm routines, remember that the language itself was nothing like asm. someday inline c would not be a problem but i'd wait, for reasons pete can easily explain. (we haven't even talked, it's just obvious why waiting would help.) qb64 as a dialect should be modeled no more after c than qb45 was modeled on asm, regardless of what's under the hood. cars are such great metaphors.

it's great that you can get to the spark plugs, pulleys, oil filter, washer fluid, and battery terminals just by stepping outside and putting the cover up. but imagine what it would be like to drive with all of those things in your face?

you'd have stains all over the car and the interior would be hideous even when it was clean. don't make basic like that. basic is incredibly readable and easily writable, because it's designed better than just "throw everything a big pile." if enough thought goes into it, non-garbage is usually what comes out.

in short, don't make excuses for qb64's shortcomings. (that's *our* job, and one we should take more lightly than what something is NAMED.)

Posted on Sep 22, 2014, 10:14 AM

Respond to this message   

Return to Index


qb64 needs a better way to include things (and why this is key)

by mn (no login)

people have often stayed away from the way that qb did it. add all the compatibility you want (i think that's already implemented,) it's so unfriendly it went largely unused. i have some proposals, and if pete doesn't like them then forget about them. but don't do anything like this until there is something identical to or very close to identical to consensus. (it should probably even require clippy to pass.)

better library management is central to making qb64 excel as the modern language you want it to be. it's probably more than you're up to coding yet, (no offense, it's more than i'm up to coding) but that gives us time to plan and reach agreements on things. as pete implies, that should be part of the process in a community this small (not always consensus, not *never* rocking the boat, but at least not dumping everyone out whenever someone steps on board.)

Posted on Sep 22, 2014, 10:15 AM

Respond to this message   

Return to Index


rushing headlong into features (or not)

by mn (no login)

a project around a basic compiler has NO REASON to rush headlong into new features. you say "core functionality is different. it has to work" or something. yes! right attitude. when you press new features that aren't built on other things working, people start to be afraid that it's either/or to you. that fear is based on it happening in every other foss basic project, ever. it's not paranoia, it's bonified care.

if additions are solid, we've maintained a foundation for the future. qb/45 as a foundation is good, but if the rest is flimsy then we'll have a roof on (not "over") our heads. if the community puts the foundation first, and (some) spirit of consistency second, adding features third, microsoft will someday wonder how they ever failed to kill basic after all ("seriously? vb wasn't enough?")

that's probably when the lawsuits will start. there was/is a product called ironpython, which tried to embrace, extend and extinguish python. it failed. i'd like to see qb64 get far enough to receive that kind of attention. thank you again for working on the nul problem.

Posted on Sep 22, 2014, 10:17 AM

Respond to this message   

Return to Index


it's kind of too bad that new features have to be added in c

by mn64 (no login)

...because once string comparison is fixed, all you'd have to do to make strcomp work properly is make a routine like: return lcase$(x) = lcase$(y) 'more or less this. that should work, once string handling in qb64 is fixed.

if every new feature has to be implemented in c, that will slow down the march of new features, which is a good thing since they should be secondary. imperfections made qb fun, but that's no call to add more imperfection than is necessary. the more that is up-to-specs the less things will suck, and you have a number of experts on specs here, who can tell you when it's broken and incompatible. like you, we work for free! kumbaya...

maybe it's a relief that extensions have to be in c, but it also means that one of the very few people that can help is michael. (mainly a problem because we have a limited number of him.) i have no interest in being a c programmer, even for this. if qb64 was implemented in python i could help, but that's probably a terrible idea.

(it would make it trivial to merge the sdl and gl versions and make it a simple option, but i'm not seriously proposing we reimplement an entire compiler in an interpreter. plus we'd have three versions for three environments on two architectures: qb64gl32-mac, qb64gl32-linux, qb64gl32-win, qb64glx64-mac, qb64glx64-linux, qb64glx64-win, qb64sdl32-mac, qb64sdl32-linux, qb64sdl32-win, qb64sdlx64-mac, qb64sdlx64-linux, qb64sdlx64-win, qb64python32-mac, qb64python32-linux, qb64python32-win, qb64pythonx64-mac, qb64pythonx64-linux, qb64pythonx64-win)

think that's messy? that's a lot like what the future looks like** unless someone makes stxaxtic happy somewhere down the road. don't do it for him, do it for qb64.

** (just not for this reason. it's not because of the license either... i would be *thrilled* if someone forked qb64 right now, because if they fixed things they could possibly be merged back into the original.)

Posted on Sep 22, 2014, 10:20 AM

Respond to this message   

Return to Index


Re: it's kind of too bad that new features have to be added in c

by SMcNeill (Login SMcNeill)
R

The problem with Bill's argument is it's a step BACKWARDS.

QB64 GL has a parts system which chooses what to add to your code. Don't use sound? It doesn't link to the sound parts and they never affect you. You don't need some silly 'INCLUDE$:'BEEP' to use the BEEP command. Type it, and THEN presto-automagically, it works with your EXE.

Same with _FONTS.... They're there as soon as you type a _FONT command, but not before...

WHY require a manual command to make BEEP available for us, when it can be done automatically??

****************************

Push for the expansion of the parts system if you want -- heck, I'd love to see that myself. But to push for something manual over an automated process that works invisibly to the end-user?? It's stepping backwards, not forwards.

*****************************

I don't know enough python to guess how it handles commands, but imagine a magical C-based IDE that knew all the function names and their headers. If you typed atan2 as a command, it automatically clicked a checkbox internally for math.h, making it available.... Wouldn't that be lovely?? Better than having to include math.h yourself?

The IDE sees you used a math.h command, so it includes and makes math.h available.....

THAT's basically the parts system in QB64.

Why move backwards with INCLUDES when we should move forward with automatic seperation and connection of parts as needed? happy.gif

*******************************

Now, one of you C-gurus tell me how to add or move existing commands into that parts-system, and I'll do it happily for you. Heck, get me started and I'll set a different part up for every command as long as it doesn't generate too much lag for us. I'm more than willing to learn, if someone is willing to show me the process once. wink.gif

***************************
***************************

As for a routine that returns lcase$(x$) = lcase$(y), that's undesirable.

First it's a call to read the whole string, alter upper to lower.
Then read the second string, alter upper to lower.
Then read both altered strings, compare byte by byte...

A much better case is to:
Read string1, read string2, compare bytes and if bytes for either is "A" to "Z" OR 32 those to make "a" to "z" and do it all in one fast pass, without the overhead of multiple function calls and their error-checks and everything else... wink.gif

One function, one set of error-checks, all handled in one stop is faster and more efficient than calling multiple functions, going through each of their error routines and then doing the same process. happy.gif

Posted on Sep 22, 2014, 12:00 PM

Respond to this message   

Return to Index


i appreciate what you're saying

by mn (no login)

> imagine a magical C-based IDE that knew all the function names and their headers. If you typed atan2 as a command, it automatically clicked a checkbox internally for math.h, making it available.... Wouldn't that be lovely?? Better than having to include math.h yourself?

yes it's ideal, up to a point. for a language the size of qbasic or qb45, it is definitely ideal. for a language the size of qb64v0954 (0495? 5309?) it's still ideal. the way things are going, i think it's going to be a problem.

it depends what you think the problem is. if the matter is inclusion, i've addressed that elsewhere. i'm not against what galleon says about it. if the matter is megabytes, i think qb64 is doing fine and the mechanism you're working on is fine, too (in my opinion.)

i would never argue for a language being more formal than it has to be, i prefer simplicity. but even if it's as automatic as what you have in mind, i think the language will need layers eventually. not just layers for the sake of binaries created, but layers so people don't have 400 commands that aren't grouped together.

at the very least, they should be named in a way that groups them. definitely NOT graphics.opengl.ellipse.rotate, but maybe all gl commands should start with _gl.

one of these days i'm going to have to download the project and see what i can make of it. if you find a way to organize it now, in a way that is obvious to the community, it will make it a lot easier to support in the future.

not just for devs/contributors, but for anyone that is answering questions like "is there a command for..."

don't need it yet. rather than dismissing it as a step backwards (i appreciate that you want it to be easy for the user) we should all try to get bill's ideas into a form that reaches you. but as far as compiled binaries goes, i think your idea is fine/great/wonderful. it probably solves the bigger "half" of the issue and then there's the rest.

by the way, it shouldn't be "include math.h" anyway. it should be: include math

the .h should be implied. what if there are other library files that don't end in .h? i don't see that being an issue, but the solution is to just make sure there aren't two math-dot-something files in the same folder.

Posted on Sep 22, 2014, 12:16 PM

Respond to this message   

Return to Index


Re: i appreciate what you're saying

by SMcNeill (no login)

at the very least, they should be named in a way that groups them. definitely NOT graphics.opengl.ellipse.rotate, but maybe all gl commands should start with _gl.

*********************

I don't have a clue how we could group them any better than they already are being grouped.

Head over to the wiki and look for yourself. http://www.qb64.net/wiki/index.php/Keyword_Reference_-_Alphabetical

The QB45 keywords contain NO underscore. PRINT, INPUT, OPEN, CLOSE.

The QB64 extended keyword set all start with an underscore. _PRINTSTRING, _KEYHIT, _LOADIMAGE, _CLOSEIMAGE

And all the gl words begin with a _gl: _glBegin, _glEnd, _glClearColor (And YES, their syntax is case sensitive and not all upper case like everything else.)


Memory commands start with _MEM: _MEM, _MEMNEW, _MEMFREE, _MEMPUT, _MEMGET.....

Font commands start with --- anything but font usually.... (Don't blame me, I didn't name them.) _LOADFONT, _FREEFONT.... :P

But generally speaking, things ARE fairly well named and organized now. Console stuff starts with _CONSOLE, screen stuff with _SCREEN... The names are made to help group them together; they aren't just all a random combination of letters and numbers. ;)

Posted on Sep 22, 2014, 12:38 PM

Respond to this message   

Return to Index


a QB64 null problem?

by Michael Calkins (Login MCalkins)
Moderator

Okay, I've glanced at some of the posts here, but I don't really feel like reading through a bunch of argument, and I'm not really sure where this issue came from.

Could someone summarize what this problem is, please? As far as I knew, QB64 worked fine with embedded nulls. I don't remember if they work for _DEST _CONSOLE, but I think they should work otherwise.

I don't remember. Was this never fixed?
http://www.qb64.net/forum/index.php?topic=4671
I don't have QB64 installed right now, so I'm not going to test.

I saw a mention of _NSTRCMP or something like that. (strncmp is a C standard library function.) Since it's relatively easy and straightforward to access the C standard library using DECLARE LIBRARY, is there a need to arbitrarily add QB64 keywords for the functions?

Regards,
Michael

Posted on Sep 22, 2014, 1:57 AM

Respond to this message   

Return to Index


Re: a QB64 null problem?

by SMcNeill (Login SMcNeill)
R

QB64 has an underlying issue with CHR$(0) and its string comparison routines.

PRINT "dog" < "dog" + CHR$(0) will print 0, when it should print -1.

Other combinations of words and chr$(0) will throw of fthe rest of the string compare commands. No worries though; a patch has been worked up and is being tested now. wink.gif

*****************************

_strncmp is a windows only command, and stops at the first chr$(0) it encounters.

_strncmp("d"+chr$(0) +"a", "d" + chr$(0) + "z") will evaluate to 0, which is equal. (And wrong.)

memicmp works much better for the purpose, but it's windows only also.....

So it's actually a good bit of work to make a cross-platform non-case comparison routine that carries the speed of strncmp/memicmp, and yet still processes past the null terminator......

One could write a .h file, DECLARE it, and then make use of it, but that's not really BASIC. BASIC is all about typing a single command and getting a reliable result. _STRCMP brings all the cross platform and CHR$(0) handling stuff together, packages it under the hood out of the way, saves a BAS programmer from having to jump through hoops and makes them a single command that performs oodles faster than anything existing in the language already for this purpose.

Posted on Sep 22, 2014, 3:30 AM

Respond to this message   

Return to Index


*okay. thanks for the reply.

by Michael Calkins (Login MCalkins)
Moderator

Posted on Sep 22, 2014, 4:43 AM

Respond to this message   

Return to Index


i'm trying hard

by STxAxTIC (no login)

... to look past Steve's dismissal of Michael's rehashing of my original suggestion, but it's difficult for me to follow Steve this morning.

This resurrects rhetorical questions (that were obviously never properly answered):

1) How is it *not* BASIC to INCLUDE a file at the top of your program? You have been able to $INCLUDE a "header" *.BI file since the early days. The inclusion of a *.h file is ABSOLUTELY in the spirit of Basic. You keep spelling out the "difficulty" of this Steve, but where precisely is the added confusion in doing things this way?

2) Assuming the premise of question 1, how is it *yes* BASIC to go adding non-BASIC keywords? This is a complete oxymoron.

I'm all for Steve's playing around with these things, and for that matter, I don't care WHO plays with Qb64... as I was never married to QB64 and never will be, HOWEVER, I do strongly encourage a unified philosophy on the tinkerer's part.

Posted on Sep 22, 2014, 5:19 AM

Respond to this message   

Return to Index


* but please don't bother responding - this is a big circle now

by STxAxTIC (no login)

Posted on Sep 22, 2014, 5:26 AM

Respond to this message   

Return to Index


Sorry, I got to respond. ;)

by SMcNeill (no login)

"1) How is it *not* BASIC to INCLUDE a file at the top of your program? You have been able to $INCLUDE a "header" *.BI file since the early days. The inclusion of a *.h file is ABSOLUTELY in the spirit of Basic. You keep spelling out the "difficulty" of this Steve, but where precisely is the added confusion in doing things this way?"


*********************

The difference in a nutshell?

.BI files are written all in BASIC.
.h files are C/C++.

You don't $INCLUDE: .h files. Those you have to DECLARE LIBRARY for, and it's not that simple to pass qbs (qb64 string) structures off to native C handling routines. Weren't you having issues with the same thing with your math library conversion??

Someone who codes in BASIC can easily figure out: Type this command, get this result. x = _STRCMP(s1$,s2$) <-- how is this not a BASIC type command? Compare it to x = ASC(s1$,p1)...

But to tell someone who only understands BASIC: "Well, here's what you do... First, you write up a C/C++ command, and don't forget to get the OS specific commands so your code can be used cross-platform. Then you make it into a .h file. Then you include that as a DECLARE LIBRARY statement. Then try it out and see if you can pass off the qbs to your routine and have it work. If not, you may want to pass off a pointer to the qbs structure, decipher it, use it to get the information you want from memory and store it in a temp memblock which you can then access and use in your .h C code.... OH! And be careful of memory leaks with DECLARE LIBRARY and .h! There's been reports of those, and no one knows a good way to address the issue yet."


Which of those 2 scenarios sound more BASIC to you.

Type a one word command to get a result.

OR

To do the same thing, learn the whole C language, how to interact with it and debug it, and then declare the C code in your BAS program with the DECLARE LIBRARY command.....

Posted on Sep 22, 2014, 5:58 AM

Respond to this message   

Return to Index


(as long ias it wasnt a bother, im not worth the time)

by STxAxTIC (no login)

So you see no mechanism to "hide" some of the nitty-gritty associated with $/#INCLUDing a header/library and reduce it to a single "include" statement? Despite the C++ machinery running under QB64? Surely some kind of sub-program embedded in QB64 that handles all of that junk (provided you and Luke get the malloc()/string headache figured out).

I really don't want to keep arguing about this, and I swear I'm trying to stop, but I need to point out that there are two different layers being discussed here, and you mix them freely and create many straw men and knock them over.

We are suggesting that a mechanism be worked that lets the programmer optionally include (loosely) anything that wasn't there in QB45.

The "policy" part we are suggesting, is that rather than going in and deleting the code we don't like, or otherwise having an "opt-out-only" paradigm... we are arguing and an opt-in paradigm where you specify the non-QB45 baggage you want in your program.

How the developers connect "mechanism" and "policy", which are separate layers, is up to them,

The way you attempt to dismiss, or argue against this point, is to say, paraphrasingly, "we don't have a good policy for that, hence the DECLARE LIBRARY stuff, therefore the whole mechanism is no good". I don't want to make this worse and say you are using a straw man argument, but that's what it looks like.

Posted on Sep 22, 2014, 9:56 AM

Respond to this message   

Return to Index


An include is not needed

by Luke (Login flukiluke)
R

What you want is actually already implemented, it just doesn't require you to explicitly state what modules you want. If you don't use any sound commands, you won't have the sound module compiled into your program. If you do you a sound command, this sets a flag during compilation, and the relevant module will be included. No need to '$include:sound, it's just done automatically.

Anyway, a header file just contains the function declarations. You don't want to be able to include headers, you want to be able to include libraries, which, as I've mentioned, is already done automagically.

Posted on Sep 22, 2014, 7:02 PM

Respond to this message   

Return to Index


*good point, i'm coming around on that issue

by STxAxTIC (no login)

Posted on Sep 23, 2014, 5:16 AM

Respond to this message   

Return to Index


now that it's being fixed (it is, isn't it?) - to anyone that may care about it

by 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.

Posted on Sep 21, 2014, 7:19 AM

Respond to this message   

Return to Index


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.

Pete

Posted on Sep 21, 2014, 8:45 AM

Respond to this message   

Return to Index


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. ;)

Posted on Sep 21, 2014, 8:50 AM

Respond to this message   

Return to Index


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.

Pete



Posted on Sep 21, 2014, 9:40 AM

Respond to this message   

Return to Index


Too many new things to learn

by 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.

Posted on Sep 21, 2014, 1:29 PM

Respond to this message   

Return to Index


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.

_Pete

Posted on Sep 21, 2014, 1:56 PM

Respond to this message   

Return to Index


Re: And just wait for the battle of the underscores, it's coming.

by SMcNeill (Login SMcNeill)
R

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.

Posted on Sep 21, 2014, 2:08 PM

Respond to this message   

Return to Index


who knows anything about SDL2

by 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.

Posted on Sep 21, 2014, 6:47 PM

Respond to this message   

Return to Index


I know something about SDL2

by 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?

Pete

Posted on Sep 21, 2014, 7:03 PM

Respond to this message   

Return to Index


sdl was an ideal choice, i liked it from day one (actually,before most here knew about it)

by mn (no login)

sdl is what dosbox uses. dosbox in turn, is the most reliable environment for running actual qbasic after running it natively in dos. there's dosemu and freedos in qemu, i've used all of them.

anyone that can run dosbox reliably should be able to rely on the sdl version, which makes it ideal. but i'm not against the gl version in theory, in practice i'm not impressed yet and i'm not alone, and it's been a year. that doesn't sound great... by the time people figure out gl isn't the way to go, we'll be stuck with it. i see this as the least of qb64's problems. it should be fixable (even if they keep gl,) but that doesn't mean it will be fixed.

Posted on Sep 22, 2014, 11:47 AM

Respond to this message   

Return to Index


here you go pete, in two words

by mn (no login)

fork qb64.

Posted on Sep 22, 2014, 3:37 PM

Respond to this message   

Return to Index


And the horse, that as of last year, rode over it.

by Pete (no login)

At least it is now a more "stable" language, but then that goes with the nature of the beast. DirectX support is a nice feature for those who wish to put programs on an XBox, instead of a PC. Does anyone even discuss QB64 on MacOS anymore? I know Galleon has a Mac, so by your math standards,that would mean countless people are using it, but then I never favored the time taken on x-platform development in the earlier years.

By the way, the prime directive of the project was to make the first 100% QuickBASIC compatible compiler. It came close. Now such a feat seems like a joke, strip out all the underscore statements? That accomplishment was no joke. Fixing what few bugs are left in the SDL version and calling it a finished product is no joke either, but smart business practices are totally lost on that project. It's a good thing the mascot has wings, because the project doesn't have legs, and probably never will at this rate. GL was a Titanic mistake and with you near the helm one can only hope that somebody baby-proofed the icebergs.

Oops, now look what you made me do. I broke my 2-word rule.

Oh well.

Pete

Posted on Sep 23, 2014, 7:47 AM

Respond to this message   

Return to Index


Re: now that it's being fixed (it is, isn't it?) - to anyone that may care about it

by 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.

OR...

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. ;)

Posted on Sep 21, 2014, 8:45 AM

Respond to this message   

Return to Index


don't be afraid to name me personally, Steve

by 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?

Posted on Sep 21, 2014, 9:10 AM

Respond to this message   

Return to Index


Re: don't be afraid to name me personally, Steve

by 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!!

BUT......

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??

Posted on Sep 21, 2014, 10:20 AM

Respond to this message   

Return to Index


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.)

Posted on Sep 21, 2014, 11:20 AM

Respond to this message   

Return to Index


Back to BASICs

by 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.

Pete





Posted on Sep 21, 2014, 12:56 PM

Respond to this message   

Return to Index


Re: Back to BASICs

by SMcNeill (Login SMcNeill)
R

"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....


OR


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

Posted on Sep 21, 2014, 1:49 PM

Respond to this message   

Return to Index


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.

Pete



Posted on Sep 21, 2014, 2:38 PM

Respond to this message   

Return to Index


Re: The problem is the disagreements...

by SMcNeill (Login SMcNeill)
R

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

Posted on Sep 21, 2014, 3:44 PM

Respond to this message   

Return to Index


then it's settled

by STxAxTIC (no login)

Steve,

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)

Posted on Sep 21, 2014, 6:34 PM

Respond to this message   

Return to Index


Re: then it's settled

by 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.

Pete

Posted on Sep 21, 2014, 7:25 PM

Respond to this message   

Return to Index


not that I speak for Steve, but

by STxAxTIC (no login)

... he proclaims himself more of a tinkerer, not a full-fledged developer, especially because the project sits on top of C++. On that note though, he does have a good support network, and by "network" I mean the shallow-mooded permanent resident in the #qb64 IRC room. This mystery figure's level if involvement is still unclear to me, but he's nonetheless a good person for Steve to have around.

Let's agree the project is moving sideways, not forward. Don't you think it's best to have your code running (and tested) in as many compilers as possible? It's worth sticking with GL for that reason alone, let alone all the others.

BTW, what kind of stuff DO you do? All screen 0 nowadays? Got a website?

Posted on Sep 21, 2014, 7:49 PM

Respond to this message   

Return to Index


Steve fiddles while Australia burns.

by Pete (no login)

But it's funny how people over there are getting the perception Steve is driving development. That just shows what a load of trouble the project is in. Galleon should have wrapped up a finished SDL version, before starting this GL mess. He doesn't even have the time currently to address bug reports adequately, or so I've heard. He used to get those fixed back in the SDL days, in a fairly timely manner.

You probably read my post about "buffering" an numerous allegations the project is going sideways, already, so yes, we certainly have common ground to agree on there.

I do have a website, and you're on it. Actually I have other non-programming sites, too. I mostly program in screen 0, business applications and programs that help me get things done. I'm involved in several other hobbies and sports (mostly coaching these days) and I enjoy long walks on the beach... oops, I'd better stop right there, or the programmer formerly known as mennonite might start getting overly interested.

Pete



Posted on Sep 21, 2014, 8:14 PM

Respond to this message   

Return to Index


Re: Steve fiddles while Australia burns.

by SMcNeill (Login SMcNeill)
R

But it's funny how people over there are getting the perception Steve is driving development. That just shows what a load of trouble the project is in. Galleon should have wrapped up a finished SDL version, before starting this GL mess. He doesn't even have the time currently to address bug reports adequately, or so I've heard. He used to get those fixed back in the SDL days, in a fairly timely manner.

*********************************************

I don't think anyone "over there" thinks I'm driving development. I have posted a lot of updates to things, but those are mainly trying to restore SDL functionality (_SCREENMOVE, _SCREENX, _SCREENY, _PRINTWIDTH, alt-num support....), or address existing bugs that I can hunt down and fix. If I'm driving, it's just in a circle around the farm....

I tell everyone that I don't consider myself a developer. It's Galleon's project, and he's going to expand and grow it in the direction he chooses. All I'm trying to do is take some of the burden off him so he can move on with his own work when he has time. I try to actually give something to the project rather than just sit and complain over choices made and roads already left behind.

My C skills are lacking, but improving all the time. When I first found QB64 a few years ago, the source was a complete mystery to me. It was hard to decipher ANYTHING, or to sort much of anything out. But I'm not the type of person to let things stay that way. Instead of saying, "It's impossible, FUBAR!!", I started dabbling with one little thing at a time. With enough dabbling and tinkering, I now know QB64.bas pretty well. If there's a glitch in there, I can usually find it with just a little digging...

BUT, my C is subpar and libqb.cpp is now to me, much like QB64.bas was when I first saw it; a hard to decipher mystery. BUT, once again, I'm not one who gives up and remains ignorant. Each day I take a look at something new in the source there. I study up on what I fail to comprehend, and I learn as I go. I'm now getting to where I comprehend and understand enough to not just make corrections inside QB64.bas, but now I'm starting to make bug-fixes in libqb.cpp. Give me a few years, and I'll be as confident with working in the C side of QB64 as I am the BAS side. While I live, I grow and learn. wink.gif

Maybe in another year's time I'll know enough that folks could rightfully call me a developer, but for now I'm just a tinkerer whose learning as he goes. And a LOT of people have helped me as I've been learning. Luke, Walter, Michael, Matt, Rob, and countless others on the forums and in chatting... And these nice folks enjoy helping others as well!

Instead of complaining that things aren't going the way you want, join us and help shape it to what you need. Bitching does nothing to move things forward, but who knows what a little help could accomplish....

After all, I might not "develop" QB64, but after a year or so of tinkering I CAN now compile and run programs in 64-bit. We've now got QB64 x64 to the point where all you have to do is swap out one compiler for the other and rebuild the libraries and you're good to go. It's something I've been wanting for ages, but I didn't just whine about it not being developed -- I kept poking around with it until I could get it working...

Not a bad feat for a poor ole farmer who doesn't know everything about C yet and just tinkers on the sideways fringe of development, eh? :D

Posted on Sep 21, 2014, 8:58 PM

Respond to this message   

Return to Index


Countless others? I thought Clippy wasthe one deficient in math skills.

by Pete (no login)

A hand full is not what I would consider countless. I know farming is hard work, but cut back on the Kool-Aid. Give it a couple of years? I just gave it a couple of years. That reminds me of the FreeBASIC motto. If you don't like us know, just wait and see what you won't like about us next year!

QB64 had a good run, and had a good version. That time has past, and it is time to move on. Personally I could waste my time on learning C, and be ever so frustrated working on what has become such an ill-defined project, or spend my time on something I'm already very good at already. People who are already good at things benefit the world a whole lot more than students, who are in the process of benefiting themselves through learning new things, but I would recommend if you intend to stick with the project, that you also consider swimming lessons.

Pete

Posted on Sep 22, 2014, 1:02 AM

Respond to this message   

Return to Index


ah, well thanks for owning this site

by STxAxTIC (no login)

There are too many "Pete"s in the QB business...

Thanks for hosting/owning this cool site, its a time-tested beacon for QB... stuff...

I'm (these days, at least) realizing that all the cool programs in the world can effectively be powered by something that either runs invisibly, or in screen 0 (using text stream output). I have prepared my latest work (bignum calculator / math language) to transcend QB and pass into C++, but admittedly, the completely detached graphics layer(s) will remain QB64 code. One day I will get around to using SDL graphics in C++ on my own (which I already did once for points and lines), then that particular project will be free of QB entirely.

Why am I destined to separate my baby from QB? Speed. I have taken to translating into "Sxript" the simple graphics demos that come in our "samples" folder with every QB64 installation. Sierpinski triangle, check. Fractal fern, check. Mandelbrot set... check, but slow as dogsh*t. It's taking all night to generate the image. This is what I get for designing high-level constructs in an already high-level language...





Posted on Sep 21, 2014, 9:05 PM

Respond to this message   

Return to Index


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.

Pete

Posted on Sep 21, 2014, 6:59 PM

Respond to this message   

Return to Index

 Copyright © 1999-2014 Network54. All rights reserved.   Terms of Use   Privacy Statement