> 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
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
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
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
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
(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
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
> 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
> 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
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
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
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
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
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
14 matches
Mail list logo