GNOME.org
 

Gtkmm-forge Digest, Vol 31, Issue 12

Send Gtkmm-forge mailing list submissions to
	gtkmm-forge lists sourceforge net

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/gtkmm-forge
or, via email, send a message with subject or body 'help' to
	gtkmm-forge-request lists sourceforge net

You can reach the person managing the list at
	gtkmm-forge-owner lists sourceforge net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Gtkmm-forge digest..."


gtkmm-forge is the mailing list that receives gtkmm bug reports from bugzilla.  A daily digest is sent to gtkmm-main, to encourage people to help fixing the bugs. Do not try to unsubscribe gtkmm-forge from gtkmm-list.


Today's Topics:

   1. [Bug 565487] New: Glib::spawn_async* functions	don't work
      with exceptions disabled (glibmm (bugzilla.gnome.org))
   2. [Bug 565454] Problematic packaging of 0.9.8
      (gnomemm (bugzilla.gnome.org))
   3. [Bug 565454] Problematic packaging of 0.9.8
      (gnomemm (bugzilla.gnome.org))
   4. [Bug 565454] Problematic packaging of 0.9.8
      (gnomemm (bugzilla.gnome.org))
   5. [Bug 565454] Problematic packaging of 0.9.8
      (gnomemm (bugzilla.gnome.org))
   6. [Bug 565454] Problematic packaging of 0.9.8
      (gnomemm (bugzilla.gnome.org))


----------------------------------------------------------------------

Message: 1
Date: Tue, 23 Dec 2008 18:04:58 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 565487] New: Glib::spawn_async*
	functions	don't work with exceptions disabled
To: gtkmm-forge lists sourceforge net
Message-ID: <bug-565487-5595 http bugzilla gnome org/>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=565487

  glibmm | general | Ver: unspecified
           Summary: Glib::spawn_async* functions don't work with exceptions
                    disabled
           Product: glibmm
           Version: unspecified
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: general
        AssignedTo: gtkmm-forge lists sourceforge net
        ReportedBy: jonathon quotidian org
         QAContact: gtkmm-forge lists sourceforge net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


notice:

73      void spawn_async_with_pipes(const std::string& working_directory,
74      const Glib::ArrayHandle<std::string>& argv,
75      const Glib::ArrayHandle<std::string>& envp,
76      SpawnFlags flags,
77      const sigc::slot<void>& child_setup,
78      Pid* child_pid,
79      int* standard_input,
80      int* standard_output,
81      int* standard_error)
82      {
83      const bool setup_slot = !child_setup.empty();
84      sigc::slot<void> child_setup_ = child_setup;
85      GError* error = 0;
86      
87      g_spawn_async_with_pipes(
88      working_directory.c_str(),
89      const_cast<char**>(argv.data()),
90      const_cast<char**>(envp.data()),
91      static_cast<GSpawnFlags>(unsigned(flags)),
92      (setup_slot) ? &child_setup_callback : 0,
93      (setup_slot) ? &child_setup_ : 0,
94      child_pid,
95      standard_input, standard_output, standard_error,
96      &error);
97      
98      if(error)
99      Glib::Error::throw_exception(error);
100     } 

If glibmm is build with exceptions disabled, the Glib::Error::throw_exception()
function simply returns a std::auto_ptr<> with the error, but we dont' do
anything with it, we just let it go out of scope at the end of the function. 
So the user has no way of knowing that the function failed.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=565487.



------------------------------

Message: 2
Date: Wed, 24 Dec 2008 10:07:05 +0000 (UTC)
From: "gnomemm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 565454] Problematic packaging of 0.9.8
To: gtkmm-forge lists sourceforge net
Message-ID: <20081224100705 AA08823F51B label gnome org>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=565454

  gnomemm | gstreamermm | Ver: unspecified

Murray Cumming changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |murrayc murrayc com




------- Comment #2 from Murray Cumming  2008-12-24 10:07 UTC -------
The generated files should be distributed in the tarball just as they are for
gtkmm.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=565454.



------------------------------

Message: 3
Date: Wed, 24 Dec 2008 17:36:46 +0000 (UTC)
From: "gnomemm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 565454] Problematic packaging of 0.9.8
To: gtkmm-forge lists sourceforge net
Message-ID: <20081224173646 5FF7923F51B label gnome org>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=565454

  gnomemm | gstreamermm | Ver: unspecified




------- Comment #3 from Jos? Alburquerque  2008-12-24 17:36 UTC -------
I see.  From the discussion of bug #560601 I was under the impression that not
all plug-ins are guaranteed to exist in the target system.
This is the relevant comment:

> Comment #16 from Sebastian Dr?ge    (reporter, points: 21)
>2008-11-16 07:21 UTC [reply]
>
>Ok, that makes sense then IMHO. One question though, how do you want to wrap
>the plugins/elements? I mean, their instance/class struct sizes are not
>guaranteed to stay the same as they're not part of the ABI. You could only
>create hand-written wrappers that only access the elements via generic
>interfaces like GObject properties, gstreamer interfaces, etc. Also
>distributors might want to choose to not include some elements, it's not
>guaranteed that everybody has audioresample for example :)

With this in mind, I thought that it'd be necessary to have the plug-ins
generated during the build process.  If the plug-ins exist on the system, their
source would be generated.  If not, that plug-in would not be included during
the build and hence not included in the target system.

OTOH, if the files are included in the tarball and a plug-in does not exist,
what would happen if a user tries to create one of them?  I suppose that the
creation would simply fail and that would be acceptable.  Should things be
modified then so that the plug-in source files are included in the tarball even
if not all plug-ins are guaranteed to exist in the target system?


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=565454.



------------------------------

Message: 4
Date: Wed, 24 Dec 2008 18:41:32 +0000 (UTC)
From: "gnomemm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 565454] Problematic packaging of 0.9.8
To: gtkmm-forge lists sourceforge net
Message-ID: <20081224184133 0029623F51A label gnome org>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=565454

  gnomemm | gstreamermm | Ver: unspecified




------- Comment #4 from Murray Cumming  2008-12-24 18:41 UTC -------
> With this in mind, I thought that it'd be necessary to have the plug-ins
> generated during the build process.  If the plug-ins exist on the system, their
> source would be generated.  If not, that plug-in would not be included during
> the build and hence not included in the target system.

But plugins could be installed _after_ the build. I would expect applications
need to do some runtime investigation to know whether a plugin is really
available.

I also generally dislike an API that has so many variations. At the least, we
would need some way to #ifdef around the variations in the API. But maybe you
have that already.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=565454.



------------------------------

Message: 5
Date: Wed, 24 Dec 2008 19:10:23 +0000 (UTC)
From: "gnomemm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 565454] Problematic packaging of 0.9.8
To: gtkmm-forge lists sourceforge net
Message-ID: <20081224191023 99BDD23F51A label gnome org>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=565454

  gnomemm | gstreamermm | Ver: unspecified

Jonathon Jongsma (jonner) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jonathon quotidian org




------- Comment #5 from Jonathon Jongsma (jonner)  2008-12-24 19:10 UTC -------
But couldn't you generate the source for all plugins and only *build* those
that are detected on the target system?  That's basically what we do for the
different cairomm surface types.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=565454.



------------------------------

Message: 6
Date: Wed, 24 Dec 2008 21:05:44 +0000 (UTC)
From: "gnomemm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 565454] Problematic packaging of 0.9.8
To: gtkmm-forge lists sourceforge net
Message-ID: <20081224210544 7E81323F51A label gnome org>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=565454

  gnomemm | gstreamermm | Ver: unspecified




------- Comment #6 from Jos? Alburquerque  2008-12-24 21:05 UTC -------
(In reply to comment #4)
> But plugins could be installed _after_ the build. I would expect applications
> need to do some runtime investigation to know whether a plugin is really
> available.

Yes.  Existence of a plug-in is determined in the C API, AFAICT, when 1) there
is an attempt to create an element using the plug-in name with
gst_element_factory_make[1] or when 2) there is an attempt to load the plug-in
with gst_plugin_feature_load[2] after finding it with
gst_element_factory_find[3] (A GstElementFactory is also a GstPluginFeature). 
In both cases a return of NULL from the functions indicates that there is no
such plug-in in the system.

> 
> I also generally dislike an API that has so many variations. At the least, we
> would need some way to #ifdef around the variations in the API. But maybe you
> have that already.

The way things work presently is that there are two lists of all possible
plug-ins (one for the core plug-ins -- in the gstreamer branch, the other for
the base plug-ins -- in the gstreamerbase branch) in the
src/Makefile_list_of_hg.am_fragment files.

For each plug-in in the lists, the plug-in generator attempts to load the
plug-in.  If it succeeds, it generates a preliminary .hg file which is run
through m4 to generate the gmmproc .hg file and a .ccg file.  If the generator
fails, empty .hg and .ccg files are generated with a comment in the .hg file
saying that the plug-in is not available.  The plug-in .hg and .ccg files are
not distributed in the tarball but they are installed using nodist_*_SOURCES in
the Makefile.am of the *mm directories of the two branches, gstreamer and
gstreamerbase.

(In reply to comment #5)
> But couldn't you generate the source for all plugins and only *build* those
> that are detected on the target system?  That's basically what we do for the
> different cairomm surface types.

Building would not be a problem; I tested and building would not fail even if
the plug-in does not exist in the system because the C++ code is
self-contained, doesn't include any headers from the C API plug-ins (because it
can't since these are not public) and generates the necessary structures, etc.
to guarantee successful compilation.

The problem, I think, is when the wrap_init() functions execute:  The plug-in
generator generates a *_get_type() function for each plug-in which first makes
sure the plug-in is loaded and then gets the GType of the loaded plug-in using
gst_element_factory_get_element_type[4].  If there is no plug-in on the system,
the _get_type() function would return 0 and this would be a serious problem
during initialization.  Makes any sense?

[1]
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstElementFactory.html#gst-element-factory-make
[2]
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstPluginFeature.html#gst-plugin-feature-load
[3]
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstElementFactory.html#gst-element-factory-find
[4]
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstElementFactory.html#gst-element-factory-get-element-type


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=565454.



------------------------------

------------------------------------------------------------------------------


------------------------------

_______________________________________________
Gtkmm-forge mailing list
Gtkmm-forge lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/gtkmm-forge


End of Gtkmm-forge Digest, Vol 31, Issue 12
*******************************************
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]