14:49 mst: can you look at people/ilmari/deferred-exception-propagation ? I actually wanted to do more work on with_deferred_fk_checks 14:51 mst: and you said ribasushi is reviewing my blob branch, is that likely to happen before 2013? 14:52 <@mst> Caelum: less likely every time you make a snarky comment like that. 14:53 mst: you know, this isn't for me, it's about making dbic more functional for people who use it, and it doesn't help them at all if the code rots in git for months 14:57 <@mst> Caelum: that's right, it is what it's about. which is why you shouldn't be snarky about the people helping you achieve that. 14:57 "helping me?" give me a fucking break 15:00 mst: so what kind of "spec" did you want for the strptime branch 15:00 <@mst> an actual spec for what the feature is trying to achieve 15:00 <@mst> basically, I need you to /achieve yourself 15:00 <@mst> and commit the results 15:00 a way to define parsers as strptime formats 15:01 that's what it does 15:01 <@mst> no, fucko, that's what you're failing to implement 15:01 <@mst> you know how this works 15:01 <@mst> step back, explain PROPERLY 15:01 <@mst> because your laughable excuse for an implementation told me fuck all 15:01 it's this kind of attitude that makes me want to stop working on dbic all together 15:01 I don't really give a fuck what it told you or didn't tell you 15:01 <@mst> what, the attitude of "let's understand the feature first, then design it, THEN implement it" ? 15:02 the feature is "make a method to make strptime parsers", which is what it does 15:03 <@mst> that's not a feature 15:03 you saw the code it replaces, something to replace that code 15:03 <@mst> DBIx::Class is not a parser generator 15:03 why not? 15:04 <@mst> the storage layer should be *constructing* an *object* that does what we need. 15:04 <@mst> why can't we just create a strptime object and use it? 15:04 because IC::DT calls methods based on the data_type 15:05 <@mst> that's not an answer. try again. 15:05 how does the object have or not have a parse_smalldatetime method? 15:06 <@mst> I was of the understanding that the majority of parsers can handle at least parse_datetime and parse_date 15:06 <@mst> have you found one that doesn't yet? 15:07 -!- cggoebel [~ggoebel@c-24-30-98-226.hsd1.ga.comcast.net] has quit [Ping timeout: 360 seconds] 15:07 <@mst> Caelum: hello? 15:09 -!- fhelmber_ [~fhelmberg@91-115-174-55.adsl.highway.telekom.at] has joined #dbix-class 15:09 I think they all can handle parse_datetime, not all DBs have a date datatype though, and for MSSQL the format is different for datetime versus smalldatetime 15:10 <@mst> so ... write a DateTime::Format::MSSQL that handles it? 15:11 <@mst> or patch Format::Strptime to provide the extra methods 15:11 -!- cggoebel [~ggoebel@c-24-30-98-226.hsd1.ga.comcast.net] has joined #dbix-class 15:11 <@mst> the whole point of just calling a datetime parser class 15:11 <@mst> was that DBIx::Class is supposed to outsource the datetime parsing to CPAN 15:11 that won't work because the formats are different depending on the driver 15:11 -!- fhelmbe__ [~fhelmberg@91-115-174-55.adsl.highway.telekom.at] has joined #dbix-class 15:11 connecting through DBD::Sybase, depending on what options you used too, will have different formats than ODBC 15:11 <@mst> well, figure out something that will work, get CPAN fixed, then we can outsource to the fixed version 15:12 <@mst> right, so we allow for a datetime parser class, and constructor args 15:12 <@mst> and we fix strptime so it works 15:12 fix strptime how 15:12 <@mst> so I still don't understand why DBIx::Class should be generating internal classes 15:12 <@mst> I don't know, you still didn't give me a spec for all the options 15:13 <@mst> the Sybase/ODBC thing is the sort of /achieve you need to document 15:13 <@mst> once you have, we can revisit it 15:13 what do you mean all the options 15:13 IC::DT calls parse_$data_type 15:13 <@mst> fuck what IC::DT does 15:13 <@mst> I don't fucking care 15:13 <@mst> that's not relevant, at all 15:14 <@mst> IC::DT and the Storage::* classes are in the same fucking dist 15:14 of course not, you just feel like being a dick and giving me shit 15:14 <@mst> we can change both if we need to 15:14 <@mst> what I need is a *SPEC* 15:14 <@mst> i.e. a list of the different use cases you've encountered 15:14 <@mst> so instead of adding yet another layer of hacks 15:14 <@mst> we can actually understand the problem space, and figure out a -good- solution for it 15:14 I don't see why I have to do all that work for a method only I use 15:15 <@mst> eh? 15:15 I wrote all the dt parsers 15:16 -!- fhelmber_ [~fhelmberg@91-115-174-55.adsl.highway.telekom.at] has quit [Ping timeout: 360 seconds] 15:16 <@mst> you didn't write DateTime::Format::MySQL 15:16 <@mst> or ::SQLite 15:16 no, I mean the ones in DBIC 15:16 <@mst> or ::Pg 15:17 I wrote ::Sybase though 15:17 <@mst> yes, but I want to produce a sane solution that encompasses all of the problem space 15:17 <@mst> DBIx::Class has -always- tried to solve problems as generally as possible 15:17 that's just generic for "fuck you I feel like being a dick so I won't merge your code" 15:18 <@mst> no, it isn't. it's "I';m not merging this shitty fuckstupid hack no matter how big a tantrum you throw you little shit, please try acting like an adult and letting me help you do it properly" 15:18 oh now I'm a "little shit" you're the 23 year old 15:19 <@mst> not for some years. 15:19 <@mst> your branches wouldn't end up lying around for 6 months if you took a little more time to get them right in the first place, by the way 15:20 <@mst> th fact you don't and then decide to interpret "here is a problem" as "fuck you" is what makes it takes so long 15:20 <@mst> since you make it incredibly hard work to get competent code out of you 15:20 -!- fhelmbe__ [~fhelmberg@91-115-174-55.adsl.highway.telekom.at] has quit [Remote host closed the connection] 15:20 <@mst> the choice is very much yours here - let me help you do it properly ... or don't do it at all, because I won't merge shit. 15:20 yes and your code is always right the first time 15:21 what the fuck do you want in a "spec" 15:21 <@mst> a list of our current datetime parsing and formatting requirements and how they're currently implemented 15:21 and why should I waste time on this rather than continue writing ugly inline parser classes because you won't merge my branch 15:21 * dams yawns 15:22 <@mst> because I won't be merging another ugly inline parser class either 15:22 <@mst> I want those out of core. 15:22 <@mst> ribasushi might have let you merge this, but I won't, because I want a codebase that doesn't take ages to do a branch review on 15:22 <@mst> and that means enforcing a higher standard 15:22 <@mst> once we've done that for a while, reviews and merges will speed up 15:23 ok I wanted to make a utility method but now I have to do a research project? why would I waste time on that? 15:23 <@mst> because we try to solve problems generally 15:24 <@mst> it isn't time wasted, it's time invested to get a decent codebase 15:25 ok, well, I'm going to wait to see what happens to my other two branches before I do any more work on dbic 15:25 it seems likely I won't do anymore work on dbic at all 15:26 <@mst> I've just spent 25 minutes discussing this with you to try and get the strptime stuff to be able to move forwards 15:26 sorry for wasting your precious time 15:26 <@mst> until you produce a result from this, I won't be looking at anymore branches of yours 15:27 <@mst> I need to know you actually care about writing -good- code 15:27 <@mst> rather than turning DBIX::Class into FormMail.PL one "good enough hack" at a time 15:27 because I only write bad code, right 15:27 <@mst> you don't seem to want to listen when I point out something -is- bad 15:27 ok, we're done then. I'll just be working on sl where I don't have to take any shit from anyone. 15:27 let's just say I disagree 15:28 <@mst> you want the fast hack instead of the done properly. I'm aware. 15:28 <@mst> that can't be done in core. 15:28 <@mst> you're welcome to propose designs to make it possible to do a fast hack -outside- core. 15:30 Caelum: maybe you should pause for 1 min, take a deep breath and concentrate on the technical stuff mst says, not how he says it. forget about his maners for 5 min. Mst : maybe you can summarize in 2 sentence what should be done, how much effort it would require, and what benefit -besides pride- it would give ? 15:30 -!- ghenry [~ghenry@ghenry.plus.com] has joined #dbix-class 15:32 sorry if this lame mediation attempt doesn't help :) 15:33 <@mst> it would mean that we could outsource DateTime handling to CPAN again 15:33 <@mst> which would then mean modules that don't have to be shipped in core 15:33 <@mst> DBIx::Class is not a datetime parser. 15:35 dams: basically what mst says is total bullshit, he just wanted to be a dick and not merge my branch and is now just making up excuses for doing so 15:37 Caelum: of course he is ! he *is* an asshole and shit, I agree with you. However, in addition to that, he generally has good technical reasons too. It's very hard to seperate the 2, but it's worthwhile to do so. So let's focus on the technical issue only. 15:37 Caelum: I'm sure if you start some the outsourcing, you won't be alone doing so, and people may guide, help and code on that. So the Additional coding effort should be minimal or non existant 15:38 is there anything else that makes you reluctant to outsourcing DateTime handling from DBIC ? unless you don't agree it's a good idea - in this case, why ? 15:38 dams: just a couple months ago he was making my life miserable because I didn't want to change a default in sl and he was threatening to "find a new maintainer" (like that's going to happen) his technical reason for changing the option? "it was long" "it might cause bad data (even though he didn't say how, because that's impossible)" 15:39 -!- dross [~dross@pool-173-75-35-247.pitbpa.fios.verizon.net] has joined #dbix-class 15:39 dams: the dt format depends on the driver and the options you give to said driver 15:41 dams: so it's perfectly logical to define the strptime format in the driver 15:41 -!- mrf [~mrf@46.43.49.105] has joined #dbix-class 15:43 <@mst> Caelum: I'm afraid I don't make up excuses for things. 15:43 caelum: It seems that the suggestion is one needs to find a way to get the appropriate options out of the driver and into the right DT parser. To paraphrase. That doesn't sound like a totally dumb suggestion. Maybe not the only way to do it. 15:43 <@mst> Caelum: and the obsession with correctness that characterised early DBIC work led by me is what gave us e.g. rsultset chaining - which fell *by accident* out of working on the design 15:45 what ? you didn't plan that upfront ? I didn't know that. It's the first thing I would have put in a ORM design spec :) 15:45 yet I would have missed the other 90% awesome ideas 15:45 <@mst> dams: it wasn't a feature available in any of the existing ORMs I looked at at the time 15:46 <@mst> even now, we're the only perl ORM to do it much 15:47 -!- cggoebel [~ggoebel@c-24-30-98-226.hsd1.ga.comcast.net] has quit [Ping timeout: 360 seconds] 15:48 it's a damn good feature anyway 15:49 -!- mst changed the topic of #dbix-class to: Git-season is OPEN! Ask about 'dbic commit?', and git busy :) | DBIC: 0.08199 | NO PASTING, use http://paste.scsys.co.uk | Query syntax is perldoc SQL::Abstract | "many_to_many" is not a relationship | DBIC_TRACE=1 | DBIC/DBICSL/C::M RM - temporarily mst | columns > select/as | MySQL - brought to you by retardo the syphilitic clown 15:50 <@mst> Caelum: I'll be doing release manager duties with review for Schema::Loader and C::M::DBIC::Schema for the moment; until we get into a decent review rhythm there's no other way to avoid compromising the stability of the packages. 15:50 mst: what is your claim to sl? you never wrote any code for it 15:50 <@mst> Caelum: right now, my claim is that I have co-maint and you don't. 15:51 -!- cggoebel [~ggoebel@c-24-30-98-226.hsd1.ga.comcast.net] has joined #dbix-class 15:51 <@mst> I'm uninterested in arguing about code versus design versus other types of input. 15:51 mst: abusing your cpan admin privileges? that's just awesome 15:51 mst: fine, I'll be releasing it under a different name 15:52 <@mst> making use of the fact that I have permission to pull the necessary knobs, because I'm not the only one who's been concerned about your ability to work with others; I'm just the only one with a thick enough skin to still be trying 15:52 <@mst> you've pissed off everybody else too much for them to think you'r worth bothering with 15:53 really? who did I piss off 15:53 <@mst> me, I think we're both dicks, and I'd like your code still to go into the projects, because when you're good you're actually good. 15:53 you said I pissed off everybody and I can't work with others 15:53 <@mst> I figure you can work with me, since I don't actually care if you keep calling me a dick 15:54 <@mst> I just care that the right code turns up 15:54 * mst shrugs 15:55 <@mst> the choice is yours, really - let me help you produce something that's really good, or don't 15:55 what other people are concerned about my ability to maintain sl? should I take this up with modules? 15:56 <@mst> why would you take it up with anybody? I had permission to do this. 15:56 <@mst> modules@ has no right to interfere 15:57 -!- cggoebel [~ggoebel@c-24-30-98-226.hsd1.ga.comcast.net] has quit [Ping timeout: 360 seconds] 15:57 you have the right to take over other people's modules at will? I don't think so 15:57 <@mst> I don't, and I didn't do that. 15:58 <@mst> I merely removed one specific set of co-maint priviliges, something which I already had permission to do if I believed it to be necessary 15:58 <@mst> I'm afraid your intransigence over collaboration has led me to believe it was necessary. 15:59 -!- djh [~djh@46.43.49.105] has joined #dbix-class 15:59 yeah I only wrote most of it and have been maintaining it for 4 years, of course that doesn't matter 16:00 -!- djh [~djh@46.43.49.105] has quit [] 16:00 <@mst> I think now might be a good time for you to give serious thought as to whether you want to ship production quality code as part of a team, or just do your own thing in a separate namespace 16:01 <@mst> at this stage I'm open to either, though I'd still prefer you to stay hacking on these projects if possible 16:01 -!- cggoebel [~ggoebel@c-24-30-98-226.hsd1.ga.comcast.net] has joined #dbix-class 16:01 good luck finding a new maintainer for sl 16:02 <@mst> it can still be you if you want 16:02 but I'm going to write to modules anyway 16:02 <@mst> I'm just going to do the release cutting for a bit 16:06 -!- dpetrov_ [b21b747f@ircip4.mibbit.com] has joined #dbix-class 16:06 <@mst> Caelum: really? 16:06 <@mst> do I really have to send mail explaining what's going on? these things are normally not done by yelling from the rooftops, especially when you don't actually have a case 16:09 -!- wk [~quassel@sa-84-52-47-213.saturn.infonet.ee] has joined #dbix-class 16:09 * mst shrugs, sends the mail just in case 16:11 -!- pingup3rl [~nixus@C8ECD1BE.dynamic.shd.tesa.net.br] has joined #dbix-class 16:17 and I'm going to attach the irc log