November 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Any objections against xemacs/*/xemacs.mak files in 21.2? 25 years

William M. Perry

Andy Piper <andy(a)xemacs.org> writes: > At 08:46 PM 11/18/99 -0700, Ben Wing wrote: > >I say, put all the nt makefiles in the proper directories, not in nt. > >Windows is not a second-class citizen w.r.t. xemacs. > > I agree, but this is not strictly true - the windows build uses its own > private versions of some header files and source files, noteably > config.h, so it is defintely not the same as all other builds. Most of the stuff in nt/inc is empty, and only needed because certain parts of the code unconditionally include things like netdb.h instead of wrapping them in #ifdef HAVE_NETDB_H, and doing the appropriate autoconf checks. sys/param.h can be removed and the definition of NBPG put in nt/config.h sys/ioctl.h, netinet/in.h, arpa/inet.h, netdb.h, unistd.h can be completely nuked sys/time.h is probably doing the wrong thing. We should just include the correct file under windows instead of creating our own prototypes for struct timeval, etc. sys/socket.h should just be nuked and all the checks for net-specific errnos should be wrapped in a new macro. In some of our code we use ISSOCKETERROR(var,ENOTCONN), on windows this expands the WSA stuff for you. -Bill P.

2 participants
1 comments

Any objections against xemacs/*/xemacs.mak files in 21.2? 25 years

Adrian Aichner

Hello Reviewers, while trying to improve makefile[1] support for Windows NT native I am faced with this problem: ALL make rules for building XEmacs Windows NT native[2] are in nt\xemacs.mak. However, ＠setfilename in man\*\*.texi are obviously relative to man\*, not nt. Having nt\xemacs.mak to call out to man\xemacs.mak to handle the info target (just like on Unix) would be must superior. There is no danger in clashing with Unix makefiles since they are always called Makefile. I would be willing to send in patches for 21.2 to make xemacs.mak build recursively if any objections/problems can be resolved. Any objections? Regards, Adrian Footnotes: [1] triggered by Martin's > From: Martin Buchholz <martin(a)xemacs.org> > Subject: Martin makes man & Makefile makeover > Message-ID: <14384.56980.560513.767776(a)lasker.666.com> [2] Building in lisp, src, man, lib-src

5 participants
5 comments

Re: [what to do?] Windows FILETIME breakage between NT and 9[58] 25 years

Jan Vroonhof

Adrian Aichner <aichner(a)ecf.teradyne.com> writes: > this article discusses FILETIME handling on NT and 9[58] and puts up > the question how to best cope with it in XEmacs (native and mingw32). Unfortunately I cannot remember the origional discussion. However reading between the lines it seems that when going over the DST changeover barrier the Apparent UTC time of a FAT file changes. And thus XEmacs view of the times becomes confused. (Question: Do other windows programs use a differnt API that doesn't go through UTC, and thus do not notice it?) If it is indeed the case that 1. It can be done sanely for sane file systems (i.e. NTFS) 2. Doing it this way goes wrong for FAT only when going over DST barrier. 3. Microsoft Exporer gets it "wrong" too. then my vote would be to not do any file system type checks (can you do those over the network?). Just direct any complainers to Redmond with tar and feathers. Jan

2 participants
1 comments

21.2.20 crash 25 years

Nick V. Pakoulin

This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.2 (beta20) "Yoko" [Lucid] (i686-pc-linux) of Tue Nov 16 1999 on pegas.kazbek.ispras.ru configured using `configure --with-pop --error-checking=none' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: I worked with Gnus, read articles. Before the crash I opened my mail group named "misc" and saw the summary buffer. In the buffers-tab there were 3 buffers - Summary, mail<2> and one more. I tried to switch to mail<2>, Xemacs hung and then crashed. -------------------------------------------------------------------------------- Lisp backtrace follows: # (condition-case ... . error) # (catch top-level ...) [2]- Segmentation fault (core dumped) xemacs-21.2-b20 -l gnus-mime -f gnus -------------------------------------------------------------------------------- #0 0x402ce111 in __kill () from /lib/libc.so.6 #1 0x8078d31 in fatal_error_signal (sig=11) at emacs.c:276 #2 0xbffff0d4 in ?? () #3 0x8158866 in XawTabsSetHighlight (t=0x889b260, w=0x8aa4378) at xlwtabs.c:1283 #4 0x8157ff4 in XawTabsSetTop (w=0x8aa4378, callCallbacks=1) at xlwtabs.c:1262 #5 0x8158c24 in TabsSelect (w=0x889b260, event=0xbffff744, params=0x0, num_params=0x4014b294) at xlwtabs.c:1047 #6 0x4013ce8d in HandleActions () from /usr/X11R6/lib/libXt.so.6 #7 0x4013d342 in HandleSimpleState () from /usr/X11R6/lib/libXt.so.6 #8 0x4013d851 in _XtTranslateEvent () from /usr/X11R6/lib/libXt.so.6 #9 0x4011a9f7 in XtDispatchEventToWidget () from /usr/X11R6/lib/libXt.so.6 #10 0x4011b5ad in _XtDefaultDispatcher () from /usr/X11R6/lib/libXt.so.6 #11 0x4011b873 in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.6 #12 0x40126b8f in XtAppProcessEvent () from /usr/X11R6/lib/libXt.so.6 #13 0x812c196 in emacs_Xt_next_event (emacs_event=0x886e130) at event-Xt.c:2427 #14 0x809a955 in event_stream_next_event (event=0x886e130) at event-stream.c:565 #15 0x809ba7c in next_event_internal (target_event=143057200, allow_queued=1) at event-stream.c:2020 #16 0x809bf96 in Fnext_event (event=143057200, prompt=136070036) at event-stream.c:2237 #17 0x80631bd in Fcommand_loop_1 () at cmdloop.c:566 #18 0x80633de in command_loop_1 (dummy=136070036) at cmdloop.c:490 #19 0x807fe8b in condition_case_1 (handlers=136070132, bfun=0x80633c8 <command_loop_1>, barg=136070036, hfun=0x8062cd0 <cmd_error>, harg=136070036) at eval.c:1630 #20 0x80634bc in command_loop_2 (dummy=136070036) at cmdloop.c:252 #21 0x807fd6f in internal_catch (tag=136143988, func=0x8063484 <command_loop_2>, arg=136070036, threw=0x0) at eval.c:1305 #22 0x8062f0c in initial_command_loop (load_me=136070036) at cmdloop.c:301 #23 0x8077752 in xemacs_21_2_b20_i686_pc_linux (argc=5, argv=0xbffffc44, envp=0xbffffc5c, restart=0) at emacs.c:1873 #24 0x8078f0f in main (argc=5, argv=0xbffffc44, envp=0xbffffc5c) at emacs.c:2298 #25 0x402c7cb3 in __libc_start_main (main=0x8078e10 <main>, argc=5, argv=0xbffffc44, init=0x804dad4 <_init>, fini=0x815ae14 <_fini>, rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffffc3c) at ../sysdeps/generic/libc-start.c:78 Recent keystrokes: i a b i p 1 5 a RET button2 button2up 3 RET misc-user misc-user misc-user Recent messages (most recent first): Parsing /home/npakoulin/.mailrc... Loading emacsbug...done Loading emacsbug... Generating summary...done Generating summary... Sorting articles...done Sorting articles... Scoring...done Scoring... Loading gnus-score...done

2 participants
1 comments

Re: [what to do?] Windows FILETIME breakage between NT and 9[58] 25 years

Fabrice Popineau

* Adrian Aichner <aichner(a)ecf.teradyne.com> writes: > which is appealing at first glance. > However, hDevice can only be opened directly with CreateFile on NT. > 95 is incompatible and requires dealing with VxDs. > Am I on the right track? > What would be the simplest working way to tell apart NTFS and FAT > files on the Windows NT, 95, 98 kindred? Sorry, I have not much time to investigate the problem you are talking about, but there are chances you can distinguish between FAT and NTFS using GetVolumeInformation() ... There are a bunch of flags returned there that FAT can't handle. Fabrice

1 participants
0 comments

XEmacs infloops on C-z with new GPM 25 years

Jan Vroonhof

With XEmacs 21.2, latest CVS. libgpm 1.14 (I still need to start GPM by hand. Shouldn't loading gpm.el be done by term/linux.el ?) Start xemacs on linux console M-x load-library RET gpm RET M-x gpm-mode RET C-z XEmacs spins printing libgpm: zero screen dimension, assuming 80x25 Attaching with gdb shows XEmacs is in some signal handler from the GPM library. Given that 1.14 is also the version that has the hang problems with the older XEmacs versions, maybe we should make configure check for libgpm 1.15 or greater? Jan

1 participants
0 comments

[what to do?] Windows FILETIME breakage between NT and 9[58] 25 years

Adrian Aichner

>>>>> "Craig" == Craig Lanning <CraigL(a)DyCon.com> writes: Hi All, this article discusses FILETIME handling on NT and 9[58] and puts up the question how to best cope with it in XEmacs (native and mingw32). Please bear with me while I give Craig two anserws. Other may fast-forward to My analysis: Craig> Are these files on an NTFS disk or FAT disk? These files are all on NTFS. Craig> My files are on a FAT32 disk. Craig> Does NTFS store the timestamp as a GMT integer like unix? Yes, that's it. Here's an extract from MSDN, which is still true for NT4: FileTimeToLocalFileTime() Adjusts for Daylight Saving Time Last reviewed: September 25, 1995 Article ID: Q128126 The information in this article applies to: Microsoft Win32 Application Programming Interface (API) included with: - Microsoft Windows NT version 3.5 SUMMARY Under NTFS, the API GetFileTime() returns the create time, last access time, and last write time for the specified file. The times returned in the FILETIME structures are in Universal Coordinated Time (UTC). This is also the time that NTFS uses. You can use FileTimeToLocalFileTime() to convert a file time to a local time. However, if you automatically adjust for Daylight Saving Time, FileTimeToLocalFileTime() will adjust for Daylight Saving Time based on whether the current date should be adjusted for Daylight Saving Time, not based on whether the date represented by the FILETIME structure should be adjusted. The behavior in this situation is different under FAT, but may be changed to match the behavior under NTFS in a future version of Windows NT. <lines deleted by Adrian> The FAT file system stores local time, not UTC. GetFileTime() gets cached UTC times from FAT. In this sample, the time stored is 1pm and the cached time is 9pm. When it becomes Daylight Saving Time, sample codes 1 and 2 will demonstrate the same behavior that they do under NTFS, because 9pm is still used. However, when you restart the machine, the new cached time will be 8pm (UTC = LocalTime + 7). The call to FileTimeToLocalFileTime() cancels the adjustment made by GetFileTime() (LocalTime = UTC - 7). Therefore, sample code 1 will report the correct time under FAT, but sample code 2 will not. On the other hand, FindFirstFile() on FAT always reads the time from the file (stored as local time) and converts it into UTC, adjusting for DST based on the current date. So if FindFirstFile() is called, the date is changed to a different DST season, and then FindFirstFile() is called again, the UTC returned by the two calls will be different. Craig> (FAT and FAT32 do not.) If so, that would explain why you Craig> see the time change in Explorer. Exactly. My analysis: I guess MS ``designed´´ FileTimeToLocalFileTime to interpret a FILETIME according to a computer's current DST and TZ setting because they have no way to know what a FAT FILETIME really means (by design, yeah right) since it is stored in local time. My vote is for doing it RIGHT for NTFS and POSIX partitions, interpreting these as UTC, and interpreting FAT partition file times to be relative to the current TZ and DST. That's all we can do, right? Craig> It is compiled and linked in, but I'm not sure how many of Craig> its functions are called. Andy would probably have a Craig> better idea on that. Could any of you tell me how to distinguish NTFS from FAT partitions both on Windows NT and Windows9[58] safely? After a lot of clicking in MSDN I found DeviceIoControl(BOOL DeviceIoControl( (HANDLE) hDevice, // handle to device of interest IOCTL_DISK_GET_PARTITION_INFO, // dwIoControlCode, control code // of operation to perform NULL, // lpInBuffer is not used; must be NULL 0, // nInBufferSize is not used; must be zero (LPVOID) lpOutBuffer, // pointer to output buffer (DWORD) nOutBufferSize, // size, in bytes, of lpOutBuffer (LPDWORD) lpBytesReturned, // pointer to variable to receive // output byte count (LPOVERLAPPED) lpOverlapped // pointer to OVERLAPPED structure // for asynchronous operation ); which is appealing at first glance. However, hDevice can only be opened directly with CreateFile on NT. 95 is incompatible and requires dealing with VxDs. Am I on the right track? What would be the simplest working way to tell apart NTFS and FAT files on the Windows NT, 95, 98 kindred? Thanks for any help! Adrian

1 participants
0 comments

Re: Give people with crashes more of a clue 25 years

Jan Vroonhof

rpluim(a)bigfoot.com writes: Thanks. > 1999-11-05 Robert Pluim <rpluim(a)bigfoot.com> > > * emacs.c (shut_down_emacs): Point users to PROBLEMS file I've applied this to 21.2. Recommended for 21.1. Jan

1 participants
0 comments

Can't load user-init-file in latest 21.2 25 years

Vin Shelton

'xemacs-21.2 -vanilla' produces the following lisp backtrace when I click on the "Load .emacs" button. Signaling: (wrong-number-of-arguments #<compiled-function nil "...(31)" [user-init-file paths-construct-path "~" user-init-file-base load t inhibit-default-init nil inhibit-startup-message "default"] 5 794380> 1) load-user-init-file("acs") (progn (delete-menu-item (quote ...)) (load-user-init-file (user-login-name))) ) eval((progn (delete-menu-item (quote ...)) (load-user-init-file (user-login-name)))) - vin

2 participants
1 comments

Re: itimer rewrite 25 years

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Hrvoje Niksic <hniksic(a)iskon.hr> writes: > > > cl.el is smarter than you think. > > I really have to read the documentation. But can I switch the safety > of just for the inner-loops? I think you can, but I'm not sure. See `declaim' docs. > > > I would love to be proven wrong though. > > > > Good enough? :-) > > Yes. But this time I would love to have Kyle's permission first. So would I. I argue for defstruct only if Kyle agrees to modernize itimer.el at all. The CL interfaces are pretty nice, but make little sense in an extremely portable Lisp application.

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta November 1999