Script Engine BETA 10

[hutch--]

Mods in this version are mainly internal but I have renamed one function and added another to compliment it. The buffer$ function has been renamed to zalloc$ and another function zenlarge$ has been added so that the original buffer can be reallocated on the fly. This is useful if you don't know what the final file size will be so you can allocate a reasonably small buffer and when the write position is close to the end you can enlarge the buffer. This is the script to demonstrate the new function. The buffer$ name still works but I will remove it later.

Code Select Expand


; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

    INTEGER cntr
    INTEGER spos
    INTEGER blen
    INTEGER indc

    STRING buf$
    STRING num$
    STRING shw$

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

    blen = 1024                     ; set the buffer length
    indc = blen                     ; load it into the indicator
    sub indc, 16                    ; set the indicator below the buffer size

    buf$ = zalloc$ blen             ; allocate a start buffer

    spos = 0                        ; start appending at the beginning of the buffer
    cntr = 0                        ; set the counter to zero

    clock 0                         ; start the millisecond clock

  lpst:
    num2str cntr $1
    spos = append$ buf$ $1 spos     ; append the converted number
    spos = append$ buf$ " " spos    ; append a space seperator

    if spos < indc                  ; is spos is below the realloc indicator
    goto nxt
      buf$ = zenlarge$ buf$ blen    ; increase the buffer size
      add indc, blen                ; update the realloc indicator
  nxt:
    add cntr, 1
    if cntr <= 2000
    goto lpst

    buf$ = ztrim$ buf$              ; trim trailing zeros

    clock 1                         ; stop the clock and return duration in #0

    num2str #0 num$                 ; convert it to a string
    shw$ = cat$ num$ " milliseconds"
    msgbox buf$ shw$ MB_OK

    end

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

[attachment deleted by admin]

[NPNW]

Hi Hutch,

Is the zenlarge$ a random choice of function nameing or is it a small peek at your search for the larger picture in Script Engine design?

[hutch--]

 :bg

It had a lot less to do with "zen" than it did with "enlarge" a "z"ero termnated buffer. I originally tried "zrealloc$" but its not a true realloc function, it will only enlarge the buffer size.

[NPNW]

And here I thought you had found some way of combining profound knowledge and understanding into a working piece of software that would elevate MASM into the forfront of programming?  :bg

However, I'll take your explanation at face value.  :(

Question,

When you are allocating the zenlarge. Do you have to worry about room in memory for the buffer?
when you create the program how much space are you leaving available?
What algorithm are you using to ensure that you don't have problems?

[hutch--]

Its actually one of the virtues of using OLE string that you can keep enlarging it by appending to the end of it so rather than use something like Heap or Global alloc, the function appends a zero filled buffer of the size specified to the original data and it is addressed by the variable it is assigned to. There is a ztrim$ function that will size it back down to the end of the data and to deallocate the buffer altogether, you simply assign a null string in the form "" to make it zero length.

[Timbo]

Hutch,

I've just returned from a short vacation (where thankfully I didn't have to jockey a pc), and I've come back to a lovely update to the script engine.  I've also written an alteration for the wordfile for UltraEdit/UEStudio so now I have syntax highlighting for scripts.  I could post it if anyone is interested.

I will be putting some tests together to see how she handles.

Best regards,

Tim

[hutch--]

Tim,

I don't know how many people use UltraEdit but I remember it being a good but large editor. I have put it down for a few days to get it out of my head but something I would like to do is make it more general purpose than it is at the moment. I have hit the target application with it being a text production engine and it appears to do this well so far and the API code seems to be working OK within its limitations but I wonder what else will be useful as runtime functions.

I did the directory functions so it could be used to do some of the simple install type operations something like a batch file but using the "run" synchronous function but I would like to hear if anyone has any suggestions for extra runtime capacity within the limitations of a line by line script processing engine.

[Timbo]

Hutch,

Am I correct in thinking that fseek only accepts immediates for parameter 2?  It would be nice if it accepted variables, or that I knew how to use it correctly in the case that I am incorrect.  See the following script:

Code Select Expand


;filemerge.se

STRING $infile_a
STRING $infile_b
STRING $outfile

INTEGER FileSize1
INTEGER FileSize2
INTEGER hFile1
INTEGER hFile2
INTEGER hFileTarget

lbl_getfile1:
cstr $1 "All Files\0*.*\0\0"
fileopen "Please select input file 1" $1
if$ $0 == ""
goto lbl_err_nofile1

$infile_a = $0

lbl_getfile2:
cstr $1 "All Files\0*.*\0\0"
fileopen "Please select input file 2" $1
if$ $0 == ""
goto lbl_err_nofile2

$infile_b = $0

lbl_gettarget:
gettext "Please enter a target filename" "FileMerge" "Target.merge"
if$ $0 == ""
goto lbl_err_notarget

$outfile = $0

hFile1 = fopen $infile_a            ;\
FileSize1 = fsize hFile1            ; \__Open input file 1, read it, and close it
$1 = fread hFile1 FileSize1         ; /
#1 = fclose hFile1                  ;/

hFileTarget = fcreate $outfile      ;\__Flush file 1 out to the target file
#1 = fprintc hFileTarget $1         ;/

hFile2 = fopen $infile_b            ;\
FileSize2 = fsize hFile2            ; \__Open input file 2, read it, and close it
$2 = fread hFile2 FileSize2         ; /
#1 = fclose hFile2                  ;/

add FileSize1 1                     ;FileSize1 is now the correct offset into
                                    ;the target file to begin writing the 2nd file

#1 = fseek hFileTarget FileSize1 FILE_BEGIN ;\__Move to the correct offset and flush
#1 = fprintc hFileTarget $2                 ;/

#1 = fclose hFileTarget             ;close the output file

msgbox "Done!" "FileMerge" MB_OK
goto lbl_end

;===================ERROR HANDLERS=============================
lbl_err_notarget:
cstr $1 "There was no target filename entered.\0Try again?"
msgbox $1 "FileMerge" MB_YESNO
if #0 == IDYES
goto lbl_gettarget
goto lbl_end

lbl_err_nofile1:
cstr $1 "There was no source file selected.\0Try again?"
msgbox $1 "FileMerge" MB_YESNO
if #0 == IDYES
goto lbl_getfile1
goto lbl_end

lbl_err_nofile2:
cstr $1 "There was no source file selected.\0Try again?"
msgbox $1 "FileMerge" MB_YESNO
if #0 == IDYES
goto lbl_getfile2
;================================================================

lbl_end:
end
The purpose of the script is simply to append File B to File A, resulting in File C.  Anything I might have overlooked to be causing the behavior exhibited by the script?

Regards,

Tim

Edit:  First effort at pasting screwed the script.

[hutch--]

Tim,

I have not digested your file yet but this is the test piece for fseek. It seems to be working OK.

Code Select Expand


; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

    INTEGER hFile

    INTEGER var1
    INTEGER var2
    INTEGER var3

    $2 = "@_@.@_@"

  ; ********************
  ; create the test file
  ; ********************
    hFile = fcreate $2
    #0 = fprint hFile "1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"
    #0 = fclose hFile

  ; *********
  ; reopen it
  ; *********
    #2 = fopen $2

    var1 = 16
    var2 = -16
    var3 = -4

  ; *******************************
  ; test fseek in relation to fread
  ; *******************************
    hFile = fseek #2 var2 FILE_END
    $22 = fread #2 var1
    msgbox $22 "fread Result using FILE_END" MB_OK

    hFile = fseek #2 0 FILE_BEGIN
    $22 = fread #2 var1
    msgbox $22 "fread Result using FILE_BEGIN" MB_OK

    hFile = fseek #2 var3 FILE_CURRENT
    $22 = fread #2 var1
    msgbox $22 "fread Result using FILE_CURRENT" MB_OK

    #0 = fclose #2

  ; ***********************************
  ; direct call API to delete test file
  ; ***********************************
    #5 = dll "kernel32" "DeleteFileA" $2

    end

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««


[zcoder]

Don't take this wrong I am just
wondering what this can be used for?

is it interesting in deed.

Zcoder....

[Timbo]

zcoder,

I have found it to be easier to use than Visual Basic (VBScript is a better comparison perhaps) and more flexible and powerful.  What I am currently thinking of using it for is for a replacement for makefiles.

Hutch,

It would be mighty nice if you provided a facility for filetime comparison within the engine.  (My comment to zcoder reminded me of this part of my "wish list").  I haven't tracked down what is causing my erroneous behavior within my example script, but surely it is my fault.  Thanks for your attention.

Regards,

Tim

[hutch--]

Tim,

I was interested to see what you had in mind for a time comparison function. There are a couple of APIs that should come close like GetFileTime() in conjunction with CompareFileTime() but GetFileTime() dumps its results in a number of FILETIME structures so its not the tidiest way when designing a script function.

I wonder if the output of CompareFileTime() would do the job correctly and the function would need to take the two filenames as arguments and output the -1 0 1 range for evaluation.

[Timbo]

Hutch,

Yes, GetFileTime() and CompareFileTime() are a bit of a clutter to mess with due to the use of the pair of FILETIME structures required but it's basically what you are looking at.  For now I can make due with simulating the FILETIME structures and making the calls directly.

Perhaps something named like "fcomp" that takes the two file names and simply returns the API retval straight back to the script.  New constants would then be in order perhaps?  FILETIME_EQUAL, FILETIME_GREATER, FILETIME_LESS?  This would enhance the legibility of the script.

Best regards,

Tim