SB64.AppImage

[AIR]

There was a post on RETROB regarding a desire for a ScriptBasic AppImage that caught my eye.

I decided to accept the "challenge" of making this work.

One of the issues that SB has is that the required paths for the modules and includes need to be absolute, which would normally make creating a usable AppImage impossible.

I ended up cheating a little, creating an AppRun file using Bash.  With this, I was able to make use of the mktemp command, to first create a text version of the config on the fly, and then also create the binary version of the config on the fly as well.

One of the things I did NOT want to do was modify the source in any way to enable either relative paths or the use of environment variables.

Using one of the binary distributions that John created (SBCentOS) I was able to coerce the AppImage to work.

Code: [Select]

./sb64-x86_64.AppImage -D
dll ".so"
module "/tmp/.mount_sb64-xb8OgNk/module/"
include "/tmp/.mount_sb64-xb8OgNk/include/"
maxstep 0
maxlocalstep 0
maxlevel 29666
maxmem 0
Note that above, the full path to the "module" and "include" sections changes each time the AppImage is executed.

Note also that I have not configured this for sbhttpd, only for scriba.

Note that the environment variables contained in the AppRun file are temporary, meaning that they exist only as long as the AppImage is executing and don't modify the persistent environment variables.

The AppRun file:

Code: Bash

1. #!/bin/bash
2.  
3. WORKDIR=$(dirname "$(readlink -f "$0")")
4. export PATH=$PATH:"${WORKDIR}"/bin
5. TEXT_CONF=$(mktemp)
6. BINARY_CONF=$(mktemp)
7. CONFIG="dll \".so\"
8. module \"${WORKDIR}/module/\"
9. include \"${WORKDIR}/include/\"
10. maxstep 0
11. maxlocalstep 0
12. maxlevel 29666
13. maxmem 0
14. "
15. echo "$CONFIG" > "${TEXT_CONF}"
16. scriba -f ${BINARY_CONF} -k ${TEXT_CONF} 2>/dev/null
17. export SCRIBACONF="${BINARY_CONF}"
18. scriba $@
19. [[ -e "${TEXT_CONF}" ]] && rm "${TEXT_CONF}"
20. [[ -e "${BINARY_CONF}" ]] && rm "${BINARY_CONF}"

The sb.desktop file:

Code: [Select]

[Desktop Entry]
Type=Application
Name=sb64
Exec=scriba
Comment=ScriptBasic Programming Language
Icon=debian-logo
Categories=Development;
Terminal=true
TestRun:

Code: [Select]

riveraa@nas:~/src$ ./sb64-x86_64.AppImage testhash.bas
q1 1
q2 2
q3 3
q4 4
q5 5
q6 6
q7 7
q8 8
q9 9
q10 10
AppImage attached.  Created with appimagetool.AppImage, forget the other weird ways to create AppImages.

This is a POC (Proof of Concept), I am not going to maintain this...

AIR.

[John]

Wow!

Thanks AIR for this contribution. It feels like old times. I really missed working with you. Script BASIC wouldn't be where it is today if it wasn't for all the time you invested.

When I upgraded the server to Plesk Onyx, I had to start over with a vanilla CentOS AMI. This will be a good test to see how your SB Linux install works.

This looks much better than the Snap idea I had for SB Linux distros. Hopefully this will get Tomaaz interested in the Script BASIC project.

AppImage Home Page

[John]

One of the issues that SB has is that the required paths for the modules and includes need to be absolute, which would normally make creating a usable AppImage impossible.

I ran into the same issue building the Windows Inno install. I also had to deal with cleaning up the system path from a possible past install.

The video on their website about AppImage was very helpful understanding the concept and use of the product.

[AIR]

It's a shame that there isn't an implementation of AppImage that runs natively under Windows (you can run it in the Subsystem for Linux, but you would be running Linux apps).

I was fooling around this evening with an alternative approach for Windows.

Windows supports VHD's (Virtual Hard Disks) so I wondered what would happen if I set one up and dumped SB onto it.

Well, I was able to actually run the IUP demo with no issues.  I included all the necessary DLL's (Curl, IUP, SDL) but didn't test them all.

This is fully self-contained, no need to copy DLL's into System32.  The way I was able to avoid that was by simply dumping them all to the "lib" folder, and then in the sb.cmd script I created adding that location to the path.

One cool feature of VHD's on Windows (Win10 at least) is that you can mount them with a simple double-click.  The OS will assign a drive letter when mounting, which the sb.cmd script accounts for.

The script sets up the SB environment by performing an on-the-fly configuration similar to how the AppRun I created for the AppImage does.

sb.cmd script:

Code: Text

1. @echo off
2. setlocal
3.  
4. set PATH=%~dp0\bin;%~dp0\lib;%PATH%
5. set ConfigFolder=%~dp0\config
6.  
7.  
8.  
9. echo dll ".dll" > %ConfigFolder%\.conf.txt
10.  
11.  
12. echo module "%~dp0\modules\\" >> %ConfigFolder%\.conf.txt
13. echo include "%~dp0\include\\" >> %ConfigFolder%\.conf.txt
14. echo maxinclude 100 >> %ConfigFolder%\.conf.txt
15.  
16. echo preproc ( >> %ConfigFolder%\.conf.txt
17. echo.   internal ( >> %ConfigFolder%\.conf.txt
18. echo.     sdbg "%~dp0\modules\\sdbg.dll" >> %ConfigFolder%\.conf.txt
19. echo.    ) >> %ConfigFolder%\.conf.txt
20.  
21. echo. ) >> %ConfigFolder%\.conf.txt
22.  
23. echo maxstep 0 >> %ConfigFolder%\.conf.txt
24.  
25. echo maxlocalstep 0 >> %ConfigFolder%\.conf.txt
26.  
27. sb64 -f  %ConfigFolder%\basic.conf -k %ConfigFolder%\.conf.txt > nul 2>&1
28.  
29.  
30.  
31. sb64 -f %ConfigFolder%\basic.conf %*
32.  

Attached is the VHD with the Windows 64bit version of SB. 

Enjoy!!

AIR.

EDIT:  I should mention that unlike an AppImage, a VHD is fully R/W.  So you can add to this at will and the changes will persist.  I've set the VHD as an expandable drive with a 2GB limit.

[John]

I was still chewing on the last candy you left us. Can't wait to try your next serving of SB.

I should mention that unlike an AppImage, a VHD is fully R/W.  So you can add to this at will and the changes will persist.  I've set the VHD as an expandable drive with a 2GB limit.

That makes the virtual drive much more usable.

[John]

AIR,

What are you seeing for MAXINT & MININT with SB64 on Window. My old VC12 64 Windows SB build shows 32 bit maximums but Linux displays and does 64 bit math.



Script BASIC has a couple of built-in functions to give you the MAXINT and MININT ranges. It would be nice to have a set of functions that would do the same for REAL (double) ranges.

Code: Script BASIC

1. PRINT MAXINT,"\n"
2. PRINT MININT,"\n"
3.  
4. PRINT (1/0),"\n"
5.  

jrs@jrs-laptop:~/sb/examples/test$ scriba range.sb
9223372036854775807
-9223372036854775808
undef
jrs@jrs-laptop:~/sb/examples/test$

Those are 64-bit values. The functions only reflect the capabilities of the operating system SB is currently running on but not the capabilities of SB proper. AFAIK SB is only capable of 32-bit integer calc on both 32- and 64-bit platforms, alas.

Code: Script BASIC

1. PRINT FORMAT("%i",9000000000000000000 - 10), "\n"
2.  

jrs@jrs-laptop:~/sb/examples/test$ scriba intmath.sb
8999999999999999990
jrs@jrs-laptop:~/sb/examples/test$


If that's the case my example shouldn't be working. SB has some issues with 64 bit PRINT / FORMAT and REAL. A couple other functions might need work for 64 bit.

[AIR]

AIR,

What are you seeing for MAXINT & MININT with SB64 on Window. My old VC12 64 Windows SB build shows 32 bit maximums but Linux displays and does 64 bit math.

Same as you.  Could be the difference between using an INT instead of LONG in the functions.  INT will always be 32bit, LONG depends on the architecture and could return 32bit or 64bit values depending...

[John]

I'm wondering if it's time for a 32 and 64 bit branch of Script BASIC?

[AIR]

Nope, that won't solve the issue under Windows (at least not with MSVC).

The issue is that Microsoft, in MSVC, defines signed longs as having a range of –2,147,483,648 to 2,147,483,647.  So SB, when compiled with MSVC in 64bit mode, is showing the correct result for MIN_LONG/MAX_LONG according to Microsoft.

MS Data Type Ranges

MS Integer Limits

The second link provides _I64_MIN/_I64_MAX, which would provide the correct ranges for 64Bit when using MSVC.

Any modification to address this most likely would need to happen in mathfuncs.c, wrapped (based on compiler used and "bit-ness") so that it wouldn't break compilation using other compilers.

AIR.

[John]

I would really like to standardize on GCC for all platforms.

Do you think the change needed is something I can do at my skill level?

Can it be as easy as replacing LONG_MIN with _I64_MIN and LONG_MAX with _I64_MAX?

Code: C

1. =section math
2. =display MAXINT
3.  
4. This built-in constant is implemented as an argument less function. Returns the maximal number that can be stored as an integer value.
5. */
6. COMMAND(MAXINT)
7. #if NOTIMP_MAXINT
8. NOTIMPLEMENTED;
9. #else
10.  
11.   /* this is an operator and not a command, therefore we do not have our own mortal list */
12.   USE_CALLER_MORTALS;
13.  
14.   RETURN_LONG_VALUE(LONG_MAX)
15.  
16. #endif
17. END
18.  
19. /**MININT
20. =section math
21. =display MININT
22.  
23. This built-in constant is implemented as an argument less function. Returns the minimal ("maximal negative") number that can be stored as an integer value.
24. */
25. COMMAND(MININT)
26. #if NOTIMP_MININT
27. NOTIMPLEMENTED;
28. #else
29.  
30.   /* this is an operator and not a command, therefore we do not have our own mortal list */
31.   USE_CALLER_MORTALS;
32.  
33.   RETURN_LONG_VALUE(LONG_MIN)
34.  
35. #endif
36. END
37.  

[John]

I think it would be helpful to a SB user to have the following built in functions.

• MININT
• MAXINT
• MINREAL
• MAXREAL

What would be cool is like the case sensitivity option, 32/64 bit math could be toggled to the desired results.

[AIR]

I would really like to standardize on GCC for all platforms.

Do you think the change needed is something I can do at my skill level?

Can it be as easy as replacing LONG_MIN with _I64_MIN and LONG_MAX with _I64_MAX?

The limits.h header should define LLONG_MIN/MAX which is the same as _I64_MIN/MAX.  You would need to update every reference, which would be error prone.

Better to redefine LONG_MIN/MAX when compiling with MSVC in 64bit mode.

Something like (not tested):

Code: C

1. #if (_MSC_VER > 0)     // check if MSVC
2.     #ifdef _WIN64      // check if 64bit
3.        #define LONG_MAX LLONG_MAX
4.        #define LONG_MAX LLONG_MAX
5.     #endif
6. #endif

if you run:

Code: [Select]

grep -rl LONG_MAX *
grep -rl LONG_MIN *at the root of the source folder, you'll get an idea of the files that would need something like this...

Windows doesn't come with grep, but you can do the same with "findstr" (still in the root of the source folder):

Code: [Select]

findstr /S /M LONG_MAX *
findstr /S /M LONG_MIN *

EDIT:

GCC under Windows has the same problem, it appears. (well mingw does from what I can tell).


AIR.

[John]

Thanks for your guidance and support for the Script BASIC project. This gives me something to get started with.

[John]

GCC under Windows has the same problem, it appears. (well mingw does from what I can tell).

The project goal is to standardize on GCC across the board.

[AIR]

[The project goal is to standardize on GCC across the board.

You will still have the 32bit ranges for MININT/MAXINT under Windows using GCC/MinGW, unless you you redefine LONG_MIN/MAX....