Camelia, the Perl 6 bug

IRC log for #bioperl, 2010-02-23

| Channels | #bioperl index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:31 driveby_bot joined #bioperl
00:31 driveby_bot /home/svn-repositories/bioperl: r16871 (nml5566) : added noinfer, sofile, manual, conf command line options; added quotemeta to regex strings in OBOEngine.pm; commented out bracket substitution in obo synonym terms for obo.pm; added SO IDs to Typemapper.pm; added noinfer flag to Unflattener.pm
00:31 driveby_bot Diff: http://tinyurl.com/ylht9mz
01:15 driveby_bot joined #bioperl
01:15 driveby_bot /home/svn-repositories/bioperl: r16872 (nml5566) : fixed id_validate() to work without needing so.obo file. Also, fixed bug where converter tries to guess primary_tag without so.obo file
01:15 driveby_bot Diff: http://tinyurl.com/yjbesxc
01:26 brunov joined #bioperl
01:29 rbuels deafferret:  sub queue_size { scalar @{shift->Engine->process_queue} }
01:30 rbuels deafferret: also, i was running into problems where when i enqueued too many jobs, the manager got slower and slower
01:30 rbuels deafferret: which i would think shouldn't happen ...
02:38 brunov joined #bioperl
04:10 deafferret rbuels: uh... ooops
04:10 rbuels yeah, you better be sorry
04:11 rbuels go to moose, and fix both this, and MooseX::Role::Parameterized!
04:11 deafferret are you talking about hundreds of thousands in queue?
04:11 rbuels lol, more than that!
04:11 rbuels sheesh, you think i'm some kind of lightweight?
04:11 brunov over 9000
04:11 was kicked by deafferret: show me the way to moose
04:11 rbuels joined #bioperl
04:12 * rbuels mooses
04:12 rbuels there, see?
04:17 deafferret only 9000? that's not many.... hmmm
04:17 rbuels lol, no, a few million
04:17 deafferret are you creating 9000 Job objects or just sub references or?
04:17 deafferret ohhh
04:17 rbuels brunov said 9000, not me
04:18 deafferret that's several
04:18 rbuels deafferret: but i don't see how that would matter so much unless it's iterating over the queue or something
04:18 rbuels but don't worry about it, like i said
04:18 deafferret or it's sorting them or something
04:18 * rbuels shrugs
06:51 bag_ joined #bioperl
12:50 brandi joined #bioperl
12:50 brandi left #bioperl
13:58 brandi joined #bioperl
14:18 brandi joined #bioperl
14:43 brandi left #bioperl
14:43 brunov joined #bioperl
14:57 brunov .oO( ... )
14:57 brunov so ...
14:58 brunov soon bioperl is going to get broken up in parts, right?
15:03 brunov I'm just thinking if we could build a dependency graph of all BioPerl to make it easier. I played five minutes yesterday with rjbs'  Module::ScanDeps, it's really nice
15:04 brunov And I thought that maybe it'd be worth it to build the graph and put it in a database or something so that people can play with it and see what's easier to take out
15:05 brunov just by playing in the command line ( find -name '*.pm' | xargs scandeps -R | grep -v 'Bio::' ) I saw that, for instance, Bio::Biblio is quite easy to take out.
15:05 brunov But maybe (probably) it's been done, so I'm just asking here.
15:15 brunov ... o@
16:01 pyrimidine joined #bioperl
16:03 pyrimidine brunov: it's been done before (re: dep graph).  And it's very tricky to separate out several bits.  Not impossible, but tricky.
16:05 brunov pyrimidine, thanks, glad I checked here first then. Would have gone all code frenzy duplicating efforts :)
16:05 pyrimidine brunov: np
16:06 pyrimidine this is part of the reason why I would like one more 1.6.x point release prior to starting (and why we'll be doing much of the dismantling on branches).
16:07 brunov *nod*
16:08 brunov Don't know if it's been mentioned before in the mailing list, but has it been considered to have a Task::BioPerl gluing all of the parts together while the separation process is taking place?
16:08 pyrimidine yes.  that will likely be what the main BioPerl distribution turns into.
16:09 pyrimidine (i.e. it will just install what you need, starting with core on up).
16:09 brunov oh, great then.
16:11 pyrimidine the actual change should be fairly minimal to the average user, they can still get a full old-style installation, but we can wrap other distributions into that
16:11 pyrimidine db, run, network, etc
16:11 brunov That way, there can be a top-down and bottom-up splitting happening at the same time. Some dists (like Bio::Biblio) are easily taken from the top, and some others (like Bio::Root) can be trivially split from the bottom, while Task:: glues it all
16:11 pyrimidine right
16:15 pyrimidine Task::Moose is just a Makefile with feature calls to inc::Module::Install (including Module::Install::AutoInstall).
16:15 pyrimidine can define defaults, multiple modules, etc.
16:15 pyrimidine so it's fairly straightforward.
16:15 brunov *nod*
16:16 brunov My hope is that, as the first dists are split appart, more can be found that don't depend on the BioPerl molass anymore (ie, "look, this also just depends on Bio::Root, so it can cleanly be taken out" )
16:17 deafferret ..                ..o .
16:23 pyrimidine We've already identified several candidates, including featureIO (which I've already pulled out on a branch), clusterIO, coordinate, restriction, etc.  The tricky part is how we approach development.
16:25 pyrimidine at the GMOD meeting, when this subject was raised, there were some devs who were of the mind that we could continue keeping everything in one large directory, and just post-process everything into smaller distributions
16:25 pyrimidine (which I don't agree with)
16:32 deafferret sounds fragile  :(
16:34 pyrimidine yes, that's why I don't agree with it, and I don't think we'll be going down that path.
16:39 brunov why can't there be a repository for each distribution?
16:40 deafferret that's what Catalyst/Moose do
16:40 brunov yep, it's not bad at all, and doesn't prevent people from contributing to many repos, or them not being mutually aware of each other
16:46 pyrimidine right.  the argument for the former was the convenience factor.  no need to have a huge list of dev directories in PERL5LIB, just to ensure you are using the right libraries instead of installed ones.
16:51 deafferret hmm. When I'm dev'ing I just -I lib the thing I'm dev'ing, and all other dists are in @INC because they're "installed on my system". So I'm only ever explicit about one dist lib/ at a time.
16:51 brunov same here
16:51 deafferret so I never have a 20-part PERL5LIB
16:51 brunov and in any case, "huge" would be like, 10
16:52 brunov doesn't compare with the pain that the release manager would have with separate dists in the same repo
16:52 deafferret the dists are each supposed to be encapsulated, so I shouldn't be fiddling multiple dists all at the same time... :)
16:52 pyrimidine we'll still have to deal with issues where changes in one distribution will affect others, but we can address that fairly easily
16:52 pyrimidine and those should be rare
16:52 pyrimidine you do see issues like this with Moose
16:54 pyrimidine Ovid blogged on this recently:
16:54 pyrimidine http://blogs.perl.org/users/ovid/2010/02/why-doesn​t-the-bbc-upgrade-their-software-often-enough.html.
16:54 pyrimidine ***
16:54 pyrimidine This version of Moose conflicts with the version of
16:54 pyrimidine Catalyst (5.80007) you have installed.
16:54 pyrimidine You will need to upgrade Catalyst after installing
16:54 pyrimidine this version of Moose.
16:54 pyrimidine ***
16:55 pyrimidine but those things will pop out on CPAN (CPAN Testers is a good thing!)
16:55 brunov well yes, but if the option is either have this possibly inevitable scenario, and having the same repository (or even the same distribution) for both Catalyst *and* Moose then.. I've rather deal with the former
16:55 brunov *the options are
16:56 pyrimidine right
16:58 pyrimidine and I would much rather say to a user who complains that something doesn't work that we've pushed the fix to CPAN, as opposed to grabbing the code from svn.
16:58 deafferret when I'm upgrading, I'm jumping up to the "latest everything I care about," so this behavior doesn't bother me
16:58 brunov yeah. Also, with things split appart, releases can be made less important and more frequent and modular
16:58 pyrimidine right.  there are too many positive aspects to dismantling the monolith, not nearly enough negatives
16:59 pyrimidine I'm also hoping this speeds up a possible full migration to git/github, but we'll see :-D
17:00 brunov yeah, specially with new tools like cpanfresh and the new cpanminus (have you tried it? it's really newbie-friendly)
17:00 brunov pyrimidine, \o/
17:01 pyrimidine brunov: (re: cpan-foo) no haven't tried them yet.
17:01 brunov re:cpanfresh, you can push a new release and have people get it in 20 minutes
17:04 pyrimidine I'm hoping to reduce the release pressure on devs and set everything up via shipit.
17:04 pyrimidine reading up on cpanp and cpanf, seems like it can be fragile (even auth admits it).
17:05 pyrimidine if it works, though, it's nice (particularly cpanf)
20:15 bag_ joined #bioperl
20:17 brandi joined #bioperl
20:17 brandi left #bioperl
20:23 kyanardag joined #bioperl
20:25 brandi joined #bioperl
20:28 brandi left #bioperl
21:19 pyrimidine left #bioperl
22:20 balin joined #bioperl
23:34 brunov joined #bioperl

| Channels | #bioperl index | Today | | Search | Google Search | Plain-Text | summary