You would need to store the contents of (atoms-family) on drawing startup and then have your variable saving program compare the current content of (atoms-family) with the stored data, removing symbols present in the stored data in order to leave only global variables and variables defined within the scope of the program itself.
How difficult would it be if I wanted to save all variables (atoms) with (type) 'SYM, 'INT, 'LIST, 'REAL, 'STR? Would it take to much memory - I suppose I don't have to compare (atoms-family) at start of session with finish session when all needed variables are stored in memory - or I am wrong?
You are essentially describing the Express Tools 'LSP' command (lspdata.lsp).
You have two options:
1. Store the content of (atoms-family) at the start of the session (i.e. before any additional symbols are defined) and subsequently compare this with the list returned by (atoms-family).
2. Hard-code the known content of (atoms-family) and then compare the current list with this hard coded data - this is how lspdata.lsp operates
Some issues that are worth considering:
1.
Accuracy of stored reals.
2.
A list may need to be analysed before being stored. Example: storing a list of enames is not useful.
3.
The 'load' function will overwrite existing values. This may not always be wise.
4.
Why not use a single file to store both the names and the values of the variables?
as far as I know there is no possibility to force *CAD to display long real values stored into 'REAL or 'LIST atoms... I don't know where to look to make (force) *CAD operates this way... So for ex. PI variable is actually truncated and when typed !PI in command prompt only 5 decimal digits are displayed - that's how much (read somenumberstring) can actually display even if (setq somenumberstring "99.9999999999999999999999999")
as far as I know there is no possibility to force *CAD to display long real values stored into 'REAL or 'LIST atoms... I don't know where to look to make (force) *CAD operates this way... So for ex. PI variable is actually truncated and when typed !PI in command prompt only 5 decimal digits are displayed - that's how much (read somenumberstring) can actually display even if (setq somenumberstring "99.9999999999999999999999999")
Use rtos in place of vl-prin1-to-string, e.g.:Code - Auto/Visual Lisp: [Select]
"3.14159" "3.141592653589793"
o.0 ... I think you should look at the method I used in storing and retrieving variables.as far as I know there is no possibility to force *CAD to display long real values stored into 'REAL or 'LIST atoms... I don't know where to look to make (force) *CAD operates this way... So for ex. PI variable is actually truncated and when typed !PI in command prompt only 5 decimal digits are displayed - that's how much (read somenumberstring) can actually display even if (setq somenumberstring "99.9999999999999999999999999")
Use rtos in place of vl-prin1-to-string, e.g.:Code - Auto/Visual Lisp: [Select]
"3.14159" "3.141592653589793"
Yes it's true, but actually it's not that simple: what shell we do with point lists?... Shouldn't (vl-prin1-to-string) be just enough good to do this task as built-in?... If not revision of this function then I suppose implementing new sysvar for more adequate representation of 'REAL numbers is necessity... Otherwise loosing data is unavoidable outcome...
as far as I know there is no possibility to force *CAD to display long real values stored into 'REAL or 'LIST atoms... I don't know where to look to make (force) *CAD operates this way... So for ex. PI variable is actually truncated and when typed !PI in command prompt only 5 decimal digits are displayed - that's how much (read somenumberstring) can actually display even if (setq somenumberstring "99.9999999999999999999999999")
Use rtos in place of vl-prin1-to-string, e.g.:Code - Auto/Visual Lisp: [Select]
"3.14159" "3.141592653589793"
Yes it's true, but actually it's not that simple: what shell we do with point lists?...
o.0... I don't see the method in above posted examples (link or similar), but beside this if 'LIST is entity DXF data, if I may also say (read) function returns error : extra cdr in dotted pair list... And for me this is odd too... So IMHO I think that at least 2 functions should be revised - or added : something similar to (vl-prin1-to-string) and something similar to (read)... So there it is - if someone wants to tackle it, it would be nice to see result of this challenge...
I wrote something like this as Lee's suggested as an inspiration, and it's not working... :(Code - Auto/Visual Lisp: [Select]
;;; ;;; put this lisp at line before last in acaddoc.lsp : (if (findfile "variables.lsp") (load "variables.lsp") (load (getfiled "Select variables.lsp file" "\\" "lsp" 16))) ;;; ;;; put this line as last one in acaddoc.lsp : (setq *atoms* (atoms-family 1)) ;;; (cond ) ) ) nil ) (cond ) ) ) nil ) (processlist x) ) ) ) ) ) nil ) ) nil ) ) ) ) ( t nil ) ) ) ) ) ) ) nil ) ) nil ) ) ) ) ( t nil ) ) l ) (foreach var varlst ) ) (foreach var varlst ) (foreach var varlst (cond ) ) ( t ) ) ) ) ) ) ) ) )
As I said I don't mind if it creates 2 txt files as long as it works correctly, but as you can see there is a problem with processing lists... I think (c:var-load) is fine as long as saved txt files are correct... (read) function should correctly perform reading long reals as strings like Lee thought, but how to read long point lists with reals as strings or entity lists that are unchanged when my recursive (processlist) function isn't working like I thought it should...
Of all the absurd posts I've ever read that was the most recent.
And just one more thing to add :
"It is NOT absurd..."
What inspiration did Lee suggest (aside from the rtos suggestion)? I didn't see any inspiration .. bla bla bla ...
1. Me trying to state that I don't think Lee would have inspired/suggested that you do it that way.
1. Me trying to state that I don't think Lee would have inspired/suggested that you do it that way.
The arrogance that gives you the illusion you have the authority to determine what inspires others is petty and immature. I'm embarrassed for you.