|
Top Document: comp.cad.autocad AutoLISP FAQ (part 1/2) - general Previous Document: [6] AutoLISP editors and other tools Next Document: [8] Sorting with AutoLISP See reader questions & answers on this topic! - Help others by sharing your knowledge For AutoCAD 2000 and unexperienced VLISP users see [0.1]. There are almost no known serious AutoLISP bugs. The language interpreter itself (ACADL.EXE/.EXP, VLISP) works undoubtedly well. Some restrictions are based on the AutoCAD, ActiveX or the Proteus (DCL) engine. Some support LISP programs (i.e. DDMODIFY.LSP) are faulty sometimes. For Visual Lisp see the README.txt which lists all known bugs and limitations. Crashes with reactors are ACAD bugs. Two inofficial buglists are at: http://www.cadonline.com/exclusive/bugs/bugwatchlist.htm (the big one) http://www.dotsoft.com/buglist.htm (a private and short one) * LDATA by Tom Berger (VLISP for R14 and A2000) In short: Don't use LDATA at all. It may destroy DXF and DWG's in A2000. It is also VERY hard to get rid of them. * List Arguments with DOTTED PAIRS Passed from AutoLISP to Visual LISP or back may loose the outer parens. See the Visual Lisp README (undocumented in Vital Lisp) * SINGLE ATOM LISTS returned incorrectly from EXTERNAL APPS Visual LISP can not distinguish between a LIST of a single atom (element), and a single atom returned from an external ObjectARX or ADS application. * ENTGET used with LWPOLYLINE, HATCH (R14 only) The Z coordinate (caddr (getval 10 ele)) is a random number and often causes a floating point exception because it may too low or too high. Workaround: see part 2, Subject [23.1] * ENTMAKE VERTEX by Terry Dotson (R14 only) A problem can occur during the process of using (entmake) to create polylines, you must assign the layer to each of the VERTEX definitions (which Autodesk has told us), but you must also assign the layer to the ending SEQEND. Absence of this will cause the SEQEND to end up on the current layer, which can be later frozen. Attempts to move this piece of geometry will then cause a EREGEN error and crash in R14 (only). * ACAD_STRLSORT: Strange sort order in Windows. The chars in Windows are not sorted on its ASCII representation! Windows: (acad_strlsort '("-1" "+1")) -> ("-1" "+1"), DOS: (acad_strlsort '("-1" "+1")) -> ("+1" "-1") Both: (mapcar 'ascii ("-" "+")) -> (45 43) More at http://xarch.tu-graz.ac.at/autocad/docs/strlsort-bug.html * AI_PROPCHK (ai_propchk) was renamed to (C:AI_PROP) in the R13c3 update patch. "The AutoLISP function ai_propchk has been changed to c:ai_prop so that it behaves similarly to other commands. This allows pressing return to bring back DDMODIFY if selected from the toolbar." * Faulty action callbacks in R13 DCL code crash AutoCAD There is a bug in R13 where AutoCAD crashes with a Fatal Error if an error occurs in AutoLISP code during an action callback from a scroll bar in a dialog box. For instance, if you try to evaluate a null function during the callback, AutoCAD crashes instantly. Technically, this isn't a bug in the AutoLISP interpreter, but we would still call it an AutoLISP bug. * You cannot rely on bitvalue 64 in flag 70 in symbol tables anymore since R13, but in all previous releases. Inserted blocks may have 64 not set. What else? See the unofficial AutoCAD buglist compiled by Steve Johnson for more faulty AutoLISP programs and behaviours, at http://www.cadonline.com/exclusive/bugs/bugwatchlist.htm * Protected LISP Files In pre-c4a R13 protected LISP files didn't stay protected in memory. In our opinion, this problem needs to be made known to all, so developers don't inadvertently assume their protected code is safe from prying eyes. This FAQ topic caused a major problem in moderated CompuServe's AutoCAD Forum. * Limited number of open selection sets They are intermediatly stored in temporary files. Get rid of not needed selection sets with setting the symbols to nil and run (gc), the garbage collector, which actually closes those files then. The maximal number depends on the operating system, i.e. in DOS of the FILES= value in CONFIG.SYS. R13 improved the number. * Numbers: range, accuracy, numerical precision Integer numbers are internal long fixnums (signed, 32-bit), but the communication from AutoLISP to AutoCAD accepts only 16-bit short fixnums, in the range -32768 .. +32767, because AutoCAD needs only short fixnums. Floating point numbers are doubles (64-bit IEEE). All internal AutoLISP and AutoCAD numerical calculations work with this double format, which should be sufficient. At least the first 14 decimal places are exact. A common problem is the confusion betwen the actual number (exact) and the rounded string representation. The number which is shown on the command-line is always the rounded string which takes care of LUPREC and DIMZIN. However with geometric comparisons there often occur round off errors, so that it's wise to compare points with a small fuzz factor [1e-12..1e-6]. (equal pt1 pt2 1e-6) ; 0.000001 rounding error tolerance instead of (equal pt1 pt2), esp. with angles. See also http://www.autodesk.com/support/techdocs/td30/td301207.htm VB: It was also reported lately, that with certain automation controllers loaded, numerical accuracy and locale issues (`,´ vs `.´) had undesirable sideeffects. A solution and explanation of this problem is pending. (Mostly in `,´ as decimal delimiter countries such as Germany) * ACOMP's (EQ) strictness With [5.1] ACOMP's compiled code you have to take care that the (EQ) behaviour in BI4's is much stricter than in plain AutoLISP. In AutoLISP (eq "1" "1") is T where in ACOMP's compiled code it's nil. The following are not real bugs, that make AutoLISP crash or return false results. They are just bad language implementations. * AND and OR should return the value of the not-NIL argument instead of T. See http://xarch.tu-graz.ac.at/autocad/docs/and-bug.html * MAX and MIN should handle string types too, because < and > accept and process strings types too. * see ACAD_STRLSORT above. * for stack overflow errors see [14] User Contributions:Comment about this article, ask questions, or add new information about this topic:Top Document: comp.cad.autocad AutoLISP FAQ (part 1/2) - general Previous Document: [6] AutoLISP editors and other tools Next Document: [8] Sorting with AutoLISP Part1 - Part2 - Single Page [ Usenet FAQs | Web FAQs | Documents | RFC Index ] Send corrections/additions to the FAQ Maintainer: rurban@xarch.tu-graz.ac.at (Reini Urban)
Last Update March 27 2014 @ 02:11 PM
|
comp.cad.autocad AutoLISP FAQ (part 1/2) - general
Section - [7] AutoLISP problems and bugs
Search the FAQ Archives
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
comp.cad.autocad AutoLISP FAQ (part 1/2) - general
Section - [7] AutoLISP problems and bugs
( Part1 - Part2 - Single Page
)
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Houses ]
Throughout time, we can see how we have been carefully conditioned to come to this point where we are on the verge of a cashless society. Did you know that the Bible foretold of this event almost 2,000 years ago?
In the book of Revelation 13:16-18, we read,
"He (the false prophet who deceives many by his miracles--Revelation 19:20) causes all, both small and great, rich and poor, free and slave, to receive a mark on their right hand or on their foreheads, and that no one may buy or sell except one who has the mark or the name of the beast, or the number of his name.
Here is wisdom. Let him who has understanding calculate the number of the beast, for it is the number of a man: His number is 666."
Referring to the last generation, this could only be speaking of a cashless society. Why so? Revelation 13:17 states that we cannot buy or sell unless we receive the mark of the beast. If physical money was still in use, we could buy or sell with one another without receiving the mark. This would contradict scripture that states we need the mark to buy or sell!
These verses could not be referring to something purely spiritual as scripture references two physical locations (our right hand or forehead) stating the mark will be on one "OR" the other. If this mark was purely spiritual, it would indicate both places, or one--not one OR the other!
This is where it comes together. It is amazing how accurate the Bible is concerning the implantable RFID microchip. Here is information from a man named Carl Sanders who worked with a team of engineers to help develop this RFID chip:
"Carl Sanders sat in seventeen New World Order meetings with heads-of-state officials such as Henry Kissinger and Bob Gates of the C.I.A. to discuss plans on how to bring about this one-world system. The government commissioned Carl Sanders to design a microchip for identifying and controlling the peoples of the world—a microchip that could be inserted under the skin with a hypodermic needle (a quick, convenient method that would be gradually accepted by society).
Carl Sanders, with a team of engineers behind him, with U.S. grant monies supplied by tax dollars, took on this project and designed a microchip that is powered by a lithium battery, rechargeable through the temperature changes in our skin. Without the knowledge of the Bible (Brother Sanders was not a Christian at the time), these engineers spent one-and-a-half-million dollars doing research on the best and most convenient place to have the microchip inserted.
Guess what? These researchers found that the forehead and the back of the hand (the two places the Bible says the mark will go) are not just the most convenient places, but are also the only viable places for rapid, consistent temperature changes in the skin to recharge the lithium battery. The microchip is approximately seven millimeters in length, .75 millimeters in diameter, about the size of a grain of rice. It is capable of storing pages upon pages of information about you. All your general history, work history, criminal record, health history, and financial data can be stored on this chip.
Brother Sanders believes that this microchip, which he regretfully helped design, is the “mark” spoken about in Revelation 13:16–18. The original Greek word for “mark” is “charagma,” which means a “scratch or etching.” It is also interesting to note that the number 666 is actually a word in the original Greek. The word is “chi xi stigma,” with the last part, “stigma,” also meaning “to stick or prick.” Carl believes this is referring to a hypodermic needle when they poke into the skin to inject the microchip."
Mr. Sanders asked a doctor what would happen if the lithium contained within the RFID microchip leaked into the body. The doctor replied by saying a terrible sore would appea (...)