[PATCH] 21.2-b1 redisplay-echo-area bug
27 years
Louis-Dominique Dubeau
Louis-Dominique Dubeau
Hello xemacsers,
I got 21.2-b1 a few days ago off the ftp.xemacs.org ftp site, built
it, ran it and crashed it. [Running it with -q and hitting C-g makes
it crash instantly.]
Looking at the stack dump I saw the problem was in
Fredisplay_echo_area. The effect is that whenever the echo area is
redisplayed, xemacs crashes. I made the debugger go step by step
through the code and realized that the value of "window" changes after
redisplay_window is called. I hypothesized that the problem was
garbage collection so I decided to protect "window". I rebuilt and
ran xemacs again: the error was gone.
Now I'm no xemacs expert and I have a very foggy idea of how garbage
collection in xemacs works. So I don't know if my fix is well
implemented or even if it is the right fix.
Given that I'm able to reproduce that bug very easily, I'm surprised
to find no mention of it in the archives of the mailing lists. I
might somehow be the only person that has encountered that bug so far.
I've worked with OSes, compilers and garbage collectors and seen my
share of bugs that appear only under certain conditions but then are
easily reproductible. Maybe this bug is one of those.
In any case, my tentative patch and other complementary information
follows.
Regards,
ldd
Here is the patch:
==========
--- redisplay.c 1998/09/04 13:39:04 1.1
+++ redisplay.c 1998/09/04 13:39:44
＠＠ -7862,6 +7862,8 ＠＠
if (FRAME_REPAINT_P (f) && FRAME_HAS_MINIBUF_P (f))
{
Lisp_Object window = FRAME_MINIBUF_WINDOW (f);
+ struct gcpro gcpro1;
+ GCPRO1(window);
/*
* If the frame size has changed, there may be random
* chud on the screen left from previous messages
＠＠ -7875,6 +7877,7 ＠＠
}
redisplay_window (window, 0);
call_redisplay_end_triggers (XWINDOW (window), 0);
+ UNGCPRO;
}
}
==========
xemacs-21.2-b1/ChangeLog:
==========
1998-09-08 Louis-Dominique Dubeau <ldd(a)step.polymtl.ca>
* src/redisplay.c: protected the "window" variable in
Fredisplay_echo_area.
==========
Lisp backtrace follows:
redisplay-echo-area()
# bind (inhibit-read-only zmacs-region-stays stdout-p frame message)
raw-append-message("Quit" #<x-frame "emacs" 0x8ef> nil)
# bind (stdout-p frame message label)
append-message(error "Quit" #<x-frame "emacs" 0x8ef> nil)
# bind (print-message-label)
display-error((quit) t)
# bind (inhibit-quit debug-on-error etype error-object)
command-error((quit))
# (catch top-level ...)
Stack dump follows:
#0 0x402349e9 in __kill ()
#1 0x80a9f2f in fatal_error_signal (sig=6) at emacs.c:262
#2 0xbfffead8 in ?? ()
#3 0x40270775 in gsignal ()
#4 0x8167256 in Fredisplay_echo_area () at window.h:245
#5 0x80b1492 in funcall_recording_as (recorded_as=-1473111988, nargs=0,
args=0xbfffed18) at eval.c:3197
#6 0x80b1705 in Ffuncall (nargs=1, args=0xbfffed18) at eval.c:3238
#7 0x808924e in Fbyte_code (bytestr=1747378028, vector=-2010718300,
maxdepth=5) at bytecode.c:416
#8 0x80b261f in funcall_lambda (fun=673636368, nargs=3, arg_vector=0xbfffeee0)
at eval.c:3597
#9 0x80b1619 in funcall_recording_as (recorded_as=-1472556644, nargs=3,
args=0xbfffeedc) at eval.c:3214
#10 0x80b1705 in Ffuncall (nargs=4, args=0xbfffeedc) at eval.c:3238
#11 0x808924e in Fbyte_code (bytestr=1747377880, vector=-2010718452,
maxdepth=4) at bytecode.c:416
#12 0x80b261f in funcall_lambda (fun=673636144, nargs=4, arg_vector=0xbffff000)
at eval.c:3597
#13 0x80b1619 in funcall_recording_as (recorded_as=-1473114692, nargs=4,
args=0xbfffeffc) at eval.c:3214
#14 0x80b2cd5 in call4 (fn=-1473114692, arg0=-1473220508, arg1=1747102828,
arg2=674664960, arg3=-1473220604) at eval.c:3973
#15 0x81446e8 in echo_area_append (f=0x8369200, nonreloc=0x0,
reloc=1747102828, offset=0, length=4, label=-1473220508) at minibuf.c:739
#16 0x814b0ca in output_string (function=674664960, nonreloc=0x0,
reloc=1747102828, offset=0, len=4) at print.c:237
#17 0x814c7bd in print_string (obj=1747102828, printcharfun=674664960,
escapeflag=0) at print.c:961
#18 0x814cdc4 in print_internal (obj=1747102828, printcharfun=674664960,
escapeflag=0) at print.c:1139
#19 0x814bd03 in print_error_message (error_object=1212708044,
stream=674664960) at print.c:646
#20 0x814c01f in Fdisplay_error (error_object=1212708044, stream=-1473220580)
at print.c:704
#21 0x80b14b4 in funcall_recording_as (recorded_as=-1473113988, nargs=2,
args=0xbffff514) at eval.c:3197
#22 0x80b1705 in Ffuncall (nargs=3, args=0xbffff514) at eval.c:3238
#23 0x808924e in Fbyte_code (bytestr=1747254716, vector=-2010841532,
maxdepth=5) at bytecode.c:416
#24 0x80b261f in funcall_lambda (fun=673513208, nargs=1, arg_vector=0xbffff630)
at eval.c:3597
#25 0x80b1619 in funcall_recording_as (recorded_as=-1473142980, nargs=1,
args=0xbffff62c) at eval.c:3214
#26 0x80b2bb4 in call1 (fn=-1473142980, arg0=1212708044) at eval.c:3921
#27 0x809038a in cmd_error (data=1212708044, dummy=-1473220604)
at cmdloop.c:195
#28 0x80ae5fe in condition_case_1 (handlers=-1473220508,
bfun=0x8090ef4 <command_loop_1>, barg=-1473220604,
hfun=0x809034c <cmd_error>, harg=-1473220604) at eval.c:1636
#29 0x809142c in command_loop_2 (dummy=-1473220604) at cmdloop.c:256
#30 0x80ae470 in internal_catch (tag=-1473142932,
func=0x80913f8 <command_loop_2>, arg=-1473220604, threw=0x0) at eval.c:1328
#31 0x80907f2 in initial_command_loop (load_me=-1473220604) at cmdloop.c:305
#32 0x80ab00e in xemacs_21_2_b1_i586_pc_linux (argc=2, argv=0xbffff7e4,
envp=0xbffff7f0, restart=0) at emacs.c:1702
#33 0x80ab6b0 in main (argc=2, argv=0xbffff7e4, envp=0xbffff7f0)
at emacs.c:2119
#34 0x8074c9b in _start ()
Output from describe-installation:
uname -a: Linux zen 2.0.30 #1 Tue Apr 22 10:49:45 EDT 1997 i586 unknown
./configure
XEmacs 21.2-b1 "Aeolus" configured for `i586-pc-linux'.
Where should the build process find the source code? /home/ldd/devel/xemacs-21.2-b1
What installation prefix should install use? /usr/local
What operating system and machine description files should XEmacs use?
`s/linux.h' and `m/intel386.h'
What compiler should XEmacs be built with? gcc -g -O3 -Wall -Wno-switch
Should XEmacs use the GNU version of malloc? yes
Should XEmacs use the relocating allocator for buffers? yes
What window system should XEmacs use? x11
Where do we find X Windows header files? /usr/X11/include
Where do we find X Windows libraries? /usr/X11/lib
Compiling in support for XAUTH.
Compiling in support for XPM images.
Compiling in support for X-Face message headers.
Compiling in support for JPEG image conversion.
Compiling in support for TIFF image conversion.
Compiling in native sound support.
Compiling in support for Berkeley DB.
Compiling in support for GNU DBM.
Compiling in support for ncurses.
Compiling in support for GPM (General Purpose Mouse).
Compiling in support for proper session-management.
Using Lucid menubars.
Using Lucid scrollbars.
Using Athena dialog boxes.
Compiling in DLL support.
movemail will use "dot-locking" for locking mail spool files.
Compiling in extra code for debugging.
Compiling in code for checking XEmacs memory usage.
WARNING: ---------------------------------------------------------
WARNING: Compiling in support for runtime error checking.
WARNING: XEmacs will run noticeably more slowly as a result.
WARNING: Error checking is on by default for XEmacs beta releases.
WARNING: ---------------------------------------------------------
- 2 participants
- 1 comments
ACCEPT CREDIT CARDS OVER THE INTERNET *** NO SETUP FEES
27 years
brk91＠usa.net
brk91＠usa.net
We received your Email address as someone who might be interested
in our services. If this is incorrect please send an Email to
brk91(a)usa.net and type REMOVE in the subject line.
___________________________________________________________________
INCREASE SALES UP TO 200%
ACCEPT CREDIT CARDS OVER THE INTERNET *** NO SETUP FEES
GIVE YOUR CUSTOMERS THE FASTEST ONLINE VERIFICATION SYSTEM!
LARGEST SERVICE WITH THE BEST RATES ON THE INTERNET!
REFERRAL PROGRAM - $50-$150 PER REFERRAL
EASIEST SITE CONNECTION with 24 Hour Customer Service!
Good Credit / Bad Credit/ No Credit **** NO PROBLEM****!!!
It Just Doesn't Matter - Everyone Gets Approved
No Upfront Fees For Application-Processing
While Others Charge You From $195 TO $250 To Get Set Up
WE CHARGE ZERO FOR SETUP FEES THROUGH AUGUST!!
Limited Offer So Take Advantage Of It Now!!
We Specialize In Servicing:
*Multilevel Marketing
*Mail Order/Phone Sales
*At Home Business
*INTERNET BASED BUSINESS
*New Business*Small Business
Whatever!!! We Do It All!!!
Everyone Is Welcome!
Scroll to bottom of this e-mail for CONTACT INFORMATION.
THIS IS THE ONLINE CREDIT CARD MERCHANT SERVICE TO GET NOW.
What Can We Do For Your Company????
Call 214-853-5153 Now to get started today!
>>>>>INTERNET SERVICE<<<<<
It's finally here!!!
The fastest and positively the most reliable way to process credit cards
through your web site or online business. The Internet's reach is global
- it knows no time zones or physical boundaries. With our user friendly,
easy to use program, you will convert your web site from an electronic
brochure to a virtual storefront without the addition of a sales clerk!!!!!
SECURE REAL-TIME ON-LINE TRANSACTIONS make it as easy as possible for your
customers to purchase your products or services.
We use SSL SECURITY, processing directly on our servers with a direct
verification line. SAFEST, ABSOLUTELY THE MOST SECURE, FASTEST SERVICE!
You will summon your customers impulse buying when you can safely process
credit cards through a secured web site linked directly to your web page.
The Internet is the fastest growing industry in today's direct marketing
business. DON'T BE LEFT BEHIND!!!
Give your customers the convenience of ordering products right from your
web page with no complicated re-programming connections.
Now tell me if this doesn't sound intriguing, lets say a customer visits
your web site and decides they want to buy your product(s) or service(s).
They would simply enter their credit card information and receive an
approval WITHIN 5 SECONDS. That's all there is to it!!!
>From that point on, the sale is complete and the money will be directly
deposited into your business checking account within 24 to 48 hours.
So you will have LIQUID ASSETS AVAILABLE ALMOST IMMEDIATELY!!!!
Your customer will be e-mailed a receipt and you will be e-mailed an
invoice slip INSTANTLY. Since this program is automated
for 24 hours a day 7 days a week, you will be receiving orders and making
money in your sleep!!!!!
IT'S JUST THAT EASY!!!!
>>>>>REFERRALS<<<<<
****ATTENTION MARKETING DIRECTORS****
Increase your marketability by giving your customers the opportunity to
accept credit cards as an added feature offered with your companies
products or services!!!!
Ideal opportunity for WEB HOSTS and WEB PAGE DESIGNERS!!!!!
***MLM's (Multi-Level Marketer's) Welcome.***
If you've ever attempted to acquire a merchant account, you know how
difficult this procedure can normally be. We can arrange for all of your
associates to be PRE-APPROVED FOR A CREDIT CARD MERCHANT ACCOUNT.
This opportunity not only benefits your clients but will also add another
selling feature for your company. Each client that establishes a merchant
account with us will result in a $50 to $150 REFERRAL FEE to your company.
***$10,000 per month in referral fees is not uncommon with large INTERNET
PROVIDERS***
If you have a Web Page, you can place one of our banners on the page and
receive referral fees for anyone who establishes a merchant account with
us from your web site.
If you're an opportunist, this is the MARKETING FEATURE YOU'VE BEEN WAITING
FOR.
WHAT MAKES US SO SPECIAL?????
* We process over $4 Billion in credit card transactions every year.
* We have over 100,000 merchants online and growing
- Experienced!
* We offer secured on-line real time transactions
-- Fastest authorization anywhere!
* We offer complete assistance and installation through our technical support group.
* We offer 24 hour customer service 7 days a week in 17 different languages.
-- Call us at 214-853-5153 Now to get started today! We can help!
* We offer a life time warranty and unlimited upgrades.
* We save time for you, your company and your customers.
* We help you increase sales quickly and keep your customers satisfied with
fast and accurate approved service!
* Without complicated re-programming connections!
Our proven method in partnerships has made our office the #1 office in the
country. So invest a little time and receive a lot of money!!!!
>>>>>ONLINE TERMINAL<<<<<
You can now take PHONE and MAIL ORDERS, accept credit cards and expose
your business to thousands of new customers. Online credit card
acceptance increases customer SALES FOUR TIMES! over companies without it.
All of this done through your own personal computer!!!!!
To accommodate your STOREFRONT RETAIL BUSINESS, we offer an ELECTRONIC
TERMINAL PACKAGE. A terminal will allow you to receive the LOWEST
DISCOUNT RATE per transaction available.
>>>>>SETUP FEE FREE THROUGH AUGUST, HIGH VOLUME COMMERCIAL RATES!<<<<<
High Volume means Business!
Through our nationwide credit card company assigned merchant accounts
are obtained without any APPLICATION FEES, NO SETUP FEES and
absolutely the BEST RATES!!!!!!
Accept credit card payments today and greatly enhance your business,
add additional credibility in the marketplace, and increase your
potential for immediate sales. So, if you're serious about increasing
your business potential, get your own Merchant Account today!!!
>>>>>CONTACT INFORMATION<<<<<---------->>>>>CONTACT INFORMATION<<<<<
Call 214-853-5153 Now to get started today!
A personal account executive will start you on your way to financial success.
We offer Outstanding service to our customers!
Finally, the easiest connection methods available at high volume rates.
SO, STOP WAITING!!! ACT NOW TO GET SETUP FOR FREE!!!!
Call 214-853-5153 Now to get started today!
If you are interested in our REFERRAL PROGRAM you can send an Email to
EMAILADDRESSHERE with the following information:
*Subject Line: Referral Program
*Your Name, Company Name
*Phone #, Fax #, and time you are available.
*Brief description of your business and/or your web page.
or
Call 214-853-5153 Now to get started today!
- 1 participants
- 0 comments
Re: [RFC] the behavior of search_command
27 years
Hrvoje Niksic
Hrvoje Niksic
Didier Verna <verna(a)inf.enst.fr> writes:
> There are two ways to achieve this: we can modify search_command (I
> have a patch ready for this), or we can modify each concerned lisp
> function. The point is that I don't know if there are
> non-interactive cases that could be fucked up with this new
> feature. If not, we'd better patch search_command directly. If yes,
> then it's preferable to modify the lisp functions, and check if
> we're calling them interactively. Or maybe not, if we use (downcase
> ...) to ensure we'll match everything ...
Although your suggestion makes sense as a user-interface improvement,
I'm certain that much code depends on case-fold-search doing what it
says it does, no matter what the search string is. For example:
(let ((case-fold-search nil))
(re-search-for "^Content-Length:")
..)
All of these would be broken by your proposed change. Checking
whether the function is called interactively would be likely to fail
when a higher-level function non-interactively calls a lower-level
function to search for a user-specified string.
The only good solution I see is to explicitly request this behaviour
in higher-level Lisp code. Note that the `with-caps-disable-folding'
macro exists for this very purpose.
--
Hrvoje, typing this in Paris.
- 1 participants
- 0 comments
Re: MIME attachments on NT in VM
27 years
Hrvoje Niksic
Hrvoje Niksic
wmperry(a)aventail.com (William M. Perry) writes:
> SL Baur <steve(a)tux.org> writes:
>
> > Darryl Okahata <darrylo(a)sr.hp.com> writes in xemacs-beta(a)xemacs.org:
> >
> > > Whatever happened to Kirill's database/registry patches? Way back,
> > > on Jan 10, he posted some patches that allowed access to the registry
> > > (they were in a file called "src/database-msw.c")? They never made it
> > > into the source tree.
> >
> > I don't recall. I vaguely recall objections that the patches weren't
> > general enough.
>
> I don't think I ever saw these. How exactly did they work? Would you
> just do (open-database nil 'mswindows 'registry "rw")?
Sort of like that, although I don't think I really like that
generalization. Note that the objector was Kirill himself, if I
remember correctly.
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
there's a beast upon my shoulder / and a fiend upon my back
- 1 participants
- 0 comments
21.2 (Aeolus) core dump
27 years
Samuel Tardieu
Samuel Tardieu
--Multipart_Wed_Sep_16_12:15:26_1998-1
Content-Type: text/plain; charset=US-ASCII
I've add a core dump while reading the xemacs-beta mails lately. Here
is the relevant information, hope that helps.
Sam
--
Samuel Tardieu -- sam(a)inf.enst.fr
--Multipart_Wed_Sep_16_12:15:26_1998-1
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: attachment; filename="BT"
Content-Transfer-Encoding: 7bit
#4 0x80a6f2e in assert_failed (file=0x81a1f90 "mule-charset.c", line=1112,
expr=0x81a2511 "!UNBOUNDP (str)") at emacs.c:2605
#5 0x80c3501 in composite_char_string (ch=524287) at mule-charset.c:1112
#6 0x80cc774 in encode_coding_iso2022 (encoding=0x8dbf608,
src=0x90244fd "\237\200ÿÿ\237\200ÿÿ\237\200½ÿ\237\200ÿÿ\237\200ÿÿ\237\200ïÿ\237\200ÿÿ\237\200ÿÿ\237\200÷ÿ\237\200ÿÿ\237\200ÿÿ\237\200ÿÿ\237\200ÿÿ\237\200ÿÿ\237\200ûÿ\237\200ø¿\237\200ÿÿ\237\200ÿÿ\201Ð\037\237\200ÿÿ\237\200ßÿ\201Ð\237\200ÿÿ\237\200ÿÿ", dst=0x9029148, n=485) at file-coding.c:4315
#7 0x80c85a9 in mule_encode (encoding=0x8dbf608,
src=0x90244f0 "P4\n48 48\n\237\200ÿÿ\237\200ÿÿ\237\200ÿÿ\237\200½ÿ\237\200ÿÿ\237\200ÿÿ\237\200ïÿ\237\200ÿÿ\237\200ÿÿ\237\200÷ÿ\237\200ÿÿ\237\200ÿÿ\237\200ÿÿ\237\200ÿÿ\237\200ÿÿ\237\200ûÿ\237\200ø¿\237\200ÿÿ\237\200ÿÿ\201Ð\037\237\200ÿÿ\237\200ßÿ\201Ð\237\200ÿÿ\237\200ÿÿ", dst=0x9029148, n=498)
at file-coding.c:2439
#8 0x80ceaba in encoding_writer (stream=0x8dbf608,
data=0x90244f0 "P4\n48 48\n\237\200ÿÿ\237\200ÿÿ\237\200ÿÿ\237\200½ÿ\237\200ÿÿ\237\200ÿÿ\237\200ïÿ\237\200ÿÿ\237\200ÿÿ\237\200÷ÿ\237\200ÿÿ\237\200ÿÿ\237\200ÿÿ\237\200ÿÿ\237\200ÿÿ\237\200ûÿ\237\200ø¿\237\200ÿÿ\237\200ÿÿ\201Ð\037\237\200ÿÿ\237\200ßÿ\201Ð\237\200ÿÿ\237\200ÿÿ", size=498) at file-coding.c:2276
#9 0x8121c1b in Lstream_flush_out (lstr=0x8dbf608) at lstream.c:343
#10 0x81222c6 in Lstream_close (lstr=0x8dbf608) at lstream.c:655
#11 0x80f4d40 in Fwrite_region_internal (start=3, end=417, filename=149886748,
append=137157364, visit=137816440, lockname=149886748, codesys=138008560)
at fileio.c:3321
#12 0x80abbce in funcall_recording_as (recorded_as=137248968, nargs=7,
args=0xbfffc9f4) at eval.c:3197
#13 0x80abd93 in Ffuncall (nargs=8, args=0xbfffc9f4) at eval.c:3238
#14 0x8087b76 in Fbyte_code (bytestr=136736932, vector=136737204, maxdepth=21)
at bytecode.c:416
#15 0x80ac850 in funcall_lambda (fun=136737548, nargs=5, arg_vector=0xbfffce04)
at eval.c:3597
#16 0x80abc9e in funcall_recording_as (recorded_as=137248408, nargs=5,
args=0xbfffce00) at eval.c:3214
#17 0x80abd93 in Ffuncall (nargs=6, args=0xbfffce00) at eval.c:3238
#18 0x8087b76 in Fbyte_code (bytestr=136738236, vector=136738508, maxdepth=15)
at bytecode.c:416
#19 0x80ac850 in funcall_lambda (fun=136739056, nargs=6, arg_vector=0xbfffcff8)
at eval.c:3597
#20 0x80abc9e in funcall_recording_as (recorded_as=137816300, nargs=6,
args=0xbfffcff4) at eval.c:3214
#21 0x80ac20d in Fapply (nargs=8, args=0xbfffcff4) at eval.c:3408
#22 0x80ab8f5 in funcall_recording_as (recorded_as=137241540, nargs=8,
args=0xbfffcff0) at eval.c:3178
#23 0x80abd93 in Ffuncall (nargs=9, args=0xbfffcff0) at eval.c:3238
#24 0x8087b76 in Fbyte_code (bytestr=139477620, vector=141054544, maxdepth=19)
at bytecode.c:416
#25 0x80ac850 in funcall_lambda (fun=141359832, nargs=1, arg_vector=0xbfffd2f4)
at eval.c:3597
#26 0x80abc9e in funcall_recording_as (recorded_as=141008604, nargs=1,
args=0xbfffd2f0) at eval.c:3214
#27 0x80abd93 in Ffuncall (nargs=2, args=0xbfffd2f0) at eval.c:3238
#28 0x8087b76 in Fbyte_code (bytestr=139490612, vector=141357080, maxdepth=15)
at bytecode.c:416
#29 0x80ac850 in funcall_lambda (fun=141359860, nargs=2, arg_vector=0xbfffd704)
at eval.c:3597
#30 0x80abc9e in funcall_recording_as (recorded_as=141405988, nargs=2,
args=0xbfffd700) at eval.c:3214
#31 0x80abd93 in Ffuncall (nargs=3, args=0xbfffd700) at eval.c:3238
#32 0x8087b76 in Fbyte_code (bytestr=141413692, vector=143994160, maxdepth=17)
at bytecode.c:416
#33 0x80ac850 in funcall_lambda (fun=143852032, nargs=0, arg_vector=0xbfffd850)
at eval.c:3597
#34 0x80abc9e in funcall_recording_as (recorded_as=143992016, nargs=0,
args=0xbfffd84c) at eval.c:3214
#35 0x80ac20d in Fapply (nargs=2, args=0xbfffd84c) at eval.c:3408
#36 0x80ab110 in Feval (form=143586680) at eval.c:3023
#37 0x80a803d in Fprogn (args=143586668) at eval.c:758
#38 0x80a7eef in Fif (args=143586452) at eval.c:699
#39 0x80ab025 in Feval (form=143586296) at eval.c:2997
#40 0x80a803d in Fprogn (args=143586260) at eval.c:758
#41 0x809fae8 in Fsave_excursion (args=143586260) at editfns.c:403
#42 0x80ab025 in Feval (form=143586176) at eval.c:2997
#43 0x80ac7dd in funcall_lambda (fun=143585960, nargs=0, arg_vector=0xbfffddfc)
at eval.c:758
#44 0x80abc9e in funcall_recording_as (recorded_as=141136924, nargs=0,
args=0xbfffddf8) at eval.c:3214
#45 0x80acb13 in run_hook_with_args_in_buffer (buf=0x8bfbe90, nargs=1,
args=0xbfffddf8, cond=RUN_HOOKS_TO_COMPLETION) at eval.c:3757
#46 0x80acb6a in run_hook_with_args (nargs=1, args=0xbfffddf8,
cond=RUN_HOOKS_TO_COMPLETION) at eval.c:3770
#47 0x80ac88e in Frun_hooks (nargs=1, args=0xbfffddf8) at eval.c:3625
#48 0x80ab8f5 in funcall_recording_as (recorded_as=137240912, nargs=1,
args=0xbfffddf4) at eval.c:3178
#49 0x80ac20d in Fapply (nargs=2, args=0xbfffddf4) at eval.c:3408
#50 0x80ab8f5 in funcall_recording_as (recorded_as=137241540, nargs=2,
args=0xbfffddf0) at eval.c:3178
#51 0x80abd93 in Ffuncall (nargs=3, args=0xbfffddf0) at eval.c:3238
#52 0x8087b76 in Fbyte_code (bytestr=139960908, vector=141077200, maxdepth=7)
at bytecode.c:416
#53 0x80ac850 in funcall_lambda (fun=141075144, nargs=1, arg_vector=0xbfffdf6c)
at eval.c:3597
#54 0x80abc9e in funcall_recording_as (recorded_as=141168476, nargs=1,
args=0xbfffdf68) at eval.c:3214
#55 0x80abd93 in Ffuncall (nargs=2, args=0xbfffdf68) at eval.c:3238
#56 0x8087b76 in Fbyte_code (bytestr=142923780, vector=143921920, maxdepth=5)
at bytecode.c:416
#57 0x80ac850 in funcall_lambda (fun=143551952, nargs=0, arg_vector=0xbfffe778)
at eval.c:3597
#58 0x80abc9e in funcall_recording_as (recorded_as=143837944, nargs=0,
args=0xbfffe774) at eval.c:3214
#59 0x80abd93 in Ffuncall (nargs=1, args=0xbfffe774) at eval.c:3238
#60 0x8087b76 in Fbyte_code (bytestr=142919644, vector=143921576, maxdepth=9)
at bytecode.c:416
#61 0x80ac850 in funcall_lambda (fun=143551924, nargs=2, arg_vector=0xbfffe998)
at eval.c:3597
#62 0x80abc9e in funcall_recording_as (recorded_as=141230804, nargs=2,
args=0xbfffe994) at eval.c:3214
#63 0x80abd93 in Ffuncall (nargs=3, args=0xbfffe994) at eval.c:3238
#64 0x8087b76 in Fbyte_code (bytestr=140015540, vector=143729976, maxdepth=9)
at bytecode.c:416
#65 0x80ac850 in funcall_lambda (fun=143725920, nargs=1, arg_vector=0xbfffeef4)
at eval.c:3597
#66 0x80abc9e in funcall_recording_as (recorded_as=143699692, nargs=1,
args=0xbfffeef0) at eval.c:3214
#67 0x80abd93 in Ffuncall (nargs=2, args=0xbfffeef0) at eval.c:3238
#68 0x8087b76 in Fbyte_code (bytestr=140329044, vector=143730232, maxdepth=15)
at bytecode.c:416
#69 0x80ac850 in funcall_lambda (fun=143726004, nargs=2, arg_vector=0xbffff160)
at eval.c:3597
#70 0x80abc9e in funcall_recording_as (recorded_as=143506956, nargs=2,
args=0xbffff15c) at eval.c:3214
#71 0x80abd93 in Ffuncall (nargs=3, args=0xbffff15c) at eval.c:3238
#72 0x8087b76 in Fbyte_code (bytestr=140926412, vector=143738488, maxdepth=15)
at bytecode.c:416
#73 0x80ac850 in funcall_lambda (fun=143726060, nargs=0, arg_vector=0xbffff290)
at eval.c:3597
#74 0x80abc9e in funcall_recording_as (recorded_as=143726060, nargs=0,
args=0xbffff28c) at eval.c:3214
#75 0x80acd0f in apply1 (fn=143726060, arg=137157364) at eval.c:3238
#76 0x80892cf in Fcall_interactively (function=141008408,
record_flag=137157364, keys=137157364) at callint.c:397
#77 0x80aa583 in Fcommand_execute (cmd=141008408, record=137157364,
keys=137157364) at eval.c:2584
#78 0x80deea2 in execute_command_event (command_builder=0x8428ec8,
#79 0x80df5f0 in Fdispatch_event (event=146939756) at event-stream.c:4685
#80 0x8090752 in Fcommand_loop_1 () at cmdloop.c:579
#81 0x80905d6 in command_loop_1 (dummy=137157364) at cmdloop.c:494
#82 0x80a8e8b in condition_case_1 (handlers=137157476,
bfun=0x80905c0 <command_loop_1>, barg=137157364,
hfun=0x80901b0 <cmd_error>, harg=137157364) at eval.c:1653
#83 0x809095c in command_loop_2 (dummy=137157364) at cmdloop.c:256
#84 0x80a8c79 in internal_catch (tag=137232044,
func=0x8090920 <command_loop_2>, arg=137157364, threw=0x0) at eval.c:1328
#85 0x80903fa in initial_command_loop (load_me=137157364) at cmdloop.c:305
#86 0x80a5ffb in xemacs_21_2_b1_i586_pc_linux (argc=1, argv=0xbffff698,
envp=0xbffff6a0, restart=0) at emacs.c:1702
#87 0x80a6721 in main (argc=1, argv=0xbffff698, envp=0xbffff6a0)
at emacs.c:2119
(gdb) fr 6
#6 0x80cc774 in encode_coding_iso2022 (encoding=0x8dbf608,
src=0x90244fd "\237\200ÿÿ\237\200ÿÿ\237\200½ÿ\237\200ÿÿ\237\200ÿÿ\237\200ïÿ\237\200ÿÿ\237\200ÿÿ\237\200÷ÿ\237\200ÿÿ\237\200ÿÿ\237\200ÿÿ\237\200ÿÿ\237\200ÿÿ\237\200ûÿ\237\200ø¿\237\200ÿÿ\237\200ÿÿ\201Ð\037\237\200ÿÿ\237\200ßÿ\201Ð\237\200ÿÿ\237\200ÿÿ", dst=0x9029148, n=485) at file-coding.c:4315
4315 Lisp_Object lstr = composite_char_string (emch);
(gdb) info local
emch = 0
lstr = 0
encoding = (Lstream *) 0x0
dst = (unsigned_char_dynarr *) 0x6
charmask = 25 '\031'
c = 255 'ÿ'
flags = 0
ch = 255
eol_type = EOL_AUTODETECT
char_boundary = 1 '\001'
str = (struct encoding_stream *) 0x8dbf650
codesys = (struct Lisp_Coding_System *) 0x839d7f0
i = 22553
charset = 137343944
half = 0
saved_n = 0
saved_src = (unsigned char *) 0x0
in_composite = 0
(gdb) p *str
$1 = {codesys = 0x839d7f0, other_end = 0x8c75570, runoff = 0x9029148,
flags = 0, ch = 0, iso2022 = {charset = {137340248, 137340392, 137157364,
137157364}, register_left = 0, register_right = 1,
force_charset_on_output = "\000\000\000", current_charset = 137157364,
current_half = 0, current_char_boundary = 1}, ccl = {size = 0, prog = 0x0,
ic = 0, eof_ic = 0, reg = {0, 0, 0, 0, 0, 0, 0, 0}, last_block = 0,
status = 0, buf_magnification = 0}}
(gdb) p *codesys
$2 = {header = {lheader = {implementation = 0x81a2abc}, next = 0x839d790,
uid = 5677, free = 0}, name = 138122100, doc_string = 137705924,
type = CODESYS_ISO2022, mnemonic = 137705716,
post_read_conversion = 137157364, pre_write_conversion = 137157364,
eol_type = EOL_AUTODETECT, eol_lf = 138008656, eol_crlf = 138008752,
eol_cr = 138008848, iso2022 = {initial_charset = {137340248, 137340392,
137157364, 137157364}, force_charset_on_output = "\000\000\000",
input_conv = 0x0, output_conv = 0x0, shoort = 1, no_ascii_eol = 0,
no_ascii_cntl = 0, seven = 0, lock_shift = 0, no_iso6429 = 0,
escape_quoted = 0}, ccl = {decode = 0, encode = 0}}
--Multipart_Wed_Sep_16_12:15:26_1998-1--
- 1 participants
- 0 comments
Re: Ispell.el bug [was Re: Announcing Kspell version .10 alpha]
27 years
Jan Vroonhof
Jan Vroonhof
[Note xemacs-patches(a)xemacs.org is for patches only. Discussions
should only go to xemacs-beta. Unfortunately there exists no mail
equivalent of Follow-Up-To:]
Ken Stevens <kstevens(a)ichips.intel.com> writes:
> This fix looks like the best solution to me, as calling append as the
> function is being built is a real dog. Thanks!
Would you mind sending any new version you release with this to
steve(a)xemacs.org (or xemacs-patches(a)xemacs.org to lighten the load on
steve). That would reduce any version skew between XEmacs and you.
Ideal would be of course if you become the maintainer of the ispell
XEmacs package. As a bonus you would get CVS for free :-) (contact
jens(a)mastaler.com for that)
> > * ispell.el: changed *-latin-* symbols to *-8859-* so that ispell
> > can find the related coding systems.
>
> Does this work right with emacsen other than XEmacs? If so I'll stick that
> in as it is.
I am not a MULE expert (can one please comment) AFAIK the *-8859-*
names are preferred on FSF 20.3 too.
Thanks for the quick response.
Jan
- 2 participants
- 1 comments
Re: Need internal help please (dynamic loading support)
27 years
Marat Boshernitsan
Marat Boshernitsan
"J. Kean Johnston" <jkj(a)sco.com> writes:
> Would it be constructive for me to post thwt I have done so far?
Yes, please do.
We are looking into integrating our research system with XEmacs via the
dynamic loading interface and I would very much like to see what's there
and what's missing.
(Our system is an embeddable library for program analysis. The system
is designed to be dynamically loadable into the host language runtime,
which can then access various program analysis functions. We already
have language bindings for Tcl and Java, and would like to add XEmacs
elisp, as this will provide us with a pretty nice editor).
I was planning to do some work on the module interface myself, so
perhaps we should coordinate so as not to duplicate our efforts...
Marat.
- 1 participants
- 0 comments
Re: Need internal help please (dynamic loading support)
27 years
William M. Perry
William M. Perry
"J. Kean Johnston" <jkj(a)sco.com> writes:
> On Thu, Sep 10, 1998 at 06:50:26PM -0500, William M. Perry wrote:
> > Do all platforms have the idea of an 'initialization' function for dynamic
> > libraries? I know most elf systems do with _init and _fini, and windows
> > has DllMain. It would be nice to just hook into that for doing the
> > DEFSUBR() and things instead of having the somewhat arbitrary
> > emacs_initializate function name.
>
> Unfortunately not all do, and DLD certainly doesn't.
I thought DLD did... huh. Not that any of the DLD code has actually been
tested. I can't think of a single platform where we would need that. Even
SunOS 4.x has dlopen(). :)
I just put that code in there out of completeness / anality. In
compiling on 13 unix platforms, I never once had to use DLD.
> > I must have sanitized my comments about SCO in the source :). I really
> > dislike the fact that _dlopen is the symbol in libc, and dlfcn.h #defines
> > dlopen _dlopen. Really makes doing the autoconf stuff a little ickier.
> > :)
>
> No you didnt santise it the comments are there, and valid :-) I myself
> hated this and made the patch to put in a #pragma weak dlopen _dlopen so
> that autoconf would find the functions. Although, to be fair, the
> original assertion that was made that you really sohuldnt be messing with
> dlopen() stuff wiothout having dlfcn.h included was valid.
Well, pfff on them.
> > All the stuff in sysdll works under SCO OpenServer 5.x, other than the
> > exporting all symbols stuff. We could get around that by putting some of
> > the core functionality of XEmacs in a libxemacs.so or something like that.
> > I don't know if that's worth it or not though.
>
> No true ... on OSR 5.0.4 I can export all the symbols trivially by
> putting -Wl,-Bexport on the link line. It works just as it does on any
> SVR4 system.
Cool - didn't find that little tidbit when we supported SCO a year or so
ago. I had to hack up Perl to build libperl.so correctly or none of the
dynamic loading stuff worked (with gcc).
> > I know the sysdll stuff works under:
> Yeah sysdll.c is quite fine exactly as it stands ... it abstracts dlopen()
> and friends. How that abstraction is USED is what needs work.
>
> Would it be constructive for me to post thwt I have done so far?
Probably. We can try to synthesize it. One of the things I'd like the
module code to do is make it possible to make XEmacs even more modular. It
would be cool to have the terminal redisplay stuff be loadable. That's
quite a ways down the road though. Would be nice to have an XEmacs that
didn't load up all the X crap in the world if it didn't need it. Not sure
how that'd play though. :)
-Bill P.
- 1 participants
- 0 comments
Re: [Various] [bug] XEmacs and gpm: SIGTSTP resignalling loop?
27 years
William M. Perry
William M. Perry
karlheg(a)inetarena.com (Karl M. Hegbloom) writes:
> >>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes:
>
> Jan> I find the current way gpm is implemented (114 lines of C code,
> Jan> including comments and whitespace) in XEmacs very clean. It does
> Jan> not involve running another subprocess from lisp nor does it
> Jan> involve manufacturing events from lisp code. The latter is only
> Jan> possible as of 21.0 anyway and is very tricky to get right.
>
> I wonder if doing it with a subprocess would work better though...
The GPM support is not complete, and should really be a little lower in
the device/console stuff. I didn't really understand the distinction when
I wrote that stuff. I was supposed to call ben about it ages ago, but the
last year has seen my hacking time go to nil.
Before the GPM support becomes really cool, we would need to implement
popup menus and menubars on a TTY. Controllable by a real mouse would be
really spiffy. Hint hint for the projects page.
Definitely fairly low priority though. We might want to turn GPM off by
default if it is causing crashes though.
-Bill P.
- 1 participants
- 0 comments
Re: Problems with creating frame on remote display
27 years
Colin Rafferty
Colin Rafferty
David Bush writes:
> 1. The frame on the PC is way to big and the fonts are oversized.
> Is there anyway to get Xemacs to adjust to different screen
> resolutions on different displays?
This is a modification of some code that I use. The basic idea is
that you can set frame-local properties of faces.
(defvar make-frame-small-font "-*-courier-medium-r-*-*-8-*-*-*-*-*-*-*"
"Font of a small frame.")
(defun make-frame-on-small-display (display &optional props)
"Create a new small frame on a display."
(interactive "sMake small frame on display: ")
(make-frame-on-display
display
(append props
(list [default font] make-frame-small-font
[bold font] make-frame-small-font
[bold font] make-frame-small-font
[bold-italic font] make-small-large-font
[modeline font] make-frame-small-font))))
Now, instead of calling gnuclient, use the following call from your
shell:
gnudoit '(make-frame-on-small-display "'$DISPLAY'")'
Note that this will only work if you let all your faces inherit from
the defaults. Otherwise, you will need to expand that list to include
all your faces.
> 2. I haven't been able to get the meta key to work on the PC. On
> the Sun I still have it defaulted to the "diamond" key. My
> efforts to remap using xmodmap have been fruitless thus far.
> As anyone solved this? I have this problem even if run
> gnuclient -nw and work in tty mode.
I have the same problem. I have a Window 95 box on my desk next to my
Sun box. When I `make-frame-on-display' to get an extra workspace,
typing Alt-x (or Alt-anything) does nothing. I assume that Windows is
trapping it for me.
I imagine that could be some Windows setting to change, but I don't
know what it is.
Although I am sure you know that `ESC x' does `M-x', I have a better
hint. The `C-[' key generates an ESC. The ESC key is too far away,
so I use `C-[ x' on the PC.
> 3. If my ISP has a glitch and drops my connection, the X error
> causes the entire Xemacs on the Sun to die. Is there any way
> to prevent this from happening?
Yes, work with Didier and Steve to make the setjmp/longjmp stuff work
correctly.
Unfortunately, this is a known deficiency. I have been hit by it far
too many times to count.
I hope that some of this has helped.
--
Colin
- 1 participants
- 0 comments