[sugar] [PATCH] Add speaker device and icon by default

Tue Apr 29 08:24:06 EDT 2008

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 <tomeu at tomeuvizoso.net> wrote:
>
> On Tue, Apr 29, 2008 at 1:37 AM, Martin Dengler
>  <martin at martindengler.com> 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 at lists.laptop.org
>  http://lists.laptop.org/listinfo/sugar
>