May 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Norbert Koch

Hi, the current CVS sources can't be built on WinNT due to the followin error: ..\src\ntproc.c(691) : error C2166: l-value specifies const object The message is correct, because in function /* When a new child process is created we need to register it in our list, so intercept spawn requests. */ int sys_spawnve (int mode, CONST char *cmdname, CONST char * CONST *argv, CONST char *CONST *envp) { We have the following assignment ... /* make sure argv[0] and cmdname are both in DOS format */ unixtodos_filename ((char*)cmdname); /* #### KLUDGE */ argv[0] = cmdname; Do we absolutely need this kludge? In this case we can't use a const pointer to const char in the arglist ... Anybody? 'norbert.

2 participants
1 comments

RE: [FAILURE] 21.2.13 on WinNT 26 years

wterrylincoln＠engineer.com

I believe that a const-cast might be used to support the kludge if necessary. In Microsoft Visual C/C++ use: const_cast<char *>argv[0] = cmdname; I hope it helps. W. Terry Lincoln \ \ _ / Senior Engineer \ \ |J| / Ultimate Technology Corporation \ _|E|_ a Tridex Company (NASDAQ:trdx) \ |_ S _| mailto:WTerryLincoln＠engineer.com \ |U| http://www.AngelFire.com/ny/TerryLincoln \ / |S| \ http://www.geocities.com/Eureka/concourse/7326 \ | | ================================================ ~~~~~ Opinions expressed do not represent the management of UTC. > -----Original Message----- > From: Norbert Koch [mailto:n.koch＠delta-ii.de] > Sent: Wednesday, May 12, 1999 4:14 PM > To: xemacs-nt > Cc: XEmacs Mailing List > Subject: [FAILURE] 21.2.13 on WinNT > > > ---------------------------------------------------- > > Hi, > > the current CVS sources can't be built on WinNT due to the followin > error: > > ..\src\ntproc.c(691) : error C2166: l-value specifies const object > > The message is correct, because in function > > /* When a new child process is created we need to register it > in our list, > so intercept spawn requests. */ > int > sys_spawnve (int mode, CONST char *cmdname, > CONST char * CONST *argv, CONST char *CONST *envp) > { > > > We have the following assignment ... > > > /* make sure argv[0] and cmdname are both in DOS format */ > unixtodos_filename ((char*)cmdname); > /* #### KLUDGE */ > argv[0] = cmdname; > > Do we absolutely need this kludge? In this case we can't use a const > pointer to const char in the arglist ... > > Anybody? > 'norbert. > > [[ WARREN~1.VCF : 4406 in winmail.dat ]]

1 participants
0 comments

RE: [for 21.1.1] Patch for Patchlevels [Was 21.0-b67] 26 years

Damon Lipparelli

What is the tag for the 21.1 release? I tried release-21-1, but no joy. Thanks, -lipp -----Original Message----- From: SL Baur [mailto:steve＠xemacs.org] Sent: Wednesday, May 12, 1999 1:18 AM To: xemacs-review(a)xemacs.org; xemacs-beta(a)xemacs.org Cc: Jan Vroonhof Subject: Re: [for 21.1.1] Patch for Patchlevels [Was 21.0-b67] This patch has been committed to the 21.1 branch. Everyone who has been unhappy please test it before I make 21.1.1. I'm not sure I like the way the patch level is put into `emacs-version' -- I want it to appear as X.Y.Z, but I know there hasn't yet been consensus for that change. Jan Vroonhof <vroonhof(a)math.ethz.ch> writes in xemacs-review(a)xemacs.org: > SL Baur <steve(a)xemacs.org> writes: >> > Charles and I are now on the record as talking you in to it. >> >> Please do not change the version number. If you need a release with a >> non-beta splash screen, it should be numbered 21.1.1 with the >> beta-detection code fixed. > OK, here is the for patch that. This turns emacs_beta_version into a > patch level when emacs_is_beta is not defined. The 21.2.x release > process needs to be fixed to include that, but that is not a priority > right now. > This in a works for me stage. I need to do some real work now. I hope > somebody can take this and make 21.1.1 this weekend.

1 participants
0 comments

Re: [FAILURE] 21.2.13 on WinNT 26 years

Adrian Aichner

>>>>> "lykos" == Norbert Koch <n.koch(a)delta-ii.de> writes: I still have following problem, reported some days ago, after cvs -z3 update -P -d -r release-21-2 toolbar-msw.c ..\src\toolbar-msw.c(212) : error C2088: '+' : illegal for union NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. Compilation exited abnormally with code 2 at Wed May 12 13:57:28 Why don't oters using MSVC 6.0 not have this problem? Regards, Adrian lykos> Hi, lykos> the current CVS sources can't be built on WinNT due to the followin lykos> error: lykos> ..\src\ntproc.c(691) : error C2166: l-value specifies const object lykos> The message is correct, because in function lykos> /* When a new child process is created we need to register it in our list, lykos> so intercept spawn requests. */ lykos> int lykos> sys_spawnve (int mode, CONST char *cmdname, lykos> CONST char * CONST *argv, CONST char *CONST *envp) lykos> { lykos> We have the following assignment ... lykos> /* make sure argv[0] and cmdname are both in DOS format */ lykos> unixtodos_filename ((char*)cmdname); lykos> /* #### KLUDGE */ lykos> argv[0] = cmdname; lykos> Do we absolutely need this kludge? In this case we can't use a const lykos> pointer to const char in the arglist ... lykos> Anybody? lykos> 'norbert. -- Adrian Aichner Teradyne GmbH, European Design Center Integra Test Division 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

Fix for (Solaris) mem corruption bug 26 years

Gunnar Evermann

YES! I finally managed to fix this elusive memory corruption bug, that showed up on a couple of Solaris and HPUX builds. Akiumi Hasegawa graciously provided an account on his machine for me to debug this -- Thanks Aki! The problem was that we didn't allocate enough space for the argv[] array used for run_temacs -- somebody forgot about the trailing 0. This bug must have been there for AGES! It showed up so seldomly because DO_REALLOC doubles the existing size. In this case it will only show up when nargs=2^n-1. This also proves that all good bug-fixes are one-liners. :-) The patch is against the 21.2.13 release. This is definitely recommended for 21.1 Gunnar 1999-05-11 Gunnar Evermann <ge204(a)eng.cam.ac.uk> * emacs.c (Frun_emacs_from_temacs): (re)alloc natgs+2 entries for run_temacs_argv array -- fixes random memory corruption crash Index: src/emacs.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/emacs.c,v retrieving revision 1.82.2.10 diff -u -r1.82.2.10 emacs.c --- emacs.c 1999/03/03 16:38:47 1.82.2.10 +++ emacs.c 1999/05/11 21:40:36 ＠＠ -2014,7 +2014,7 ＠＠ total_len += wampum_all_len[ac]; } DO_REALLOC (run_temacs_args, run_temacs_args_size, total_len, char); - DO_REALLOC (run_temacs_argv, run_temacs_argv_size, nargs+1, char *); + DO_REALLOC (run_temacs_argv, run_temacs_argv_size, nargs+2, char *); memcpy (run_temacs_args, wampum, namesize); run_temacs_argv [0] = run_temacs_args;

2 participants
1 comments

[21.1.1] Also restore the minibuffer in window-configurations 26 years

Jan Vroonhof

As Gunnar reported, the window configuration patch that is in for 21.1.1 breaks resize-minibuffer as it does not do the magic for the minibuffer. Here is a patch that does that.

1 participants
0 comments

make bindist 26 years

Peter B. West

Once upon a time in the mythological past, I could `make distclean; make bindist' in my xemacs-packages directory, and a directory structure with all of the files and the gzipped packages would appear in my staging directory. This is not now working. Is this to be expected, or do I have some kind of configuration problem with my packages, possibly related to the fact that I do not have a complete set of the packages, and so I do not habitually do a `cvs update -d -P', which restores everything I have carefully blown away? Is there, btw, a way to say "just get any new directories and files within the packages that already exist here"? Yours faithfully, -- __ /__ Peter B. West p.west(a)uq.net.au / http://www.uq.net.au/~zzpwest / "Lord, to whom shall we go?"

1 participants
0 comments

Re: [for 21.1.1] Patch for Patchlevels [Was 21.0-b67] 26 years

Didier Verna

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > The problem with the x.y.z. mechanism is that there is no clear > distinction between beta's and patchlevels, unless you want to go the > linux even-odd style way (and confuse the h*ll out of everybody > because we have the even and odds swapped). That's why I always have prefered the beta state to be explicit, like in `21.2-b14'. Then, there's no ambiguousness in something like 21.2.4 and you don't have this awfull need to distinguish odds and evens. -- / / _ _ 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: 21.1 26 years

Tor Arntsen

>I would like to download the latest XEmacs 21.2 from >the CVs repository, but I do not know how. Following >the instructions from http://cvs.xemacs.org just >gives me the latest stable release, that is, >XEmacs 21.0. > >Any help? >What is the tag for release 21.1? The CVS command checkout -rr21-1-1 didn't >work, but -r21-1-0 fetched a bunch of stuff. Did I get the right stuff? The right answer to both of these questions as well as similar questions is 'cvs status -v ChangeLog' (or some other file) and look for the right branch tag. Then do something like this: cvs -z3 update -P -d -r <the name you found> -P to get rid of any empty directories, -d to check out any new directories, -r to get the right branch. >Try this in the top level directory: > >cvs -z3 update -Pd -A -r release-21-2 Er, not quite right :-) You don't want that '-A' in there, it means 'move me over to the main branch'. '-r release-21-2' does the right thing. - Tor

1 participants
0 comments

Re: [for 21.1.1] Patch for Patchlevels [Was 21.0-b67] 26 years

Jan Vroonhof

SL Baur <steve(a)xemacs.org> writes: > This patch has been committed to the 21.1 branch. Everyone who has > been unhappy please test it before I make 21.1.1. I'm not sure I like > the way the patch level is put into `emacs-version' -- I want it to > appear as X.Y.Z, but I know there hasn't yet been consensus for that > change. The problem with the x.y.z. mechanism is that there is no clear distinction between beta's and patchlevels, unless you want to go the linux even-odd style way (and confuse the h*ll out of everybody because we have the even and odds swapped). Jan

1 participants
0 comments

2025

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 May 1999