v1.5 128 bit (and beyond) math *** COMPILER ERROR ***

[Richard]

The preferred method for feature requests AND bugs etc is the link below

https://github.com/QB64Team/qb64/issues


When editing an include file for use with the current QB64 program being edited in the IDE - the .exe file generated does not use the latest include file version (unless the programmer remembers to also "edit" the line (and immediately restores the line) where the include file is mentioned).

Feature request - option to auto update to latest versions of any include files referenced when compiling

Summary github
#142   Multi instance launch problem     by Richard   bug
#135   _COPYIMAGE(x, 33) returns -16777214     by all-other-usernames-were-taken   .
#133   PUT with variable length string element UDT (binary)    by FellippeHeitor bug
#131   +=-= etc. operators     by omerhizai404   feature request <wontfix> CLOSED
#126   AutoUpdate for include file     by Richard   feature request
#124   Type suffixed constants not processed by READ statemente     by dkearns
#116   QB64 quits on MacOS Big Sur and won't open again     by loudar CLOSED
#109   problem passing _mem(var) as an argument to a subroutine     by BlameTroi
#104   Unable to Open Source Code     by GeorgeMcGinn
#101   _KEYDOWN shift bug causing keys to stick pressed down     by johannhowitzer bug input handling
#99   OPEN COM flow handling paramters are fragile     by flukiluke bug
#93   QB64 is Slow in Processing     by Barthdry CLOSED
#91   not in repositories     by n3gwgdkearns feature request
#89   PRINT USING HEX output   by Richard   feature request   CLOSED
#88   Option no Title Bar when not in FullScreen mode   by Richard   feature request   CLOSED
#87   AudioUnitInitialize failed   by pforpond
#86   Set Start directory same as file directory   by omerhijazi404   feature request   CLOSED
#85   REDIM (no _PRESERVE) not clearing _BYTE values from array defined AS UDT   by FellippeHeitor   CLOSED
#83   TUI scales to 1/4 of the console window on macOS   by jedixo
#81   Proposal to remove the cberbit.tiff file   by flukiluke   feature request   CLOSED
#79   ENVIRON$() does not work as expected in a for loop when using long DATA statements   by abusetech   bug CLOSED
#78   _CINKEY$   by PQCraft   feature request input handling
#77   Wrong scaling on MacOS   by emlyn
#76   Windows 10 Reqired Program to be ran as Administrator   by RCcola1987
#74   Linux console bug   by PQCraft
#73   binary F##/CHR font format support for text modes   by TheRealHamtaro126   feature request
#72   Implement falcon.h functionality/fixes into QB64   by FellippeHeitor   feature request
#71   Improvments to print unicode content   by douyuan   feature request
#70   Pure TUI mode   by mdpkh   feature request   CLOSED
#69   Cannot see full TUI, weird scaling   by jagot
#68   Code-collapsing/expanding   by loudar   feature request
#67   OPTION EXPLICIT: with paramters   by loudar   feature request   CLOSED
#66   -q flag for quite compilation   by flikiluke   feature request   CLOSED
#63   Length of SUBs / FUNCTIONs in F2 view   by loudar   feature request
#65   _NEWIMAGE color mode additions   by ParzivalWolfram   CLOSED
#64   Variable length strings in types don't compile on macOS   by flukiluke   bug   CLOSED
#62   Crash: abort with empty random access file with fields   by twogood   bug
#61   Script not found error   by elasmojs   CLOSED
#60   QB64 Linux Mint Debian Edition   by ghost
#59   Ability to remove asynchronus.   by real2two   feature request   CLOSED
#58   Tui library   by patrickw99   feature request   CLOSED
#57   Clarify situation about Microsoft copyright on example programs   by ssb22   CLOSED
#56   Modifying an array element in a SUB   by ghost   feature request   CLOSED
#54   PAINT's tiling pattern string   by ghost   feature request   CLOSED
#53   Alternate TUI layout   by lighth7015   feature request
#52   $VERSIONINFO missing product version   by SpriggsySpriggs
#51   TYPE within a TYPE changing string to numerical   by SpriggsySpriggs   CLOSED
#50   Popup showing available elements in a TYPE declaration   by SpriggsySpriggs   feature request
#49   _MOUSEMOVEMENTX and _MOUSEMOVEMENTY don't work.   by PQCraft
#47   Extend to UHD and 5K test for Mac computers.   by familygw   feature request   CLOSED
#46   ACCEPTFILEDROP not working when elevated (run as administrator)   by SpriggsySpriggs   CLOSED
#44   Mac: $PATH issue when converting QB4.5 files in another directory   by johnkharvey   CLOSED
#42   WPF Message Boxes in QB64!   by SpriggsySpriggs  CLOSED
#39   Not sure how to use INKEY$ with _DEST _CONSOLE   by SpriggsySpriggs   CLOSED
#36   Maximize button not functioning as expected   by SpriggsySpriggs
#35   Update Wiki Page for SHELL (function)   by SpriggsySpriggs   CLOSED
#34   Make a CLIPBOARD$() array since Windows 10 has Clipboard   by SpriggsySpriggs   feature request
#33   ALL Sound not working on OSX/macOS   by Pirachy  CLOSED
#32   Clipboard contents my lead to QB64 to crash at startup on MacOS   by Lisias   CLOSED
#31   Cannot use $NOPREFIX and $COLOR in the same code   by SpriggsySpriggs   CLOSED
#29   Allow sound data to be accessible (_MEMSOUND?)   by FellippeHeitor   feature request
#16   EXIT-Code   by bhuebschen   CLOSED
#15   Metacommand to disable program-termination prompt   by bhuebschen   CLOSED
#14   Compilation for macOS devices with Retina displays needs attention   by FellippeHeitor   bug   CLOSED
#12   Optional parameters to SUBs/FUNCTIONs   by QB64Bot   feature request  low priority   CLOSED
#11   Allow definable keyword prefix   by QB64Bot   feature request   CLOSED
#10   SHELL command requiring cmd /c in some scenarios   by QB64Bot   glitch   CLOSED
#9    Compile with -O2 by default   by QB64Bot   enhancement   CLOSED
#8     Allow SHELL to capture stdout of command   by QB64Bot   enhancement
#7     Improve resolution of paths for DECLARE LIBRARY   by QB64Bot   enhancement
#6    `_STDOUT`,`_STDERR` methods?   by QB64Bot   feature request
#5    Array in User Type   by QB64Bot   feature request
#4    No warning is shown when non-_MEM type variable is used with some _MEM functions   by QB6Bot   glitch   CLOSED
#3    `REDIM _PRESERVE` multi-dimensional array shifts data   by QB64Bot   bug
#2    *WIP* Make-based build system   by QB64Bot

Previous Topic Title
v1.5 128 bit (and beyond) math
v1.5 multi instance launch problem  https://github.com/QB64Team/qb64/issues #142
QB64v1.5 AutoUpdate for include file  https://github.com/QB64Team/qb64/issues
QB64 v1.5   Auto update for compiling when include file changed
QB64 v1.5   reply to SpriggsySpriggs challenge answer (re bytes free)

(Previous Topic Title … Fellippe's interpreter option)
QB64 v1.5 Feature Request - interpreter options + other things (quiz QB64 stats))
QB64 v1.5 Feature Request - (from archives) interpreter  + ...(quiz QB64 stats)) 
QB64 v1.5 Feature request - A meaningless request for IDE
                                        - Meaningless IDE request,multiwindows,[abandoned, outdated and now likely malicious qb64 dot net website - don’t go there] stats
                                        - new string functions
                                        - new string functions, multi-variable FOR-NEXT
QB64 v1.5 Feature -new string fns, multi-var FOR-NEXT,autofill block statements)
QB64 v1.5 -new string fns,multi-var FOR-NEXT, autofill block statements, var debug)
QB64 v1.5 stringFns,multi-varFOR-NEXT,autofill░statements,debug, IDE auto refresh
QB64 v1.5 $Fns,multivarFOR-NEXT,autofill░statements,debug,IDErefresh, TITLE bar
QB64 v1.5      MOVe   &   REName    statements for files and directories
QB64 v1.5 MOVE & RENAME statements files/directories,   IDE hotkey expansion
QB64 v1.5 MOVE & RENAME files/directories,IDE hotkey expansion,   Win KB->bytes
QB64 v1.5   Statement(s) force program run on selected physical/logical processors
QB64 v1.5   Additional Code Select Options (for Forum Reply / New Topic)

QB64 v1.5   IDE help

QB64 v1.5   PRINT USING HEX output   (https://github.com/QB64Team/qb64/issues)

Would be useful to have Fellippe's interpreter as part of QB64 even if for only testing out small code fragments at a time.

[freetrav]

There's no +1 button on the forums!  I need a +1 button!

[TempodiBasic]

Hi
now I can say my thought...

the  Fellippe's interpreter of Qb64 is very fun! It can be cool!

Generally
I think that it is not so good to use an interpeter like in the old old old times...
I remember that using the Qbasic.exe  (an interpeter that cannot make and exe)
I was used to write quickly some code and press F5 without make any project of code...
so I think that an immediate interpreter,  I know  only Basic like this,
let you take easily the habit to project poorly your application...
and in this point of view I think about this affirmation
https://www.brainyquote.com/quotes/edsger_dijkstra_201164
https://softwareengineering.stackexchange.com/questions/7747/do-you-think-that-exposure-to-basic-can-mutilate-your-mind
an immediately interpreter let you prefer the "Type and Run" despite the think, plan, type and run.

So the presence of interpreter into the QB64IDE as a fix part and not as an optional part that can be activated on request of user  can add quicksand to the IDE thinking about who is not a veteran of programming but he is just a beginner.
:-) who beginner driver doesn't drive a spider car if he has available it?

Reference
Spider https://rcs.cdn.publieditor.it/w640/M1313_00.jpg
https://rcs.cdn.publieditor.it/w640/M1137_00.jpg

[bplus]

Is that what you guys are looking for, an Immediate Window?

So you can test a snippet of code.

[freetrav]

Is that what you guys are looking for, an Immediate Window?

So you can test a snippet of code.

That's part of it; another part of it is for scribbling up quick-and-dirty one-offs - the kind of thing that other people might do in bash, powershell, python, windows batch, etc.

[bplus]

That's part of it; another part of it is for scribbling up quick-and-dirty one-offs - the kind of thing that other people might do in bash, powershell, python, windows batch, etc.

When I first came back to BASIC in Sept, 2014, I used SmallBASIC, pure interpreter, Types are automatic including User Defined. For "scribbling up quick-and-dirty one-offs", you could do worse + it's in our familiar Basic that is also branch off from QB45. But, I don't know I do these all the time with QB64 now too.

QB64 IDE Help does math, did you know?

[dbosely]

What I would like is the ability to step through my running code, and check variables as they are encountered.  I have programmed for over 40 years (Now my age is 84 and still programming) and I have used many of the flavors of Basic (Commodore, GWBasic, QB, QB 4.5, VB For Dos, VB 3.0, 4.0 and 6.0, etc).  The ability to step-through code as part of the IDE is a tremendous help when debugging an app.  Also the ability to set break points and check the state of variables during a 'run' greatly facilitates debugging.  I really, really miss that in QB64!

As a work-around I insert code to display variables along with a 'Sleep' statement. A poor solution, though.

Just my two cents.

Darrell

[bplus]

Hi dbosely,

Wow 84, cool! There is now a $CONSOLE option, Ashish was using to good effect in Smart Snake thread.

Oh Fellippe has made vWatch for watching variables as you step through program but for me, a little tricky to figure out.

VB for DOS one of my favorites.

[Richard]

Prior to QB64 I used Microsoft PDS 7.1 (essentially an upgrade from QB45) which had the features dbosely mentioned.

Overall, if programming without the very nice improvements of QB64, I still prefer PDS 7.1 because of the above features mentioned. In the early days I used to write the code on paper first - but now I always keyboard the code instead. Whereas on paper I could put "circles and arrows", I can rapidly do changes (with comments) on screen - and save some trees in the process.

I have briefly used Fellippe's  vWATCH, but personally found it to be lacking for my taste, beside the fact that it is not automatically integrated as part of the QB64 package.

Yes QB64, by its "C" nature apparently has to be  "compiled first", whereas PDS 7.1 was interpreted based (but automatically produced compiled exe). However because QB64 as a guess has been "run" millions of times, it is justifiable to have "advanced debugging capabilities - such as program tracing, watchpoints etc. vWATCH sort of showed it was possible to have these debugging features - maybe vWATCH could be integrated into the IDE as default (option selectable?).

It was interesting to read, from so long ago, that when Galleon was developing QB(64) in the very early days - at one stage he actually used PDS 7.1 to create the QB(64) builds - but eventually PDS 7.1 could not handle the greatly increased QB(64) files. However, sadly Galleon did not want to, it seems, incorporate advanced features of PDS 7.1 and stuck only with QB45 (QB) features (which are a subset of PDS 7.1).

There will be those who would argue that the program should be "well thought out" before keying in - however in my case, where programs run into thousands of lines long it is impossible to predict all programming situations and the result being an massively "inflated" program size from my original program concepts. 

I have experimented  running two instances of QB64 simultaneously (on the one computer) - the first instance was my original program (this instance ONLY for program editing) - the second instance "imported" the program, did some minor changes (such as putting in "Line Numbers", "Trace Points", etc) and ran this slightly modified program and gave me a "TRON-TROFF" simulation (with vast improvements such as in addition to showing line numbers (which correspond to the IDE line numbers of the first instance of QB64 (i.e. the "editing" instance) - it also displayed the actual program line code as well, etc). This approach was quite workable for me.

[CBTJD]

For my two cents...
Being able to quickly enter a snippet of code and run it through an interpreter instead of compiling in order to gain a better understanding of certain commands or constructs sounds very appealing.

[STxAxTIC]

I'm with Tempodibasic on this one - I like the concept of being able to pause what code you're working on, go to another area, and quickly test some short code without disrupting your flow... Don't we all like that? Hopefully nobody is dunning DOS anymore, and we all have a system that can multitask, so honestly it would be redundant and unnecessarily difficult to implement and maintain anyone's interpreter as embedded in the IDE. Just pop open a new window and have a ball, right?

[Richard]

In theory it may sound nice to just try a "snippet of code" in a "stand alone" testing environment.

In the case of "dynamic testing program enhancements" (for want of a better phrase) - it would be time consuming and fairly difficult (I claim) to mimic the effect (as say  "static testing program enhancements" - by way of independent snippets). For my programs, the program is still running (until it reaches preset "breakpoints", "flags", etc) and various files are open, arrays preloaded, etc - (and can take some hours to reach certain conditions).  Independent snippets, in my case, would need to access these same "opened" files,etc - and the same file, etc being accessed (and open) at the same time by two program instances (same calling program or different calling programs) NEVER plays well for me. If I close my program, to close the opened files, etc I may have to restart my long-running program using initial conditions.

In my case with a program thousands of lines long, "new things" need to be done/tested after say a thousand lines of code.  To replicate the effect to be tested into a stand alone code snippet might require the snippet to be many hundreds of lines (of course everyone would have varying degrees of code snippet sizes).



If one was simply wanting to know "what if I did …" say     Print &HFFFFFFFF& AND OR NOT XOR NEG &HFFFFFFFF&&      (as a silly example) then an independent code snippet environment (one line long in this case) may be sufficient.

[STxAxTIC]

I'm totally with you man - so all I can say is keep his interpreter open in a second window.

I'm not being cheeky, either. This is for a deeply technical reason. I have no clue what I'm really saying, but it makes a lot of sense. So QB64 is compiled, sent off to C++-land, where your original source code, at run time, is basically meaningless. Without something like vWATCH, you can't pause and go line-by-line in QB64 code like you could in the old days. How does vWATCH achieve this? A whole lot of work. It's not taking advantage of anything native in QB64 that lets you interrupt and go line by line.

Why rant about that at all? This reason: If we attach an interpreter, it'll be a separate animal than QB64 itself. Yes, an embedded interpreter could be maintained to do the same behavior as QB64, basically doubling Fellippe's work (or worse). Or perhaps combining the interpreter with vWATCH technology, one can conceive of a borg-cube-like IDE that lets you pause your code, make changes as its going, run snippets as you've paused - all that. It can be done. I can even see it happening with what we already have.

But we're doing some Tower of Babel stuff there. It might get too high, and God may come down, smash the project, and send us our separate ways, speaking other languages. How fitting an image.

[Richard]

Thanks STxAxTIC for your reply.

I will give Fellippe's vWATCH another "try" (and also try to refine my dual QB64 instance approach).

Previously, whenever I had used vWATCH it was always only when a new "version" of QB64 was released. For some reason I always had trouble installing vWATCH - the problem being that the vWATCH files did not go to the proper folders.

Could Fellippe please tell me exactly where each vWATCH file has to go (in the QB64 v1.4 folder set) - so that I can double check that the vWATCH unzipping process was correct for me? Often I was one or two folder levels out preventing proper running of vWATCH.

Could Fellippe please have vWATCH as part of the QB64 zip file - so that it is guaranteed that vWATCH is installed in the correct folders (even if QB64 does not access vWATCH)?

Some thirty years ago, PDS 7.1 was released and I am still impressed with all that it could do (though pales in comparison with QB64) and to work with 640K RAM. Like so many MS products, "if it works then replace it with something that does not work as well". It is difficult to find a working computer (x16) so to run PDS 7.1 I use DOSBox (but there are limitations).

Imagine if the present computer hardware advances we take for granted today were present some thirty years ago … We might have had PDS 10.1 today, using the programming methodology of PDS 7.1 with even many more features than QB64 present and in the pipeline.

I will, for myself, follow the PDS 7.1 "Tower of Babel" approach (but using existing QB64 features as the backbone - by way of dual instances of QB64). The "PDS 7.1 Tower of Babel" did not really fall down - just got "lost" in time. Who knows, maybe one day QB64 will take on some "proven" programming concepts from PDS 7.1.

[Richard]

Just some further information which may be of interest to some.

Below is a "Dynamic HTML file" (I do not know how to convert this file to a "Static HTML file) - so it will not be "pretty" (sorry).

 

   
News:
Instructions for creating Android Apps:
http://www.[abandoned, outdated and now likely malicious qb64 dot net website - don’t go there]/forum/index.php?topic=13162.0

Home
Help
Search
Login
Register

QB64 Community »
General »
Beginner's Help (Moderators: Galleon, OlDosLover, SMcNeill, Kobolt) »
Testing is slowed down by creating the executable every time

« previous next »
Print
Pages: [1]
 Author Topic: Testing is slowed down by creating the executable every time  (Read 1510 times)
ascii
Newbie

Posts: 25

 
Testing is slowed down by creating the executable every time
« on: January 05, 2016, 06:22:02 am »

Every time I change a single thing in my program, it creates an exe if run. It takes a 'lot' of time. In a previous BASIC, such wasn't the case. It ran instantly.
Can't I skip making the exe?

 Logged

Johny B.
QB64 Partner Site Owner
Hero Member

 
Posts: 1539

 
Re: Testing is slowed down by creating the executable every time
« Reply #1 on: January 05, 2016, 06:25:50 am »

Short answer: nope, that's just not the way QB64 works. It's purely a compiler.

I'm sure someone else will give you the longer answer.

 Logged

DonW
Jr. Member

Posts: 70

 
Re: Testing is slowed down by creating the executable every time
« Reply #2 on: January 06, 2016, 12:00:32 am »

I agree with ascii...to be truly useful in debugging a complex program, QB64 needs an interpreter in addition to a compiler.

I have taken complex QB45 programs that run/compile just fine with QB45.  But often times when I load the same .bas code into QB64, I get an "OK", however, when I compile the code, the .exe often times executes with improper results.  There seems to be no way to debug things in a manner like the QB45 interpreter.

 Logged

notemeal
Full Member

 
Posts: 160
I think I may have coded myself into a comma,,,

 
Re: Testing is slowed down by creating the executable every time
« Reply #3 on: January 06, 2016, 04:26:17 pm »

Maybe the solution is to get a more capable machine.  I got a used Toshiba laptop running Windows 10 with an older core i7-2670QM processor, maxed out the memory from 6 to 8 gb and dropped in a 256 gb SSD. This thing kicks butt.  I have been doing some work on a program that is about 2300 lines and an attached library of about 700 lines giving a total of about 3000 lines.  I think that each time I change something in the program, with the exception of when I am editing (in other words after editing the current line is done), it reloads the library in case it has changed.  That is where the large memory comes into play as the library is already in a buffer in memory and only takes a fraction of a second to load.  You know your program is getting large when, upon hitting F5,  the status line reads "Checking program   (editing will cancel request)" or something like that.

When I hit F5 to recompile and run the program, it takes about 2 or 3 seconds which, in my book is acceptable.   If I do that a second time right after the program is run, it runs instantly as both the program and library are in memory and there is an almost unnoticeable lag.  If it were 10 or 15 seconds or more, that would be unacceptable.

Contrast that with an older HP laptop I have running XP with 1 gig of memory and a regular 120 gb HDD.  Under the best of circumstances where I am running only QB64 there is a noticable lag even when I am just editing a large program.  So just for laughs, in order to consume a bunch of memory, I fired up Chrome (Chrome eats up memory quicker than anything else) and had less memory available.  It got to the point that, after each edit, there was a noticable lag before I could do anything else!  For even more laughs I loaded up enough tabs in Chrome so that I only had a few megabytes of Physical Memory left and I knew that the machine would have to use virtual (hard drive) memory.  It took well over a minute to compile and run!  Now, THAT is a pain in the rear, especially when you remember that one little edit your forgot before pushing F5 which means that you have to edit and recompile it again.  I would find programming in QB64 much less enjoyable on that machine.

So the upshot of this is that, if you could find a good laptop  I got the Toshiba for about $200 and paid $30 for the memory and about $90 for the SSD you could have a machine where it really makes no difference if you are running an interpreted or compiled BASIC.


 Logged
There would be a signature here but the signature-generating app is offline due to a cloud malfunction and various TCP/IP proxy anomalies due to the UN name server errors on the various internets.

bobtheunplayer
Full Member

 
Posts: 134
I'd rather be coding.

 
Re: Testing is slowed down by creating the executable every time
« Reply #4 on: January 06, 2016, 07:42:00 pm »

GCC itself is pretty fast.  I've got some C programs that are several thousand lines in size spread out over many files and I use Make to compile after changes and at most its 3 seconds to compile.

With QB64 the time consuming issue is the translation of QB64 code into C++ code then GGC compiles the translator output.  If the translator could be further optimized for speed, the perceived compile performance would be significantly improved.

Code: [Select]
--------------------    -------------------    -------    ----------
| QB64 Source Code | -> | QB64 Translator | -> | GCC | -> | Binary |
--------------------    -------------------    -------    ----------
 
But for now, you might take notemeal's advice and get a faster computer (>= i5 and SSD).

~b

 Logged

Johny B.
QB64 Partner Site Owner
Hero Member

 
Posts: 1539

 
Re: Testing is slowed down by creating the executable every time
« Reply #5 on: January 06, 2016, 08:28:27 pm »

When the IDE says "..." or "checking program" it's producing C++ code; when it says "creating .exe file" or "creating executable" it's running g++.

 Logged

notemeal
Full Member

 
Posts: 160
I think I may have coded myself into a comma,,,

 
Re: Testing is slowed down by creating the executable every time
« Reply #6 on: January 06, 2016, 09:23:21 pm »

Thanks for that Johnny B Good.  I was wondering about that, especially the "...".  Why not just indicate "Making C++ Code"...
Also, what is g++  (that is the first time in my life that I have used a smiley and the reason is my question mark is not working as I accidentally spilled some coffee in that area of the keyboard - never drink and code or comment - I should just sign off and put the machine in the dryer on fluff for half an hour...)  Also, I tried the alt key code thing and it did not work.  Funny thing is, I always got it to work under DOS with the 3-digit codes but for whatever reason I can't with the Windows 4-digit codes.

 Logged
There would be a signature here but the signature-generating app is offline due to a cloud malfunction and various TCP/IP proxy anomalies due to the UN name server errors on the various internets.

bobtheunplayer
Full Member

 
Posts: 134
I'd rather be coding.

 
Re: Testing is slowed down by creating the executable every time
« Reply #7 on: January 06, 2016, 10:52:17 pm »

Quote
...what is g++...


g++ is the GNU C++ compiler.
http://gcc.gnu.org/

 Logged

Dark Star
Hero Member

 
Posts: 1029

 
Re: Testing is slowed down by creating the executable every time
« Reply #8 on: January 07, 2016, 12:00:50 am »

As far as I am concerned (take this as you will any other opinion), the extra compilation time is simply the price we pay for having access to the full potential of a modern 32 or 64-bit machine with BASIC.  As has been mentioned, intelligent use of _TITLE statements, PRINT and SLEEP, custom-written debug files, etc. more than makes up for the lack of ability to assign breakpoints and such.  Don't get me wrong; I love breakpoints, but I can live without them.  If I were more familiar with C/C++ and the translation of BASIC to C++ then I might be able to make use of gdb or other means, but for a hobbyist programmer such as myself the above-mentioned methods are more than sufficient.  What must change is the programmer's state of mind.  It's almost like the transition from driving a stick shift to an automatic car, you give up control, but you gain ease-of-use.  To put it another way, do any of us really want to go back to the limitations of DOS and QB45?  Hell no.   

 Logged

ascii
Newbie

Posts: 25

 
Re: Testing is slowed down by creating the executable every time
« Reply #9 on: January 07, 2016, 12:10:34 am »

Quote
Maybe the solution is to get a more capable machine.

I already have an 8-core i7 with 16GB and a 250GB SSD. But I don't use Win10; I use Win7. I really see no pro's for me, in Win10.

In fact, I had QB64 reside on my HDD; not on the SSD. I just moved it to the SSD. Result: the creating of the exe isn't faster (at the moment it is even slower). I have a small program (maybe 50 lines of code); on the HDD it takes about 3 to 6 seconds to create the exe (I don't know why it differs); on the SSD it took 5 seconds (well, I only tested once on the SSD).
Can I disable graphics in QB64 itself, so that, when creating the exe, it will go faster?

 Logged

notemeal
Full Member

 
Posts: 160
I think I may have coded myself into a comma,,,

 
Re: Testing is slowed down by creating the executable every time
« Reply #10 on: January 07, 2016, 01:34:14 am »

@american standard code for information interchange:

I don't know why you would have any lag at all with your machine specs. Yes there is always a momentary lag but that is necessary with the translation and compilation(s) that take place when you hit F5.  Maybe you were just too used to using something like QB45 where the program did indeed run instantaneously as it was dynamically translated to binary and was resident all the time on the machine.  There is a subtle but important distinction between instant and a lag of even a couple of seconds.  All I can say is that, over time, I have got used to that second or two lag and I am in agreement with Dark Star that, given the new bells and whistles that come with QB64, I do not even think of using QB45.  And yes, breakpoints and watchpoints etc were great but I still feel that, given the capabilities of QB64 we come out ahead.  Maybe we can take up a collection to buy enough pizza and coke to lock up one of the resident geniuses (4+ stars) on this board and force them to code a credible Debug menu for the QB64 IDE.

@Dark Star
It never occurred to me to use _TITLE as a way of dynamically displaying variable values much the way watchpoints were used in QB45.  That was the kind of thing I was looking to accumulate in the thread I started a few days ago "for noobs like me".  I saw it as a way to transition noobs from say QB45 to QB64 and kind of fill in oh so missed breakpoints and watchpoints.

Finally, in other news, even after tossing this laptop in the dryer for a half hour, my arrow keys and question mark slash slash key is not working so I can pose no further questions until I get the keyboard I ordered off eBay.  The major change I noticed is that my screen is now oval...

 Logged
There would be a signature here but the signature-generating app is offline due to a cloud malfunction and various TCP/IP proxy anomalies due to the UN name server errors on the various internets.

ascii
Newbie

Posts: 25

 
Re: Testing is slowed down by creating the executable every time
« Reply #11 on: January 07, 2016, 02:34:40 am »

Quote from: notemeal on January 07, 2016, 01:34:14 am
Finally, in other news, even after tossing this laptop in the dryer for a half hour

What kind of dryer do you use? When a family member dropped a photo camera in a river, I used a hair dryer on it for a few hours. It functioned reasonably well, after.
But maybe something burned through, in your case.

On topic:
I just did a test with this program:
 print "Hello, world"
It took about 11 seconds before it showed result.
Another run: about 25 seconds!
« Last Edit: January 07, 2016, 02:42:26 am by ascii »
 Logged

notemeal
Full Member

 
Posts: 160
I think I may have coded myself into a comma,,,

 
Re: Testing is slowed down by creating the executable every time
« Reply #12 on: January 07, 2016, 04:40:27 am »

Wow, there is something definitely wrong there.  I actually copied an pasted your code ( print "Hello, world" ) in a fresh QB64 window and literally timed it.  It ran a fraction after 3 seconds and instantly the second time I pressed F5.  Do you have any other machines around where you might be able to compare times (question mark)

As for the dryer thing, I was merely trying to bring a moment of levity to an otherwise staid, formal setting.  The spill part is true, the dryer is not.  I hope that the forum gods will let it slide as I don't want to get locked up somewhere and forced to code until I come up with a Debug item for the QB64 IDE...

 Logged
There would be a signature here but the signature-generating app is offline due to a cloud malfunction and various TCP/IP proxy anomalies due to the UN name server errors on the various internets.

DonW
Jr. Member

Posts: 70

 
Re: Testing is slowed down by creating the executable every time
« Reply #13 on: January 07, 2016, 12:08:59 pm »

Quote
What must change is the programmer's state of mind.  It's almost like the transition from driving a stick shift to an automatic car, you give up control, but you gain ease-of-use.  To put it another way, do any of us really want to go back to the limitations of DOS and QB45?


The only real limitation to QB45 was memory limitations, not coding/debugging.  Of course, one could not use it for "true" windows applications, but for creating applications for doing real work, it was just fine.

QB64 has long been promoted as being a QB45 compatible compiler as in the following banner on the home page:
Quote
Over 50 years of BASIC compatibility and (as close as we can get without being an emulator like DOSBOX) 100% compatible with MS QBASIC/QB4.5 code


However, I have found this not to be entirely true.  I have been able to take some of my QB45 programs, compile them with QB64, and see that .exe's work as expected.  However, I have also experienced instances of loading very large and complex QB45 programs, get an "OK" in the IDE (which I take means no syntax errors), but when I compile them, they don't execute properly.  I don't get any run-time errors...they just don't work correctly and give me extraneous results.

So if there is a way to set break points and examine variable values in real time (like with the QB45 interpreter) in order to debug incorrect results, I'd appreciate someone pointing me to that methodology with QB64.  Thanks.

 

 Logged

bobtheunplayer
Full Member

 
Posts: 134
I'd rather be coding.

 
Re: Testing is slowed down by creating the executable every time
« Reply #14 on: January 10, 2016, 01:05:57 am »

Quote
I just did a test with this program:
 print "Hello, world"
It took about 11 seconds before it showed result.


Maybe you have a virus or something hogging up your resources?

I got a two-year-old macbook and a simple print "hello world" showed in about 2 seconds.

~b

 Logged

Print
Pages: [1]
« previous next »
QB64 Community »
General »
Beginner's Help (Moderators: Galleon, OlDosLover, SMcNeill, Kobolt) »
Testing is slowed down by creating the executable every time

 


SMF 2.0.3 | SMF © 2011, Simple Machines
XHTML
RSS
WAP2