I'm not really sure about the value of this kind of try/except blocks.
If the target is to avoid the shell exiting in any case, we could as
well try/except the whole code executed before gtk.main().
Marco
On Tue, Apr 29, 2008 at 2:12 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote:
>
> On Tue, Apr 29, 2008 at 1:37 AM, Martin Dengler
> <[EMAIL PROTECTED]> wrote:
> > On Mon, Apr 28, 2008 at 06:12:31PM -0400, Michael Stone wrote:
> > > On Mon, Apr 28, 2008 at 10:26:21PM +0100, Martin Dengler wrote:
> > > > On Mon, Apr 28, 2008 at 01:08:04PM -0400, Michael Stone wrote:
> > > > > Can calls to self._mixer or self._master fail even when these
> attributes
> > > > > are not None?
> > > >
> > > > It doesn't appear a concern from the existing hardwaremanager.py code,
> > > > and not in practice: I've tested checking/changing the volume in a few
> > > > activities.
> > >
> > > I seem to recall having encountered situations where sugar startup would
> > > fail (in early versions of the QEMU image, before sound began working)
> > > as a result of unchecked use of sound hardware. I fixed the problem by
> > > commenting out volume control in the sugar shell. It was a particularly
> > > annoying problem because it was persistent, which meant that X entered
> > > an infinite reboot loop.
> >
> > Yes, that problem exists and my patch is no worse in this respect - I
> > meant to make both points very explicit later in the email to which
> > you replied. Given the clear implication that we should do better,
> > I'll change my patch.
> >
> > If you, or marco, or anyone has an opinion about where the best place
> > to introduce the real paranoia, please let me know. OTTOMH, given we
> > obviously want to make Sugar not crash and (secondarily) minimize
> > spamming of 'try:...except's, hardwaremanager.py's where I would
> > introduce the bulk of the changes (rather than make speaker.py,
> > randomactivity.py,
> > presence-palette-that-wants-to-make-a-dinging-noise.py, etc. do this).
> >
> > If anyone thinks that's controversial let me know.
> >
> >
> > > > The original author of the hardwaremanager.py trusted the gst classes
> > > > just as much as I am... also keep in mind that I actually saw and
> > > > worked around two failures (#6933, #6934) of exactly these
> > > > attributes/implementations,
> > >
> > > In your opinion, did the original author of hardwaremanager.py (or
> > > authors of the clients of hardwaremanager.py?) exercise the degree of
> > > caution necessary to deliver a solid, reliable Sugar experience to our
> > > present audience? (I say "present" audience because I think that our
> > > audience has changed from one which consisted primarily of developers to
> > > one which consists primarily of semi-literate children.)
> >
> > As a rhetorical question I think I understand the point. As a
> > non-rhetorical question, I'll decline to answer due to lack of
> > context/familiarity with the conditions.
> >
> >
> > > > > Also, what happens if an exception is thrown by, say,
> Device.__init__()?
> > > >
> > > > Given the current state of error checking, sugar (the shell) will fail
> > > > to start and matchbox will exit (I saw this during testing, and just
> > > > now tried 'raise Exception("we love m_stone")' to confirm.)
> > >
> > > Is the exception properly recorded?
> >
> > I'm sorry, I will have to research the proper way to record such an
> > exception. I don't know.
> >
> >
> > > Is it possible (easy?) to send the traceback upstream to us?
> >
> > Very interesting idea. Is there a plan for aggregating such data?
> > cscott's FISL presenation had some (http-sourced?) usage graphs...is
> > there a "Send Microsoft a Report"- (or "We Share Your Pain" :)) like
> > server to which our code could send such reports? Do you want
> > automated/staged trac submissions? The design/architecture/maintenance
> > solution space is well beyond my time to explore. Lacking any leads
> > therein I'm going to answer to your question as "I know not this
> > 'upstream', would be happy to use one, but have no resources to build
> > one".
> >
> >
> > > > Device.__init__() is four lines of code, and depends on
> > > > util.unique_id() and gobject.GObject.__init__().
> > >
> > > Device.__init__() sounds like the sort of thing that I expect will be
> > > overridden by subclasses in interesting ways and it sounds like the sort
> > > of thing that will break when people try to run Sugar on platforms we
> > > haven't tested pre-qualified.
> >
> > I think you're encouraging me to make Device.__init__() a bit safer,
> > or add some comments, or something similar, rather than changing
> > speaker.py's __init__(). It's going to get a bit hairy if we can't
> > trust our superclass(es)'s constructor(s). Or perhaps you'd have me
> > consider patching devices.py, to survive any of its devices' not
> > initializing.
> >
> > If you / anyone has a preference for either approach, or how I
> > structure the changes into one or more patches (this is part of the
> > culture that I haven't picked up yet), please let me know.
> >
> > Otherwise I will go forward with what you've said on the principle
> > that you/others would rather slap my code back/down than micromanage
> > me forward.
> >
> >
> > > > and no other similar bit of code... does any more checking than this.
> > >
> > > Is this good? In particular, is it good that an exception that bubbles
> > > up through Device.__init__() causes X to enter an infinite restart loop?
> >
> > ibid.
> >
> >
> > > > And please excuse me if I've missed a howler of a bug that you're
> > > > socraticly/patiently trying to make me realize - just feel free to say
> > > > outright what sucks and I'll fix it!
> > >
> > > You seem to be telling me that Sugar will crash if any of its device
> > > abstractions fails to initialize. That seems like a howler of a bug to
> > > me (though perhaps not one in your code). Is this desirable behavior? Is
> > > it intentional?
> >
> > No, and (from the point of view of a non-Sugar, non-OLPC, new patcher)
> > I had to consider that it was intentional, or at least was something
> > that (before your email) I wasn't in a position to presume to change
> > (or to submit a patch that invasive for a new icon addition).
> >
> > I'm happy to revise that approach, as hopefully previously made clear.
>
> I think that Michael has spotted here a wonderful opportunity for
> making Sugar more robust, thanks to your patch.
>
> What about just making the shell to catch (and log) any exception
> resulting from the initialization of a device? That should amount to
> just add one try..except block.
>
> Devices are thought to be easily added, so its an expected source of
> new bugs. The shell should be able to start when any of them fail.
>
> Thanks,
>
> Tomeu
>
>
> _______________________________________________
> Sugar mailing list
> Sugar@lists.laptop.org
> http://lists.laptop.org/listinfo/sugar
>
_______________________________________________
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
