DIM?() and UBOUND() and various dialects of BASIC

[Victor]

Congratulations for this wonderful program!
I am using it on a Galaxy S3 phone and also in Windows 7 for testing.
Because the program is in development I would like to share a few remarks.

[1]
In order do write procedures for arrays without transmitting the
dimensions, a basic function would be very useful
For example, if DIM a(m,n) then
DIM?(a(),1) should return m and DIM?(a(),2) should return n.

For the moment I use
b() = a(:,0)
and DIM?(b()) returns m, but
a) This generates some warnings ("type mismatch")
b) A direct DIM?(a(:,0))
does not work.

[2]
I see that the product of matrices a()b() works but not as expected.
If a() and b() are square matrices (same dimension of course)
then a()b() returns actually b()*a().
I can cope with this, but if the matrices are rectangular the result
is always wrong. I think that this should be solved because it is a
fundamental operation for matrices. It can be of course implemented
by the user but the speed will be slower (see also [1]).

[3]
There is a strange behaviour when the phone changes
the orientation portrait <--> landcape.
In this situation if the program is launched via a widget
or via the .bas file, it restarts!
This happens even with a simple program like
FOR i=1 TO 20
PAUSE 1
PRINT i
NEXT i
END
If the program is launched from X11Basic, it runs as expected.

Thank you,
V.

[Markus Hoffmann]

Hi Victor, thank you for the feedback. Yes, the matrix functions are not perfect yet. Extending the DIM?() is a good idea. I think it would be most consistent to make DIM?(a(:,0)) and similar work.
[2] hm, a()*b() looks buggy. I need to do some tests here. There should also be a c()=MUL(a(),b()) function. Do you know a product for three and more dimensional arrays? The algorithm sould be independant of the dimension.

[3] this is agood

[Markus Hoffmann]

[3] this is a good point. This error was reported several times but I couldnt reproduce it, because i did not know that it occurs only when x11-basic was called from a shortcut. Thanks. Now I have a chance to debug it.

[Victor]

I don't think that a product for arrays with >2 dimensions should be implemented.
But the product should take care of vectors.
For now there exist 3 types of objects corresponding to an element of the Euclidean space:
1. vector: DIM v(n)
2. row matrix: DIM a(1,n)
3. column matrix: DIM b(n,1)

Besides the usual x() * y() where DIM x(m,n),y(n,p) one should have
1. x() * v() ==> v() identified with a column matrix
2. v() * y() ==> v() identified with a row matrix
3. v1() * v2() ==> dot product (real number, provided that the vectors have the same dim)

May be in (1) and (2) the result could be a vector rather than a matrix
(this is not very important because e.g. a column matrix c(n,1) can
be converted to a vector via c(:,0)).

Best regards, I appreciate very much your work,
V.

[Victor]

1. According to the documentation, LPEEK(ARRPTR(a())) - and also LPEEK(VARPTR(a()))
   gives the number of dimensions for an array a().
   It is 2 for a standard 2 dimensional matrix.
   Is it possible to find in a similar way the number of rows and columns?
   (until dim? and the slice operator ":" will work flawlessly).

2. The GRAPHMODE command seems to be ignored in both Windows and Android.
   Any chance to make it work?
   Same question about opacity in COLOR_RGB.

[Markus Hoffmann]

1. you can use ARRPTR() on arrays. But you should not use VARPTR(), al though it gives the same result at the moment.
   LPEEK(ARRPTR(a())) returns the dimension of the array.
   LPEEK(lpeek(arrptr(a())+4)+4*i) returns the length of the i-th dimension of the array. For an 2-dimensional array i can be 0 or 1. This will only work on the 32bit Version of X11-basic. If you have compiled it for 64Bit it will not work. Android and Windows are 32bit.

Currently you can get following information on ARRPTR():
d%=LPEEK(ARRPTR(a())) -- dimension
p%=LPEEK(ARRPTR(a())+4) -- pointer to the index-list
t%=DPEEK(ARRPTR(a())+8) -- the type of the array

The contents of the array starts at the memory-location:
p%+8*d%

[Markus Hoffmann]

1. GRAPHMODE works only on displays with a palette. You can use GRAPHMODE 1 or 2 to modify the appearance of TEXT on all screens. Thats all.
   The opacity in COLOR_RGB can work in the SDL-Driver (WINDOWS version) but will not on Android. I have not used nor tested it. So I fear that it does not work even on WINDOWS. Al though Android supports the alpha channel on graphics, X11-Basic does not so far, because it uses it own graphic engine.

Sorry. These issues are all on the TODO List.

[Victor]

Thank you Markus for the info, it works!
So, we can define the standard Basic command:
DEFFN ubound(x(),i) = LPEEK(LPEEK(ARRPTR(x())+4)+4*i) - 1

About GRAPHMODE: it seems that in Android it is completely ignored (even for mode = 1 or 2).
For example if in the provided "Analogic clock" program we comment out (or remove)
the GRAPHMODE lines, the program runs exactly the same.

Another issue found in the same prog:
the documentation says that DEFTEXT affects only LTEXT (and not TEXT).
But DEFTEXT 1 makes TEXT to ignore SETFONT. That is why the digits of the
Analogic Clock are too small (in a 720x1280 pixels phone).

And a last question. Is it possible to have a full screen
(without the logo) in the case we desperately need the extra 100 pixel rows?

Best regards,
V.

[Markus Hoffmann]

yes, good idea. I am going to add the ubound() function into the next version 1.23-18. Then it will also work on 64 bit systems....

[Markus Hoffmann]

Full-screen in Android: In the Menu->Settings there are options to hide the status bar and the title bar. This would give you the full screen. But: I have disabled it, because with removing the title bar, the MENU button is removed on devices, which do not have an hardware button for MENU. So the menu would be gone forever on these devices. I have no solution to this.

Fullscreen-Command: There is a command forseen to switch to fullscreen: ROOTWINDOW
But it only works on Linux.

Let me have a look at the GRAPHMODE bug:

On WINDOWS: no effect.
On UNIX/Linux: works as expected.
On Android: works differently: One can set the transparency for allgraphics commands in following way:
switch (n) {
case GRAPHMD_REPLACE:FB_set_alpha(255);break;
case GRAPHMD_TRANS:break; // no effect
case GRAPHMD_XOR:break; // no effect
case GRAPHMD_ERASE:FB_set_alpha(127);break;
case 5:break; // no effect
default:
if(n>=0) FB_set_alpha(n);
else FB_set_alpha(-n);

This is probably not a good solution, because the command would have differnt effects on different operating systems. At least the behaviour on WINOWS could be adapted to have the same effect as on Android.

[Victor]

I just want to say that anyway there are several commands acting
differently in Windows and Android.
For example CIRCLE, PCIRCLE ignore the angles and DEFLINE ignores thickness in Windows. See also TIMER.

[Victor]

Hello,

I needed the FILL command and I found a strange bug.
Here is a minimal example:

---

clearw
color color_rgb(1,1,0)
circle 300,200,100
color color_rgb(1,0,0)
! gprint ! uncommented ok
fill 500,200
showpage
end

---

FILL fails but uncommenting gprint, it works.
Note also that the 3rd parameter in FILL seems to be ignored.

Best regards,
V.

[Markus Hoffmann]

this should be fixed in version 1.23-17.

[Wanderer]

Hello everybody,

I am jumping into this tread, since its topic is related to the bug reports I am submitting further down.

First of all, thank you Markus for developing X11-Basic. It looks promising, especially for the special features normally not found in a free compiler/interpreter: String compression, matrix operations, arbitrary precision numbers... Also the capacity of developing and testing a program on a Windows or Linux PC and then easily porting it to Android is great. - Although its usefulness on Android devices is somewhat limited, at least for other users, as long as it cannot create APKs. (If I understand correctly the discussion about this point, this has not yet been solved, has it?) If I want to share an X11B program and tell people to "install X11-Basic and then run myprogram.b in the interpreter", the average user will not have a clue about what to do.

Anyway, I spent some time testing the Windows and the Android versions (both Version 1.23-16), and would like to report the bugs I found so far. I tested the Windows version on a Pentium IV running Windows XP SP2, and the Android version on an LG E410g phone running Android 4.1.2 (Screen resolution 320x240). Some of the bugs occur only on one of the two platforms.

ELSE IF:

In the Windows version, IF..ELSE IF.. blocks do not work properly. If the first IF condition is not met, execution jumps directly to the last ELSE without evaluating the ELSE IFs. For example in the following code segment:

input m

if m<2

  print "Small"

else if m<10

  print "Less than 10"

else if m<20

  print "Less than 20"

else

  print "Large"

endif

If m is larger than 2, the programs prints always "Large".
In the Android version it worked correctly.

In order to achieve the correct behaviour in the Windows version as it is now, I had to code:

input m

if m<2

  print "Small"

else 

  if m<10

    print "Less than 10"

  else 

    if m<20

      print "Less than 20"

    else

      print "Large"

    endif

  endif

endif

PUT (Graphics):

Transparency and PUTting of only a section of the bitmap do not work: When trying to do this, the compiler complained about "too many parameters". The "scale" parameter is the last one which it accepts. (Both Win32 and Android version.)

The Android version of the compiler crashed when trying to PUT an 8-bit paletted bitmap previously loaded from a file. In some instances there appeared a report which said the crash was due to a "Division by zero" error. From the report I could also verify that the bitmap data had been loaded correctly; so that was not the problem.
With a 24-bit bitmap it worked correctly, except:
-When the x,y coordinates are negative, the bitmap is not displayed at all.
-When parts of the bitmap are off the right side of the screen, they wrap around and are displayed on the left side of the screen.
On the Windows version I did not find any of these problems.
So far I did not test with any other BMP formats except 8-bit and 24-bit.

Test code:

If Not exist("test.bmp")

  Print "File not found."

  End

EndIf

bmp$ = Space$(size("test.bmp"))

BLoad "test.bmp", VarPtr(bmp$)

Color get_color(65535,32000,0)

For i%=0 To 40

  clearw

  graphmode i% Mod 5            ! had no effect

  pbox 100,100,150,150

  Put 50+3i%,50-2i%,bmp$, 1.5 !, 15 !Scale was accepted, Transparency not.

  showpage

  pause 0.1

Next i%

PUT_BITMAP:

On the Windows version, neither GRAPHMODE nor COLOR affected the behaviour of this statement: The bitmap appeared always black and white, without transparency. Also, it was color-inverted (0=white, 1=black).
On the Android version, the bitmap was not displayed at all.

Test code:

bmp$ = "<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<"  ! CHR$(60) = %00111100

graphmode 4

Color get_color(65535,65535,0), get_color(32000,0,32000) 

pbox 90,108,120,120

put_bitmap bmp$, 100,100, 16,16

showpage

DEFLINE:

Had no effect on the Windows version: all lines were drawn 1 pixel wide. (Tested LINE, POLYLINE, SCOPE, LTEXT, BOX.)
Worked as expected on Android.

POLYLINE:

Inconsistent behaviour between platforms: If the first and last point are different, the Windows version closes the polygon; the Android version leaves the line open.

SETFONT:

SETFONT "8x16", "LARGE", etc, had no effect on GPRINT nor on TEXT; always the same font was used. Both on Windows and Android.

COLOR_RGB:

Using this statement caused several kinds of errors, mostly compiler crashes. (On both Windows and Android.) In some cases, when a program began with "COLOR COLOR_RGB(1,1,0.5), COLOR_RGB(0,0,1)", the compiler issued an error message saying that the first occurring string variable had an "illegal variable name". Sometimes this produced other subsequent errors, such as "PC negative". I could not find a consistent pattern in these errors, so I did not record them in detail. Replacing COLOR_RGB by the corresponding GET_COLOR statements fixed these issues.

ALERT:

With both versions (Windows and Android), displaying an ALERT box destroyed the color values set by a previous COLOR statement: subsequent graphics were drawn black.

Test code for several of the above:

color get_color(65000,65000, 32000), get_color(32000,0,32000)

'color color_rgb(1,1,0.5) color_rgb(0.5,0,0.5)  ! caused crash!

defline 4,5

deftext 0, 0.1, 0.18, 0

dim x(100), y(100)

for i=0 to 99

  x(i) =125+100sin(i/15)

  y(i) =150+80cos(i/15)

next i

scope x(), y(), 0

polyline 25, x(),y(),-10,-40

Line x(10),y(10),x(60),y(60)

box 5,50,25,75

pbox 2,2,100,40

ltext 0,200,"A test"

showpage

alert 0, "Edit this line:|"+chr$(27)+"What?", 0, "OK", click, t$

setfont "LARGE"

gprint t$

ltext 0,20,t$

showpage

SPEAK:

On my phone, X11-Basic crashed when using SPEAK. A message appeared (apparently from the system, not from X11-Basic): "We are sorry. X11-Basic has crashed." The funny thing was that after X11-Basic was already gone, you could still hear the first few sentences spoken; so the speech engine by itself DID work.
At first I thought the crash might be due to the localizer "de" used in your test program. But when I used SPEAK without localizers, the same thing happened.

• The following two are not exactly bugs, but I would still like to mention them:

Touchscreen and Graphics display:

On the Android version, it seems that retrieving touchscreen ("mouse") data sometimes causes following statements to be ignored. In the following program section which traces lines where the user "draws" on the screen, I had to insert a PAUSE statement immediately after MOUSE, and then it worked (almost) correctly. Without the PAUSE (or with the PAUSE in another place of the loop) about half of the lines were not drawn:

repeat

  mouse msx%, msy%, btn%

  pause 0.1

  state% = btn% and 7

until state%

repeat

  mouse msx2%, msy2%, btn%

  pause 0.1         !! was necessary HERE to display all lines.

  line msx%, msy%, msx2%, msy2%

  showpage

  msx%=msx2%

  msy%=msy2%

  state% = btn% and 7

until state%=0

(This may not be an issue on faster devices, but on mine it was.)

SIZEW, MOVEW:

This is more a feature request: It would be great if it were possible, at least on Android devices (some of which have a very small screen), to define a window which is larger than the physical screen, and allow negative coordinates in MOVEW, so we could allow the user to navigate in a display which is larger than the actual screen.

[Markus Hoffmann]

Hi Wanderer, thank you for the detailed error reports. Let me correct them one by one:

The following code runs in the interpreter (WINDOWS and ANDROID), but the compiler has a bug, which caused a behaviour, even different from the one descibed above: If the first condition is not met, always "Less than 10" was printed. Good news: I have found and corrected it, the next version will have that corrected. The behaviour should be the same on all OS-Platforms.

input m

if m<2
print "Small"
else if m<10
print "Less than 10"
else if m<20
print "Less than 20"
else
print "Large"
endif
quit

By the way: The compiler needs the QUIT (or END) at its last line,

[Markus Hoffmann]

COLOR_RGB: I could not reproduce any error with it. Can you post an example program, which produces a crash?

[Wanderer]

Thank you for your quick reply.
The graphics test code I posted above produced these problems when the line containing "color get_color ..." is commented out, and instead the next line (containing color_rgb) is uncommented.
In order to use it as a complete program, you would have to add at the end something like:
input dummy$
end

By the way, I have not yet found out how to get correct code formatting on this forum. It looks like two asterisks got lost in that test code; the two lines in the for..next loop should be:
x(i) =125+100*sin(i/15)
y(i) =150+80*cos(i/15)
Now I got this right, but I also wonder why my formatted code is displayed with double spaced lines...

[Wanderer]

Hello Markus,

now I've had some time to look again into this COLOR_RGB issue. I found that you are right, and I apologize for having led you down a false trail: The problem was not caused by the COLOR_RGB statement.

The issue was that I had set the compiler (via commandline) to produce a *.b file and to run that one. (I had used this setting for a "real" program and then forgot to change it.) Now, the line containing COLOR_RGB had a syntax error: you will notice that there is no comma between the two COLOR_RGB statements. In spite of this error, in my first tests the compiler had created a *.b file (obviously a faulty one) and tried to run that; and that was what caused the crash. So the real issue was that the compiler did not abort compilation when encountering that error, but produced a screwed-up *.b file; and that caused so many error messages that I could no longer see the initial one about the syntax error.

[Markus Hoffmann]

SPEAK: On my phone it works. But when it says: "We are sorry. X11-Basic has crashed." there is a possibility to send a bug-report to the developer (me). It contains information about the system service which has that problem and could help me fix it.

[Wanderer]

I will try to get that report next time it happens. But I do not have internet connection on my phone, so I would have to find a way to save the report to a file.

[Wanderer]

About the crash after SPEAK: The error message was not the long one which allowed to send a report, but only a short one with an OK button and nothing else.
But in the meantime I found out that this problem occurred only when I had previously run another test program which tested AFTER/EVERY and SOUND. The code of that program was:

wave 0,3
every 0.5, play(259, 0.4)
input m
end

procedure play(freq,dur)
 sound 0,freq,0.5,dur
 print "(";
return

Another version had instead of the two lines with "EVERY" and "INPUT":

after 1, play(256,0.4)
after 1.5, play(320,0.4)
after 2, play(384,0.4)
after 2.5, play(320,0.2)
after 2.75, play(288,0.2)
after 3, play(256,0.9)
pause 4
end

Both versions did not play any sound. I heard only a soft click (probably indicating that sound output was initialized), but no sound played, and only one single "(" was printed.

Only when I tested SPEAK after running this test program, the crash formerly described occurred. The problem remained even after exiting X11-Basic and restarting it. It disappeared only after a complete reboot of the device.

[Markus Hoffmann]

Hm, Maybe it is not a good idea to run the SPEAK command out of an interrupt routine (AFTER and EVERY) Android does not like that. It would be better to just write a flag into a variable and then let the main program do the SPEAK, by polling the variable with the flag. ALSO SPAWN and FORK() may or may not work on Android.

[Markus Hoffmann]

Ok, i see what is wrong: only one AFTER command can be processed at once. AFTER and EVERY both set a timer which excecutes the specified subroutine. Each new AFTER or EVERY command will overwrite the timer also when it has not triggered so far. I use the system timer, and there is only one. I understand how you want to use the commands, this would really be nice, but sorry, this is not the way it is implemented. Maybe i get a good idea how i could change that in future.

[Wanderer]

Windows has an API function which could handle it; I think it is called SetTimer. I suppose other OSes have similar functionality, but I am not knowledgeable about that.

[Wanderer]

I have posted in the "Programs" section an example how multiple timers could be implemented without using OS functions, only using TIMER and a "timer manager" function which must be called continuously while waiting for user input. If you could implement something like this in the X11-Basic source code, you could use AFTER and EVERY for multiple procedures at the same time.