-
Notifications
You must be signed in to change notification settings - Fork 0
/
IMPORT_CALLS.TXT
500 lines (397 loc) · 32.5 KB
/
IMPORT_CALLS.TXT
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
https://github.com/lastforkbender/staqtapp
_______________________________________________________________________________________
STAQTAPP V1.2 IMPORT FUNCTIONS USAGE:
UPDATED: MON, SEP2 2024, added registry() features description
*Staqtapp 1.2 is a all-in-one stand alone vfs env-var module. No third-party
libraries are needed to use staqtapp.py module or modules it makes for other
functional return uses, like lambdavar().
----> makevfs(vfsFileName, directoryName, folderName), builds a .sqtpp vfs file
in current ../staqtapp/* directory; @vfsFileName cannot include ':' chars,
tqpt file auto inserted to sub-folder naming of @folderName & is set path.
----> setpath(vfsFileName, directoryName, folderName), sets the working path for
the .sqtpp vfs file @vfsFileName, inline with @directoryName + @folderName
paths given to a env-var stack/tqpt file. This can also be done by opening
the .stg file in the current working module dir .../staqtapp1_2/ where for
a path example: 'vfs-A:dir-A:folder-A:subFolder-A:tqpt-A' can be editted.
A subfolder name required and only dash chars - allowed, not underscores _.
By use of this function is assumed @folderName is same for subfolder name.
(This wouldn't be true for a rev9 built vfs file having many dirs+folders.)
----> addvar(varName, varData), adds variable to path set vfs tqpt file. @varData
must be tagged with '@qp(...):' for staqtapps unique read parsing routines.
Can be as many @qp(...): tags as needed, with commenting in between. Read as
a comma separation for a list return when more than one. This function does
not change variable data, see changevar to edit stacked variable datas. Is
suggested to use lockvar after adding a variable with this function. *****If
storing a lambda function as a env-var runnable, only use one @qp(...): tag
for that lambda function use, including the lambda name & equal sign for the
function. @varName is ignored in this case. You can also skip qp tagging for
this type env-var storing of which gets @q|p tagged anyway. See lambdavar().
Example: @qp(my_lambda = lambda x,y,z,r: (x*z/y)/(r)): *****
----> corevar(mode, varName, booleanList), for storing and reading boolean type list.
If @mode == 1 is write, 2 is returned boolean list or 3 returns the special --
delta RLE encoding that was saved to tqpt stack, a tuple(s) list encoding. (The
parity bit[last index value of stored boolean list] is always flipped on read.)
----> appvar(varNames, varDatas, varLocks), adds env-vars by lists only. All params
must be list type except for @varLocks, which can be None value if not needed.
If the list lengths between @varNames and @varDatas is unbalanced then can add
@qp(null): to the tqpt stack as a value for env-var; and also if no @varLocks
list element found then no lock block is made in the tpqt file for env-var. @
varLocks correct example index ..., 'myvar2:fnc1,fnc2,fnc3', ...] whereof this
type :, format to lock names must be to properly add a lock block for env-var.
When lock block only needs one fnc name or other name, no comma use is needed.
If you do not need a value or lock block for a env-var added, simply None as
that pair [element] bypasses any checking needed, otherwise can be error prone.
(Recognition of lambda function strings is not done with appvar, only addvar.)
----> listvars(), returns stack list names of current env-vars in tqpt vfs source.
----> joinvars(newVarName, varNames), as a list of str names @varNames, this will
join together those env-var datas at the qp(...): taggings merged into one
new env-var @newVarName. Precaution assumed, if does not find a valid name
listed in tqpt env-var source then does not add to joining. If @newVarName is
a stalked env-var then will merge all spawned vars from a stalkvar use. (No
spawned vars are removed from svvs listing or the tqpt vars stack.) No join
for any env-var data having chars ☆ in it, will raise exception that it is a
smv-tree type error that cannot be merged with other env-vars. This is power-
ful feature in connect of stalkvar function env-var spawned data use, of which
is possible to do multiple layered recursion from just a singular event loop.
However in some adv cases, would need the raw @qp(...): tagging to manipulate
ast converted smv-tree dict type for this mathematically, via some other dict
type conversions or abstract reductions of paired branching, see loadvar_stx.
----> changevar(varName, newVarData), change @varName env-var data to @newVarData
if @newVarData has proper @qp(...): data tag(s) found. To change the names
of env-vars in a vfs tqpt source, see renamevar. Duplicates only allowed for
the stalkvar() feature. *This function should be used with lockvar & keyvar.
If the @varName is a stalked env-var, the original stalked and not the other
incremented spawned vars from it, then this function will check if any of --
the incremented spawned var data matches the @newVarData string. If it does
then any spawned vars matching @newVarData are removed; and any spawned vars
left are renamed of a new incremented naming, re-named to a new number order.
This changes no env-var data. Becomes a find and remove operation allowing a
programmer more advanced control over stalkvar spawned env-vars, in a larger
scope use of stalkvar env-var spawnings in the tqpt source. If any spawned
env-var is removed from tqpt and svvs sub file listings, is also removed @ a
lockvar tpqt listing if found. Will not do any of this if the stalked var is
read as having only one spawned env-var. Raises a non-allowed svvs exception.
If this function switches to this type find & del, returns named list of the
spawned env-var(s) it deleted or else returns None.
----> addtree_stx(treeName, initialTreePathList), adds a initial dict type tree
structure to vfs tqpt stacks for deep spahk-mv type tree edits. @initial-
TreePathList is simply a list elements of strings or int values. Chars not
allowed @initialTreePathList string element(s) are \n,':{} and ☆ The ---
other functions that edit this type, all stalkvar() type similiar actions.
----> addbranch_stx(treeName, branchId, newBranchId, newBranchValue), Adds, shifts,
replaces, or spawns merged branch for a mv-tree. Behavior of mv-tree branch
edits are in exotic relation to stalkvar. The examples below show this. The
first dict key cannot be changed, will raise exception. Is 'a' in examples:
Example A:
smvt-state {'a':{'b':{'c':'vl1','d':'vl2'}, 'e':'vl3'}}
.addbranch_stx('smvt_tree_a', 'c', 2035, None)
results ---> {'a':{'b':{'c':{'2035':'knt'}, 'd':'vl2'}, 'e':'vl3'}}
'vl1' now a nested branch, not a separate value
Example B:
smvt-state {'a':{'b':{'c':'vl1'},'e':'vl3'}}
.addbranch_stx('smvt_tree_b', 'b', 2056, None)
results ---> {'a':{'b':{'2056':'knt'},'b_2056':{'c':'vl1'},'e':'vl3'}}
'b' hoplinked to branch&value, however not full link replace parse
@'b_2056', feature serves as replace options and other features
Example C:
smvt-state {'a':{'b':{'c'},'e':'vl3'}}
.addbranch_stx('smvt_tree_c', 'c', 2032, 2051)
results ---> {'a':{'b':{'2032':'2051'},'e':'vl3'}}
'c' replaced by {'2032':'2051'} branch
----> getbranch_stx(isAlf, treeName, branchId), returns a found branch value or
None. @branchId can be either int or str for param usage. @isAlf is for a
return list of all original branch key(s) + value(s) to an @brnchId merge.
The return list format as ['br_br:br:bv',...], whereof first after :orig:
Avoid using alf as much as possible on large mv-trees. If use, @branchId=
None. A tip to this type dict tree type: Record env-var any adds done last
to a branch, that can be then known replaced or merged with other branch.
The staqtapp mv-tree type can be difficult to use at first, however opens
a whole other world for *indirect & *adapt recursion unions with stalkvar.
----> lockvar(varName, fncName), adds a function name or else associated to a var-
Name in a tpqt type file. This can then be used with keyvar to gate what is
allowed to edit the env-var. There no real security/math to it like the Koch
version Staqtapp, however is very useful in preventing any env-vars mishaps.
@fncName can be either a string; or, list parameter of string names properly.
To delete vfs entries from a lockvar use, see lockdel to do that effectively.
----> locklist(varName), returns listed fnc/etc. names for a lockvar tpqt vfs entry.
----> keyvar(varName, fncName), returns True if @fncNm is allowed to edit @varNm,
is a listed key to @varNm. Other very useful conditions of this include ---
@fncNm being a env-var name of a spawned var set, from use of the stalkvar
function, with multi-processing. Unlike Staqtapp Koch version has no vfs --
tpqt directory restriction features via a directory split route linkers. The
listed keys to the @varName are a clear text read in view of .sqtpp vfs file.
Attempting to encrypt vfs file yourself, with standard encrypt libraries will
not only prove poor performance but will also be insecure in the near future.
(That includes Kyber lattice encrypt that can be cracked by parentheses char
chewing attacks using a dual side channel repeater from a mere single phone.)
----> revar(isNewSetVfsPath, newVfsFileName, newVfsDirName, newVfsFldrName),
replicates a new .sqtpp vfs file in the .../staqtapp/ folder, having only the
env-var(s) from the current set vfs file that are linked to a tpqt lockvar
entry. @isNewSetVfsPath as True will reset current set vfs file path to the
now new vfs file and it's tqpt path. (If this function is called and the ----
current set vfs file has no tpqt lockvar entries found a exception is raised.)
**This function is used for advanced rev9 staqtapp features in building custom
env-var library modules from within a staqtapp1.2 vfs thru self-replications.
Can respawn any missing stalkvar() env-vars to a new self-made svvs sub file.
The svvs file from the current set vfs file is lost on the new transfer.**
----> lambdavar(lambdaName, inputVars), this function is an original of Staqtapp1.2.
See addvar() for storing a lambda in tqpt stack first. Of the instruction sets
connected to lambdavar(): Makes sqtpp1_2_LMB.py module, converts @lambdaName
function in tqpt stack to a parameterless lambda; params made to slots attrs @
sqtpp1_2_LMB.py. Once the parameterless lambda is there is then directly ran if
called again, no param/body conversions or edit of the module. With @inputVars
as str element list only. Example: ['x=4','y=2,3,4'] If is use of commas then
is converted to a list when the slots attrs are set before run of slots lambda.
If string elements after the = are all numbers is converted to int, both for a
list value(s) or single value. The created module in the working current dir of
staqtapp.py, with a import math declaring in the module. Because this function
leads to all lambda parameters added to the slots attrs, keeping the parameter
names generic to a lambda when use of addvar() bypasses edits & slots length.
----> lambdalist(isComplete), returns stored lambda data from a vfs tqpt stack. If is
@isComplete=True then returns a list of the full lambda functions. Other option
as @isComplete=False returns a special formatted string of the lambda functions
name(s) and param(s) so is much easier to work alongside a lambdavar() call -->
Example: '@.:my_lambda1,i=,p=,l=,@.:my_lambda2,x=,n=' whereof separated ",@.:"
----> removevar(varName), removes env-var from tqpt stack and any tpqt lockvar block.
Will not delete a stalked env-var or a dark env-var, raises a exception that
the @varNm parameter choice is connected to a vfs dependency function only.
This is a dangerous function; well not as dangerous as us, to rely on for env
var use. It is much better to just rename a env-var and go from there, when
then use of changevar function. Keeps your env-var stack smaller and more
easily controlled instead of wild adding until you don't know what to remove.
Which could then result in bad collisions of a spawned or dark env-var group
if using those to protect a hidden database of passwords or drone config file.
----> darkvar(), mirrors any removal of a stalked env-var, placing the then removed
spawned vars datas to a assigned address, that is all the incremented numbers
of the spawned var namings to be removed. After this assigns a pointer to the
address by dash, example 56791218-3095903, a random 7-digit palindrome number
that will then be of a vssv sub-file content. A darkvar, or dark env-var does
not repeat any char when saving the data of the removed vars to a @qp(...):
tagging. It only interacts with other env-vars by any palindrome sequences of
those chars, if is visible/matching @ the new address to env-var(s) data. This
type env-var uses menorah base numbering, non-znero by shifting the pointer to
a most probable next match in chars of a recent env-var data viewed. The slots
attributes specific to this env-var are _sf_sLstX, _sf_sStrX and _sf_sIntX. To
call on this non-parameter method it will react either two ways: One, _sf_sLstX
is of a visible relevant list of env-var(s) in the tqpt source and is spawned
set of env-var(s) with at least one tpqt lock block visible. This will cause a
assignment probable str to @_sf_sStrX and a new palindrome pointer @_sf_sIntX.
Or two, then uses what is done by the first to build a new env-var having ---
data of a probable set of decisions chars relevant to a new spawned var added.
The rev9 features of this library to be added later, uses this to vastly alter
any module building it does from another, by decisions in conditionals choice;
by lengthing a klf id depend string or splicing it to lesser address probables.
(The Staqtapp-Koch does this similar type env-var actions by numerous modules
classed Seten modules, yet for random length key padding in vfs-dir routing.)
The type mathematical looping of this function with palindrome address shifts
is tri-half looping, just as seen on the Menorah. Where a pairing loop is not
matched to a static center necessary pairing(Base10), however of LR.R or RL.L
rotation, of which either larger loop with middle exact to 1 | smaller " to 1.
(UNDER CONSTRUCTION)
----> renamevar_stx(varName newVarName), this function a important one to the data
structure of this new staqtapp one version. It actions a normal renaming of a
env-var if does not conflict with other namings and can also change the ----
spawned var(s) naming(s) from a stalkvar() use just as staqtapp koch version.
To do this there must be more than one spawned env-var from a stalked var. By
param @newVarName being a int and @varName being the stalked var, the renames
of the spawned vars take order increasing from the int value; but if negative
number or zero for @newVarName then will remove the spawned var(s) until reach
of int one or is only one spawned var left..if negative int, replaced positive.
That explained, removes spawned vars by nearest increment of the spawned names.
With negative param does not rename any individual spawned of env-var namings,
the renaming is central of svvs list, shifted left after any number of removes.
This is tricky at first to use with negative del order, however a very powerful
useable when matching spawned env-vars to a replaced branching of smv-tree use.
(The Staqtapp Koch version does this in between multi-layered encryption key --
padding, while encrypt of vdf path directories as most secure env-var vfs ever.)
Returns 1 if renamed env-var, 2 if renamed spawned var(s) and there is only --
one left spawned var of the stalked var and 3 if renamed spawned env-var(s).
----> findvar(varName), returns True if variable present to set vfs tqpt file.
----> findvar_stx(varNameList, stalkVarName), findvar function for multiple found
result list return. If @stalkVarName not None then returns the list of the
spawned incremented var names, with each element s-var name of a additional
equal detail = <if @varNameList[ ]'s data ?= @incremented_var's data> which
will be either =1 or =-1. List length @varNameList determines return length
for both search options. This new feature is used for recursive analysis or
chained events hidden from a pivot conclusion or escape type params forming.
[If stalked var will have thousands of spawned naming see modvar for lambda
spawned res-type slots attribute class caching before calling this method.]
----> vardata_stx(isRegex, varNameList, search), returns list type from search on
the @varNameList if @search terms found in a env-var data; returns names of
env-var(s) from @varNameList, not the env-var data. @isRegEx instructs the
@search is a regex type pattern search. Can search mv-tree stx var types of
their keys & values for a listed name return also if @search pattern found.
Either way, regular find or regex of no found results returns a empty list.
----> loadvar(isAllNumbers, varName, mode), returns a env-var data from @varName.
@mode either 'd' for deque type return or 's' for a string type return. All
tqpt env-var data parsing is smart on if is a list return, has numbers with
decimals for decimal type returns and etc. via @qp(...): env-var data tags.
Be aware if @isAllNumbers set to True then will return list within list if
reads multiple qp tags having commas. This will also convert to decimal if
tqpt_spdr() finds use of '.' with numbers for a deque type returns. (By use
of char * only @varName, load most recent added spawned var from stalkvar()
function use. This spawned var tracking found in the tpqt lockvar stacks --
with the special header naming as '___SQTPP___MRSV___' and can be editted.)
----> stalkvar(varName, varData), keeps the original env-var as a static read only
var and makes a new but same @varName, with extension '_ ' as a numbered
increment _1~ . If the @varData matches the original, is no longer a stalked
env-var and all the incremented spawns are removed from both the tqpt & svvs
set vfs path files contents. This feature is used for recursive analysis or
chained events hidden from a pivot conclusion or escape type params forming.
----> lockdel(isRemoveAll, varName, fncName), removes lockvar entries from a tpqt
block of names that are associated to a env-var name. The @fncName parameter
can be str or a list for the entries to remove. The previous Staqtapp 1 ver.
had a log function name when a keyvar is called option. That is no longer in
use. If @isRemoveAll then the entire tpqt block is removed for @varName. If
you need a list return of what @fncName exist of a tpqt block, see getlocks.
Once again, there is no security measures added of this function. To have
full password & tor like vfs dir encryption security for this, you must have
the Staqtapp-Koch version. The full ver is not open freeware and is the most
secure env-var library on earth, that does not use any online third party to
to store any env-var data or passwords.
----> registry(isRead, keyName, keyData, harpSchemaPath), stores registry keys in the
auto-generated slots performance module sqtpp1_2_REG.py for integrated lambda
function use for registry value(s) normalizations. It does this by a schema of
custom coding, that has a nested validator for lambda returns in connect of --
types, items, inherits and any kept order of the main category types assigned.
The more advanced pojishon optionals use this type lambda-registry extensive.
(NOT YET IMPLEMENTED)
----> pojishon(mode, varData, varName, dirList), gives access to Staqtapp's vfs dir/
embedded file system located at the top directory of a sqtpp file. Includes --
28 functional calls in 6 categories: next, jump, tqpt, tpqt, watch and record.
Below are the functional aspects of these categories and optional parameters.
Argument *mode* is a str that includes the dot refrences and any optionals. Of
@varData and @varName can be either str or list type; @dirList the folder tree
path to file(s). Env-vars are as files whereof @dirList = list = [mount, dir]
and @varName the filename as a positional read/write file in vfs mount/dir seq.
*In a single mount only can a env-var/file be moved, edited, copied or removed.
These positional file features allow vast options with env-vars within the vfs
use across many vfs directories & files for any circumstances needed, making -
Staqtapp 1.2 the most versatile env-vars py module publicly available. Some of
these dot functional modes include integration with normal sqtpp env-var uses.
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|||||||| NEXT |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(1) ("next", required, required, required), makes new mount, new directory
and a new file. *Of no dot refrence instructions and has no optionals.
(2) ("next.cast.*", non-required, non-required, required), copies last env-
var(s) file added to a new directory. *dirList[0] argument string must
match the last mount name used or throws a mount placement exception;
and argument dirList[1] does not match last directory used. If new dir
@dirList[1] is not currently a dir in mnt then will add the new dir.
(3) ("next.ghost.*", non-required, non-required, required), from last file
added compares it's data to any file @dirList path. If a entire line in
the most recent added file matches a entire line in @dirList file, then
an add all matching lines to a new file in same directory of @dirList[1]
whereof index[0] is mount; index[1] is directory. The @varName parameter
is ignored and the new file's name is of a number of lines #. Is a 1rst
match basis on any file then scans the same file for more line matches.
EXAMPLE: lastfileaddedname_#numberoflines
As example above takes on last added file name and number of lines that
will be a number, not #numberoflines. If at any time this action repeat
and the naming above matches for a new file to added in same directory,
the file is replaced. Has to complete match. Will not overwrite a file
having a different number of lines. In other words the original *host*
file of this add file feature is a unknown in Staqtapp's procedures --
when next.refill or next.remove is used on that same mount/directory.
(The setting for the last file added in vfs settings is not updated to
the mnt/dir/file of the new match lines file just added, is ghost file)
One to be careful with. If the @dirLst is pointing to directory where
there is a file of a same naming, however not a lines match file then
gets over written just a same anyway. Also to remember the last added
file in the vfs settings is not there for this type file added. Any
optionals used after this command sees same unchanged m/d/f setting.
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|||||||| OPTIONALS |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
***using a optional will be the final return, either True or False applied;
or for the quantumf optional, a discrete math based lambda function str
***arguments separator must be ";" not "," or will result in exceptions
and any use of ; in a 'string' also results in exceptions, see below
***optional's params all string and requiring normal type declarations,
if list required param then list=[..., ...] with the brackets and
all else also string for #, str or #[index] a number list needed;
if is a string or string list then use of ' is needed between "
meaning cannot use ; or ' in a 'str', is formed by ast literals
EXAMPLE:
("next.cast.open(['@qp(data1,1X):', '@qp(data2,2X):']; [3,4,5,6])", ...
***if a raised exception happens with parsing or instructions from an
optional, the dot commands before it already done and saved to the
.sqtpp vfs file
(1) .open(varDt=list; occurence=#[index]) | .open(varNm=list; occurence=#[index])
If @varDt then requires @qp(...): normal staqtapp env-var data tagging. This
will cause staqtapp to search for qp tagged env-var data from @varDt and then
compare it to the env-var data being set in a directory. If there is a match
in data sequence, anywhere of the new set dir/file data compared against the
@varDt found in stored qp tagged env-var(s), then those qp tagged env-var(s)
take on any further compared/found data of a same. Will add to the qp tagged
env-var(s), from the file, starting at the end index of find up to a newline
encountered or the char scanning method finds a char set of ":|:". If there
is commas found from the scanning then is separated into @qp(...): taggings.
Char sequence ":|:" marks the end of a file and if no newline encountered is
an add all data until end of file. See third paragraph for occurence detail.
The same for @varNm choice env-var search, however the search & find method is
based upon matching a naming category: Is first a find env-var name match from
@varNm element, then on a first match of a data sequence comparing that is of
a length matching @occurence element, of comparison between the newly added
file data and the tqpt env-var data then/when the new data from file's data is
added to the env-var; @occurence parmeter is of a same for @varNm param choice
though doubles as a scan find & scan cut. If lack of a pairing occurence index
value for matching, a raised exception. With @varDt use, a single element str
of "*" for that list ignores @occurence length cut-offs. Works a same for this
param choice yet a add all data only from newly added file; if scans data with
newlines or commas, splits the data into separate added qp(...): taggings. The
param choice @varNm tricky since @occurence elements are both length scan for
a match and the length cut-offs after match. You'll need to balance your file
type data being added before this open optional request, specific of where the
newlines arrange the data or adv char sequence ":|:" cuts from an counts list.
This option instructed from a pojishon next command and is an omega pojishon
next dot command involved then occurence is ignored. Occurence argument tells
staqtapp of a specific super length order and must be present, as a list. The
index value(s) as int, whereof any search & found happens then index value is
max length the new data will be added to the qp tagged env-var(s). If you are
to bypass this argument then occurence=['*'] will do so but not the same as a
omega pojishon next command that auto involves certain locking properties for
stored qp tagged env-vars, outside the embedded mount/directory/files edits.
*This option will bypass scanning qp tagged data on a globe var, KLF__DSG var,
smv tree var, darkvar, st1_atlaspice var(runnable lambda str) and any corevar.
All six are special env-vars of Staqtapp1.2's parsing methods and are skipped.
(2) .closed(varNm=str; start=#; end=#) | .closed(varNm=list; start=#; end=#)
With param @varNm can be either a closed phase string or single env-var nm
if param is a string. If a phase string then char '=' must be present and
char sequence '::' for separation of each closed phase. A phase string use
is same as @varNm being a list of env-var names but not a single s & e for
all var names. This allows closed-off data from a file in multiple phases
if a match is found from the env-var's data.
EXAMPLE:
("next.cast.closed('varNmA=64:133::varNmB=85:456'; None; None)", ...
This optional quantum like between the file being compared with the env-var.
If any match found between the s & e indices in the file, the observation is
removed from the file and is now of the env-var's data. The env-var's values
or qp(...): tagged data, individual is the comparison check of the s & e str.
If is a dual observation match, meaning the entire length of the qp tagged
data matches the entire length in chars of s & e from the file, both will be
removed.
The match is removed either way; not entire s & e--->unless is a full length
environment match both ways met, a completed dual identical length matching.
The closed optional works with optionals cache, seal, setfreq and removefreq
of a similiar instructions bounded to env-vars' names and env-vars' datas in
a dynamic observe, pass, collect, merge or remove context search further.
(3) .cache(varNm=str; occurence=#) | .cache(varNm=list; occurence=#[index])
(NOT YET IMPLEMENTED)
(4) .seal(dirLst=list; match=str; freq=str; type=unlocked=0|locked=1)
(NOT YET IMPLEMENTED)
.setfreq(varNm=str; dirLst=list; occurence=#) | .setfreq(varNm=list; dirLst=list; occurence=#[index]) --> (NOT YET IMPLEMENTED)
.removefreq(varNm=str; dirLst=list; freq=str) | .removefreq(varNm=list; dirLst=list; freq=str) --> (NOT YET IMPLEMENTED)
.retag(varDt=str; freq=str; span=#; removeat=#) | .retag(varDt=list; freq=str; span=#[index]; removeat=#[index]) --> (NOT YET IMPLEMENTED)
.quantumf(varNm=str; dirLst=list; span=#) | .quantumf(varNm=list; dirLst=list; span=#[index]) --> (NOT YET IMPLEMENTED)
----> modrev9(prmsLst), builds a complete custom env-var module. @prmsLst elements
for this staqtapp feature is 34 arguments. The type modules generated can be
very difficult to understand, with obfuscation turned on or not. Some of the
arguments need the DUN3.py random lambda generator module present. (The DUN3
random lambda generator is still being tested and refined.) This feature is
central to staqtapp. Enables bluetooth communication with any other builds &
can respawn itself, changed to meet any new bluetooth communication commands.
And being it would need an clean and semi-abstract vfs file system for that.
(UNDER CONSTRUCTION)
_______________________________________________________________________________________