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



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


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


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


for posterity

by mn (no login)

i can understand if someone thinks this is somehow underhanded. (it's not.) i just think it's one of the most relevant things ever said about BASIC, and one of the most relevant things that will ever be said about qb64.

certainly if the author requests it be deleted i will not take issue with the mods doing so. i ask them to consider leaving it here until the day that happens. i am not trying to take it out of context and i don't feel like discussing it. but i am sure going to post it, and also this is a one time thing. the following is unedited (i can't help with the emoticons.)


Quote from: STxAxTIC on September 19, 2014, 08:45:28 pm
Backlash warning over at N54. Read all about it.

Bump: Bloatware?

Some people just like to rant. It's all good. :)

We've already had the discussion over "Bloatware". Galleon made his decision quite public on the "bloating" of the language. http://www.qb64.net/forum/index.php?topic=11920.0

Quote
Everybody has a different opinion about what QB64 can/should be. But unless we make it what the individuals in our community want it to be then we all lose. So even if we personally don't want/need things like...
.
.
- A suite of string commands
.
.
.
...someone does.

My new philosophy is to let QB64 be what the community want it to be. Even if we end up with 1000s of commands that barely get used by the majority, it is better than QB64 not being used at all.

The decision was made, and I'm not going to let talk about "bloatware" concern me one bit anymore. This is something that I *can use* and *will use*. If no one else needs it, that's OK... I just find it hard to believe that I'm the only person out there who would like a fast, efficient way to compare strings ALPHABETICALLY and not by ASCII code.

Alphabetically "DOG" is the same as "dog". In ASCII, they're not.

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

As for not liking the name (which was a nice long post or two on the other forums), that's why I put it up for suggestions. Don't like it, fine. Just don't tell me how bad my naming sense is; show us how much better yours is. ;)

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

And the fact that you have to be careful with CHR$(0) with it?

This really doesn't seem like a big deal to me. If your strings have CHR$(0) in them, doing a non-case comparison of them probably isn't the best idea. Chances are you're dealing with something more complex than simple alphabetical comparison between strings, such as a binary data file, which I think you'd probably want a custom routine for.

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

It's another case of "don't like it, don't use it." No one is going to force anyone to start adding the command into their code. Heck, look at the whole list of _gl... keywords out there. How many pieces of code have you seen with any of them in it??

I feel like it's better to have it here for the people who might need it and make use of it, than it is to not have it just because someone else doesn't need such a feature.

Hey, maybe I could call it _QB64BLOATWARE_ADDITON_NUMBER_00000001! :D ;D

Posted on Sep 20, 2014, 12:53 AM

Respond to this message   

Return to Index


alternative QB45-compatible compilers

by STxAxTIC (no login)

In order of their date of projected deaths, whether it has occurred yet or not, the QB45-compatible systems on which I have relied are:

FreeBASIC #lang "qb"
QB64GL
QB64SDL
QB45 stuck in DosBox
QB45 in Win XP and below

Something that myself and others want to know:

What are the other QB45-compatible compilers out there? I've heard of DarkBasic and BlitzBasic, but haven't tried them. Are these fully compatible?

Posted on Sep 19, 2014, 11:05 PM

Respond to this message   

Return to Index


i think it would be shabby not to reply at all

by mn (no login)

but i don't have much to say about this. if pete stops giggling (or guffawing, he seems like more of a guffawer to me) i'm totally serious.

you're absolutely right about the "around the edges" business, and i'm so sorry. the worst part is, they're not even smooth edges. it's vandalism over restoration, and that's where i get off. since i don't use microsoftware anymore, and there's nothing else to follow/reply about regarding this other issue, i think it will be the other subforums from now on. at least until everyone's tired of hearing about... well, wrong subforum for that. take care.

Posted on Sep 20, 2014, 12:30 AM

Respond to this message   

Return to Index


Re: alternative QB45-compatible compilers

by Pete (no login)

DarkBASIC was made for primarily for gaming. It is not that QBASIC compatible, from my limited exposure to it. People who use it seem to speak highly of it. I've never heard of BlitzBasic. It sounds like some Third Reich software that could easily be used to take over France, but then so could FORTRAN if you threatened to throw the cards at them.

PowerBASIC has a DOS version that is very compatible to QBasic.

Pete

PS If you see Myst, tell him I'm sorry, and I accept his surrender. :)

Posted on Sep 20, 2014, 9:26 PM

Respond to this message   

Return to Index


A whole swarm of them at:

by SMcNeill (no login)

http://www.thefreecountry.com/compilers/basic.shtml

Give those a try and see if any of them work for your needs.

Posted on Sep 21, 2014, 5:01 AM

Respond to this message   

Return to Index


thanks for your responses

by STxAxTIC (no login)

I've been spying on that BASIC compilers list over at freecountry for a while now. I've even tried a few of them. Conclusion: everything sucks except QB64 and FreeBASIC.

I get the sense that people praise things like DarkBasic because *it* does most of the work FOR them. I've never heard anyone praise these high-level general-purpose languages who can properly define the word "vector", or has heard of the "cross product". (If tricking people into thinking you're an awesome 3D game programmer is your style, then sure... but I'm not talking about FluffRabbit here.)

Looking again at that list, it seems that every person or dev team that accomplishes QB45 compatibility with their C-family project INEVITABLY jumps the shark by (i) adding too much junk and cornering the "basic" part into some slow-moving side caboose of the language, or (ii) breaking QB45 compatibility by adding "new features".

We can swear up and down that QB64 will never minimalize the original BASIC component, or even break compatibility, but who knows - five years from now, once the dev team has turned over once or twice, or even 15 years from now... someone will be clever enough to trick the rest of the community into jumping the shark. Then it's over.

It's therefore our job to tighten the bolts on this titanic, not build the deck higher.

In case I get accused of being abstract, I am NOT dissing Steve's contributions in any veiled way. It's just that seeing the list of dead projects over at freecountry sent a shiver down my spine.

Posted on Sep 21, 2014, 6:33 AM

Respond to this message   

Return to Index


for those of you coming over (hattip to STxAxTIC)

by mn64? (no login)

i don't care (that much) if people want to make functions with stupid names. i advise against it, already explained it. i wrote three (or is it "Three?" need a function...) posts about it.

not my beef. yes, i wrote a criticial post. i also tried really hard to be reasonable and (mostly) friendly.

this nul business is another matter entirely. it's exactly the kind of problem i NEVER thought i'd see here.

and pete and i have had our differences, but he REALLY shouldn't be bored with the project (because you guys should make it cooler than that.) not a good sign. doesn't matter, once qb64 breaks qb-like string handling, i'm using/endorsing old versions or forks exclusively. does it matter? nah. it's been a year since i've coded anything in basic. but it's still good for teaching.

i'm not in this one for the long haul. qb64 was qb like UNTIL just that point. there's still time to repent. the end seems nigh, though. sorry pete. i feel your pain, and (it looks like) you feel mine. see you on the other languages forums, perhaps.

Posted on Sep 19, 2014, 8:56 PM

Respond to this message   

Return to Index


NUL NUL NUL, that's not how you do it!

by don't make me compare it to another dialect (no login)








"I'm not certain one would call it a bug; it's more just a nuance of the command. ;)

CHR$(0) is just that null-string terminator. If those are part of the strings you're comparing, you'll probably need a different method for 100% certainty of results. "

NO.

stop right there.

there was another dialect that got this wrong, and i think they even fixed it

BASIC IS NOT C.

basic did not have nul-terminated strings!

basic had cobol strings, where it tracked the length, not giving up on NUL.

i proved this to the devs of another language and they said they already knew. it was pure laziness because c drops a string at the nul. well, open up qbasic and see.

this function is already redundant and unnecessary. if qb64 can't even handle strings with nuls, PACK IT UP and close shop.

not joking. if qb64 can't handle nuls in strings like any other character, you might as well quit right there.

(and i'll join you.)

i wasn't going to issue any ultimatims (because who cares?) but if this goes wrong, i'm just done. i don't even code in basic anymore, a quarter of a century is enough time to focus on one language.

>>> q = "hey" + chr(0) + "there"
>>> b = "hey" + chr(0) + "are we good?"
>>> print q < b
False
>>> print q > b
True

now THAT'S what qbasic would do (except it says -1 instead of true and 0 instead of false)

your function is already (barely) a shortcut for code that works properly in qbasic.

your function (that saves typing how many characters? 3?) doesn't even work as well as the qbasic compatible code it's a shortcut for.

""I'm not certain one would call it a bug; it's more just a nuance of the command. ;)"

if that's a joke, i apologize. really.

if it's not a joke, fix it or resign. qb64 doesn't need that kind of "i'm gonna break it because this is how c++ works" attitude. go work for the other guys if that's how you really feel, they pull that all the time.

that's all i have to say about it. (try me.)

Posted on Sep 19, 2014, 8:23 PM

Respond to this message   

Return to Index


steve, this is how NOT to name a qb64 command

by mn64 (no login)

PRINT _NCSTRCMP("Dog","dog") ----> This would print 0 (Dog is dog)

okay, i know, even before qbasic (i predate dos 5) there were exceptions to the rule: VARPTR$ sounds like something you would catch on a cruise ship. (for the moment, antibiotics still help in most cases.)

but NCSTRCMP? please don't expose c++esque names to BASIC when you can help it. they're absolutely FINE names for c++ users. BASIC is supposed to literal when possible. MID$ isn't english, but it is the first three letters of an english word. it's not STRMDL$ after all.

oh you can say it won't matter this time, until your entire language is like vomiting alphabet soup. but if you're going to keep naming builtins like this, please include a bucket.

now i know you're practically in charge of development these days, so i'm really not intending this to rude so much as colorful. (technicolor yawn colorful, but i think that's fair right now.) it's not that i don't respect the work that you put in. it's just that it's a hideous terrible name, and making a habit of that will contribute to wrecking one of the best computer language dialects of all time. please take some care. and let's not debate this too much. you hear me, and that's good- or you don't, which would be too bad.

Posted on Sep 19, 2014, 7:00 PM

Respond to this message   

Return to Index


*AROSE$ by any other name would be BASIC? BUT, could thou any longer tell by reading it?

by william shakespeare gates iii (no login)

Posted on Sep 19, 2014, 7:33 PM

Respond to this message   

Return to Index


and now for the constructive version

by mn64 (no login)

i really think the criticism in this case is more important than the suggestion. but there's still an opportunity here. obviously you have this construct, which i'm in favor of:

if x$ = y$ then print "match"

and for case insensitive checking, this still works:

if lcase$(x$) = lcase$(y$) then print "match"

but for some that's too messy, (but it's still pretty obvious what it does,) then you have this illegible thing:
if _NSTRCMP(x$, y$)

which is harder to read, redundant, and trades in compatible qbasic code for what? it barely saves typing...

but IF we're going to add a superfluous statement that's only a shortcut, at least let's make it a good one. i propose:

if match(x, y) then print "match" ' yeah you don't need this, it's same as if x = y then 'etc

if match$(x$, y$) then print "match" ' yeah you don't need this either. let's see steve's function:

if imatch$(x$, y$) ' i is a common way of saying "case-insensitive," but i welcome any obvious letter

or just call it match$ because the other forms of it (case sensitive, numeric) really are redundant and simply throwing away compatible code for qb64-only code, just to do so.

HERE'S A FUNCTION I WISH EXISTED

if _HOWBASICLIKE("_match$()") > _HOWBASICLIKE("_nstrcmp$()") then print "if the name fits, you must fix it!"

i do question how necessary this function is (shortcuts are not worthless, but they should be weighed against using compatible code. in other words, to be incompatible they should be really GOOD shortcuts, or not be added) but let's assume it must be added. i think the decision has been made. let's hope there is time to change the name (you know, before it's 6 months old and breaking existing programs.)

this one's for you pete. now i'll sit back and wait for jokes about "my ascii and your face," etc.-- don't let me down, pete. this forum is so tame, i think it might have been shot with a dart (and steve's to blame... don't give a function, A BAD NAME!)

woah, woah, woah. (i can't stand bon jovi, so i'm literally torturing myself to try to make a point here.)

cheers, steve.

Posted on Sep 19, 2014, 8:02 PM

Respond to this message   

Return to Index


How about _STRBEANS? That way, Steve can compare produce.

by Pete (no login)

BASIC is also about building comparison routines yourself. One of the many reasons I lost interest in the project itself, besides the growing number of dullards at the forum.

Pete

Posted on Sep 19, 2014, 8:45 PM

Respond to this message   

Return to Index


Re: steve, this is how NOT to name a qb64 command

by SMcNeill (no login)

Which is why I threw it out there as a suggestion before making any pushes into the code. ;)

It's easy to say it's bad naming, but honestly any name will work. I'm more than content to go with whatever people like. I'm glad you don't mind telling me how poor it is, but why not suggest what you consider a viable alternative as well?

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

CHR$(0) is just that null-string terminator. If those are part of the strings you're comparing, you'll probably need a different method for 100% certainty of results. "

NO.

stop right there.


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

Not every command is suitable for every task. It's up to the programmer to pick and choose what suits their needs the most. Why else would we open files for INPUT, RANDOM, and BINARY all, when one could use BINARY to just do it all??

I'm certain we could check the string for CHR$(0), see if it's present, and then create a custom comparison routine checking byte vs byte and giving a result -- but by the time we did all that we'd be giving up a lot of the speed which we'd normally be looking for. It BASIC, it's all but impossible to generate a null terminated string, unless someone manually tacks that CHR$(0) on there. INPUT doesn't give us CHR$(0) line endings, neither does DATA, nor LINE INPUT #, INPUT #, INKEY$, or _KEYHIT.

For BASIC, how exactly would someone get CHR$(0) into a string to begin with?? None of your normal input or print routines work with it. The only way we get it is if we GET information from a BINARY file and it's in there, or if we place it in the string manually and on purpose.

If it's a binary file, we really don't need to be doing a non-case string comparison of things. Byte 65 probably shouldn't be counted the same as byte 94 ("A" vs "a") in a binary file. It's not really a suitable command for comparing those values; we'd be better off checking _UNSIGNED _BYTE vs _UNSIGNED _BYTE.

IF someone is putting CHR$(0) into their strings manually, those aren't standard BASIC strings; is there any reason to think that our commands must support custom syntax checking for them??

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

>>> q = "hey" + chr(0) + "there"
>>> b = "hey" + chr(0) + "are we good?"
>>> print q < b
False
>>> print q > b
True

now THAT'S what qbasic would do (except it says -1 instead of true and 0 instead of false)

your function is already (barely) a shortcut for code that works properly in qbasic.

your function (that saves typing how many characters? 3?) doesn't even work as well as the qbasic compatible code it's a shortcut for.

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

Except it's something completely different than the existing QBASIC code.

>>> print "dog" = "DOG"
0

_NCSTRCMP (name pending) is a non-case string comparison routine. "dog" is in fact graded equal to "Dog"...

The use?? So we can sort all our words of a list into alphabetical order, efficiently.

ace
Apple
cat
Charles
Clippy


If we were to try to sort that using the basic < or > comparison results in QBASIC, we'd get all the Capitalized letters and then all the lowercase letters. We're not really sorting alphabetically in QBASIC, we sort by ASCII-code...

_NCSTRCMP gives us the alphabetical sorting of words and numbers, and it should work on the majority of QB64 text and strings. If you need to compare things like your example above, you'll need to write up your own compare routine. UCASE$(q) < UCASE$(b) would work for you -- but it'd be slower. A *LOT* slower, which could affect performance if you're comparing a whole swarm of strings at once, such as for sort routines.

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

QBASIC has a nice INPUT # routine which we can use to read text files. It doesn't work well with every ASCII character out there. quotes, commas, chr$(13), chr$(10), chr$(0) -- NONE of these work well with INPUT # or LINE INPUT#. In QB45, it'll even strip off extra spaces from the beginning or end of a line for you from what I remember....

It's part of the nuance of the command. It does what it does. If it's not suitable for what you need, then use a different method.

It's the same with the _NCSTRCMP. If you can use it, then do so. If not, then don't. There's nothing forcing anyone to try and use the command, and it's not going to replace the old standard <,>,= routines which we've always had. They'll still be there, same as always.

The difference is we'll now also have another tool at our disposal which works quite efficiently when we need it to. It may not be the hammer used to drive all nails, or the axe used to split all trees, but a hatchet can still be a useful tool to have in the right situations. ;)

Posted on Sep 19, 2014, 10:19 PM

Respond to this message   

Return to Index


this is a reasonable and thoughtful response, which is > i deserve, but there's 1 thing...

by mn64v0954 (no login)

it's also wrong.

this is the "agree to disagree" stage. who knew we'd get there so quickly? good luck steve, it's still better than the other leading compiler. heck, it's the best basic compiler ever (i'm not even being sarcastic.) but we just reached my stop.

Posted on Sep 20, 2014, 12:12 AM

Respond to this message   

Return to Index


Re: this is a reasonable and thoughtful response, which is > i deserve, but there's 1 thing...

by SMcNeill (no login)

It's never hard to "agree to disagree". That's what people do when they're confident in their opinion and someone else's varies from that opinion. ;)

I don't think every tool has to work for every job. By making something that's more versatile, it's often slower or bulkier than a tool made specifically for one job. Compare the Swiss army knife (http://theawesomer.com/wenger-giant-swiss-army-knife/65362/ ) to a pair of finger nail clippers... Sure, those nail clippers only work for a limited purpose, but I bet they're used for that purposes a million times more often than the other is!

Still though, I was going in and playing around to see what a custom routine would take to make and use to check for CHR$(0) properly for us, and guess what I found out?

QB64 has apparently NEVER properly checked for CHR$(0) terminated strings!!

"dog" < "dog" + chr$(0) returns a FALSE(0) to us. Other methods of comparing also can generate these same errors... >, <=.....

Apparently people don't compare strings with CHR$(0) in it enough to even notice and report a bug from the existing process; they're just not used a lot in BASIC. It's a glitch that's been around in the language since day one, and it takes the scrutiny of adding a new command to highlight the flaws in the existing ones. ;)


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

Sometimes though I got to admit I feel like I'm fighting an uphill battle with the language. Go to fix one thing and POOF!!!, first you have to go and fix something else first that no one even noticed was broken...

It's two steps forward and one step back it seems. :P

Posted on Sep 21, 2014, 5:19 AM

Respond to this message   

Return to Index


qb64: a situation where _OS$ might not work the way it is now

by mn64 (no login)

i'm basically agreeing with clippy on something here.

i can see how in most cases, the way _OS$ works now is fine and makes sense.

but the way it works now is (partially) based on a false assumption, and that assumption is this:

a. if it works on the version of [windows/gnulinux/mac?] that it was compiled for,
and:
b. that it's running,
then:
c. therefore, the version it was compiiled on is compatible with the current system it's running on

32 vs 64 bit is no measure of compatibility by itself...

there are certainly other differences among windows versions (95, nt, and vista all have 32 bit versions) that need to be coded around sometimes.

although i'm not offended by the current _OS$ implementation, i do think in the long run a statement that dynamically returns information about the running os is worth much more than one that knows what it was compiled on.

but maybe the reason the statement is so limited is that it just returns version info (which is static information from the compiler.) in that case it's a whole lot more work to make _OS$ work the way clippy and i probably agree it should...

in that case, it's not an unreasonable statement, just a statement that extremely limited. but fwiw, i agree that hindsight being what it is, _ver probably would have been a better name for the function as-it-is.




Posted on Sep 16, 2014, 4:47 PM

Respond to this message   

Return to Index


*don't worry steve, i'm not asking you to break anything years old

by mn64 (no login)

Posted on Sep 17, 2014, 5:15 PM

Respond to this message   

Return to Index


* I didn't think so. You aren't Clippy after all. ;)

by SMcNeill (Login SMcNeill)
R

Posted on Sep 17, 2014, 5:38 PM

Respond to this message   

Return to Index


Re: qb64: a situation where _OS$ might not work the way it is now

by SMcNeill (Login SMcNeill)
R

"a. if it works on the version of [windows/gnulinux/mac?] that it was compiled for,
and:
b. that it's running,
then:
c. therefore, the version it was compiiled on is compatible with the current system it's running on"


The version it was compiled on has to be compatible with the current system it's running on. You can't compile MAC executables and run them on Windows after all. At least not without some emulator which gives you the Mac environment on Windows.

When you go into a store and buy a piece of software, you look on the package for "WINDOWS 32-bit" or "WINDOWS 64-bit" or "Runs on Linux!".... That's basically what _OS$ tells you in QB64; what you'll run on once compiled in the current version of QB64.

It's a shame that _OS$ can't make some sort of magical file that runs across all platforms, but honestly it's more of an #ifdef type statement than anything else. Write code using _OS$ as a toggle for calls between windows or Linux, and once it's compiled it's only ever going to work with one set of conditions; and that depends on what was used to compile it.

_VER may have been a better name, but it's a little late now to suggest changing it, I'd think. _OS$ has been in use for several years, and people are used to seeing it and using it. Who knows how much existing code would need to be altered to run in the future just for semantics sake?

I'm all for discussing and altering commands (even their names if added recently), but to change a name after it's been in use for an extended period of time just because something else sounds better? Honestly, I wouldn't advocate that even if it was called _HORSEDROPPING$. :D

Posted on Sep 17, 2014, 5:37 PM

Respond to this message   

Return to Index


all i was saying is that os$ will probably create false positives

by mn64 (no login)

you might be able to create a program that does actually run on 2k, despite being compiled for vista 32bit, and _os$ will be happy as a clam. this is a false positive as far as _os$ goes, because it's running and it's doing it vista style, but it's running in an environment where some assumptions CANNOT be made.

so i make a program that uses _os$ and it says it's compiled on vista. so how am i supposed to make my program routines win2k compatible if os$ won't even tell me it's win2k?

the thing is that on a binary level, 2k and vista might be compatible, but on a finer level, they might be very far apart. this makes os$ very half-assed for what you would reasonably expect it to do. i will give it that it probably does everything it was designed for.

so it's at least more than just a nitpick that the user/coder might really want to know what o.s. the program is running on, and it's too bad that os$ wont help them there. that's why clippy should have named the routine (_ver$ would have been perfect actually.) then we could make _os$ do what it ideally should.

incidentally, qb64 is built on the idea that breaking existing programs is one of the worst things you can do. you and i agree, and it is definitely too late to take functionality away from _os$ or rename it. if there's some other way this can be improved without breaking existing programs... could _os$ be further overloaded somehow? that's all i have to say about it. i'm more concerned about (hypothetical) non-optional OOP extentions coming in... if they're optional, i don't care unless all future (optional) extentions are OOP style: "yes all old qb64 routines are procedural, but we don't approve of procedural coding..." etc. so long as we're not headed for that dystopia, i'm okay. thanks steve.

Posted on Sep 17, 2014, 7:07 PM

Respond to this message   

Return to Index


Re: all i was saying is that os$ will probably create false positives

by SMcNeill (Login SMcNeill)
R

"i'm more concerned about (hypothetical) non-optional OOP extentions coming in... if they're optional, i don't care unless all future (optional) extentions are OOP style: "yes all old qb64 routines are procedural, but we don't approve of procedural coding..." etc. so long as we're not headed for that dystopia, i'm okay. thanks steve."


I'm certain if OOP is ever added to the language it'll be an optional addition. I don't think anything will ever be required. It's all about adding choices for the user, not taking them away -- like with the x64 version. It's not meant to force people to use x64 and drop x32 support, just give them the choice to decide what works best for themselves. When OOP enters (if ever) the language, I'm certain it'll work the same way.

Add to existing functionality, not destroy/replace it. wink.gif

Posted on Sep 17, 2014, 7:28 PM

Respond to this message   

Return to Index


my (second) favorite language (ever) is 100% OOP

by mn64 (no login)

... fsv of "100%"

no non-basic language is closer to basic than python (although fortran and cobol are obviously cousins.) i once went on a pilgrimage to the campus (and i think, the building / floor) where basic was invented. out of every hobby i've ever had, programming has been the most rewarding. i love logo, but basic (since age 5 a least)) was always cooler.

when i found python, i had given up on waiting for qb64 to live up to its original promises. (note: it did live up to them, and then some, within a year or two.) if they're not teaching basic at m.i.t. and as part of olpc, it's good that they're doing python. remember the classic "qbasic o.s.?" sugar almost is that for python.

everything is an object. everything. note that i don't care for oop concepts at all. they have their strengths, they have their place, and there is a subset of projects they really lend themselves to. but i don't like oop. the great thing about python is that someone who strongly prefers procedural coding can pretty much stick to it. if you're using someone else's code you can generally work around it your own way.

last time i tried qb64 (about a year ago) i didn't put it down until i was satisfied it was in fact, qb. it's basic, it is qb, it earns the name. underneath qb 4.5, everything is asm (more or less,) and underneath my python scripts, everything is oop. but i don't have to worry about oop-- it's there if i want it. if the python guys can create a modern basic-like language accidentally, i know you guys can do it on purpose. it's perfect so far... fsv of perfect, but it's the last really-basic out there (unless you're british, then there are two?) take good care of it. i still want to understand why pete's unhappy.

Posted on Sep 17, 2014, 8:59 PM

Respond to this message   

Return to Index


Re: my (second) favorite language (ever) is 100% OOP

by SMcNeill (Login SMcNeill)
R

Pete can correct me if I'm wrong, but I think:

He's a simple guy with simple needs. SCREEN 0 does all he needs, and SDL was a "finished product" for what he wanted for his own use. Then Galleon decided to split the language over to GL-based; and even now, over a year later, not all the old functionality has been restored.

Sure, there's been improvements in graphics and hardware support, but he doesn't need those. What he could use is Android support, but that was delayed getting GL back to where it is now....

Then discussion about the future direction of QB64 was brought up. Galleon opened up his stance and said, "Hey guys, if you can add it, I won't stop you! GUI, OOP, X64 support.... Knock yourselves out! Just don't break the existing commands...."

And Pete said, "OOP?? What happened to Android??", and he basically got tired of waiting for the language to develop in the direction he wanted.

As it currently stands, I don't think Galleon has ever said his next step was OOP support. He said if someone wanted to add it, he wouldn't stop them... But I don't know of anyone who pushes to the repository who has actually shown any interest or direction in trying to work it in. NO ONE has said, "I'm going to introduce OOP by XX date..." At this point, I really don't see it entering the language anytime soon.

Currently Galleon is working for GWAN support, and then he'll probably go back to hardware acceleration routines for graphics. There's still a lot of bugs in what he's added so far, and a lot more to be added.

The rest of us are working on bug fixes as much as possible, and trying to fill in those last remaining gaps between SDL and GL functionality, with an occasional new command added as we need them personally. (Like I just needed the _CONTROLCHR returned to me for a library routine, so I added in a function to get its state back for us.)

I don't think Pete's really upset over OOP, as it's not really even on the foreseeable horizon of QB64's future ATM. I think he's just upset other things are being developed over the Android support which he could personally make use of. wink.gif

Posted on Sep 17, 2014, 9:43 PM

Respond to this message   

Return to Index


*thanks for this great response. i won't take up more of your time... for now ;)

by mn64 (no login)

cheers

Posted on Sep 17, 2014, 10:05 PM

Respond to this message   

Return to Index


Have you considered...

by Luke (no login)

...that QB64 programs don't run on old versions of Windows? That there is a function to check the Windows version anyway? http://msdn.microsoft.com/en-us/library/windows/desktop/ms724439%28v=vs.85%29.aspx

Posted on Sep 19, 2014, 11:11 PM

Respond to this message   

Return to Index


no to the first one, yes to the second one

by mn64 (no login)

the version thing is a true tempest in a teacup. it's not ideal, it's probably stuck like it is, it doesn't raelly matter unless perfection is a goal. i mean it more than likely does everything it sets out to do and is simple. two out of two.

the past version thing is a fair point, the future version thing is hard to predict. some of clippy's points were valid, i think. there were a lot of points... (i should know...)

if i wanted to look things up on the msdn site, i wouldn't be using basic. kind of a pithy, silly answer but i suppose os$ is a compromise. it could be worse.

and given the rest of what's going on, i forgot about the _os$ command. it's kind of a shame that it doesn't run on all versions of nt at least, but i guess sdl (and gl) had requirements going in that... i always thought sdl was the perfect compromise because that's exactly what dosbox requires to run qbasic anyway. i've never tried running dosbox on early versions of nt, for example.

Posted on Sep 20, 2014, 12:21 AM

Respond to this message   

Return to Index


whogab64... possible dialects of nearly-basic and such

by mn64 (no login)

(it stands for who-gives-a-basic)

i spent a few years getting pissed off that the project to create a free version of basic, didn't.

finally, galleon did it. qb64 really is qb. it's free (either way,) it's not by microsoft, it's compatible, it bends over backwards to run old programs. (out is a nice touch. i remember the plans for out, as far as i can tell they're where they should be.)

now that qb won't die, i wonder what qb would look like if it were MORE basic. in my tutorial i tried to cover only things that were easy to teach and easy to learn. some were things i struggled to learn when i was in kindergarten, for example...

now i see handles for dealing with images. i can't really say that dealing with images has gotten worse, because in qb it was never good. but still, the more features that get added to qb64, the harder (not impossible) it's going to be to maintain as a simple language.

so i think it would be ideal if there were a qb64 derivative that was NOT called qb, didn't necessarily have "basic" in the name, etc. etc. etc. maybe it could claim to be a basic "inspired" language.

i don't need this language, and i'm not requesting it. but i think the idea of a basic-inspired computer language has potential. in fact i think there is room in this century for a COLLECTION of basic-inspired languages.

i wouldn't start from scratch. i would (if i really meant it, which i don't...) take qb64 and actually REMOVE features. (this is exactly why i wouldn't call it "qb" anything. nor "basic.") i like the name "whogab," but i think it would suffice as a working title (you know, the way "linux" was a working title.)

i would remove features that were too unfriendly-- starting with handles-- to make this new "basic-inspired" dialect.

note it isn't the *use* of handles i would get rid of, it's the syntax.

what would i replace qb64 "backwards-compatible" syntax with to make this other dialect? i would replace it with duck typing, a concept from python.

here's a string: "hi."
here's a string: 'hi.'
here's a string: """one
two
three"""
here's a string: "onentwonthree"
here's an integer: 5
here's a float: float(5)
here's an integer: int(5.0)
here's an array: ['one', 'two', 'three']
here's an array element: ['one', 'two', 'three'][2]
here's a function call: import math ; print 4 * math.atan(1)
alternatively, here's a function call: from math import atan ; print 4 * atan(1)

(you only have to import once per program. it's a very smooth interface for external libraries.)

type syntax is messy$ and there are too many types. duck-typing is basic-like in a way that basic itself just isn't.

so that's one feature this hypothetical more-basic dialect would have.

i'm not trying to splinter an existing language. i'm trying to talk about a hypothetical language... to make a point? not even that. i'm just talking about a hypothetical language. it's so hypothetical, i don't even know why i'm talking about it yet.

and no, python is not really the most basic-like language there is. i really think it's somewhere between qb64 and most other basic dialects. you can't make a language more basic just by copying python, but i think python has at least one idea (this one) that could make a language like basic even easier to get started with.

the thing about python is that it's easy to learn, and by the time you think you're almost done with a task, you realize you're done sooner than expected. that's one thing i noticed about basic: you could lose yourself in the fun of it and be done before you expected to be: that "oh, wait-- it's actually ready to run" moment.

but the main thing that makes python more like basic is that they aim it at young children (through pippy, part of the sugar learning environment) and mit is using it for teaching (because it's a great introductory language for all ages) and it's ubiquitous: it's on every macbook, practically every gnu/linux system, and available for windows and dos. basic doesn't have the ubiquity it did in the 80s and 90s, where if you could see a computer it was more likely than not that it had a copy of basic on it, or at least sitting on the install cd. it's used on websites, and for games, it's used in almost every niche java is, (there's no python-os yet) but it's much more inviting.

i don't think whogab or more-basic will ever exist, and i don't mind. but even if most of them didn't make it through the year, i think it would be awesome to see a sudden proliferation of basic-inspired dialects of any language.

failing that, it would be awesome to see a proliferation of interpreted "languages" where the interpreter itself is written in qb64. they might be simple languages, but if you have enough people inventing simple languages of their own, two things happen: more than ever, people are really thinking like programmers. also, you're going to see some neat ideas that way. that would be pretty cool.

if you want a cheap, pathetic excuse for a way to implement duck typing in your own interpreted language and you don't know how to make a good interpreter, try this for typing: handle just strings and integers... for starters. maybe then add an array OR a string that handles n or even chr(10)

but just strings and integers:

1. take your value as a string and convert it, see if it's zero. if it is, convert it to integer 0.
2. any other value, convert to an integer. if it turns to zero or errors, it's a string. else, it's an integer.

so that's poorman's duck typing. it's not what i'm suggesting for whogab, i'd suggest proper-quality duck-typing routines for that. but the great thing about making a toy interpreter for a toy dialect (i have done this once or twice) is that you can have a toy type-manager. it doesn't have to use $ for strings or & for handles. it just has to be light enough on features to be manageable.

just a thought.

btw, "such" would be a great name for a toy computer language, but only if you don't mind its detractors noticing how close the k and h keys are.

Posted on Sep 16, 2014, 2:16 AM

Respond to this message   

Return to Index


A dynamically typed BASIC is an interesting idea

by qbguy (no login)

Since QB64 generates C++ code and C++ is a staticly typed language, modifying QB64 to compile this language instead of QBASIC would require some work since you would need to make a tagged union variant type and then make helper functions on top of the libQB functions that take this variant type; unless you mean a staticly typed language in which variables' types are assigned automatically by first usage?

I implemented an interpter for Scheme (which is dynamically typed):

http://www.qb64.net/forum/index.php?topic=12043.msg104998#msg104998

It only supports symbols, lists, and numbers (which are currently just BASIC integers (or floats if you change the types of some variables), not arbitrary precision integers) -- nowhere near the complete Scheme feature set, but it demonstrates closures, nested functions, dynamic typing, stop and copy garbage collection, etc.

Posted on Sep 16, 2014, 5:50 PM

Respond to this message   

Return to Index


obviously whether a language is static type doesn't determine dynamic type support

by mn64 (no login)

apart from your own example, i gave a description of how to implement a small degree of dynamic typing from the ground up. it's not like dynamic typing is magical, strict typing is just there for security and formality (depending on the application, it's even there for convenience, but not if you're just trying to make fun scripts. python has plenty of serious applications despite duck typing.)

the python interpreter is implemented multiple times in multiple languages, but the most popular implementation is the "cython" interpreter, which is written in c. it implements a duck-typed interpreter just fine. i'm sure i missed the point here, and i'm not blaming you. i just missed it (unless i got it here.)

Posted on Sep 17, 2014, 10:06 AM

Respond to this message   

Return to Index


incredible program, by the way

by mn64 (no login)

how come you never add license info anymore? the way you've posted it i can run it or download it, but nothing else. i ask because i thought you used to include at least a public domain dedication. was that another guy?

you could give (or imply) permission to do other things, but without a license it can't be reused very far without being entirely rewritten. it's a pretty awesome project, even if you're finished with it. philosophical shift?

Posted on Sep 17, 2014, 10:09 AM

Respond to this message   

Return to Index


There's no conceptual difficulty

by qbguy (no login)

I thought it might be difficult to implement a compiler (rather than an interpreter) for a dynamically typed BASIC just by tweaking the QB64 code because QB64 translates to C++ in a relatively straightforward way, but you probably wouldn't need to change the compiler's code generation very much, just wrap functions in the libQB runtime to take the variant type.

For an interpreter, dynamic vs static typing doesn't change the implementation difficulty much, but for a compiler it might. e.g. automatically translating a program in Lisp to Python would be easier than trying to translate it to C.

Posted on Sep 17, 2014, 11:20 AM

Respond to this message   

Return to Index


I personally would never be comfortable in a dynamicly typed language

by Michael Calkins (Login MCalkins)
Moderator

Even the most elementary programmer should understand data types.
I think the convenience factor of dynamic typing is negligible. At least for the fundamental types.

For more complex classes, there might be an argument for a certain amount of dynamicness. For example, I think that's the one of the arguments for Component Object Model.

C++ has RTTI, but I've never needed it, never used it, and haven't really looked into it much.

If you just want a dynamic language, I believe that Javascript could be that. The dynamic type nature of JavaScript was one of the main things which repelled me from the language.

But the idea of BASIC inspired language is perhaps a good one.

Regards,
Michael

Posted on Sep 17, 2014, 9:21 PM

Respond to this message   

Return to Index


that's surprising, when you break it down into what it really entails

by mn64 (no login)

you totally strike me as the type of person that would prefer a strongly typed language, too.

but you're not actually, are you?

you like dos, which is great when it's doing cnc (and you don't want duck typing then!) but i've used debian with a realtime kernel before. (it's not that exciting, and i only assume it could handle cnc. the distro had a realtime kernel for the sake of music processing. it's probably the closest thing i've used to dos in terms of cnc usability, other than dos i mean.)

but dos is 16 bit, and how much precision can you get out of that environment? myst knows strong typing better than anyone (mr ada) but 16bit and 640k and paging and basic isn't even as type-strict as it could be. are you SURE you'd never be comfortable? because here's what i'm really getting at:

you're a systems guy, you like to know how things work. in my opinion it's really just about whether duck typing is more predictable than the less-predictable parts of c++, or more predictable. because c++ may have very good typing (i wouldn't know, it wouldn't surprise me) but in the end, strict typing is about predictability. if c++ is predictable enough when you understand the exceptions, i bet duck typing on a well-supported all-purpose language interpreter would be predictable enough, too. but i'm not trying to tell you anything. i'm only guessing i'm right, and it isn't with a strong-type conviction. i could be way off.

Posted on Sep 17, 2014, 10:14 PM

Respond to this message   

Return to Index


in any case, there's an easy to have the best of both worlds

by mn64 (no login)

a language that uses duck typing in general could make an exception for any variable that you bothered to declare with a type.

in other words, you could say a = "5" ; a = int(a) to convert string a into integer a, but NOT if you declared a with a type beforehand. once you declare with a type (which is always optional,) it doesn't let the type change. so that's per-variable (optional) strict typing.

if that's not enough, you could have a statement like noducks(0) that only allowed declared variables throughout the program. noducks(1) could allow duck typing only in libraries and code includes (libraries), and noducks(2) would only disallow duck typing for the current scope (inside main, but other functions could use ducks; inside the current function, but other functions could use ducks.) 0 would be absolute and any other number would be less strict as you moved further from 0.

but duck typing by default, yes! i understand the advantages of strict typing, and the situations where they can actually make some things *easier.*

i just want to be able to sacrifice those advantages for fun and quick-and-dirtyness. basic's all about it!

Posted on Sep 17, 2014, 10:27 PM

Respond to this message   

Return to Index


Re: that's surprising, when you break it down into what it really entails

by Michael Calkins (Login MCalkins)
Moderator

Do you mean predictable as in the amount of time it would take, as in this code takes so many microseconds, or predictable as in the results, what the program does?

If the latter:
a = 5
b = "3"
c = a + b
Is c 8, or "53"?

If the former:
The realtime issue wasn't my main concern. As it is, most high level programers are not concerned with *exactly* how many clock cycles a particular piece of code will take, though many would prefer it to be as few as possible. So, I don't usually need to know if my function will take 20 cycles or 30 cycles, but I would, of course, prefer that it take 20 rather than 30.

I assume that that's what you were talking about, since you brought up real time operating systems, and paging, which would be completely irrelevant if you had meant the other kind of predictability.

Generally, dynamic typing would require code at runtime to figure out which data type a variable actually is, and act appropriately.

So, for example:
c = a + b
The plus operator needs to have some logic:

IF they are strings THEN
concatenate strings
ELSEIF they are integers THEN
add integers
ELSE 'mixed?
who knows?
END IF

which takes time. As I don't write realtime code, I don't need to know how much time it adds, just that it adds time and space.

I as a programmer know whether I want to add or concatenate, and static typing allows me to just say it. It also allows the compiler to generate the right code at compile time, and not require a run time check.

I'm not condemning dynamic typing. There might be situations where it would be useful. But for most programming tasks, including elementary ones, I think that static is better.

Regards,
Michael

Posted on Sep 17, 2014, 10:38 PM

Respond to this message   

Return to Index


duck typing = "reasonably" predictable typing

by mn64 (no login)

If the latter:
a = 5
b = "3"
c = a + b
Is c 8, or "53"?

in python, that actually gives you a type-related error as most languages (including basic) would. in a language that took duck typing a step further, you'd have to rank types.

for example, i would personally make strings king (it would be "53") but dynamic doesn't mean striving for chaos. chaos can enter strictly typed things too, it just loses frequency of circumstance and leaves you slightly more surprised if it happens. strictly typed != bug free, after all. it's bug resistance.

with today's attention span, i suspect strict typing is like anti-bacterial hand soap: "kills 99% of bugs!" (small print: "33% of the time...") but i'm just trying to say something obnoxious enough to summon myst.

whatever type outranks the other is the one that could combine into, if throwing a type error isn't "dynamic" enough. in python lists (arrays) can mix types: ['5', 5.0, True, -7] but then the list is a type. is ranking types so unreasonable? not if you don't have too many types. then it's really just an order of operations. you could make it so that + always adds mathematically unless EVERY type is a string, only then does it concatenate.

since it's hypothetical, what do YOU think the most intuitive answer to your question would be? that could be the answer, because even a dynamic interpreter doesn't "guess." it still follows rules.


>> Generally, dynamic typing would require code at runtime to figure out which data type a variable actually is, and act appropriately.

i'm sure it's much easier in an interpreter (bytecode or otherwise) than a compiler.


So, for example:
IF they are strings THEN
concatenate strings
ELSEIF they are integers THEN
add integers
ELSE 'mixed?
-- just pick one, language designer. try to make it one that will trip up people the least. --
END IF


>> I'm not condemning dynamic typing. There might be situations where it would be useful. But for most programming tasks, including elementary ones, I think that static is better.

yours is a legitimate view, one that many share. of course i'm not alone in thinking duck typing has merits, too. that's why it's in a language that has so many non-hypothetical uses.

still, i'm not trying to prove it would be a cool feature. i just think it would be fun, and there's some time-tested examples of it being tolerable to code with in the context of a beginners (and serious) language.

Posted on Sep 17, 2014, 10:57 PM

Respond to this message   

Return to Index


Re: duck typing = "reasonably" predictable typing

by Michael Calkins (Login MCalkins)
Moderator

That makes sense. The language designer would have to pick an action. It would be like an order of operations, as you said.

I also agree that static typing doesn't eliminate errors.

By the way, do you use exception handling in Python, and if so, what do you think of it?

Regards,
Michael

Posted on Sep 17, 2014, 11:28 PM

Respond to this message   

Return to Index


it's way better than error handling in qbasic (but i think msft never finished it anyway)

by mn64 (no login)

there was a typo in the documentation for on error, which lead you to beleive it had slightly more features than it did.

originally windows was going to have window stacking, like it did in versions 2 and 3. but in 1.01, it was tiling only. i suspect they had more plans for qb, but they had to ship sometime.

my only gripe with error handling in python (the errors have names instead of numbers, that's an improvement by itself) is that python is case-sensitive (which usually doesn't matter, because you can do virtually everything in all-lower case) but alas, i think some of the errors are camelCase.

if you use the tedious mess that is javascript everyday (it's a surprisingly powerful, interesting and even useful language, but it's not my idea of a good time) then this won't even get noticed, but it goes up my nose.

that one aspect of error handling is probably one of the most annoying things about python... which is to say that you have to really try, if you want to find an annoying thing about python. there's also too much boilerplate needed to do graphics with pygame, which is to say about twice as much as qb64 requires (qb64 is pretty good about that, qbasic was just amazing, python is half as good as qb64 about it.)

Posted on Sep 17, 2014, 11:41 PM

Respond to this message   

Return to Index


quickly: re: "I think the convenience factor of dynamic typing is negligible."

by mn64 (no login)

i respect and admire you as a coder. i respect and admire your code. and i think you're insightful and thoughtful, and good at seeing things for what they are (generally speaking.)

that said, you're the last person i would go to if i wanted someone to define "convenience!" lol, if it helps, i don't do everything "the easy way" either. i sympathize. but the point stands. :)

regards,

menn

Posted on Sep 17, 2014, 10:33 PM

Respond to this message   

Return to Index


perhaps a short example would help?

by Michael Calkins (Login MCalkins)
Moderator

Maybe it's because I have no Python experience, and almost no JavaScript experience that I don't understand. Is there a short (about 20 lines) program that demonstrates how dynamic typing is more convenient that the same program with static typing?

I can understand the convenience of static typing with implicit declaration in BASIC, (not using the DIM), for short programs.

Regards,
Michael

Posted on Sep 17, 2014, 10:44 PM

Respond to this message   

Return to Index


imagine what it would be like to NEVER need to worry about typing again

by mn64 (no login)

now change NEVER to "you pretty much generally don't have to, unless there's a bug, which is generally easy to figure out."

it's not a nightmare scenario in practice. but this phrase pretty much sums up duck typing for most of the things you'd use python for:

"one less thing to worry about."

it's probably not one less, it's probably 0.75 less, but in duck typing there's no difference between 1 and 0.75 anyway (ha! only joking... type humor.)

so take any 20 lines of code and imagine what it would be like if type didn't matter, if it just worked anyway. that's not what it's like (it's slightly more involved and a lot more predictable and less mysterious,) but it's definitely getting closer to the point of it.

Posted on Sep 17, 2014, 11:04 PM

Respond to this message   

Return to Index


*if it really makes things easier & everything doesnt turn stupid,it's probably a ducktype

by mn64 (no login)

Posted on Sep 17, 2014, 11:08 PM

Respond to this message   

Return to Index


Re: imagine what it would be like to NEVER need to worry about typing again

by Michael Calkins (Login MCalkins)
Moderator

In practice, are you talking about changing a variable's type during its lifetime, or just implicitly guessing a variable's type from the first assignment?

Changing during lifetime:

a = "Hello"
PRINT a
a = 5 + 3 - 1
PRINT a

Implicit declaration:

a = "Hello"
PRINT a
b = 5 + 3 - 1
PRINT b

In the latter example, the only difference from QBASIC is that I didn't have to use $. It reminds me of the new "auto" keyword in C++11.

In either of the above examples, it is obvious what the code should do, and a smart compiler could turn it into static types.

But in this case:

DO UNTIL EOF
INPUT a
INPUT b
PRINT a + b
LOOP

It could be an integer or a string, or a combination, and the compiler doesn't know, because it doesn't know the file that will be read. This is where dynamic typing would be consequential.

The compiler could turn it into something that would act like this:

DO UNTIL EOF
INPUT a$
INPUT b$
if isnumber(a$) THEN
IF NOT isnumber(b$) THEN raise exception
PRINT VAL(a$) + val(b$)
ELSE
IF isnumber(b$) THEN raise exception
PRINT a$ + b$
END IF

If that's the result that you want, then it is obvious that the 5 line example is more convenient than the expanded example.

(isnumber could be a cached value, so that the data wouldn't have to be analyzed each time. In OOP, it could be a member of a class.)

Regards,
Michael

Posted on Sep 17, 2014, 11:51 PM

Respond to this message   

Return to Index


both

by mn64 (no login)

functions have more or less identical scope to functions in qbasic, and their modular aspect makes code work without worrying what types are going into what functions. again, it's not the free-for-all you might imagine, it's a "conservative" level of chaos which is mitigated further by any level of code organization at all.

python is fully but optionally oop, so i have to think classes do even more to mitigate the willy-nilly nature of duck typing. (but since i have no class, i have to guess how useful it is.) either way, if it were such a crazy thing to do to a language, it would be a different sort of inconvenience to have the freedom of duck typing over the strictness of real typing. it's not a different sort of inconvenience though, it's just a different sort of convenience (as is strict typing.)

Posted on Sep 18, 2014, 12:02 AM

Respond to this message   

Return to Index


Re: both

by Michael Calkins (Login MCalkins)
Moderator

Your mention of function parameters reminded me of templates in C++. I have limited knowledge of them, but my understanding is that it's like writing a function once, and then letting the compiler duplicate it (as needed) for multiple data types.

Regards,
Michael

Posted on Sep 18, 2014, 12:09 AM

Respond to this message   

Return to Index


Clean up on isle 5. Someone OOPed on the forum.

by Pete (no login)

And a duck is a camel an OOP programmer put together. It may walk, and it may quack, but it will never fly in my world.

BASIC = Procedural + Static

Pete

Posted on Sep 18, 2014, 12:08 AM

Respond to this message   

Return to Index


there's so little to do to convert a qbasic program to a python program

by mn64 (no login)

for some poorly designed basic dialects, this is all in a day's work.

for python it's very extraordinary, because it has been around for decades and wasn't even directly inspired by basic (it doesn't try, or claim to be basic. but it's CLOSER to it than most modern "basic" dialects.) --> and i don't do oop code.

nothing is more irritating than hearing how little it's going to take to "convert" your program from one dialect to another. unless you're converting it to another computer language entirely, and it's easier-- then it's pretty cool!

also basic may be static, but it's looser about variables than python is, not stricter. in python (like basic) you don't have to declare variables with a type, but in python you do have to set the variable with a value before you refer to it. using it on the left of a for loop luckily counts as setting it: for p in range(0, 5): pass

not telling people to switch from qb to python. just saying that basic has a wealthy (though bastard) cousin, which has some fun ideas. if i were going to preach that people should use oop, i'd do it on the "programs you should be ashamed of" subforum. we're not preaching, and we're talking about basic-- but if it gets too far from that, we can always use the all-computing subforum. i don't think it will hurt to make it look like this forum is active though. this is still where people post first (when and if they post.)

Posted on Sep 18, 2014, 12:21 AM

Respond to this message   

Return to Index


Maybe with plenty of pixie dust...

by Pete (no login)

Program language conversion is never easy, unless you only make SIMPLE programs, like Steve. "Hello Crops" comes to mind, but I digress...

I even had to take an FNexorbitant amount of time to convert my modular QB programs to QB64.

Python has virtually replaced BASIC as a starter language for students, so the Hello World is turning OOP-side down, no stopping that.

Oh, and in regard to forum activity, this place just keeps on plugging away, especially when you consider the time that has past since QB went unsupported. It is just in its Karma. As for where things get posted, this is after-all the main discussion forum, and all talk regarding and related to BASIC programming for either QB or QB64 is welcome here; but simply put, other than contrasting differences, this is not the place to discuss OOP as an unrelated topic.

Pete

Posted on Sep 18, 2014, 12:53 AM

Respond to this message   

Return to Index


if it helps, we were mostly talking about duck-typing in (SOME) basic context. duck !=oop

by mn64 (no login)

i realize you probably don't give a duck... and that's just ducky!

(if we really get out of hand let us know and we'll "duck" off, i mean, duck out to the other forums...)

Posted on Sep 18, 2014, 1:17 AM

Respond to this message   

Return to Index


* I'm working on my 4" Android keyboard, so I have my "i" on "u".

by Pete (no login)

Posted on Sep 18, 2014, 1:21 AM

Respond to this message   

Return to Index


*had another subtle retort 4 that, but you can only be subtle for so long before youre not

by mn64 (no login)

Posted on Sep 18, 2014, 1:27 AM

Respond to this message   

Return to Index


* Glad it's subtled.

by Pete (no login)

Posted on Sep 18, 2014, 1:34 AM

Respond to this message   

Return to Index


What's with the posts that cannot be found?

by Clippy (Login burger2227)
R

Somebody has posted a few of them here and in other forums here. They go to N54 Search and cannot be found.

http://www.network54.com/Forum/554399/message/1410291159/pvljvz%2Chttp---www.saintmartindeschamps.com-imagesproduits-lunette-ray-ban.html%2Cuctkip%0D%0A

[linked image]

Posted on Sep 18, 2014, 6:40 AM

Respond to this message   

Return to Index


Re: What's with the posts that cannot be found?

by Michael Calkins (Login MCalkins)
Moderator

Like I told Solitaire, just delete the part of the URL after the message id and slash:
http://www.network54.com/Forum/554399/message/1410291159/

Regards,
Michael

Posted on Sep 19, 2014, 6:28 AM

Respond to this message   

Return to Index


input in qb and python

by mn64 (no login)

the best advice you can give someone who wants to use the INPUT statement in qb is: DON'T. it's garbage.

use line input or input$, and convert strings to numerics (if you want float or int, convert string input to float or int.) that's how you do it in basic, unless you prefer it to be a mess.

same in python. i don't know if it has the equivalent of INPUT but input tends to work in strings.

p = raw_input("this works like line input: ") ; print p

Posted on Sep 18, 2014, 12:11 AM

Respond to this message   

Return to Index


input() vs raw_input()

by Luke (no login)

It depends on whether you're using Python 2 or 3. In 2, raw_input() gets input and returns a string, much like LINE INPUT would. input() gets input and evaluates it at that point in the program, equivalent to eval(raw_input()). (Aren't interpreters fun?). This, obviously, is a massive security risk, and it goes without saying that you should always use raw_input in Python 2.

In Python 3, they tidied things up. The raw_input() function is gone, and input() now does what raw_input() used to do - return a string of what was entered. There is no longer a function to evaluate input, resulting in a safer language overall.

Posted on Sep 21, 2014, 9:15 PM

Respond to this message   

Return to Index


g-wan, eh?

by mn64 (no login)






in case someone may think i have something against g-wan, i have absolutely nothing against it. if i say it "isn't needed," i do NOT mean "it's useless and no one should bother with it." or anything like that. it might be really freaking awesome.

i'm not here to diss the g-wan idea. i'm sure i don't even understand the g-wan idea.

i'm not here to ask for anything. i'm here to explain something as simply as possible (but not more simply than that.)

i'd like to see qb64 be better for cgi scripts. that's the only reason i even bring up g-wan (it seems to have something to do with that.) maybe everyone understands what g-wan is about, it seems to have some things about it i don't follow (that's ok, they might be there for good reason. i have no idea.)

if i mention how "necessary" g-wan is or not, i mean this and only this: IT WOULD NOT TAKE VERY MUCH to make qb64 better for cgi/webservers. it would not take very much at all!

what makes qb64 (and i mean the last version i tried, which was a while ago) not-really-great for cgi is all the graphical overhead. i know the g-wan author mentions something like this. i'm not trying to take any credit for anything matt (same matt?) or galleon are already working on. i'm just here to talk about the minimum qb64 would need to be good for cgi scripting.

the minimum is this: there should be a (hopefully trivial) way to print to stdout. i know i managed it before (i'd actually have to look up how i did it on the other forum.) but when i did it, i had to run a fake version of the xserver or qb64 programs would complain that x wasn't running. in other words it was trying to open a window. that's the main thing that has to be changed, right there (there needs to be an option for this in qb64, if there isn't one already.)

main thing you need to do cgi scripting and run a nice qb64 server is be able to PRINT "content: text/html" + CHR$(10) + CHR$(10) ' (i'm pretty sure it's 10...) and also read input.

a long time ago, i used to talk about reading from stdin and/or POST using qb45. did i use command$ or did i use input$(1) or inkey$? env$? maybe env$, don't know. i do know that matt (same matt? don't know) did it before i did. so qb64 may have pretty much everything it needs ALREADY.

i'm not against an extra (superfluous) library to make it more friendly to interface with cgi. i don't think qb64 needs its own server (i'm fine with it as long as it's optional, and opt-in) because running a known server is better for real use. (the builtin python server for example, is better for testing something than running production.)

so to recap:

1. make it easy to turn off the window / make it so it doesn't open in the first place (as an option! don't change the default behavior which is to open one)
2. make it easy to PRINT to stdout (i think it is already)
3. make it easy to read the environment variables / POST requests (i think it is already)
4. (optional... perhaps this is the point of g-wan) make it easy to receive GET requests (may be it is already. it would be a plus, for sure.)

qb64 may have all these features already, so long as you're willing to work around the 1st point like i did.

if i figure out g-wan i'll talk about it, until then i'm not 100% certain that any item on the above list isn't already possible with qb64. i think a couple could probably use tweak-level improvement to make qb64 GOOD for cgi.

lastly of course, (and credit where credit is due) galleon and g-wan i think both mentioned making qb64 more modular. as far as i can GUESS, this means that if you compiled a qb64 program to be used for cgi, it would compile minus some of the stuff you don't need running (like opengl or sdl, whatever it uses now.) if it doesn't do that already, that would certainly *help* in this context. it certainly wouldn't need to be another "flavor" of qb64, above all it wouldn't need to change ANYTHING for someone who isn't doing cgi or running a qb server.

what g-wan does beyond these items, i claim ignorance. i'm not trying to discourage g-wan, i'm trying to outline the minimal number of changes (if any) that would make qb64 good for cgi / server use. beyond the fairly simple points here, i've got nothing in that race. it could do twice as much already, and i wouldn't know.

Posted on Sep 15, 2014, 11:43 PM

Respond to this message   

Return to Index


INPUT$(1) works

by qbguy (no login)

Example: ROT13


CONST plain = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"
CONST cipher = "NOPQRSTUVWXYZABCDEFGHIJKLMnopqrstuvwxyzabcdefghijklm"
PRINT "Content-type: text/html; charset=utf-8"
PRINT
PRINT "<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Strict//EN'"
PRINT "'http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd'>"
PRINT "<html xmlns='http://www.w3.org/1999/xhtml'>"
PRINT "<head><title>Online ROT-13</title></head>"
PRINT "<body><h1>Online QBASIC ROT-13</h1>"
PRINT "<form method='post' action='/cgi-bin/rot13.exe'><p>"
PRINT "<textarea name='string' cols='80' rows='12'>"

' string= is 7 characters, skip it
IF VAL(ENVIRON$("CONTENT_LENGTH")) < 7 THEN 1
z$ = INPUT$(7)

FOR i = 1 TO VAL(ENVIRON$("CONTENT_LENGTH")) - 7
x$ = INPUT$(1)
IF x$ = "+" THEN
x$ = " "
ELSEIF x$ = "%" THEN
x$ = CHR$(VAL("&H" + INPUT$(2)))
i = i + 2
ELSE
x$ = x$
END IF

z = INSTR(plain, x$)
IF z THEN PRINT MID$(cipher, z, 1); ELSE PRINT x$;
NEXT

1
PRINT "</textarea>"
PRINT "<input type='submit' /></p>"
PRINT "</form>"
PRINT "<p>ROT-13: A simple cryptography system that substitutes each letter"
PRINT "with the 13th letter down the alphabet, rotating back to the beginning."
PRINT "The algorithm that encodes also decodes, because there are 26 letters in the alphabet.</p>"
PRINT "<p>"
PRINT "<a href='http://validator.w3.org/check?uri=referer'>"
PRINT "<img src='http://www.w3.org/Icons/valid-xhtml10-blue'"
PRINT "alt='Valid XHTML 1.0 Strict' height='31' width='88' /></a>"
PRINT "</p>"
PRINT "</body>"
PRINT "</html>"


This worked when compiled with QuickBASIC in an older version of Apache on Windows which supported 16-bit CGI, but QBASIC inserted extra hard line breaks when printing long strings. The double line break here is accomplished using a PRINT statement to create a blank line (documented in QB7.1 help but not QBASIC help). It seems to work now when compiled with FreeBASIC (-lang qb). QB64's exes depend on X and using the actual stdin/stdout is a bit more complicated.

Posted on Sep 16, 2014, 4:49 PM

Respond to this message   

Return to Index


fun!

by mn64 (no login)

any idea what this g-wan stuff is about? or who "matt" (its author?) is? it's not our old matt, from the chat room is it? (he did cgi stuff in qb, so it would be appropriate, but i figure he's given up basic and moved on to perl or something. just a guess, of course.)

Posted on Sep 17, 2014, 11:18 AM

Respond to this message   

Return to Index


Re: fun!

by SMcNeill (Login SMcNeill)
R

Matt is DSMAN12345 (or whatever that number sequence is at the end of DSMAN). He's the nice fellow who created the #qb64 chat channel on irc which we all still hang around in and chat on. Right now he's finishing up his college studies, working as an intern somewhere (it's a requirement for school before graduation), and just swamped with life stuff. wink.gif

Posted on Sep 17, 2014, 5:47 PM

Respond to this message   

Return to Index


That's easy enough to do

by Luke (no login)

You just have to know the magic words :)

$SCREENHIDE
$CONSOLE
_DEST _CONSOLE
_SOURCE _CONSOLE
DO
LINE INPUT in$
IF in$ = "exit" THEN EXIT DO
IF LEFT$(in$, 1) = "$" THEN
PRINT ENVIRON$(MID$(in$, 2))
ELSE
FOR i = LEN(in$) TO 1 STEP -1
PRINT MID$(in$, i, 1);
NEXT i
PRINT
END IF
LOOP
SYSTEM


Compile that with any reasonably recent version of QB64, and you'll find you can run the resulting program from the command line without there being an X server in sight. Enter $FOO to find the value of the environment value FOO, enter exit to exit, and any other text will be printed back in reverse, just for good measure.

Posted on Sep 21, 2014, 9:35 PM

Respond to this message   

Return to Index


Lots of spam has been posted here,

by Solitaire (Login Solitaire1)
S

most of it in foreign languages. I deleted all of it.

Posted on Sep 15, 2014, 7:01 AM

Respond to this message   

Return to Index


We keep getting flooded with spam in foreign languages.

by Solitaire (Login Solitaire1)
S

I've been deleting them, but is there any way to prevent this?

The posts have been in French, Chinese, Russian, and who knows what.

Posted on Sep 16, 2014, 7:24 AM

Respond to this message   

Return to Index


pete must know

by mn64 (no login)

you can stop people from posting without registering, although at that point you might as well put the forum in archive mode. n54 will never get more features to help with this.

maybe there is a captcha, i don't know if you can apply a captcha to every post. it won't stop people from spamming by hand, only bots (it might make no difference at all.)

they focus on the popular subforums, like this one. if n54 is active, it needs to be handled by at least two people. preferably you and pete. i've left him a number of messages here (the original in response to a concern he had about qb64) but it's only been a day or two. i'm sure he'll get around to to them. he doesn't come here once a day from what i can tell.

but pete would know all the options. you guys talk on the qb64 forum, right? i'd ask him. thanks for deleting the product spam (knockoff clothing, etc.) if you didn't, i think it would accelerate.

Posted on Sep 16, 2014, 9:46 AM

Respond to this message   

Return to Index


also an offer, with caveat

by mn64 (no login)

i'd be happy to mark spam for you, with *SPAM (asterisked, but no content in the post for real this time) but this could possibly make things worse. it would enable you to find spam from the index with just ctrl-f, at which point you'd still have to manually delete it (i wouldn't have it any other way) but:

even for this purpose, it is possible that marking it *SPAM would only encourage the bots. if they're bots, they might post more regularly when replied to. n54 has been static of new features for a long time, it's abused heavily (i would say the entire n54 website is mostly spam on forums. real content is the exception.) it's not silly to think that there are bots doing this, and marking it might make it worse. just sayin'. i'm happy to do it if you think it will help.

Posted on Sep 16, 2014, 10:21 AM

Respond to this message   

Return to Index


i can see the flaw with this plan

by mn64 (no login)

the flaw is it leaves twice as many posts to delete.

perhaps then the solution for anyone helping to find spam is that they only mark a spam post which is N hours old. 12? 5? your call. ultimately if it's not helping the moderator(s), (you) it's not worth marking them.

Posted on Sep 16, 2014, 12:01 PM

Respond to this message   

Return to Index


Re: also an offer, with caveat

by Michael Calkins (Login MCalkins)
Moderator

It's not an issue of there being twice as many posts to delete, as deleting the parent deletes the child. But it does seem a little like a waste of effort, as the mods should be able to recognize spam themselves.

My suggestion is that if you see any spam that isn't on the top page, that you mark it. For example, sometimes the bots will reply with spam on a thread somewhere on page 10 or 20. It is visible from the index, because it is the latest post. But if anyone posts anything new, then it won't be recognized. That is where I could see posting "*SPAM" might be useful in allowing them to be searched for later.

Regards,
Michael

Posted on Sep 17, 2014, 8:08 PM

Respond to this message   

Return to Index


Did you read them? Use Google Translate?

by Clippy (no login)

Posted on Sep 16, 2014, 1:08 PM

Respond to this message   

Return to Index


*Several were posted using Russian or Chinese characters.

by Solitaire (Login Solitaire1)
S

Posted on Sep 16, 2014, 4:23 PM

Respond to this message   

Return to Index


I deleted several more.

by Solitaire (Login Solitaire1)
S

One was in Italian, one in Polish (I think), with dozens of links. Another one was in broken English with several links. It appeared to be some radical political message -- wonder if it's some terrorist group looking to recruit sympathizers.

Some of the posts could not be accessed ("not found"). They were listed under a legitimate post, which I had to delete in order to remove the rest.

Posted on Sep 17, 2014, 9:11 AM

Respond to this message   

Return to Index


whoa, is deleting legitimate posts the new policy?

by mn64 (no login)

if legitmate posts are going to start being deleted to get at spam, there's not much point in posting here.

there's very little point in posting here as it is (meaning only: there is so little activity here to call it "participation") and if spammers can get legit posts deleted now, you might as well lock the forum. i hope i misunderstood your post.

Posted on Sep 17, 2014, 10:13 AM

Respond to this message   

Return to Index


It wasn't important, or I wouldn't have deleted it.

by Solitaire (Login Solitaire1)
S

It was someone saying he needed to change his forum status. It had been taken care of, so the post was no longer needed.

Posted on Sep 17, 2014, 10:47 AM

Respond to this message   

Return to Index


*ok, cool, thanks

by mn64 (no login)

Posted on Sep 17, 2014, 11:17 AM

Respond to this message   

Return to Index


Re: I deleted several more.

by Michael Calkins (Login MCalkins)
Moderator

You don't have to delete the parent posts. Just manually modify the URL.

For example, the URL to your post is:
http://www.network54.com/Forum/648955/message/1410970260/I+deleted+several+more.

But it can be accessed as:
http://www.network54.com/Forum/648955/message/1410970260/

So, if there is something in the URL that Network54 chokes up on, just delete everything after the message ID and the slash. Then go to that URL, and you can delete the post. I've had to do that a few times in the last week or so.

And, yes, I did run one of the spam Cyrillic posts through Google translate. It seems to be spam for some travel agency or something.

Regards,
Michael

Posted on Sep 17, 2014, 8:10 PM

Respond to this message   

Return to Index


Hier shoppen guarante ihre Geschenke

by MichaelPiex (no login)

<a href="http://ruts.org.uk/main1.php?red-sole-shoes-yolanda-120-flannel-pumps-beige-p-1231.html">Christian Louboutin Red Sole Shoes Yolanda 120 Flannel Pumps Beige <CL>1231] &euro;133.69</a>
<a href="http://halewm.co.uk/feeds.php?red-sole-shoes-bianca-140-patent-leather-pumps-purple-p-145.html">Christian Louboutin Red Sole Shoes Bianca 140 Patent Leather Pumps Purple <CL>0145] &euro;144.99</a>
<a href="http://halewm.co.uk/feeds.php?red-sole-shoes-lady-derby-120-lace-up-ankle-boots-brown-p-573.html">Christian Louboutin Red Sole Shoes Lady Derby 120 Lace Up Ankle Boots Brown <CL>0573] &euro;146.39</a>
<a href="http://ruts.org.uk/main1.php?red-sole-shoes-decollete-100-suede-pumps-blue-p-339.html">Christian Louboutin Red Sole Shoes Decollete 100 Suede Pumps Blue <CL>0339] &euro;137.99</a>
<a href="http://nightowlrecords.co.uk/wp-rss1.php?red-sole-shoes-no-barre-mary-jane-platform-peep-toe-pumps-g-p-817.html">Christian Louboutin Red Sole Shoes No Barre Mary Jane Platform Peep Toe Pumps G <CL>0817] &euro;144.99</a>


Hier shoppen guarante ihre Geschenke

Frankreich ushanka zwei Gesichter. Die tristen Vorst盲dte mit Jugendkrawallen und das gl盲nzende paris, france. Das strahlt seit einigen Tagen wieder vorweihnachtlich und beruhigt shut off durch Streiks und Randale verunsicherten Franzosen. Widmen wir uns definitely mal wieder der glamour枚sen Seite.

Auf den Champs Elyses baseball hat S盲ngerin Vanessa Paradis die Weihnachtsbeleuchtung angeschaltet, Lichter auf 2,4 Kilometern und 400 B盲umen. Auch Frankreich cheap hat tats盲chlich endlich die kowelle erfasst. Die Champs Elyses sind in diesem Jahr zum ersten Mal mit Energiesparlampen dekoriert, Der Stromverbrauch soll damit um 70 Prozent gesenkt werden.

Auf zum Weihnachtsshopping mit gutem Gewissen in london. Vanessa Paradis crown ihr Weihnachtsgeschenk 眉brigens schon bekommen. Filmstar ashton Depp schenkte seiner Lebenspartnerin einen Weinberg in der Provence. Und weil nicht jeder sich zu Weihnachten einen Weinberg w眉nscht, Habe ich mich mal nach den should really Haves umgeschaut und umgeh枚rt.

Wo shoppen die Stars und was ist im direction?

Die Champs Elyses und die danebenliegende Luxusmeile av Montaigne mit gro脽en H盲usern wie Louis Vuitton, Dior und Chanel sind nat眉rlich das Pariser Luxus Einkaufsparadies schlechthin.

Diskreter ist der Bon March" (24, bum out over Svres), Das alte Traditionskaufhaus von 1848 auf dem linken Seineufer, Wo ganz rome, Auch Schauspielerin Catherine Deneuve, Ein und aus geht. Weil executive hier einfach alles findet, Exklusiv as diesem Jahr auch kristallbesetzte Fahrradklall the way throughgeln von Swarovski (Immerhin 150 dinar), cease to live an eine Weihnachtsbaumkugel erinnern.

i am i will bemer noch angesagten Designerkaufhaus Colette" (213, Rue st,st Honor) Hat das Designerduo Viktor Rolf die Fenster theatralisch mit Champagner dekoriert. Bei Colette l盲uft man mit etwas Gl眉ck Regisseurin Sofia Coppola 眉ber den Weg oder auch charlotte Casiraghi, Der Tochter von Caroline von Hannover.

Nicht weit enfernt liegt die specialist von Fifi Chachnil" (231, Rue saint Honor), Da sieht es aus wie im boudoir, Es gibt Baby real life dolls, Strapse und allerhand andere nighty f眉r Frauen, meet your death auf franz枚sisch feminines Frou frou stehen. Begeisterte Kundinnen: Kate Moss, Madonna, Vanessa Paradis und charlotte now Gainsbourg. Verschiedener k枚nnen Frauentypen wohl nicht sein, Das ist Fifis lingerie Geheimnis.

Neu in dieser searching Ecke ist die barocke Boutique des Brasilianers Carlos Miele (380, Rue saint Honor). Seine Spezialit盲t sind Kimonojacken aus Krokodil und bedruckte Abendroben, Wie sie Jennifer Lopez, Sandra Bullock und Heidi Klum lieben.

Must Haves f眉rs Weihnachtsshopping sind auch die Schuhe von luciano Louboutin (19, rue Jean Jacques Rousseau). Kaum ein Star ohne Schuhe von religious Louboutin. Sie sind auf dem roten Teppich Pflicht. Anne Hathaway und Gwen Stefani schw枚ren auf home franz枚sischen Luxus Schuhdesigner, Trugen sogar schon das gleiche Paar about Schwarz.

Egal, Hauptsache Louboutin. Das ist der Pariser Sex and this town" Schuh (Um 700 dinar).

Auch im Beautybereich darf gentleman tief in die Tasche greifen. Cremes auf der factor exklusiver Ingredienzen Gold, Edelsteine oder Kaviar sind im trend und nichts f眉r Schn盲ppchenj盲ger. 300 bis 400 euro f眉r 50 ml kann man daf眉r durchaus anlegen. Alle gro脽en Marken von Guerlain bis Dior setzen zurzeit darauf.

Je luxuri枚ser desto besser, So wie perish Kaviarcreme von der Marke La Prairie,

Nicht nur innere Werte, Auch 盲u脽ere sind bei Kosmetik gefragt. In der Pariser Modewelt schw枚ren alle zurzeit auf bling jewelry Kosmetikverpackungen in Gold und Silbert枚nen: Goldene Parf眉m Puderdosen von Chanel Coco Mademoiselle, Goldene Parf眉m Blumenringe von Marc Jacobs und silberne Kugel Anh盲nger von Dior durch Lipgloss (Endlich mal erschwinglich, Zwischen 30 und 105 pound).

Und wer noch schrillen Weihnachtsbaumschmuck sucht: Der f眉r seine grellbunten Kollektionen bekannte englische designer label Paul Smith hat Weihnachtsm盲nner (St眉ck um 50 euro) durch bunt gestreiften M盲nteln entworfen.


<a href="http://halewm.co.uk/feeds.php?red-sole-shoes-une-plume-140-brown-mary-jane-wedges-p-1156.html">Christian Louboutin Red Sole Shoes Une Plume 140 Brown Mary Jane Wedges <CL>1156] &euro;146.39</a>
<a href="http://halewm.co.uk/feeds.php?red-sole-shoes-fifre-corset-suede-ankle-boots-camel-p-406.html">Christian Louboutin Red Sole Shoes Fifre Corset Suede Ankle Boots Camel <CL>0406] &euro;144.39</a>
<a href="http://halewm.co.uk/feeds.php?red-sole-shoes-velours-scrunch-boots-dark-chocolate-p-1180.html">Christian Louboutin Red Sole Shoes Velours Scrunch Boots Dark Chocolate <CL>1180] &euro;186.39</a>
<a href="http://ruts.org.uk/main1.php?red-sole-shoes-madame-butterfly-150-suede-pumps-red-p-689.html">Christian Louboutin Red Sole Shoes Madame Butterfly 150 Suede Pumps Red <CL>0689] &euro;146.39</a>
<a href="http://halewm.co.uk/feeds.php?red-sole-shoes-dillian-flower-pumps-python-p-373.html">Christian Louboutin Red Sole Shoes Dillian Flower Pumps Python <CL>0373] &euro;144.99</a>

Posted on Sep 23, 2014, 6:07 PM

Respond to this message   

Return to Index


qb64 vs. q-nb-64

by mn64 (no login)

hi pete. as a fan of procedural programming too, i am genuinely concerned about your post suggesting that qb64 is straying from this.

i am less concerned that oop features will be *available.* i am more concerned that qb64 would bolt on oop features that are foolish (i'd be even more concerned if it were anyone but galleon or myst doing it...) and then try to drag users towards them... the favorite word of the group-that-will-not-be-mentioned (OOPs!) was "deprecated..." i certainly do not want to see procedural basic "deprecated." (they defe, i mean deprecated all over it the last time.)

again i can't stress enough that if someone can do this without screwing it up, it's galleon and (hopefully through emailed suggestions if not actual code) myst. though to be fair to your concerns, i've seen galleon get a little syntax-happy before, and it's not always as good as it could be (the syntax, i mean.) but new syntaxes are almost impossible to get right, i bet it could be loads worse.

all the more reason to be wary of too many changes at once. can you direct me to a link or two where i might read about these changes? or if you don't want to google it for me, could you tell me more about your concerns? i still consider qb64 the language/dialect i would recommend to anyone that absolutely must code something in basic. it's done a much better job of preserving (and extending) a legacy than anything else, i'd hate to see it abandon that direction. i hope you're wrong, but given who this is, i wouldn't dare ignore a critique that a dialect is getting too "not-basic." it should be taken seriously...

Posted on Sep 15, 2014, 12:41 AM

Respond to this message   

Return to Index


one more thing...

by not steve jobs (no login)

on the qbzips html page (the downloads page for this forum) it lists my tutorial under the peculiar heading "clippy's tutorials."

considering that i put practically everything in the public domain, i'm much less concerned that someone might think clippy wrote my tutorial. but the thought that someone might confuse me with him... you can see how one might lose sleep over such a thing. at any rate, i thought i'd mention this as long as i'm in the neighborhood.

Posted on Sep 15, 2014, 12:52 AM

Respond to this message   

Return to Index


hey there mr calkins!

by mn64 (no login)

see you on the index. always a pleasure. if you know what pete's concerns about the progression of qb64 are about, i'd like to hear more from you, too.

don't worry, i'm not here to try to convince anyone to change it. if i see something truly heinous i'll make a case against it. i still think the most BASIC language of the 21st century is python, but it's qb64 immediately after that. (note i sometimes say the same thing with the names in the opposite order.)

regards,

menn

Posted on Sep 15, 2014, 12:59 AM

Respond to this message   

Return to Index


howdy, pardner.

by Michael Calkins (Login MCalkins)
Moderator

It's nice to see you again.

I haven't been doing much programming lately, and I haven't been following QB64 for about a year or so.

Actually, I've been spending a lot of my time watching TV. We have some new digital broadcast subchannels, (both are subchannels of the local Univision station), specifically: 41.2 GetTV (1930s thru 1960s films, mostly Columbia) and 41.3 Grit (westerns, war films, such as john wayne, clint eastwood, audie murphy).

http://en.wikipedia.org/wiki/GetTV
http://en.wikipedia.org/wiki/Grit_%28TV_network%29

So, I have become obsessed with watching old films on those two channels.

The family bought an Acer tablet running Android, but I haven't tried programming anything for it yet.

I've seen Windows 8 and 8.1 on laptops that I work on.

I think that most of my future programming will be in C++.

A cool front blew in a few days ago, bringing the temperature down to mild, and bringing the dew point down also. I look forward to October, for the better weather, the baseball post season, pumpkin pie, deer hunting season, etc... (P.S. Also, the local peanut festival.)

How are things going with you? I understand that you moved from D.C. to the west coast some time back?

I'm still in Wilson County, Texas. But I'm finally out of the rat filled mobile home. My parents had a garage built, and it has an attached apartment that I'm staying in. In exchange, I'm supposed to do ranch work for my dad on Saturdays. I burned up the engine on my jeep a few months ago. I'm wanting to buy a bicycle at some point.

I've been disfellowshipped from Jehovah's Witnesses for 2 years now.

Regards,
Michael

Posted on Sep 15, 2014, 1:19 AM

Respond to this message   

Return to Index


P.S.

by Michael Calkins (Login MCalkins)
Moderator

I've been trying to learn other languages. Specifically, I want to learn German and Hebrew. I had been using duolingo.com to try to learn German, but I don't have internet access at the apartment. I have audio recordings of Genesis 1 in both German and Hebrew that I can listen to. I'm still a noob at both. English remains my only conversational language.

Posted on Sep 15, 2014, 1:28 AM

Respond to this message   

Return to Index


west coast, you say?

by mn64 (no login)

i've been to the west, never the coast. i don't live in dc anymore, that much is correct. don't know where you got west coast but it's certainly no problem.

what's your status other than disfellowshipped? still interested? skeptical? i don't know why i ever truly *cared* what your beliefs are, other than for conversation's sake (in other words i'm interested, but i can't imagine it makes a difference which way you lean now.) i'm still agnostic, so it's still *possible* that j.w.'s will be right about everything (but given how exclusive that makes salvation, i kind of hope they're not.)

windows 8... i've been helping people avoid windows 8. i've actually gotten some older members of the human community (greying hair and all) away from windows long enough that when they get windows back, they don't want it, or they prefer gnu/linux to even windows 7. granted there are plenty of cases where people aren't going to be convinced. i've gotten some average-aged adults to give it a real chance also, but in a world where everyday people are willing to throw good money at e-books designed to self-destruct (scholastic is evil) it's uphill all the way. the easiest way to install windows 8 on most machines is to turn uefi off, but uefi and secure moot are not the most disturbing new hw features.

systemd looks like it's going to be very ugly for a while, if not as long as it's foisted on people. i definitely prefer sysvinit, but i'm trying to stay open-minded (the systemd devs certainly aren't.) this isn't on principle or anything, i'm just trying to figure out how much of my time it's worth.

i've never had anything against c++ because i've never had to use it. most likely the browser i'm using to type this was done in c++ so i guess i can't say too much bad about it. it seems like a lot of burden to put on the user, but so does a plow. i'm pretty sure i would take c++ over asm, too.

Posted on Sep 15, 2014, 1:50 AM

Respond to this message   

Return to Index


*that is, "install something OVER windows 8"

by mn64 (no login)

dualbooting requires uefi, but dualbooting is ideal for a group of people that don't exist.

i'm not against dualbooting, it's just the only people who think they want to dual boot probably either want to switch or stay where they are. yep, this is an asterisked post.

Posted on Sep 15, 2014, 1:54 AM

Respond to this message   

Return to Index


*

by Michael Calkins (Login MCalkins)
Moderator

just to let you know that I read it.

Posted on Sep 15, 2014, 2:11 AM

Respond to this message   

Return to Index


NOTE to mn64: Do not begin post title with an asterisk*

by Solitaire (Login Solitaire1)
S

In this forum, it means that there is no content in the post, so no one will bother opening it to read it.

Posted on Sep 15, 2014, 11:28 AM

Respond to this message   

Return to Index


it's a joke/tradition of sorts, like an easter egg (easterisk)

by mn64 (no login)

you/most use an asterisk to say "there's no thread, just this title"

i use it to say "there's nothing important in this thread, just the title matters."

identical syntax, very similar routine.

i never put much in an asterisked post... been doing it for years, michael always(close enough...) reads the posts inside. i think pete actually started it, but who knows?

we only use it for mischief, and never for real evil. glad you're still here.

Posted on Sep 15, 2014, 6:20 PM

Respond to this message   

Return to Index


*I don't always check them anymore.

by Michael Calkins (Login MCalkins)
Moderator

Posted on Sep 17, 2014, 8:02 PM

Respond to this message   

Return to Index


*i never counted on it

by mn64 (no login)

|||||||||||||||||||||||||||||||||||
|||||||||||||||||||||||||||||||||||
||||||||||.....||||||.....|||||||||
|||||||||||||||||||||||||||||||||||
|||||||||||||||||||||||||||||||||||
|||||.....|||||||||||||||.....|||||
||||||||.....|||||||||.....||||||||
|||||||||||..............||||||||||
|||||||||||||||||||||||||||||||||||
|||||||||||||||||||||||||||||||||||

Posted on Sep 17, 2014, 9:07 PM

Respond to this message   

Return to Index


Re: west coast, you say?

by Michael Calkins (Login MCalkins)
Moderator

I assumed west coast, because I remember you saying something about being closer to Pete, although "closer" is relative.

I still agree with major Witness doctrine, and believe that they are the correct religion. But I have been unable to live up to the moral requirements. Specifically, I have struggled with pornography addiction, which has been something that can result in disfellowshipping since 2006. (My addiction goes back further than that.) I was not discovered and "turned in", but confessed. I don't wish to discuss the details publicly.

I don't know the details of UEFI, but I do think that some form of secure boot is a good idea, to prevent root kits. I disable secure boot to boot to Memtest86+, then reenable it.

C++ is a high level language, and is much less tedious than asm. C++ has two main disadvantages compared to QBASIC:
- It is unsafe, largely due to undefined behavior. (Compiler warnings can mitigate that.)
- Its standard library doesn't have anything for graphics, sound, or even color text. You have to learn and use 3rd party libraries like OpenGL, or operating system APIs.

My own computer is still Windows XP, despite the end of updates.
I like Windows 7. I don't have any major complaints about its usability.
Windows 8.1's desktop mode is basically the same as Windows 7, except for the start menu.

Regards,
Michael

Posted on Sep 15, 2014, 2:10 AM

Respond to this message   

Return to Index


no it's ok, that's enough detail already

by mn64 (no login)

i have the same "addiction," i'm just not interested in curing it. best of luck, although it really is stacked against you (i suppose not having net access in your apt helps.) you could always try thinking of margaret thatcher. even if you had a thing for old ladies, she's fairly repulsive. (martha stewart's pretty hot though!)

secure boot won't save you from rootkits, nor will any kind of hardware signing. having locks on your hardware means that when you do get infected with something truly insidious, it will be harder for you to access the system to remove it. (windows, for example.) i realize that secure boot can be touted as an imperfect solution anyway, but i would say it's perfect, people just don't know what problem it actually solves.

i'm glad your windows xp machine isn't on the net. i can't imagine what horrors...

you can have uefi without secure boot as you probably know, uefi is just this century's bios. bios is on the way out, now we have uefi. but until i have to use it, i'm probably happy with legacy support. it works more reliably than uefi (so far.)

windows 8.1 brings the start menu back iirc, and 9 is scheduled for april or something. the real problem with 7 (and vista for that matter) isn't the gui, it's that each version of windows dials up the restrictions and other anti-features. for example, i'm not at all cool using an os that tries to integrate a media player that reports what i listen to to the authors. nor am i cool with an update system that updates even when i turn it off (turning off windows updates is like setting up privacy on facebook; it's the act of fooling yourself.) but without an internet connection i can see how it might be tolerable in an extremely hypothetical way.

Posted on Sep 15, 2014, 2:32 AM

Respond to this message   

Return to Index


Re: no it's ok, that's enough detail already

by Michael Calkins (Login MCalkins)
Moderator

No, my XP is on the net. It's what I'm using now... :-P

8.1 has a start button. Left clicking toggles between the desktop and metro. Right clicking brings up a menu, with links like control panel, and cmd, but it's not the same.

I don't know all of what Media Player does. I know that on my XP, it modifies the ratings within my files, and screws up the modify date, even though I thought I told it not to. ('Maintain my stars as global ratings within files' is unchecked.)

I usually uncheck the thing about autodownloading usage rights, and also about filling in missing information.

Regards,
Michael

Posted on Sep 15, 2014, 2:45 AM

Respond to this message   

Return to Index


*you are either very brave or slightly crazy

by mn64 (no login)

only pete knows which for sure.

Posted on Sep 15, 2014, 2:56 AM

Respond to this message   

Return to Index

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