November 1999 - XEmacs-Beta - XEmacs Mailing List Archives

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

Bill Tutt

> From: Adrian Aichner [mailto:aichner＠ecf.teradyne.com] > >>>>> "Bill" == Bill Tutt <billtut(a)microsoft.com> writes: > > Hello Bill! > > Bill> Adrian, your stat wrapping makes sense to me. > > What I have yet to put in, is to determine whether the current volume > actually has UTC dates. Fabrice suggested using > GetVolumeInformation() and that works fine too. > > Does CDFS have UTC times? > With your current fix, what would this gain? As long as you compare file times using identical methods all the time, then it should never matter. To fill in the details on the ISO CD FS spec: (not the Win32 CDFS driver) Volume creation date/times are formatted something like: struct sCDFS { DWORD dwYear; WORD wMonth; WORD wDay; WORD wHour; WORD wMinute; WORD wSecond; WORD wHundredths; BYTE bOffsetFromGMT; // This is for 15min. intervals }; > Bill> The explination behind this mess is fairly straight forward: > > Bill> NT doesn't use the standard timezone handling library that > Bill> everyone knows and loves in Unix land. See KB article: > Bill> Q115231 for details on what Win32 actually does. > > Bill> Which is why FileTimeToLocalTime() can only use the current > Bill> DST state, and stat() uses FileTimeToLocalTime() due to > Bill> various backwards compatibility reasons. See the MS CRT > Bill> source for the grungy details. > > Bill> glibc appears to do the correct thing by searching through > Bill> the timezone's transition history and makes the appropriate > Bill> adjustment. (including leap seconds) > > Isn't that neat? > Yeah it is. It'd be even neater if time_t could handle all of the timezone transitions that the timezone file has. Bill

1 participants
0 comments

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

Adrian Aichner

>>>>> "Bill" == Bill Tutt <billtut(a)microsoft.com> writes: Hello Bill! Bill> Adrian, your stat wrapping makes sense to me. What I have yet to put in, is to determine whether the current volume actually has UTC dates. Fabrice suggested using GetVolumeInformation() and that works fine too. Does CDFS have UTC times? Bill> The explination behind this mess is fairly straight forward: Bill> NT doesn't use the standard timezone handling library that Bill> everyone knows and loves in Unix land. See KB article: Bill> Q115231 for details on what Win32 actually does. Bill> Which is why FileTimeToLocalTime() can only use the current Bill> DST state, and stat() uses FileTimeToLocalTime() due to Bill> various backwards compatibility reasons. See the MS CRT Bill> source for the grungy details. Bill> glibc appears to do the correct thing by searching through Bill> the timezone's transition history and makes the appropriate Bill> adjustment. (including leap seconds) Isn't that neat? Bill> Bill Cheers, and thanks for the insight! Adrian

1 participants
0 comments

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

Bill Tutt

Adrian, your stat wrapping makes sense to me. The explination behind this mess is fairly straight forward: NT doesn't use the standard timezone handling library that everyone knows and loves in Unix land. See KB article: Q115231 for details on what Win32 actually does. Which is why FileTimeToLocalTime() can only use the current DST state, and stat() uses FileTimeToLocalTime() due to various backwards compatibility reasons. See the MS CRT source for the grungy details. glibc appears to do the correct thing by searching through the timezone's transition history and makes the appropriate adjustment. (including leap seconds) Bill

1 participants
0 comments

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

Michael Sperber

>>>>> "APA" == Adrian Aichner <aichner(a)ecf.teradyne.com> writes: >>>>> "Michael" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: >>>>> "APA" == Adrian Aichner <aichner(a)ecf.teradyne.com> writes: APA> Handling of user-init-* is an open issue which was discussed starting at APA> http://www.xemacs.org/list-archives/xemacs-beta/9908/msg00772.html Michael> What's open about it? There was design, discussion, redesign, Michael> implementation, and agreement, and so far, noone has complained. APA> I missed the redesign, implementation, and agreement part. >From etc/NEWS: ** New command-line switches -user-init-file and -user-init-directory. These can be used to specify alternate locations for what is normally ~/.emacs and ~/.xemacs. Moreover, -user <user> (which used to only work in unpredictable ways) is now equivalent to -user-init-file ~<user>/.emacs -user-init-directory ~<user>/.xemacs. APA> Are you suggesting APA> xemacs -u aichner APA> works for you in 21.2-b20? As far as such a thing can work given the design constraints, yes. A couple of people (Jan, notably) who depend on it also approved the fixes. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: Empty string in mini buffer history 25 years

Jan Vroonhof

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > Recording zero-length input makes sense in the situations where what > you record really is a zero-length string. It does not make sense and > is annoying in the situations where just typing RET activates a > default. In that case typing RET to activate a default should maybe put that default value in the history? Jan

1 participants
0 comments

@ifnottex: texinfo 3.12, 4.0, and XEamcs 21.2 25 years

Adrian Aichner

Hello Karl, the latest XEmacs 21.2-b20 CVS sources have been synched with texinfo 4.0. This surfaced the problem that the `texinfo' package of XEmacs does not support the ＠ifnottex .. ＠end ifnottex construct. Further investigation shows that texinfo-3.12 has problems with this construct also. Was this a bug in 3.12? Sources indicate that it should support the construct. makeinfo-4.0 has not problems translating texinfo.txi and info.texi. Thanks for any insight into the issue. d:\tmp\texinfo-4.0\ChangeLog: Sun Nov 29 17:12:35 1998 Karl Berry <karl(a)gnu.org> * doc/texinfo.txi: Use ＠ifnottex rather than ＠ifinfo for ＠top. (makeinfo top): document this. * doc/info-stnd.texi, * doc/info.texi: Use ＠ifnottex rather than ＠ifinfo for ＠top. Best regards, Adrian

3 participants
2 comments

Re: Char-related crashes (hopefully) fixed 25 years

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > Hrvoje> I could think of more of such, but I don't really see > Hrvoje> the point. > > The point is that at least two of your four examples are bugs. > (`foo-legal-chars' suffers from the same problem as `stupid'.) And > the implicit ones, if they turn out to be bugs after all (eg, > because the internal representation of characters changes) are going > to be practically impossible to find until they bite. I agree completely. *But*, they work for many (most?) people, and I believe they should continue to work unchanged at least for some more time. Retaining a measure of backward-compatibility is important. During the years I've come to the conclusion that Emacs is not a very smart thing; it's good because it's old and because lots of code has been written. APIs _do_ change (as witness by the coming of Emacs 19 and XEmacs), but they should change slowly and at the right time, unless we wish to alienate our user-base.

3 participants
2 comments

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

Adrian Aichner

>>>>> "Michael" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: >>>>> "APA" == Adrian Aichner <aichner(a)ecf.teradyne.com> writes: APA> Handling of user-init-* is an open issue which was discussed starting at APA> http://www.xemacs.org/list-archives/xemacs-beta/9908/msg00772.html Michael> What's open about it? There was design, discussion, redesign, Michael> implementation, and agreement, and so far, noone has complained. I missed the redesign, implementation, and agreement part. Are you suggesting xemacs -u aichner works for you in 21.2-b20? It surely can't work under a native Windows build, but that's a different matter. Windows users are all homeless, except for the use of a HOME env. var. by XEmacs. Adrian Michael> -- Michael> Cheers =8-} Chipsy Michael> Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

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

Michael Sperber

>>>>> "APA" == Adrian Aichner <aichner(a)ecf.teradyne.com> writes: APA> Handling of user-init-* is an open issue which was discussed starting at APA> http://www.xemacs.org/list-archives/xemacs-beta/9908/msg00772.html What's open about it? There was design, discussion, redesign, implementation, and agreement, and so far, noone has complained. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: 10% redisplay speed up... 25 years

Jan Vroonhof

Ben Wing <ben(a)666.com> writes: > Why don't you post exactly the steps you took in order to get the > profiling output, as well as the relevant part of the output itself? > I think people are scared off of profiling because XEmacs is big and > does nonstandard things with its executable, and they don't want to > figure out how to do it. I had originally planned to do make a --enable-profiling configure option. Because now you have to hand edit the makefile to make sure the right startup code gets linked in. Maybe I should indeed just do a Q&D README becuase the pdumper will make all linking magic unnecessary hopefully. > I really really think you should implement your comment about > memcmp(). Do something like this: It is on the todo list for one of those long winter nights (Unfortunately, "Write thesis" is also on that list). Let me take this opportunity to discuss some things. grprof data from doing (hanoi 6) 100-times Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 19.87 128.23 128.23 6977571 0.02 0.03 create_text_block 16.35 233.71 105.48 577884641 0.00 0.00 add_emchar_rune 15.36 332.81 99.10 543668585 0.00 0.00 compare_runes 6.99 377.94 45.13 544418806 0.00 0.00 display_table_entry 3.29 399.16 21.22 6977832 0.00 0.00 compare_display_blocks 2.89 417.78 18.62 715922 0.03 0.04 generate_fstring_runes 1.76 429.15 11.37 6978119 0.00 0.00 output_display_line 1.44 438.44 9.29 14864431 0.00 0.00 specifier_instance 1.36 447.23 8.79 23712557 0.00 0.00 specifier_instance_from_inst_list 1.06 454.08 6.85 44087313 0.00 0.00 find_symbol_value_1 Notes 1. add_emchar_rune and compare_runes are called approximately equal numbers of times. So we must take care not to add too much overhead to the one to optimize the other. 2. The self_seconds data seems fairly inaccurate and/or I am interpreting the data wrong. Here is the callgraph data for add_emchar_rune 33107464 generate_fstring_runes <cycle 1> [16] 544777177 create_text_block <cycle 1> [5] [8] 16.3 105.48 0.00 577884641 add_emchar_rune <cycle 1> [8] 0.00 0.00 362/980266 Dynarr_resize [173] 9125117 ensure_face_cachel_contains_charset <cycle 1> [86] Note how its children takeup almost no time, so where did the CPU time go... Now to completely differnt data. This is from gcov (compile using --profile-arcs). This was a normal news reading and writing session using Gnus. This is in point_in_line_start_cache from redisplay.c 1563 if (!Dynarr_length (cache) || line_start_cache_start (w) > point branch 0 taken = 37% call 1 returns = 100% branch 2 taken = 1% call 3 returns = 100% branch 4 taken = 0% branch 5 taken = 100% || line_start_cache_end (w) < point) { 589 int loop; Notice that in almost 40% of the cases, there was no cache present. Note also the callcount of the function and compare that with the callcount in redisplay_window. /* Don't pollute the cache if not sure if we are correct */ 8843 if (w->start_at_line_beg) branch 0 taken = 0% 8842 update_line_start_cache (w, start, end, pointm, 1); call 0 returns = 100% Is the line_start_cache being ineffective? Jan

2 participants
1 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