Re: pass at srfi-89 implementation

2008-08-21 Thread Julian Graham
> I just ran the statprof unit test and it seems to still be OK. Perhaps > in Julien's run, there simply was not enough time in user space relative > to the sampling frequency. (Certainly statprof should deal with this in > a more intelligent fashion.) That's certainly possible (I take it you're u

Re: pass at srfi-89 implementation

2008-08-21 Thread Julian Graham
Alright, I give up. I'm still not exactly sure why my implementation is as slow as it is; I have a hunch that I'm taking too long processing the list of actual parameters, but I haven't been able to glean many specifics from statprof. Marc also employs some nifty but un-Scheme-y (to my mind, at l

Re: pass at srfi-89 implementation

2008-08-20 Thread Andy Wingo
Hi, On Wed 20 Aug 2008 00:32, [EMAIL PROTECTED] (Ludovic Courtès) writes: > http://thread.gmane.org/gmane.lisp.guile.bugs/3895 > > I'm concerned about the accuracy of `statprof' given that handlers are > called asynchronously. Signal handlers have always been called asynchronously, so there's

Re: pass at srfi-89 implementation

2008-08-20 Thread Ludovic Courtès
Hi, Andy Wingo <[EMAIL PROTECTED]> writes: > I haven't noticed this, no. Normally this would mean that we're dividing > by zero, perhaps no counts were taken or something. (Perhaps we should > pull statprof into guile itself.) Let me know if you get around to > fixing this before I do. It could

Re: pass at srfi-89 implementation

2008-08-19 Thread Andy Wingo
Hi Julian, On Sat 16 Aug 2008 14:19, "Julian Graham" <[EMAIL PROTECTED]> writes: > (Has anyone else noticed that statprof hasn't been working for a while > now? I get a "Numerical overflow" from `statprof-display' no matter > what arguments I pass to `statprof-reset'.) I haven't noticed this, n

Re: pass at srfi-89 implementation

2008-08-16 Thread Julian Graham
(Sorry for the late reply -- I was out of the country last week...) >> Okay, I've tried -- at length. And so far I haven't been able to top >> the performance of the reference implementation. In fact, it actually >> seems to be fairly efficient > > Did you run some sort of "benchmark"? Yes. No

Re: pass at srfi-89 implementation

2008-08-11 Thread Ludovic Courtès
Hi Julian, "Julian Graham" <[EMAIL PROTECTED]> writes: > Okay, I've tried -- at length. And so far I haven't been able to top > the performance of the reference implementation. In fact, it actually > seems to be fairly efficient Did you run some sort of "benchmark"? > From what I can see, the

Re: pass at srfi-89 implementation

2008-07-27 Thread Julian Graham
> I'm still not convinced by the last option. Given the above, Option 2 > (that is, writing our own, preferably in Scheme) seems to be the safest. > Hopefully this isn't too much work, but the above quote indicates that > we should be careful about performance. ;-) > > Would you like to try doing

Re: pass at srfi-89 implementation

2008-05-24 Thread Julian Graham
> It looks like the license terms would indeed allow us to do that. I'm > not sure whether there's a precedent including non-LGPL SRFI code as is, > though. Well, it wouldn't have to be 100% as-is -- aside from adding the module declaration, there are some things I wouldn't mind tweaking a bit, s

Re: pass at srfi-89 implementation

2008-05-20 Thread Ludovic Courtès
Hi, "Julian Graham" <[EMAIL PROTECTED]> writes: > Well, there's a reference implementation of SRFI-89 that (I think) > could just be dropped in and used, now that we have SRFI-88-style > keywords. It looks like the license terms would indeed allow us to do that. I'm not sure whether there's a p

Re: pass at srfi-89 implementation

2008-05-19 Thread Julian Graham
Well, there's a reference implementation of SRFI-89 that (I think) could just be dropped in and used, now that we have SRFI-88-style keywords. I was just hoping that the existence of `(ice-9 optargs)' would make possible a more compact / potentially more efficient implementation. > Would it be a

Re: pass at srfi-89 implementation

2008-05-19 Thread Ludovic Courtès
Hi Julian, "Julian Graham" <[EMAIL PROTECTED]> writes: > So I've taken a stab at implementing SRFI-89, using Guile's existing > (ice-9 optargs) module -- my thinking was that the two were similar > enough to make it worthwhile to have optargs do most of the heavy > lifting. What I've done is add

Re: pass at srfi-89 implementation

2008-05-05 Thread Ludovic Courtès
Hi Julian, "Julian Graham" <[EMAIL PROTECTED]> writes: > So I've taken a stab at implementing SRFI-89 This is good news! Neil and I have agreed to release 1.8.5 ASAP, which I'll try to do by the end of the week, after which I'll look into your SRFI-89 module if no one beats me at it. ;-) Than

pass at srfi-89 implementation

2008-05-02 Thread Julian Graham
Hi everyone, So I've taken a stab at implementing SRFI-89, using Guile's existing (ice-9 optargs) module -- my thinking was that the two were similar enough to make it worthwhile to have optargs do most of the heavy lifting. What I've done is add some pre-parsing of the formals list before it's p