ScriptBasic O2h Embedding

[Charles Pegge]

John,

Tthe next step is to combine SBO2 with the interfacing software of Mdlt and create an SBOxygen module.

Most of Windows GUI programming is best done Oxygen script. and frequently used procedures can be passed down into SBOxygen. So they are precompiled.

My knowledge of SQL is theoretical at best. Could you show me some stock examples of SB using SQL? Do the modules return data in arrays or as splittable text.

I am currently working on '->' pointer notation so that Oxygen can understand C header macros that contain them.

Charles

[JRS]

Here is the post I made on the second page of this thread that shows both SB embedding itself and a SQLite scripted demo. Where I have a problem is understanding how to use the SQLite C header in O2. Once I got that down, the rest should go smoothly.

Is the O2 ext. mod. going o be like DYC but smarter? Or will it be a framework to create SB extension modules without having to use C?

[JRS]

Here is what I have come up with. I attached the self contained SQLite3 console shell to use if you need it.

Code: [Select]

' #include <sqlite3.h>

extern stdcall lib "sqlite3.dll"

  int sqlite3_open(
    const char *filename,   /* Database filename (UTF-8) */
    sqlite3 **ppDb          /* OUT: SQLite db handle */
  );
  
  int sqlite3_exec(
    sqlite3*,                                  /* An open database */
    const char *sql,                           /* SQL to be evaluated */
    int (*callback)(void*,int,char**,char**),  /* Callback function */
    void *,                                    /* 1st argument to callback */
    char **errmsg                              /* Error msg written here */
  );
  
  int sqlite3_prepare_v2(
    sqlite3 *db,            /* Database handle */
    const char *zSql,       /* SQL statement, UTF-8 encoded */
    int nByte,              /* Maximum length of zSql in bytes. */
    sqlite3_stmt **ppStmt,  /* OUT: Statement handle */
    const char **pzTail     /* OUT: Pointer to unused portion of zSql */
  );
  
  int sqlite3_step(sqlite3_stmt*);  /* Evaluate the statement */
  
  const unsigned char *sqlite3_column_text(sqlite3_stmt*, int iCol);  /* The "result set" interface */
  
  int sqlite3_close(sqlite3 *);  /* Destructor for the sqlite3 object */

end extern


[attachment deleted by admin]

[Charles Pegge]

Thanks John,

That example will help me to understand how SQL is setup and used.

I can produce a simple header based on this information:

http://www.sqlite.org/c_interface.html

I envisage SBOxygen as starting out with Dyc + compiler functionality and developing into a framework by acquiring commonly used functions to lighten the burden for source scripts. Windows GUI coding is cumbersome and a selection of standard GUIs will often suffice in many applications.

Charles

[JRS]

I just finished looking over your besNotes.txt file and the #define work looks like a major effort on your part. I would like to try working with the defines if possible. Have you done any preliminary testing of the SB API via these defines?

[Charles Pegge]

Hi John,

I've made a few enhancements to Oxygen towards supporting bes macros and other #defines.

Here are the major ones:

Support C Arrow Notation: ->

The arrows can be used interchangeably with dots since Oygen automatically resolves indirection.

Support classical C function tables

Code: [Select]

  typedef struct _tb
  {
  long (*f1)(long*s)
  long (*f2)(long*s)
  long (*f3)(long*s)
  zstring (*s1)(long*s)
  zstring (*s2)(char*s)
   long (*s3)(char**s)
  } tb,*ptb

(C++ style classes makes this notation obsolete.)


Allow #defines inside types and typedefs.



But There is still some more work to do before we can use the bes headers directly.

Charles

[JRS]

It looks like your close to being able to deal with ANSI/ISO C structures transparently in O2. This should make working with C libraries effortless.

I'm looking forward to using O2 with SB. I will be even more overjoyed when there is a native O2 for Linux.

Now that you have had time to unravel SB at the developers level, what is your take on Peter Verhas's effort?

[Charles Pegge]

John,

I ought to study the Ansi C standard.

I have not gone much beyond exploring Peter Verhas' headers. They are well documented though not easy to work through due to the macros. The intensive use of function tables is a kind of OOP though C does not lend itself to clean coding in this paradigm and I am sure that was one good reason to offer the macros:  to make modules readable by hiding the internal complexity.

Charles

[JRS]

The macros seem to be a double edge sword. For the extension module builder, the macros are a big time saver. (if using C) I hope the O2 extension generates new interest in SB on the Windows platform.

I think the work you doing for the SB interface has value beyond just this interface. I think its great O2 is more compatible with C resources and everyone will benefit from it.

 

[JRS]

Charles,

I'm trying to get the GNU Scientific Library (GSL) working with DYC.

Code: [Select]

DECLARE SUB DLL ALIAS "dyc" LIB "dyc"

dv = DLL("ms,d,libgsl.dll,gsl_sf_bessel_J0,d",5.0)

PRINT dv,"\n"

1.057783e-307

Based on the results compiled native with gcc under Ubuntu 64, the results for this function don't match.

Code: [Select]

#include <stdio.h>
#include <gsl/gsl_sf_bessel.h>

int
main (void)
{
  double x = 5.0;
  double y = gsl_sf_bessel_J0 (x);
  printf ("J0(%g) = %.48e\n", x, y);
  return 0;
}

gcc -Wall intro.c -lgslcblas -lgsl -o intro

J0(5) = -1.775967713143382642471124199801124632358551025391e-01

Any ideas what might be going wrong?

Update

I figured out what was missing.

dv = DLL("ms8,d,libgsl-0.dll,gsl_sf_bessel_J0,d",5.0)

C:\scriptbasic\test>scriba testgsl.sb
-1.7759677131433826e-001
C:\scriptbasic\test>

GSL.zip

[Charles Pegge]

Hi John,

A quick look at the DYC source:

Code: [Select]

     case 0: //define the call type
        switch( *pszFormat ){
          case 'm': case 'M': Flags |= DC_MICROSOFT;    break;
          case 'b': case 'B': Flags |= DC_BORLAND;      break;
          case 'c': case 'C': Flags |= DC_CALL_CDECL;   break;
          case 's': case 'S': Flags |= DC_CALL_STD;     break;
          case '4':           Flags |= DC_RETVAL_MATH4; break;
          case '8':           Flags |= DC_RETVAL_MATH8; break;
          case ',' : iParseState++; break;
          }


Code: [Select]

    else if (Flags & DC_RETVAL_MATH8) {
        _asm fstp qword ptr [Res]
    }

This means the float double result is taken from the FPU stack
Charles

[JRS]

This means the float double result is taken from the FPU stack

Finally you can specify 4 or 8 to specify that the function is returning a four or eight-byte floating point number. Although this is a kind of return value specification, it is stated here, because this affects the calling convention. These values are returned not in a memory place from the function but rather in the co-processor register and function dyc has to know to fetch them from there rather than expection the function to return a four or eight-byte memory chunk.

[JRS]

Charles,

I converted one of the GSL examples to display all the combinations of a number set.

Code: Text

1. #include <stdio.h>
2. #include <gsl/gsl_combination.h>
3.  
4. int
5. main (void)
6. {
7.   gsl_combination * c;
8.   size_t i;
9.  
10.   printf ("All subsets of {0,1,2,3} by size:\n") ;
11.   for (i = 0; i <= 4; i++)
12.     {
13.       c = gsl_combination_calloc (4, i);
14.       do
15.         {
16.           printf ("{");
17.           gsl_combination_fprintf (stdout, c, " %u");
18.           printf (" }\n");
19.         }
20.       while (gsl_combination_next (c) == GSL_SUCCESS);
21.       gsl_combination_free (c);
22.     }
23.  
24.   return 0;
25. }
26.  

jrs@laptop:~/C/gsl/doc/examples$ ./combo
All subsets of {0,1,2,3} by size:
{ }
{ 0 }
{ 1 }
{ 2 }
{ 3 }
{ 0 1 }
{ 0 2 }
{ 0 3 }
{ 1 2 }
{ 1 3 }
{ 2 3 }
{ 0 1 2 }
{ 0 1 3 }
{ 0 2 3 }
{ 1 2 3 }
{ 0 1 2 3 }
jrs@laptop:~/C/gsl/doc/examples$

Code: Text

1. DECLARE SUB DLL ALIAS "dyc" LIB "dyc"
2.  
3. CONST GSL_SUCCESS  = 0
4.  
5. PRINT "All subsets of {0,1,2,3} by size:\n"
6.  
7. FOR i = 0 TO 4
8.   c = DLL("ms,l,libgsl-0.dll,gsl_combination_calloc,ll", 4, i)
9.  
10.   DO
11.     PRINT "{"
12.     DLL("ms,i,libgsl-0.dll,gsl_combination_fprintf,llz", 0, c, " %u")
13.     PRINT " }\n"
14.   LOOP WHILE DLL("ms,i,libgsl-0.dll,gsl_combination_next,l", c) = GSL_SUCCESS
15.   DLL("ms,i,libgsl-0.dll,gsl_combination_free,l", c)
16. NEXT
17.  

The program gets as far as printing the blank combo before giving an exception error. My guess is I'm not providing a pointer to STDOUT.

Backtrace:
=>0 0x7ec95669 MSVCRT_fwrite+0x29() in msvcrt (0x0033ecb4)
  1 0x7ec97222 MSVCRT_vfprintf+0x151() in msvcrt (0x0033f524)
  2 0x7ec9774b MSVCRT_fprintf+0x2a() in msvcrt (0x0033f544)
  3 0x6ef53430 gsl_combination_fprintf+0x2f(stream=(nil), c=0x111c10, format="
u") [d:\gslNew\combination/file.c:73] in libgsl-0 (0x0033f574)
  4 0x1000224b in dyc (+0x224a) (0x0033f5c0)
  5 0x10001cd2 in dyc (+0x1cd1) (0x0033f868)
  6 0x00453915 in scriba (+0x53914) (0x0033f8d8)
  7 0x00412e38 in scriba (+0x12e37) (0x0033f8f4)
  8 0x004137cd in scriba (+0x137cc) (0x0033f948)
  9 0x0044de97 in scriba (+0x4de96) (0x0033f978)
  10 0x00412e38 in scriba (+0x12e37) (0x0033f994)
  11 0x00403dc3 in scriba (+0x3dc2) (0x0033f9a8)
  12 0x00402179 in scriba (+0x2178) (0x0033fe50)
  13 0x004557a5 in scriba (+0x557a4) (0x0033fe90)
  14 0x7b85899c call_process_entry+0xb() in kernel32 (0x0033fea8)
  15 0x7b85963f ExitProcess+0xc9e() in kernel32 (0x0033fee8)
  16 0x7bc72e68 call_thread_func+0xb() in ntdll (0x0033fef8)
  17 0x7bc75920 call_thread_entry_point+0x6f() in ntdll (0x0033ffc8)
  18 0x7bc4aa0a call_dll_entry_point+0x629() in ntdll (0x0033ffe8)

Is there a Windows API call I could use to get the pointer to STDOUT? I noticed there isn't a void return type option with DYC. The best place to add VARPTR, STDIN/OUT pointers, alloc/free function pointers and basext.h is DYC until you get the SBOxygen extension module working. Can I use what we have to provide the STDOUT pointer?



John

[Charles Pegge]

Hi John,

If you want to call a void or sub then it is safe to set the return type as i.
the value in the EAX register is read and assigned to a mortal integer which can be safely ignored.

DYC needs a few extras. The main problem for Oxygen was calling a function without any parameters.

I've been thinking about the best way to handling parameters that need to be passed byref. I think using '*' notation would be widely understood:
L*D*D*C** etc.

To recover output values an additional function is required:
x=result(1)
y=(result(2) ...

With regard to GSL, I'm not sure what is happening. It can't be STDOUT since manages to display something. It could be the calling convention. If it requires CDECL and you give it STDCALL it will accumulate stuff on the stack and eventually fail after a few calls.

Charles

[JRS]

It can't be STDOUT since manages to display something.

The something is being printed using the SB PRINT statement. The fprintf() function needs a pointer to STDOUT to work.