Re: How do I indicated modules used by Makefile.PL (or Build.PL) ?

[Torsten Schoenfeld]

On 09.08.2011 09:11, Gabor Szabo wrote:

So I tried

configure_requires 'File::Copy::Recursive' =>  0;
require File::Copy::Recursive;

but that still blows up when I run Makefile.PL


Yes, configure_requires is the way to go.  If a CPAN client sees that, 
it will fetch the requirement before running Makefile.PL/Build.PL. 
Then wrap your 'use' call in an eval and if that fails, show an 
informative message to the user, and exit with exit code 0 so that CPAN 
testers know that their system is not supported.  See also 
.

Re: Reflex extensions namespace?

[Torsten Schoenfeld]

On 24.05.2010 09:06, Rocco Caputo wrote:

CPAN has a de facto standard of appending X to make "extensions"
namespaces. Does that make sense for namespaces that end in X already?
If not, please suggest alternatives.


For Gtk2, we settled on Gtk2::Ex.  For example, Gtk2::Ex::VolumeButton.

Re: Package aliases and isa()

[Torsten Schoenfeld]

Rafael Garcia-Suarez wrote:
So I wonder if it is safe to rely on the behavior exhibited by perl >= 5.8.  Or 
is it just some implementation-dependent artifact?  Is there a better way to 
achieve what I want?


I think it's safe.


OK, thanks for the confirmation.


A quick look shows that bleadperl does not have tests for this behaviour
in t/mro/*.t. I suggest that you turn your example program into a test
and submit it to perl5-porters. The best way to ensure that a behaviour
will not break in a next release is to add a regression test for it :)


Good idea.

Package aliases and isa()

[Torsten Schoenfeld]

Aloha,

over in gtk2-perl land, we'd like to split out the Gtk2::Pango stuff from the 
Gtk2 module into its own module with the namespace Pango.  We would like to do 
this in a backwards compatible way so that any code that is using the 
Gtk2::Pango stuff continues to work just fine when we switch Gtk2 over to use 
the new Pango.


So we basically do this in Gtk2.pm:

  use Pango;
  {
no strict 'refs';
foreach my $key (keys %Pango::) {
  *{'Gtk2::Pango::' . $key} = *{'Pango::' . $key};
}
  }

For some reason, this has the effect that the following lines both evaluate to 
true:

  Pango::Layout->isa (Gtk2::Pango::Layout::);
  Gtk2::Pango::Layout->isa (Pango::Layout::);

Now, that's really good because we need those to evaluate to true for backwards 
compatibility.  The problem is that I don't understand *why* they are true.


I attach a simple standalone program that demonstrates this behavior.  perl 
5.8.8, 5.10.0, and blead all output two "1"s when running this program on my 
machine.  perl 5.6.2, however, evaluates "New->isa(Old::)" to false.


So I wonder if it is safe to rely on the behavior exhibited by perl >= 5.8.  Or 
is it just some implementation-dependent artifact?  Is there a better way to 
achieve what I want?


-Torsten
package New;
use strict;
use warnings;

package Old;
use strict;
use warnings;

{
  no strict 'refs';
  *{'Old::'} = *{'New::'};
}

package main;
use strict;
use warnings;

warn Old->isa(New::);
warn New->isa(Old::);

ExtUtils::MakeMaker strips important linker flags

[Torsten Schoenfeld]

Aloha,

the shared object in one of my modules, Gtk2::MozEmbed, needs to be
linked in a way that makes sure the Mozilla libs can be found at run
time.  For this to work, libgtkmozembed's pkg-config file[1] specifies
that "-Wl,-rpath -Wl,${libdir}" be used as arguments to the linker.
Unfortunately, ExtUtils::MakeMaker strips linker flags that don't look
like -lxxx[2].

I've been using LD_RUN_PATH as a workaround, but apparently that stopped
working some time ago.

So, is this a bug in EU::MM?  Or is the stripping done intentionally?
If it's not a bug, what do I do if there are vital linker flags like the
above?

-- 
Bye,
-Torsten

[1] Usually /usr/lib/{firefox,mozilla}-gtkmozembed.pc.
[2] In lib/ExtUtils/Liblist/Kid.pm, sub _unix_os2_ext.

Re: Introduction Letter

[Torsten Schoenfeld]

On Sun, 2005-02-27 at 16:28 -0800, Ofer Nave wrote:

> 2) requesting feedback on design/implementation

For reviews there's also the code-review-ladder:

  http://lists.netthink.co.uk/listinfo/code-review-ladder

-- 
Bye,
-Torsten

Re: Name for GStreamer bindings

[Torsten Schoenfeld]

On Sat, 2005-02-26 at 15:14 -0500, Randy W. Sims wrote:

> > That's the question.  What do others think?
> 
> I'd consider it a very bad practice. Imagine if many authors started 
> doing the same. There could be unpredictable collisions all over the 
> place. It defeats the CPAN scheme for ensuring unique namespaces.

That's a problem indeed.

> I still don't see the problem of using a proper namespace. Arguments of 
> length are not compelling. What's wrong with a descriptive name?

I tried to explain this two times already.  If it doesn't convince you,
well, there's nothing more I can do.  If you had ever used a module such
as Gtk2 or Gnome2, you'd understand.

-- 
Bye,
-Torsten

Re: Name for GStreamer bindings

[Torsten Schoenfeld]

On Fri, 2005-02-25 at 09:43 +0100, A. Pagaltzis wrote:

> > >   use constant Gst=>'Multimedia::Gstreamer';
> > > 
> > >   Gst->new();
> > 
> > I just realized that this won't work.  I don't just need Gst to
> > be an alias for Media::GStreamer, I need Gst::* to be an alias
> > for Media::GStreamer::*.  That also seems to rule out the
> > aliased.pm approach.
> 
> Why? Sure, you need many constants, not just one, but does that
> matter?

No, not really.  It seems a bit cumbersome, but I guess it would work.

> Something that doesn't seem to have come up in debate here is
> that the distribution and main module namespace need not dictate
> the package names for classes. You could well stick everything in
> Gst:: even though your modules are called Media::GStreamer(::.*)?.

This sounds very evil, but might actually work!  This would solve the
problem in a pretty elegant way:  No top-level CPAN pollution, but a
usable namespace.

> Is this a bad idea even if it's clearly documentent?

That's the question.  What do others think?

-- 
Bye,
-Torsten

Re: Name for GStreamer bindings

[Torsten Schoenfeld]

On Wed, 2005-02-23 at 18:55 +, Orton, Yves wrote:

> > I tried to explain that in my original mail.  The GStreame bindings, 
> > just like Gtk2 or Gnome2, are different.  You don't just use one 
> > constructor once.  Typical applications will have to create many 
> > Gst::Element's, a few Gst::Structure's, some Gst::Index's,  
> > Gst::Caps's, a Gst::Clock, etc., etc.  Try imagining how long this  
> > paragraph would be if I used Multimedia::GStreamer as the namespace.
> 
> Export a constant Gst() that equals Multimedia::Gstreamer.
> 
> Ie the moral equivelent of 
> 
>   use constant Gst=>'Multimedia::Gstreamer';
> 
>   Gst->new();

I just realized that this won't work.  I don't just need Gst to be an
alias for Media::GStreamer, I need Gst::* to be an alias for
Media::GStreamer::*.  That also seems to rule out the aliased.pm
approach.

> Or make a factory sub: 
> 
> sub GstNew { 
>   my $class="Multimeadia::Gstreamer::".shift(@_); 
>   return $class->new(@_); 
> }
> 
> And also possibly a clone method:
> 
> my $elem=GstNew("Clock"); 
> my $other_elem=$elem->clone();

That would work, but seems way too hacky to me.  It would also deviate
quite a bit from the C API, which I want to avoid.  Thanks for the
suggestion nonetheless, though.

-- 
Bye,
-Torsten

Re: Name for GStreamer bindings

[Torsten Schoenfeld]

On Wed, 2005-02-23 at 18:25 +, Smylers wrote:

> If all modules have really short names then nobody knows when anybody
> else's modules are for, which rather defeats the purpose of Cpan.  Cpan
> is a global namespace, and as such names have to be chosen carefully to
> be as meaningful as possible to people who don't share the author's
> context.

Yeah, I agree.  That's why I like Mark's proposal of using aliased.pm to
alias something like Media::GStreamer to Gst.

> > I need something that is easy and fast to type.
> 
> Why?  I can see why you'd _like_ something that's less to type, but why
> is there a need that applies to this module rather than other modules.
> You only have to type the module name in the use line and in any class
> methods, often just a constructor.

I tried to explain that in my original mail.  The GStreamer bindings,
just like Gtk2 or Gnome2, are different.  You don't just use one
constructor once.  Typical applications will have to create many
Gst::Element's, a few Gst::Structure's, some Gst::Index's, Gst::Caps's,
a Gst::Clock, etc., etc.  Try imagining how long this paragraph would be
if I used Multimedia::GStreamer as the namespace.

> "GST" can mean many things (try Googling for it) -- even within the
> context of Gnome it has another meaning:

It's the object prefix the library itself uses, and also has other
precedents.

-- 
Bye,
-Torsten

Re: Name for GStreamer bindings

[Torsten Schoenfeld]

On Wed, 2005-02-23 at 00:26 -0500, Randy W. Sims wrote:

> Multimedia::GStreamer

What about just using Media::GStreamer and aliasing it to Gst?  That
would introduce a new top-level namespace, but I think it makes sense to
have it.

> I don't see any advantage of using Gst over GStreamer as a name, they 
> both describe the same thing and GStreamer is a tad more helpfull (to 
> google a description).

It's all about the length.  I need something that is easy and fast to
type.

> Then Gnome part as mentioned seems irrelevant. Glib is possibly usefull
> info, but probably better conveyed via documentation as an
> implementation issue.

Agreed.

> It might be nice to "say" somethnig about what it does: plugin,
> pipeline... I can't think of a better word.

Well, that's just an implementation detail too, isn't it?

-- 
Bye,
-Torsten

Re: Name for GStreamer bindings

[Torsten Schoenfeld]

On Wed, 2005-02-23 at 14:08 +0100, David Landgren wrote:

> Another alternative is to let the user choose. Take a look at Yves' 
> Data::Dumper::Streamer module. During the installation, the user has a 
> choice of additionally installing it in the DDS namespace (this does not 
> occur by default).

That doesn't sound like a good idea to me.  Application writers couldn't
be sure if they can use the short version of the package name, since
it's up to the user/package if it gets enabled.

-- 
Bye,
-Torsten

Re: Name for GStreamer bindings

[Torsten Schoenfeld]

On Tue, 2005-02-22 at 21:29 -0500, Mark Stosberg wrote:

> One option would be to use a very clear top level name space
> and used 'aliased' internally to call it 'Gst'.
> 
>  http://search.cpan.org/~ovid/aliased-0.11/lib/aliased.pm

That sounds like a good idea.  The only nag is that it's a very young
module and only a few distributions have it.  But I guess that if the
packager can create a package for the GStreamer bindings, he can do it
for aliased too while he's at it.

-- 
Bye,
-Torsten

Name for GStreamer bindings

[Torsten Schoenfeld]

Aloha,

GStreamer is a powerful and pretty popular media framework.  GNOME
already uses it extensively, and KDE just started to.  It's based on
GLib and uses its object oriented C API style.  The objects have names
like GstQueue or GstElement.

For similar objects like GtkWindow or GnomeIconList in other libraries,
us Gtk2-Perl people tend to directly map them to namespaces:
Gtk2::Window and Gnome2::IconList.  For smaller libraries like libwnck
or librsvg, on the other hand, we try not to pollute the top-level
namespace: Gnome2::Wnck::Screen, Gnome2::Rsvg::Handle, etc.

For GStreamer, I would tend towards using Gst as a namespace.  It
matches the C objects' names.  It's short to type, which is not
unimportant since it's not like the typical Perl OO module where the
full package name only appears once when using the constructor -- the
GStreamer bindings contain a lot of objects with their own constructors,
many of which almost all programs will use.  It's not directly
GNOME-related.  And lastly, Gst has a precedent: the Python bindings
also use this namespace.

On the con side, there's of course the introduction of a new top-level
namespace.  One that is an abbreviation and not easily recognizable.

So, if you were to write Perl bindings for GStreamer, what namespace
would you use?

-- 
Thanks,
-Torsten