gmane.lisp.cmucl.general

When slots :type are used

Didier Verna — 2008-11-26T17:53:02

Hi again, Section "2.23.2 Slot Type Checking" continues to puzzle me, especially the fact that you have to be within *methods* for the :type slot option to be taken in consideration when writing something to a slot. For instance, with: (defclass foo () ((a :type fixnum))) (defvar *object* (make-instance 'foo)) (setf (slot-value *object* 'a) 3.5) ;; this works like a charm but: (defmethod setslot ((foo foo) val) (setf (slot-value foo 'a) val)) (setslot *object* 3.5) ;; triggers a type error Can somebody provide a rationale for this ?? Thanks.

:type slot option in classes

Didier Verna — 2008-11-26T09:39:47

Hello, Reading section "2.23.2 Slot Type Checking" of the manual, I'm inclined to think that the following code should trigger an error when instanciating the class. But it doesn't: | (declaim (optimize (speed 0) | (compilation-speed 0) | (safety 3) | (debug 0))) | | | (defclass foo () | ((slot :type single-float :initform "bar"))) The behavior is not undefined (as the standard would say), but coherent in the sense that objects of any type can be correctly written and read from the slot, just as if the :type option was not given. Am I missing something ? Thanks! BTW, some more info: * pcl::*use-slot-types-p* T * (lisp-implementation-version) "CVS 19d 19d-release (19D)"

compilation note -> style-warning?

Nicolas Neuss — 2008-11-25T10:11:35

Hello, in the following code a compilation note (returning of double) triggers also a style-warning. Is this intended? (I cannot see how to improve the style...) (catch 'trap (handler-bind ((serious-condition #'(lambda (condition) (throw 'trap condition))) (warning #'(lambda (condition) (throw 'trap condition)))) (compile nil (lambda (x n) (declare (type fixnum n) (type (simple-array double-float (*)) x)) (declare (optimize (safety 0) (space 0) (debug 0) (speed 3))) (loop for i of-type fixnum from 0 below n summing (* (aref x i) (aref x i)) of-type double-float))))) Yours, Nicolas

Please explain this compiler note

Didier Verna — 2008-11-19T15:40:18

[Fwd: ILC]

Raymond Toy — 2008-10-29T13:04:44

In case you didn't already know, there's another Lisp conference coming up. Ray, who might go if he plans things out better this time than he did for OOPSLA.

Mailing list issues?

Raymond Toy — 2008-10-13T13:35:42

Can someone check the mailing lists? It appears that subscriptions work but, in fact, you're not, because messages sent don't make to the list and new messages aren't forwarded to the new subscriber. Well, at least one person has mentioned to me that his subscription doesn't work. Thanks, Ray

CVS down

Raymond Toy — 2008-10-09T13:47:54

Just found out that common-lisp.net is being moved to a new server today (or yesterday). I guess the move is still in progress, so CVS is currently down. Trac is also down. common-lisp.net is up, though. It's being worked on. Ray

SSE2 support

Raymond Toy — 2008-10-06T14:29:52

While you're waiting for the 2008-10 snapshot, here's something new you can play with: SSE2 support for CMUCL. You can grab the (large) binary for Linux from This includes support for both x87 and sse2. (This idea was suggested by Carl.) The C runtime will try to determine if you machine supports sse2 and loads the sse2 core if it does. Otherwise, it loads the x87 core. There's a new command-line switch to allow you to select between the x87 or sse2 core if you want to force a certain core. "-fpu x87" selects the x87 core, and "-fpu sse2" selects the sse2 core. I've run some numerical tests and the sse2 core works just fine. I do not know if the sse2 core is faster or slower than the x87 core, but it does fix some issues with double-float support for x87. (See trac ticket #15, which now returns the correct value.) If you have a machine that does NOT support sse2, I would appreciate it if you could try running this to see if the detection works. There are some rough edges, but if all goes well, SSE2 support should be available for the next snapshot. A related question: Is there anyone who doesn't have sse2? If everyone has sse2, we may eventually drop support for x87. (Except, perhaps for long-float support, if that ever happens.) Ray P.S. Darwin binaries will be uploaded in a bit.

Undefined functions bug summary

Steven Edwards — 2008-10-05T17:29:49

When compiling with (speed 3) (safety 0) (space 0), I get: ; Warning: These functions are undefined: ; STREAM::%LISTEN STREAM::%READ-CHAR STREAM::%UNREAD-CHAR STREAM- LISTEN STREAM-READ-CHAR STREAM-UNREAD-CHAR ; because of references to: listen read-char unread-char (some with stream arguments, some without) However, the compiled code works fine. Banner: CMU Common Lisp 19e (19E), running on gail With core: /Users/sje/cmucl-19e-x86-darwin/lib/cmucl/lib/lisp.core Dumped on: Thu, 2008-05-01 20:38:02-04:00 on macmini See for support information. Loaded subsystems: Python 1.1, target Intel x86 CLOS based on Gerd's PCL 2004/04/14 03:32:47 Compilation banner: ; Python version 1.1, VM version Intel x86 on 05 OCT 08 01:22:45 pm.

Error loading flexi-streams on CMUCL + Debian

Watt Poosanguansit — 2008-09-30T01:40:36

I am new to CMUCL and flexi-streams. I tried to load the library and I got the message below. I have asked this on flexi-streams list and I was told this might be a better place since this might have to do with how CMUCL load the files. Any help is appreciated. ; loading system definition from ; /usr/local/asdf-install/site-systems/flexi-streams.asd into ; # ;; Loading #P"/usr/local/asdf-install/site/flexi-streams-1.0.7/flexi-streams.asd". ; registering # as FLEXI-STREAMS ; registering # as FLEXI-STREAMS-TEST ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O C): ; Compiling Top-Level Form: ;; Loading #P"/var/cache/common-lisp-controller/1000/cmucl/local/usr/local/asdf-install/site/flexi-streams-1.0.7/packages.x86f". ;; Loading #P"/var/cache/common-lisp-controller/1000/cmucl/local/usr/local/asdf-install/site/flexi-streams-1.0.7/mapping.x86f". Error in function LISP::INTERNAL-LOAD: File has a fasl file type, but no fasl file header: "/var/cache/common-lisp-controller/1000/cmucl/local/usr/local/asdf-install/site/flexi-streams-1.0.7/ascii.x86f" [Condition of type SIMPLE-ERROR]

Another stumper compilation diagnostic

Steven Edwards — 2008-09-24T18:08:09

The source (most of it, anyway): ;;; Time mark structure (defstruct (timemark (:print-function (lambda (my-timemark my-stream my-level) (declare (ignore my-level)) (encode-timemark my-stream my-timemark)))) (year 0 :type fixnum) ; Year [0-9999] (month 0 :type fixnum) ; Month number [1-12] (date 0 :type fixnum) ; Day of month number [1-31] (hour 0 :type fixnum) ; Hour of day [0-23] (minute 0 :type fixnum) ; Minute of hour [0-59] (second 0 :type fixnum) ; Second of minute [0-59] (msec 0 :type fixnum)) ; Millisecond of second [0-999] ;;; Time mark routines (defun calc-timemark-from-tm-list (my-tm-list) "Return a new time mark calculated from a time mark list." (make-timemark :year (sixth my-tm-list) :month (fifth my-tm-list) :date (fourth my-tm-list) :hour (third my-tm-list) :minute (second my-tm-list) :second (first my-tm-list) :msec 0)) And the compiler diagnostic: ; In: DEFUN CALC-TIMEMARK-FROM-TM-LIST ; (SIXTH MY-TM-LIST) ; --> NTH CAR NTHCDR BLOCK FLET TYPECASE LET COND IF COND IF PROGN DO BLOCK LET ; --> TAGBODY RETURN-FROM PROGN LISP::FAST-NTHCDR ; ==> ; (MOD LISP::N LISP::I) ; Note: Deleting unused function ; MOD ; ; --> NTH CAR NTHCDR BLOCK FLET TYPECASE LET COND IF COND IF PROGN DO BLOCK LET ; --> TAGBODY RETURN-FROM PROGN LISP::FAST-NTHCDR MOD BLOCK LET ; ==> ; (REM NUMBER KERNEL::DIVISOR) ; Note: Deleting unused function ; REM ; Weird, eh? == Steven

Compiling macros with an optional function parameter?

Denis Papathanasiou — 2008-09-24T16:44:49

I'm not sure if this is a Lisp thing or an issue specific to CMUCL, but when I compile this macro and try to include the resulting x86f file into a larger binary (i.e. using 'cat'), I see this: "Error in batch processing: Cannot dump objects of type FUNCTION into fasl files." This is the macro: (defmacro update-list-hash (hash data-key data-value &optional (test-fn #'string-equal)) "Update the given hash (key:value is 1:n) with data by adding data to the list of values for the key." `(let ((current (gethash ,data-key ,hash))) (if (member ,data-value current :test ,test-fn) current (setf (gethash ,data-key ,hash) (cons ,data-value current))))) If I remove the optional parameter and explicitly specify the member :test parameter inside the macro, I can compile and cat the resulting x86f file without any problems. Any idea why this might be happening and what (if any) work-arounds there are? I'm using CMUCL 19e on debian etch.

Another spurious compilation diagnostic?

Steven Edwards — 2008-09-22T21:06:09

Greetings again, list readers: It seems that every time I compile something like: (list-length some-random-list) I get a compiler warning: ; (LIST-LENGTH SOME-RANDOM-LIST) ; --> BLOCK DO BLOCK LET TAGBODY WHEN COND IF PROGN RETURN ; ==> ; (RETURN-FROM NIL NIL) ; Warning: This is not a (VALUES &OPTIONAL REAL &REST T): ; NIL ; ; [Last message occurs 2 times] Any ideas?

Spurious compilation diagnostic?

Steven Edwards — 2008-09-21T07:45:50

Greetings, list readers: Banner: CMU Common Lisp 19e (19E), running on gail With core: /Users/sje/cmucl-19e-x86-darwin/lib/cmucl/lib/lisp.core Dumped on: Thu, 2008-05-01 20:38:02-04:00 on macmini See for support information. Loaded subsystems: Python 1.1, target Intel x86 CLOS based on Gerd's PCL 2004/04/14 03:32:47 User source (wrapper for read-char): (defun read-ch (my-stream) "Return the next character on an input stream; return nil on end of stream." (read-char my-stream nil nil)) Compilation warning output: ; In: DEFUN READ-CH ; (READ-CHAR MY-STREAM NIL NIL) ; --> BLOCK LET LISP::STREAM-DISPATCH ETYPECASE LET COND IF COND IF COND IF ; --> PROGN LET ; ==> ; (STREAM-READ-CHAR STREAM) ; Warning: Undefined function STREAM-READ-CHAR Is the above a spurious compilation diagnostic? The user function works fine.

Buffered stream output bug report

Steven Edwards — 2008-09-13T13:57:55

Banner: CMU Common Lisp 19e (19E), running on gail With core: /Users/sje/cmucl-19e-x86-darwin/lib/cmucl/lib/lisp.core Dumped on: Thu, 2008-05-01 20:38:02-04:00 on macmini See for support information. Loaded subsystems: Python 1.1, target Intel x86 CLOS based on Gerd's PCL 2004/04/14 03:32:47 Three related bugs: (defun bug0 (my-stream) (write-char #\1 my-stream) (format my-stream "~D" 2) (write-char #\3 my-stream)) (defun bug1 (my-stream) (write-char #\1 my-stream) (format my-stream "~D" 2) (write-char #\3 my-stream) (finish-output my-stream)) (defun bug2 (my-stream) (write-char #\1 my-stream) (finish-output my-stream) (format my-stream "~D" 2) (finish-output my-stream) (write-char #\3 my-stream) (finish-output my-stream)) (bug0 t) -> should print "123". It doesn't. (bug1 t) -> should print "123". It doesn't. (bug2 t) -> should print "123". It doesn't. In fact, the outputs are all different. GNU clisp seems to handle these okay, as does GNU gcl. Thank you for your time. == Steven

defmethod+flet

Walter C. Pelissero — 2008-07-21T15:13:59

I just stumbled in something that doesn't look quite right to me. Under 19E the following is legal code: (defmethod foo (x) x) (defmethod bar (x) (flet ((foo (a) (declare (ignore a)))) (foo))) while I'd expect a warning for the missing argument in the call of FOO. On the other hand the following code does produce a warning in the call of FOO2 (missing argument): (defmethod foo2 (x) x) (defmethod bar2 (x) (flet ((foo2 ())) (foo2))) SBCL doesn't show this behaviour.

Bug in snapshot 2008-05 for x86

Raymond Toy (RT/EUS — 2008-05-20T15:36:53

Just discovered a bug in snapshot 2008-05 for all x86 versions. It affects arrays of (unsigned-byte 16) or (signed-byte 16). You can see for yourself with: (defun bar () (declare (optimize (speed 3) (safety 0))) (make-array 8 :element-type '(unsigned-byte 16) :initial-element 42)) Compile this, and (bar) produces #(0 1 2 3 4 5 6 7) instead of #(42 42 42 42 42 42 42 42). The bug may manifest itself in other ways, though, so that when you set an element of such an array, you get some weird number. This will be fixed in the next snapshot. Until then, I would recommend using the previous snapshot. This bug does NOT affect the 19e release. The bug was introduced after the release branch was made. Sorry for the problem, Ray

CMUCL 19e released

Raymond Toy (RT/EUS — 2008-05-19T15:21:34

========================== C M U C L 19 e ============================= The CMUCL project is pleased to announce the release of CMUCL 19e. This is a major release which contains numerous enhancements and bugfixes from the 19d release. CMUCL is a free, high performance implementation of the Common Lisp programming language which runs on most major Unix platforms. It mainly conforms to the ANSI Common Lisp standard. CMUCL provides a sophisticated native code compiler; a powerful foreign function interface; an implementation of CLOS, the Common Lisp Object System, which includes multimethods and a metaobject protocol; a source-level debugger and code profiler; and an Emacs-like editor implemented in Common Lisp. CMUCL is maintained by a team of volunteers collaborating over the Internet, and is mostly in the public domain. New in this release: * Supported system: - Support for Mac OS X/Intel has been added for OSX 10.5 and later. * Issues - One some openSUSE systems, cmucl will fail to start because it can't map enough memory. This might be caused be a memory limit that is set too low. Use "ulimit -a" to see the limit on virtual memory. This can be adjusted with "ulimit -v " - Tracing on Mac OS X/Intel uses encapsulation, unlike other platforms. This means tracing recursive functions may not show the recursive calls. You can try setting debug::*trace-encapsulate-default* to :default. Be warned that under some conditions, tracing will cause an error such that you can not get back to the repl and must terminate the process in some other way. * Feature enhancements: - Support for dynamic-extent added for ppc. However, it suffers from the same problems with dynamic-extent as other platforms, so it is disabled by default. Tests indicate that it does work in simple situations. - PARSE-TIME recognizes the format produced by C asctime/ctime. (This change may break some other less commonly used patterns.) - PARSE-TIME recognizes and discards any microseconds. - PARSE-TIME checks that a specified day of the week matches the actual day of the week given in the date. An error is signaled if they are inconsistent. - New option to SAVE-LISP allows creating executable Lisp images that do not require a runtime loader. Syntax: (save-lisp "filename" :executable t) Currently supported on FreeBSD and Linux; work on a Solaris version is underway. Limitations: depends on files in "library:" to dump new executable images. - CMUCL's version of CLX has been replaced with telent CLX. - Preliminary support for external formats. Currently only iso8859-1 and utf-8 are supported. Utf-8 support is limited since CMUCL only has 8-bit characters. - UNIX-MPROTECT added to access mprotect. * ANSI compliance fixes: - BOA constructors with &AUX variables are handled better now. - SHADOW accepts characters now. - Default initargs are now passed correctly to initialize-instance and shared-initialize. - Several issues in formatted output of floats have been fixed: o ~,dF won't print out extra digits if the number is too small. o ~E sometimes erroneously printed the overflow filler instead of the number. o ~G has changed so that ~E is chosen more often. This is seen when printing large numbers. Instead of printing lots of zeroes, ~E is used. ~G now matches what Fortran would do. o Inconsistencies between print and ~E are now gone. (See Trac ticket #1.) o Some incorrectly printed results for ~E have been fixed. (See Trace ticket #12.) * Bugfixes: - Floating-point traps are now handled on ppc. Previously, no traps were signalled and SET-FLOATING-POINT-MODES did nothing. - FILE-POSITION no longer returns negative values for mapped file-simple-stream's. - Potential Version numbers that start with a leading 0 are no longer treated as version numbers. Hence, "foo.~1~" has name "foo", type nil, and version 1, but "foo.~01~" has type "~01~" and version :NEWEST. - A bug in type derivation for EXPT has been fixed. (expt x y) for x of type (double-float (0d0) 1d0) and y of type (double-float (0d0)) now returns (or (member 0d0) (double-float (0d0) 1d0)) instead of (double-float 0d0 1d0), i.e., -0d0 is not in the range. - On sparc, the decoding of a trapping FP instruction is correct now. Previously the wrong instruction was decoded, which produced the wrong operation and operands in the arithmetic error handler. - Fix issue with UNIX:UNIX-MMAP handling of "large" addresses that appeared to be negative numbers. - DOUBLE-DOUBLE-FLOAT fixes: o Converting negative rationals to double-double-float's doesn't produce wrong answers anymore. o (float 1w0) no longer returns a positive result. o Some issues with creation of DOUBLE-DOUBLE-FLOAT and (COMPLEX DOUBLE-DOUBLE-FLOAT) have been fixed on sparc, ppc, and x86. These seem to work, except there appears to be some bugs on x86 when compiling at speed 3 and safety 0. o (INTEGER-DECODE-FLOAT ) was sometimes returning the wrong integer value because the two components had the wrong sign. o Some issues with debugger printing out DOUBLE-DOUBLE-FLOATs and (COMPLEX DOUBLE-DOUBLE-FLOAT)'s have been fixed. o CLOS now recognizes that (COMPLEX DOUBLE-DOUBLE-FLOAT) is a valid built-in class instead of a random object. o Branch cuts for ASIN and ATANH for double-double-float's should match the branches for double-float's. o ATAN2 should correctly handle signed double-double-float zeroes. o FASL files containing -0w0 are now converted to -0w0 instead of 0w0. o SIN and TAN return -0w0 when the argument is -0w0. Previously, they returned 0w0. o Signed zeroes are handled better for addition, subtraction, and multiplication. That is, the correct signed zero is returned now. o Overflow in addition, multiplication, and division returns infinity if traps are disabled. o EQL supports DOUBLE-DOUBLE-FLOAT's now. o The printer and reader should now be consistent for double-double-floats. o Conversion of bignums and ratios to double-double-floats should be more accurate. o Double-double-float's should have print/read consistency now. o TRUNCATE works now when given a DOUBLE-DOUBLE-FLOAT divisor. o FORMATted output of DOUBLE-DOUBLE-FLOAT's should work. - The assembler for ppc had some arguments for some instructions in the wrong order, producing the wrong effect. - When making displaced arrays, the element types are checked to see if they are type equivalent. If not, an error is signaled. - The reader for #= and ## has been enhanced to be much faster for cases with a large number of shared objects. However, it is also somewhat slower for simple cases. - #p"..." now has a namestring and is treated as a pathname with name ".." and type "". - #p"..a" erroneously had directory (:relative). This has been fixed so that directory = nil, name = ".", and type = "a". - Compiling code using SIGNUM no longer causes a compiler error. The defoptimizer for SIGNUM was missing a case for double-double-float. - MAPHASH no longer causes a type-error when the mapping function calls (setf gethash) on the same table. - NOTINLINE declarations are honored for local functions even if they only have only one use. Previously, these would be inlined anyway. This allows tracing of such functions. - TRACE and UNTRACE should now work as expected for local labels/flet functions. Untracing should work. Redefining a function should automatically retrace the local functions if they were traced previously. - Callbacks should now work on systems where malloc'ed space does not normally allow execution of code. - The FLOAT-ACCURACY declaration has been removed. This should have no affect on most user's code, unless they were using this. The default is 53-bit (double-float) precision for everything and the compiler takes care of the precision for the appropriate ABI. It is the compiler's responsibility to make sure single-precision floats are done correctly with single-precision results. (This may be buggy currently.) - The :PRECISION-CONTROL keyword in SET-FLOATING-POINT-MODES has been removed. - A compiler bug with type inferencing and deleting unsued functions has been fixed. - A compiler bug has been fixed where a source transformation was incorrectly applied because the local variable happens to have a function type and has the same name as a known function. - On Darwin/x86, tracing with :encapsulate nil works better, and tracing of labels/flets works better. However, there are still issues with tracing. Returning to the repl after tracing sometimes fails, and you must exit lisp completely. - ~E should be faster now in some cases. - The range over which sin/cos/tan would use the builtin instruction on x86 has been reduced. Previously, values near the limit would either produce result greater than 1 in absolute value or cause a floating-point exception. Note that accuracy is reduced when the builtin instructions are used for very large arguments. - Issues with compact info environments should be fixed. The issue manifests itself when a new core is saved with lots of functions (or other objects). The resulting core executes the wrong code for some of the functions. * Trac Tickets: - #8 fixed so logs of bignums and ratios that won't fit into a float can be computed, instead of signalling an error. - #9 fixed. An error is generated if the number of days doesn't match the number of days in the given month. - #10 fixed. ROUND should now return correct answers for floats bigger than most-positive-fixnum. - #11 fixed. EQL handles double-double-float's correctly now. - #1 fixed. prin1 and ~E should produce the same results. - #12 fixed. (format t "~10,1,2,0,'*,,'DE" 1d-6) prints "0.1D-05" now. - #13 fixed. (format nil "~11,3,2,0,'*,,'EE" .9999) produces 0.100e+1 instead of 1.000e+0. * Other changes: - UNIX:UNIX-ERRNO accesses the thread errno value instead of the global errno value. - Floating point zero is now printed with an exponent of zero, independent of any scale factor that might be used. Thus, we get results like "0.0D+00" instead of "0.0D-5". - CMUCL should now build and run on Redhat Fedora Core 9. * Improvements to the PCL implementation of CLOS: - Forward-referenced classes are allowed. * Changes to rebuilding procedure: - load-world.sh now supports a -p option to load the world without PCL. This is mostly for cross-compiling which doesn't want PCL loaded because it's not build during a cross-compile. - make-dist.sh now defaults to bzip compression instead of gzip. This release is not binary compatible with code compiled using CMUCL 19d; you will need to recompile FASL files. See for download information, guidelines on reporting bugs, and mailing list details. We hope you enjoy using this release of CMUCL!

Installing CMUCL on a remote machine

scem geyik — 2008-03-26T19:08:36

Hello, I have a 14-year old software that I am trying to run on a new machine. The author of the software has written that he has tested it with cmucl 17e, but this can not be installed on a solaris 2.10 machine. Due to this I tried to install the closest possible version (18a) to the solaris 2.10 machine which I connect remotely and I don't have the administrator rights. I opened the zip files (solaris24.tgz and solaris24.extra.tgz) to my user directory --I did the necessary environment variable changes-- and set the CMUCLLIB to my user director (which is not /lib)but some_user_directory/lib and when I try to run lisp it says: can not find file: /usr/local/lib/cmucl/lib/lisp.core, it doesn't exisst what should I do for lisp to see lisp.core, I tried lisp -core lisp.core but this time it gave Segmentation Fault. Any help would be appreciated, thanks in advance _________________________________________________________________ Watch Cause Effect, a show about real people making a real difference. Learn more. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause

cmucl-19e + gcc43 better, not quite there

Rex Dieter — 2008-03-14T19:37:44

Tried out cmucl-19e-pre1, and this works better (than cmucl-19d) and gets further, but fails in some asm in ../../src/lisp/x86-assem.S ../../src/lisp/x86-assem.S: Assembler messages: ../../src/lisp/x86-assem.S:84: Error: suffix or operands invalid for `fnstsw' ?? For complete build.log, see http://koji.fedoraproject.org/koji/getfile?taskID=515618&name=build.log Further, attached is a quick-n-dirty patch I needed to make it not choke on #include -> #include which contains #ifdef __i386__ #include "unistd_32.h" #else #include "unistd_64.h" #endif on recent kernel-headers. In short, translating -I- to use -iquote instead (and have the build respect our rpm optflags)

[Newbie Q] Detecting what packages are defined

David A. Cobb — 2008-02-15T20:03:01

I've read the documentation -- even the Hyperspec, tho' it gives me a headache. I must not have seen the "right" document, because I miss the answer to a simple question: How can I determine what packages are already defined? I see a lot of symbols that look like package-names in *FEATURES*, but nothing to suggest that that is automatic or even recommended. If I look at *MODULES*, the names I see don't look like known packages; and of course *MODULES* is "depreciated." The spec seems to require that the namespace of package-names is unique and separate from any other namespace, so enumerating it shouldn't be such a big deal. TIA