Calling the Oxygen DLL

[cevpegge]

 

Okay. I'll go ahead and develop this interface for JIT compiling.

Dawn breaks. I must get some sleep.

Charles

[JRS]

That's great Charles!

Sure is going to open up a world of possibilities for the Windows version of SB.


BTW Are you going to be creating that O2.DLL extension module using Oxygen? If that's possible, creating extension modules for SB will be much easier then using C.

[cevpegge]

Yes making extension modules should be very easy once we crack all those macros. Strictly speaking they create a dependency on compiling with C. All the extension modules are expected to be recompiled whenever the module extension interface is altered.

We have to break that rule and maybe do some reverse engineering on the macros. They seem to be more than the usual header file stuff.

Charles

[JRS]

Peter's use of macros was to simulate a object like API interface. A set of helpers if you may but has been a turnoff to programmers offering to help. I would be happy if a clean, easy to use interface to O2 was the end goal. (even if the O2 extension module interface is compiled with C)  Taking on converting all those macros is a huge task just to make creating extension modules easier.. IMHO
 

[JRS]

Another idea is to run O2 in a thread (like how sbhttpd works now) and use the already existing MT shared memory model. MT has locking for both read/write common variables and can even maintain session variables between iterations. Is O2 thread safe?

SB Thread Support API

MT Shared Variable/Session Management Extension Module

Looking over the developer docs for the interpreter architecture, it seems the thread support functions are part of the scripting engine API. The best way to go might be to used scriba as a base and create a new variation SB02 that seamlessly allows creating O2 threads with shared memory support.

I could simulate this now by using sbhttpd as a local application server. (running as a Windows service) I could use the startup optional program to act as a master and send GET requests via a socket to start a SB threaded script that has O2 embedded.

[cevpegge]

We could try something fairly naive to start with.

Nearly all the Oxygen runtime functions are re-entrant and use stack variables. I suppose that makes them suitable for multithreading. You can run several binaries in different threads - and each would have their own private static space as well as stack locals.  But I don't think you would be able to compile several programs at the same time. (Not that you would need to )

Charles

[JRS]

But I don't think you would be able to compile several programs at the same time. (Not that you would need to)

Are you saying that SB could only run .exe based O2 programs in a thread and using JIT from a string is not possible?

[AIR]

The following worked for me, using v3 of Scriptbasic (32bit) under Win7-64:

Code: [Select]

'---------------------------------
'USING OXYGEN WITH SCRIPTBASIC DYC
'---------------------------------

'ScriptBasic

import "c:/scriptbasic32/include/dyc.bas"


'OXYGEN SOURCE CODE
'------------------

src="""
  print "Greetings from OxygenBasic!"

""" & chr$(0)

dyc::dyc("ms,i,OXYGEN.DLL,o2_mode,L",0)
dyc::dyc("ms,i,OXYGEN.DLL,o2_basic,Z",src)


'how do we make dll calls that have no arguments?
'TRY THIS
e=dyc::dyc("ms,i,OXYGEN.DLL,o2_error,C")
'e=0
if e=0 then
  dyc::dyc("ms,i,OXYGEN.DLL,o2_exec,L",0)
endif
Regarding strings, have you tried returning a POINTER by specifying "P" as the return type?  Not sure it it would work, but I'm just saying.....

A.

[JRS]

I still get a beep when I run your version under v3. Can you zip up and e-mail your v3 scriba.exe to test here?

z specifies that the argument is a pointer that should point to a zero terminated string. The BASIC argument is converted to string and a pointer to the start of the string is passed as actual argument. Note that BASIC strings are not zero terminated and the function dyc does not append the terminating zero character to the string. Thus you have to append a zero character to the BASIC string before you pass it as zero terminated string.

What do you think of using the z argument type using a CHR(0) for the argument value? (zstring with a null value)

Update - (e-mail from AIR)

Code: [Select]

e=dyc::dyc("ms,i,OXYGEN.DLL,o2_error,C")

From the interface.c file:

            case 'c': case 'C': //char
              Parm[i].nWidth  = 1;
              Parm[i].dwFlags = 0;
              if( NULL == Argument ){
                Parm[i].dwArg = 0;
                }else
                switch( TYPE(Argument) ){
                  case VTYPE_STRING:
                    if( STRLEN(Argument) < 1 )
                      Parm[i].dwArg = 0;
                    else
                      Parm[i].dwArg = *STRINGVALUE(Argument);
                    break;
                  case VTYPE_UNDEF:
                  case VTYPE_LONG:
                  case VTYPE_DOUBLE: Parm[i].dwArg = (char)besGETLONGVALUE(Argument); break;
                  default: return COMMAND_ERROR_ARGUMENT_RANGE;
                  }

With no argument, nothing extra should be passed.  It worked fine for me user 3.0

A.

[JRS]

Regarding strings, have you tried returning a POINTER by specifying "P" as the return type?  Not sure it it would work, but I'm just saying.....

I think I tried P and L as return types and the same numeric value is returned as I.

It's times like this when I wish there was a PEEK/POKE function call in the NT extension module.  

[AIR]

I think "Z" will still place something extra on the stack.

Unless you're talking about the return type, which glancing at the code doesn't exist:

Code: [Select]

      case 1: // define the return value using a single character
        if( cbFormat < 1 )return COMMAND_ERROR_ARGUMENT_TYPE;
        cRet = tolower(*pszFormat);
        switch( cRet ){
          case 'I': case 'i': nRetSiz = sizeof(int);    break;
          case 'L': case 'l': nRetSiz = sizeof(long);   break;
          case 'P': case 'p': nRetSiz = sizeof(void *); break;
          case 'F': case 'f': nRetSiz = sizeof(float);  break;
          case 'D': case 'd': nRetSiz = sizeof(double); break;
          case 'V': case 'v': nRetSiz = sizeof(__int64);break;
          default: return COMMAND_ERROR_ARGUMENT_RANGE;
          }
I'm using the standard v3, nothing special.  What may be different is that I don't have extra items in my system or user paths by default.  I run various scripts to set my environments for SB, MinGW, Python, Ruby, etc as needed to avoid potential problems or to use different versions without conflicts.


A.

[AIR]

Regarding strings, have you tried returning a POINTER by specifying "P" as the return type?  Not sure it it would work, but I'm just saying.....

I think I tried P and L as return types and the same numeric value is returned as I.

It's times like this when I wish there was a PEEK/POKE function call in the NT extension module.  

I think that's because the return value is the address and not the content.

[JRS]

I'm confused then.

I have two directories in my C:\ root.

C:\scriptbasic_2.1
C:\scriptbasic_3.0

All my paths and registry settings are based on ...

C:\scriptbasic

I just rename the _2.1 or _3.0 to C:\scriptbasic and go. the 2.1 version works and the 3.0 doesn't.

C:\scriptbasic\test>scriba -v
ScriptBasic v3.0
Variation >>STANDARD<< build 1
Magic value 859002680
Node size is 16
Extension interface version is 11
Compilation: Jul 18 2010 12:51:07
Executable: C:\scriptbasic\bin\scriba.exe

Just ran the same thing on my laptop and 3.0 doesn't run there either while 2.1 runs fine.

Are we running the same builds?

Update

For grins I copied the v3 scriba to my 2.1 C:\scriptbasic\bin and no joy. (BEEP)

[AIR]

C:\scriptbasic32\Oxygen>scriba -v
ScriptBasic v3.0
Variation >>STANDARD<< build 1
Magic value 859002673
Node size is 16
Extension interface version is 11
Compilation: Jul 11 2010 20:06:51
Executable: C:\scriptbasic32\bin\scriba.exe

Attached is my version.

The only other difference is that I have the Oxygen.dll in the same location as the test file.  That, and I don't use a scriba.conf file.

[JRS]

Thank You !

Your v3 scriba.exe works (July 11, 2010) and my v3 (July 18, 2010) doesn't.

I'll check what version is on the SB forum in the download section.

This drove me NUTS !

I may be wrong but wasn't that July 18th build an experiment of dropping the pthread reference in the build?