+++ /dev/null
-15:36 <t0m> right. so the first thing to do is probably write a test to check
- generating an application doesn't change.
-15:37 <dhoss> per app?
-15:38 <t0m> no, I mean whilst you're ripping ::Helper apart.
-15:38 <dhoss> OH
-15:38 <dhoss> gotcha
-15:38 <t0m> if you install your branch.. Then catalyst.pl t/TestAppForComparison
-15:39 <dhoss> so we have the same results now as before, yes?
-15:39 <t0m> then you write a test which says catalyst.pl /tmp/TempTestApp; my
- $diff = `diff -urN t/TestAppForComparison /tmp/TempTestApp`; ok
- !length($diff) or warn $diff;
-15:40 <t0m> exactly. and that'll test you rip all of the files out of Helper.pm
- correctly..
-15:40 <dhoss> okay, TestAppForComparison created. i'll commit that initial
- version
-15:40 <t0m> you'll probably want to nuke it after that, as testing the
- generated strings of an entire app dir is gonna be a PITA
-15:41 <t0m> to maintain
-15:41 <dhoss> i could see that
-15:41 <t0m> But it's totally the right solution whilst you're trying to rip
- stuff out without changing it
-15:41 <dhoss> temp testing :-D
-15:44 <t0m> I've got some ideas on doing better testing that the TestApp we
- generate is good.
-15:44 <t0m> but they're a bit more involved, and not needed for this at all ;)
-15:45 <dhoss> this being this refactor, or this bit of the refactor?
-15:45 <t0m> the latter.
-15:45 <dhoss> okay - got it
-15:46 <t0m> and once this is done - you can branch again to work on the code,
- and again to work on the generated app templates (as we'll want to
- moosify those, so your app is moosetastic by default
-15:46 <t0m> and as it's all in different files - you can do both in parallel as
- you feel like and safely merge back
-15:47 <t0m> did you get to grips with MX::GetOpt and do you have a plan for
- that yet?
-15:48 <dhoss> so one branch for helper_refactor, one for code (which code?),
- and one for app templates
-15:48 <t0m> As I guess catalyst.pl should be taught to use it, and so should
- the generated scripts :)
-15:48 <dhoss> i've been playing with MX::GetOpt, i need a few more details on
- what exactly needs to be beat up
-15:48 <t0m> yy, but you branch from completed helper_refactor :)
-15:49 <t0m> and 'code' is the actual refactor / api changes for helpers
-15:49 <t0m> bletch
-15:50 <dhoss> okay, so the 'code' branch will be simply the C::H code branched
- from helper_refactor
-15:50 <t0m> get_file has to keep working as everything using ::Helper needs it
-15:50 <t0m> yes, exactly.
-15:51 <t0m> so you need to make a get_file_from_sharedir function or something
-15:51 <dhoss> okay, making sense now :-)
-15:51 <t0m> and change things over to use that.
-15:51 <t0m> that's fine though - means you can extract 1 file at a time
-15:52 <dhoss> which would be better, no? better atomicity and for testing
-15:52 <t0m> yy
-15:52 <t0m> bletch was at the fact that 'get_file' is a good method name, and
- it's now deprecated
-15:53 <dhoss> is that in C::H?
-15:53 <t0m> yy
-15:53 * dhoss is a little behind in my api knowledge
-15:53 <dhoss> off the top of my head at least
-15:53 <t0m> it's the 'get me a file out the <DATA> section' method
-15:53 <dhoss> aha right
-15:54 <t0m> which you're replacing in favour of 'get me a file out of the share
- dir'
-15:54 <t0m> and 'copy file out of sharedir' methods.
-15:54 <t0m> The former for templates
-15:54 <t0m> the latter for binaries, which gets rid of the hateful decoding and
- writing out business
-15:54 <dhoss> get -> we're going to interpolate shit, copy -> we're giong to
- use directly?
-15:55 <t0m> just so
-15:55 <t0m> eliminating the 'please turn this giant hex string back into
- binary' thing
-15:55 <dhoss> definitely :-P
-16:00 <t0m> sub _mk_favicon {
-16:00 <t0m> my ( $self ) = @_;
-16:00 <t0m> $self->copy_share_file(
-16:00 <t0m> File::Spec->catfile( ( caller(0) )[0], 'favicon.ico' ),
-16:00 <t0m> File::Spec->catfile( $self->{root}, "favicon.ico" )
-16:00 <t0m> );
-16:00 <t0m> }
-16:00 <t0m> sumfin like dat
-16:01 <dhoss> easy enough
-16:01 <t0m> the actually, all the caller crap dies too
-16:02 <dhoss> hrm, i suppose we have to keep the atrocious
- Class::Accessor::Fast method name artifacts?
-16:02 <t0m> that's to clue get_file what file to borg crap out off
-16:03 <t0m> I vote that most of them can burn, as we'll be working out what
- shit to copy a lot more dynamically
-16:03 <t0m> and the ones which can't get deprecated, but preserved.
-16:04 <dhoss> so that's just for the current get_file, right?
-16:04 <t0m> yy
-########################################################################
-## done
-16:04 <t0m> $self->copy_share_file(
-16:04 <t0m> 'favicon.ico',
-16:04 <t0m> File::Spec->catfile( $self->{root}, "favicon.ico" )
-16:04 <t0m> );
-#########################################################################
-16:05 <t0m> more like it
-16:05 <t0m> so we have sub mk_foo { shift->generate_foo(@_); }
-
-====
-5-28
-03:04 < dhoss> SO. official next step: 1) #done trim crap out 2) #done write test for how
- helpers are invoking Catalyst::Helper 3)??? 4) profit!
-03:05 < t0m> 3)#done Re arrange files in sharedir so we can make the comversion guts
- totally generic
-03:05 < t0m> 4) merge&profit
-03:05 < t0m> *conversion
-03:05 < dhoss> rearrange meaning mv foo MyApp?
-03:06 < t0m> erm, yes, as described above, so that the contents of share/ is
- laid out the same as a newly generated MyApp
-03:06 < dhoss> OH
-03:06 < dhoss> okay
-03:06 < dhoss> instead of my current fuckery :-)
-03:06 < dhoss> autarch: btw if you have an idea for that i'd love an email to
- the one in topic
-03:06 < t0m> cause then the entire generate application becomes 'copy this
- directory from X => Y, applying some file mangling rules)
-
-=============================================================================
-04:26 < t0m> dhoss: erm, yeah - so the two things to do is: unit tests for the
- methods like get_file which we're not actually using any more..
-04:27 < t0m> (do that by making t/lib/ExampleHelper.pm - copy the TT one from
- CPAN or something, and then write some tests that get_file can
- successfully pull chunks out the __DATA__ segment
-04:28 < t0m> and rename everything in the sharedir to be named as-per where it
- ends up in your app, but suffixed by .tt or .bin
-04:29 < t0m> e.g. share/Makefile.PL.tt share/root/favicon.ico.bin
- share/lib/MyApp.pm.tt
-04:30 < t0m> the exact reasons for this nameing scheme become aparent post
- first merge, when we remove most of the code :)
-04:30 < t0m> but all of share/ needs to be in it's final resting place pre-merge
-04:31 < marcus> http://lumberjaph.net/blog/index.php/2009/05/30/catalystxdispatcherasgraph/ # <3 lazyweb
-04:31 < t0m> so tests the stuff we're no longer using in Helper.pm (e.g.
- get_file) still works. Rename share/ bits
-04:31 < t0m> marcus: Indeed :)
-04:31 < t0m> ^^ those two, then first merge.
-23:36 <@kd> dhoss: just found a bug in ::Devel ...
-23:36 <@kd> we're using #!/usr/bin/env perl now
-23:36 <@kd> that means we have to add the use warnings; pragma beneath it
-23:37 <@kd> that doesn't appear to be happeining in the scripts
-23:37 <@kd> please fix
-23:38 <@kd> dhoss: i.e. http://gist.github.com/122081
-==============================================================================
-
-# DONE
-1. Rename everything into final layout:
- . tt files all named .tt
- . none tt files all named .bin
- . directory structure as generated, e.g. share/lib/MyApp.pm.tt, share/root/favicon.ico.bin
-
-2. get new layout working
-
-
-# DONE
-3. get tests for back compat - i.e. the methods no longer used in Helper.pm like 'get_file'
- . copy Catalyst::Helper::View::TT into t/lib/TestBackCompat.pm
- . write test t/deprecated_methods_backcompat.t which says:
- use FindBin qw/$Bin/;
- use lib "$Bin/lib";
- use Test::More tests => 1;
-
- my $helper = TestBackCompat->new( %maybe_some_params_here );
- my $a_section = $helper->get_file('FileName');
- is $a_section, 'FILECONTENTSFROM__DATA__';
-
-3. RFC - DONE
-
-Looking ahead
-
-MooseX::Getopt
-
-################################################################################
-17:46 < t0m> dhoss: erm, oh, so the _other_ thing I didn't think of
-17:46 < t0m> Is Cat works on windows
-17:46 < t0m> I have stuffed loads of "t/foo.t"
-17:46 < t0m> into strings.
-17:46 < t0m> which will break win
-17:47 < t0m> so, all those places where I just "string/append/a/file.name"
-17:47 < t0m> you need to use Path::Class qw/file/; file(qw/ string append a
- file.name /);
-17:47 < t0m> like ^^^
-17:48 < t0m> then it will still work on win32
-17:48 < dhoss> noted
-17:48 < t0m> There is already File::Spec->catfile
-17:48 < t0m> which does the same thing
-17:48 < t0m> but more ugly
-17:48 < t0m> either/or
-17:48 < purl> either/or is "public load_first_existing_class" or "load_class
- passes multiple args to load_first_existing_class"
-17:48 < t0m> don't care...
-17:49 < t0m> Just "file/name" is BAD
-17:49 < t0m> and will hate windows users
-
-Summary:
-17:43 < dhoss> 1. fix pod coverage, 2. remove TestAppForInvocation 3. ??? # DONE
-17:43 < t0m> 3. merge # DONE
-################################################################################
---- Log opened Wed Jun 17 18:23:06 2009
-18:23 -!- Irssi: Starting query in perl with t0m
-18:23 <t0m> yo. wanna pick my brain affore I crash?
-18:23 <t0m> I wanna branch, and start hacking local::lib stuff
-18:23 <t0m> but that'll do a 4am on me again
-18:24 <dhoss> okay, yes
-18:25 <dhoss> i stopped after the last thing we talked about, the Moose-ification of Helper.pm. started that but nothing significant
-18:26 <t0m> no worries. There's at least 2 things you can work on right now obviously
-18:26 <t0m> one being that
-18:26 <t0m> one being hacking the generated
-18:26 <t0m> +code
-18:26 <t0m> one being tests for the generation stuff
-18:27 <t0m> at least 2 :)
-18:27 <dhoss> :-D
-18:27 <dhoss> lemme check hiveminder
-18:28 <t0m> but yeah, first 2 can be independent branches. +tests can just go in trunk
-18:29 <dhoss> so branch again
-18:29 <dhoss> and work on scripts
-18:29 <dhoss> which are tasks...hold on
-18:30 <t0m> and branch again for moosify helper. if you want. I mean work on what you wanna work on - I'm just saying after stage 1, there is a whole spread of stuff to do now
-18:30 <dhoss> #PYMI,#PYM9?
-18:30 <dhoss> yea, i'd love to moosify the helper
-18:30 <t0m> Also, probably not enough todos to cover it - there is removing all the hardcoded filenames...
-18:31 <t0m> so many stuff.
-18:31 <t0m> cool, do that then :)
-18:31 <t0m> then we'll actually refactor/rewrite it
-18:31 <t0m> so all those _mk_foo things go away
-18:31 <dhoss> okay, sweet, yea i forgot the about the hardcoded shits
-18:31 <dhoss> okay, so my famous list:
-18:31 <t0m> that's going to involve some fun Module::Install hacking ;)
-18:32 <dhoss> making _mk_blargh go away is?
-18:32 <t0m> just so
-18:32 <t0m> oh, sorry - yeah. _mk_favicon
-18:32 <dhoss> just so == yes? (sorry, my crosspondia lang isn't up to snuff)
-18:32 <t0m> etc etc etc
-18:33 <t0m> just so = yes = exactly like you descibed but I misread what you said.
-18:33 <dhoss> ahaha :-)
-18:33 <t0m> basically, the code has sub _mk_foo { render('lib/foo..pm.tt', 'lib/foo.pm') } (pseudocode)
-18:34 <dhoss> okay, so: 1. #PMYI 2. #PYM9 3. Moosification of halper
-18:35 <t0m> if you could do foreach my $from_fn_-_to_fn ( $self->get_list_of_things_in_sharedir ) {
-18:35 <t0m> ^^ That would suck so much less
-18:36 <dhoss> yea i've been looking at something like that
-18:38 <t0m> that's fairly easy, with the way we did the rename
-18:38 <t0m> initially, if you just found everything not /\.tt$/
-18:38 <dhoss> exactly, phrew
-18:39 <t0m> and transplanted them
-18:39 <t0m> that would be a good start
-18:39 <t0m> in fact, you could add that
-18:39 <t0m> not take any code away
-18:39 <t0m> just copy the files twice
-18:39 <t0m> not fail tests
-18:39 <t0m> commit
-18:39 <dhoss> copy the files twice?
-18:39 <t0m> take away the _mk_favicon etc methods one by one
-18:40 <dhoss> aha, and add that loop
-18:40 <t0m> well, if you run foreach my $binfile ($self->find_all_bin_files) { $self->copybinfile_to_app($binfile) }
-18:40 <t0m> (pseudocode)
-18:41 <t0m> ^^ Adding that to the current generation process won't break anything
-18:41 <t0m> You just generate the favicon.ico (etc) twice
-18:41 <t0m> once in that loop
-18:41 <t0m> once in pre-existing $self->_mk_favicon
-18:41 <t0m> in the same place..
-18:41 <t0m> so you overwrite it the 2nd time
-18:41 <dhoss> okay, so *leave* _mk_blargh and copy it into the for loop, i get it
-18:42 <t0m> well, do the generic thing in the for loop
-18:42 <t0m> in fact - here is a smart move. You know the 'check generated files' test?
-18:42 <dhoss> yes
-18:42 <t0m> unlink each file
-18:43 <t0m> after you pass a test as it exists
-18:43 <t0m> then add an extra test doing a File::Find
-18:43 <t0m> and fail if it finds anything
-18:43 <dhoss> so check file, unlink, then another test to look for leftovers
-18:44 <t0m> exactly
-18:44 <t0m> then you add something generic to copy bin files
-18:44 <dhoss> and, forgive me, but what does that help us make sure we've done?
-18:45 <t0m> Makes sure you're not suddenly generating t/01app.t and t/01/app.t.tt # Oops, you fucked up the 'what file name do I generate test'
-18:45 <t0m> s/test'$/code'/
-18:46 <t0m> so you don't ever accidentally generate duplicate files with diff names
-18:46 <t0m> or blank files with a weird name
-18:46 <dhoss> okay, i think i understand
-18:47 <t0m> or genrally any shit you're not specificially saying 'we test it generates a file named X'
-18:47 <t0m> you test it generates X
-18:47 <t0m> you test it does not generate anything other than X
-18:47 <dhoss> right
-18:47 <dhoss> oaky
-18:47 <dhoss> that's what i figured
-18:47 <t0m> sorry => tangent :)
-18:48 <dhoss> it's okay, i'm a one track mind with this stuff :-)
-18:48 <t0m> I can't find pmyi, but pym9 cool
-18:49 <dhoss> Try rewriting script_create.pl and see how far you can get - the big issue is going to be help display
-18:49 <dhoss> that's pmyi
-18:49 <t0m> yes
-18:49 <t0m> exactly so :)
-18:49 <t0m> Oh, no, hang on
-18:49 <t0m> Rewrite script_server.pl first
-18:50 <t0m> in fact, rewrite everything that isn't _create first
-18:50 <t0m> _create is the hardest
-18:50 <t0m> and needs the most thinking
-18:50 <t0m> by a fucking long shot
-18:50 <t0m> I think _create probably involves MooseX::App::Cmd
-18:51 <dhoss> so, rewrite with Moose sex getops
-18:51 <t0m> do the simple ones
-18:51 <t0m> first
-18:51 <t0m> like myapp_server.pl
-18:51 <t0m> like you just said :)
-18:51 <t0m> which will get you up to scratch on the Moo sex
-18:51 <t0m> before you have to hack it
-18:52 <t0m> Also, we can then start the bikeshedding about the right thing to do with moving the real code back into a CPAN dist
-18:52 <t0m> rather than it being in generated scripts
-18:52 <dhoss> right, that would be awesome :-)
-18:53 <t0m> myapp_XXXXX.pl should say: use Catalyst::Script::XXXXX; Catalyst::Script::XXXXX->new_with_options->run;
-18:53 <t0m> + shebang line
-18:53 <dhoss> right, i saw that in the list
-18:53 <t0m> kk. So make the simple scripts MX::Getopt packages
-18:54 <t0m> with the ->new_with_options->run incantation at the end of the source
-18:54 <t0m> hit until myapp_server.pl works like it used to.
-18:54 <t0m> rip Catalyst::Script::DevServer out
-18:55 <t0m> job done
-18:55 <dhoss> okay. i'll give it a crash
---- Log closed Wed Jun 17 19:00:38 2009
---- Log opened Wed Jun 17 19:00:44 2009
-19:00 <t0m> http://scsys.co.uk:8001/29932.
-19:00 <t0m> I guess something like that but with less syntax errors works
-19:01 <t0m> expand out till original functionality replicated :)
-19:01 <dhoss> Moose<3
-19:01 <dhoss> thanks man
-19:04 <dhoss> i'm gonna get some grub. i'll ping you if i have any questions, i appreciate the help :-)
-19:06 <t0m> no worries. I'm at 2am
-19:06 <t0m> so => bed
-19:08 <dhoss> hehe sleep up man
---- Log closed Wed Jun 17 19:13:38 2009
-++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-12:39 < t0m> to check we generate an application which can pass it's own tests
- :)
-12:40 < dhoss> so write a test to do taht?
-12:40 < t0m> yy, that would be cool. Can just be on the bottom of the generated
- files one
-12:41 < t0m> run Makefile.PL, check exist status 0, check 'Makefile' exists,
- run make test, check exit status zero
-12:41 < dhoss> i trust something like `$perl Makefile.pl; make test` would do?
-12:41 < t0m> *exit status
-12:41 < dhoss> or is that windows unfriendly?
-12:41 < dhoss> OH SHIT
-12:41 < dhoss> thats right
-12:41 < t0m> yeah, pretty much
-12:41 < dhoss> i have to fix those /'s
-12:41 < dhoss> make em windows happy
-12:41 < t0m> yy, good one, File::Spec->catfile it up :)
-12:42 < dhoss> i'm working on hacking buubot to read my mind
-12:42 < dhoss> so i can just tell it to grab shit i say and todo it
-12:42 < t0m> other than that, lets leave it till we can actually see a need for
- more tests..
-12:42 < dhoss> that's *fine* by me :-)
-12:43 < dhoss> so i can branch and moosify, and hack on the create scripts to
- make them moosey
-12:43 < dhoss> also, what does MX::Getopt need to play nice?
-12:43 < t0m> yy. I guess if you hack on the scripts, you want to write tests
- that they still perl -c in the generated app
-12:43 < t0m> yy. I guess if you hack on the scripts, you want to write tests
- that they still perl -c in the generated app
-12:43 < t0m> and attack the simple scripts like myapp_server.pl first
-12:44 < t0m> And you'll work out what GetOpt struggles with :)
-12:44 < dhoss> which one was the pain in the ass one? was that create?
-12:44 < t0m> yy
-12:44 < dhoss> ok, i got them backwards
-12:44 < t0m> create has much more elaborate option parsin
-12:44 < t0m> *parsing
-12:44 < dhoss> okay. that will be a later beast
-12:45 < t0m> so yeah, just branch and jfdi, add tests for things as you touch
- them - as you touch scripts add a 'scripts still compile' test
-12:46 < t0m> when each script is nicely getopt'd and refactored, it'll be easy
- to test a lot more..
-
-
-
-
projects / catagits/Catalyst-Devel.git / commitdiff