Re: PATCH: was: Re: endianness of wordcode

Re: PATCH: was: Re: endianness of wordcode

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> (1)	cd $^fpath/_cvs(|)(:h)
> 	zcompile _cvs
> 
> (2)	compinit
> 	zcompile -c _cvs _cvs
> 
> ...
> 
> (3)	compinit
> 	cvs <TAB><C-U>
> 	zcompile -c _cvs _cvs
> 
> And it also doesn't "work" to list all the helper functions explicitly.
> 
> I don't mind the discrepancy between (1) and (3) so much, but (2) and (3)
> is really unfortunate.  Maybe an additional (or simply different) option
> should be required to get the effect of (2)?

(I wasn't too sure about this anyway...)

So, this adds the -a option to zcompile which is needed to make
functions that are currently only marked for autoloading to be written 
into the zwc file. If it is not given and there is at least one name
of such a function given, zcompile will return an error (and not write 
the zwc file).

Bye
 Sven

diff -ru ../z.old/Doc/Zsh/builtins.yo Doc/Zsh/builtins.yo
--- ../z.old/Doc/Zsh/builtins.yo	Wed Mar 29 10:36:27 2000
+++ Doc/Zsh/builtins.yo	Wed Mar 29 11:11:41 2000
@@ -1304,7 +1304,7 @@
 cindex(.zwc files, creation)
 cindex(compilation)
 xitem(tt(zcompile) [ tt(-U) ] [ tt(-z) | tt(-k) ] [ tt(-R) | tt(-M) ] var(file) [ var(name) ... ])
-xitem(tt(zcompile) tt(-c) [ tt(-m) ] [ tt(-R) | tt(-M) ] var(file) [ var(name) ... ])
+xitem(tt(zcompile) tt(-c) [ tt(-ma) ] [ tt(-R) | tt(-M) ] var(file) [ var(name) ... ])
 item(tt(zcompile -t) var(file) [ var(name) ... ])(
 This builtin command can be used to compile functions or scripts and
 store the compiled form in a file, and to examine files containing
@@ -1336,13 +1336,16 @@
 
 The second form, with the tt(-c) option, writes the definitions for
 all the named functions into var(file).  The names must be functions
-currently defined in the shell or marked for autoloading.  If the
-tt(-m) option is given, too, the var(name)s are used as patterns and
-all functions whose names match one of these patterns will be
-written. If no var(name) is given, the definitions of all functions
-currently defined or marked as autoloaded will be written. In any
-case, the functions in files written with the tt(-c) option will be
-autoloaded as if the tt(KSH_AUTOLOAD) option were unset.
+currently defined in the shell.  Functions that are only marked for
+autoloading can not be written unless the tt(-a) option is given, too.
+In that case the contents of the definition files for those functions
+will be written to the var(file).  If the tt(-m) option is given, too,
+the var(name)s are used as patterns and all functions whose names
+match one of these patterns will be written. If no var(name) is given,
+the definitions of all functions currently defined or marked as
+autoloaded will be written.  In any case, the functions in files
+written with the tt(-c) option will be autoloaded as if the
+tt(KSH_AUTOLOAD) option were unset.
 
 The third form, with the tt(-t) option, examines an existing
 compiled file.  Without further arguments, the names of the original
diff -ru ../z.old/Src/builtin.c Src/builtin.c
--- ../z.old/Src/builtin.c	Wed Mar 29 10:51:11 2000
+++ Src/builtin.c	Wed Mar 29 10:58:31 2000
@@ -124,7 +124,7 @@
     BUILTIN("where", 0, bin_whence, 0, -1, 0, "pmsw", "ca"),
     BUILTIN("which", 0, bin_whence, 0, -1, 0, "ampsw", "c"),
     BUILTIN("zmodload", 0, bin_zmodload, 0, -1, 0, "ILabcfdipue", NULL),
-    BUILTIN("zcompile", 0, bin_zcompile, 0, -1, 0, "tUmrcMzk", NULL),
+    BUILTIN("zcompile", 0, bin_zcompile, 0, -1, 0, "tUMRcmzka", NULL),
 };
 
 /****************************************/
diff -ru ../z.old/Src/parse.c Src/parse.c
--- ../z.old/Src/parse.c	Wed Mar 29 10:51:13 2000
+++ Src/parse.c	Wed Mar 29 10:59:01 2000
@@ -2285,7 +2285,7 @@
 
     if ((ops['k'] && ops['z']) || (ops['R'] && ops['M']) ||
 	(ops['c'] && (ops['U'] || ops['k'] || ops['z'])) ||
-	(!ops['c'] && ops['m'])) {
+	(!ops['c'] && (ops['m'] || ops['a']))) {
 	zwarnnam(nam, "illegal combination of options", NULL, 0);
 	return 1;
     }
@@ -2333,7 +2333,8 @@
 
     dump = (strsfx(FD_EXT, *args) ? *args : dyncat(*args, FD_EXT));
 
-    return (ops['c'] ? build_cur_dump(nam, dump, args + 1, ops['m'], map) :
+    return (ops['c'] ?
+	    build_cur_dump(nam, dump, args + 1, ops['m'], map, ops['a']) :
 	    build_dump(nam, dump, args + 1, ops['U'], map, flags));
 }
 
@@ -2556,7 +2557,7 @@
 
 static int
 cur_add_func(Shfunc shf, LinkList names, LinkList progs,
-	     int *hlen, int *tlen)
+	     int *hlen, int *tlen, int autol)
 {
     Eprog prog;
     WCFunc wcf;
@@ -2564,6 +2565,9 @@
     if (shf->flags & PM_UNDEFINED) {
 	int ona = noaliases;
 
+	if (!autol)
+	    return 2;
+
 	noaliases = (shf->flags & PM_UNALIASED);
 	if (!(prog = getfpfunc(shf->nam, NULL)) || prog == &dummy_eprog) {
 	    noaliases = ona;
@@ -2593,9 +2597,10 @@
 
 /**/
 static int
-build_cur_dump(char *nam, char *dump, char **names, int match, int map)
+build_cur_dump(char *nam, char *dump, char **names, int match, int map,
+	       int autol)
 {
-    int dfd, hlen, tlen;
+    int dfd, hlen, tlen, err;
     LinkList progs, lnames;
     Shfunc shf = NULL;
 
@@ -2618,9 +2623,10 @@
 
 	for (i = 0; i < shfunctab->hsize; i++)
 	    for (hn = shfunctab->nodes[i]; hn; hn = hn->next)
-		if (cur_add_func((Shfunc) hn, lnames, progs,
-				 &hlen, &tlen)) {
-		    zwarnnam(nam, "can't load function: %s", shf->nam, 0);
+		if ((err = cur_add_func((Shfunc) hn, lnames, progs,
+					&hlen, &tlen, autol))) {
+		    zwarnnam(nam, (err == 1 ? "can't load function: %s" :
+				   "function is not loaded: %s"), shf->nam, 0);
 		    errflag = 0;
 		    close(dfd);
 		    unlink(dump);
@@ -2644,9 +2650,10 @@
 		for (hn = shfunctab->nodes[i]; hn; hn = hn->next)
 		    if (!listcontains(lnames, hn->nam) &&
 			pattry(pprog, hn->nam) &&
-			cur_add_func((Shfunc) hn, lnames, progs,
-				     &hlen, &tlen)) {
-			zwarnnam(nam, "can't load function: %s", shf->nam, 0);
+			(err = cur_add_func((Shfunc) hn, lnames, progs,
+					    &hlen, &tlen, autol))) {
+			zwarnnam(nam, (err == 1 ? "can't load function: %s" :
+				       "function is not loaded: %s"), shf->nam, 0);
 			errflag = 0;
 			close(dfd);
 			unlink(dump);
@@ -2663,8 +2670,9 @@
 		unlink(dump);
 		return 1;
 	    }
-	    if (cur_add_func(shf, lnames, progs, &hlen, &tlen)) {
-		zwarnnam(nam, "can't load function: %s", shf->nam, 0);
+	    if ((err = cur_add_func(shf, lnames, progs, &hlen, &tlen, autol))) {
+		zwarnnam(nam, (err == 1 ? "can't load function: %s" :
+			       "function is not loaded: %s"), shf->nam, 0);
 		errflag = 0;
 		close(dfd);
 		unlink(dump);

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: was: Re: endianness of wordcode

[Bart Schaefer]

On Mar 29, 11:14am, Sven Wischnowsky wrote:
} Subject: Re: PATCH: was: Re: endianness of wordcode
}
} So, this adds the -a option to zcompile which is needed to make
} functions that are currently only marked for autoloading to be written 
} into the zwc file. If it is not given and there is at least one name
} of such a function given, zcompile will return an error (and not write 
} the zwc file).

This is still a bit odd, because it means you have to check yourself
whether a function is defined or undefined before you know what result
"zcompile -a -c ..." is going to produce.  I'd rather that you simply
CAN'T compile both defined and undefined functions in the same pass.

Anybody else want to weigh in on this?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: PATCH: was: Re: endianness of wordcode

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Mar 31,  9:06am, Sven Wischnowsky wrote:
> } Subject: Re: PATCH: was: Re: endianness of wordcode
> }
> } Or maybe make `-a' the opposite of `-c'? I.e. `-c' says that currently 
> } defined (not marked for autoloading) functions are to be written and
> } `-a' says functions marked for autoloading are to be written. We could 
> } then say `...to be written without signalling an error', so that `-ca' 
> } allows to mix both
> 
> That would be fine.  (Note, I'm not "everyone" ...)

Since it allows everything that was possible before, just giving more
security...

> } And then we can add a description of the _cvs problem in the manual,
> } so that people know why using this might be a problem.
> 
> That would be good, too.

I hope I made that clear enough in the patch...

Bye
 Sven

diff -ru ../z.old/Doc/Zsh/builtins.yo Doc/Zsh/builtins.yo
--- ../z.old/Doc/Zsh/builtins.yo	Fri Mar 31 14:34:18 2000
+++ Doc/Zsh/builtins.yo	Fri Mar 31 14:57:17 2000
@@ -1304,7 +1304,7 @@
 cindex(.zwc files, creation)
 cindex(compilation)
 xitem(tt(zcompile) [ tt(-U) ] [ tt(-z) | tt(-k) ] [ tt(-R) | tt(-M) ] var(file) [ var(name) ... ])
-xitem(tt(zcompile) tt(-c) [ tt(-ma) ] [ tt(-R) | tt(-M) ] var(file) [ var(name) ... ])
+xitem(tt(zcompile) tt(-ca) [ tt(-m) ] [ tt(-R) | tt(-M) ] var(file) [ var(name) ... ])
 item(tt(zcompile -t) var(file) [ var(name) ... ])(
 This builtin command can be used to compile functions or scripts and
 store the compiled form in a file, and to examine files containing
@@ -1312,7 +1312,7 @@
 execution of scripts by avoiding parsing of the text when the files
 are read.
 
-The first form (without the tt(-c) or tt(-t) options) creates a
+The first form (without the tt(-c), tt(-a) or tt(-t) options) creates a
 compiled file.  If only the var(file) argument is provided, the
 output file has the name `var(file)tt(.zwc)' and will be placed in
 the same directory as the var(file).  This will make the compiled
@@ -1334,18 +1334,33 @@
 and are intended to be used as elements of the tt(FPATH)/tt(fpath)
 special array.
 
-The second form, with the tt(-c) option, writes the definitions for
-all the named functions into var(file).  The names must be functions
-currently defined in the shell.  Functions that are only marked for
-autoloading can not be written unless the tt(-a) option is given, too.
-In that case the contents of the definition files for those functions
-will be written to the var(file).  If the tt(-m) option is given, too,
+The second form, with the tt(-c) or tt(-a) option, writes the
+definitions for all the named functions into var(file).  For tt(-c),
+the names must be functions currently defined in the shell, not only
+marked for autoloading.  Functions that are only marked for
+autoloading can be written by using the tt(-a) option. If both tt(-c)
+and tt(-a) are given, a mixture of defined functions and functions
+marked for autoloading may be given. In the case of functions marked
+for autoloading, the contents of the definition files for those
+functions will be written to the var(file).  In any case, the
+functions in files written with the tt(-c) or tt(-a) option will be
+autoloaded as if the tt(KSH_AUTOLOAD) option were unset.
+
+The reason for making loaded and not-yet loaded functions be handled
+by different options is that some definition files for autoloaded
+define multiple functions including the function currently loaded
+itself and, at the end, call this function. In such cases the
+resulting zwc file will be different in the two cases (function is
+already loaded or not). In particular, if it is already loaded, the
+other functions defined in the file are not automatically written into 
+the zwc file and, of course, any other initialization code in the file 
+will be lost.
+
+If the tt(-m) option is combined with tt(-c) or tt(-a),
 the var(name)s are used as patterns and all functions whose names
 match one of these patterns will be written. If no var(name) is given,
 the definitions of all functions currently defined or marked as
-autoloaded will be written.  In any case, the functions in files
-written with the tt(-c) option will be autoloaded as if the
-tt(KSH_AUTOLOAD) option were unset.
+autoloaded will be written.
 
 The third form, with the tt(-t) option, examines an existing
 compiled file.  Without further arguments, the names of the original
diff -ru ../z.old/Src/parse.c Src/parse.c
--- ../z.old/Src/parse.c	Fri Mar 31 14:34:07 2000
+++ Src/parse.c	Fri Mar 31 14:58:22 2000
@@ -2285,11 +2285,11 @@
 
     if ((ops['k'] && ops['z']) || (ops['R'] && ops['M']) ||
 	(ops['c'] && (ops['U'] || ops['k'] || ops['z'])) ||
-	(!ops['c'] && (ops['m'] || ops['a']))) {
+	(!(ops['c'] || ops['a']) && ops['m'])) {
 	zwarnnam(nam, "illegal combination of options", NULL, 0);
 	return 1;
     }
-    if (ops['c'] && isset(KSHAUTOLOAD))
+    if ((ops['c'] || ops['a']) && isset(KSHAUTOLOAD))
 	zwarnnam(nam, "functions will use zsh style autoloading", NULL, 0);
 
     flags = (ops['k'] ? FDHF_KSHLOAD :
@@ -2328,13 +2328,14 @@
     }
     map = (ops['M'] ? 2 : (ops['R'] ? 0 : 1));
 
-    if (!args[1] && !ops['c'])
+    if (!args[1] && !(ops['c'] || ops['a']))
 	return build_dump(nam, dyncat(*args, FD_EXT), args, ops['U'], map, flags);
 
     dump = (strsfx(FD_EXT, *args) ? *args : dyncat(*args, FD_EXT));
 
-    return (ops['c'] ?
-	    build_cur_dump(nam, dump, args + 1, ops['m'], map, ops['a']) :
+    return ((ops['c'] || ops['a']) ?
+	    build_cur_dump(nam, dump, args + 1, ops['m'], map,
+			   (ops['c'] ? 1 : 0) | (ops['a'] ? 2 : 0)) :
 	    build_dump(nam, dump, args + 1, ops['U'], map, flags));
 }
 
@@ -2556,8 +2557,8 @@
 }
 
 static int
-cur_add_func(Shfunc shf, LinkList names, LinkList progs,
-	     int *hlen, int *tlen, int autol)
+cur_add_func(char *nam, Shfunc shf, LinkList names, LinkList progs,
+	     int *hlen, int *tlen, int what)
 {
     Eprog prog;
     WCFunc wcf;
@@ -2565,21 +2566,26 @@
     if (shf->flags & PM_UNDEFINED) {
 	int ona = noaliases;
 
-	if (!autol)
-	    return 2;
-
+	if (!(what & 2)) {
+	    zwarnnam(nam, "function is not loaded: %s", shf->nam, 0);
+	    return 1;
+	}
 	noaliases = (shf->flags & PM_UNALIASED);
 	if (!(prog = getfpfunc(shf->nam, NULL)) || prog == &dummy_eprog) {
 	    noaliases = ona;
-
+	    zwarnnam(nam, "can't load function: %s", shf->nam, 0);
 	    return 1;
 	}
 	if (prog->dump)
 	    prog = dupeprog(prog, 1);
 	noaliases = ona;
-    } else
+    } else {
+	if (!(what & 1)) {
+	    zwarnnam(nam, "function is already loaded: %s", shf->nam, 0);
+	    return 1;
+	}
 	prog = dupeprog(shf->funcdef, 1);
-
+    }
     wcf = (WCFunc) zhalloc(sizeof(*wcf));
     wcf->name = shf->nam;
     wcf->prog = prog;
@@ -2598,9 +2604,9 @@
 /**/
 static int
 build_cur_dump(char *nam, char *dump, char **names, int match, int map,
-	       int autol)
+	       int what)
 {
-    int dfd, hlen, tlen, err;
+    int dfd, hlen, tlen;
     LinkList progs, lnames;
     Shfunc shf = NULL;
 
@@ -2623,10 +2629,8 @@
 
 	for (i = 0; i < shfunctab->hsize; i++)
 	    for (hn = shfunctab->nodes[i]; hn; hn = hn->next)
-		if ((err = cur_add_func((Shfunc) hn, lnames, progs,
-					&hlen, &tlen, autol))) {
-		    zwarnnam(nam, (err == 1 ? "can't load function: %s" :
-				   "function is not loaded: %s"), shf->nam, 0);
+		if (cur_add_func(nam, (Shfunc) hn, lnames, progs,
+				 &hlen, &tlen, what)) {
 		    errflag = 0;
 		    close(dfd);
 		    unlink(dump);
@@ -2650,10 +2654,8 @@
 		for (hn = shfunctab->nodes[i]; hn; hn = hn->next)
 		    if (!listcontains(lnames, hn->nam) &&
 			pattry(pprog, hn->nam) &&
-			(err = cur_add_func((Shfunc) hn, lnames, progs,
-					    &hlen, &tlen, autol))) {
-			zwarnnam(nam, (err == 1 ? "can't load function: %s" :
-				       "function is not loaded: %s"), shf->nam, 0);
+			cur_add_func(nam, (Shfunc) hn, lnames, progs,
+				     &hlen, &tlen, what)) {
 			errflag = 0;
 			close(dfd);
 			unlink(dump);
@@ -2670,9 +2672,7 @@
 		unlink(dump);
 		return 1;
 	    }
-	    if ((err = cur_add_func(shf, lnames, progs, &hlen, &tlen, autol))) {
-		zwarnnam(nam, (err == 1 ? "can't load function: %s" :
-			       "function is not loaded: %s"), shf->nam, 0);
+	    if (cur_add_func(nam, shf, lnames, progs, &hlen, &tlen, what)) {
 		errflag = 0;
 		close(dfd);
 		unlink(dump);

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: was: Re: endianness of wordcode

[Bart Schaefer]

On Mar 31,  3:00pm, Sven Wischnowsky wrote:
} Subject: Re: PATCH: was: Re: endianness of wordcode
}
} > } And then we can add a description of the _cvs problem in the manual,
} > } so that people know why using this might be a problem.
} > 
} > That would be good, too.
} 
} I hope I made that clear enough in the patch...

I reworded it just a little.  The diff looks bigger because I hit alt-Q in
emacs to refill the paragraphs ...

Index: builtins.yo
===================================================================
RCS file: /extra/cvsroot/zsh/zsh-3.1/Doc/Zsh/builtins.yo,v
retrieving revision 1.64
diff -c -r1.64 builtins.yo
--- builtins.yo	2000/03/31 16:35:40	1.64
+++ builtins.yo	2000/03/31 16:53:50
@@ -1334,27 +1334,25 @@
 and are intended to be used as elements of the tt(FPATH)/tt(fpath)
 special array.
 
-The second form, with the tt(-c) or tt(-a) option, writes the
-definitions for all the named functions into var(file).  For tt(-c),
-the names must be functions currently defined in the shell, not only
-marked for autoloading.  Functions that are only marked for
-autoloading can be written by using the tt(-a) option. If both tt(-c)
-and tt(-a) are given, a mixture of defined functions and functions
-marked for autoloading may be given. In the case of functions marked
-for autoloading, the contents of the definition files for those
-functions will be written to the var(file).  In any case, the
-functions in files written with the tt(-c) or tt(-a) option will be
-autoloaded as if the tt(KSH_AUTOLOAD) option were unset.
+The second form, with the tt(-c) or tt(-a) options, writes the compiled
+definitions for all the named functions into var(file).  For tt(-c), the
+names must be functions currently defined in the shell, not those marked
+for autoloading.  Undefined functions that are marked for autoloading
+may be written by using the tt(-a) option, in which case the tt(fpath)
+is searched and the contents of the definition files for those
+functions, if found, are compiled into var(file).  If both tt(-c) and
+tt(-a) are given, names of both defined functions and functions marked
+for autoloading may be given.  In either case, the functions in files
+written with the tt(-c) or tt(-a) option will be autoloaded as if the
+tt(KSH_AUTOLOAD) option were unset.
 
-The reason for making loaded and not-yet loaded functions be handled
-by different options is that some definition files for autoloaded
-define multiple functions including the function currently loaded
-itself and, at the end, call this function. In such cases the
-resulting zwc file will be different in the two cases (function is
-already loaded or not). In particular, if it is already loaded, the
-other functions defined in the file are not automatically written into 
-the zwc file and, of course, any other initialization code in the file 
-will be lost.
+The reason for handling loaded and not-yet-loaded functions with
+different options is that some definition files for autoloading define
+multiple functions, including the function with the same name as the
+file, and, at the end, call that function.  In such cases the output of
+`tt(zcompile -c)' does not include the additional functions defined in
+the file, and any other initialization code in the file is lost.  Using
+`tt(zcompile -a)' captures all this extra information.
 
 If the tt(-m) option is combined with tt(-c) or tt(-a),
 the var(name)s are used as patterns and all functions whose names

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: PATCH: was: Re: endianness of wordcode

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Mar 30, 12:56pm, Sven Wischnowsky wrote:
> } Subject: Re: PATCH: was: Re: endianness of wordcode
> }
> } 
> } Bart Schaefer wrote:
> } 
> } > On Mar 29, 11:14am, Sven Wischnowsky wrote:
> } > } Subject: Re: PATCH: was: Re: endianness of wordcode
> } > }
> } > } So, this adds the -a option to zcompile which is needed to make
> } > } functions that are currently only marked for autoloading to be written 
> } > 
> } > This is still a bit odd, because it means you have to check yourself
> } > whether a function is defined or undefined before you know what result
> } > "zcompile -a -c ..." is going to produce.  I'd rather that you simply
> } > CAN'T compile both defined and undefined functions in the same pass.
> } 
> } Hm. Consider someone who has all his functions autoloaded (i.e. none
> } defined in .zshrc or other init files) and doesn't use kshautoload.
> } With the current state he can do `zcompile -ca all-funcs' to write them
> } all into one file. If we disallow compiling both already-loaded and
> } not-yet-loaded functions `in the same pass', it is impossible to do
> } that if at least one of the functions happens to be loaded already.
> 
> But that user will still get the wrong result if e.g. _cvs is one of the
> functions that happens to be loaded already.  Isn't it better to have to
> expend slightly more effort to get consistent and correct results than to
> easily be able produce an inconsistent and sometimes incorrect results?
> 
> Even something as simple as searching $fpath and printing a warning when
> a file with the same name as an already-loaded function is found, would
> be preferable to silently doing the wrong thing.  (That warning would be
> printed only when -a is given, of course.)

I'm starting to give in...

So, make `-a' the opposite of not-`-a', i.e. barf when there are
names of function not still makred for autoloading. Yes?

Or maybe make `-a' the opposite of `-c'? I.e. `-c' says that currently 
defined (not marked for autoloading) functions are to be written and
`-a' says functions marked for autoloading are to be written. We could 
then say `...to be written without signalling an error', so that `-ca' 
allows to mix both (I think I really want a way to do that, but it's
ok for me to make it as far from the default as possible). And then we 
can add a description of the _cvs problem in the manual, so that
people know why using this might be a problem.

Would that be acceptable for everyone?

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: was: Re: endianness of wordcode

[Bart Schaefer]

On Mar 31,  9:06am, Sven Wischnowsky wrote:
} Subject: Re: PATCH: was: Re: endianness of wordcode
}
} Or maybe make `-a' the opposite of `-c'? I.e. `-c' says that currently 
} defined (not marked for autoloading) functions are to be written and
} `-a' says functions marked for autoloading are to be written. We could 
} then say `...to be written without signalling an error', so that `-ca' 
} allows to mix both

That would be fine.  (Note, I'm not "everyone" ...)

} And then we can add a description of the _cvs problem in the manual,
} so that people know why using this might be a problem.

That would be good, too.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: PATCH: was: Re: endianness of wordcode

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Mar 29, 11:14am, Sven Wischnowsky wrote:
> } Subject: Re: PATCH: was: Re: endianness of wordcode
> }
> } So, this adds the -a option to zcompile which is needed to make
> } functions that are currently only marked for autoloading to be written 
> } into the zwc file. If it is not given and there is at least one name
> } of such a function given, zcompile will return an error (and not write 
> } the zwc file).
> 
> This is still a bit odd, because it means you have to check yourself
> whether a function is defined or undefined before you know what result
> "zcompile -a -c ..." is going to produce.  I'd rather that you simply
> CAN'T compile both defined and undefined functions in the same pass.

Hm. Consider someone who has all his functions autoloaded (i.e. none
defined in .zshrc or other init files) and doesn't use kshautoload.
With the current state he can do `zcompile -ca all-funcs' to write them
all into one file. If we disallow compiling both already-loaded and
not-yet-loaded functions `in the same pass', it is impossible to do
that if at least one of the functions happens to be loaded already.

At least until we add a helper function that allows merging wordcode
files, like the one you suggested a while ago.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: was: Re: endianness of wordcode

[Bart Schaefer]

On Mar 30, 12:56pm, Sven Wischnowsky wrote:
} Subject: Re: PATCH: was: Re: endianness of wordcode
}
} 
} Bart Schaefer wrote:
} 
} > On Mar 29, 11:14am, Sven Wischnowsky wrote:
} > } Subject: Re: PATCH: was: Re: endianness of wordcode
} > }
} > } So, this adds the -a option to zcompile which is needed to make
} > } functions that are currently only marked for autoloading to be written 
} > 
} > This is still a bit odd, because it means you have to check yourself
} > whether a function is defined or undefined before you know what result
} > "zcompile -a -c ..." is going to produce.  I'd rather that you simply
} > CAN'T compile both defined and undefined functions in the same pass.
} 
} Hm. Consider someone who has all his functions autoloaded (i.e. none
} defined in .zshrc or other init files) and doesn't use kshautoload.
} With the current state he can do `zcompile -ca all-funcs' to write them
} all into one file. If we disallow compiling both already-loaded and
} not-yet-loaded functions `in the same pass', it is impossible to do
} that if at least one of the functions happens to be loaded already.

But that user will still get the wrong result if e.g. _cvs is one of the
functions that happens to be loaded already.  Isn't it better to have to
expend slightly more effort to get consistent and correct results than to
easily be able produce an inconsistent and sometimes incorrect results?

Even something as simple as searching $fpath and printing a warning when
a file with the same name as an already-loaded function is found, would
be preferable to silently doing the wrong thing.  (That warning would be
printed only when -a is given, of course.)

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

PATCH: was: Re: endianness of wordcode

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Mar 27,  1:43pm, Sven Wischnowsky wrote:
> } Subject: Re: endianness of wordcode
> }
> } Bart Schaefer wrote:
> } 
> } > In particular
> } > I'm not sure how to explain what happens if you do
> } > 
> } > 	zcompile -c foo foo bar frob ding
> } > 	fpath=($PWD)
> } > 	autoload foo
> } > 	foo
>
> ...
> 
> The question in this first case is:  `bar', `frob' and `ding' do not
> become available when foo is autoloaded, but why not?  If I had a text
> (not .zwc) file named `foo' inside a directory in $fpath, and that
> file contained four functions, and I said to autoload foo and then I
> executed foo, all four functions would become defined.
> 
> If I'd said `fpath=($PWD/foo)' so that foo.zwc was treated like a
> directory, I'd expect only `foo' to be searched out of it; but since
> `foo' is *inside* a directory in $fpath, I expected it to be treated
> like a script.  (Well, *I* didn't, but I'm trying to think like a
> newbie.)

Maybe it would be clearer if we made people pay more attention to the
files. Because: if I have a couple of function definition files,
containing the functions foo, bar, frob and ding (in $PWD) and I do

  fpath=($PWD)
  autoload foo
  foo

this makes available (and before that: autoloaded(!)) only foo. And
with a zwc file it's just the same. If one doesn't say that bar, frob
and ding are to be autoloaded and/or doesn't tell the shell where to
find the definitions for them, they won't be autoloaded (of course ;-).
And the things you wrote in func.yo make it quite clear, how zwc files 
are searched for functions, so `fpath=($PWD)' without files like
bar.zwc in $PWD doesn't tell the shell where to find the
file/definition for bar, frob, ding.

Hm, dunno if that would help...

> ...
> 
> Given this, I think we should just make -k not work at all with -c, and
> ignore kshautoload on -c as well, i.e. -c always behaves as if -z.  If
> -k is given, stop with an error, and if kshautoload is set, print an
> informative warning message but write the file anyway.

The patch does this and it also swaps -[rm] and -M. I.e. -R is for
`make zwc file be read', -M for `make it be mapped' and -m is for
`make names be used as patterns with the -c option'.

Bye
 Sven

diff -ru ../z.old/Doc/Zsh/builtins.yo Doc/Zsh/builtins.yo
--- ../z.old/Doc/Zsh/builtins.yo	Tue Mar 28 13:41:06 2000
+++ Doc/Zsh/builtins.yo	Tue Mar 28 14:12:31 2000
@@ -1303,8 +1303,8 @@
 findex(zcompile)
 cindex(.zwc files, creation)
 cindex(compilation)
-xitem(tt(zcompile) [ tt(-U) ] [ tt(-z) | tt(-k) ] [ tt(-r) | tt(-m) ] var(file) [ var(name) ... ])
-xitem(tt(zcompile) tt(-c) [ tt(-M) ] [ tt(-z) | tt(-k) ] [ tt(-r) | tt(-m) ] var(file) [ var(name) ... ])
+xitem(tt(zcompile) [ tt(-U) ] [ tt(-z) | tt(-k) ] [ tt(-R) | tt(-M) ] var(file) [ var(name) ... ])
+xitem(tt(zcompile) tt(-c) [ tt(-m) ] [ tt(-R) | tt(-M) ] var(file) [ var(name) ... ])
 item(tt(zcompile -t) var(file) [ var(name) ... ])(
 This builtin command can be used to compile functions or scripts and
 store the compiled form in a file, and to examine files containing
@@ -1337,10 +1337,12 @@
 The second form, with the tt(-c) option, writes the definitions for
 all the named functions into var(file).  The names must be functions
 currently defined in the shell or marked for autoloading.  If the
-tt(-M) option is given, too, the var(name)s are used as patterns and
+tt(-m) option is given, too, the var(name)s are used as patterns and
 all functions whose names match one of these patterns will be
 written. If no var(name) is given, the definitions of all functions
-currently defined or marked as autoloaded will be written.
+currently defined or marked as autoloaded will be written. In any
+case, the functions in files written with the tt(-c) option will be
+autoloaded as if the tt(KSH_AUTOLOAD) option were unset.
 
 The third form, with the tt(-t) option, examines an existing
 compiled file.  Without further arguments, the names of the original
@@ -1357,9 +1359,9 @@
 item(tt(-U))(
 Aliases are not expanded when compiling the var(name)d files.
 )
-item(tt(-r))(
+item(tt(-R))(
 When the compiled file is read, its contents are copied into the
-shell's memory, rather than memory-mapped (see tt(-m)).  This
+shell's memory, rather than memory-mapped (see tt(-M)).  This
 happens automatically on systems that do not support memory mapping.
 
 When compiling scripts instead of autoloadable functions, it is
@@ -1367,22 +1369,22 @@
 remain mapped if the script has defined one or more functions, even
 if the rest of the file will not be used again.
 )
-item(tt(-m))(
+item(tt(-M))(
 The compiled file is mapped into the shell's memory when read. This
 is done in such a way that multiple instances of the shell running
-on the same host will share this mapped file.  If neither tt(-r) nor
-tt(-m) is given, the tt(zcompile) builtin decides what to do based
+on the same host will share this mapped file.  If neither tt(-R) nor
+tt(-M) is given, the tt(zcompile) builtin decides what to do based
 on the size of the compiled file.
 )
 xitem(tt(-k))
 item(tt(-z))(
 These options are used when the compiled file contains functions and
 those functions are to be autoloaded. If tt(-z) is given, the
-function will be autoloaded as if the tt(KSHAUTOLOAD) option is
+function will be autoloaded as if the tt(KSH_AUTOLOAD) option is
 em(not) set, even if it is set at the time the compiled file is
-read. The tt(-k) makes the function be loaded as if tt(KASHAUTOLOAD)
+read. The tt(-k) makes the function be loaded as if tt(KSH_AUTOLOAD)
 em(is) set.  If neither of these options is given, the function will
-be loaded as determined by the setting of the tt(KSHAUTOLOAD) option
+be loaded as determined by the setting of the tt(KSH_AUTOLOAD) option
 at the time the compiled file is read.
 
 These options may also be repeated among the listed var(name)s to
diff -ru ../z.old/Functions/Misc/zrecompile Functions/Misc/zrecompile
--- ../z.old/Functions/Misc/zrecompile	Tue Mar 28 13:41:49 2000
+++ Functions/Misc/zrecompile	Tue Mar 28 14:31:44 2000
@@ -18,8 +18,8 @@
 #       seperated by `--'. For example:
 #
 #         zrecompile -p \
-#                    -r ~/.zshrc -- \
-#                    -m ~/.zcompdump -- \
+#                    -R ~/.zshrc -- \
+#                    -M ~/.zcompdump -- \
 #                    ~/zsh/comp.zwc ~/zsh/Completion/*/_* \
 #
 #       This makes ~/.zshrc be compiled into ~/.zshrc.zwc if that doesn't
@@ -146,10 +146,10 @@
   # See if the wordcode file will be mapped.
 
   if [[ $files[1] = *\(mapped\)* ]]; then
-    map=-m
+    map=-M
     mesg='succeeded (old saved)'
   else
-    map=-r
+    map=-R
     mesg=succeeded
   fi
 
diff -ru ../z.old/Src/parse.c Src/parse.c
--- ../z.old/Src/parse.c	Tue Mar 28 13:40:58 2000
+++ Src/parse.c	Tue Mar 28 14:28:44 2000
@@ -2283,10 +2283,15 @@
     int map, flags;
     char *dump;
 
-    if (ops['k'] && ops['z']) {
+    if ((ops['k'] && ops['z']) || (ops['R'] && ops['M']) ||
+	(ops['c'] && (ops['U'] || ops['k'] || ops['z'])) ||
+	(!ops['c'] && ops['m'])) {
 	zwarnnam(nam, "illegal combination of options", NULL, 0);
 	return 1;
     }
+    if (ops['c'] && isset(KSHAUTOLOAD))
+	zwarnnam(nam, "functions will use zsh style autoloading", NULL, 0);
+
     flags = (ops['k'] ? FDHF_KSHLOAD :
 	     (ops['z'] ? FDHF_ZSHLOAD : 0));
 
@@ -2321,18 +2326,14 @@
 	zwarnnam(nam, "too few arguments", NULL, 0);
 	return 1;
     }
-    if ((ops['c'] && ops['U']) || (!ops['c'] && ops['M'])) {
-	zwarnnam(nam, "illegal combination of options", NULL, 0);
-	return 1;
-    }
-    map = (ops['m'] ? 2 : (ops['r'] ? 0 : 1));
+    map = (ops['M'] ? 2 : (ops['R'] ? 0 : 1));
 
     if (!args[1] && !ops['c'])
 	return build_dump(nam, dyncat(*args, FD_EXT), args, ops['U'], map, flags);
 
     dump = (strsfx(FD_EXT, *args) ? *args : dyncat(*args, FD_EXT));
 
-    return (ops['c'] ? build_cur_dump(nam, dump, args + 1, ops['M'], map, flags) :
+    return (ops['c'] ? build_cur_dump(nam, dump, args + 1, ops['m'], map) :
 	    build_dump(nam, dump, args + 1, ops['U'], map, flags));
 }
 
@@ -2533,7 +2534,7 @@
 	wcf = (WCFunc) zhalloc(sizeof(*wcf));
 	wcf->name = *files;
 	wcf->prog = prog;
-	wcf->flags = flags;
+	wcf->flags = ((prog->flags & EF_RUN) ? FDHF_KSHLOAD : flags);
 	addlinknode(progs, wcf);
 
 	flen = (strlen(*files) + sizeof(wordcode)) / sizeof(wordcode);
@@ -2555,7 +2556,7 @@
 
 static int
 cur_add_func(Shfunc shf, LinkList names, LinkList progs,
-	     int *hlen, int *tlen, int flags)
+	     int *hlen, int *tlen)
 {
     Eprog prog;
     WCFunc wcf;
@@ -2578,7 +2579,7 @@
     wcf = (WCFunc) zhalloc(sizeof(*wcf));
     wcf->name = shf->nam;
     wcf->prog = prog;
-    wcf->flags = flags;
+    wcf->flags = ((prog->flags & EF_RUN) ? FDHF_KSHLOAD : FDHF_ZSHLOAD);
     addlinknode(progs, wcf);
     addlinknode(names, shf->nam);
 
@@ -2592,7 +2593,7 @@
 
 /**/
 static int
-build_cur_dump(char *nam, char *dump, char **names, int match, int map, int flags)
+build_cur_dump(char *nam, char *dump, char **names, int match, int map)
 {
     int dfd, hlen, tlen;
     LinkList progs, lnames;
@@ -2618,7 +2619,7 @@
 	for (i = 0; i < shfunctab->hsize; i++)
 	    for (hn = shfunctab->nodes[i]; hn; hn = hn->next)
 		if (cur_add_func((Shfunc) hn, lnames, progs,
-				 &hlen, &tlen, flags)) {
+				 &hlen, &tlen)) {
 		    zwarnnam(nam, "can't load function: %s", shf->nam, 0);
 		    errflag = 0;
 		    close(dfd);
@@ -2632,13 +2633,6 @@
 	HashNode hn;
 
 	for (; *names; names++) {
-	    if (!strcmp(*names, "-k")) {
-		flags = (flags & ~(FDHF_KSHLOAD | FDHF_ZSHLOAD)) | FDHF_KSHLOAD;
-		continue;
-	    } else if (!strcmp(*names, "-z")) {
-		flags = (flags & ~(FDHF_KSHLOAD | FDHF_ZSHLOAD)) | FDHF_ZSHLOAD;
-		continue;
-	    }
 	    tokenize(pat = dupstring(*names));
 	    if (!(pprog = patcompile(pat, PAT_STATIC, NULL))) {
 		zwarnnam(nam, "bad pattern: %s", *names, 0);
@@ -2651,7 +2645,7 @@
 		    if (!listcontains(lnames, hn->nam) &&
 			pattry(pprog, hn->nam) &&
 			cur_add_func((Shfunc) hn, lnames, progs,
-				     &hlen, &tlen, flags)) {
+				     &hlen, &tlen)) {
 			zwarnnam(nam, "can't load function: %s", shf->nam, 0);
 			errflag = 0;
 			close(dfd);
@@ -2661,13 +2655,6 @@
 	}
     } else {
 	for (; *names; names++) {
-	    if (!strcmp(*names, "-k")) {
-		flags = (flags & ~(FDHF_KSHLOAD | FDHF_ZSHLOAD)) | FDHF_KSHLOAD;
-		continue;
-	    } else if (!strcmp(*names, "-z")) {
-		flags = (flags & ~(FDHF_KSHLOAD | FDHF_ZSHLOAD)) | FDHF_ZSHLOAD;
-		continue;
-	    }
 	    if (errflag ||
 		!(shf = (Shfunc) shfunctab->getnode(shfunctab, *names))) {
 		zwarnnam(nam, "unknown function: %s", *names, 0);
@@ -2676,7 +2663,7 @@
 		unlink(dump);
 		return 1;
 	    }
-	    if (cur_add_func(shf, lnames, progs, &hlen, &tlen, flags)) {
+	    if (cur_add_func(shf, lnames, progs, &hlen, &tlen)) {
 		zwarnnam(nam, "can't load function: %s", shf->nam, 0);
 		errflag = 0;
 		close(dfd);

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: was: Re: endianness of wordcode

[Bart Schaefer]

On Mar 28,  2:32pm, Sven Wischnowsky wrote:
} Subject: PATCH: was: Re: endianness of wordcode
}
} > } > 	zcompile -c foo foo bar frob ding
[then in a new shell]
} > } > 	fpath=($PWD)
} > } > 	autoload foo
} > } > 	foo
} >
} > ...
} > 
} > The question in this first case is:  `bar', `frob' and `ding' do not
} > become available when foo is autoloaded, but why not?  If I had a text
} > (not .zwc) file named `foo' inside a directory in $fpath, and that
} > file contained four functions, and I said to autoload foo and then I
} > executed foo, all four functions would become defined.
} 
} Maybe it would be clearer if we made people pay more attention to the
} files. Because: if I have a couple of function definition files,
} containing the functions foo, bar, frob and ding (in $PWD) and I do
} 
}   fpath=($PWD)
}   autoload foo
}   foo
} 
} this makes available (and before that: autoloaded(!)) only foo. And
} with a zwc file it's just the same.

The case I'm thinking of is one like Completion/User/_cvs, where there
is a "primary" function and a whole bunch of "helpers" all in one file.
The following produce the same result in _cvs.zwc:

(1)	cd $^fpath/_cvs(|)(:h)
	zcompile _cvs

(2)	compinit
	zcompile -c _cvs _cvs

But this produces something different:

(3)	compinit
	cvs <TAB><C-U>
	zcompile -c _cvs _cvs

And it also doesn't "work" to list all the helper functions explicitly.

I don't mind the discrepancy between (1) and (3) so much, but (2) and (3)
is really unfortunate.  Maybe an additional (or simply different) option
should be required to get the effect of (2)?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com