gmane.emacs.xemacs.beta

Re: cl-gethash

Stephen J. Turnbull — 2012-05-26T05:02:57

 > Mats Lidell writes:
 > 
 >  > And who uses ftp these days for download?
 > 
 > Well, I would, if it worked ;-)

You need to tell your client *not* to use passive FTP.

I know, I know, but this misconfiguration of the server has persisted
for years, and every time it gets fixed it gets restored from backup.
I'd like to move from Tux (they used to be very helpful, but the
people who actually do the administration now are, er, a bit
self-centered).  Suggestions are welcome.  I'd rather avoid
Sourceforge (we're big enough that we would be continuously
negotiating with them for space) and Savannah (dunno whether it's
enemies on the outside, or lack of staff on the inside, but they're
just too unresponsive).

 >  > wget, even getting libcurl support included in the core.

I've posted branches for that in past, but nobody expressed any
interest.  There are three ways to do it, in fact; you can incorporate
the FFI branch and use the included libcurl bindings as SXEmacs does,
or you can use my libcurl or neon bind

Re: cl-gethash

Mats Lidell — 2012-05-25T21:46:46


I'm afraid that it might be that. I don't know whether this is true in
all cases but I think that the ftp-sites are not known to be very
stable. I have also had problems with the ftp client side that might
not work stable. And who uses ftp these days for download?

I've previously announced that I'm looking into improving the package
situation possibly by using another client than ftp, like curl or
wget, even getting libcurl support included in the core. So we could
have http based archives. However I'm afraid I've been busy with other
stuff so much that I have forgotten all about this and I need to start
it all over again if I will find the time for it at all.

Yours

Re: cl-gethash

Charles G Waldman — 2012-05-25T21:50:53

 > And who uses ftp these days for download?

Well, I would, if it worked ;-)

 > I've previously announced that I'm looking into improving the package
 > situation possibly by using another client than ftp, like curl or
 > wget, even getting libcurl support included in the core. So we could
 > have http based archives. However I'm afraid I've been busy with other
 > stuff so much that I have forgotten all about this and I need to start
 > it all over again if I will find the time for it at all.

OK, a familiar situation ... maybe I'll hack on this and see if I get
anywhere!


 - Charles

cl-gethash (was: another redisplay crash)

Charles G Waldman — 2012-05-25T16:29:57

Thanks Mike -  HTML mail is now readable again, after manually
downloading and installing a prerelease W3 package.

     - Charles

cl-gethash (was: another redisplay crash)

Charles G Waldman — 2012-05-25T14:17:18

Thanks for the tip Mike. 

I tried using the package manager to download prerelease packages,
and I get this:

  open ftp.xemacs.org
  Connected to xemacs.org.
  220 ProFTPD 1.2.9 Server (ProFTPD on ftp.tux.org) [gwyn.tux.org]
  quote user "anonymous"
  500 AUTH not understood

  open mirrors.ibiblio.org
  Connected to mirrors.ibiblio.org.
  220 Welcome to mirrors.ibiblio.org FTP service.
  quote user "anonymous"
  530 Please login with USER and PASS.

I'll download packages manually and try that out.  But I wanted to
report this failure with the integrated package manager.  Is this
a well-known issue?

     - Charles

Mike Kupfer writes:
 > Charles G Waldman wrote:
 > 
 > > Most prominently, I can no longer display HTML mail
 > > in VM, which used to work... I'm seeing this error:
 > >  
 > >   Inline HTML display failed: (void-function cl-gethash)
 > 
 > I see this error if I try to use an older version of w3 with 21.5.  You
 > might need to install a prerelease version of vm or w3.
 > 
 > mike

cl-gethash (was: another redisplay crash)

Mike Kupfer — 2012-05-25T00:34:44


I see this error if I try to use an older version of w3 with 21.5.  You
might need to install a prerelease version of vm or w3.

mike

[Bug: w3] excessive indentation in w3 1.37+

Mike Kupfer — 2012-05-24T22:44:10

Dear Bug Team!

When I view some simple HTML using the new w3 (package versions 1.37,
1.38), lists have an excessive amount of indentation.  This is bad
enough to make w3 unusable IMO.

For example:

*** w3-1.36Thu May 24 15:29:44 2012
--- w3-1.38Thu May 24 15:28:52 2012
***************
*** 2,9 ****
  
  Mike's Reference Library
  
!    o Aikido
!    o Audio that I own
!    o Bay Area
!         o SF and north Peninsula soil types
!         o mid-Peninsula and south bay soil types
--- 2,16 ----
  
  Mike's Reference Library
  
!                                 o Aikido
!                                 o Audio that I own
!                                 o Bay Area
!                                                                   o SF and
!                                                                     north
!                                                                     Peninsula
!                                                                     soil types
!

Re: another redisplay crash

Charles G Waldman — 2012-05-24T22:01:28

Yesterday, I wrote: 

  > I have a nice looking XEmacs now, and if that redisplay crash is
  > gone, I'll be happy.

I guess I spoke too soon.  The version I built from latest Hg sources
has some issues.  Most prominently, I can no longer display HTML mail
in VM, which used to work... I'm seeing this error:

  Inline HTML display failed: (void-function cl-gethash)

Doing "require 'cl" and "require 'cl-extra" doesn't help, I'm trying
to figure out what's going on.

         - Charles

Re: another redisplay crash

Stephen J. Turnbull — 2012-05-24T09:13:22

 > Oh, that's right, I remember the situation now.  Sorry for
 > misspeaking.  I guess if I wanted to be snarky (which I don't,
 > really) I'd ask next:  "What would it take to get a new version
 > released?"

Find me another two hours in the day....

Or another volunteer.

Re: another redisplay crash

Charles G Waldman — 2012-05-24T01:31:57

Oddly enough, it is the configure flag "--with-datadir=/usr/share"
which caused my build to fail at load time.

I only specified this flag because it's in the Gentoo ebuild.
But, since I'm setting --prefix=/usr, this flag shouldn't even
matter:  according to ./configure --help,

  --datarootdir=DIR       read-only arch.-independent data root [PREFIX/share]
  --datadir=DIR           read-only architecture-independent data [DATAROOTDIR]

So, since I'm setting prefix to /usr, the datarootdir should default
to /usr/share, and datadir to the same thing, right?  So it's odd that
this should cause the build to fail.  But I suppose there are bigger 
fish to fry than this - at least, I have a nice looking XEmacs now, and if
that redisplay crash is gone, I'll be happy.

     Cheers,

- Charles



 > > # ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 -

Re: another redisplay crash

Charles G Waldman — 2012-05-24T00:32:21

 > You might try a configure without all the options you used. I am running
 > the latest mercurial code building with:
 > 
 > ./configure --with-ncurses --with-system-packages=/usr/local/lib/xemacs --with-menubars=lucid --with-scrollbars=lucid --with-dialogs=athena

OK, that works, but ... I don't get the nice antialiased fonts I've
grown accustomed to (it looks pretty rough) and it's also noticeably
slower, I presume because of the lack of '--with-optimization'

Anyhow, now it's on me to find out which of my configure flags
is breaking things.  I'll work on that and report back.

Vielen Dank,

   - C

 > Charles G Waldman wrote:
 > > # ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --with-widgets=athena --with-dialogs=athena --with-menubars=lucid --with-scrollbars=lucid --with-athena=3d --with-dragndrop --with-offix --with-tiff --with-png

Re: another redisplay crash

Thomas Mittelstaedt — 2012-05-23T23:56:19

Am Mittwoch, den 23.05.2012, 18:34 -0500 schrieb Charles G Waldman:

You might try a configure without all the options you used. I am running
the latest mercurial code building with:

./configure --with-ncurses --with-system-packages=/usr/local/lib/xemacs --with-menubars=lucid --with-scrollbars=lucid --with-dialogs=athena

Re: another redisplay crash

Charles G Waldman — 2012-05-23T23:34:06

 > Charles G Waldman wrote:
 > > 
 > > What would it take to get this patch applied?
 > 
 > If this is the issue and patch I'm thinking of, the patch has been
 > applied, but there hasn't been a new release since then.

Oh, that's right, I remember the situation now.  Sorry for
misspeaking.  I guess if I wanted to be snarky (which I don't,
really) I'd ask next:  "What would it take to get a new version
released?"
 > 
 > You could try downloading from the Mercurial repo and building that.
 > I'm running

OK, just grabbed the latest from Mercurial.  It's been a while since I
built XEmacs from source myself (used to do it a lot, nowadays I let
Gentoo build it for me).

So I grabbed the latest from the hg repo, and used the same configure
command that Gentoo came up with, based on my system settings:


# ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/li

Re: another redisplay crash

Mike Kupfer — 2012-05-23T22:26:23


If this is the issue and patch I'm thinking of, the patch has been
applied, but there hasn't been a new release since then.

You could try downloading from the Mercurial repo and building that.
I'm running

    changeset:   5644:0df3cedee9ac
    tag:         qparent
    user:        Aidan Kehoe <kehoea< at >parhasard.net>
    date:        Fri Mar 02 18:26:14 2012 +0000
    summary:     select-coercion-alist, not select-conversion-alist, select.el
    
and it's been stable for me.

mike

Summary of XEmacs Issue Tracking System Issues

XEmacs Issue Tracking System — 2012-05-22T10:35:04

ACTIVITY SUMMARY (2012-05-15 - 2012-05-22)
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.


  543 open ( +1) /   286 closed ( +0) /   829 total ( +1)

Open issues with patches:    11

Average duration of open issues: 1127 days.
Median duration of open issues: 1187 days.

Open Issues Breakdown
              new   220 ( +1)
         deferred     6 ( +0)
          napping     3 ( +0)
         verified    55 ( +0)
         assigned   152 ( +0)
        committed    18 ( +0)
       documented     3 ( +0)
  done/needs work    17 ( +0)

Issues Created Or Reopened (1)
______________________________

Scrolling Bug                                                  2012-05-20
       http://tracker.xemacs.org/XEmacs/its/issue831 created  anonymous

21.5.31 Mule and the ’ symbol (input method?)

Uwe Brauer — 2012-05-23T09:53:08


Hello


I sent this mail to the list via gmane and it did not pass it seems, so I
send it again.

symbol ’ is used, as in j’ai instead of j'ai.

Now this is perfectly displayed (en encoded via UTF8) in
21.5.31 Mule, however I cannot find any input method for
this symbol.

Well this is not entirely true. latin-ltx includes it:
typing \rq results in ’
but this looks cumbersome. 
 
Uwe Brauer 

_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta< at >xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta

another redisplay crash

Charles G Waldman — 2012-05-23T16:50:59

Hi XEmacs team:

I'm running 
 XEmacs 21.5  (beta31) "ginger" [Lucid] (x86_64-pc-linux) of Thu Mar 22 2012 on x201

I've gotten the same crash a few times in the last few days.  I believe 
that a patch for this exact problem has been submitted (not by me).  

What would it take to get this patch applied?


     Thanks, 

     - Charles



(gdb) where
#0  0x00007f8a58d4ebc7 in kill () from /lib64/libc.so.6
#1  0x00000000004c9c64 in fatal_error_signal (sig=6) at emacs.c:3896
#2  <signal handler called>
#3  0x00007f8a58d4ea05 in raise () from /lib64/libc.so.6
#4  0x00007f8a58d4fd05 in abort () from /lib64/libc.so.6
#5  0x00000000004c9905 in really_abort () at emacs.c:4792
#6  assert_failed (file=<optimized out>, line=<optimized out>, expr=<optimized out>) at emacs.c:4089
#7  0x0000000000689675 in Dynarr_verify_pos_atp (line=9179, file=0x794f77 "redisplay.c", pos=-1, 
    d=<optimized out>) at array.h:202
#8  pixel_to_glyph_translation (f=0x31a6268, x_coord=628, y_coord=504, col=0x7fff64bbebfc, 
    row=<optim

RE: [Bug: 21.5-b29] Crash in XawVendorStructureNotifyHandler

Janzen, Martin — 2012-05-15T15:41:31

 
Hi, Jerry!


It was running on RHEL AS4; I believe it's version 4.2.  Here's the Linux version: 

$ uname -a
Linux euxconnlx 2.6.9-103.EL.msdw.1largesmp #1 SMP Mon Dec 12 13:34:16 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

I don't have root access here, so I'm not able to run the debuginfo-install command.  I had a look around for debugging versions of these libraries, with no success.  Building them myself is a last resort, but this would take a lot of time, which is something I'm afraid I don't have right now!

I'm sorry if that's not much help.  If you're unable to investigate further without the debugging stack trace, I completely understand.  I think it's the second time that Emacs has crashed on me since about 1988, so I won't be too upset.  If the problem does turn out to be recurring, and ideally reproducible, I'll certainly see what I can do to gather more debugging information.

Thanks very much,

MJ

--------------------------------------------------------------------------
NOTICE: Morgan Stanley

Summary of XEmacs Issue Tracking System Issues

XEmacs Issue Tracking System — 2012-05-15T10:35:04

ACTIVITY SUMMARY (2012-05-08 - 2012-05-15)
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.


  542 open ( +0) /   286 closed ( +0) /   828 total ( +0)

Open issues with patches:    11

Average duration of open issues: 1123 days.
Median duration of open issues: 1182 days.

Open Issues Breakdown
              new   219 ( +0)
         deferred     6 ( +0)
          napping     3 ( +0)
         verified    55 ( +0)
         assigned   152 ( +0)
        committed    18 ( +0)
       documented     3 ( +0)
  done/needs work    17 ( +0)

Re: Byte compiler issue

Aidan Kehoe — 2012-05-16T15:57:42

Hi Rodney,

 Ar an ceathrú lá déag de mí Bealtaine, scríobh Rodney Sparapani: 

 > I have a file that byte compiles with 21.4.22, but not with
 > the latest as of last Friday nor 21.5.31.  The file is
 > https://svn.r-project.org/ESS/trunk/lisp/ess-sas-a.el
 > 
 > The backtrace from the latest is:
 > 
 > Debugger entered--Lisp error: (invalid-function #<keymap map size 0 0x11e>)
 >    (map nil #<compiled-function (from 
 > "/home/rsparapa/hg/xemacs/lisp/bytecomp.elc") (&rest #:--rest--32884) 
 > "...(46)" [function #:--rest--32884 nargs 1 signal 
 > wrong-number-of-arguments nil put byte-compile-keyword-start] 5 
 > "\n\narguments: ((FUNCTION &rest NARGS))\n" 0x1afa> (quote (... ... ... 
 > ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 
 > ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 
 > ... ... ... ... ... ... ... ... ... ... ... ... ...)))

Thanks for the bug report! This is a problem with ESS, not with XEmacs; I’ve
a patch below.

Best,

Aidan

Re: [Bug: 21.5-b29] Crash in XawVendorStructureNotifyHandler

Jerry James — 2012-05-15T13:56:57

Martin, what version of RHEL/CentOS/Fedora are you using?  If you can
run "debuginfo-install libXt libXaw" as root, then regenerate the
backtrace, that would be very helpful.