xemacs-beta: src/lrecord.h comparison

comparison src/lrecord.h @ 5125:b5df3737028a ben-lisp-object

merge

author	Ben Wing <ben@xemacs.org>
date	Wed, 24 Feb 2010 01:58:04 -0600
parents	623d57b7fbe8 0d4c9d0f6a8d
children	2a462149bd6a

comparison

equal deleted inserted replaced

-:623d57b7fbe8
+:b5df3737028a
 /* The "lrecord" structure (header of a compound lisp object).
 Copyright (C) 1993, 1994, 1995 Free Software Foundation, Inc.
-Copyright (C) 1996, 2001, 2002, 2004, 2005, 2009 Ben Wing.
+Copyright (C) 1996, 2001, 2002, 2004, 2005, 2009, 2010 Ben Wing.
 This file is part of XEmacs.
 XEmacs is free software; you can redistribute it and/or modify it
 under the terms of the GNU General Public License as published by the
 do not need to supply all the methods (see below); reasonable
 defaults are provided for many of them.  Alternatively, if you're
 just looking for a way of encapsulating data (which possibly
 could contain Lisp_Objects in it), you may well be able to use
 the opaque type.
-The "public API's" meant for use by regular Lisp objects are macros
-in capital letters, involving the word "LISP_OBJECT".  Underlyingly,
-the functions and structures use "lrecord" or "lcrecord", but most
-code shouldn't have to worry about this.
 */
+#ifdef NEW_GC
+/*
+There are some limitations under New-GC that lead to the creation of a
+large number of new internal object types.  I'm not completely sure what
+all of them are, but they are at least partially related to limitations
+on finalizers.  Something else must be going on as well, because
+non-dumpable, non-finalizable objects like devices and frames also have
+their window-system-specific substructures converted into Lisp objects.
+It must have something to do with the fact that these substructures
+contain pointers to Lisp objects, but it's not completely clear why --
+object descriptions exist to indicate the size of these structures and
+the Lisp object pointers within them.
+At least one definite issue is that under New-GC dumpable objects cannot
+contain any finalizers (see pdump_register_object()).  This means that any
+substructures in dumpable objects that are allocated separately and
+normally freed in a finalizer need instead to be made into actual Lisp
+objects.  If those structures are Dynarrs, they need to be made into
+Dynarr Lisp objects (e.g. face-cachel-dynarr or glyph-cachel-dynarr),
+which are created using Dynarr_lisp_new() or Dynarr_new_new2().
+Furthermore, the objects contained in the Dynarr also need to be Lisp
+objects (e.g. face-cachel or glyph-cachel).
+--ben
+*/
+#endif
 #ifdef NEW_GC
 #define ALLOC_LISP_OBJECT(type) alloc_lrecord (&lrecord_##type)
 #define ALLOC_SIZED_LISP_OBJECT(size, type) \
 alloc_sized_lrecord (size, &lrecord_##type)
 #ifndef NEW_GC
 lrecord_type_free, /* only used for "free" lrecords */
 lrecord_type_undefined, /* only used for debugging */
 #endif /* not NEW_GC */
 #ifdef NEW_GC
+/* See comment up top explaining why these extra object types must exist. */
 lrecord_type_string_indirect_data,
 lrecord_type_string_direct_data,
 lrecord_type_hash_table_entry,
 lrecord_type_syntax_cache,
 lrecord_type_buffer_text,
 libraries, such as window-system windows or file handles.  This can be
 NULL, meaning no special finalization is necessary. */
 void (*finalizer) (void *header);
 /* This can be NULL, meaning compare objects with EQ(). */
-int (*equal) (Lisp_Object obj1, Lisp_Object obj2, int depth);
+int (*equal) (Lisp_Object obj1, Lisp_Object obj2, int depth,
+		int foldcase);
 /* `hash' generates hash values for use with hash tables that have
 `equal' as their test function.  This can be NULL, meaning use
 the Lisp_Object itself as the hash.  But, you must still satisfy
 the constraint that if two objects are `equal', then they *must*
 && !LRECORD_FREE_P (MCACF_lheader)  )				\
 {									\
 const struct lrecord_implementation *MCACF_implementation		\
 	= LHEADER_IMPLEMENTATION (MCACF_lheader);			\
 if (MCACF_implementation && MCACF_implementation->disksaver)	\
-	MCACF_implementation->disksaver (ptr);				\
+	MCACF_implementation->disksaver (MCACF_obj);			\
 }									\
 } while (0)
 #define LRECORD_FREE_P(ptr)			\
 (((struct lrecord_header *) ptr)->free)
 { XD_BLOCK_PTR,	offsetof (Lisp_Foo, objects),
 XD_INDIRECT (0, 0), { &lisp_object_description } },
 ...
 };
-lisp_object_description is declared in alloc.c, like this:
+lisp_object_description is declared in gc.c, like this:
 static const struct memory_description lisp_object_description_1[] = {
 { XD_LISP_OBJECT, 0 },
 { XD_END }
 };
 #define XD_IS_INDIRECT(code) ((code) < 0)
 #define XD_INDIRECT_VAL(code) ((-1 - (code)) & 255)
 #define XD_INDIRECT_DELTA(code) ((-1 - (code)) >> 8)
-#define XD_DYNARR_DESC(base_type, sub_desc)				      \
-{ XD_BLOCK_PTR, offsetof (base_type, base), XD_INDIRECT(1, 0), {sub_desc} },\
-{ XD_INT,        offsetof (base_type, cur) },				      \
-{ XD_INT_RESET,  offsetof (base_type, max), XD_INDIRECT(1, 0) }	      \
-#ifdef NEW_GC
-#define XD_LISP_DYNARR_DESC(base_type, sub_desc)			\
-{ XD_LISP_OBJECT_BLOCK_PTR, offsetof (base_type, base),		\
-XD_INDIRECT(1, 0), {sub_desc} },					\
-{ XD_INT,        offsetof (base_type, cur) },				\
-{ XD_INT_RESET,  offsetof (base_type, max), XD_INDIRECT(1, 0) }
-#endif /* not NEW_GC */
 /* DEFINE_*_LISP_OBJECT is for objects with constant size. (Either
 DEFINE_DUMPABLE_LISP_OBJECT for objects that can be saved in a dumped
 executable, or DEFINE_NODUMP_LISP_OBJECT for objects that cannot be
 saved -- e.g. that contain pointers to non-persistent external objects
 such as window-system windows.)

Mercurial > hg > xemacs-beta

comparison src/lrecord.h @ 5125:b5df3737028a ben-lisp-object