On 20 Apr., 06:49, Keshav Kini wrote:
> Uh... I'm not sure why Google Groups just quoted John's message five times,
> but sorry about that...
Must have been some joke by a google operator, which gets apparent if
you read the sage-devel digest:
On 21 Apr., 21:04, John Cremona wrote:
> On 21 April 2012 19:37, David Roe wrote:
>
> > I've seen this as well, but I don't know what causes it.
>
> I am managing by using the wysiwyg box instead, which I would normally avoid.
You should be able to resize the text box, which IMHO has too few
lin
I figured it out. The problem was somewhere else completely - with
python itself. I copied the patches from the FreeBSD port of python,
and so far it is looking good.
On 04/21/2012 05:20 PM, Volker Braun wrote:
I guess the os.wait() throws an OSError with errno = EINTR because the
SIGALARM
This is not directly relevant but might be useful for you if you're a
Firefox user. It certainly is for me.
https://addons.mozilla.org/en-US/firefox/addon/lazarus-form-recovery/
-Keshav
Join us in #sagemath on irc.freenode.net !
--
To post to this group, send an email to sage-devel@googl
I guess the os.wait() throws an OSError with errno = EINTR because the
SIGALARM fires? If that is the case we should probably ignore it in
use_fork.py
On Saturday, April 21, 2012 3:36:44 PM UTC-4, Stephen Montgomery-Smith
wrote:
>
> I did some research, and I found that you are completely c
Hi!
I've put
class bla(type):
pass
into a file test.pyx
On the machine in my office (Debian GNU/Linux 6.0), both with
sage-4.6.2 and sage-5.0.beta13, I got (correctly)
sage: attach test.pyx
Compiling ./test.pyx...
sage: bla.__module__
'_home_king_SAGE_tests_test_pyx_0'
sage: sys
I did some research, and I found that you are completely correct. I
don't know why FreeBSD is misbehaving, because the os.wait command
definitely triggers the OSError exception. signal.getsignal(SIGCHLD)
shows that it is correctly set to signal.SIG_DFL. So I am mystified.
Thank you for sett
On 21 April 2012 19:37, David Roe wrote:
> I've seen this as well, but I don't know what causes it.
I am managing by using the wysiwyg box instead, which I would normally avoid.
The other thing which annoys me about trac which happens a lot when
several people are working on one ticket at the sa
I've seen this as well, but I don't know what causes it.
David
On Sat, Apr 21, 2012 at 04:13, John Cremona wrote:
> After some recent changes in the trac version we use (I think) I find
> the following, but only when I use it with chromium on my small-screen
> netbook: The text box into which o
I don't have a FreeBSD box to try this on, but note that children shouldn't
just disappear when they finish. They remain as zombies ( in ps)
until they are collected by os.wait()
On Saturday, April 21, 2012 12:39:13 AM UTC-4, Stephen Montgomery-Smith
wrote:
>
> In parallel/use_fork.py, around
After some recent changes in the trac version we use (I think) I find
the following, but only when I use it with chromium on my small-screen
netbook: The text box into which one types comments is extremely
narrow, exactly 3 characters in fact (the same width as the words
"wysisyg" and "textarea" w
11 matches
Mail list logo
