From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Tom Lord Newsgroups: gmane.lisp.guile.devel Subject: Re: i know -- let's play bridge! Date: Sat, 3 Aug 2002 20:55:41 -0700 (PDT) Sender: guile-devel-admin@gnu.org Message-ID: <200208040355.UAA14721@morrowfield.regexps.com> References: <200208040205.TAA14205@morrowfield.regexps.com> <200208040227.TAA14327@morrowfield.regexps.com> <200208040246.TAA14414@morrowfield.regexps.com> <87wur772x2.fsf@becket.becket.net> <200208040257.TAA14483@morrowfield.regexps.com> <87sn1v729z.fsf@becket.becket.net> NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1028432972 1343 127.0.0.1 (4 Aug 2002 03:49:32 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 4 Aug 2002 03:49:32 +0000 (UTC) Cc: guile-devel@gnu.org Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17bCOW-0000LH-00 for ; Sun, 04 Aug 2002 05:49:28 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17bCP5-0005Rs-00; Sat, 03 Aug 2002 23:50:03 -0400 Original-Received: from 1cust242.tnt13.sfo8.da.uu.net ([63.10.241.242] helo=morrowfield.regexps.com) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17bCOW-0005Lt-00 for ; Sat, 03 Aug 2002 23:49:29 -0400 Original-Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id UAA14721; Sat, 3 Aug 2002 20:55:41 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Original-To: tb@becket.net In-Reply-To: <87sn1v729z.fsf@becket.becket.net> (tb@becket.net) Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:957 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:957 > I think there are some other players who suffer a > disabilitating lack of trust that would make that possible, though, > and I am beyond exhaustion at trying to win them over.... at least > that's my (repeated and extensive) experience.) First: dammit tb -- shut up. I really want to say "bye" here on some pithy note about how to allocate tags. Don't drag me into politics on this list. Second: have you ever had a conversation with a bunch of people who aren't wage slaves where it's painfully apparent that they are trying to evaluate whether you can be trusted with a public spotlight that they control? While your family is starving and suffering and being agreeable to such assholes is your apparent best chance? Sorry developer's list --- tb just knows how to push my buttons. -t ! The Heap Type Tag Spec File -*-*- * Location Tags This file is part of the source code for the Hackerlab C library. It's translated to C by the awk program "./tags.awk". A value of of type `scm_location_tag' holds a tag value (`enum scm_location_tag') that describes the physical type of some location. A value of type `scm_location_storage' is a value of type `scm_location_tag' tagged with an `enum scm_location_arity'. The tag indicates whether the location contains a single value or a pointer to a dynamic array of (homogenously typed) values. The type `scm_location_desc' is a `scm_location_storage_type' tagged with `enum scm_location_protection'. The tag describes whether and under what conditions the location may be read and written. Note that this is a tripple-tagged value: when decoded, it yields another tagged value (using two disjoint sets of tags). When that second value is decoded, the final result is yet another tag value (in yet another disjoint set): the data type stored at the lcoation. `scm_location_storage' fits (exactly) in 8 bits. *> heap-tags tags scm_location_desc **: decodes-to scm_location_storage **> split-tag protection 2 ***> tag opaque ***> tag guarded ***> tag read_only ***> tag public *> tags scm_location_storage **: decodes-to scm_location_type **> split-tag arity 1 ***> tag cell ***> tag array *> tags scm_location_type **: decodes-to t_uint **> split-tag id 5 ***> tag t_uint8 ***> tag t_int8 ***> tag t_uint16 ***> tag t_int16 ***> tag t_uint32 ***> tag t_int32 ***> tag t_uint64 ***> tag t_int64 ***> tag scm_float32 ***> tag scm_float64 ***> tag scm_u ***> tag scm_i ***> tag scm ***> tag unused_loc_0 ***> tag unused_loc_0 ***> tag unused_loc_0 ***> tag unused_loc_0 ***> tag unused_loc_0 ***> tag unused_loc_0 ***> tag unused_loc_0 ***> tag unused_loc_0 ***> tag unused_loc_0 ***> tag unused_loc_0 ***> tag unused_loc_0 ***> tag unused_loc_0 ***> tag unused_loc_0 ***> tag unused_loc_0 ***> tag unused_loc_0 ***> tag unused_loc_0 ***> tag unused_loc_0 ***> tag unused_loc_0 ***> tag unused_loc_0 * Structure Tags A simple physical strucutre type is described by an array of location tags (roughly one for each field) plus two parameters: alignment and allocation strategy. Alignment is a power of two that establishes the grid on which fields are aligned when in contiguous memory. The allocation strategy is: _inline_ for a flat object. _handle_ for a separately resizable object _pow2_array_ for a _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel