On my hunt for a bug I stumbled in this trap
It looks like only the last BOOLEAN in DIM expression is treated as a real BOOLEAN

OPTION EXPLICIT

DIM b0, b1, b2 AS Boolean
TRACE b0, b1, b2
PRINT b0, b1, b2
TRACE STR$(b0);STR$(b1);STR$(b2)
TRACE STR$(b0)+STR$(b1)+STR$(b2)
DIM s AS string = STR$(b0)+STR$(b1)+STR$(b2)
TRACE "s1: "; s
s = STR$(b2)
s = s + STR$(b1)
s = s + STR$(b0)
TRACE "s2: "; s

DIM b4 AS Boolean
DIM b5 AS Boolean
TRACE b4, b5

crashed in 0.8.2. 0.8.3, 0.9.0 IDE - maybe the same as reported before

OPTION EXPLICIT

DIM SHARED AS Integer t = 2
DIM SHARED AS Integer z = 3

t = z + (1 - z) * z ' okay
t = (1 - z) ' okay

SUB Crash(x AS Integer) REM
    t = x
    ' t = (1 - x) ' CRASH!
    t = (-x + 1)
    ' t = (1 + x) ' CRASH!
    t = (x + 1)
    ' t = x + (1 - x) * x ' CRASH!
END SUB

Double as type isn't supported now.
Using it chrashes the IDE
I stumbled in it while converting a qbasic program

I searched for near an hour for a simple stupid fail I made.
If you declare a constant and assign a value later, this happens ;)
I think the compiler should help the devs to find these things.
BTW: I like AQB quite a lot!

example:

CONST AS INTEGER n = 5
PRINT i
i = 4

in 0.8.2:

assertion "FALSE" failed: file "codegen.c", line 3509, function: CG_transAssignment
Program aborted

When I build aqb it fails linking the Linux binary aqb. The math library is added to the beginning of the command line, so the linker does not resolve symbols for pow and other math functions. When I add -lm to the end of the command line it works.

Possibly this is related to the linker used with gcc on Ubuntu 20.04 LTS? I have seen the very same issue in a completely different context before (using the Qbs build system to compile some C programs).

gcc -Wall -Werror -g -lm -o ../..//target/x86_64-linux/bin/aqb ../..//target/x86_64-linux/obj/aqb.o ../..//target/x86_64-linux/obj/scanner.o ../..//target/x86_64-linux/obj/hashmap.o ../..//target/x86_64-linux/obj/util.o ../..//target/x86_64-linux/obj/frontend.o ../..//target/x86_64-linux/obj/ide.o ../..//target/x86_64-linux/obj/options.o ../..//target/x86_64-linux/obj/errormsg.o ../..//target/x86_64-linux/obj/symbol.o ../..//target/x86_64-linux/obj/link.o ../..//target/x86_64-linux/obj/linscan.o ../..//target/x86_64-linux/obj/ui_linux.o ../..//target/x86_64-linux/obj/ui_amiga.o ../..//target/x86_64-linux/obj/run.o ../..//target/x86_64-linux/obj/temp.o ../..//target/x86_64-linux/obj/assem.o ../..//target/x86_64-linux/obj/env.o ../..//target/x86_64-linux/obj/types.o ../..//target/x86_64-linux/obj/compiler.o ../..//target/x86_64-linux/obj/logger.o ../..//target/x86_64-linux/obj/codegen.o ../..//target/x86_64-linux/obj/regalloc.o ../..//target/x86_64-linux/obj/liveness.o ../..//target/x86_64-linux/obj/color.o ../..//target/x86_64-linux/obj/flowgraph.o ../..//target/x86_64-linux/obj/table.o ../..//target/x86_64-linux/obj/tui.o
/usr/bin/ld: ../..//target/x86_64-linux/obj/scanner.o: in function `number':
/home/jochen/projects/amiga/aqb/src/compiler/scanner.c:250: undefined reference to `pow'
/usr/bin/ld: ../..//target/x86_64-linux/obj/util.o: in function `U_float2str':
/home/jochen/projects/amiga/aqb/src/compiler/util.c:471: undefined reference to `pow'
/usr/bin/ld: /home/jochen/projects/amiga/aqb/src/compiler/util.c:487: undefined reference to `floor'
/usr/bin/ld: /home/jochen/projects/amiga/aqb/src/compiler/util.c:502: undefined reference to `pow'
/usr/bin/ld: /home/jochen/projects/amiga/aqb/src/compiler/util.c:508: undefined reference to `floor'
/usr/bin/ld: /home/jochen/projects/amiga/aqb/src/compiler/util.c:536: undefined reference to `floor'
/usr/bin/ld: ../..//target/x86_64-linux/obj/assem.o: in function `getConstInt':
/home/jochen/projects/amiga/aqb/src/compiler/assem.c:968: undefined reference to `round'
/usr/bin/ld: ../..//target/x86_64-linux/obj/codegen.o: in function `CG_getConstInt':
/home/jochen/projects/amiga/aqb/src/compiler/codegen.c:494: undefined reference to `round'
/usr/bin/ld: ../..//target/x86_64-linux/obj/codegen.o: in function `CG_transBinOp':
/home/jochen/projects/amiga/aqb/src/compiler/codegen.c:1500: undefined reference to `round'
/usr/bin/ld: /home/jochen/projects/amiga/aqb/src/compiler/codegen.c:1500: undefined reference to `round'
/usr/bin/ld: /home/jochen/projects/amiga/aqb/src/compiler/codegen.c:1715: undefined reference to `pow'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:31: ../..//target/x86_64-linux/bin/aqb] Fehler 1
make[2]: Verzeichnis „/home/jochen/projects/amiga/aqb/src/compiler“ wird verlassen

I tested the "Sprite tutorials" which opens a window in Workbench screen. My Workbench runs in DBNTSC screen mode.

SpriteDemo1 : Sprite not displayed
SpriteDemo2 : Runtime error 200 at "ILBM LOAD SPRITE"
SpriteDemo3 : Sprite not displayed

This occurs in screen modes with a horizontal frequency greater than15Khz.

maybe a better error message to find the misuse of RESTORE?
with DATA no error of course

' DATA 42

RESTORE
READ I 

I can't delete the last line by using Ctrl-Y
The last left line!
Not the line at the bottom.

what's the right way to open the windows in the availabe area?
How to get the SCREEN resolution in a BASIC way?

Hello!

My setup:

• Amiga 500+2MB chip ram via ACE2B+ACA500Plus(68000 CPU @ 42MHz, 8 MB fast ram, CF card as HDD)
• AmigaOS 3.2
• Fresh version of AQB extracted to AQB:

What happens:

• When I try open existing source code - all fine(I even can create new file and try make something inside it)
• When I try just run AQB via ICON/CLI/etc - it crashes with Guru 8000 0003 error

I added this option at top of code, but it keeps breaking the execution when CTRL-C is pressed. It seems that this istruction is ignored.

Thank you very much for your effort and dedication on this, AQB is a fantastic and promising project.

My concern

The readme states that "classic 68k Amiga systems" are targeted by the compiler; however, this may still leave room for confusion. For example, while I can guess that the Amiga 500 is very likely supported, I am much less sure about, for example, the CD32, and less sure about the A4000.

Suggestion to fix

A markdown table listing each system, whether it is supported, and the degree of support, such as a percentile; red/yellow/green; bronze/silver/gold/full; and/or a notes and caveats column.

How I think this will help

• It will assist users with an overview of the current support state of a system, and how well AQB can be expected to run on that system.
• It will assist contributors by providing an idea of where to focus their efforts.
  • A contributor who has improved an area of support, can then raise an issue or PR to have the support state of that system changed; which can notify both users and contributors of an improvement in the level of support.

A version tag should be added.

Some makefiles use pushd and popd. But on Ubuntu 20.04 /bin/sh is used by the make tool which seems to be not bash but some other shell which does not know pushd/popd.

/home/jochen/projects/amiga/amiga-build-env/bin/m68k-amigaos-ar -crs _brt.a cstartup.o astr.o amath.o autil.o dyna.o data.o dprintf.o
pushd .. && rm -f startup.o _brt.a && ln -s _brt/startup.o && ln -s _brt/_brt.a && popd
/bin/sh: 1: pushd: not found
make[3]: *** [Makefile:22: _brt.a] Fehler 127
make[3]: Verzeichnis „/home/jochen/projects/amiga/aqb/src/lib/_brt“ wird verlassen

I tried a AQB program in true color (WinUAE with uaegfx):

The CLS in a window did nothing.

If I do open a old school SCREEN first it works.
With hicolor screenmode or 8bit (uaegfx) it works too.
Only true color seems not to work
And it was all on WB 3.9

The Makefile in examples/dev is expecting a file foo.bas which is not found. Should this file be generated somehow or is it just missing in the repository?

The following lines let the IDE crash
I tested in 0.8.2 and 0.9.0

OPTION EXPLICIT

DIM SHARED colr AS Integer

SUB test (split AS Integer)
    colr = split + 4 REM this works
    colr = 16 - split REM this leads to crash
END SUB

...with $HOSTTYPE-$OSTYPE.

these operators are all implemented (no compile or link error)
but all results are FALSE (no pun intended ;)
version 0.8.2 and 0.8.3 show the same

the behaviour seems to be different for constant expressions and expressions depending on variables

You make big progress with the OOP things! Good work!
I think the GadTools support is broken in the oop branch.

some little problems ...

If the IDE window is wider then 80 characters (I often use SuperHires mode 1280x512), the messages wraps unneeded.

If the compiler message wraps, then one character is missed.
In 640x512 are missed more characters - "missing uments" as an example

The produced tab characters in "TRACE a, b, c" should be used like in PRINT - maybe replaced by one SPACE as a simple solution first

The console has only one size. If I write in an extern editor, often I have to fix a lot of small mistakes afterwards - typos, missed THEN after IF, and some more infamous things ;)
It would be easier with a little bigger window size, or without unneeded wraps. Sometimes the first (and most important) message scrolls to far up and I have to fiddle with the mouse to get it. Maybe the ESC key could switch between NO window, 1/4 screen height, 1/2, 3/4
It would be helpful also while using the debugger with lot of variables

BTW: we could "filter the noise": if the actual file is compiled - the path and file name is only noise - nice to have!
BTW: the console should be usable by keyboard - maybe after implementing mouse clicks in the editor - nice to have!

I discovered a way to crash the compiler with the following message:

assertion "0" failed: file "frontend.c", line 726, function: coercion
Program aborted

Attempting to concatenate an integer type to a string will do this every time. For example:
DIM n AS INTEGER
PRINT "HELLO " + n

If I use the type correct "HELLO " + STR$(n), the program seems to work as expected.

The expected result would be either a compiler error (since you can't concatenate strings and numeric types) or an automatic widening conversion (ie: an implicit STR$(n)).

all programs compile, but some crash on start.
All GadToolsTutorials have this problem:

assertion " last_hunk_slot < MAX_NUM_HUNKS"
function: load_hunk_header

or am I wrong?
With TRUE and FALSE in bPSET the lines are looking different
this lines with negativ y are drawn correct only when I PSET a point to the start before.

' try TRUE and FALSE 
DIM AS BOOLEAN bPSET = FALSE

IF bPSET THEN
    PSET (10, -10), 1
END IF
LINE (10, -10) - (50, 100), 1
IF bPSET THEN
    PSET (60, -10), 1
END IF
LINE (60, -10) - (80, 150), 2

WHILE inkey$ = ""
    sleep
WEND

Sorry for reporting that many build problems. I really love the idea of this project and would like to contribute so I try to get this building on my machine.

Here is another build problem, I do not know (yet) where this is coming from:

cp startup.o /home/jochen/snap/fsuae/common/FS-UAE/hdd/Exchange/aqb/lib
../../..//target/x86_64-linux/bin/aqb -d none -s _brt.sym _brt.bas
AQB: env var not set.

make[3]: *** [Makefile:11: _brt.sym] Fehler 1
make[3]: Verzeichnis „/home/jochen/projects/amiga/aqb/src/lib/_brt“ wird verlassen

for positive values the functions HEX$, OCT$, BIN$ are working fine,
but for negative values of BYTE and INTEGER the results are looking strange:

-1 => "FFFFFFFF"

because the parameter is converted to LONG in between.

no big problem, you can use a workaround: first convert to UBYTE or UINTEGER

but anytime it should be fixed

If I open source code two times the path is lost in between.
"The contents of an ASL requester data structure are preserved across calls to AslRequest(). So, until the requester is freed, tag settings and user selections will remain in the data structure unless they are altered by tags in subsequent calls to AslRequest(). This is very useful because it allows the requester to remember and redisplay the user's previous selections. However, this also means that the programmer must assure that any addresses passed in ASL tags remain valid, or are refreshed on each call to AslRequest()."

F1 isn't working in 0.8.2
I think, the file README.guide isn't in place

I am writing a program that uses READ/DATA statements to populate several arrays with code table information, and I keep getting weird results.

I finally wrote a simple test program and came up with a fairly consistent behavior: instead of correctly reading DATA statements, there first element in each DATA statement is replaced by the last statement of the program (usually WEND, in this case.)

Here is an example:

FOR I=1 TO 2
    READ A$
    PRINT A$
NEXT

DATA "HELLO", "WORLD"

WHILE INKEY$=""
  SLEEP
WEND

Output is:
WEND
WORLD

After playing with it more, it seems like the first item on a DATA line will be replaced with the last program statement. So programs with multiple lines of DATA statements will return WEND for the first data item per line, followed by the correct items on that line.

DATA a,b,c,d
DATA e,f,g,h

Would return something like
WEND
b
c
d
WEND
f
g
h

I'm currently using AQB on WinUAE with OS 3.1.4, a 68030 CPU selected, 8MB RAM, 1.5MB Slow RAM, 256MB Z3 Fast 256MB Chip RAM. I am also using the UAE Zorro III RTG module.

I'll try different CPU and memory combinations to see if there's any difference.

I am trying to understand how to change the memory contents of a bitmap_t variable without using the graphic commands.

is the bitmap_t variable something i can use with memset/peek/poke ?

Not really an issue... I just want to extend an invite for you to join us over on the https://gotBASIC.com discord server; I realized that I setup an AQB room (ages ago) and thought to myself this morning after watching @RetroNick2020 most recent video, "self, why don't you invite the author?". I also had to poke him as to why there was no mention of AQB in the video. 🤔 So if you are so inclined, would love to see you over on this discord server sharing tidbits, updates, thoughts, etc. regarding AQB.

https://discord.gg/V9U5dMRs

Hope to see you there!

I tried, but can't find out, how marking a block works in 0.8.2.
Ctrl-M inserts a line break
Ctrl-B works like Ctrl-DOWN - cursor jumps to the last line

Another situation leads to a crash of the IDE in 0.8.2 and 0.9.0

OPTION EXPLICIT

TYPE GameGrid
    player AS Integer
    nTake AS Integer
    cx AS Integer
    cy AS Integer
END TYPE

DIM SHARED GG(8, 8) AS GameGrid
DIM SHARED HUMAN AS Integer

SUB InitGame
    HUMAN = 4
    GG(5, 5).player = HUMAN
END SUB

the compiler in the IDE crashs
just uncomment!

OPTION EXPLICIT

TYPE TypeTest
    inn AS Integer
    boo AS Boolean
END TYPE

DIM SHARED tt AS TypeTest

tt.boo = True

' IF tt.boo THEN
'     TRACE "Crash!"
' END IF

IF tt.boo = True THEN
    TRACE "Okay!"
END IF    

since 0.8.3 the tutorial ILBMShow.bas has a problem - some wrong colors in the image

I dived a little into it:

ILBM LOAD BITMAP picFileName,,, @meta, @cmap
meta.viewModes = 135296: REM this is my workaround - value &H21080 from 0.8.2 - &H80 works too
TRACE SIZEOF(ILBM_META_T): REM in 0.8.2 it is 24 - now 30
TRACE meta.nPlanes: REM 6
TRACE meta.viewModes
FOR i AS integer = 0 TO cmap.numEntries
TRACE i, cmap.colors(i).r, cmap.colors(i).g, cmap.colors(i).B
NEXT i

two strange things:

1. In 0.8.2 viewModes shows the value 135296,
   since 0.8.3 it is zero after LOAD - I think, at least the halfbrite bit is missed
   If you set viewModes to 135296 or &H80 the image shows correct.

2. The TRACE of colors shows values in wrong place
   Every second entry is skipped
   I think in 0.8.2 it was shown right

in the current version SPC() and SPACE$() are equal

SPC() should only be used in PRINT statements and there it should only move the text cursor

looks equal, but not the same results!
often it's -8
but sometimes +8

DIM AS SINGLE s1, s2
s1 = -2
s2 = 3
TRACE "-2 ^ 3", -2 ^ 3, -s1 ^ 3, -2 ^ s2, s1 ^ s2
TRACE "-2 * -2 * -2", s1 * s1 * s1

If the values are very tiny and the "E" is used in STRING, the conversion back leads to a loss of the exponent.

DIM AS single v = -24
PRINT v
v = exp(v)
PRINT v
DIM AS string s = STR$(v)
PRINT s
v = val(s)
PRINT v
v = log(v)
PRINT "log: ", v
s = STR$(v)
PRINT s
v = val(s)
PRINT v

in the help file RefCore.md is the function FREE() mentioned.
When I try to use it, I get "undeclared identifier FREE"
I did not found anything about FREE() anywhere else than in the help file

If you use ' for remarks folding is still working, but indentation is broken in some cases
I think, it should look like this:

SUB test ' test remark
    PRINT "test"    
END SUB    

This happens only if AutoUpdateWB is preloaded (tipically in WBStartup).

My config

A1200 + Blizzard 1230 MKIV + 64MB.
Amiga OS 3.2.1 (the same failure confirmed with 3.2).
Some OS tweaks were applied (MuMove4k (exec in fast), fblit & ftext, ReqAttack), but disabling this tweaks does not solve the problem (It also crashes starting the OS in failsafe mode).
Same problem in AQB 0.8.0 as in 0.8.1.

How to reproduce it

• Ensure that AutoUpdateWB is running (http://aminet.net/package/util/wb/AutoUpdateWB).
• Open the AQB editor and press F1 to open the Help guide.
• Close Help by pressing the "Esc" key or the "close" window gadget.
• Software failure requester appears (error #800000008).

SnoopDos log

Just when Help window closes

169 [1] AmigaGuide® (amigaguide ChangeDir Work:Desarrollo/aqb
170 aqb OpenLib intuition.library Ver 0 OK
171 ReqAttack Open Sistema:Prefs/ReqAttac Read Fail
172 aqb OpenFont xen.font Size 8 OK
173 aqb FindRes MorphOS Fail
174 aqb FindRes MorphOS Fail

You can use a single quotation mark (') instead of the REMstatement.
But it's not possible to type it in the IDE.

it is working for UDT records
but is broken for UDT alias

PRINT and TRACE show different "text"

DIM BB AS BYTE = -10
DIM UB AS UBYTE = -10

TRACE BB; STR$(BB) REM -10 -10
PRINT BB; STR$(BB) REM 246-10
TRACE UB; STR$(UB) REM 246 246
PRINT UB; STR$(UB) REM 246 246

WHILE inkey$ = ""
    sleep
WEND

Does AQB support external hunk (object) files that can be linked. if so does AQB also support auto allocating memory (chip/fast) for the hunk data if the correct flags are set?

FOR id [ AS type ] "=" expr TO expr [ STEP stepExpr ]
    <code>
NEXT [ id1 [ "," id2 [ "," ...] ] ]

I think stepExpr shouldn't be a constant.
It can be useful to calculate it or change it in nested loops.

I can work around it, but I think other BASICs can handle it

My concern

Certain 68k CPUs do not have features other 68k CPUs have; for example, the 68030 does not have floating-point. While this was typically provided through a 68881 or 68882 add-in floating-point chip, this is not guaranteed.

Thoughts on fixing

Some indicator of how this may be handled, such as:

• Only supporting CPUs such as the 68030 if they come with a floating-point unit.
• Noting that software floating-point support may be required on some CPUs.
• A setting or option that returns a compiler error on floating-point, thus allowing a program to be compiled without it.