Author Topic: LISP PACKAGER  (Read 6708 times)

0 Members and 1 Guest are viewing this topic.

domenicomaria

  • Swamp Rat
  • Posts: 725
LISP PACKAGER
« on: December 26, 2020, 06:10:55 AM »
I have all my lisp files, in the same folder.
Some of these files contain only sub-routines.
When I write a routine, it uses some of these sub-routines.
And sub-routines uses other sub-routines and so on.
So there is a TREE of the sub-routines.

In the past I wrote a LISP PACKAGER
that read all the lisp files contained in a folder

Checks the ATOMS-FAMILY for all sub-routines.

And finds all the DEFUNS and their related codes.

When I give it the name of the main routine,
it finds all the related defuns
and create a single lisp file
that contains the main routine and all the related sub-routines
. . .
it contains only what is necessary
. . .
But I wrote this PACKAGER a lot of years ago.
It is a not professional code.

I am wondering if there is already a software that makes the same thing.

And if not,
I want ask you if someone is interested
to write togheter
something that is useful for every one.


domenicomaria

  • Swamp Rat
  • Posts: 725
Re: LISP PACKAGER
« Reply #1 on: December 26, 2020, 07:01:56 AM »
the LISP EDITOR
does the same thing.

It needs to know the TREE of ALL USED SUB-ROUTINES
and find and uses the code defined in every SUB-ROUTINES

So it is sure, that it already exists
an internal function the solve this issue.

The problem is that it is an INTERNAL function !

... or NOT ?

maybe is it accessible ?

JohnK

  • Administrator
  • Seagull
  • Posts: 10646
Re: LISP PACKAGER
« Reply #2 on: December 26, 2020, 10:33:35 AM »
Years ago I wrote a preprocessor called LiFP that will do what you ask but it was intended to keep you organized during the writing process (not after). -i.e. You should have an organized folder for "libarary routines" and not several copies of them amongst many files. If you read the tutorial and/or the initial post you will see what I mean.

https://www.theswamp.org/index.php?topic=37700.0
TheSwamp.org (serving the CAD community since 2003)
Member location map - Add yourself

Donate to TheSwamp.org

domenicomaria

  • Swamp Rat
  • Posts: 725
Re: LISP PACKAGER
« Reply #3 on: December 26, 2020, 12:21:23 PM »
I have seen your software.
It seems to be interesting and well done.
But it is not what I need.
. . .
I have TWO KIND of files :
- ONE lisp file that contains a ROUTINE that DOES something
and uses external SUB-ROUTINES

- SOME lisp files that contain ONLY SUB-ROUTINES

The "PACKAGER"
has to pack up the lisp file that contains the MAIN ROUTINE
and to search, the DEFUNs and their related codes,
in the lisp files that contain only SUB-ROUTINES ...


What I want acheive is
ONE LISP FILE that contains
everything it needs to work and only this

This because,
if I want create a VLX,
I don't want put everything in the "compiler".
 . . .



« Last Edit: December 26, 2020, 12:36:02 PM by domenicomaria »

domenicomaria

  • Swamp Rat
  • Posts: 725
Re: LISP PACKAGER
« Reply #4 on: December 26, 2020, 12:30:10 PM »
However it is possible to create this software
. . .
I wrote it
only for internal use (where I was working)
and it was working well
. . .
Maybe I have to re-write it
in a better and more elegant way
. . .
For istance . . .

what is the best way to extract
all the DEFUNs, (the name and the related code)
from a LISP file ?
. . .
what is the best way to find
the TREE of all used SUBROUTINES ?
. . .

is there somebody that can give some suggestions ?



domenicomaria

  • Swamp Rat
  • Posts: 725
Re: LISP PACKAGER
« Reply #5 on: December 26, 2020, 12:38:25 PM »
however . . .
again :

it is sure,
that an internal function the solves this issue
already exists !

The problem is that it is an INTERNAL function !

... or NOT ?

maybe is it accessible ?


Maybe with .NET or C++ ?

VovKa

  • Water Moccasin
  • Posts: 1631
  • Ukraine
Re: LISP PACKAGER
« Reply #6 on: December 26, 2020, 01:43:02 PM »

domenicomaria

  • Swamp Rat
  • Posts: 725
Re: LISP PACKAGER
« Reply #7 on: December 26, 2020, 02:29:45 PM »
VovKa thank you for your reply
. . .
I will take a look at it
It seems to be very interesting . . .
I have to study it.
To understand it.

Does it works well also without an "Author Prefix" ?

Because I'm not so organized !

And however, is this code able to answer to my request, at all ?

Does your routine find the all the code related to all the nested defuns ?

ciao

JohnK

  • Administrator
  • Seagull
  • Posts: 10646
Re: LISP PACKAGER
« Reply #8 on: December 26, 2020, 02:42:47 PM »
Nice one, VovKa.
TheSwamp.org (serving the CAD community since 2003)
Member location map - Add yourself

Donate to TheSwamp.org

VovKa

  • Water Moccasin
  • Posts: 1631
  • Ukraine
Re: LISP PACKAGER
« Reply #9 on: December 26, 2020, 05:15:20 PM »
looks like this is one posted is an old version and is quite slow
think i will have to update it

Does it works well also without an "Author Prefix" ?
hmmm, i do not remeber :)
edit the code to
Code: [Select]
(defun vk_GetAuthorPrefix (/) "")
and try
Does your routine find the all the code related to all the nested defuns ?
at least it does for me :)
it recursively scans all functions in all files in the given directory
here's quite a big app of mine https://www.theswamp.org/index.php?topic=47908.0
it requires more than 300 library functions (spread across 30 files) to work and is assembled with the given function without a problem

one should be careful with this function as it uses read thus 'long' reals would be truncated
i usually store long reals as strings and atof them on the run
by 'long' i mean 'with many significant digits'

Nice one, VovKa.
thank you, John

domenicomaria

  • Swamp Rat
  • Posts: 725
Re: LISP PACKAGER
« Reply #10 on: December 27, 2020, 05:52:29 AM »
(defun VK_READTEXTSTREAM (FileName Charset / ADODBStreamObj Result)
   (if (and   (setq FileName (findfile FileName))
            (setq ADODBStreamObj (vlax-create-object "ADODB.Stream"))
       )
      (progn (setq Result
                     (vl-catch-all-apply
                        (function
                           (lambda ()
                              (vlax-put ADODBStreamObj "Charset" Charset)
                              (vlax-invoke ADODBStreamObj "Open")
                              (vlax-invoke ADODBStreamObj "LoadFromFile" FileName)
                              (vlax-invoke-method ADODBStreamObj "ReadText" -1)
                           )
                        )
                     )
             )
             (vlax-release-object ADODBStreamObj)
             (if (not (vl-catch-all-error-p Result))
                Result
             )
      )
   )
)


(setq txt-strm (VK_READTEXTSTREAM "c:\\ your folder \\TEST.LSP" "windows-1251") )
(setq read-txt-strm (read txt-strm) )
RETURNS ONLY the FIRST DEFUN !
(DEFUN C:TEST1 (/ A B C) (SETQ A 1 B 2 C 3) (+ A B C))
. . .
While TEST.lsp contains these 3 DEFUNs . . .
(defun c:test1 (/ a b c) (setq a 1 b 2 c 3) (+ a b c) )
(defun c:test2 (/ a b c) (setq a 4 b 5 c 6) (+ a b c) )
(defun c:test3 (/ a b c) (setq a 7 b 8 c 9) (+ a b c) )
. . .


Lee Mac

  • Seagull
  • Posts: 12914
  • London, England
Re: LISP PACKAGER
« Reply #11 on: December 27, 2020, 07:24:49 AM »
That's why progn is used in the original code, to always yield a single expression.

domenicomaria

  • Swamp Rat
  • Posts: 725
Re: LISP PACKAGER
« Reply #12 on: December 27, 2020, 09:15:49 AM »
Lee, maybe this one,
was not too much difficult to understand . . .

But what is obvious for you, for vovka . . .
is not the same for me.

I am not a genius like you !

Ciao

domenicomaria

  • Swamp Rat
  • Posts: 725
Re: LISP PACKAGER
« Reply #13 on: December 27, 2020, 09:28:22 AM »
however I am finding some problems . . .

(setq txt-strm (VK_READTEXTSTREAM "C:\\YOUR FOLDER\\%ID-POINT.lsp" "windows-1251") )

(setq txt-strm (strcat "(progn\n" txt-strm "\n)" ) )
(setq read-txt-strm (read txt-strm) )

;   malformed list on input   

WHY ?

the LIST is NOT MALFORMED !


VovKa

  • Water Moccasin
  • Posts: 1631
  • Ukraine
Re: LISP PACKAGER
« Reply #14 on: December 27, 2020, 04:33:31 PM »

WHY ?

the LIST is NOT MALFORMED !


because you have an unclosed comment at the end of your file
|; is missing

JohnK

  • Administrator
  • Seagull
  • Posts: 10646
Re: LISP PACKAGER
« Reply #15 on: December 27, 2020, 08:01:16 PM »
I have seen your software.
It seems to be interesting and well done.
But it is not what I need.
. . .
I have TWO KIND of files :
- ONE lisp file that contains a ROUTINE that DOES something
and uses external SUB-ROUTINES

- SOME lisp files that contain ONLY SUB-ROUTINES

The "PACKAGER"
has to pack up the lisp file that contains the MAIN ROUTINE
and to search, the DEFUNs and their related codes,
in the lisp files that contain only SUB-ROUTINES ...


What I want acheive is
ONE LISP FILE that contains
everything it needs to work and only this

This because,
if I want create a VLX,
I don't want put everything in the "compiler".
 . . .

That's odd because it sounds exactly like what you want. ...You just described one of the many uses of LiFP (That is exactly the design principle behind the use of LiFP).

Read the description and/or tutorial for LiFP again. Your `sub-routines` should be divided into separate files (one file per sub-routine or one file per small group of sub-routines) just like all other programming languages do. I even give you a starting point and created a small (simple) starters library of functions you can use in your code or as a guide to create your own (-i.e. the idea was that you would expand on that library).

The concept of keeping your library functions separate played into the design of LiFP (-I.e. keep the library files somewhere in your path); all the LiFP instructions are kept behind a semi-colin so you can still use/load the files right into AutoCAD with no problems.

And if you ever needed to `package` up your code for compiling or shipment off to a client then you can use the LiFP tool to assemble a file in seconds. LiFP was designed for speed so you can use/call it from another lisp file (it would have zero problem crunching hundreds of files at a time in less then a second).

LiFP is just a preprocessor (it is a fancy way to take files and copies and pastes their contents into another file) so you can use it to build websites, documentation, etc. etc. I have used LiFP in Visual Studio when I did some C# (dotNet) development. It is a very versatile tool.
TheSwamp.org (serving the CAD community since 2003)
Member location map - Add yourself

Donate to TheSwamp.org

domenicomaria

  • Swamp Rat
  • Posts: 725
Re: LISP PACKAGER
« Reply #16 on: December 28, 2020, 12:50:01 AM »
Reading source files...
  reading "C:\@\[PACKAGER]\%BLOCK-INSERT.LSP"...
  reading "C:\@\[PACKAGER]\%BLOCK-MANAGER.lsp"...
  reading "C:\@\[PACKAGER]\%BLOCK-PURGE.lsp"...
  reading "C:\@\[PACKAGER]\%BLOCK-RENAME.lsp"...
  reading "C:\@\[PACKAGER]\%CHANGE-OBJECTS-PROPERTIES.lsp"...
  reading "C:\@\[PACKAGER]\%COMMANDS-COLLECTION.lsp"...
  reading "C:\@\[PACKAGER]\%DIM-LINEAR.LSP"...
  reading "C:\@\[PACKAGER]\%DISTANCE-2P.lsp"...
  reading "C:\@\[PACKAGER]\%DWG-MANAGER.lsp"...
  reading "C:\@\[PACKAGER]\%ID-POINT.lsp"...
  reading "C:\@\[PACKAGER]\%MAKE-INSERT-BLOCK-WBLOCK.LSP"...
  reading "C:\@\[PACKAGER]\%STEEL-PROFILES.LSP"...
  reading "C:\@\[PACKAGER]\%TEXT-UTILITIES.lsp"...
  reading "C:\@\[PACKAGER]\---%3D-UTILITIES.LSP"...
  reading "C:\@\[PACKAGER]\---%commands.LSP"...
  reading "C:\@\[PACKAGER]\3-Point Rectangle.LSP"...
  reading "C:\@\[PACKAGER]\@ABOUT-AND-DEMO-ALERT.lsp"...
  reading "C:\@\[PACKAGER]\@ACAD-ENTITIES.LSP"...
  reading "C:\@\[PACKAGER]\@BASE.lsp"...
  reading "C:\@\[PACKAGER]\@BLOCK-GROUP-SETTINGS.LSP"...
  reading "C:\@\[PACKAGER]\@BLOCK-INSERT.LSP"...
  reading "C:\@\[PACKAGER]\@BOUNDING BOX.LSP"...
  reading "C:\@\[PACKAGER]\@CURVE.LSP"...
  reading "C:\@\[PACKAGER]\@DCL-SELECT-COLOR.lsp"...
  reading "C:\@\[PACKAGER]\@DCL-TEXT-PARAMETERS.lsp"...
  reading "C:\@\[PACKAGER]\@DCL.lsp"...
  reading "C:\@\[PACKAGER]\@ERROR-AND-REQUIREMENTS-CHECKS.lsp"...
  reading "C:\@\[PACKAGER]\@GET-INPUT.lsp"...
  reading "C:\@\[PACKAGER]\@GET-INPUT2.LSP"...
  reading "C:\@\[PACKAGER]\@GRDRAW.lsp"...
  reading "C:\@\[PACKAGER]\@hatch.lsp"...
  reading "C:\@\[PACKAGER]\@INIT-VARS.lsp"...
  reading "C:\@\[PACKAGER]\@INTERS.LSP"...
  reading "C:\@\[PACKAGER]\@LIST.LSP"...
  reading "C:\@\[PACKAGER]\@MATEMATICA E GEOMETRIA.lsp"...
  reading "C:\@\[PACKAGER]\@ODCL-BLOCK-VIEW.lsp"...
  reading "C:\@\[PACKAGER]\@ODCL-BLOCKVIEW-SETTINGS.lsp"...
  reading "C:\@\[PACKAGER]\@ODCL-HATCH-PARAMETERS.lsp"...
  reading "C:\@\[PACKAGER]\@ODCL-INSERTION-PARAMETERS.lsp"...
  reading "C:\@\[PACKAGER]\@ODCL-LINETYPES-PARAMETERS.lsp"...
  reading "C:\@\[PACKAGER]\@ODCL-MESSAGE-BOX.lsp"...
  reading "C:\@\[PACKAGER]\@ODCL-OBJECT-BASE-PROPERTIES.lsp"...
  reading "C:\@\[PACKAGER]\@ODCL-TEXT-PARAMETERS.LSP"...
  reading "C:\@\[PACKAGER]\@ODCL.lsp"...
  reading "C:\@\[PACKAGER]\@OS-FILES.LSP"...
  reading "C:\@\[PACKAGER]\@RICH-TEXT-BOX.LSP"...
  reading "C:\@\[PACKAGER]\@SELECTION-SET-FILTER.lsp"...
  reading "C:\@\[PACKAGER]\@SSET.LSP"...
  reading "C:\@\[PACKAGER]\@STRING-LIST.lsp"...
  reading "C:\@\[PACKAGER]\@STRING.LSP"...
  reading "C:\@\[PACKAGER]\@TABLES.lsp"...
  reading "C:\@\[PACKAGER]\@TEXT.LSP"...
  reading "C:\@\[PACKAGER]\@TL-GROUPS.LSP"...
  reading "C:\@\[PACKAGER]\@VIEWS.lsp"...
  reading "C:\@\[PACKAGER]\@VLAX.LSP"...
  reading "C:\@\[PACKAGER]\bbpoly.lsp"...
  reading "C:\@\[PACKAGER]\CCZZ.LSP"...
  reading "C:\@\[PACKAGER]\changetbfont.LSP"...
  reading "C:\@\[PACKAGER]\CookieCutter2 v1.2 mod by VVA.lsp"...
  reading "C:\@\[PACKAGER]\create-3d-lib.LSP"...
  reading "C:\@\[PACKAGER]\dcl-grid-2c.LSP"...
  reading "C:\@\[PACKAGER]\DCL-LISTBOX.lsp"...
  reading "C:\@\[PACKAGER]\DCL-RIGHT-CLICK-MENU.LSP"...
  reading "C:\@\[PACKAGER]\DCL_PALETTE_TABS_MENU.LSP"...
  reading "C:\@\[PACKAGER]\ElpanovEvgeniy GRREAD.LSP"...
  reading "C:\@\[PACKAGER]\Flex 23 CAB.LSP"...
  reading "C:\@\[PACKAGER]\GRID - OPENDCL SAMPLE.LSP"...
  reading "C:\@\[PACKAGER]\interpolate-triangulation-new.LSP"...
  reading "C:\@\[PACKAGER]\LAYER-LIST.LSP"...
  reading "C:\@\[PACKAGER]\LIST-FUNCTIONS.LSP"...
  reading "C:\@\[PACKAGER]\LISTBOX-STYLE.LSP"...
  reading "C:\@\[PACKAGER]\LM-alphanumsort.LSP"...
  reading "C:\@\[PACKAGER]\LM-GetSyntax.LSP"...
  reading "C:\@\[PACKAGER]\MOUSE REACTOR.LSP"...
  reading "C:\@\[PACKAGER]\NOTEPAD.lsp"...
  reading "C:\@\[PACKAGER]\ODCL8Upd.lsp"...
  reading "C:\@\[PACKAGER]\on_doc_load.lsp"...
  reading "C:\@\[PACKAGER]\Osnaps.lsp"...
  reading "C:\@\[PACKAGER]\qh.lsp"...
  reading "C:\@\[PACKAGER]\STUDIO-PURGEABLE-BLOCKS.LSP"...
  reading "C:\@\[PACKAGER]\tab-test.LSP"...
  reading "C:\@\[PACKAGER]\TEST.LSP"...
  reading "C:\@\[PACKAGER]\Text2MTextV2-0.lsp"...
  reading "C:\@\[PACKAGER]\VK_PACKAGER !.LSP"...
  reading "C:\@\[PACKAGER]\VLA-ADD-MTEXT.lsp"...
  reading "C:\@\[PACKAGER]\WORDS-s.LSP"...
  reading "C:\@\[PACKAGER]\WORDS.LSP"...
  reading "C:\@\[PACKAGER]\WRDS-FORMAT-STRINGS.lsp"...
  reading "C:\@\[PACKAGER]\XML 2.LSP"...
  reading "C:\@\[PACKAGER]\XML.LSP"...
  reading "C:\@\[PACKAGER]\[DEBUG].lsp"...
  reading "C:\@\[PACKAGER]\[LOADER].LSP"...
  reading "C:\@\[PACKAGER]\[Triang V0.6.7].LSP"...
Source files read.
Tracing fucntions.
  tracing 'C:WRDS...
Hard error occurred ***
internal stack limit reached (simulated)


domenicomaria

  • Swamp Rat
  • Posts: 725
Re: LISP PACKAGER
« Reply #17 on: December 28, 2020, 12:58:27 AM »
. . .
And if you ever needed to `package` up your code for compiling or shipment off to a client then you can use the LiFP tool to assemble a file in seconds. LiFP was designed for speed so you can use/call it from another lisp file (it would have zero problem crunching hundreds of files at a time in less then a second).

LiFP is just a preprocessor (it is a fancy way to take files and copies and pastes their contents into another file) so you can use it to build websites, documentation, etc. etc. I have used LiFP in Visual Studio when I did some C# (dotNet) development. It is a very versatile tool.

I prefer a LSP file that does this work.
Because I can undestand and modify it, if i need.

But with lisp it is possible to find this kind of troubles . . .

Hard error occurred ***
internal stack limit reached (simulated)


. . .

thank you for your reply . . .

domenicomaria

  • Swamp Rat
  • Posts: 725
Re: LISP PACKAGER
« Reply #18 on: December 28, 2020, 02:25:34 AM »
perhaps,
to avoid this kind of problem
 
Hard error occurred ***
internal stack limit reached (simulated)


it could be possible
split the work
in more smaller works
(considering the size of LSP files)
and at the end
assemble every things

any idea ?

VovKa

  • Water Moccasin
  • Posts: 1631
  • Ukraine
Re: LISP PACKAGER
« Reply #19 on: December 28, 2020, 08:00:49 AM »
any idea ?
i've been looking at this my function for a while now and the only idea i have is: i have no idea of how it's working :)
i'll implement some 'improvements' (i suppose) and post a new version

d2010

  • Bull Frog
  • Posts: 326
Re: LISP PACKAGER
« Reply #20 on: December 28, 2020, 08:10:59 AM »
You can compile pp_topoxcad.zip to--> pp_topoxcad.lsp.
You can compile pp_peter2ucs.zip to-> pp_peter2ucs.lsp.txt
« Last Edit: December 29, 2020, 06:50:27 AM by d2010 »

domenicomaria

  • Swamp Rat
  • Posts: 725
Re: LISP PACKAGER
« Reply #21 on: December 28, 2020, 11:30:37 AM »
i've been looking at this my function for a while now and the only idea i have is: i have no idea of how it's working :)
i'll implement some 'improvements' (i suppose) and post a new version
Thanks VovKa.
You are very professional and very kind.

However I will try to do something,too.
And if the routine  will work well
I will post it here.

Ciao

domenicomaria

  • Swamp Rat
  • Posts: 725
Re: LISP PACKAGER
« Reply #22 on: December 29, 2020, 03:12:47 AM »
i've been looking at this my function for a while now and the only idea i have is: i have no idea of how it's working :)
i'll implement some 'improvements' (i suppose) and post a new version

Good news VovKa ! ! !

Your code worked well ! ! !

I tried to remove all the not necessary files . . .

It is a little bit slow !

And maybe it cannot handle too many and too much great files . . .

But this is a limit of VLISP . . .

Maybe it could be optimized
splitting the work in more little works
and at the end
assemble the result.

But nothing is easy as it could seem.

. . .
I have found also my (packaged) PACKAGER
that has 1950 lines ! ! !

It works too.
But it works analizing every row of every file
and counts the open parens and the closed parens
...
While your code is almost perfect.
And is very compact.

You are very clever.

Thank you very much.

Ciao



domenicomaria

  • Swamp Rat
  • Posts: 725
Re: LISP PACKAGER
« Reply #23 on: December 29, 2020, 03:46:20 AM »
VovKa
maybe
an ITERATIVE mode
could be better then
a RECURSIVE mode.

Because
the RECURSIVE mode
makes to grow too much
the lists
and the too much nested processes
require too much resources . . .
!

VovKa

  • Water Moccasin
  • Posts: 1631
  • Ukraine
Re: LISP PACKAGER
« Reply #24 on: December 29, 2020, 05:48:08 AM »
Maybe it could be optimized
vk_FindFunction was the 'weakest link', it did a lot of unnecessary work
i've rewritten it long ago but never posted new version because nobody was interested in the code

i also did some more changes and now it is supposed to work even without 'author prefix'

Code: [Select]
(defun vk_GetSysCharset (/) (strcat "windows-" (substr (getvar "SYSCODEPAGE") 6)))
(defun vk_Assemble (Dir   WorkFunctionNamesList OutFileName       /     AllFunctionsList*
    FoundFunction   FunctionTail WorkFunctionNamesList*     WorkFunctionsList
    OutFile ;
    _FindFunction   _TraceFunction _IsFunctionCustom
   )
  (defun _IsFunctionCustom (Name)
    (or
;;;      (wcmatch (vl-symbol-name Name) (strcat (vk_AuthorPrefix) "*,C:" (vk_AuthorPrefix) "*"))
(= (type (eval Name)) 'USUBR)
    )
  )
  (defun _FindFunction (Name FunctionsList /)
    (cond ((not FunctionsList) nil)
  ((atom FunctionsList) nil)
  ((atom (cdr FunctionsList)) nil)
  ((and (= (car FunctionsList) 'DEFUN) (= (cadr FunctionsList) Name)) FunctionsList)
  ((car (vl-member-if (function (lambda (e) (and (listp e) (= (car e) 'DEFUN) (= (cadr e) Name))))
      FunctionsList
)
   )
  )
  ((_FindFunction Name (car FunctionsList)))
  (t (_FindFunction Name (cdr FunctionsList)))
    )
  )
  (defun _TraceFunction (FunctionDefun FunctionTail / Found)
    (if FunctionTail
      (progn (if (atom FunctionTail)
       (setq FunctionTail (list FunctionTail))
     )
     (if (= (car FunctionTail) 'DEFUN)
       (_TraceFunction FunctionTail (cdr FunctionTail))
       (if (listp (car FunctionTail))
(append (_TraceFunction FunctionDefun (car FunctionTail))
(_TraceFunction FunctionDefun (cdr FunctionTail))
)
(if (and (= (type (car FunctionTail)) 'SYM)
  (_IsFunctionCustom (car FunctionTail))
  (not (vl-position (car FunctionTail) WorkFunctionNamesList*))
  (not (vl-position (car FunctionTail) (caddr FunctionDefun)))
  (not (_FindFunction (car FunctionTail) FunctionDefun))
     )
   (append (if (setq Found (_FindFunction (car FunctionTail) AllFunctionsList*))
     (progn (setq WorkFunctionNamesList* (cons (car FunctionTail) WorkFunctionNamesList*))
    (cons (car FunctionTail) (_TraceFunction (car FunctionTail) Found))
     )
     (progn (princ (strcat "    " (vl-symbol-name (car FunctionTail)) " not found\n")) nil)
   )
   (_TraceFunction FunctionDefun (cdr FunctionTail))
   )
   (_TraceFunction FunctionDefun (cdr FunctionTail))
)
       )
     )
      )
    )
  )
  (textscr)
  (setq WorkFunctionNamesList* WorkFunctionNamesList)
  (princ (strcat "Reading source files...\n" Dir "\n"))
  (setq AllFunctionsList*
(apply 'append
(mapcar (function
  (lambda (FileName /)
    (princ (strcat "  " FileName "... "))
    (if (vl-catch-all-error-p (vl-catch-all-apply 'load (list (strcat Dir FileName))))
      (progn (princ "ERROR\n") nil)
      (progn (princ "OK\n")
     (cdr (read (strcat "(progn\n" (vk_ReadTextStream (strcat Dir FileName) (vk_GetSysCharset)) "\n)")))
      )
    )
  )
)
(acad_strlsort (vl-directory-files Dir "*.lsp" 1))
)
)
  )
  (princ "Done\n\n")
  (princ "Tracing functions...\n")
  (foreach WorkFunction WorkFunctionNamesList*
    (princ (strcat "  " (vl-symbol-name WorkFunction) "...\n"))
    (setq FoundFunction (_FindFunction WorkFunction AllFunctionsList*))
    (_TraceFunction FoundFunction (cdr FoundFunction))
  )
  (princ "Done\n\n")
  (princ (strcat "Writing destination file...\n" OutFileName "\n"))
  (setq OutFile (open OutFileName "W"))
  (princ "(vl-load-com)\n" OutFile)
  (foreach WorkFunctionName WorkFunctionNamesList*
    (princ (strcat "  " (vl-symbol-name WorkFunctionName) "...\n"))
    (prin1 (_FindFunction WorkFunctionName AllFunctionsList*) OutFile)
    (princ "\n" OutFile)
  )
  (foreach WorkFunctionName WorkFunctionNamesList
    (if (wcmatch (vl-symbol-name WorkFunctionName) "C:*")
      (princ (strcat "(vl-doc-export '" (vl-symbol-name WorkFunctionName) ")\n") OutFile)
    )
  )
  (close OutFile)
  (princ "Done\n\n")
  (princ)
)
« Last Edit: December 29, 2020, 05:52:22 AM by VovKa »

domenicomaria

  • Swamp Rat
  • Posts: 725
Re: LISP PACKAGER
« Reply #25 on: December 29, 2020, 06:27:40 AM »
Quote
i've rewritten it long ago but never posted new version because nobody was interested in the code

I believe that your code
is absolutely
a "must-have" !


I can't imagine a LISPER
that can work without your routine !

I will test it.
But I feel that you are on the right way.

Thank you very much.
« Last Edit: December 29, 2020, 06:49:09 AM by domenicomaria »

VovKa

  • Water Moccasin
  • Posts: 1631
  • Ukraine
Re: LISP PACKAGER
« Reply #26 on: December 29, 2020, 07:25:03 AM »
I can't imagine a LISPER
that can work without your routine !
it's almost 2021 and all lispers are doing just fine without it :)
i think they have their own routines to organize their projects

domenicomaria

  • Swamp Rat
  • Posts: 725
Re: LISP PACKAGER
« Reply #27 on: December 30, 2020, 05:57:50 AM »
VovKa,
you forgot to add VK_READTEXTSTREAM
to your code . . .

This is the complete WORKING (!  :smitten:) code !

Code - Auto/Visual Lisp: [Select]
  1. (defun vk_GetSysCharset   (/)
  2.    (strcat "windows-" (substr (getvar "SYSCODEPAGE") 6))
  3. )
  4.  
  5. (defun VK_ASSEMBLE (Dir                     WorkFunctionNamesList OutFileName
  6.                     /                     AllFunctionsList*       FoundFunction
  7.                     FunctionTail            WorkFunctionNamesList*
  8.                     WorkFunctionsList      OutFile ;
  9.                     _FINDFUNCTION         _TRACEFUNCTION          _ISFUNCTIONCUSTOM
  10.                    )
  11.  
  12.    
  13.    (defun VK_READTEXTSTREAM (FileName Charset / ADODBStreamObj Result)
  14.       (if (and   (setq FileName (findfile FileName))
  15.                (setq ADODBStreamObj (vlax-create-object "ADODB.Stream"))
  16.           )
  17.          (progn (setq Result
  18.                         (vl-catch-all-apply
  19.                            (function
  20.                               (lambda ()
  21.                                  (vlax-put ADODBStreamObj "Charset" Charset)
  22.                                  (vlax-invoke ADODBStreamObj "Open")
  23.                                  (vlax-invoke ADODBStreamObj "LoadFromFile" FileName)
  24.                                  (vlax-invoke-method ADODBStreamObj "ReadText" -1)
  25.                               )
  26.                            )
  27.                         )
  28.                 )
  29.                 (vlax-release-object ADODBStreamObj)
  30.                 (if (not (vl-catch-all-error-p Result))
  31.                    Result
  32.                 )
  33.          )
  34.       )
  35.    )
  36.  
  37.    
  38.    
  39.    (defun _ISFUNCTIONCUSTOM (Name)
  40.       (or
  41.          ; (wcmatch (vl-symbol-name Name) (strcat (vk_AuthorPrefix) "*,C:" (vk_AuthorPrefix) "*"))
  42.          (= (type (eval Name)) 'USUBR)
  43.       )
  44.    )
  45.  
  46.  
  47.    
  48.    (defun _FINDFUNCTION   (Name FunctionsList /)
  49.       (cond   ((not FunctionsList) nil)
  50.             ((atom FunctionsList) nil)
  51.             ((atom (cdr FunctionsList)) nil)
  52.             ((and   (= (car FunctionsList) 'DEFUN)
  53.                   (= (cadr FunctionsList) Name)
  54.              )
  55.              FunctionsList
  56.             )
  57.             ((car
  58.                 (vl-member-if
  59.                    (function
  60.                       (lambda   (e)
  61.                          (and (listp e) (= (car e) 'DEFUN) (= (cadr e) Name))
  62.                       )
  63.                    )
  64.                    FunctionsList
  65.                 )
  66.              )
  67.             )
  68.             ((_FINDFUNCTION Name (car FunctionsList)))
  69.             (t (_FINDFUNCTION Name (cdr FunctionsList)))
  70.       )
  71.    )
  72.  
  73.  
  74.    
  75.    (defun _TRACEFUNCTION (FunctionDefun FunctionTail / Found)
  76.       (if FunctionTail
  77.          (progn (if (atom FunctionTail)
  78.                    (setq FunctionTail (list FunctionTail))
  79.                 )
  80.                 (if (= (car FunctionTail) 'DEFUN)
  81.                    (_TRACEFUNCTION FunctionTail (cdr FunctionTail))
  82.                    (if (listp (car FunctionTail))
  83.                       (append   (_TRACEFUNCTION FunctionDefun (car FunctionTail))
  84.                               (_TRACEFUNCTION FunctionDefun (cdr FunctionTail))
  85.                       )
  86.                       (if (and (= (type (car FunctionTail)) 'SYM)
  87.                                (_ISFUNCTIONCUSTOM (car FunctionTail))
  88.                                (not   (vl-position (car FunctionTail) WorkFunctionNamesList*)
  89.                                )
  90.                                (not (vl-position (car FunctionTail) (caddr FunctionDefun)))
  91.                                (not (_FINDFUNCTION (car FunctionTail) FunctionDefun))
  92.                           )
  93.                          (append   (if (setq Found (_FINDFUNCTION (car FunctionTail) AllFunctionsList*))
  94.                                     (progn (setq WorkFunctionNamesList*
  95.                                                    (cons   (car FunctionTail)
  96.                                                          WorkFunctionNamesList*
  97.                                                    )
  98.                                            )
  99.                                            (cons (car FunctionTail)
  100.                                                  (_TRACEFUNCTION (car FunctionTail) Found)
  101.                                            )
  102.                                     )
  103.                                     (progn (princ (strcat "    "
  104.                                                           (vl-symbol-name (car FunctionTail))
  105.                                                           " not found\n"
  106.                                                   )
  107.                                            )
  108.                                            nil
  109.                                     )
  110.                                  )
  111.                                  (_TRACEFUNCTION FunctionDefun (cdr FunctionTail))
  112.                          )
  113.                          (_TRACEFUNCTION FunctionDefun (cdr FunctionTail))
  114.                       )
  115.                    )
  116.                 )
  117.          )
  118.       )
  119.    )
  120.  
  121.    
  122.    (textscr)
  123.    (setq WorkFunctionNamesList* WorkFunctionNamesList)
  124.    (princ (strcat "Reading source files...\n" Dir "\n"))
  125.    (setq   AllFunctionsList*
  126.            (apply
  127.               'append
  128.               (mapcar
  129.                  (function
  130.                     (lambda (FileName /)
  131.                        (princ (strcat "  " FileName "... "))
  132.                        (if   (vl-catch-all-error-p
  133.                               (vl-catch-all-apply 'load (list (strcat Dir FileName)))
  134.                            )
  135.                           (progn (princ "ERROR\n") nil)
  136.                           (progn
  137.                              (princ "OK\n")
  138.                              (cdr
  139.                                 (read
  140.                                    (strcat "(progn\n"
  141.                                            (vk_ReadTextStream (strcat Dir FileName) (vk_GetSysCharset))
  142.                                            "\n)"
  143.                                    )
  144.                                 )
  145.                              )
  146.                           )
  147.                        )
  148.                     )
  149.                  )
  150.                  (acad_strlsort (vl-directory-files Dir "*.lsp" 1))
  151.               )
  152.            )
  153.    )
  154.    (princ "Done\n\n")
  155.    (princ "Tracing functions...\n")
  156.    (foreach   WorkFunction WorkFunctionNamesList*
  157.       (princ (strcat "  " (vl-symbol-name WorkFunction) "...\n"))
  158.       (setq FoundFunction (_FINDFUNCTION WorkFunction AllFunctionsList*))
  159.       (_TRACEFUNCTION FoundFunction (cdr FoundFunction))
  160.    )
  161.    (princ "Done\n\n")
  162.    (princ
  163.       (strcat "Writing destination file...\n" OutFileName "\n")
  164.    )
  165.    (setq OutFile (open OutFileName "W"))
  166.    (princ "(vl-load-com)\n" OutFile)
  167.    (foreach   WorkFunctionName WorkFunctionNamesList*
  168.       (princ
  169.          (strcat "  " (vl-symbol-name WorkFunctionName) "...\n")
  170.       )
  171.       (prin1 (_FINDFUNCTION WorkFunctionName AllFunctionsList*)
  172.              OutFile
  173.       )
  174.       (princ "\n" OutFile)
  175.    )
  176.    (foreach   WorkFunctionName WorkFunctionNamesList
  177.       (if (wcmatch (vl-symbol-name WorkFunctionName) "C:*")
  178.          (princ (strcat   "(vl-doc-export '"
  179.                         (vl-symbol-name WorkFunctionName)
  180.                         ")\n"
  181.                 )
  182.                 OutFile
  183.          )
  184.       )
  185.    )
  186.    (close OutFile)
  187.    (princ "Done\n\n")
  188.    (princ)
  189. )
  190.  

ribarm

  • Gator
  • Posts: 3274
  • Marko Ribar, architect
Re: LISP PACKAGER
« Reply #28 on: December 30, 2020, 07:56:16 AM »
This is the complete WORKING (!  :smitten:) code !

You could add command testing function with all necessary inputs like all normal routines...
BTW. I don't know what is it for, I keep organized all my *.lsp files with only those subs that are used in functioning... According to my testings, there is no big gain in speed-efficiency if subs are as globals (not binded within main routine)... All my subs are binded no matter how much I have them and if they are the same - library functions into each *.lsp that is called with invoking command call (c:functionname)...
Marko Ribar, d.i.a. (graduated engineer of architecture)

:)

M.R. on Youtube

domenicomaria

  • Swamp Rat
  • Posts: 725
Re: LISP PACKAGER
« Reply #29 on: December 30, 2020, 02:19:27 PM »
I don't know what is it for, . . .
there is no big gain in speed-efficiency if subs are as globals
. . .
I have
a file that contains all sub-routines that handle STRINGS
a file that contains all sub-routines that handle LISTS
a file that handles OPEN DCL controls
a file that handles GEOMETRICAL issues
a file that handles MATHEMATICAL issues
and so on . . .
. . . when I work on a new LISP project,
it uses some sub-routines contained in these files . . .
. . .
If I need to create a STANDALONE file,
I need a "packager", an "assembler"
that analizes the main routine, finds the name of all the used subroutines,
and searchs in the library files to find the definitions of these functions.
(and finds also the subroutines used from subroutines . . . and so on)
And at the end ASSEMBLES everything in ONLY ONE STANDALONE FILE.

The lisp file of VovKa is for THIS .

Quote
no big gain in speed-efficiency if subs are as globals
We are not treating this issue.

Ciao.


domenicomaria

  • Swamp Rat
  • Posts: 725
Re: LISP PACKAGER
« Reply #30 on: December 30, 2020, 02:26:53 PM »
ONLY ONE STANDALONE FILE
is USEFUL when I have to give the file to someone
. . .
I cannot give the MAIN FILE
and ALL MY LIBRARIES !






ribarm

  • Gator
  • Posts: 3274
  • Marko Ribar, architect
Re: LISP PACKAGER
« Reply #31 on: December 30, 2020, 02:47:01 PM »
No one wants you to give all your library subs... I am saying that when you code, you should actually put needed subs along with main routine and not to keep them separated... What will happen if you loose your library subs - no use of main routines... I know that you backup well your files, but without library subs your other files will be useless... And with this procedure, you actually are doing what should be done as default action IMHO... Yes I think better ever than never, but when I code, I am always avoiding to do things that I would have to do later in future... Yes my library of lisps is big, but then again not so big that with modern computers and good hardware it wouldn't be possible to backup in relatively quick way...
Marko Ribar, d.i.a. (graduated engineer of architecture)

:)

M.R. on Youtube

domenicomaria

  • Swamp Rat
  • Posts: 725
Re: LISP PACKAGER
« Reply #32 on: December 30, 2020, 03:46:38 PM »
Quote
I am saying that when you code, you should actually put needed subs along with main routine and not to keep them separated...
. . . it is frequent that a subroutine contains another sub routine . . .
it is possible that there are more subroutine nested levels . . .
...
all the times that I need a subroutine, it is not so easy to add it to the main file,
it is not so easy to add it and all the nested subroutines . . .
. . .
however, it happens that I need to modify or implement a subroutine
. . .
But if all the times that I work on a new project, I add all the subroutines to it,
when I modify a subroutine, I have to modify it in ALL THE MAIN FILES . . .
. . .
I believe that is good to keep 2 different types of files.

1 - The files that DO SOMETHING
2 - the LIBRARY FILES.

And when I need a STANDALONE FILE,
I will use the VOVKA ASSEMBLER
(or my too much complicated old PACKAGER that has 1950 rows !)
« Last Edit: December 31, 2020, 01:25:38 AM by domenicomaria »

JohnK

  • Administrator
  • Seagull
  • Posts: 10646
Re: LISP PACKAGER
« Reply #33 on: December 30, 2020, 10:34:27 PM »
I keep(t) a library of `sub-routines' as well (when I programmed in AutoLisp and now when I use C/C++). A good directory structure and proper programming habits is/are essential.

The argument about the possibility of loosing library code (`sub routines') is a bad argument.

With AutoLisp, I kept a file per subroutine.
TheSwamp.org (serving the CAD community since 2003)
Member location map - Add yourself

Donate to TheSwamp.org

ribarm

  • Gator
  • Posts: 3274
  • Marko Ribar, architect
Re: LISP PACKAGER
« Reply #34 on: December 30, 2020, 10:46:07 PM »
The argument about the possibility of loosing library code (`sub routines') is a bad argument.

You can say it so from your point of view... I am not saying or wanting that it can/should happen to anyone, but still there is such a possibility, so argument is just fine... I want to say that if/when you actually loose such a file/files, all your work is worthless, nothing is/would be working... If you though keep a good practice to implement subs within routines, when you loose library, still something may work after all... I have to say that once I was in situation to recover from ransomware attack and half of my data on PC were polluted and I had to permanantly remove affected files... Luckily I have a good practice that I backup my important stuff on external drives, so nothing really good wasn't destoyed, but as you see it can happen and really in reality of all of us...
Marko Ribar, d.i.a. (graduated engineer of architecture)

:)

M.R. on Youtube

domenicomaria

  • Swamp Rat
  • Posts: 725
Re: LISP PACKAGER
« Reply #35 on: December 30, 2020, 11:13:24 PM »
Quote
Luckily I have a good practice that I backup
my important stuff on external drives,
so nothing really good wasn't destoyed

This is the solution !

ciao

domenicomaria

  • Swamp Rat
  • Posts: 725
Re: LISP PACKAGER
« Reply #36 on: December 31, 2020, 01:29:06 AM »
Quote
A good directory structure and proper programming habits is/are essential.

Yes. Without this, it is impossible to do something good!

JohnK

  • Administrator
  • Seagull
  • Posts: 10646
Re: LISP PACKAGER
« Reply #37 on: December 31, 2020, 12:03:49 PM »
The argument about the possibility of loosing library code (`sub routines') is a bad argument.

You can say it so from your point of view... I am not saying or wanting that it can/should happen to anyone, but still there is such a possibility, so argument is just fine... I want to say that if/when you actually loose such a file/files, all your work is worthless, nothing is/would be working... If you though keep a good practice to implement subs within routines, when you loose library, still something may work after all... I have to say that once I was in situation to recover from ransomware attack and half of my data on PC were polluted and I had to permanantly remove affected files... Luckily I have a good practice that I backup my important stuff on external drives, so nothing really good wasn't destoyed, but as you see it can happen and really in reality of all of us...
Of course you should be backing up your files--that goes without saying.

The more experience you have, you should resist keeping your library-subs in your main function files because that eliminates the potential for weird behavior/results. -i.e. if your library subs are constant it makes tracking down errors easier. Hence why I created LiFP and VovKa created his tool...

I do not agree with using AutoLisp for this task--it would be akin to using a teaspoon to dig a pool, in my oppinion--but I agree with the method. I believe everyone should maintain their libabries and keep them as clean as possible--and that includes putting them under version control as well. I created my version (LiFP) because I also wanted a way to preform this operation on many projects at once and I could do that with simple batch scripts and windows scheduler--or whenever I felt like it. I could double-click a batch script and update all my code on the network for all the departments in seconds if I ever changed my library sub routines (much of my job at one time was "custom solutions developer" (aka: I wrote programs in AutoLisp, VBA, C++, etc) for multiple departments.
TheSwamp.org (serving the CAD community since 2003)
Member location map - Add yourself

Donate to TheSwamp.org