On Wednesday 10 December 2008, Adam Olsen wrote:
> On Wed, Dec 10, 2008 at 3:39 AM, Ulrich Eckhardt
>
> <[EMAIL PROTECTED]> wrote:
> > On Tuesday 09 December 2008, Adam Olsen wrote:
> >> The only thing separating this from a bikeshed discussion is that a
> >> bikeshed has many equally good solution
Le Wednesday 10 December 2008 20:04:00 Terry Reedy, vous avez écrit :
> >> Recover after a segfault is dangerous, but my first goal was to get the
> >> Python backtrace instead just one line: "Segmentation fault". It helps a
> >> lot for debug!
> >
> > Exactly! That's why it doesn't belong in the P
>
> If we could calculate how much stack is left we'd have a much more
> robust way of doing recursion limits. I suppose this could be done by
> reading a byte from each page with a temporary SIGSEGV handler
> installed, but I'm not convinced you can't ask the platform directly
> somehow. I'd als
Ulrich Eckhardt wrote:
> On Wednesday 10 December 2008, Adam Olsen wrote:
>> On Wed, Dec 10, 2008 at 3:39 AM, Ulrich Eckhardt
>>
>> <[EMAIL PROTECTED]> wrote:
>>> On Tuesday 09 December 2008, Adam Olsen wrote:
The only thing separating this from a bikeshed discussion is that a
bikeshed ha
Martin v. Löwis wrote:
> Jeffrey Yasskin wrote:
>> Was there ever a conclusion to this? I need to merge the patches
>> associated with issue 4597 from trunk to all the maintenance branches,
>> and I'd like to avoid messing anyone up if possible. If I don't hear
>> back, I'll plan to svnmerge direct
Simon> Some indictation of what Python was executing when the segfault
Simon> occurred would help narrow now the possibilities rapidly.
The Python distribution comes with a Misc/gdbinit file (you can grab it from
the Subversion source tree via the web as well) that defines a pystack
comma
pobox.com> writes:
>
> The Python distribution comes with a Misc/gdbinit file (you can grab it from
> the Subversion source tree via the web as well) that defines a pystack
> command. It will work with core files as well as running processes and
> should give you a very good idea where your Pyth
Antoine> Still, it would be much better if the stack trace could be
Antoine> printed by Python itself rather than having to resort to gdb
Antoine> wizardry. Especially if the problem is reported by one of your
Antoine> non-developer users.
I understand. The guy has a problem toda
pobox.com> writes:
>
> I understand. The guy has a problem today for which there is a solution
> that I posted. If he's "been meaning to look into the problem" and he's
> posting to python-dev I presume he knows at least a little about running gdb
> if he's operating in a Unix environment. The
On Thursday 11 December 2008, Steve Holden wrote:
> Ulrich Eckhardt wrote:
> > What I'd just like some feedback on is the approach to return a distinct
> > type (neither a byte string nor a Unicode string) from readdir(). In
> > order to use this, a programmer will have to convert it explicitly,
>
Hi Martin,
On Dec 11, 2008, at 12:12 AM, Martin v. Löwis wrote:
Several people already said (essentially) that: -1. I don't think such
code should be added to the Python core, no matter how smart or
correct
it is.
does your -1 apply only to attempts to resume execution after SIGSEGV,
or
Le Thursday 11 December 2008 13:57:03 [EMAIL PROTECTED], vous avez écrit :
> Simon> Some indictation of what Python was executing when the segfault
> Simon> occurred would help narrow now the possibilities rapidly.
>
> The Python distribution comes with a Misc/gdbinit file
Hum, do you real
On Thu, 11 Dec 2008, Ulrich Eckhardt wrote:
On Thursday 11 December 2008, Steve Holden wrote:
Ulrich Eckhardt wrote:
Seems to me this just threatens to add to the confusion.
If you know what your filesystem produces, you can take the appropriate
action to convert it into a type that makes sens
>> The Python distribution comes with a Misc/gdbinit file
Victor> Hum, do you really run *all* programs in gdb? Most of the time,
Victor> you don't expect a crash (because you trust your softwares). You
Victor> will have to try to reproduce the crash, but sometimes it's very
V
On Thu, Dec 11, 2008 at 1:34 AM, Victor Stinner
<[EMAIL PROTECTED]> wrote:
> But if -as many people wrote-
> Python is totally broken after a segfault, it is maybe not a good idea :-)
While it's true that after a segfault or unexpected longjmp, there are
no guarantees whatsoever about the state of
On Thu, Dec 11, 2008 at 4:18 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
>> Jeffrey Yasskin wrote:
>>> Was there ever a conclusion to this? I need to merge the patches
>>> associated with issue 4597 from trunk to all the maintenance branches,
>>> and I'd like to avoid messi
On Dec 11, 2008, at 11:08 AM, Jeffrey Yasskin wrote:
On Thu, Dec 11, 2008 at 1:34 AM, Victor Stinner
<[EMAIL PROTECTED]> wrote:
But if -as many people wrote-
Python is totally broken after a segfault, it is maybe not a good
idea :-)
While it's true that after a segfault or unexpected longj
On Thu, Dec 11, 2008 at 10:08 AM, Jeffrey Yasskin wrote:
> On Thu, Dec 11, 2008 at 1:34 AM, Victor Stinner
> wrote:
>> But if -as many people wrote-
>> Python is totally broken after a segfault, it is maybe not a good idea :-)
>
> While it's true that after a segfault or unexpected longjmp, there
Ulrich Eckhardt wrote:
> On Thursday 11 December 2008, Steve Holden wrote:
>> Ulrich Eckhardt wrote:
>>> What I'd just like some feedback on is the approach to return a distinct
>>> type (neither a byte string nor a Unicode string) from readdir(). In
>>> order to use this, a programmer will have to
On Thu, Dec 11, 2008 at 6:41 AM, Ulrich Eckhardt
wrote:
> On Thursday 11 December 2008, Steve Holden wrote:
>> re-present it to the filesystem to manipulate the file. What are we
>> supposed to do with the "special type"?
>
> You receive from readdir() and pass it to stat(), simple as that. No
> c
On Thu, Dec 11, 2008 at 2:34 AM, Victor Stinner
wrote:
> Le Wednesday 10 December 2008 20:04:00 Terry Reedy, vous avez écrit :
>> >> Recover after a segfault is dangerous, but my first goal was to get the
>> >> Python backtrace instead just one line: "Segmentation fault". It helps a
>> >> lot for
On Thu, Dec 11, 2008 at 12:15 PM, Adam Olsen wrote:
> You have to use the low-level stderr, nothing that invokes Python.
> I'd hate to get a second segfault while printing the first.
>
> Just think about how indirect refcounting bugs tend to be. Another
> example is messing up GIL handling. The
On 2008-12-11 19:15, Adam Olsen wrote:
> On Thu, Dec 11, 2008 at 2:34 AM, Victor Stinner
> wrote:
>> Le Wednesday 10 December 2008 20:04:00 Terry Reedy, vous avez écrit :
> Recover after a segfault is dangerous, but my first goal was to get the
> Python backtrace instead just one line: "Se
> I believe that's difficult when you previously merged from the trunk to
> the py3k branch - the merged change to the svnmerge related properties
> on the root directory gets in the way when svnmerge attempts to update
> them on the maintenance branch.
>
> That's what started this thread, and so
> On Dec 11, 2008, at 12:12 AM, Martin v. Löwis wrote:
>> Several people already said (essentially) that: -1. I don't think such
>> code should be added to the Python core, no matter how smart or correct
>> it is.
>
>
> does your -1 apply only to attempts to resume execution after SIGSEGV,
> or a
> Yeah, that's why I asked. I tried what Martin suggested with r67698 by
> just saying I'd resolved the conflict, which added the single revision
> I was merging from to the svnmerge-integrated property. It didn't add
> the two original revisions.
Can you elaborate? What are the "two original rev
On Thu, Dec 11, 2008 at 12:10 PM, "Martin v. Löwis" wrote:
>> Yeah, that's why I asked. I tried what Martin suggested with r67698 by
>> just saying I'd resolved the conflict, which added the single revision
>> I was merging from to the svnmerge-integrated property. It didn't add
>> the two origina
Martin v. Löwis wrote:
>> I believe that's difficult when you previously merged from the trunk to
>> the py3k branch - the merged change to the svnmerge related properties
>> on the root directory gets in the way when svnmerge attempts to update
>> them on the maintenance branch.
>>
>> That's what
Nick Coghlan wrote:
Martin v. Löwis wrote:
I believe that's difficult when you previously merged from the trunk to
the py3k branch - the merged change to the svnmerge related properties
on the root directory gets in the way when svnmerge attempts to update
them on the maintenance branch.
That's
>> The Python distribution comes with a Misc/gdbinit file
>
> Hum, do you really run *all* programs in gdb? Most of the time, you don't
> expect a crash (because you trust your softwares). You will have to try to
> reproduce the crash, but sometimes it's very hard (eg. Heisenbugs!).
You don't h
Steve Holden writes:
> Ulrich Eckhardt writes:
> > What I'd just like some feedback on is the approach to return a
> > distinct type (neither a byte string nor a Unicode string) from
> > readdir().
This is presumably unacceptable on the grounds that it will break
existing code that does somet
Last month there was a discussion on Python-Dev regarding removal of
reference counting to remove the GIL. I hope you forgive me for continuing
the debate.
I think reference counting is a good feature. It prevents huge piles of
garbage from building up. It makes the interpreter run more smoothly.
On Thu, Dec 11, 2008 at 6:55 PM, Stephen J. Turnbull wrote:
> Unfortunately, even programmers experienced in I18N like Martin, and
> those with intuition-that-has-the-force-of-law like Guido,
> express deliberate disbelief on this point. They say that filesystem
> names and environment variable v
Adam Olsen wrote:
> On Thu, Dec 11, 2008 at 6:55 PM, Stephen J. Turnbull
> wrote:
>> Unfortunately, even programmers experienced in I18N like Martin, and
>> those with intuition-that-has-the-force-of-law like Guido,
>> express deliberate disbelief on this point. They say that filesystem
>> names
On Thu, Dec 11, 2008 at 10:41 PM, Toshio Kuratomi wrote:
> Adam Olsen wrote:
>> On Thu, Dec 11, 2008 at 6:55 PM, Stephen J. Turnbull
>> wrote:
>>> Unfortunately, even programmers experienced in I18N like Martin, and
>>> those with intuition-that-has-the-force-of-law like Guido,
>>> express delib
On Thu, Dec 11, 2008 at 10:19 PM, Adam Olsen wrote:
>
> I doubt that UTF-16 is used very much (other than on windows).
>
There's this other obscure platform called "Java"... ;)
--
Curt Hagenlocher
c...@hagenlocher.org
___
Python-Dev mailing list
Pytho
On Thu, Dec 11, 2008 at 10:22 PM, Adam Olsen wrote:
> On Thu, Dec 11, 2008 at 6:55 PM, Stephen J. Turnbull
> wrote:
>> Unfortunately, even programmers experienced in I18N like Martin, and
>> those with intuition-that-has-the-force-of-law like Guido,
>> express deliberate disbelief on this point.
On Thu, Dec 11, 2008 at 11:25 PM, Curt Hagenlocher wrote:
> On Thu, Dec 11, 2008 at 10:19 PM, Adam Olsen wrote:
>>
>> I doubt that UTF-16 is used very much (other than on windows).
>
> There's this other obscure platform called "Java"... ;)
Sorry, I should have said "for interchange". :)
(CPyth
Adam Olsen wrote:
> A half-broken setup is still a broken setup. Eventually you have to
> tell people to stop screwing around and pick one encoding.
>
But it's not a broken setup. It's the way the world is because people
share things with each other.
> I doubt that UTF-16 is used very much (ot
Adam Olsen wrote:
> As a data point, firefox (when pointed at my home dir) DOES skip over
> garbage files.
>
>
That's not true. However, it looks like Firefox is actually broken.
Take a look at this screenshot:
firefox.png
That shows a directory with a folder that's not decodable in my utf-8
40 matches
Mail list logo
