Hi Robert and all who attend this thread,
well, since we just can't fix the path search behaviour in Python's
sys module, I headed for a pragmatic workaround.
I just attached a first patch to #4366. (Hah. My very first Sage
patch.)
This needs a bit more work, but already all doctests pass.
Any
On Oct 26, 2008, at 2:15 PM, Georg S. Weber wrote:
>
> Hi,
>
> I know now how to change the code so that when we had before:
>
> sage: time for i in range(10^4): float(1)/2
> CPU times: user 17.72 s, sys: 13.44 s, total: 31.16 s
> Wall time: 31.20 s
>
> then after the changes we get:
>
> sage: ti
Hi,
I know now how to change the code so that when we had before:
sage: time for i in range(10^4): float(1)/2
CPU times: user 17.72 s, sys: 13.44 s, total: 31.16 s
Wall time: 31.20 s
then after the changes we get:
sage: time for i in range(10^4): float(1)/2
CPU times: user 0.37 s, sys: 0.00 s,
Hi,
On 24 Okt., 01:00, Willem Jan Palenstijn <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 23, 2008 at 02:20:42PM -0700, Georg S. Weber wrote:
> > 3. Even the innocent line
>
> > sage: time for i in range(10): float(1)/2
>
> This seems to be caused by the _record_exception() function in the
> coerc
On Thu, Oct 23, 2008 at 02:20:42PM -0700, Georg S. Weber wrote:
> 3. Even the innocent line
>
>sage: time for i in range(10): float(1)/2
This seems to be caused by the _record_exception() function in the
coercion model. Specifically, the function canonical_coercion() in
coerce.pyx calls this
On Thu, Oct 23, 2008 at 2:20 PM, Georg S. Weber
<[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> just a short update of my findings so far:
>
> 1.) Yes, on a Mac "fs_usage" is exactly the smoking gun needed. It
> prints something like:
>
>
> 22:30:15.446 stat [ 2]
> coerce_maps.pyx
> 22:30
Hi,
just a short update of my findings so far:
1.) Yes, on a Mac "fs_usage" is exactly the smoking gun needed. It
prints something like:
22:30:15.446 stat [ 2]
coerce_maps.pyx
22:30:15.446 stat [ 2]
coerce_maps.pyx
22:30:15.446 stat [ 2]
On Oct 22, 2008, at 22:36 , Georg S. Weber wrote:
[snip]
> I didn't do development on Apple Mac OS X yet, but I found the
> "Sampler"
> tool under Developer/Applications, thanks for the tip!
>
> It'll take some time to get acquainted to it, but it already showed me
> that
> while executing the fo
Hi,
I'll open a trac ticket for this, as soon as I can figure out a
reasonable description
(this evening or tomorrow).
Cheers,
gsw
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
On Oct 22, 10:36 pm, "Georg S. Weber" <[EMAIL PROTECTED]>
wrote:
> Hi,
> It'll take some time to get acquainted to it, but it already showed me
> that
> while executing the following line:
>
> sage: for i in range(100): float(1)/2
>
> the sage.bin process calls quite often "posix_stat", "p
Hi,
On 21 Okt., 22:54, "Justin C. Walker" <[EMAIL PROTECTED]> wrote:
> On Oct 21, 2008, at 13:26 , Georg S. Weber wrote:
>
>
>
>
>
> > Hi,
>
> > On 21 Okt., 20:59, Emmanuel Thomé <[EMAIL PROTECTED]> wrote:
> >> Hmm, it turns out that it's not just any code that triggers this
> >> behaviour. Howev
On Oct 21, 2008, at 13:26 , Georg S. Weber wrote:
>
> Hi,
>
> On 21 Okt., 20:59, Emmanuel Thomé <[EMAIL PROTECTED]> wrote:
>> Hmm, it turns out that it's not just any code that triggers this
>> behaviour. However, with the following test case I can reproduce the
>> problem quite deterministicall
Hi,
On 21 Okt., 20:59, Emmanuel Thomé <[EMAIL PROTECTED]> wrote:
> Hmm, it turns out that it's not just any code that triggers this
> behaviour. However, with the following test case I can reproduce the
> problem quite deterministically:
>
> (term1): strace -p `pidof sage.bin` -e trace='stat'
>
>
Hmm, it turns out that it's not just any code that triggers this
behaviour. However, with the following test case I can reproduce the
problem quite deterministically:
(term1): strace -p `pidof sage.bin` -e trace='stat'
(term2):
sage: for i in range(100): float(1)/2
Regards,
E.
--~--~-
14 matches
Mail list logo
