November 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: suggestion for the CVS archive 25 years, 5 months

SL Baur

Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes in xemacs-beta(a)xemacs.org: dv> There has been recent checkins in the source code whereas no new dv> beta is officially announced yet for 21.2, and there's no relation dv> between checkins and betas for packages. Besides, now that package dv> checkins begin to be distributed among their respective maintainers, dv> they tend to become completely asynchronous and I beleive a mailing dv> list for this could be very usefull. Checkins *and* builds if everything goes according to the new plans. > I didn't know that. However, as far as I can tell, there are still no > useful log messages. They have been useful to me letting me know which packages need new binary kits built. That's not going to matter when there's a method for developers to have their packages rebuilt (hopefully) without XEmacs maintainer intervention. But they're still useful in the sense seeing entries appear on freshmeat is useful. As to log messages, I haven't bothered with them in the core because the ChangeLogs and CHANGES-beta carry all change information and I've been the only one doing commits[1]. I'm all for some kind of distribution of commit info and log entries and I believe the more light we shine on them, the better the messages will become. Footnotes: [1] Actually, I don't know how to make CVS report existing log entries.

1 participants
0 comments

Re: suggestion for the CVS archive 25 years, 5 months

Didier Verna

Michael Sperber writes: Michael> However, as far as I can tell, there are still no useful log Michael> messages. Usefull in themselves, perhaps not, but nevertheless, this is a convenient way to let people (updating from CVS) informed that there was a checkin (so they probably want the grab the new version), and removes the burden of composing a silly mail by hand each time in the same purpose. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

Re: suggestion for the CVS archive 25 years, 5 months

Michael Sperber

>>>>> "dv" == Didier Verna <verna(a)inf.enst.fr> writes: dv> Michael Sperber writes: Michael> This is rather pointless at present as there are no useful log Michael> messages, and checkins happen only at beta release time. dv> There has been recent checkins in the source code whereas no new beta dv> is officially announced yet for 21.2, and there's no relation between checkins dv> and betas for packages. Besides, now that package checkins begin to be dv> distributed among their respective maintainers, they tend to become completely dv> asynchronous and I beleive a mailing list for this could be very usefull. I didn't know that. However, as far as I can tell, there are still no useful log messages. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: suggestion for the CVS archive 25 years, 5 months

Didier Verna

Michael Sperber writes: Michael> This is rather pointless at present as there are no useful log Michael> messages, and checkins happen only at beta release time. There has been recent checkins in the source code whereas no new beta is officially announced yet for 21.2, and there's no relation between checkins and betas for packages. Besides, now that package checkins begin to be distributed among their respective maintainers, they tend to become completely asynchronous and I beleive a mailing list for this could be very usefull. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

Re: base64 suggestions 25 years, 5 months

Hrvoje Niksic

Martin Buchholz <martin(a)xemacs.org> writes: > >> Also, here is a rewritten XMALLOC_OR_ALLOCA macro that avoids > >> multiple evaluation of the `len' argument. > > Hrvoje> I'll add the patch on the grounds of general saneness, but > Hrvoje> what's the point? I mean, the macro is purely local in > Hrvoje> nature, and if you use it, you should know what you're > Hrvoje> doing. > > For macros that have statement semantics, e.g. using do {} while > (0), as opposed to expression semantics, it is always possible to > eliminate multiple evaluation, and we should do so consistently. I > have been adding this kind of macro hygiene in the XEmacs sources > for a while now. Do the added automatic variables make a difference? -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- A jury consists of 12 persons chosen to decide who has the better lawyer.

2 participants
1 comments

Re: base64 suggestions 25 years, 5 months

Hrvoje Niksic

Martin Buchholz <martin(a)xemacs.org> writes: > The Sun compiler points out that this code looks suspicious: > > if (decoded_length < 0) > { > return Qnil; > XMALLOC_UNBIND (decoded, length * MAX_EMCHAR_LEN); > } And rightfully so. Fix attached below. > Also, here is a rewritten XMALLOC_OR_ALLOCA macro that avoids > multiple evaluation of the `len' argument. I'll add the patch on the grounds of general saneness, but what's the point? I mean, the macro is purely local in nature, and if you use it, you should know what you're doing. Your rewritten version also adds parentheses around PTR, which is an lvalue -- is that legal? (I removed them.) --- src/fns.c.orig Mon Nov 30 00:13:19 1998 +++ src/fns.c Mon Nov 30 00:18:26 1998 ＠＠ -3771,15 +3771,16 ＠＠ ways these functions can blow up, and we don't want to have memory leaks in those cases. */ #define XMALLOC_OR_ALLOCA(ptr, len, type) do { \ - if ((len) > MAX_ALLOCA) \ + size_t XOA_len = (len); \ + if (XOA_len > MAX_ALLOCA) \ { \ - ptr = (type *)xmalloc ((len) * sizeof (type)); \ + ptr = (type *)xmalloc (XOA_len * sizeof (type)); \ speccount = specpdl_depth (); \ record_unwind_protect (free_malloced_ptr, \ make_opaque_ptr ((void *)ptr)); \ } \ else \ - ptr = alloca_array (type, len); \ + ptr = alloca_array (type, XOA_len); \ } while (0) #define XMALLOC_UNBIND(ptr, len) do { \ ＠＠ -3939,8 +3940,9 ＠＠ if (decoded_length < 0) { - return Qnil; + /* The decoding wasn't possible. */ XMALLOC_UNBIND (decoded, length * MAX_EMCHAR_LEN); + return Qnil; } result = make_string (decoded, decoded_length);

2 participants
1 comments

[Failure] XEmacs 21.2-b4 "Aglaophonos", i386-pc-win32 25 years, 5 months

Adrian Aichner

With this patch I was able to compile dired.c. However, filelock.c does not build under WindowsNT4sp3 with MSDS C++ 5.0. I can't find anything suspicious in src/ChangeLog. Regards, Adrian Index: dired.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs-20/src/dired.c,v retrieving revision 1.18.2.4 diff -u -r1.18.2.4 dired.c --- dired.c 1998/11/28 10:28:41 1.18.2.4 +++ dired.c 1998/11/29 21:22:17 ＠＠ -949,6 +949,7 ＠＠ DEFSUBR (Ffile_attributes); } +#ifndef WINDOWSNT void vars_of_dired (void) { ＠＠ -965,3 +966,4 ＠＠ user_cache_len = 0; user_cache_max = 0; } +#endif > XEmacs Build Report as generated > by build-report-version $Revision: 1.51 $ follows: > Contents of c:\export\home\tmp\xemacs-20\nt\Installation: > (Output from most recent run of ./configure) OS: Windows_NT XEmacs 21.2-b4 \"Aglaophonos\" configured for `i386-pc-win32'. Where should the build process find the source code? c:\\export\\home\\tmp\\xemacs-20\\nt What compiler should XEmacs be built with? ＠cl -nologo What window system should XEmacs use? MS Windows > Contents of c:\export\home\tmp\xemacs-20\nt\xemacs-20-make-all-r21-2b4-3.err > keeping lines matching > "^--\[\[\|\]\]$\|^$cd\|n?make$\s-\|errors?\|warnings?\|pure.*$space\|size$\|hides\b\|strange\|shadowings\|^Compil$ing\s-+in\|ation$\|not\s-+found\|^While\s-+compiling.*$ \s-+.+$*\|^Note:" > and then deleting lines matching > "confl.*with.*auto-inlining" cd c:\export\home\tmp\xemacs-20\nt\ nmake -f xemacs.mak PACKAGEPATH="c:\\Program Files\\XEmacs\\xemacs-packages" HAVE_MSW=1 HAVE_NATIVE_SOUND=1 HAVE_XPM=1 XPM_DIR="c:\export\home\tmp\xpm-3.4k" HAVE_PNG=1 PNG_DIR="c:\export\home\tmp\libpng-1.0.2" HAVE_TIFF=1 TIFF_DIR="c:\export\home\tmp\tiff-v3.4" HAVE_JPEG=1 JPEG_DIR="c:\export\home\tmp\jpeg-6b" ZLIB_DIR="c:\export\home\tmp\zlib" DEBUG_XEMACS=0 all Compilation started at Sun Nov 29 14:51:32 1998 Compiling in support for native GUI. Compiling in support for XPM images. Compiling in support for GIF images. Compiling in support for PNG images. Compiling in support for TIFF images. Compiling in support for JPEG images. Compiling in support for toolbars. Compiling in support for dialogs. Compiling in support for native sounds. Compiling in fast dired implementation. ..\src\filelock.c(142) : warning C4013: 'symlink' undefined; assuming extern returning int ..\src\filelock.c(174) : warning C4013: 'readlink' undefined; assuming extern returning int ..\src\filelock.c(249) : warning C4101: 'p' : unreferenced local variable ..\src\filelock.c(249) : warning C4101: 'o' : unreferenced local variable emacs.obj : error LNK2001: unresolved external symbol _vars_of_dired filelock.obj : error LNK2001: unresolved external symbol _symlink filelock.obj : error LNK2001: unresolved external symbol _rindex filelock.obj : error LNK2001: unresolved external symbol _index filelock.obj : error LNK2001: unresolved external symbol _readlink ..\src\temacs.exe : fatal error LNK1120: 5 unresolved externals NMAKE : fatal error U1077: 'link.exe' : return code '0x19' Compilation exited abnormally with code 2 at Sun Nov 29 14:52:22 -- Adrian Aichner European Design Center Teradyne GmbH Semiconductor Test Group Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 (What is a Fax?) D-81673 MUENCHEN E-mail adrian.aichner(a)teradyne.com

1 participants
0 comments

Anybody using hideif.el? Alternatives? Suggestions? 25 years, 5 months

Adrian Aichner

Hello All, while investigating my build-problems with r21-2b4 I started playing and found it not to support relational expressions. So I implementad that and it seems to work fine. However, the handling of numbers is rather peculiar. I would like to hear some feedback from authors or experienced users of hide-ifdef-mode, whether this works as it should, or what improvements would be welcomed. Where would I send my patches? Maintainer says FSF. Is there no owner for this in XEmacs? For each number occuring in an #if expression an interned symbol is created and looked up in the assoc list hide-ifdef-env to decide whether to hide that block. So, #if 0 /* Testing decimal number */ #endif #if 1 /* Testing decimal number */ #endif will be displayed as follows after M-x hide-ifdefs #if 0 ... #endif #if 1 ... #endif because the (intern "0") and (intern "1") are not found in hide-ifdef-env To display the #if 0 bit, one would M-x hide-ifdef-define RET 0 RET Hmmh, I'll have to think about this some more. Regards, Adrian -- Adrian Aichner European Design Center Teradyne GmbH Semiconductor Test Group Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 (What is a Fax?) D-81673 MUENCHEN E-mail adrian.aichner(a)teradyne.com

1 participants
0 comments

Re: Patch for linux arm support 25 years, 5 months

Martin Buchholz

>>>>> "Dres" == James LewisMoss <dres(a)ioa.com> writes: Dres> This comes from one of the Debian ARM porters. It adds a check in Dres> config.guess, an option in configure.in, and a m/arm.h file to allow Dres> compiling for Linux ARM. I didn't see anything that looks like a Dres> Debian dependency, but I may have missed it. I also don't know if Dres> this actually works (I don't have an ARM machine myself), but I'm Dres> assuming that if this person is telling me about it then he's gotten Dres> it to work on ARM. Dres> Debian ARM Maintainer: Tor Slettnes <tor(a)slett.net> Dres> ------------------------------------------------------------------------ Dres> diff -ruN xemacs20-20.4/config.guess xemacs20-20.4-7.2/config.guess Dres> --- xemacs20-20.4/config.guess Sat May 17 20:39:24 1997 Dres> +++ xemacs20-20.4-7.2/config.guess Wed Nov 25 02:39:14 1998 Dres> ＠＠ -422,6 +422,8 ＠＠ Dres> echo alpha-unknown-linux-gnu ; exit 0 Dres> elif test "${UNAME_MACHINE}" = "sparc" ; then Dres> echo sparc-unknown-linux-gnu ; exit 0 Dres> + elif test "${UNAME_MACHINE}" = "armv4l" ; then Dres> + echo arm-unknown-linux-gnu ; exit 0 Dres> else Dres> # Either a pre-BFD a.out linker (linux-gnuoldld) or one that does not give us Dres> # useful --help. Gcc wants to distinguish between linux-gnuoldld and linux-gnuaout. Thanks for your contributions. One of the next few betas for xemacs-21.2 will feature an upgrade to the latest config.guess and config.sub from FSF (/gd/gnu/lib/). That file already has support for arm machines. If there is a bug in those files, you should communicate directly with rms. Most of the XEmacs sources have forked from the FSF sources, but not config.guess and config.sub. Let's keep it that way. The rest of the arm support looks OK, although I am unhappy on the quantity of legacy cruft in the s&m headers. Martin

1 participants
0 comments

base64 suggestions 25 years, 5 months

Martin Buchholz

The Sun compiler points out that this code looks suspicious: if (decoded_length < 0) { return Qnil; XMALLOC_UNBIND (decoded, length * MAX_EMCHAR_LEN); } Also, here is a rewritten XMALLOC_OR_ALLOCA macro that avoids multiple evaluation of the `len' argument. #define XMALLOC_OR_ALLOCA(ptr, len, type) do { \ size_t XOA_len = (len); \ if (XOA_len > MAX_ALLOCA) \ { \ (ptr) = (type *)xmalloc (XOA_len * sizeof (type)); \ speccount = specpdl_depth (); \ record_unwind_protect (free_malloced_ptr, \ make_opaque_ptr ((void *)ptr)); \ } \ else \ (ptr) = alloca_array (type, XOA_len); \ } while (0) Martin

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 1998