AutoLISP STDLIB mail archive [part 10], 13.Jun.00 - 27.Oct.00
[Date Prev][Date Next] [Thread Prev][Thread Next]     [Date Index] [Thread Index] [Author Index]

Re: stdlib dict functions

Hi David,

David Kozina schrieb:

the problem with vladimir's functions is the disclaimer.
he wants some reward if you use it commercially. so i didn't include it.
and it does more than is needed.

> Well, I've found Vladimir's functions *very* helpful for this (I wish they
> were in the STDLIB), but wouldn't
> you know, among the other helper functions in this lisp file there is this
> one:
> ;; List A Dictionary As Pairs {Name . Object Name}
> (defun dict-list...
> Vladimir's function is somewhat different than the one I came up with
> (independently) and it appears to take other dxf group code factors into
> account that I've never even seen before.  So I wouldn't be a bit surprised
> if his is better than the one I sent to you.  I realize that the dictionary
> functions I wrote were quite minimal in their functionality.  I was mostly
> just looking for a little easier way to access the entity names.

I'll have a look also and maybe rewrite it :)
it uses xrecords and is modifying instead of your simple query functions.

> But Vladimir's function naming leads me to wonder if the DICT module
> functions maybe should be renamed to avoid conflicts with his?  Or maybe
> just the DICT-LIST?  I really don't know.  For my own personal use, I've
> renamed all of Vladimir's SaveData functions to VN-..., thus solving the
> conflicts for *me*, but not for others.

I will not rename the dict module for sure. this is pretty stable now.

> This probably isn't a really big deal, but I just wanted to bring it to your
> attention.

Thanks. I'll think about the name conflict. maybe a check-function
which tests against vladimir's function.
maybe the put function as well, but probably in a later release (past 1.0)
I see no big advantage over xdata.

of course the encoder/decoder is very useful. I'll probably add serge volkov's
or my private version to the stdlib sooner or later.
mine is not recursive.

> One other comment is that the ENTMAKE-MLINE I sent you ...

yes, I'll remove it.

> No news is good news?

sure! there're still some known problems but not discouraging ones.
and there are still some not yet known problems for sure. just last week
I found a bug in vl-file-copy! (which is fixed in the std- version 0.5004).
today I fixed STD-GET-DRIVE-LIST

temp. it is at:
Reini Urban
(sorry, no free web service for some time)