PATCH: 3.1.6-dev-18 AIX dependency fixes

PATCH: 3.1.6-dev-18 AIX dependency fixes

[Oliver Kiddle]

Just mod_exports added.

Are we going to get a 3.1.7 (and maybe 4.0) out soonish? The 3.1 series
seems to be quite stable to me now. Also, 3.0 seems to be very far
behind now and it might be better to have more users using the new
functionality.

Oliver


--- Src/params.bak	Sat Feb 12 13:49:32 2000
+++ Src/params.c	Sat Feb 12 13:51:36 2000
@@ -40,6 +40,7 @@
 /* Variables holding values of special parameters */
  
 /**/
+mod_export
 char **pparams,		/* $argv        */
      **cdpath,		/* $cdpath      */
      **fpath,		/* $fpath       */
--- Src/Zle/compcore.bak	Sat Feb 12 14:19:58 2000
+++ Src/Zle/compcore.c	Sat Feb 12 14:34:53 2000
@@ -47,6 +47,7 @@
 /* Non-zero if we should keep an old list. */
 
 /**/
+mod_export
 int oldlist, oldins;
 
 /* This is used to decide when the cursor should be moved to the end
of    *
@@ -59,7 +60,7 @@
 /* The match and group number to insert when starting menucompletion.  
*/
 
 /**/
-int insmnum, insgnum, insgroup, insspace;
+mod_export int insmnum, insgnum, insgroup, insspace;
 
 /* Information about menucompletion. */
 
@@ -133,12 +134,12 @@
 /* Non-zero if we have newly added matches. */
 
 /**/
-int newmatches;
+mod_export int newmatches;
 
 /* Number of permanently allocated matches and groups. */
 
 /**/
-int permmnum, permgnum, lastpermmnum, lastpermgnum;
+mod_export int permmnum, permgnum, lastpermmnum, lastpermgnum;
 
 /* The total number of matches and the number of matches to be listed.
*/
 
@@ -180,7 +181,7 @@
 /* The match counter when unambig_data() was called. */
 
 /**/
-int unambig_mnum;
+mod_export int unambig_mnum;
 
 /* Length of longest/shortest match. */
 
@@ -214,12 +215,12 @@
 /* A heap of free Cline structures. */
 
 /**/
-Cline freecl;
+mod_export Cline freecl;
 
 /* Ambiguous information. */
 
 /**/
-Aminfo ainfo, fainfo;
+mod_export Aminfo ainfo, fainfo;
 
 /* The memory heap to use for new style completion generation. */
 
@@ -2523,7 +2524,7 @@
 /* This duplicates all groups of matches. */
 
 /**/
-int
+mod_export int
 permmatches(int last)
 {
     Cmgroup g = amatches, n;
--- Src/Zle/complete.bak	Sat Feb 12 14:33:25 2000
+++ Src/Zle/complete.c	Sat Feb 12 14:33:46 2000
@@ -71,7 +71,7 @@
 Param *comprpms, *compkpms;
 
 /**/
-void
+mod_export void
 freecmlist(Cmlist l)
 {
     Cmlist n;

Next release (Re: PATCH: 3.1.6-dev-18 AIX dependency fixes)

[Bart Schaefer]

On Feb 12,  4:47pm, Oliver Kiddle wrote:
} Subject: PATCH: 3.1.6-dev-18 AIX dependency fixes
}
} Are we going to get a 3.1.7 (and maybe 4.0) out soonish? The 3.1 series
} seems to be quite stable to me now.

I'd really like for there to be at least a 3.1.7 before 3.2 or 4.0.  The
new wordcode execution engine in particular should have wider exposure
than PWS's -dev releases before being blessed as stable non-beta code,
and we still have unresolved issues with e.g. portability of zpty.

But I agree it would be good to get 3.1.7 out as soon as possible.

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

Re: PATCH: 3.1.6-dev-18 AIX dependency fixes

[Peter Stephenson]

Oliver Kiddle wrote:
> Just mod_exports added.

There was a line wrapping problem again, so this had to be applied by hand.

> Are we going to get a 3.1.7 (and maybe 4.0) out soonish? The 3.1 series
> seems to be quite stable to me now. Also, 3.0 seems to be very far
> behind now and it might be better to have more users using the new
> functionality.

3.1.7 should certainly appear soon.  The major items on my to-do list are

-- rewrite compinstall.  Either this has to be done or it should simply be
missed out, since the current version is essentially useless.  I have
started working on this, but there is a lot to do even to be able to set
the basic styles for basic contexts.  In addition it's aimed at a moving
target, even if moving more slowly.

-- I'd like to get out the chapter of my zsh guide for new-style completion
in time for the release.  The first draft is more or less finished, though
the same problems apply and it needs rewriting already (I've changed the
context stuff, but it still needs checking, and I need to change the
$compmatchers stuff).

Neither of these is absolutely required, but if I don't get them ready for
3.1.7 they are likely to drift off.

There are other things --- for example, I suspect getting and setting of
parameters internally needs a complete rethink --- but it's unrealistic to
put a timetable on them.

Since completion now appears to be pretty much stable, 4.0.1 could then
appear without too many user-visible changes.  However, I think the
wordcode stuff is going to continue to evolve anyway (rewrite parser to
eliminate the old-style structs altogether, aim to eliminate
HEAPALLOC/PERMALLOC by passing allocation strategy directly to appropriate
constructors), and I don't think it would be a good idea to produce 4.0.1
with the current hybrid state, though it won't matter for 3.1.7.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>

Re: PATCH: 3.1.6-dev-18 AIX dependency fixes

[Sven Wischnowsky]

Peter Stephenson wrote:

> ...
>
> There are other things --- for example, I suspect getting and setting of
> parameters internally needs a complete rethink --- but it's unrealistic to
> put a timetable on them.

Having done quite a bit of testing lately, I'd say: yes. It's
currently the slowest part of the shell, and used quite often.

> Since completion now appears to be pretty much stable, 4.0.1 could then
> appear without too many user-visible changes.  However, I think the
> wordcode stuff is going to continue to evolve anyway (rewrite parser to
> eliminate the old-style structs altogether, aim to eliminate
> HEAPALLOC/PERMALLOC by passing allocation strategy directly to appropriate
> constructors), and I don't think it would be a good idea to produce 4.0.1
> with the current hybrid state, though it won't matter for 3.1.7.

Well, I've written: a) a parser that immediatly produces the wordcode
(still recursive), b) a non-recursive execution code c) several
optimisations.

Unfortunately, b) doesn't seem to make things faster and probably less 
easy to read (I've only tested this on a Intel/Linux box yet, it may
be different on other machines). And, unfortunately, I overwrote the
patch for a) alone, so now I have it only for a) and c) together. I'll 
try to separate them again, but I don't know when I'll find the time.

And none of these needs to be in 3.1.7, of course.

Bye
 Sven

P.S.: c) is quite good, almost 30% faster than before.

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