December 2011 - XEmacs-Beta - XEmacs Mailing List Archives

Issues raised by the red windows build 12 years, 4 months

The XEmacs Package Smoketest

Hi, I thought it was time to turn the last red build into a green one. We have had that one for a very long time. I thought it would be a simple type mismatch that possibly could be handled with a cast. But... When I looked into it I realized it was much harder and that it raises a number of questions. - First of all the problem is the same with the other windows builds but these are built with gcc and the one that fails is built with g++. c++ is a bit harder on type mismatch causing errors instead of warnings. Conclusion: All windows builds ought to be fixed. - Fixing it is both easy and hard. - Fixing it is hard because unicode support on windows seems to be a can of worms. If I get it right we are also trying hard to build one binary that will work on all windows flavors going back to Windows-98 (or even further?) This doesn't make things easier. The current cygwin version has dropped support for the old versions of windows. This raises the question. Q: Can we drop that support to? Since I don't understand the code fully I'm not sure but it feels like that your code will be simpler if we could drop the runtime check on Windows version. Later versions of Windows might have more stable APIs making our code even simpler? - Fixing it is easy because these functions that causes the error isn't used!? We could simply remove them. If I get it right there is in intl-auto-encap-win32.c and intl-encap-win32.c a small framework for supporting windows APIs that could potentially be used. So they are ready to be used once we need them. It also has trip wires to alert you when using the wrong function names. Am I missing something here? Are they maybe useful for users writing there own modules so removing them would be a bad idea? Is the framework really paying of? It seems strange to me to have a bunch of loose functions hanging around. (If I fix the error how would I know that I did it right?) But I guess once I would need a function in the framework I would be grateful that it was already provided (if it was implemented right that is!) Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

3 participants
15 comments

Summary of XEmacs Issue Tracking System Issues 12 years, 4 months

XEmacs Issue Tracking System

ACTIVITY SUMMARY (2011-12-13 - 2011-12-20) XEmacs Issue Tracking System at http://tracker.xemacs.org/XEmacs/its/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 540 open ( +0) / 276 closed ( +0) / 816 total ( +0) Open issues with patches: 11 Average duration of open issues: 986 days. Median duration of open issues: 1041 days. Open Issues Breakdown new 215 ( +0) deferred 6 ( +0) napping 4 ( +0) verified 55 ( +0) assigned 150 ( +0) committed 19 ( +0) documented 3 ( +0) done/needs work 17 ( +0) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

1 participants
0 comments

busy-pointer-glyph 12 years, 4 months

Julian Bradfield

What *is* the busy pointer? I can't find any actual use of it in the code. Where I previously thought I saw it, I think I'm actually seeing the gc pointer. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

2 participants
1 comments

XEmacs website about packages 12 years, 4 months

Didier Verna

I guess somebody's aware of the fact that the website still mentions alioth and CVS for the packages distribution ? -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

2 participants
1 comments

XEmacs 21.5 and hard links 12 years, 4 months

Didier Verna

Hi, I don't have time to look into this right now, but I've just discovered that 21.5 has a serious problem with hard links. - write something in a - ln a b - modify a you get a brand new file for a, and a~ stays as the original linked file, so b and a~ (not a) are the same file. 21.4 doesn't have this problem (in fact, it seems that 21.4 does not create a backup file with -vanilla whereas 21.5 does). -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

3 participants
3 comments

No changes since October? 12 years, 4 months

robert delius royar

Have there been no committed changes to xemacs 21.5.31 source since late October? I have seen discussions on this list about problems with commits to the package store. But I have not noticed any changes to the source archives at hg.debian.org/hg/xemacs/xemacs Version for the latest compilation I have on my system reads XEmacs 21.5 (beta31) "ginger" 10f179710250 [Lucid] (i386-apple-darwin10.8.0, Mule) of Sat Oct 29 2011 Running % hg --cwd /Users/royar/src/xemacs-hg incoming Tells me real URL is http://anonscm.debian.org/hg/xemacs/xemacs/ comparing with http://hg.debian.org/hg/xemacs/xemacs/ searching for changes no changes found % -- rdr _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

3 participants
3 comments

Re: [Bug: 21.5-b31] seg fault 12 years, 4 months

Jerry James

Please don't drop the mailing list in your replies. I've added it back for this message. On Mon, Dec 12, 2011 at 8:47 PM, Don Cohen <don-redhat-zx(a)isis.cs3-inc.com> wrote: > I don't know how to repeat it, but I've had a number of similar > problems since installing fedora 16 kde last week... > I gather that in order to get a C backtrace I need a core file > and the OS came with ulimit core size = 0. I've now changed that > so the next time I can try to use the core file. OK, but ... > > So abrt didn't catch the crash? Or have you disabled abrt? > Is that the "automatic bug reporting tool"? Yes. > That shows some sigsegv's from usr/bin/kded4 but not xemacs. > So I guess it's not disabled. Hmmm, it's supposed to catch crashes and store core files, even if the user running the process has ulimit core-size = 0. I do, for example, but I've already files 3 crash reports via abrt since installing Fedora 16. So there's some kind of problem with abrt not noticing that your XEmacs process crashed. How are you launching XEmacs? Via a desktop menu? On the command line? > I guess this particular crash will go undiagnosed, and I'll be > better prepared if it happens again. Maybe. Should I be installing > xemacs-debuginfo in anticipation? Anything else? No, let's go with what you've tried so far and see what happens. -- Jerry James http://www.jamezone.org/ _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

2 participants
1 comments

Re: [21.5] bytecomp bug 12 years, 4 months

Aidan Kehoe

Ar an t-ochtú lá de mí na Nollaig, scríobh Katsumi Yamaoka: > Aidan Kehoe <kehoea(a)parhasard.net> wrote: > > > Ar an seachtú lá de mí na Nollaig, scríobh Katsumi Yamaoka: > > >> The combination of the `lexical-let' macro and the `labels' macro > >> produces the `(quote lambda)' element in its expanded form as > >> the case may be, and the most recent bytecomp got to fail with it. > > > Thanks for the clear and detailed bug report. This is my bug, I ll commit a > > fix within a next week. > > Thanks. Good luck on you! I’ve just committed: https://bitbucket.org/xemacs/xemacs/changeset/2c20bc575989 which addresses the problem you reported. I’ve also committed: https://bitbucket.org/xemacs/xemacs/changeset/a944c124b2d3 which addresses a separate problem that I need to fix in order to get emacs-w3m to compile (fair enough, glad to have the opportunity to fix it). I, however, also need the following change to W3M to get it to compile, I’m surprised you’re not seeing it (the problem was an interaction of lexical-let and compile-time defsetf expansion). Index: w3m.el =================================================================== RCS file: /storage/cvsroot/emacs-w3m/w3m.el,v retrieving revision 1.1545 diff -u -r1.1545 w3m.el --- w3m.el 7 Dec 2011 02:35:46 -0000 1.1545 +++ w3m.el 13 Dec 2011 20:50:51 -0000 ＠＠ -2873,8 +2873,8 ＠＠ Otherwise return nil." (let ((v (w3m-arrived-intern url t))) (and v (boundp v) (symbol-value v)))) -(defsetf w3m-arrived-time (url) (value) - (list 'w3m-arrived-add url nil nil value)) +(defsetf w3m-arrived-time (url-) (value) + (list 'w3m-arrived-add url- nil nil value)) (defun w3m-arrived-put (url property value) "Store VALUE in the arrived URLs database as the PROPERTY of URL. -- ‘Iodine deficiency was endemic in parts of the UK until, through what has been described as “an unplanned and accidental public health triumph”, iodine was added to cattle feed to improve milk production in the 1930s.’ (EN Pearce, Lancet, June 2011) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

1 participants
0 comments

[Bug: 21.5-b31] seg fault 12 years, 4 months

Stephen J. Turnbull

Don Cohen writes: > turned out to be my touch pad sending scroll events too eagerly, > things are improved by turning down the sensitivity Nice to know. Thanks for the followup! If you have further issues, or if you find that you'd really like to have the higher sensitivity in other applications, feel free to file a bug report then. Maybe there's something XEmacs can do to absorb those events more flexibly. > > No core, no help. Lisp by definition can't crash :-), so the problem > > is in the C runtime. Without a C backtrace, there's nothing we can > > do. > The problem (at least part of it) is that fedora 16 seems to come > with ulimit core = 0 - I've now fixed that for next time. Well, it's a two-edged sword. ISTR that Fedora contrives to have a unique name for each core file, so they can pile up pretty fast if you've got a commonly used library that goes buggy in some upgrade. > yum install xemacs-debuginfo > now done That sounds easy enough! Again, thanks for the followup. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

2 participants
1 comments

Summary of XEmacs Issue Tracking System Issues 12 years, 4 months

XEmacs Issue Tracking System

ACTIVITY SUMMARY (2011-12-06 - 2011-12-13) XEmacs Issue Tracking System at http://tracker.xemacs.org/XEmacs/its/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 540 open ( +0) / 276 closed ( +0) / 816 total ( +0) Open issues with patches: 11 Average duration of open issues: 979 days. Median duration of open issues: 1034 days. Open Issues Breakdown new 215 ( +0) deferred 6 ( +0) napping 4 ( +0) verified 55 ( +0) assigned 150 ( +0) committed 19 ( +0) documented 3 ( +0) done/needs work 17 ( +0) Issues Now Closed (1) _____________________ XEmacs 21.4 will not compile w/gcc-4 on cygwin 783 days http://tracker.xemacs.org/XEmacs/its/issue609 acs _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

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 December 2011