It happens only at the first time. On Sat, Apr 10, 2010 at 3:58 AM, <stumpwm-devel-requ...@nongnu.org> wrote:
> Send Stumpwm-devel mailing list submissions to > stumpwm-devel@nongnu.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.nongnu.org/mailman/listinfo/stumpwm-devel > or, via email, send a message with subject or body 'help' to > stumpwm-devel-requ...@nongnu.org > > You can reach the person managing the list at > stumpwm-devel-ow...@nongnu.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Stumpwm-devel digest..." > > > Today's Topics: > > 1. shell command tab completion takes 6 seconds! (Yuliang Wang) > 2. Re: shell command tab completion takes 6 seconds! > (Lionel Flandrin) > 3. Re: shell command tab completion takes 6 seconds! > (Rupert Swarbrick) > 4. Re: shell command tab completion takes 6 seconds! (Shawn Betts) > 5. Re: shell command tab completion takes 6 seconds! (Shawn Betts) > 6. Re: shell command tab completion takes 6 seconds! > (Julian Stecklina) > 7. Re: shell command tab completion takes 6 seconds! (Shawn Betts) > 8. Re: shell command tab completion takes 6 seconds! > (Tobias C. Rittweiler) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 9 Apr 2010 15:54:34 -0400 > From: Yuliang Wang <jadelightk...@gmail.com> > Subject: [STUMP] shell command tab completion takes 6 seconds! > To: stumpwm-devel@nongnu.org > Message-ID: > <x2n5d8cd4661004091254v454ec54ya2bff7ac26138...@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > This doesn't happen in ratpoison. > -- > Sincerely, > Yuliang Wang > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.gnu.org/pipermail/stumpwm-devel/attachments/20100409/02e92fb3/attachment.html > > ------------------------------ > > Message: 2 > Date: Fri, 9 Apr 2010 20:34:00 +0000 > From: Lionel Flandrin <simia...@gmail.com> > Subject: Re: [STUMP] shell command tab completion takes 6 seconds! > To: stumpwm-devel@nongnu.org > Message-ID: <20100409203358.gc12...@shame> > Content-Type: text/plain; charset="us-ascii" > > Hi, > > Does it happen every time or only the first time? Stumpwm caches the > binaries in PATH, so it should only be slow (albeit indeed very slow) > the first time. > > On Fri, Apr 09, 2010 at 03:54:34PM -0400, Yuliang Wang wrote: > > This doesn't happen in ratpoison. > > -- > Lionel Flandrin > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 198 bytes > Desc: not available > Url : > http://lists.gnu.org/pipermail/stumpwm-devel/attachments/20100409/bf578081/attachment.bin > > ------------------------------ > > Message: 3 > Date: Fri, 09 Apr 2010 22:58:40 +0100 > From: Rupert Swarbrick <rswarbr...@gmail.com> > Subject: Re: [STUMP] shell command tab completion takes 6 seconds! > To: stumpwm-devel@nongnu.org > Message-ID: <hpo7uj$q0...@dough.gmane.org> > Content-Type: text/plain; charset="us-ascii" > > Skipped content of type multipart/mixed-------------- next part > -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 315 bytes > Desc: not available > Url : > http://lists.gnu.org/pipermail/stumpwm-devel/attachments/20100409/039ed039/attachment.bin > > ------------------------------ > > Message: 4 > Date: Fri, 9 Apr 2010 18:15:25 -0700 > From: Shawn Betts <sabe...@gmail.com> > Subject: Re: [STUMP] shell command tab completion takes 6 seconds! > To: StumpWM-devel <stumpwm-devel@nongnu.org> > Message-ID: > <s2i62e3e0b31004091815gde3f48a3h2525e4efd5273...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > > I've attached a patch with a faster implementation. Advert to prove it > > works: > > This is a great optimization but I think it fails to look at the > bigger picture. It seems for all its awesomeness, the ansi standard > doesn't have a function to list the contents of a fucking directory! > Or at least not all implementations DWIM (I'm looking at you, clisp). > But I'm sure they each have a function in one of their extensions that > does that. So perhaps we should write a function in wrappers.lisp that > calls the right function for each implementation. Then, if needed, we > can just zip through the list and remove anything we're not interested > in (directories come to mind). That would hopefully be even faster. > Any takers? > > -Shawn > > > > > ------------------------------ > > Message: 5 > Date: Fri, 9 Apr 2010 18:25:24 -0700 > From: Shawn Betts <sabe...@gmail.com> > Subject: Re: [STUMP] shell command tab completion takes 6 seconds! > To: StumpWM-devel <stumpwm-devel@nongnu.org> > Message-ID: > <h2s62e3e0b31004091825m3438f85ev9d6e9d554b951...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > I found this amusing so I thought I'd share. The same command run on 3 > different implementations: > > Lispworks: > > ND> (length (directory "/usr/bin/*")) > 864 > > SBCL: > > * (length (directory "/usr/bin/*")) > 815 > > CLISP: > > [12]> (length (directory "/usr/bin/*")) > 908 > > -Shawn > > > > > ------------------------------ > > Message: 6 > Date: Sat, 10 Apr 2010 04:21:39 +0200 > From: Julian Stecklina <j...@alien8.de> > Subject: Re: [STUMP] shell command tab completion takes 6 seconds! > To: stumpwm-devel@nongnu.org > Message-ID: <87r5mo82to....@tabernacle.localhost> > Content-Type: text/plain; charset=us-ascii > > Shawn Betts <sabe...@gmail.com> writes: > > > I found this amusing so I thought I'd share. The same command run on 3 > > different implementations: > > > > Lispworks: > > > > ND> (length (directory "/usr/bin/*")) > > 864 > > > > SBCL: > > > > * (length (directory "/usr/bin/*")) > > 815 > > > > CLISP: > > > > [12]> (length (directory "/usr/bin/*")) > > 908 > > And THAT is why osicat exists. :) > > http://common-lisp.net/project/osicat/ > > Regards, > -- > Julian Stecklina > > I fear [...] that most undergraduate degrees in computer science these > days are basically Java vocational training. - Alan Kay > > > > > > ------------------------------ > > Message: 7 > Date: Fri, 9 Apr 2010 21:41:49 -0700 > From: Shawn Betts <sabe...@gmail.com> > Subject: Re: [STUMP] shell command tab completion takes 6 seconds! > To: StumpWM-devel <stumpwm-devel@nongnu.org> > Message-ID: > <r2o62e3e0b31004092141r7985a33akb8956b8860899...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > > > > And THAT is why osicat exists. :) > > > > http://common-lisp.net/project/osicat/ > > Well shit we could just rip the code straight out of the > with-directory-iterator example! It sucks to add another dependency > but that looks like exactly what we need. > > -Shawn > > > > > ------------------------------ > > Message: 8 > Date: Sat, 10 Apr 2010 09:58:02 +0200 > From: "Tobias C. Rittweiler" <t...@freebits.de> > Subject: Re: [STUMP] shell command tab completion takes 6 seconds! > To: stumpwm-devel@nongnu.org > Message-ID: <87633zpwmt....@freebits.de> > Content-Type: text/plain; charset=us-ascii > > Shawn Betts <sabe...@gmail.com> writes: > > >> > >> And THAT is why osicat exists. :) > >> > >> http://common-lisp.net/project/osicat/ > > > > Well shit we could just rip the code straight out of the > > with-directory-iterator example! It sucks to add another dependency > > but that looks like exactly what we need. > > Actually, it's what CL-FAD exists for. OSICAT just surpasses the > implementation and goes straight to the OS, while CL-FAD is a > portability wrapper around DIRECTORY. > > You could probably just rip CL-FAD:LIST-DIRECTORY. > > -T. > > > > > > ------------------------------ > > _______________________________________________ > Stumpwm-devel mailing list > Stumpwm-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/stumpwm-devel > > > End of Stumpwm-devel Digest, Vol 61, Issue 2 > ******************************************** > -- Sincerely, Yuliang Wang
_______________________________________________ Stumpwm-devel mailing list Stumpwm-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/stumpwm-devel
