Mercurial > hg > xemacs-beta
annotate man/lispref/dragndrop.texi @ 4921:17362f371cc2
add more byte-code assertions and better failure output
-------------------- ChangeLog entries follow: --------------------
src/ChangeLog addition:
2010-02-03 Ben Wing <ben@xemacs.org>
* alloc.c (Fmake_byte_code):
* bytecode.h:
* lisp.h:
* lread.c:
* lread.c (readevalloop):
* lread.c (Fread):
* lread.c (Fread_from_string):
* lread.c (read_list_conser):
* lread.c (read_list):
* lread.c (vars_of_lread):
* symbols.c:
* symbols.c (Fdefine_function):
Turn on the "compiled-function annotation hack". Implement it
properly by hooking into Fdefalias(). Note in the docstring to
`defalias' that we do this. Remove some old broken code and
change code that implemented the old kludgy way of hooking into
the Lisp reader into bracketed by `#ifdef
COMPILED_FUNCTION_ANNOTATION_HACK_OLD_WAY', which is not enabled.
Also enable byte-code metering when DEBUG_XEMACS -- this is a form
of profiling for computing histograms of which sequences of two
bytecodes are used most often.
* bytecode-ops.h:
* bytecode-ops.h (OPCODE):
New file. Extract out all the opcodes and declare them using
OPCODE(), a bit like frame slots and such. This way the file can
be included multiple times if necessary to iterate multiple times
over the byte opcodes.
* bytecode.c:
* bytecode.c (NUM_REMEMBERED_BYTE_OPS):
* bytecode.c (OPCODE):
* bytecode.c (assert_failed_with_remembered_ops):
* bytecode.c (READ_UINT_2):
* bytecode.c (READ_INT_1):
* bytecode.c (READ_INT_2):
* bytecode.c (PEEK_INT_1):
* bytecode.c (PEEK_INT_2):
* bytecode.c (JUMP_RELATIVE):
* bytecode.c (JUMP_NEXT):
* bytecode.c (PUSH):
* bytecode.c (POP_WITH_MULTIPLE_VALUES):
* bytecode.c (DISCARD):
* bytecode.c (UNUSED):
* bytecode.c (optimize_byte_code):
* bytecode.c (optimize_compiled_function):
* bytecode.c (Fbyte_code):
* bytecode.c (vars_of_bytecode):
* bytecode.c (init_opcode_table_multi_op):
* bytecode.c (reinit_vars_of_bytecode):
* emacs.c (main_1):
* eval.c (funcall_compiled_function):
* symsinit.h:
Any time we change either the instruction pointer or the stack
pointer, assert that we're going to move it to a valid location.
This should catch failures right when they occur rather than
sometime later. This requires that we pass in another couple of
parameters into some functions (only with error-checking enabled,
see below).
Also keep track, using a circular queue, of the last 100 byte
opcodes seen, and when we hit an assert failure during byte-code
execution, output the contents of the queue in a nice readable
fashion. This requires that bytecode-ops.h be included a second
time so that a table mapping opcodes to the name of their operation
can be constructed. This table is constructed in new function
reinit_vars_of_bytecode().
Everything in the last two paras happens only when
ERROR_CHECK_BYTE_CODE.
Add some longish comments describing how the arrays that hold the
stack and instructions, and the pointers used to access them, work.
* gc.c:
Import some code from my `latest-fix' workspace to mark the
staticpro's in order from lowest to highest, rather than highest to
lowest, so it's easier to debug when something goes wrong.
* lisp.h (abort_with_message): Renamed from abort_with_msg().
* symbols.c (defsymbol_massage_name_1):
* symbols.c (defsymbol_nodump):
* symbols.c (defsymbol):
* symbols.c (defkeyword):
* symeval.h (DEFVAR_SYMVAL_FWD_OBJECT):
Make the various calls to staticpro() instead call staticpro_1(),
passing in the name of the C var being staticpro'ed, so that it
shows up in staticpro_names. Otherwise staticpro_names just has
1000+ copies of the word `location'.
author | Ben Wing <ben@xemacs.org> |
---|---|
date | Wed, 03 Feb 2010 08:01:55 -0600 |
parents | bc4f2511bbea |
children |
rev | line source |
---|---|
428 | 1 @c -*-texinfo-*- |
2 @c This is part of the XEmacs Lisp Reference Manual. | |
3 @c Copyright (C) 1998 Oliver Graf <ograf@fga.de> | |
444 | 4 @c Original reference is (c) 1990, 1991, 1992, 1993, 1994 Free Software Foundation, Inc. |
428 | 5 @c See the file lispref.texi for copying conditions. |
6 @setfilename ../../info/dragndrop.texi | |
7 @node Drag and Drop, Modes, Scrollbars, Top | |
8 @chapter Drag and Drop | |
9 @cindex drag and drop | |
10 | |
11 @emph{WARNING}: the Drag'n'Drop API is still under development and the | |
12 interface may change! The current implementation is considered experimental. | |
13 | |
14 Drag'n'drop is a way to transfer information between multiple applications. | |
4790
bc4f2511bbea
Remove support for the OffiX drag-and-drop protocol. See xemacs-patches
Jerry James <james@xemacs.org>
parents:
904
diff
changeset
|
15 To do this several GUIs define their own protocols. Examples are CDE, Motif, |
bc4f2511bbea
Remove support for the OffiX drag-and-drop protocol. See xemacs-patches
Jerry James <james@xemacs.org>
parents:
904
diff
changeset
|
16 KDE, MSWindows, GNOME, and many more. To catch all these protocols, XEmacs |
bc4f2511bbea
Remove support for the OffiX drag-and-drop protocol. See xemacs-patches
Jerry James <james@xemacs.org>
parents:
904
diff
changeset
|
17 provides a generic API. |
428 | 18 |
19 One prime idea behind the API is to use a data interface that is | |
20 transparent for all systems. The author thinks that this is best | |
21 archived by using URL and MIME data, cause any internet enabled system | |
22 must support these for email already. XEmacs also already provides | |
23 powerful interfaces to support these types of data (tm and w3). | |
24 | |
25 @menu | |
26 * Supported Protocols:: Which low-level protocols are supported. | |
27 * Drop Interface:: How XEmacs handles a drop from another application. | |
28 * Drag Interface:: Calls to initiate a drag from XEmacs. | |
29 @end menu | |
30 | |
31 @node Supported Protocols | |
32 @section Supported Protocols | |
33 | |
34 The current release of XEmacs only support a small set of Drag'n'drop | |
35 protocols. Some of these only support limited options available in the API. | |
36 | |
37 @menu | |
38 * CDE dt:: Common Desktop Environment used on suns. | |
39 * MSWindows OLE:: Mr. Gates way of live. | |
40 * Loose ends:: The other protocols. | |
41 @end menu | |
42 | |
43 @node CDE dt | |
44 @subsection CDE dt | |
45 @cindex CDE dt | |
46 | |
47 CDE stands for Common Desktop Environment. It is based on the Motif | |
48 widget library. It's drag'n'drop protocol is also an abstraction of the | |
49 Motif protocol (so it might be possible, that XEmacs will also support | |
50 the Motif protocol soon). | |
51 | |
52 CDE has three different types: file, buffer, and text. XEmacs only uses | |
53 file and buffer drags. The API will disallow full URL drags, only file | |
54 method URLs are passed through. | |
55 | |
56 Buffer drags are always converted to plain text. | |
57 | |
58 @node MSWindows OLE | |
59 @subsection MSWindows OLE | |
60 @cindex MSWindows OLE | |
61 | |
62 Only allows file drags and drops. | |
63 | |
64 @node Loose ends | |
65 @subsection Loose ends | |
66 | |
67 The following protocols will be supported soon: Xdnd, Motif, Xde (if I | |
4790
bc4f2511bbea
Remove support for the OffiX drag-and-drop protocol. See xemacs-patches
Jerry James <james@xemacs.org>
parents:
904
diff
changeset
|
68 get some specs). |
428 | 69 |
70 In particular Xdnd will be one of the protocols that can benefit from | |
71 the XEmacs API, cause it also uses MIME types to encode dragged data. | |
72 | |
73 @node Drop Interface | |
74 @section Drop Interface | |
75 @cindex drop | |
76 @cindex Drop API | |
77 | |
904 | 78 For each activated low-level protocol, an internal routine will catch |
428 | 79 incoming drops and convert them to a dragdrop-drop type |
80 misc-user-event. | |
81 | |
82 This misc-user-event has its function argument set to | |
83 @code{dragdrop-drop-dispatch} and the object contains the data of the drop | |
84 (converted to URL/MIME specific data). This function will search the variable | |
444 | 85 @code{experimental-dragdrop-drop-functions} for a function that can handle the |
428 | 86 dropped data. |
87 | |
88 To modify the drop behavior, the user can modify the variable | |
89 @code{experimental-dragdrop-drop-functions}. Each element of this list | |
90 specifies a possible handler for dropped data. The first one that can handle | |
91 the data will return @code{t} and exit. Another possibility is to set a | |
92 extent-property with the same name. Extents are checked prior to the | |
93 variable. | |
94 | |
95 The customization group @code{drag-n-drop} shows all variables of user | |
444 | 96 interest. |
428 | 97 |
98 @node Drag Interface | |
99 @section Drag Interface | |
100 @cindex drag | |
101 @cindex Drag API | |
102 | |
103 This describes the drag API (not implemented yet). |