Re: [Catalyst] Contributing code
On Mon, Jun 21, 2010 at 13:48, Sir Robert Burbridge wrote: > Out of a discussion last week, I have some code to contribute (largely to > Catalyst::Helper). > > Two quick questions: > > 1) I've never contributed code to a project outside my work before. How do > I go about it? Have you read http://wiki.catalystframework.org/wiki/contrib ? > 2) I've noticed many times in the CPAN modules I've looked through tend to > be very sparsely commented (disregarding POD). I tend to do a fair bit of > inline comments (maybe about 1:2 comments:code). Is there some reason I > should keep comments sparse in contributed code? It depends on what sort of comments you're making. Comments that explain tricky code that help with maintenance down the road are welcome everywhere. If you're just making comments that help someone completely unfamiliar with Catalyst to read the code it'll probably be more distracting than helpful to core devs. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Dist::Zilla + Catalyst?
On Wed, Apr 28, 2010 at 15:29, Matt S Trout wrote: > On Wed, Apr 28, 2010 at 03:20:05PM +, Ęvar Arnfjörš Bjarmason wrote: >> On Wed, Apr 28, 2010 at 14:30, Matt S Trout wrote: >> > In the case of Catalyst applications, the standard assumption that a >> > checkout >> > and a final dist look much the same (as is normal for CPAN) is used quite >> > substantially; so I'd say that in this case Dist::Zilla's philosophical >> > decision to violate that convention makes it a suboptimal choice. >> >> Thats more a tenet of how Ricardo Signes (the dzil author) likes to >> work than a core assumption of Dist::Zilla. > > Fair point; though if you don't use it that way I'm not really convinced > it does anything that Module::Install/etc. doesn't already do just fine. It's (at least for me) mainly about removing the duplicate work that goes into release. The *only* thing that I do when releasing now, aside from editing the code, is manually updating the Changes file, and I usually do that as I go. Then it's just `dzil release`. Before that I had to maintain a MANIFEST, dependencies in Makefile.PL, $VERSION in all my files, `git tag $VERSION` && `git push` after release. In addition I had boilerplate like README and LICENSE that either had to be generated from something else in the distro, or copy/pasted into every repository. I'm willing to bet that you have to fiddle around more than I at release time :) >> There's no reason why Catalyst distros cant work with dzil.ini that I >> can see. Are there hooks available for catalyst.pl so that it can >> generate Dist::Zilla based distros instead of using Module::Install? > > The whole thing's generated from templates so far as I'm aware - don't see > why you couldn't (or if it isn't already exposed why it wouldn't given a > trivial patch). > > But rather the point of catalyst.pl is that it's "one sane way" to do things. > > I stick to the standard layout for most things in apps I work on not because > it's necessarily my favourite, but because it's a common standard that > anybody working on Catalyst apps is going to be familiar with. As Stevan says: catalyst.pl's behavior (and not being able to change it) is the aspect of Catalyst that irks me the most. When I create a project the first thing I have to do is clean the boilerplate the install script added. When I create models / views / controllers with it, I usually have to at least go edit the POD afterwards to make it sane. It would be nice if someone made it pluggable so that you could easily set your preferred build system / starting template in a global config somewhere, along with an easy way to use other people's configs or upload your own from the CPAN. I don't use Catalyst enough to justify doing the work needed for that to myself, especially if people would rather have "one true way" to do it. But if someone did implement it I'd be a very happy (infrequent) user. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Dist::Zilla + Catalyst?
On Wed, Apr 28, 2010 at 14:30, Matt S Trout wrote: >> I'm sorry, I thought that the location of 'Home' was set based on the >> Makefile.PL. Reviewing the documentation, I see a dist.ini file can also >> serve for that purpose. > > However, one of the tenets of Dist::Zilla is that your base directory need > not look anything like the final distribution. > > In the case of Catalyst applications, the standard assumption that a checkout > and a final dist look much the same (as is normal for CPAN) is used quite > substantially; so I'd say that in this case Dist::Zilla's philosophical > decision to violate that convention makes it a suboptimal choice. Thats more a tenet of how Ricardo Signes (the dzil author) likes to work than a core assumption of Dist::Zilla. The only modification Dist::Zilla does of my distributions is to add $VERSION variables to my packages with the PkgVersion plugin. You can skip even that and manually upgrade $VERSION like you do now. There's no reason why Catalyst distros cant work with dzil.ini that I can see. Are there hooks available for catalyst.pl so that it can generate Dist::Zilla based distros instead of using Module::Install? ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On Mon, Apr 26, 2010 at 09:36, Dermot wrote:
> On 21 April 2010 18:01, J. Shirley wrote:
>> __END__
>> Benchmark: running all, low, sep for at least 1 CPU seconds...
>> all: 1 wallclock secs ( 1.11 usr + 0.00 sys = 1.11 CPU) @
>> 2917341.44/s (n=3238249)
>> low: 0 wallclock secs ( 1.27 usr + 0.04 sys = 1.31 CPU) @
>> 12930179.39/s (n=16938535)
>> sep: 1 wallclock secs ( 1.21 usr + 0.01 sys = 1.22 CPU) @
>> 3223081.15/s (n=3932159)
>>
>> Subroutines suck, lets all use hashrefs.
>
> Now that it's quietened down, I can ask a question. Does this I mean
> it's preferable to use
>
> $c->req->{parameters}->{foo}
>
> rather than
>
> $c->req->param('foo')
>
> Obviously I'd rather use the faster method but if I'm breaking the
> encapsulation in some ways that's going to bite me later, I'd steer
> clear.
"Obviously".
Unless you're doing method calls in a tight loop somewhere in your
code you *shouldn't care about this*. Now I've written code that
actually *did* suffer from method call overhead but since you're just
casually asking it's very unlikely that you're doing the same.
Don't sprinkle premature optimizations around your codebase just
because someone produced a benchmark showing one is faster than the
other. You should be doing *profiling* of your entire program, not
micro-optimizing something that's likely 0.0001% of its total runtime.
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Dist::Zilla + Catalyst?
On Sun, Apr 25, 2010 at 15:39, John SJ Anderson wrote: > Is anybody using Dist::Zilla in combination with Catalyst? If so, are you > just not using it to generate your Makefile.PL or are you working around the > issues that presents in some other way? I'm using it for a plugin I have (Catalyst::Plugin::Upload::Digest). What issues are you talking about? ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Data::Localize::Railsy for rails-like i18n in Catalyst
On Mon, Jan 4, 2010 at 01:02, Matthias Dietrich wrote:
> Am 04.01.2010 um 01:44 schrieb Ævar Arnfjörð Bjarmason :
>
>> I just uploaded Data::Localize::Railsy to CPAN for use in the Catalyst
>> app I was building:
>>
>> http://search.cpan.org/dist/Data-Localize-Railsy/ (not yet indexed
>> as of writing)
>>
>> I wrote it because I didn't like the existing Gettext frameworks for
>> internationalization and prefer something where you don't specify the
>> human readable source text in your code/templates but an abstract key,
>
> Did you take a look at Locale::Maketext::Lexicon::DBI with its Catalyst
> plugin C::P::I18N::DBI? There you are suggested to have an abstract key
> that belongs to one sentence in each language. It supports every
> gettext/maketext "interpolation" and so on.
Yeah and I didn't want to run DBI :) Actually you could also do this
with the Gettext plugin:
msgid "an.abstract.id"
msgstr "Hello there [_1]"
$c->loc("an.abstract.id", "your name here");
So you can coerce most backends to accept the sort of stuff I did. I
just wanted something with a simple tree-structure hash. I also have a
backend for it already at Translatewiki (http://translatewiki.net/)
which is a plus.
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] Data::Localize::Railsy for rails-like i18n in Catalyst
I just uploaded Data::Localize::Railsy to CPAN for use in the Catalyst app I was building: http://search.cpan.org/dist/Data-Localize-Railsy/ (not yet indexed as of writing) I wrote it because I didn't like the existing Gettext frameworks for internationalization and prefer something where you don't specify the human readable source text in your code/templates but an abstract key, here's how it looks like in practice: Template: http://github.com/avar/App-OpenStreetMapIs-Web/blob/master/root/_sidebar.tt The translation file: http://github.com/avar/App-OpenStreetMapIs-Web/blob/master/lib/App/OpenStreetMapIs/I18N/is.yml And here are further POD docs on how to use it (this'll be easier to read on search.cpan.org once it's indexed): http://github.com/avar/data-localize-railsy/blob/master/lib/Data/Localize/Railsy.pm Anyway I hope it's useful for someone. Now I just have to find out how to make some drop-down menu that sets a language cookie when you change it so that I can use this stuff myself :) ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Gitalist arrives on CPAN
Is there a demo site? ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
