Wondrous stories about arrays in TCC

I've been working with arrays lately to read lists from a file. Now I noticed that once an array has
been filled, it can no longer be deleted or read in again. That means, the commands
UNSETARRAY arFilesList or SETARRAY /F /R filename arFilesList are completely ineffective.
I wrote a little "Test_Array.BTM" to check it out:

Code:
Setlocal
  SetArray garJobList[99]
    Echo %@EXEC[Set garJobList[0]=Hello everybody, it is %_date at %_time]
    Echo ArrayTest 0:[Size:%@ARRAYINFO[garJobList,1]]:"%garJobList[0]"
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
  Set ListFile=%1
IFF NOT DEFINED ListFile THEN
rem  Set ListFile=D:\JPSoft\_SyncListen\NetSyncListe.Txt
rem 
Set ListFile=d:\JPSoft\_SyncListen\EvalAttribs_Liste.TXT
rem  Set ListFile=d:\JPSoft\_SyncListen\CopyListe.2_Daten
ENDIFF
  Echo Listfile=%listfile, with %@INC[%@LINES[%listfile]] lines.
  Echo %@LinieMit[*]
:
Pause Show Listfile
Echo.
    Do Zeile In @%listfile
      Echo `Do`:"%zeile"
    EndDo
  Echo %@LinieMit[:]

Pause Array actions
  Echo Zeile:[%Zeile], z:[%z]
    Echo ArrayTest 1:[Size:%@ARRAYINFO[garJobList,1]]:"%garJobList[0]"
rem
  If %_bdebugger EQ 1 Echo IDE - Here I am :-)
::
  If %@ARRAYINFO[garJobList,0] NE -1 Unset /Q garJobList
:: This means, that the command is completely inoperative !
rem   %@If[%_bdebugger EQ 1,Unset /Q garJobList,Echo Nothing ToDo :-)]
  SetArray /R %listfile% garJobList
    Echo ArrayTest 2:[Size:%@ARRAYINFO[garJobList,1]]:"%garJobList[0]"
::
  Do z=0 To %@DEC[%@ARRAYINFO[garJobList,1]]
    Set Zeile=%garjoblist[%z]
        Echo  Array-Z:%z:"%zeile%"
  EndDo

Echo.
Echo The Array is not changeable !
    Echo ArrayTest 3:[Size:%@ARRAYINFO[garJobList,1]]:"%garJobList[0]"
        Echo %@EXEC[Set garJobList[0]="Hello everybody, here is TCC-Batchdebugger"]
    Echo ArrayTest 4:[Size:%@ARRAYINFO[garJobList,1]]:"%garJobList[0]"

EndLocal
If I start the debugger again after the first run, e.g. with another file to read in, the array is still
present and still filled and will not be changed ! When I exit the debugger session, the array is still
present in the TCC session and cannot be used again for SETARRAY /R !
In TCC 18 this still worked ...

And it goes even further : If I open a new shell with F7 (not mentioned in the manual) from the debugger
while the program is running, then all environment variables currently in use with the current states are
present there, but not arrays ! This has probably always been the case from beginnig of using arrays, but
nobody noticed it yet :-)
And - Arrays are not inherited or shared like the Environment, ALiases, Functions to other opened TCC-Sessions.
 
Why are you using UNSET instead of UNSETARRAY?
Arrgh - because I am ... getting old, I think :banghead:
Sorry this was My mistake. Of cause, with UNSETARRAY it's working well
as expected (in the TCC18 script I've use it so :rolleyes:)
But the other points mentioned are still in place. :smile:
 

rconn

Administrator
Staff member
May 14, 2008
11,013
98
I'm not sure I understand exactly what your other issues are (when using UNSETARRAY). I can't run your batch file because I don't have the file(s) you're loading, or the user-defined functions you're using.

Arrays are not supposed to be inherited like the environment or shared like aliases & functions (only if you're using global aliases or functions). There are some architectural reasons for this, and nobody has ever requested it.

Arrays (like environment variables, aliases, and functions) are not destroyed when you restart the debugger. If you want to read a file into an array and that array has already been defined, you need to combine the /F and /R options in SETARRAY. (Or put in an UNSETARRAY before the SETARRAY.)
 
I'm not sure I understand exactly what your other issues are (when using UNSETARRAY). I can't run your batch file because I don't have the file(s) you're loading, or the user-defined functions you're using.
The files are simple Textfiles, in this script only used for testing the handling, so You could use whatever You like, if You like. :smile:
I like to use the arrays to read temporarily created text files and then "throw them away".
The User-Defined-Function is only a little helper:
Code:
    FUNCTION LineWith=%@REPEAT[%1,%@DEC[%_COLUMNS]]
It's more "cosmetics" to clearly separate outputs.

Arrays are not supposed to be inherited like the environment or shared like aliases & functions (only if you're using global aliases or functions). There are some architectural reasons for this, and nobody has ever requested it.
Ok, thank You for clarifcation, I'd already supposed that (and I will also not request it :cool:).
Anyway, I think, it should mentioned it in the Manual, under "Array Variables" or so, because
it has surprised me, that I could not handle it as a normal environment variable.

Arrays (like environment variables, aliases, and functions) are not destroyed when you restart the debugger. If you want to read a file into an array and that array has already been defined, you need to combine the /F and /R options in SETARRAY. (Or put in an UNSETARRAY before the SETARRAY.)
Ok, that's clear so far.
But they will also not "destroyed" (what a martial phrasing :smile: ) if I using an array between SETLOCAL / ENDLOCAL and finish a script without UNSETARRAY theArray - the array is still present during the TCC-Session.
Is that the intention ?
 

rconn

Administrator
Staff member
May 14, 2008
11,013
98
Ok, that's clear so far.
But they will also not "destroyed" (what a martial phrasing :smile: ) if I using an array between SETLOCAL / ENDLOCAL and finish a script without UNSETARRAY theArray - the array is still present during the TCC-Session.
Is that the intention ?
Yes - the documentation for SETLOCAL says "SETLOCAL does not save the command history or array variables".