🚀 go-pugleaf

In article <17524@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes:
>
>An interesting problem was just described to me.  It seems that the
>fileforall operator has a minor bug in it.  As it enumerates the files
>on the disk (if you have a NTX), it leaves a copy of the file name on
>the stack.  512 files later, kablooie.  The solution of course is to
>redifine it so that it does a pop after each call to get the filename.
>The problem apparently does not show up unless you have over 512 files
>of the disk.
>
>One of Don's clients got bit by that one, and Don dug around until hi
>found it.  Watch for a ***VERY*** interesting article to appear shortly
>in Byte magazine.

In article <17529@rpp386.cactus.org>, woody@rpp386.cactus.org (Woodrow Baker) writes:
>I have not tested this filenameforall problem out, as I don't have a
>printer with a hd on it. Seems that the mac utilities take advantage of it.
>It may be a part of the description for all I know, as I don't have
>a manual dealing with the filestuff, but Don reports it as a bug.  At the
>least, it is an annoyance.

Your description of your friend's problem is very poor, but it seems like
the filenameforall operator works the way it is described in the manual.
My experiences from playing around with the filenameforall operator (I don't
have a PostScript printer with a hard disk to try it on right now) is that
it works the way it is described, which is both reasonable and analogous to
the way the forall operator works.

The forall operator pushes one or two things (depending on whether you apply
it to an array, a dictionary, or a string) on the stack, before invoking the
procedure you passed as an argument.  It's your responsibility to pop those
things, unless you want to leave them on the stack.

The filenameforall pushes a filename (it doesn't create a new string for each
filename, it uses the string you passed it for a buffer) on the stack, before
it invokes the procedure.  It's your responsibility to pop that string, unless
you want to leave it on the stack.

Jan Michael Rynning,			jmr@nada.kth.se
Department of Numerical Analysis	If you can't fully handle domains:
  and Computing Science,		ARPA: jmr%nada.kth.se@uunet.uu.net
Royal Institute of Technology,		UUCP: {uunet,mcvax,...}!nada.kth.se!jmr
S-100 44 Stockholm,			BITNET: jmr@sekth
Sweden.					Phone: +46-8-7906288