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.
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 »
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
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
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 »
Programs (.BAS), Tutorials and Libraries ($INCLUDE, DECLARE LIBRARY, ...) »
Sample Programs (Moderators: Galleon, OlDosLover, SMcNeill, Kobolt) »
Return of the possibly useless interpreter
« previous next »
Pages: [1]
Author Topic: Return of the possibly useless interpreter (Read 620 times)
rks
Newbie
Posts: 34
Return of the possibly useless interpreter
« on: December 07, 2015, 09:47:22 am »
This is an interpreter I've written based (very) loosely on ASM, I dust it off occasionally and tinker with it, this is one of those occasions. I've also written an editor to go with it this time. Unzip it all in a folder, compile the interpreter with or without the editor and have at it. There are some demo scripts and a game. It's something to kill time with when things are slow.
r
sscript21.zip (39.36 kB - downloaded 63 times.)
« Last Edit: December 07, 2015, 02:08:59 pm by rks »
Logged
FellippeHeitor
QB64 Partner Site Owner
Hero Member
Posts: 1806
LET IT = BE
Re: Return of the possibly useless interpreter
« Reply #1 on: December 07, 2015, 10:23:39 am »
Looks like it was a lot of work. Everything worked as expected here. Congrats!
« Last Edit: December 07, 2015, 10:34:36 am by FellippeHeitor »
Logged
- InForm for QB64 http://qb64.org/inform
- vWATCH64 (debugger for QB64) http://bit.ly/vWATCH64v1-103
- Games: http://bit.ly/2048_qb64 * http://bit.ly/ClonedShades_qb64source * http://bit.ly/2aqK866 * http://bit.ly/SpaceshipQB64 * http://bit.ly/2rD1pPP
FellippeHeitor
QB64 Partner Site Owner
Hero Member
Posts: 1806
LET IT = BE
Re: Return of the possibly useless interpreter
« Reply #2 on: December 07, 2015, 10:30:15 am »
You may want to correct line 94 on the script for Nightfall; it seems like it should read:
Code: [Select]
$rndm 2,12
« Last Edit: December 07, 2015, 10:35:46 am by FellippeHeitor »
Logged
- InForm for QB64 http://qb64.org/inform
- vWATCH64 (debugger for QB64) http://bit.ly/vWATCH64v1-103
- Games: http://bit.ly/2048_qb64 * http://bit.ly/ClonedShades_qb64source * http://bit.ly/2aqK866 * http://bit.ly/SpaceshipQB64 * http://bit.ly/2rD1pPP
rks
Newbie
Posts: 34
Re: Return of the possibly useless interpreter
« Reply #3 on: December 07, 2015, 01:14:07 pm »
You are correct, there are several $rdm's that should have been $rndm, that was a late change and I forgot about it. Thanks.
r
Logged
rks
Newbie
Posts: 34
Re: Return of the possibly useless interpreter
« Reply #4 on: December 07, 2015, 01:34:35 pm »
I've posted a corrected .zip file.
Logged
Pages: [1]
« previous next »
QB64 Community »
Programs (.BAS), Tutorials and Libraries ($INCLUDE, DECLARE LIBRARY, ...) »
Sample Programs (Moderators: Galleon, OlDosLover, SMcNeill, Kobolt) »
Return of the possibly useless interpreter
SMF 2.0.3 | SMF © 2011, Simple Machines
XHTML
RSS
WAP2
Thinking of other possible features for 1.5, here is one. How about having it automatically minimize the QB64 window when you run the program and then returns when you exit the program.OOh, I like it! Sounds like a good idea.
Something I thought of some may also like. Just a thought.
Quiz Question:-
From the old [abandoned, outdated and now likely malicious qb64 dot net website - don’t go there] days what author-topic was most viewed (and approximately how many views).
The answer for the topic title does not have to exactly match and a tolerance of +/- 25% (maybe more) for the views given.
If a topic title eg "SDL" is given and this title (or very similar) has more than one author, then the post with the higher number of views is taken.
To allow time for a few replies, I plan to tell the answer say at the end of June (if there are any entries).
There is "no reward" for the most correct answer.
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 »
Programs (.BAS), Tutorials and Libraries ($INCLUDE, DECLARE LIBRARY, ...) »
Sample Programs (Moderators: Galleon, OlDosLover, SMcNeill, Kobolt) »
Novelty Interpreters (tiny)
« previous next »
Pages: [1] 2
Author Topic: Novelty Interpreters (tiny) (Read 667 times)
bplus
Hero Member
Posts: 622
B = B + _
Novelty Interpreters (tiny)
« on: July 29, 2017, 09:23:57 am »
Hi all,
This subject was started by Aureal at the QB64.org with the BrainF*** (BF) Interpreter.
Well I have taken this tiny interpreter idea and ran with it. Now I CAN write a program for this IEN (but not BF!).
Maybe you will be as amused as I.
Here is what the Hi Lo Guessing Game looks like for IEN Interpreter. Most of the Cn's are just printing characters and so take up allot of room in the program.
Code: [Select]
P
Z100 M4 Z1 A0 F3
A4 B3 * M3
Z2 A0 B3 F3
Z1 A0 B3 + M3
[ C 69 C 110 C 116 C 101 C 114 C 32 C 97 C 32 C 103 C 117 C 101 C 115 C 115 C 32 C 102 C 111 C 114 C 32 C 109 C 121 C 32 C 110 C 117 C 109 C 98 C 101 C 114 C 32 C 98 C 101 C 116 C 119 C 101 C 101 C 110 C 32 C 49 C 32 C 97 C 110 C 100 C 32 C 49 C 48 C 48 C32 ?4
A4 B10 =
I
X
N
A4 B3 >
I
C 72 C 105 C 103 C 104 P
E
<
I
C 76 C 111 C 119 P
E
C 82 C 105 C 103 C 104 C 116 C 33 P
X
N
N
P
]
This is full of tabs, spaces, line feeds to make it readable (well... easier) for humans. These are all stripped before the IEN Interpreter starts it's execution. IEN only works with one-liners ;-)) albeit they can be quite long!
Here is the current complete package for this ever evolving idea. My next thing will be string handling and comments.
Let me know what you think or ideas,
Mark
PS (Append): BTW, IEN stands for Is Everything Number? because that is all IEN can handle. To print text, you have to use the C command with the ASC number for the letter/digit/symbol. Letter by letter labels are displayed, yikes! (that part of things still not fun enough, YET!).
Novelty IEN Interpreter.zip (1239.13 kB - downloaded 21 times.)
« Last Edit: July 31, 2017, 07:47:55 am by bplus »
Logged
Will you still love me, will you still need me, when I'm (QB) 64?
bplus
Hero Member
Posts: 622
B = B + _
Re: Novelty IEN Interpreter
« Reply #1 on: July 29, 2017, 12:55:02 pm »
I better post the code so you don't worry it's too long. ;-))
Code: [Select]
'IEN Interpreter.bas for QB64 fork (B+=MGA) 2017-07-28 new name
RANDOMIZE TIMER
_TITLE "IEN Interpreter for QB64"
'for directory stuff
CONST ListMAX% = 20
COMMON SHARED dirList$()
COMMON SHARED DIRCount% 'returns file count if desired
DIM dirList$(ListMAX%)
CONST numChars$ = "-.1234567890"
CONST cmdChars$ = "WC?ABZMFIENP[X]%^/*~+=><()!&|"
CONST allChars$ = numChars$ + cmdChars$
CONST memsize% = 20000
COMMON SHARED memory#()
COMMON SHARED source$, code$, err$
DIM memory#(memsize%)
WHILE 1
source$ = ""
CLS
ERASE dirList$
DIM dirList$(ListMAX%)
loadDirList "IEN*.txt"
IF DIRCount% THEN
FOR i% = 1 TO DIRCount%
PRINT i%, dirList$(i%)
NEXT
PRINT: INPUT "Enter line number of IEN Filename you desire "; ln%
IF ln% < 1 OR ln% > DIRCount% THEN END
filename$ = dirList$(ln%)
OPEN filename$ FOR INPUT AS #1
DO
LINE INPUT #1, FLINE$
source$ = source$ + FLINE$
LOOP UNTIL EOF(1)
CLOSE #1
ELSE
PRINT "No IEN*.txt files found."
END IF
IF LEN(source$) THEN
PRINT source$
PRINT: INPUT "n(New) e(Edit) r(Run) k(Kill) q(Quits) other(Files)"; menu$
ELSE
PRINT: INPUT "n(New) q(Quits) other(Files)"; menu$
END IF
SELECT CASE UCASE$(LEFT$(menu$, 1))
CASE "N": INPUT "Enter a title, for *IEN + title + DATE.TXT* format "; tl$
dt$ = RIGHT$(DATE$, 4) + "-" + LEFT$(DATE$, 2) + "-" + MID$(DATE$, 4, 2)
fname$ = "IEN " + tl$ + " " + dt$ + ".txt"
OPEN fname$ FOR OUTPUT AS #1
CLOSE #1
SHELL "notepad " + fname$
CASE "E": IF LEN(source$) THEN SHELL "notepad " + filename$
CASE "K": IF LEN(source$) THEN KILL filename$
CASE "Q": END
CASE "R": IF LEN(source$) THEN CLS: runSource
END SELECT
WEND
SUB runSource
source$ = UCASE$(source$)
'let's clean the code up, check bracket balance
bktCnt = 0: ifCnt = 0: code$ = ""
FOR i = 1 TO LEN(source$)
char$ = MID$(source$, i, 1)
'check to see if this is a valid instruction character
IF INSTR(allChars$, char$) THEN
code$ = code$ + char$
'count brackets
IF char$ = "[" THEN bktCnt = bktCnt + 1
IF char$ = "]" THEN bktCnt = bktCnt - 1
IF char$ = "I" THEN ifCnt = ifCnt + 1
IF char$ = "N" THEN ifCnt = ifCnt - 1
END IF
NEXT
IF bktCnt THEN 'mismatched brackets
PRINT "Uneven brackets": SLEEP: EXIT SUB
ELSEIF ifCnt THEN
PRINT "Uneven I N counts": SLEEP: EXIT SUB
ELSE
PRINT code$ 'check
END IF
ERASE memory#
DIM memory#(memsize%)
cmd$ = "": ds$ = "": err$ = ""
FOR i% = 1 TO LEN(code$) 'loop through the code
c$ = MID$(code$, i%, 1) 'get the instruction we're on
IF INSTR("-.1234567890", c$) THEN ds$ = ds$ + c$
IF INSTR(cmdChars$, c$) OR i% = LEN(code$) THEN 'hit next command or end
IF cmd$ <> "" THEN 'execute unfinished command
d# = VAL(ds$)
'exec last cmd
SELECT CASE cmd$
CASE "A": memory#(1) = memory#(d#)
CASE "B": memory#(2) = memory#(d#)
CASE "Z": memory#(0) = d#
CASE "M": memory#(d#) = memory#(0)
CASE "F"
SELECT CASE memory#(1)
CASE 0: IF memory#(2) <> 0 THEN memory#(d) = 0 ELSE memory#(d) = 1
CASE 1: memory#(d#) = RND
CASE 2: memory#(d#) = INT(memory#(2))
END SELECT
CASE "W": PRINT memory#(d#);
CASE "C": PRINT CHR$(d#);
CASE "?": INPUT memory#(d#)
END SELECT
cmd$ = "": ds$ = ""
END IF 'if cmd <> ""
'handle current cmd
IF INSTR("WC?ABZMF", c$) THEN
cmd$ = c$
ELSEIF c$ = "I" THEN
IF memory#(0) = 0 THEN i% = Findi(i%)
IF err$ <> "" THEN PRINT err$: SLEEP: EXIT SUB
ELSEIF c$ = "E" THEN
i% = Findi(i%)
IF err$ <> "" THEN PRINT err$: SLEEP: EXIT SUB
ELSEIF c$ = "P" THEN
ELSEIF c$ = "X" THEN
bktCnt% = 1 'count the bracket we're on
i% = i% + 1 'move the code pointer to the next char
WHILE bktCnt% <> 0
'count nested loops till we find the matching one
IF MID$(code$, i%, 1) = "]" THEN bktCnt% = bktCnt% - 1
IF MID$(code$, i%, 1) = "[" THEN bktCnt% = bktCnt% + 1
i% = i% + 1 'search forward
WEND
i% = i% - 1%
ELSEIF c$ = "]" THEN ' end a loop if loop index is 0
bktCnt% = -1 'count the bracket we're on
i% = i% - 1 'move the code pointer back a char
WHILE bktCnt% <> 0
'count nested loops till we fine the matching one
IF MID$(code$, i%, 1) = "]" THEN bktCnt% = bktCnt% - 1
IF MID$(code$, i%, 1) = "[" THEN bktCnt% = bktCnt% + 1
i% = i% - 1 'search backwards
WEND
i% = i% + 1
ELSEIF c$ = "%" THEN
memory#(0) = memory#(1) MOD memory#(2)
ELSEIF c$ = "^" THEN
memory#(0) = memory#(1) ^ memory#(2)
ELSEIF c$ = "/" THEN
memory#(0) = memory#(1) / memory#(2)
ELSEIF c$ = "*" THEN
memory#(0) = memory#(1) * memory#(2)
ELSEIF c$ = "~" THEN
memory#(0) = memory#(1) - memory#(2)
ELSEIF c$ = "+" THEN
memory#(0) = memory#(1) + memory#(2)
ELSEIF c$ = "=" THEN
memory#(0) = memory#(1) = memory#(2)
ELSEIF c$ = "<" THEN
memory#(0) = memory#(1) < memory#(2)
ELSEIF c$ = ">" THEN
memory#(0) = memory#(1) > memory#(2)
ELSEIF c$ = "(" THEN
memory#(0) = memory#(1) <= memory#(2)
ELSEIF c$ = ")" THEN
memory#(0) = memory#(1) >= memory#(2)
ELSEIF c$ = "!" THEN
memory#(0) = memory#(1) <> memory#(2)
ELSEIF c$ = "&" THEN
IF memory#(1) <> 0 AND memory#(2) <> 0 THEN
memory#(0) = -1
ELSE
memory#(0) = 0
END IF
ELSEIF c$ = "|" THEN
IF memory#(1) <> 0 OR memory#(2) <> 0 THEN
memory#(0) = -1
ELSE
memory#(0) = 0
END IF
END IF
END IF ' ran into next command
NEXT
PRINT: INPUT "Run is done, enter to continue..."; temp$
END SUB
FUNCTION Findi% (i%)
cnt% = 1
FOR j% = i% + 1 TO LEN(code$)
c1$ = MID$(code$, j%, 1)
IF c1$ = "N" THEN
cnt% = cnt% - 1
IF cnt% = 0 THEN Findi% = j%: EXIT FUNCTION
ELSEIF c1$ = "I" THEN
cnt% = cnt% + 1
ELSEIF c1$ = "E" AND cnt% = 1 THEN
Findi% = j%: EXIT SUB
END IF
NEXT
err$ = "Could not find N"
END FUNCTION
' modified function from Help files
SUB loadDirList (spec$)
CONST TmpFile$ = "DIR$INF0.INF"
IF spec$ > "" THEN 'get file names when a spec is given
SHELL _HIDE "DIR " + spec$ + " /b > " + TmpFile$
Index% = 0: dirList$(Index%) = "": ff% = FREEFILE
OPEN TmpFile$ FOR APPEND AS #ff%
size& = LOF(ff%)
CLOSE #ff%
IF size& = 0 THEN KILL TmpFile$: EXIT SUB
OPEN TmpFile$ FOR INPUT AS #ff%
DO WHILE NOT EOF(ff%) AND Index% < ListMAX%
Index% = Index% + 1
LINE INPUT #ff%, dirList$(Index%)
LOOP
DIRCount% = Index% 'SHARED variable can return the file count
CLOSE #ff%
KILL TmpFile$
ELSE IF Index% > 0 THEN Index% = Index% - 1 'no spec sends next file name
END IF
END SUB
Logged
Will you still love me, will you still need me, when I'm (QB) 64?
bplus
Hero Member
Posts: 622
B = B + _
Re: Novelty SHN Interpreter
« Reply #2 on: July 31, 2017, 07:45:51 am »
SHN (Strings Handled Now) Interpreter coming soon!
Just have to work out the translation to QB64, piece of cake, right?
Looks to be about the same amount of commands believe it or not!
Functions will look more realistic and it will be as easy as eating pie to add your own (built-in ones, I mean).
Stay tuned...
Logged
Will you still love me, will you still need me, when I'm (QB) 64?
Ashish
Hero Member
Posts: 551
Eat.... Sleep.... CODE.... Repeat.....
Re: Novelty Interpreters (tiny)
« Reply #3 on: July 31, 2017, 09:04:50 am »
Nice work bplus! I like it!
Logged
if (Me.Success) {Me.Improve();} else {Me.TryAgain();}
aKFrameWork - http://bit.ly/aKFrameWork
p5js.bas - http://bit.ly/p5jsbas
Menu System - http://bit.ly/guiMenuBar
OpenGL Demos - http://bit.ly/openGLdemos
bplus
Hero Member
Posts: 622
B = B + _
Re: Novelty Interpreters (tiny)
« Reply #4 on: August 01, 2017, 09:02:42 pm »
Strings Now Handled
Code: [Select]
'SNH Interpreter.bas for QB64 fork (B+=MGA) 2017-08-01 trans
RANDOMIZE TIMER
_TITLE "Strings Now Hamdled, the SNH Interpreter (tiny)"
SCREEN 12: COLOR 7, 0: CLS
'for directory stuff
CONST ListMAX% = 20
COMMON SHARED dirList$()
COMMON SHARED DIRCount% 'returns file count if desired
DIM dirList$(ListMAX%)
CONST numChars$ = "-.1234567890"
CONST cmdChars$ = "W?ABCDFMIENP[X]%^/*~+=><()!&|"
CONST allChars$ = numChars$ + cmdChars$
CONST memsize% = 20000
COMMON SHARED m$()
COMMON SHARED source$, code$, err$
DIM m$(memsize%)
NotBeenHere% = 1
'PRINT "COMMAND$ = "; COMMAND$
'INPUT "OK, press enter "; temp$
WHILE 1
source$ = ""
COLOR 7, 0: CLS
ERASE dirList$
DIM dirList$(ListMAX%)
loadDirList "*SNH.txt"
IF _FILEEXISTS(COMMAND$) AND RIGHT$(UCASE$(COMMAND$), 7) = "SNH.TXT" AND NotBeenHere% = 1 THEN
filename$ = COMMAND$: NotBeenHere% = 0
ELSEIF DIRCount% THEN
FOR i% = 1 TO DIRCount%
PRINT i%, dirList$(i%)
NEXT
PRINT: INPUT "0 quits, Enter line number of SNH Filename you desire "; ln%
IF ln% < 1 OR ln% > DIRCount% THEN END
filename$ = dirList$(ln%)
ELSE
PRINT "No *SNH.txt files found."
SLEEP: END
END IF
OPEN filename$ FOR INPUT AS #1
DO
LINE INPUT #1, fline$
source$ = source$ + fline$
'PRINT fline$
'INPUT " OK, enter"; temp$
LOOP UNTIL EOF(1)
CLOSE #1
runSource
WEND
SUB runSource
ERASE m$
DIM m$(memsize%)
'note: anything above first {} is comment and ignored
'First get m$ (string memory array) loaded with data values
FOR i% = 1 TO LEN(source$)
c$ = MID$(source$, i%, 1)
IF c$ = "{" THEN
bs% = i%
WHILE MID$(source$, i%, 1) <> "}"
i% = i% + 1
IF i% = LEN(source$) THEN PRINT "Missing }": SLEEP: EXIT SUB
WEND
ix% = VAL(MID$(source$, bs% + 1, i% - bs% - 1))
IF ix% < 1 THEN EXIT FOR
b$ = "": i% = i% + 1
WHILE MID$(source$, i%, 1) <> ";"
b$ = b$ + MID$(source$, i%, 1)
i% = i% + 1
IF i% = LEN(source$) THEN PRINT "Missing ending ;": SLEEP: EXIT SUB
WEND
m$(ix%) = b$
END IF
NEXT
source$ = MID$(source$, i% + 1)
'OK now letters, digits or symbols from strings wont interfere with program code
source$ = UCASE$(source$)
'let's clean the code up, check bracket balance
bktCnt% = 0: ifCnt% = 0: code$ = ""
FOR i = 1 TO LEN(source$)
char$ = MID$(source$, i, 1)
'check to see if this is a valid instruction character
IF INSTR(allChars$, char$) THEN
code$ = code$ + char$
'count brackets
IF char$ = "[" THEN bktCnt% = bktCnt% + 1
IF char$ = "]" THEN bktCnt% = bktCnt% - 1
IF char$ = "I" THEN ifCnt% = ifCnt% + 1
IF char$ = "N" THEN ifCnt% = ifCnt% - 1
END IF
NEXT
PRINT "Code check: "; code$
IF bktCnt% THEN 'mismatched brackets
PRINT "Uneven brackets": SLEEP: EXIT SUB
ELSEIF ifCnt% THEN
PRINT "Uneven I N counts": SLEEP: EXIT SUB
ELSE
PRINT code$ 'check
INPUT "OK, press enter... "; temp$
CLS
END IF
cmd$ = "": ds$ = "": err$ = ""
FOR i% = 1 TO LEN(code$) 'loop through the code
c$ = MID$(code$, i%, 1) 'get the instruction we're on
IF INSTR("-.1234567890", c$) THEN ds$ = ds$ + c$
IF INSTR(cmdChars$, c$) OR i% = LEN(code$) THEN 'hit next command or end
IF cmd$ <> "" THEN 'execute unfinished command
d# = VAL(ds$)
'exec last cmd
SELECT CASE cmd$
CASE "A": m$(1) = m$(d#)
CASE "B": m$(2) = m$(d#)
CASE "C": m$(3) = m$(d#)
CASE "D": m$(4) = m$(d#)
CASE "F"
SELECT CASE m$(1) 'the function name m$(2) 1st para...
CASE "NOT": IF VAL(m$(2)) = 0 THEN m$(d#) = "-1" ELSE m$(d#) = "0"
CASE "RND": m$(d#) = STR$(RND)
CASE "INT": m$(d#) = STR$(INT(VAL(m$(2))))
CASE "CTR": LOCATE CSRLIN, (80 - LEN(m$(2))) / 2: PRINT m$(2);
CASE "CLS": CLS
CASE "COLOR": COLOR VAL(m$(2)), VAL(m$(3))
CASE "LEN": m$(d#) = STR$(LEN(m$(2)))
CASE "MID1": m$(d#) = MID$(m$(2), VAL(m$(3)))
CASE "MID2": m$(d#) = MID$(m$(2), VAL(m$(3)), VAL(m$(4)))
CASE "INSTR1": m$(d#) = STR$(INSTR(m$(2), m$(3)))
CASE "INSTR2": m$(d#) = STR$(INSTR(VAL(m$(2)), m$(3), m$(4)))
CASE "LOCATE": LOCATE VAL(m$(2)), VAL(m$(3))
END SELECT
CASE "M": m$(d#) = m$(0)
CASE "W": PRINT m$(d#);
CASE "?": INPUT m$(d#)
END SELECT
cmd$ = "": ds$ = ""
END IF 'if cmd <> ""
'handle current cmd
IF INSTR("ABCDFMW?", c$) THEN
cmd$ = c$
ELSEIF c$ = "I" THEN
IF VAL(m$(0)) = 0 THEN i% = Findi(i%)
IF err$ <> "" THEN PRINT err$: SLEEP: EXIT SUB
ELSEIF c$ = "E" THEN
i% = Findi(i%)
IF err$ <> "" THEN PRINT err$: SLEEP: EXIT SUB
ELSEIF c$ = "P" THEN
ELSEIF c$ = "X" THEN
bktCnt% = 1 'count the bracket we're on
i% = i% + 1 'move the code pointer to the next char
WHILE bktCnt% <> 0
'count nested loops till we find the matching one
IF MID$(code$, i%, 1) = "]" THEN bktCnt% = bktCnt% - 1
IF MID$(code$, i%, 1) = "[" THEN bktCnt% = bktCnt% + 1
i% = i% + 1 'search forward
WEND
i% = i% - 1%
ELSEIF c$ = "]" THEN ' end a loop if loop index is 0
bktCnt% = -1 'count the bracket we're on
i% = i% - 1 'move the code pointer back a char
WHILE bktCnt% <> 0
'count nested loops till we fine the matching one
IF MID$(code$, i%, 1) = "]" THEN bktCnt% = bktCnt% - 1
IF MID$(code$, i%, 1) = "[" THEN bktCnt% = bktCnt% + 1
i% = i% - 1 'search backwards
WEND
i% = i% + 1
ELSEIF c$ = "%" THEN: m$(0) = STR$(VAL(m$(1)) MOD VAL(m$(2)))
ELSEIF c$ = "^" THEN: m$(0) = STR$(VAL(m$(1)) ^ VAL(m$(2)))
ELSEIF c$ = "/" THEN: m$(0) = STR$(VAL(m$(1)) / VAL(m$(2)))
ELSEIF c$ = "*" THEN: m$(0) = STR$(VAL(m$(1)) * VAL(m$(2)))
ELSEIF c$ = "~" THEN: m$(0) = STR$(VAL(m$(1)) - VAL(m$(2)))
ELSEIF c$ = "+" THEN: m$(0) = STR$(VAL(m$(1)) + VAL(m$(2)))
ELSEIF c$ = "=" THEN: m$(0) = STR$(VAL(m$(1)) = VAL(m$(2)))
ELSEIF c$ = "<" THEN: m$(0) = STR$(VAL(m$(1)) < VAL(m$(2)))
ELSEIF c$ = ">" THEN: m$(0) = STR$(VAL(m$(1)) > VAL(m$(2)))
ELSEIF c$ = "(" THEN: m$(0) = STR$(VAL(m$(1)) <= VAL(m$(2)))
ELSEIF c$ = ")" THEN: m$(0) = STR$(VAL(m$(1)) >= VAL(m$(2)))
ELSEIF c$ = "!" THEN: m$(0) = STR$(VAL(m$(1)) <> VAL(m$(2)))
ELSEIF c$ = "&" THEN
IF VAL(m$(1)) <> 0 AND VAL(m$(2)) <> 0 THEN m$(0) = "-1" ELSE m$(0) = "0"
ELSEIF c$ = "|" THEN
IF VAL(m$(1)) <> 0 OR VAL(m$(2)) <> 0 THEN m$(0) = "-1" ELSE m$(0) = "0"
END IF ' ran into next command
END IF
NEXT
PRINT: INPUT "Run is done, enter to continue..."; temp$
END SUB
FUNCTION Findi% (i%)
cnt% = 1
FOR j% = i% + 1 TO LEN(code$)
c1$ = MID$(code$, j%, 1)
IF c1$ = "N" THEN
cnt% = cnt% - 1
IF cnt% = 0 THEN Findi% = j%: EXIT FUNCTION
ELSEIF c1$ = "I" THEN
cnt% = cnt% + 1
ELSEIF c1$ = "E" AND cnt% = 1 THEN
Findi% = j%: EXIT SUB
END IF
NEXT
err$ = "Could not find N"
END FUNCTION
' modified function from Help files
SUB loadDirList (spec$)
CONST TmpFile$ = "DIR$INF0.INF"
IF spec$ > "" THEN 'get file names when a spec is given
SHELL _HIDE "DIR " + spec$ + " /b > " + TmpFile$
Index% = 0: dirList$(Index%) = "": ff% = FREEFILE
OPEN TmpFile$ FOR APPEND AS #ff%
size& = LOF(ff%)
CLOSE #ff%
IF size& = 0 THEN KILL TmpFile$: EXIT SUB
OPEN TmpFile$ FOR INPUT AS #ff%
DO WHILE NOT EOF(ff%) AND Index% < ListMAX%
Index% = Index% + 1
LINE INPUT #ff%, dirList$(Index%)
LOOP
DIRCount% = Index% 'SHARED variable can return the file count
CLOSE #ff%
KILL TmpFile$
ELSE IF Index% > 0 THEN Index% = Index% - 1 'no spec sends next file name
END IF
END SUB
I threw out the file management stuff, let the Windows Explorer or Equivalent do that stuff!
Now you can drag and drop *SNH.txt programs onto the exe or select a file to run from a folder listing.
A limited set of built-in functions just to show that they All can be done.
EDIT: 2017-08-02 12:18 PM It turns out that the NOT function did need to be fixed, -1 not 1 for True.
That and some additional *SNH.txt code files have been added to the revised SNH Pack.zip
SNH Pack.zip (635.14 kB - downloaded 16 times.)
« Last Edit: August 02, 2017, 09:25:17 am by bplus »
Logged
Will you still love me, will you still need me, when I'm (QB) 64?
bplus
Hero Member
Posts: 622
B = B + _
Re: Novelty Interpreters (tiny)
« Reply #5 on: August 02, 2017, 09:24:14 am »
Small fix made to .bas & .exe code in the SNH Pack.zip attachment in previous post.
Additional test *SNH.txt files have been added and some more edits of the Read Me.txt file.
Logged
Will you still love me, will you still need me, when I'm (QB) 64?
bplus
Hero Member
Posts: 622
B = B + _
Re: Novelty Interpreters (tiny)
« Reply #6 on: February 08, 2018, 02:31:17 pm »
I have converted SmallBASIC Nano3 Interpreter to QB64 with help with Evaluate system started in JB, further developed in FB and then converted to QB64.
The Interpreter now works completely as a stand alone 6 times the size Nano was.
It is a drag and drop of source code program onto BRUN.exe. All the file management stuff is left to Windows or your OS and all editing left to NotePad++ or your favorite editor.
The BRUN Pack#1.zip has a bonus copy of source code and exe with debugger switched on so can step through each line of program and watch the variables to help track down errors.
Also included in package are 10 sample and test programs and one 000BRUN Help B.txt cheat sheet of 21 keywords and list of math functions...
New form Nano3 is variable names as long as you like, setting number variables are done with n keyword at first position in program line instead of = sign after variable name.
It might be fun to play with for short programs...
attached is zip and a few screen shots: cheat sheet and 2 calculator programs
Next up, I have to remember how to handle strings and their functions... (consulting last post here!),
I might have to give up on idea of no punctuation.
Append: Comment lines are ANY line that doesn't start with keyword, no REM or ' needed!
Printing stuff: just start line with . , or ; no quotes needed, variable values are automatically substituted in for variable names.
You might miss having control of spaces (not ready yet) but have LOCATE sub replaced with: rc row, col and have graphics: at x, y to locate a print at any pixel.
Oh! Here is what code looks like for first calculator (to sort of look like the device, though you cant click keys (yet!))
Code: [Select]
calculator B.txt revised again for BRUN 2018-02-07 originally from:
calculator nano3.txt for Nano3.bas (B+=MGA) 2017-06-10
sub Menu
n i -1
at 0 80 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>__ r __<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
at 0 120 Command Menu:
do
n i i + 1
if i > 22
exit
fi
n x (i % 5) * 160
n y int( i / 5) * 50 + 160
if i = 0
at x y i = +
fi
if i = 1
at x y i = -
fi
if i = 2
at x y i = *
fi
if i = 3
at x y i = /
fi
if i = 4
at x y i = ^
fi
if i = 5
at x y i = pi
fi
if i = 6
at x y i = rad
fi
if i = 7
at x y i = cos
fi
if i = 8
at x y i = sin
fi
if i = 9
at x y i = tan
fi
if i = 10
at x y i = atan
fi
if i = 11
at x y i = deg
fi
if i = 12
at x y i = mod
fi
if i = 13
at x y i = ln
fi
if i = 14
at x y i = exp
fi
if i = 15
at x y i = mIn
fi
if i = 16
at x y i = m+
fi
if i = 17
at x y i = mOut
fi
if i = 18
at x y i = mClear
fi
if i = 19
at x y i = # start
fi
if i = 20
at x y i = quit
fi
loop
return
sub getC
mark cStart
cls
gosub Menu
at 0 40 Enter command number
? c
if c >= 0
if c < 23
go cEnd
else
go cStart
fi
else
go cStart
fi
mark cEnd
return
cls
at 0, 20 Enter a number for starting the calculator...
? r
do
gosub getC
if c = 0
? s + Enter number to add...
n r r + s
fi
if c = 1
? s - Enter number to subtract...
n r r - s
fi
if c = 2
? s * Enter number to multiply...
n r r * s
fi
if c = 3
? s / Enter divisor...
if s <> 0
n r r / s
else
. Oops, can't divide by 0
fi
fi
if c = 4
? s ^ Enter power...
n r r ^ s
fi
if c = 5
n r pi
fi
if c = 6
n r r *pi/180
fi
if c = 7
n r cos( r )
fi
if c = 8
n r sin( r )
fi
if c = 9
n r tan( r )
fi
if c = 10
n r atan( r )
fi
if c = 11
n r deg( r )
fi
if c = 12
? s Enter modulus...
n r r % s
fi
if c = 13
n r log( r )
fi
if c = 14
n r exp( r )
fi
if c = 15
n m r
fi
if c = 16
n m m + r
fi
if c = 17
n r m
fi
if c = 18
n m 0
fi
if c = 19
? r Enter new start number...
fi
if c = 20
at 0 400 Goodbye!
end
fi
loop
And code for line calculator (or expressions evaluator):
Code: [Select]
Line calc by bplus for BRUN 2018-02-07
do
at 110 40 *** Line Calculator ***
at 10 80 arith: +, -, *, /, constants: e, pi, random 0-1 use rnd
at 10 100 (keep - for subtraction spaced on both sides to distinguish from neg numbers)
at 10 120 functions modulus use %, power use ^, log, exp, sqr, int, random 0 to 1 use rnd
at 10 140 trig (radians): sin( ), cos( ), tan( ), atan( ) conversion: rad, deg
at 10 160 boolean: =, <>, <, <=, >, >=, and, or, not
at 50 180 (results are displayed for 3.5 secs)
n row int(220/16 + .5)
rc row 2
? string (-42 to quit) Enter an expression to evaluate...
if string = -42
exit
fi
n result string
at 10 250 The calculator came up with this: result
wait 3.5
cls
loop
cls
.
. Goodbye!
.
.
BRUN pack #1.zip (914.47 kB - downloaded 7 times.)
000 BRUN Help B_txt.PNG (43.7 kB - downloaded 4 times.)
calculator B_txt.PNG (9.19 kB - downloaded 5 times.)
line calc B_txt.PNG (14.01 kB - downloaded 4 times.)
« Last Edit: February 08, 2018, 02:56:27 pm by bplus »
Logged
Will you still love me, will you still need me, when I'm (QB) 64?
IGetGroovy
Newbie
Posts: 23
Re: Novelty Interpreters (tiny)
« Reply #7 on: February 08, 2018, 08:15:15 pm »
I had a blast running the examples here bplus, nice job! This is a really cool project - this is the program that grew from the 100 LOC contest, right? I also messed with the line of code that reports on "EvalW" on each iteration and then re-ran everything - it's fun watching a recursive thing clamp down on an answer, agree? I also wonder if you know where this program is going next. In the spirit of separating mechanism from policy, do you intend on having a version that runs embedded in a terminal?
Now is another good chance to mention (perhaps not for the first time), do you have any aversion to hanging out in IRC #qb64? You are a vibrant member in the QB-sphere and I suspect you'd have a blast there.
Logged
eoredson
Hero Member
Posts: 570
I programmed myself into a conniption..
Re: Novelty Interpreters (tiny)
« Reply #8 on: February 08, 2018, 11:08:53 pm »
I wrote an interpreter here:
http://www.[abandoned, outdated and now likely malicious qb64 dot net website - don’t go there]/forum/index.php?action=dlattach;topic=13148.0;attach=4378
Erik.
Logged
Games: DNDDOOR - https://bit.ly/EriksDNDDoor DUNGEON - https://bit.ly/EriksDungeon
Interpreter - https://bit.ly/EriksSICK Hex Editor - https://bit.ly/EriksHexEditor
Utilities - https://bit.ly/EriksUtils Old QB64 - https://bit.ly/OldQB64
QB64 shell - https://bit.ly/QB64shell
FellippeHeitor
QB64 Partner Site Owner
Hero Member
Posts: 1806
LET IT = BE
Re: Novelty Interpreters (tiny)
« Reply #9 on: February 09, 2018, 05:35:52 am »
Is it interpreter sharing season? Here's mine too https://github.com/FellippeHeitor/QB64-interpreter
I'll check yours right now bplus, sounds like fun.
Logged
- InForm for QB64 http://qb64.org/inform
- vWATCH64 (debugger for QB64) http://bit.ly/vWATCH64v1-103
- Games: http://bit.ly/2048_qb64 * http://bit.ly/ClonedShades_qb64source * http://bit.ly/2aqK866 * http://bit.ly/SpaceshipQB64 * http://bit.ly/2rD1pPP
bplus
Hero Member
Posts: 622
B = B + _
Re: Novelty Interpreters (tiny)
« Reply #10 on: February 09, 2018, 11:28:43 am »
Oh hey a response! Yeah!
Hi IGetGroovy,
Thanks for paying attention, yes it is Nano3 SmallBASIC code spread out into QB64 (version 2017 11 06 /82 (if I recall), sorry I forgot to add that Jack). Now I think I remember you from another name but which Luke? Bill? I can't keep track of names very well or do I mean psuedo names. Now I know where WHN? got the idea of constantly changing avatar names (and from lurking at Studio 54 ) are you all really one guy? maybe with split personality? Pete is that you!
There is talking, there is talking about coding and there is coding, I have no aversion to hanging out at IRC QB64, I do wish I could lurk a little before signing on as member, a glance into what I may be spending more time
Quote
In the spirit of separating mechanism from policy, do you intend on having a version that runs embedded in a terminal?
Plans? well embedding is not even on my radar but I asked a question about embedding at BP.org, 2 years before it went belly up, and have yet to get a decent answer: What is it? What is it good for? I've looked into it, a little, have some foggy notions but nothing is clear.
I have immediate plans for primitive graphics (got to have fun with that! specially if QB64 gives me more speed that SB) and of course strings and arrays. My plans are in To do list in opening comments of BRUN source... Long range? I usually go where the spirit takes me or am sorry I didn't.
This not BASIC, I don't want to build another BASIC interpreter, Erik and Fellippe's are likely too good to even try and better them ! It is Basic like, I guess since Basic is all I prefer to code with.
Yes! Fellippe and Erik, I have looked into both your beautiful monsters! I suppose mine too is growing so large as to require serious study time to understand and use effectively.
BRUN (and Nano) is very much in spirit of WHN? author of FIG, who started contest with Walter at TJP that ended up producing nascent Nano after nasty argument with him. I argue but I listen too (sometimes, specially when I respect person with whom I am arguing. Of course my idea of respect is to try and avoid foul moronic language, of course that does signal extreme frustration which is better than nothing, I guess.)
eh! I could go on and on about my child... sheeze
« Last Edit: February 09, 2018, 11:53:38 am by bplus »
Logged
Will you still love me, will you still need me, when I'm (QB) 64?
bplus
Hero Member
Posts: 622
B = B + _
Re: Novelty Interpreters (tiny)
« Reply #11 on: February 09, 2018, 11:35:37 am »
Quote
Is it interpreter sharing season? Here's mine too https://github.com/FellippeHeitor/QB64-interpreter
I'll check yours right now bplus, sounds like fun.
Oh now I've seen Erik's post and understand
Yes, Interpreter season opened up in January or before at TJP with David Taylor making all sorts of announcements with such piss and vinegar and spunk, it reignited my own spark for the subject.
The crazy thing is he is not sharing his source code, so I guess we are showing him how it's done.
Logged
Will you still love me, will you still need me, when I'm (QB) 64?
eoredson
Hero Member
Posts: 570
I programmed myself into a conniption..
Re: Novelty Interpreters (tiny)
« Reply #12 on: February 09, 2018, 07:14:44 pm »
@bplus: You need to concentrate on your engine of choice first - such as a descent parser, then write the interpreter around it.
Pay certain attention on how to parse parenthesis first, then smaller structures like Do..Loop and For..Next.
Once the parser engine is written the rest will follow, including the basic commands - List, Run, Load, Save, etc.
Expect to spend alot of time on it.
Erik.
Logged
Games: DNDDOOR - https://bit.ly/EriksDNDDoor DUNGEON - https://bit.ly/EriksDungeon
Interpreter - https://bit.ly/EriksSICK Hex Editor - https://bit.ly/EriksHexEditor
Utilities - https://bit.ly/EriksUtils Old QB64 - https://bit.ly/OldQB64
QB64 shell - https://bit.ly/QB64shell
bplus
Hero Member
Posts: 622
B = B + _
Re: Novelty Interpreters (tiny)
« Reply #13 on: February 09, 2018, 07:17:30 pm »
Quote from: eoredson on February 09, 2018, 07:14:44 pm
@bplus: You need to concentrate on your engine of choice first - such as a descent parser, then write the interpreter around it.
Pay certain attention on how to parse parenthesis first, then smaller structures like Do..Loop and For..Next.
Once the parser engine is written the rest will follow, including the basic commands - List, Run, Load, Save, etc.
Expect to spend alot of time on it.
Erik.
Been there done all that, did you even run a sample? just drag and drop a *B.txt file over BRUN.exe
You know this like my 6th (toy) interpreter ? and this is not traditional Basic IDE style runs.
Don't need List, Run, Load, Save ... as explained earlier, you edit your files in your favorite text editor (eliminates New, Load, List, Save, Edit), I am letting Windows or your favorite OS handle all file management (rename, cut/copy/paste to whatever folders, delete...). just end your program files with "B.txt"
The "engine" for parsing... handling expressions has been assembled and tutored at TJP under FreeBasic two threads on subject Evaluation. It does not use traditional parser techniques let alone worry about ascent and decent... yet it handles operators in regular order: preparing string for evaluation, substitutions in of constants and variable values, functions, math operators like mod and power, arith operators / then * the - then +, then booeans < = > stuff then logical conjugates "and" and "or" and finally not. True it's not the quickest most efficient system but it works.
You Run your source file, "Program name B.txt" by drag and drop onto the BRUN.exe and just like magic it runs or tells you the first line number it can't execute.
or drag and drop onto BRUN w debugger.exe and watch your code get processed line by line.
Here is a program "Count to ten B.txt"
Code: [Select]
n count 1
do
. count
n count count + 1
if count > 10
exit
fi
loop
count to 10.PNG (61.05 kB - downloaded 6 times.)
« Last Edit: February 09, 2018, 07:49:15 pm by bplus »
Logged
Will you still love me, will you still need me, when I'm (QB) 64?
eoredson
Hero Member
Posts: 570
I programmed myself into a conniption..
Re: Novelty Interpreters (tiny)
« Reply #14 on: February 09, 2018, 07:20:13 pm »
Ok, well, if you've done all that, then, nevermind
Logged
Games: DNDDOOR - https://bit.ly/EriksDNDDoor DUNGEON - https://bit.ly/EriksDungeon
Interpreter - https://bit.ly/EriksSICK Hex Editor - https://bit.ly/EriksHexEditor
Utilities - https://bit.ly/EriksUtils Old QB64 - https://bit.ly/OldQB64
QB64 shell - https://bit.ly/QB64shell
Pages: [1] 2
« previous next »
QB64 Community »
Programs (.BAS), Tutorials and Libraries ($INCLUDE, DECLARE LIBRARY, ...) »
Sample Programs (Moderators: Galleon, OlDosLover, SMcNeill, Kobolt) »
Novelty Interpreters (tiny)
SMF 2.0.3 | SMF © 2011, Simple Machines
XHTML
RSS
WAP2
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 »
Programs (.BAS), Tutorials and Libraries ($INCLUDE, DECLARE LIBRARY, ...) »
Sample Programs (Moderators: Galleon, OlDosLover, SMcNeill, Kobolt) »
Novelty Interpreters (tiny)
« previous next »
Pages: 1 [2]
Author Topic: Novelty Interpreters (tiny) (Read 667 times)
rks
Newbie
Posts: 34
Re: Novelty Interpreters (tiny)
« Reply #15 on: February 10, 2018, 09:35:13 am »
I'll throw mine back in again, I've done some more work on it, and it's probably to big to be considered a 'tiny' anything but it is a novelty something.
r
tascript 30.7z (46.4 kB - downloaded 12 times.)
Logged
bplus
Hero Member
Posts: 622
B = B + _
Re: Novelty Interpreters (tiny)
« Reply #16 on: February 10, 2018, 10:13:11 am »
Hi rks,
Thanks I will check it out, do you have a link here where/when you've discussed what you are doing?
I see you signed up 2012 (edit year) and are already up to 30 posts! I will check out those too, maybe you are Bill.
Append: Man what a salesman you are! Got me interested hook, line and slinker!
http://www.[abandoned, outdated and now likely malicious qb64 dot net website - don’t go there]/forum/index.php?topic=13259.msg114533#msg114533
« Last Edit: February 10, 2018, 01:56:07 pm by bplus »
Logged
Will you still love me, will you still need me, when I'm (QB) 64?
rks
Newbie
Posts: 34
Re: Novelty Interpreters (tiny)
« Reply #17 on: February 11, 2018, 09:21:21 am »
Hi bplus,
Back when I posted the first version of the interpreter (several years ago under a different name), there was some explanation, but it was so long ago I can't remember it, which is not unusual. There is a piece in the manual about what I’m doing but honestly it came about from two reasons, a desire to write my own language without actually having a clue as to how to go about it, and sufficient boredom one winter to make me start. So I read a few articles, some of which I almost understood and with no plan in sight started coding a way to get single keystrokes followed by a way to print them. I’ve used syntax from several different languages and made up the rest as I went, through several iterations, to reach this point. I’m probably done with it for a while, it’s ended up a lot bigger than I intended as it strayed from it’s original purpose of a text game engine into a more general purpose language, but it’s been an interesting diversion.
And by the way, I'm not Bill, at least that I recall.
r
Logged
bplus
Hero Member
Posts: 622
B = B + _
Re: Novelty Interpreters (tiny)
« Reply #18 on: February 11, 2018, 11:56:58 am »
Hi rks,
Nice docs, 8 pages is about my limit but you seem to be doing things well = how I might! ha!
I like how you map all the jump points line labels, go subs... and how you fit your IF lines to that system.
I also like how it is designed, at least originally, with a particular goal of being a text game engine. That gives one a clear idea of direction and when one is done or when one might add a new feature...
Doing a general interpreter covers too broad an area specially if one of your ideas/ideals is that the smaller the more fun to learn and use.
Logged
Will you still love me, will you still need me, when I'm (QB) 64?
rks
Newbie
Posts: 34
Re: Novelty Interpreters (tiny)
« Reply #19 on: February 12, 2018, 09:23:18 am »
Thanks! The docs came into being after I forgot how I was implementing something after a several day break, figured if I didn't write things down I never know where I was. The general purposity (? new word alert!) came about from playing with ways to modify text and it's easy enough to ignore them when they aren't needed. It doesn't hurt that the compiled size doesn't change much with or without the feature bloat, but it's sometimes difficult to keep ones fingers out of the pie. Anyway, the layout makes things fairly simple to strip out non-essentials if needed.
I've been reading through your latest, nice! Although BRUN brought back memories of good ole QB run times.
r
Logged
bplus
Hero Member
Posts: 622
B = B + _
Re: Novelty Interpreters (tiny)
« Reply #20 on: February 12, 2018, 09:40:25 am »
Code: [Select]
Although BRUN brought back memories of good ole QB run times.
Yes, I am glad you caught that!
I hope my effort is respectful and honoring of that tradition. If not please complain and I will change name (alas poor Erik, another name to track!)
I tried some research on BRUN name, came up with zilch, no mention of QuickBasic or QBasic (and I am still trying to figure out the original name of QB version name I was using, I think QuickBasic 4.5 because it did have compiler and it was just before QBasic came free with DOS (I just learned it was DOS 5 not 6 that QBasic came free without compiler).
Logged
Will you still love me, will you still need me, when I'm (QB) 64?
rks
Newbie
Posts: 34
Re: Novelty Interpreters (tiny)
« Reply #21 on: February 13, 2018, 09:33:54 am »
I like the name, brings back memories. BRUN had the version number of QB as part of the name, so QB45 came with BRUN45.EXE, QB40 came with BRUN40.EXE, etc. It also seems like QB45 was little more than an IDE update to QB40. It was something of a shock when I upgraded from DOS 4.01 to DOS 5.0 and had QBasic instead of BASICA, that took some getting used to.
Anyway, I like the conciseness of your language, mine sprawls all over the place.
r
Logged
bplus
Hero Member
Posts: 622
B = B + _
Re: Novelty Interpreters (tiny)
« Reply #22 on: February 13, 2018, 10:56:30 am »
Hi rks,
Speaking of likes, I forgot to mention I like [varaiable] to tell exe to print value instead of string (or name of variable).
I like it so much I might have to steal idea. (if paying this compliment isn't enough).
Re: Arrays and strings
Last night I woke up at 4 AM with idea that might eliminate need for strings and arrays (as we QBers know them anyway).
I did say, might, these middle of night insights sometimes do pan out but not exactly how they were first seen...
Anyway I hope I have titillated and stirred up some imaginations with this announcement.
Logged
Will you still love me, will you still need me, when I'm (QB) 64?
bplus
Hero Member
Posts: 622
B = B + _
Re: Novelty Interpreters (tiny)
« Reply #23 on: February 14, 2018, 01:08:27 am »
Hey happy Valentines Day!
Code: [Select]
simple sieve 2 B.txt for BRUN v 2 2018-02-14 adopted from:
'Simple sieve 2.bas SmallBASIC 2015-04-29 found a faster sieve with BASIC 256
n topLimit 100
n limit topLimit ^ .5
. Primes to topLimit
take care of even numbers first
n index 4
do
put composites index 1
n index index + 2
if index > topLimit
exit
fi
loop
now do odd numbers
n index 3
do
get test composites index
if test = 0
if index < limit
n j 2 * index
do
put composites j 1
n j j + index
if j > topLimit
exit
fi
loop
fi
fi
n index index + 2
if index > limit
exit
fi
loop
n index 2
pCount = 0
do
get test composites index
if test = 0
n pCount pCount + 1
. index
fi
n index index +1
if index > topLimit
exit
fi
loop
.
. There are pCount primes for the first topLimit integers.
It works!
prime sieve 2.PNG (11.13 kB - downloaded 4 times.)
Logged
Will you still love me, will you still need me, when I'm (QB) 64?
bplus
Hero Member
Posts: 622
B = B + _
Re: Novelty Interpreters (tiny)
« Reply #24 on: February 14, 2018, 07:02:34 am »
Glacial slow get and put for BRUN 2
Basic: array(Index) = someValueEvaluatedInProgramLine
BRUN 2 put syntax:
put stringArrayName numberVariableIndex valueFromNumberCalcInProgramLine
Basic: numberVariable = array(Index)
BRUN 2 get syntax:
get getValuePutUnderThisNumberVariableName fromThisStringArrayVariableName andThisNumberVariableIndex
Logged
Will you still love me, will you still need me, when I'm (QB) 64?
rks
Newbie
Posts: 34
Re: Novelty Interpreters (tiny)
« Reply #25 on: February 14, 2018, 09:14:33 am »
You are more than welcome to use [variable], I took it from assembly language.
Without strings and arrays what would the BASIC community have to argue about making the best use of? Does sound intriguing, though. I've had some of those middle of the night flashes of insight, mine rarely make nearly as much sense after coffee.
There's nothing wrong with glacially slow if you get the correct answer, speed can be worked on later.
r
Logged
bplus
Hero Member
Posts: 622
B = B + _
Re: Novelty Interpreters (tiny)
« Reply #26 on: February 14, 2018, 10:01:34 am »
so that's why I drink so much coffee! to sober up from my dreams...
Logged
Will you still love me, will you still need me, when I'm (QB) 64?
eoredson
Hero Member
Posts: 570
I programmed myself into a conniption..
Re: Novelty Interpreters (tiny)
« Reply #27 on: March 03, 2018, 01:33:13 am »
Quote
I hope my effort is respectful and honoring of that tradition. If not please complain and I will change name (alas poor Erik, another name to track!)
My utilities, my whatis parser, my SICK interpreter, and my QB64shell all indicate the road I've traveled down.
If you could look at them all (in my signature), I'm sure they will help and be of some aid.
Although I will admit my interpreter was born of a recursive descent parser. If you need to adapt a tokenizer or such to
your own then you are on your own.
Erik.
Logged
Games: DNDDOOR - https://bit.ly/EriksDNDDoor DUNGEON - https://bit.ly/EriksDungeon
Interpreter - https://bit.ly/EriksSICK Hex Editor - https://bit.ly/EriksHexEditor
Utilities - https://bit.ly/EriksUtils Old QB64 - https://bit.ly/OldQB64
QB64 shell - https://bit.ly/QB64shell
Pages: 1 [2]
« previous next »
QB64 Community »
Programs (.BAS), Tutorials and Libraries ($INCLUDE, DECLARE LIBRARY, ...) »
Sample Programs (Moderators: Galleon, OlDosLover, SMcNeill, Kobolt) »
Novelty Interpreters (tiny)
SMF 2.0.3 | SMF © 2011, Simple Machines
XHTML
RSS
WAP2
Posted by: +KZYes I can agree
« on: Yesterday at 02:21:08 PM »Insert Quote
allow multiple windows on same program will be nice :)
From the old [abandoned, outdated and now likely malicious qb64 dot net website - don’t go there] days what author-topic was most viewed (and approximately how many views).Damnation! GDK was second!
allow multiple windows on same program will be nice :)You can do this, either using VQB to have seperate frames in your window, my sfml lib (allows 5 screens but only works with .954(sdl)) or use RhoSigma's GUI Framework to have multiple screens.
Sounds like the beginning of a collective project to be featured in the samples gallery instead.
Replace is a command that has to be custom rolled, in my opinion. There’s just no way to please the masses when implementing it. Add it to a language, and forevermore you’ll get suggestions on “how to improve it”.
His arguments - all of which make perfect sense - would be not to add it to the language itself.
Think of CircleFill, though: several decisions have had to be made in that one and now we have a major tool available for everyone to use.
All you need is a function that does plain search replace and one that does regex matches, and all of Steve's strange desires for catfood are taken care of.
result$ = REGEXREPLACE(regex$, replacement$, subject$[, limit&])
Now let's all argue over whether we use POSIX or perl regexen.
I don't know, Steve just put forward a pretty good argument for NOT that!is one reality, not all reality...
I realize that "for next" can only contain one variable (correct me if I'm wrong)
my suggestion is enable "for next" to contain more variables
example:Code: QB64: [Select]
I think I’m confused by the above.
For "BLOCK Statements" eg
FOR … NEXT
DO … LOOP
WHILE ...WEND
SELECT CASE … END SELECT
IF … ENDIF
etc
it would save some time to let the IDE auto fill the termination of the block code.
For example, when starting off a new line of code such as FOR I.... that the IDE auto inserts a blank line followed by another line NEXT I...
At present the IDE "flags an error" (FOR without NEXT) - which is correct but it is practically impossible to type in the required NEXT … line before the warning message pops up - so why not let the IDE just insert the NEXT … line instead of giving an error message?
Similarly for all the other "Block Statements" as per above (and maybe other things as well).
I know this may sound to be "poor programming" - however it would make sense to automate as much as possible any repetitive (even trivial) tasks to allow focus on the "real" programming task at hand.
Thanks Steve for reply.
The suggestion was for "brand new code lines generated in real(live) time" not for code already in existence - so feature not applicable to editing (copy/cut/paste , replacing, included files, etc.).
Unless I missed it in all the posts...
Have proper means of MOVING and RENAMING files/directories without having to resort to eg
SHELL "COPY D:\oldfilename$ D:\newfilename$"
KILL "D:\oldfilename$"
for renaming
Similarly
SHELL "COPY D:\filename$ D:\TRASH\filename$"
KILL "D:\filename$"
for moving
It is important to reduce wear and tear on the HHD and SSD - especially with SSD that have a very limited rewrite cycles (factored with when rewriting to SSD - depending on the model number - up to 4 MBytes minimum is "block erased" even for say a 4KB file due to the very nature of the non-volatile silicon design). Generally speaking SSD have close to "infinite" reads, it is just the erase/rewrite procedure that is drastically reduced in the number of times it can be performed.
Maybe a Windows API procedure?
The third thing that would help a lot has to do with the editor and is a system that with the simple press of a function key compresses and expands the code contained in subs, functions and routines. this way the code would look more natural.
( QB64 v1.5 MOVe & REName statements for files and directories
@Richard For Move and Rename, check my API collection zip or the forum link here: https://www.qb64.org/forum/index.php?topic=3034.msg123040#msg123040 (https://www.qb64.org/forum/index.php?topic=3034.msg123040#msg123040)
I used the WinAPI to write code to allow for Move, Copy, Rename, Recycle, and Empty Recycle Bin. Maybe this is what could be used for 1.5?
For a file copy:@SMcNeill
OPEN “yourfile.ext” FOR BINARY AS #1
OPEN “yourcopy.ext” FOR BINARY AS #2
l = LOF(1)
temp$ = SPACE$(l)
GET #1, 1, temp$
PUT #2, 1, temp$
CLOSE
That seems like a lot of lines just to say copy from here to here. At that point you might as well just SHELL and use some CMD command. Besides, since mine uses the built in Windows functions it actually gives confirmation dialogs to prevent overwrites and such.
Just make it a single SUB. SHELL comes with several issues, such as OS dependency, and user permissions. I tend to find it best to handle program execution internally, when possible, rather than just shelling out for everything.Which is why I used the WinAPI functions found in Shell32 so I could have all the nice things that Windows offers with the confirmation dialogs and progress bars and creation of directories if they don't already exist when doing a copy or move. I know you can write in message boxes and check for directories and files existing but why not just let Windows handle it since, after all, it is a Windows program. I don't write things for Linux or Mac because I haven't found Linux or Mac to be good solutions for me as alternative operating systems. I'm a Windows man.
Try NAME: https://www.qb64.org/wiki/NAME
NAME "BIGBAD.TXT" AS "BADWOLF.TXT"
I know that I can use for instance DOS CMD for file sizes (bytes), also use QB64 LOF(…) for program investigation of files sizes, and also that there are 3rd party software that do this. However, for convenience, it would be nice if Windows File Explorer was "modified" to display (as an option) file sizes in bytes.
Is there a way to do this - eg Registry setting or even a Windows API to do this?
This maybe beyond the scope of QB64 but...
Any way (as an option) that QB64 on startup (or in a program) override Windows File Explorer displaying of file sizes in KB, rather display as bytes (comma separated)?
I have been "caught out" many times using Windows File explorer when it shows two files as the same size (in KB) but often the file sizes differ by a few bytes. I suspect that I had problems of using the File Explorer to merge files together and it tells the files are the same size (but I guess it seems only in KB) and so I allowed Windows not to keep two files the same size (KB) etc.
To display bytes (rather than KB) would only occupy display real estate of only 1 extra character.
I know that I can use for instance DOS CMD for file sizes (bytes), also use QB64 LOF(…) for program investigation of files sizes, and also that there are 3rd party software that do this. However, for convenience, it would be nice if Windows File Explorer was "modified" to display (as an option) file sizes in bytes.
I have searched the internet on the solution - but it appears Windows does not want anyone to change file size display.
Is there a way to do this - eg Registry setting or even a Windows API to do this?
@B+
Thanks for the reply - yes I knew of the Windows Properties feature.
However, when "eye-balling" a list say of over a thousand files - it becomes tiring to constantly get the file properties - I might as well just go to CMD window and do a directory listing (sort of defeats the purpose of having File Explorer).
@B+
Thanks for the reply - yes I knew of the Windows Properties feature.
However, when "eye-balling" a list say of over a thousand files - it becomes tiring to constantly get the file properties - I might as well just go to CMD window and do a directory listing (sort of defeats the purpose of having File Explorer).
You might give this a shot: https://www.smartftp.com/en-us/sizeinbytes
It’s supposedly a tool which alters explorer to show byte size instead of kb size, but I haven’t used it, nor do I actually know the developer. Junk like that always makes me wary of spamware, spyware, and crap which might be included with it. If anyone has a bare bones system, or a sandbox for testing first, I’d definitely let them give it a go before trying it on my work machine.
Description:[ This attachment cannot be displayed inline in 'Print Page' view ]
cb|GeSHi= -mod 1.2
cb|GeSHi-mod adds code syntax highlighting = to your forum. Powered by GeSHi, the mod= supports +200 different languages and is fully customizable for each of yo= ur themes.
Compatible with SMF 2.0 and later.
What's = new in 1.2?
- GeSHi sources updated to 1.0.8.11 which inclu= des some new languages
- Minor fix to avoid error notices in the logs wh= en running on PHP 5.4
GNU General Public License v3.0
cb|GeSHi-mod - Syntax Highlighter mod for SMF powered by GeSHi
Cop= yright (C) 2012-2013, codebirth
Website: htt= p://www.codebirth.com
Powered by GeSHi - http://qbnz.com/highlighter/
It would be useful to have additional options for the Code Select Box - I was thinking of HTML (and others) if this can be made workable in the forum environment. Although working with HTML would be much more difficult than say just text only or inserting JPG images - it could produce a much better overall appearance.
I checked the SMF forum on this and they mentioned that QB64 site had custom made the Code Select Box (options) and so any additional options would have to be done by QB64 themselves.
I was referenced over to the site below (for the Mods) and it seems that there are some 200 code options available.
https://custom.simplemachines.org/mods/index.php?mod=3070
(https://custom.simplemachines.org/mods/index.php?mod=3070)
[ This attachment cannot be displayed inline in 'Print Page' view ]
I had 3 different (non-interacting with each other) QB64 programs running and because of the the very slow performance I suspect that all 3 programs were running using the same physical (+logical) processor maybe???
If statements are not (or cannot be) available - would it help to have multiple QB64 x64 installations eg on C:\ , A:\, D:\ etc and accordingly run each program from a different QB64 installation?
Similarly if I wish to force multiple programs to run on a particular physical/logical processor (where speed is not important) - is this possible to program?
@SpriggsySpriggs
Thanks for code - you even gave me an extra 2 bytes for the file! :) (a semi-colon on PRINT #1 line fixed that)
I modified slightly your code, as below, to investigate why I got millions of "SPACEs" in my file - I thought that it would EITHER be millions of "NULLs" (i.e. CHR(&H00)) or "RANDOM GARBAGE" (if things were not initialized properly).
I used a simple free HEX editor to quickly view the file - have not yet analyzed what is in the MEM block.
Anyone like to comment???Code: QB64: [Select]
For some reason improper coordinates got stored for the second instance. Go to internal/config.ini and delete the section for the second ide window. Please let me know if that fixes it.
Maybe I may be the only one to use this larger math - if so, then it may not be justified to invest into the required QB64 code development.. So much can be said relevant to this implementation.
It appears that DIM gig as STRING * GIGABYTE does an initialization for the whole string to be spaces.
Anyway to do DIM gig so that "NO INITIALIZATION OCCURS" (I know that this is a strange request)?
I started looking at @bplus OHI and am a bit lost at this stage to "extract" the least code required to incorporate in my programs. (To be able to do many digits of resolution for the basics - add, subtract, multiply and divide). Has anyone previously done this?
.
Even if BPlus code is used, I will be limited - eg doing SQR, TAN, <>, arrays, input # etc would be a pain!
I will be limited - eg doing SQR, TAN, <>, arrays, input # etc would be a pain!
128 bit variable types do exist in C++
At 9:32 into video, there are 512 bit registers available. Serious stuff.
What is the reason for needing such a large number right now?
What is the reason for needing such a large number right now?
Alright well I sure do hope I see some 128 bit numbers being used in that NASA code and can't wait to see what colorful little demo we get next.
Well this thread has been all over the place, did we visit NASA too?
@SpriggsySpriggs, @bplusafter the second loop SUM = 964 so SQR(SUM / 9) is going to vary depending on the precision, it's not going to be exactly 10.34945 except perhaps for single
Here is an example of why it is important to increase the size of the accuracy or precision of numbers.
The program should produce a standard deviation of 10.34945. That's all.
However, when I extent the PRINT USING to accommodate the possibility of a number larger than this (say, 15 decimal places) you will see that I get garbage after the "945" using DOUBLE, SINGLE and _FLOAT.
Is that what you guys are looking for, an Immediate Window?
So you can test a snippet of code.
There’s a lot of big num libraries out there for C. If you guys really need such precision, you should look a few up and write wrappers and DECLARE LIBRARY them for use. As I posted above, boost offers up to 1024-bit precision.
@SpriggsySpriggs, @bplus
Here is an example of why it is important to increase the size of the accuracy or precision of numbers.
The program should produce a standard deviation of 10.34945. That's all.
However, when I extent the PRINT USING to accommodate the possibility of a number larger than this (say, 15 decimal places) you will see that I get garbage after the "945" using DOUBLE, SINGLE and _FLOAT.
This is an everyday example of the need for using large numbers, and QB64 fails at it. Which is why I and others have asked for changes to include large number math routines or the implementation of 128bit math processing.
It is not that it will not be used that often. In fact, it can be used for simple tasks that generally will produce numbers greater than the mantissa that restricts the precision of a result of a simple standard deviation. And if this is screwed up, even more uses will provide invalid results, and anyone looking for accuracy is just not going to get it.
It's not a matter of nice to have. It is something needed for many programming tasks.
Here is the code, followed by my results:
Code:Code: QB64: [Select]
Results:
[ This attachment cannot be displayed inline in 'Print Page' view ]
after the second loop SUM = 964 so SQR(SUM / 9) is going to vary depending on the precision, it's not going to be exactly 10.34945 except perhaps for single
bplus or STxAxTIC could probably write a pre-parser that would convert a basic program's math expressions into a program that would call string math functions
One problem, George, is it looks like your program doesn't calculate standard deviation correctly. I checked against a standard deviation calculator and your numbers don't return 10.34945. I looked up a C++ example to calculate standard deviation and mine matches the online deviation calculator.Code: QB64: [Select]
You can check that code against this link:
https://www.calculator.net/standard-deviation-calculator.html?numberinputs=72%2C84%2C96%2C88%2C91%2C75%2C79%2C100%2C76%2C99&ctype=p&x=33&y=10 (https://www.calculator.net/standard-deviation-calculator.html?numberinputs=72%2C84%2C96%2C88%2C91%2C75%2C79%2C100%2C76%2C99&ctype=p&x=33&y=10)
My return: 9.8183501669069
That online calculator's return: 9.8183501669069
One problem, George, is it looks like your program doesn't calculate standard deviation correctly. I checked against a standard deviation calculator and your numbers don't return 10.34945. I looked up a C++ example to calculate standard deviation and mine matches the online deviation calculator.Code: QB64: [Select]
You can check that code against this link:
https://www.calculator.net/standard-deviation-calculator.html?numberinputs=72%2C84%2C96%2C88%2C91%2C75%2C79%2C100%2C76%2C99&ctype=p&x=33&y=10 (https://www.calculator.net/standard-deviation-calculator.html?numberinputs=72%2C84%2C96%2C88%2C91%2C75%2C79%2C100%2C76%2C99&ctype=p&x=33&y=10)
My return: 9.8183501669069
That online calculator's return: 9.8183501669069
But QB64 has more problems than many interpreters that run on mobile devices, whose hardware isn't as robust as our desktops.
Another question I have is one this line: E = 2D0 * EXP(30D * ln(10D0))
There’s no array called ln in your program, so ln(10) is going to be 0. Is that what you expect here? Or are you looking for LOG(10)?
Oh the code in reply #127 is wrong, some fixes and it comes in on double and _Float because intermediary variables are _float:
Sorry I thought Spriggsy was quoting George code, guess that function was his own in QB64 that he was comparing to the Internet calc.
Why does the techbasic on the ipad print the wrong answer?
((186000 * 60 ^ 2) * 24) * 365.25 = 5869713600000 (at least according to both google and my windows calculator, which is what I lazily used to check results), which is what QB64 gives us. The screen shot of your ipad is showing the result as 5869713489920.
I must be missing something here, as it seems QB64 is giving us the correct answers while the mobile device screenshot you posted isn't.
I left the code exactly the same as it was in TechBASIC.
Without the ln it seems to not produce a result on the iPad. Since I am working on an iOS app right now, I will test what I just did in QB64 later. But with it, it corrects the issue of memory corruption and produces the right value. I haven't looked into why, but it just does.
The population standard deviation is a parameter, which is a fixed value calculated from every individual in the population.
A sample standard deviation is a statistic. This means that it is calculated from only some of the individuals in a population. Since the sample standard deviation depends upon the sample, it has greater variability. Thus the standard deviation of the sample is greater than that of the population.
One problem, George, is it looks like your program doesn't calculate standard deviation correctly. I checked against a standard deviation calculator and your numbers don't return 10.34945. I looked up a C++ example to calculate standard deviation and mine matches the online deviation calculator.Code: QB64: [Select]
You can check that code against this link:
https://www.calculator.net/standard-deviation-calculator.html?numberinputs=72%2C84%2C96%2C88%2C91%2C75%2C79%2C100%2C76%2C99&ctype=p&x=33&y=10 (https://www.calculator.net/standard-deviation-calculator.html?numberinputs=72%2C84%2C96%2C88%2C91%2C75%2C79%2C100%2C76%2C99&ctype=p&x=33&y=10)
My return: 9.8183501669069
That online calculator's return: 9.8183501669069
Different languages, different commands. Seems like TechBasic uses ln, while QB64 uses LOG.
Code won’t be the same unless you take the effort to convert to the proper language commands. We use SQR, C uses sqrt... You can’t just copy a formula directly from one into the other and expect it to always work. You have to convert to proper syntax.
Both my result and yours are correct. It is a matter of which Standard Deviation is being performed. I chose SAMPLE as it illustrated my example.
However, for those who do not understand the difference, I guess I need to clear up the difference between "POPULATION" vs "SAMPLE" in regards to Standard Deviation:
They are:
The formulas to calculate both of these standard deviations are nearly identical:
Calculate the mean.
Subtract the mean from each value to obtain deviations from the mean.
Square each of the deviations.
Add together all of these squared deviations.
Now the calculation of these standard deviations differs:
If we are calculating the population standard deviation, then we divide by n, the number of data values.
If we are calculating the sample standard deviation, then we divide by n -1, one less than the number of data values.
The final step, in either of the two cases that we are considering, is to take the square root of the quotient from the previous step.
The larger the value of n is, the closer that the population and sample standard deviations will be.
@madscijr
A number of forum members would welcome the feature of an immediate window, but despite request for same it would seem it is not going to happen with the developers.
...
I have never used any version of MS Office or accessories etc but in MS PDS 7.1 (30 year old BASIC) it still has very important and useful features (such as immediate window, etc) which despite calls is still lacking in QB64.
@madscijr
Regarding your reply #130 (this thread)
A number of forum members would welcome the feature of an immediate window, but despite request for same it would seem it is not going to happen with the developers.
If you refer to the following replies from me:-
https://www.qb64.org/forum/index.php?topic=3947.30 (https://www.qb64.org/forum/index.php?topic=3947.30) see reply #34
https://www.qb64.org/forum/index.php?topic=1839.msg110823#msg110823 (https://www.qb64.org/forum/index.php?topic=1839.msg110823#msg110823) see reply #2
https://www.qb64.org/forum/index.php?topic=2276.msg116118#msg116118 (https://www.qb64.org/forum/index.php?topic=2276.msg116118#msg116118) see reply #8
I had experimented with dual instances of QB64 to simulate TRON-TROFF, breakpoints, watchpoints etc (from very old BASIC days) - and in principal an "immediate window" within the program (i.e. second instance BLOATED program) may, with care, give useful capability comparable to a true intermediate window. It is "messy" but with programming care it can be automated into programs (i.e. BLOAT original program (in instance #1), auto-insert TRON-TROFF flags, breakpoints, watchpoints, immediate window sort-of capability, logs, parsing original and replace with alternative code, etc. - and then UNBLOATING to recreate the original program after debugging/developing (in instance #2))
Of course, a cheap and nasty solution is to simply open up a "new instance" of QB64 to quickly test a snippet of code but of course it may not be so convenient in many cases because certain events/values may be required beforehand.
I have never used any version of MS Office or accessories etc but in MS PDS 7.1 (30 year old BASIC) it still has very important and useful features (such as immediate window, etc) which despite calls is still lacking in QB64.
For me, I may apply this technique (in the BLOATED program) to in "parallel" with the math code of instance #1, simultaneously check all calculations etc with 128 bit computations and auto-insert relevant comments generated by instance #2 into the instance #1 (UNBLOATED) program.
In [3]: print(float(((186000 * 60 ^ 2) * 24) * 365.25))
97828577532.0
The speed of light in imperial units and US units is based on an inch of exactly 2.54 cm and is exactly
299792458 m/s × 100 cm/m × 1/2.54 in/cm
which is approximately 186282 miles, 698 yards, 2 feet, and 5 inches per second (Or accepted as 186282.397).
Why does the techbasic on the ipad print the wrong answer?
((186000 * 60 ^ 2) * 24) * 365.25 = 5869713600000 (at least according to both google and my windows calculator, which is what I lazily used to check results), which is what QB64 gives us. The screen shot of your ipad is showing the result as 5869713489920.
I must be missing something here, as it seems QB64 is giving us the correct answers while the mobile device screenshot you posted isn't.
Previous definition: The second is the duration of 9192631770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium-133 atom.
2019 definition: The second, symbol s, is the SI unit of time. It is defined by taking the fixed numerical value of the caesium frequency ΔνCs, the unperturbed ground-state hyperfine transition frequency of the caesium-133 atom,[40] to be 9192631770 when expressed in the unit Hz, which is equal to s−1.
The second may be expressed directly in terms of the defining constants:
1 s =
9192631770
/
ΔνCs
.
@GeorgeMcGinn
If I may further confuse the issue - referring to
https://www.unitconverters.net/length/inches-to-mm.htm (https://www.unitconverters.net/length/inches-to-mm.htm)
[ This attachment cannot be displayed inline in 'Print Page' view ]
So in 2019 the metre has been re-defined based on changes made to the definition of a second - should I take it that the inch conversion, being defined by that 25.4 conversion factor, prior to 2019 is not the exact same quantity of physical length "distance" as to from 2019 onwards?
If this is so, calculations involved sending a probe to the planet Pluto (yes I still call it a planet) made prior to 2019 may be out by a few feet when the same calculations are done after 2019. Not that it really matters, since the mission success rate is questionable for such great distances :)
5,878,625,370,000 miles
In a vacuum, light travels at 670,616,629 mph (1,079,252,849 km/h). To find the distance of a light-year, you multiply this speed by the number of hours in a year (8,766). The result: One light-year equals 5,878,625,370,000 miles (9.5 trillion km).May 31, 2019
Is there a limit, if you compile with the 64-bit version of QB64? I guess if you max out ram + hard drive usage, but that’s either one massive program or one helluva memory leak!
@TempodiBasic
Don't forget; you can also use my new shared memory library in Windows!
Parent:Code: QB64: [Select]
Child:Code: QB64: [Select]
Full $INCLUDE, save as Win32 SharedMem.basCode: QB64: [Select]
To my knowledge, my Shared Memory Library should allow you to share a memory buffer up to the upper limit of a 64 bit integer. As long as your data matches on both sides then you can share whatever you want. Strings, numbers, arrays, etc.
To my knowledge, my Shared Memory Library should allow you to share a memory buffer up to the upper limit of a 64 bit integer. As long as your data matches on both sides then you can share whatever you want. Strings, numbers, arrays, etc.
3.Dim As _MEM pShare 'You need to use a _MEM block
4.Dim As Long longtoShare: longtoShare = 500 'declaring a long variable to store in the _MEM block
5.pShare = _Mem(longtoShare) 'storing the long variable in the _MEM block
What is the reason for needing such a large number right now?
So we're building security programs in QB64 now?
I sure as heck ain't building anything for security. Security doesn't even cross my mind when writing a QB64 program. Only thing I think is, "huh, neat. It worked. It's a miracle"
« Reply #113 on: May 01, 2021, 05:17:03 am »
What is the reason for needing such a large number right now?
« Reply #115 on: May 02, 2021, 12:47:22 am »
I highly doubt we're doing that in QB64, though. It's not really being used for any serious applications. Simple graphics demos and games.
% 3.231700607131100371F+616
except for the unneeded % the output is correct, if you want better output for the Float type then use the C runtime library as I have shown you in the past
% 2.098318982648383492F+4969
correct value is 2.098318982648383492F+4917