Development

IRCLogs20110217 (diff)

You must first sign up to be able to contribute.

Changes from Version 1 of IRCLogs20110217

Show
Ignore:
Author:
lsmith (IP: 109.164.240.33)
Timestamp:
02/18/11 13:31:17 (7 years ago)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • IRCLogs20110217

    v0 v1  
     1= Summary = 
     2                          
     3http://doodle.com/9v4kmc9gvn3mpqqt 
     4 
     5= IRC logs = 
     6{{{ 
     7Feb 17 11:00:13 <fabpot>        ok, so let's start 
     8Feb 17 11:00:34 <Seldaek>       not many seem to be around :/ 
     9Feb 17 11:00:35 <fabpot>        first topic is about the Symfony sub-namespaces 
     10Feb 17 11:01:01 <fabpot>        don't know why we need to talk about that as last time I did, everybody seem to be againts any change 
     11Feb 17 11:01:01 *       na8flush (~rosshette@c-67-175-220-187.hsd1.il.comcast.net) has joined #symfony-dev 
     12Feb 17 11:01:18 <Seldaek>       bschussek: avalanche123 iampersistent jmikola|w jmikola johanness kriswallsmith lala ping 
     13Feb 17 11:01:25 <jmikola|w>     pong pong pong pong 
     14Feb 17 11:01:28 <avalanche123>  Seldaek lala pong 
     15Feb 17 11:01:30 <jmikola|w>     oh, meeting time :) 
     16Feb 17 11:01:32 *       aways|bnc Bye all 
     17Feb 17 11:01:42 *       kriswallsmith is here 
     18Feb 17 11:01:50 <Seldaek>       fabpot: I believe the thing is that bschussek proposed something new 
     19Feb 17 11:01:51 <lsmith>        fabpot: about to head out .. 
     20Feb 17 11:01:59 <lsmith>        but yeah .. there was a new proposal on the list 
     21Feb 17 11:02:14 <fabpot>        bschussek proposal is to move bundles under Framework 
     22Feb 17 11:02:15 <Seldaek>        http://groups.google.com/group/symfony-devs/msg/5e9b52a340557a26 
     23Feb 17 11:02:25 <fabpot>        and move up components under the main namespace 
     24Feb 17 11:02:28 <Seldaek>       yes 
     25Feb 17 11:02:33 <Seldaek>       you didn't answer afaik 
     26Feb 17 11:02:42 <fabpot>        Seldaek: I missed that one 
     27Feb 17 11:02:45 <Seldaek>       so that's the main question, is it a no go for you or not :) 
     28Feb 17 11:02:56 <kriswallsmith> i like the current layout 
     29Feb 17 11:03:25 <fabpot>        but then, the components are not clearly stored under one place 
     30Feb 17 11:03:27 *       johnwards_ (~johnwards@host81-141-9-106.wlms-broadband.com) has joined #symfony-dev 
     31Feb 17 11:03:36 <fabpot>        I think the current way is good enough 
     32Feb 17 11:03:38 <Seldaek>       sure, but if we move them to their own repo at some point anyway 
     33Feb 17 11:03:47 <Seldaek>       then the subnamespace would make less sense 
     34Feb 17 11:03:48 <jmikola|w>     Seldaek: with bernhard's proposal, would the best practice for other vendors be to have no Bundle/ in their bundle namespaces? 
     35Feb 17 11:04:03 <Seldaek>       jmikola|w: no that has nothing to do with vendors I think 
     36Feb 17 11:04:16 <fabpot>        the problem is that the "best practice" will not be followed by Symfony anyway 
     37Feb 17 11:04:24 <Seldaek>       yes, that's irrelevant 
     38Feb 17 11:04:43 <jmikola|w>     I don't mind Symfony having a component namespace... after all, those will become http://components.symfony-project.org/ right? :) 
     39Feb 17 11:04:43 <fabpot>        IIRC, we advocate Sensio\FooBundle 
     40Feb 17 11:04:44 <kriswallsmith> on the other hand, if i wanted to use a component in a non-symfony project, Symfony\Yaml would be nicer than Symfony\Component\Yaml 
     41Feb 17 11:04:53 <bschussek>     kriswallsmith: +1 
     42Feb 17 11:05:00 <Seldaek>       yeah that's what I meant kriswallsmith 
     43Feb 17 11:05:05 <bschussek>     I think it makes sense, because the bundles are the "framework" 
     44Feb 17 11:05:09 <Seldaek>       if they're in their own repo/package, then the extra namespace becomes annoying 
     45Feb 17 11:05:13 <bschussek>     so Symfony\Framework is that, and Symfony\X is everything else 
     46Feb 17 11:05:16 <fabpot>        as discussed on the CMF ML, we will have a Symfony\CMF 
     47Feb 17 11:05:18 <jmikola|w>     bschussek: would we have Framework\FrameworkBundle? :) 
     48Feb 17 11:05:39 <kriswallsmith> CoreBundle? 
     49Feb 17 11:05:42 <bschussek>     jmikola|w: for example. or CoreBundle, I don't mind 
     50Feb 17 11:05:42 <fabpot>        so, there is no clear difference between a component, the framework (a bunch of bundle), and the CMF 
     51Feb 17 11:05:49 <fabpot>        looks messy, no? 
     52Feb 17 11:05:55 <Seldaek>       fabpot: not really 
     53Feb 17 11:05:56 <bschussek>     I don't think so 
     54Feb 17 11:06:02 <Seldaek>       the framework is a component of sorts 
     55Feb 17 11:06:10 <fabpot>        Seldaek: not at all 
     56Feb 17 11:06:11 <Seldaek>       you can use it on its own, it just has lots of dependencies 
     57Feb 17 11:06:16 <fabpot>        the framework is definitely NOT a component 
     58Feb 17 11:06:33 <fabpot>        the "few dependencies" is part of the component definition 
     59Feb 17 11:06:42 <Seldaek>       yes of course it's special 
     60Feb 17 11:06:53 <Seldaek>       but I don't see it as bad to have it under the same namespace 
     61Feb 17 11:07:02 <Seldaek>       it's quite clear what Framework is.. 
     62Feb 17 11:07:04 <Seldaek>       same for CMF 
     63Feb 17 11:07:15 <fabpot>        the problem is not the CMF or Framework namespaces, but all the other ones 
     64Feb 17 11:07:16 *       johnwards has quit (Ping timeout: 240 seconds) 
     65Feb 17 11:07:16 *       johnwards_ is now known as johnwards 
     66Feb 17 11:07:52 <Seldaek>       well the notion of what a component is honestly is just as vague 
     67Feb 17 11:07:59 <Seldaek>       component means something to us because it has been defined 
     68Feb 17 11:08:00 <fabpot>        it's not 
     69Feb 17 11:08:10 <Seldaek>       if we define that those things in Symfony, except Framework, are components 
     70Feb 17 11:08:20 <Seldaek>       then it's the same.. it's just a matter of documenting it properly I think 
     71Feb 17 11:08:36 <Seldaek>       in another framework, Component could be something totally not reusable and standalone 
     72Feb 17 11:08:43 <fabpot>        let's put it another way: Why would you want to remove the Component\ sub-namespace? 
     73Feb 17 11:08:44 <Seldaek>       it's not a universal meaning, that's what I mean 
     74Feb 17 11:09:12 *       gordonslondon_ (~julesbous@ble59-5-82-233-204-65.fbx.proxad.net) has joined #symfony-dev 
     75Feb 17 11:09:13 *       gordonslondon has quit (Read error: Connection reset by peer) 
     76Feb 17 11:09:13 *       gordonslondon_ is now known as gordonslondon 
     77Feb 17 11:09:14 <Seldaek>       on the plus side it makes things shorter, and it has no real benefit imo 
     78Feb 17 11:09:16 <bschussek>     fabpot: for clarity, mainly. I like the short namespaces of Doctrine 
     79Feb 17 11:09:22 <bschussek>     but it's no must have 
     80Feb 17 11:09:31 <jmikola|w>     Seldaek: i think other projects using namespaces are more single purpose - while Symfony\ here is lumping a lot of independent things together... perhaps one of the few things to compare to would be ZF2, but those are essentially all components afaik 
     81Feb 17 11:09:40 *       weaverryan has quit (Ping timeout: 276 seconds) 
     82Feb 17 11:09:43 <pgodel_work>   you can always use "use namespace;" to shorten things 
     83Feb 17 11:10:00 <fabpot>        to be clear, I'm not opposed to the change. But we are now in a stabilization phase. So we only change things if there is a real advantage 
     84Feb 17 11:10:20 <bschussek>     what about a voting then? 
     85Feb 17 11:10:25 <Seldaek>       pgodel_work: well, you gotta write the long use statements.. :) 
     86Feb 17 11:10:33 <kriswallsmith> can someone recap why the CMF is going into Symfony\CMF? 
     87Feb 17 11:10:36 <pgodel_work>   IDE autocompletion ;) 
     88Feb 17 11:10:38 <fabpot>        bschussek: I want pros and cons before 
     89Feb 17 11:10:51 <Seldaek>       kriswallsmith: please later, unless it's a pressing matter 
     90Feb 17 11:11:01 <kriswallsmith> it will inform this decision 
     91Feb 17 11:11:02 *       weaverryan (~ryan@72.242.184.210) has joined #symfony-dev 
     92Feb 17 11:11:10 <fabpot>        Seldaek: it is important to make the right decision 
     93Feb 17 11:11:22 <fabpot>        let's add another one: Symfony\Twig 
     94Feb 17 11:11:26 <Seldaek>       well, they will never be in the same repo I guess, so I'd say it's less important 
     95Feb 17 11:11:32 <fabpot>        that's something I'm thinking about 
     96Feb 17 11:11:37 <jmikola|w>     if CMF, as a project is going into the top namespace, i see value in keeping sf2 components isolated from that 
     97Feb 17 11:11:48 <Seldaek>       but the rationale behind the CMF is that it's endorsed by Symfony 
     98Feb 17 11:11:50 <fabpot>        jmikola|w: +1 
     99Feb 17 11:11:57 <pgodel_work>   jmikola|w: and there may be more things like that in the future 
     100Feb 17 11:11:58 <Seldaek>       and it is a CMFramework 
     101Feb 17 11:12:10 <Seldaek>       it's not really a product on its own 
     102Feb 17 11:12:12 <jmikola|w>     pgodel_work: yes, i considered Symfony\Twig, too 
     103Feb 17 11:12:15 <kriswallsmith> why is CMF different than YAML? 
     104Feb 17 11:12:16 <johanness>     fabpot, what about different release cycles and dependencies between components? 
     105Feb 17 11:12:29 <fabpot>        johanness: What do you mean? 
     106Feb 17 11:12:30 <johanness>     that wouldn't work so well if they are all in the same repo no? 
     107Feb 17 11:12:35 <Seldaek>       kriswallsmith: it's not a component, it'll use many dependencies 
     108Feb 17 11:12:48 <fabpot>        johanness: there are in the same namespace, but can be in different repo 
     109Feb 17 11:12:48 <pgodel_work>   same namespace does not mean same repo 
     110Feb 17 11:12:52 <kriswallsmith> Seldaek: i see 
     111Feb 17 11:12:55 <fabpot>        they* 
     112Feb 17 11:13:08 <kriswallsmith> +1 for no change 
     113Feb 17 11:13:09 <fabpot>        2 minutes left 
     114Feb 17 11:13:19 <pgodel_work>   +1 no change 
     115Feb 17 11:13:22 <Stof>  +& for no change too 
     116Feb 17 11:13:24 <fabpot>        +1 no change 
     117Feb 17 11:13:27 <Seldaek>       well, I'll live either way, but I would have liked the shortened ns 
     118Feb 17 11:13:30 <Nenuial>       +1 no change 
     119Feb 17 11:13:33 <bschussek>     +1 change :) 
     120Feb 17 11:13:37 <fabpot>        bschussek: ?! 
     121Feb 17 11:13:41 <mvrhov>        +1 fo no change. 
     122Feb 17 11:13:57 <bschussek>     I'm alright with no change, but as for the voting :P 
     123Feb 17 11:13:59 <Seldaek>       bschussek: it's the liip office influence, you start having ideas that nobody agrees with 
     124Feb 17 11:14:07 <Seldaek>       it's okaay 
     125Feb 17 11:14:09 <jmikola|w>     in the interest of how close we are to stabilizing, +1 for no change (this seems more opinion than functional need) 
     126Feb 17 11:14:10 <fabpot>        Seldaek: hehe 
     127Feb 17 11:14:22 <jmikola|w>     Seldaek: Symfony\ViewBundle? :) 
     128Feb 17 11:14:25 <fabpot>        Seldaek: by the way, I'm the one who started this thread 
     129Feb 17 11:14:38 <fabpot>        jmikola|w: looks ugly o) 
     130Feb 17 11:14:46 *       kriswallsmith gavels 
     131Feb 17 11:14:48 <Seldaek>       well then next topic I guess :p 
     132Feb 17 11:14:53 <fabpot>        yep 
     133Feb 17 11:15:04 <fabpot>        what's missing for RC1? 
     134Feb 17 11:15:17 <fabpot>        bschussek: my first main concern is the form/validation component 
     135Feb 17 11:15:24 <fabpot>        2 things: intl and the binding process 
     136Feb 17 11:15:42 <bschussek>     fabpot: intl is being worked on 
     137Feb 17 11:15:52 <bschussek>     progress can be seen at github.com/Infranology/symfony 
     138Feb 17 11:16:03 <fabpot>        bschussek: great, I will have a look then 
     139Feb 17 11:16:06 <fabpot>        any ETA? 
     140Feb 17 11:16:14 <igorw> also igorw/symfony for the dateformatter 
     141Feb 17 11:16:16 <kriswallsmith> i have work to do in assetic and AsseticBundle 
     142Feb 17 11:16:27 <fabpot>        locale branch? 
     143Feb 17 11:16:34 <bschussek>     numberformatter, I think 
     144Feb 17 11:16:36 <igorw> numberformatter 
     145Feb 17 11:16:40 <igorw> and intldateformatter on mine 
     146Feb 17 11:16:50 <bschussek>     \Locale and \NumberFormatter are already ported 
     147Feb 17 11:16:59 <bschussek>     igorw is working on \IntlDateFormatter 
     148Feb 17 11:17:11 <bschussek>     then there's \Collator missing, but I hope this'll be a quick one 
     149Feb 17 11:17:12 <jmikola|w>     kriswallsmith: assetic won't depend on bulat's imagine stuff for initial release, correct? not sure how much overlap there was on spriting 
     150Feb 17 11:17:16 <igorw> bschussek: would be great if you could review what I have and tell me what else is needed 
     151Feb 17 11:17:27 <kriswallsmith> jmikola|w: correct 
     152Feb 17 11:17:36 <kriswallsmith> we may work together when it comes to image sprites 
     153Feb 17 11:17:50 <fabpot>        let's finish intl before 
     154Feb 17 11:17:53 <bschussek>     igorw: I'll do that tomorrow 
     155Feb 17 11:18:10 <fabpot>        bschussek: so, as I understand, you are confident about it, right? 
     156Feb 17 11:18:11 <bschussek>     fabpot: so if ecosta has some time, we might have a first intl candidate by the end of next week 
     157Feb 17 11:18:26 <bschussek>     yes 
     158Feb 17 11:18:36 <fabpot>        great 
     159Feb 17 11:18:56 <bschussek>     as for the binding process, I'll change that, but I also want to take Bulat's, Jon's and Lukas' feedback into account 
     160Feb 17 11:19:02 <bschussek>     more on that next week 
     161Feb 17 11:19:06 <fabpot>        great 
     162Feb 17 11:19:19 <fabpot>        anything special on assetic? 
     163Feb 17 11:19:27 <fabpot>        kriswallsmith: what about the documentation for the Symfony book? 
     164Feb 17 11:19:45 <kriswallsmith> i'm tracking issues here https://github.com/kriswallsmith/symfony/issues 
     165Feb 17 11:20:06 <kriswallsmith> there are issues with how assets configured in templates are cached 
     166Feb 17 11:20:23 <kriswallsmith> i'll probably write a custom cache mechanism in assetic for that 
     167Feb 17 11:20:25 <Seldaek>       I really hope I find time to play with assetic next week 
     168Feb 17 11:20:31 <Seldaek>       I'm very interested in the topic 
     169Feb 17 11:20:35 <fabpot>        Seldaek: same for me 
     170Feb 17 11:20:48 *       johnkary (~johnkary@129.237.222.1) has joined #symfony-dev 
     171Feb 17 11:20:56 <fabpot>        kriswallsmith: Will you find some time to write a small chapter on assetic for the book? 
     172Feb 17 11:20:58 <kriswallsmith> i also need to write the loader that extracts assets from php templates 
     173Feb 17 11:21:21 <igorw> who is responsible for spriting stuff? one of the phpBB guys was doing something with that lately, he might be able to help 
     174Feb 17 11:21:22 <kriswallsmith> i need to solve the caching issue before i document it 
     175Feb 17 11:21:31 <fabpot>        kriswallsmith: ok 
     176Feb 17 11:21:34 *       krymen (~krymen@87.99.38.40) has joined #symfony-dev 
     177Feb 17 11:21:36 <kriswallsmith> once that's in place i'll be confident it's stable enough 
     178Feb 17 11:21:55 <pgodel_work>   talking about phpBB, is the bundle dependency going in RC1 ? 
     179Feb 17 11:21:56 <fabpot>        next thing to finish before RC1 is the conversion of the DIC extension configuration 
     180Feb 17 11:22:12 <fabpot>        pgodel_work: hopefully, but that will be though I think 
     181Feb 17 11:22:14 <kriswallsmith> anyone want to do that for AsseticBundle? 
     182Feb 17 11:22:16 <Stof>  I think 2 docs are needed: the doc about Symfony integration and the doc of the standalone library 
     183Feb 17 11:22:21 <weaverryan>    I'm working on some tweaks to the "Definition" class right now per the extensions 
     184Feb 17 11:22:46 <fabpot>        TwigBundle should also be migrated; this one should be easy. Anyone? 
     185Feb 17 11:22:50 <Stof>  kriswallsmith: I can convert AsseticBundle 
     186Feb 17 11:22:56 <kriswallsmith> Stof: thanks 
     187Feb 17 11:22:59 <weaverryan>    it's still somewhat difficult to use, because we're so "friendly" to different formats - something can be null, true, an array etc 
     188Feb 17 11:23:16 *       na8flush (~rosshette@c-67-175-220-187.hsd1.il.comcast.net) has left #symfony-dev 
     189Feb 17 11:23:27 <kriswallsmith> please send assetic-related pull requests through kriswallsmith/symfony 
     190Feb 17 11:23:41 <Stof>  ok 
     191Feb 17 11:24:00 <jmikola|w>     fabpot: what remains in Twig Bundle? 
     192Feb 17 11:24:04 <jmikola|w>     to the config builder? 
     193Feb 17 11:24:18 *       jonwage (~jwage@c-98-240-88-160.hsd1.tn.comcast.net) has joined #symfony-dev 
     194Feb 17 11:24:28 <jmikola|w>     I can do that today if so 
     195Feb 17 11:24:59 <fabpot>        jmikola|w: that would be great 
     196Feb 17 11:25:51 <weaverryan>    I'm still on the ODM - it's mostly finished locally - will love some feedback soon from the guys using it in prod :) 
     197Feb 17 11:25:57 <jmikola|w>     weaverryan: and please ping me when you submit a pull for Def changes, i'd be interested in tracking those 
     198Feb 17 11:26:16 <jmikola|w>     weaverryan: can accommodate you on ODM feedback, too :) 
     199Feb 17 11:26:27 <weaverryan>    will-do thanks 
     200Feb 17 11:27:22 <Stof>  DoctrineBundle needs to be converted too 
     201Feb 17 11:27:26 <Seldaek>       fabpot: next? 
     202Feb 17 11:27:57 <Stof>  I can work on it this weekend 
     203Feb 17 11:28:14 <weaverryan>    Stof: that's very-much related to the mongodb one - so let's coordinate somewhat 
     204Feb 17 11:28:18 <fabpot>        next topic: bootstrap.php in dev env 
     205Feb 17 11:28:19 <fabpot>        http://groups.google.com/group/symfony-devs/browse_thread/thread/5418d43e7ffdebd9 
     206Feb 17 11:28:22 <fabpot>        https://github.com/symfony/symfony-sandbox/pull/30 
     207Feb 17 11:28:24 <weaverryan>    would love to have your thoughts on it anyways 
     208Feb 17 11:29:07 <Seldaek>       fabpot: yes, so we talked a bit last time but you weren't there 
     209Feb 17 11:29:25 <jmikola|w>     fabpot: how is bootstrap currently generated? 
     210Feb 17 11:29:29 <kriswallsmith> do you mean in debug? 
     211Feb 17 11:29:30 <Seldaek>       basically it's about not using the bootstrap.php file in dev, because it makes it quite annoying to debug 
     212Feb 17 11:29:39 <fabpot>        it's not generated 
     213Feb 17 11:29:43 <fabpot>        it's included in the framework 
     214Feb 17 11:29:44 *       kertz_ (~kertz@122.167.181.206) has joined #symfony-dev 
     215Feb 17 11:29:53 <jmikola|w>     oh, it's not the result of addCompiledClass() ? 
     216Feb 17 11:29:58 <Stof>  jmikola|w: no 
     217Feb 17 11:30:03 <avalanche123>  +1 on not using bootstrap.php it in debug=true 
     218Feb 17 11:30:07 <Seldaek>       jmikola|w: nah that's another bootstrap :) 
     219Feb 17 11:30:17 <Seldaek>       it's the bootstrapped bootstrap 
     220Feb 17 11:30:19 <johnwards>     As a n00b to deving with Symfony2 it is a pain for getting my head around the codebase 
     221Feb 17 11:30:27 <Stof>  addCompiledClass create a classXXXX.php file in your cache 
     222Feb 17 11:30:28 <johnwards>     with bootstrap in dev 
     223Feb 17 11:30:45 <Stof>  johnwards: even for non-noob :) 
     224Feb 17 11:30:47 <jmikola|w>     Stof: oh, with the special loader? 
     225Feb 17 11:31:02 <Seldaek>       so.. if nobody has any argument against, we agree on removing bootstrap from the sandbox? 
     226Feb 17 11:31:08 <Stof>  jmikola|w: yes, this file is generated by ClassCollectionLoader 
     227Feb 17 11:31:10 <fabpot>        I want all the env to work the same way as much as possible 
     228Feb 17 11:31:13 <fabpot>        so, I'm )1 
     229Feb 17 11:31:17 <fabpot>        -1 
     230Feb 17 11:31:26 <Seldaek>       but what about generating it on the fly vs having it compiled? 
     231Feb 17 11:31:29 <fabpot>        and we can probably document how to de-activate it 
     232Feb 17 11:31:31 <Seldaek>       because then, envs could be the same 
     233Feb 17 11:31:40 <johnwards>     fabpot has a big point here. that is a big pain in sf1 
     234Feb 17 11:31:40 <fabpot>        Seldaek: not possible 
     235Feb 17 11:31:51 <Seldaek>       fabpot: yeah not completely 
     236Feb 17 11:32:00 <fabpot>        the bootstrap file contains things that are needed very early 
     237Feb 17 11:32:04 <fabpot>        so, it cannot be generated 
     238Feb 17 11:32:10 <jmikola|w>     chicken and egg problem? :) 
     239Feb 17 11:32:13 <Seldaek>       well, if you load the autoloader 
     240Feb 17 11:32:16 <Seldaek>       I guess it can? 
     241Feb 17 11:32:22 *       rooster has quit (Remote host closed the connection) 
     242Feb 17 11:32:25 <Seldaek>       that's how it was before no? 
     243Feb 17 11:32:35 <jmikola|w>     fabpot: so when these core classes change (if at all), you have to update the code in two places? 
     244Feb 17 11:32:42 *       kertz has quit (Ping timeout: 260 seconds) 
     245Feb 17 11:32:43 *       kertz_ is now known as kertz 
     246Feb 17 11:32:57 <Seldaek>       jmikola|w: there is a script to generate it 
     247Feb 17 11:33:01 <Seldaek>       it's just not done on the fly 
     248Feb 17 11:33:07 <fabpot>        jmikola|w: there is a script that need to be called to regenerate them 
     249Feb 17 11:33:27 <Seldaek>       so ..  -1? 
     250Feb 17 11:33:29 <Seldaek>       +1? 
     251Feb 17 11:33:30 <mvrhov>        you can live just fine without bootstra.php. I was until lsmith mentioned it last week that he'd like to exclude it from debug 
     252Feb 17 11:33:32 <jmikola|w>     and having bootstrap.php just require the things it currently includes inline would defeat the optimization?  it would avoid autoloading at least 
     253Feb 17 11:33:49 <Stof>  Seldaek: no. The only change was adding the Autoloader to the bootstrap file. It was not generated on the fly before 
     254Feb 17 11:34:20 <avalanche123>  is bootstrap.php even necessary? 
     255Feb 17 11:34:28 <fabpot>        avalanche123: yes, performance 
     256Feb 17 11:34:34 <avalanche123>  were there any benchmarks? 
     257Feb 17 11:34:41 <avalanche123>  I assume with performance you'd use APC 
     258Feb 17 11:34:43 <johnwards>     I'm not voting, but I think having the envs the same is very important. Then having it well documented on how to disable it for doing debug 
     259Feb 17 11:34:43 <fabpot>        avalanche123: yes, plenty 
     260Feb 17 11:34:48 <fabpot>        avalanche123: even with APC 
     261Feb 17 11:34:52 <avalanche123>  fabpot, I see 
     262Feb 17 11:35:07 <fabpot>        for a simple hello world, the difference can be up to 30% 
     263Feb 17 11:35:09 <fabpot>        with APC 
     264Feb 17 11:35:24 <avalanche123>  fabpot, gotcha, I understand 
     265Feb 17 11:35:35 <Seldaek>       well then let's move on to next topic, those that want can still disable it. ack? 
     266Feb 17 11:35:47 <fabpot>        yes, I will close the pull request then 
     267Feb 17 11:35:57 <avalanche123>  agree, that doesn't seem like a bc breaking change anyway 
     268Feb 17 11:36:01 <fabpot>        and perhaps write a some tuto on how to disable it 
     269Feb 17 11:36:07 <bschussek>     short comment 
     270Feb 17 11:36:19 <bschussek>     your statement about that 30% in hello world, is that relevant? 
     271Feb 17 11:36:26 <fabpot>        bschussek: no 
     272Feb 17 11:36:33 <avalanche123>  bschussek, that's the game we need to play 
     273Feb 17 11:36:40 <fabpot>        except for all the blog posts that try to benchmark frameworks 
     274Feb 17 11:36:46 <avalanche123>  yup 
     275Feb 17 11:36:48 <fabpot>        and I don't want to suffer like we did with symfony1 
     276Feb 17 11:36:51 <bschussek>     yes sure, but we're talking about dev env right? 
     277Feb 17 11:37:07 <fabpot>        bschussek: all the envs should work the same 
     278Feb 17 11:37:17 <fabpot>        that's one of the big pbe in symfony1 
     279Feb 17 11:37:19 <bschussek>     ok 
     280Feb 17 11:37:23 <fabpot>        things work in dev and not in prod 
     281Feb 17 11:37:52 <avalanche123>  next? 
     282Feb 17 11:38:09 <fabpot>        yes 
     283Feb 17 11:38:19 <fabpot>        cache warming 
     284Feb 17 11:38:34 *       ce_afk is now known as cescalante 
     285Feb 17 11:38:39 <fabpot>        I'm aware that the current way the cache warming works is not ideal 
     286Feb 17 11:38:46 <fabpot>        so, I will work on it next week 
     287Feb 17 11:38:52 <fabpot>        I don't see a need to talk about it now 
     288Feb 17 11:39:06 <Seldaek>       nope, there's https://github.com/fabpot/symfony/pull/618 
     289Feb 17 11:39:07 <avalanche123>  cool 
     290Feb 17 11:39:18 <Seldaek>       just needs an answer:) 
     291Feb 17 11:39:32 <kriswallsmith> fabpot: we should discuss before I write the Assetic cache stuff 
     292Feb 17 11:39:40 <fabpot>        kriswallsmith: ok 
     293Feb 17 11:39:50 *       unknownbliss has quit (Ping timeout: 240 seconds) 
     294Feb 17 11:39:51 *       igorkliks (~igorkliks@238-65.dsl.iskon.hr) has joined #symfony-dev 
     295Feb 17 11:40:00 <fabpot>        Seldaek: I work as much as I can but everyday is only 24 hours ;) 
     296Feb 17 11:40:23 <Seldaek>       fabpot: sure no problem, just pointing it out in case it got lost 
     297Feb 17 11:40:37 <Seldaek>       so, johanness are you there? 
     298Feb 17 11:40:42 <fabpot>        Seldaek: nothing is lost if it's on github 
     299Feb 17 11:41:05 <fabpot>        next topic is eager Response creation 
     300Feb 17 11:41:08 <Seldaek>       http://groups.google.com/group/symfony-devs/browse_thread/thread/0d1e05558bcbe275/7cdc3836e9de79b9#7cdc3836e9de79b9 
     301Feb 17 11:41:16 *       tecbot has quit () 
     302Feb 17 11:41:24 <Seldaek>       you were already -1 on the ml though iirc 
     303Feb 17 11:41:31 <fabpot>        my answer is very clear: if we change that, it's not Symfony2 anymore, so -1 
     304Feb 17 11:41:45 <Seldaek>       so it's not happening so skip? :) 
     305Feb 17 11:41:53 <kriswallsmith> sounds like a veto :) 
     306Feb 17 11:41:57 <Seldaek>       or someone wants to try and convince fabpot ? :p 
     307Feb 17 11:41:58 <avalanche123>  I agree with fabpot 
     308Feb 17 11:42:02 <avalanche123>  +1 on not doing that 
     309Feb 17 11:42:02 <weaverryan>    +1 to move on 
     310Feb 17 11:42:30 <fabpot>        route placeholders vs. GET parameters 
     311Feb 17 11:42:30 <johanness>     just as a note, i'm also not really convinced after doing a sample implementation 
     312Feb 17 11:42:43 <Seldaek>        http://groups.google.com/group/symfony-devs/browse_thread/thread/8d32595215d65b44 
     313Feb 17 11:42:47 <fabpot>        you will hate me, but I'm -1 also 
     314Feb 17 11:42:51 <Seldaek>       really 
     315Feb 17 11:42:55 <bschussek>     could you explain? 
     316Feb 17 11:42:57 <Seldaek>       I think this one actually makes sense 
     317Feb 17 11:43:05 <Seldaek>       for flexibility's sake 
     318Feb 17 11:43:21 <fabpot>        if you want that, that's possible by registering a listener 
     319Feb 17 11:43:38 <avalanche123>  you could still get the parameters from Request::$attributes, no? 
     320Feb 17 11:43:42 <Seldaek>       yeah but we know we can do anything we want in our fork.. that's not the point :) 
     321Feb 17 11:43:45 <fabpot>        I don't want that as parameters coming from the request must be isolated: POST, GET, PATH INFO, ... 
     322Feb 17 11:44:15 <Seldaek>       avalanche123: the problem is just that your controller has to know where it comes from 
     323Feb 17 11:44:19 *       ckwalsh (~ckwalsh@phpbb/developer/ckwalsh) has joined #symfony-dev 
     324Feb 17 11:44:28 <avalanche123>  Seldaek, make action that doesn't take any parameters 
     325Feb 17 11:44:32 <avalanche123>  and use Reqeust::get() 
     326Feb 17 11:44:34 <avalanche123>  :) 
     327Feb 17 11:44:35 <Seldaek>       fabpot: routing params are kind of get params in hiding though, prettified GET params 
     328Feb 17 11:44:36 <jmikola|w>     Seldaek: but a listener could move them to attributes, no? 
     329Feb 17 11:45:09 <bschussek>     jmikola|w: I think Seldaek is talking about a potential trap for other users 
     330Feb 17 11:45:20 <bschussek>     you think you can easily change the routing, but you can't 
     331Feb 17 11:45:20 <fabpot>        Seldaek: and what do you do when you have /foo/:id and the URL is /foo/12?id=foobar 
     332Feb 17 11:45:34 <Seldaek>       fabpot: route wins 
     333Feb 17 11:45:39 <Seldaek>       otherwise it's security issue 
     334Feb 17 11:45:45 <Seldaek>       because the route has the requirements 
     335Feb 17 11:45:50 <Seldaek>       query params don't 
     336Feb 17 11:46:14 <jmikola|w>     aren't those requirements a contract for the controller, though? (assuming your controller is only accessed through a given route) 
     337Feb 17 11:46:17 <Seldaek>       I'm not saying we have to advertise this as best practice, but I think it's nice if it's possible natively 
     338Feb 17 11:46:21 *       gordonslondon has quit (Quit: gordonslondon) 
     339Feb 17 11:46:42 <avalanche123>  fabpot maybe when we implement the full route template spec, that would be possible? 
     340Feb 17 11:46:54 <avalanche123>  as then you could specify requirements on GET parameters as well 
     341Feb 17 11:47:00 <fabpot>        avalanche123: I'm not sure how this is related 
     342Feb 17 11:47:28 <avalanche123>  well then get parameters can be validate and I don't see harm in injecting them automatically 
     343Feb 17 11:47:35 *       rande has quit (Quit: Leaving.) 
     344Feb 17 11:47:44 <avalanche123>  but since they are not validate now, it might lead to problems 
     345Feb 17 11:47:45 *       kertz has quit (Ping timeout: 246 seconds) 
     346Feb 17 11:47:48 <kriswallsmith> avalanche123: does the spec support that? 
     347Feb 17 11:47:49 <avalanche123>  *validated 
     348Feb 17 11:47:58 <fabpot>        avalanche123: ok, let's discuss that issue when we have support for the template spec then 
     349Feb 17 11:48:02 <Seldaek>       avalanche123: by default params match .+?, so it's not like we prevent injection of anything 
     350Feb 17 11:48:04 *       rande (~Adium@alpha.fullsix.com) has joined #symfony-dev 
     351Feb 17 11:48:04 <avalanche123>  kriswallsmith spec let's you define get paramters for a route 
     352Feb 17 11:48:15 <avalanche123>  and routing lets you define validation (requirements) 
     353Feb 17 11:48:17 <avalanche123>  kriswallsmith ^ 
     354Feb 17 11:48:33 *       rande has quit (Client Quit) 
     355Feb 17 11:48:42 <avalanche123>  Seldaek, but you could with attributes, not with get parameters 
     356Feb 17 11:48:44 <kriswallsmith> avalanche123: if it's in the spec, that seems like the way to go 
     357Feb 17 11:48:55 <bschussek>     so when we'd have this, we could inject GET parameters into the actions right? 
     358Feb 17 11:49:02 <fabpot>        anyway, this is something we might be able to add for a 2.1, there is no pressure to have it in 2.0 as BC will be kept 
     359Feb 17 11:49:10 <avalanche123>  fabpot +1 
     360Feb 17 11:49:21 <kriswallsmith> I would love to be able to a ?page={page} to my routes 
     361Feb 17 11:49:29 <kriswallsmith> *add 
     362Feb 17 11:49:36 <Seldaek>       bschussek: we could already imo, if we consider that /{id} is just /?id=foo beautified (which it is), {id} is a query parameter imo 
     363Feb 17 11:49:42 <avalanche123>  kriswallsmith yeah, that's what I mean 
     364Feb 17 11:49:43 <fabpot>        as of today, we need to concentrate on things that breaks BC 
     365Feb 17 11:49:50 <bschussek>     ok 
     366Feb 17 11:49:51 <Seldaek>       so we could treat them similarly, and allow injecting any of them in the action 
     367Feb 17 11:49:54 <avalanche123>  so -1 
     368Feb 17 11:50:09 <bschussek>     Seldaek: what about implementing that? we can still decide whether and when to merge it 
     369Feb 17 11:50:13 <kriswallsmith> +1 for 2.1 
     370Feb 17 11:50:33 <Seldaek>       bschussek: if fabpot is somewhat open to it, sure 
     371Feb 17 11:50:56 <Seldaek>       I don't see the reason not to allow GET params to be injected in actions really 
     372Feb 17 11:51:01 <fabpot>        Seldaek: I'm somewhat open to it, but not for 2.0 
     373Feb 17 11:51:18 <kriswallsmith> what's next? 
     374Feb 17 11:51:29 <fabpot>        we're done 
     375Feb 17 11:51:42 <Seldaek>       well, there's 2 left 
     376Feb 17 11:51:48 <fabpot>        Seldaek: but no vote on them 
     377Feb 17 11:51:58 <fabpot>        generate human readable docs out of bundle Configuration class 
     378Feb 17 11:52:00 <fabpot>        is the next one 
     379Feb 17 11:52:04 <kriswallsmith> I'm going to send a pull req for subtree-merging Zend\Log 
     380Feb 17 11:52:06 <fabpot>        but there is nothing to discuss 
     381Feb 17 11:52:17 <Seldaek>       yes I don't think so either 
     382Feb 17 11:52:21 <bschussek>     maybe there's someone here wanting to implement it? :) 
     383Feb 17 11:52:25 <weaverryan>    I'm hoping to get to this - but actually getting the merging done in all extensions is more important 
     384Feb 17 11:52:31 <Seldaek>       fabpot: and what about that https://github.com/fabpot/symfony/pull/561 
     385Feb 17 11:53:05 <kriswallsmith> is it possible to generate an xsd from a config definition? 
     386Feb 17 11:53:11 <Seldaek>       fabpot: is that the "one more thing"? is that why you don't answer? !! :p 
     387Feb 17 11:53:17 <fabpot>        lol 
     388Feb 17 11:53:18 <Seldaek>       damn secrets 
     389Feb 17 11:53:19 <kriswallsmith> theoretically, at least? 
     390Feb 17 11:53:21 <jmikola|w>     kriswallsmith: perhaps for simple things 
     391Feb 17 11:53:29 <jmikola|w>     even with doc generation, the issue is closures :) 
     392Feb 17 11:53:48 <bschussek>     I'd like to throw in a random topic then 
     393Feb 17 11:53:49 <johanness>     kriswallsmith, theoretically it's possible 
     394Feb 17 11:53:54 <bschussek>     bug tracking 
     395Feb 17 11:53:54 <fabpot>        As these helpers use intl, and as we don't have the replacement yet, I don't see how we will be able to include them in 2.0 
     396Feb 17 11:54:07 <kriswallsmith> it would be nice, to avoid duplication 
     397Feb 17 11:54:08 <fabpot>        bschussek: I'm working on installing Jira for 2.0 
     398Feb 17 11:54:15 <bschussek>     fabpot: awesome 
     399Feb 17 11:54:20 <fabpot>        should be available for the Symfony Live conf 
     400Feb 17 11:54:26 <jmikola|w>     for hackday? 
     401Feb 17 11:54:28 <bschussek>     cool 
     402Feb 17 11:54:31 <Seldaek>       I guess it's not worse than trac :( 
     403Feb 17 11:54:43 <fabpot>        Seldaek: any other viable option? 
     404Feb 17 11:54:45 <bschussek>     Seldaek: why? you've quite some experience with it right? 
     405Feb 17 11:54:56 <Seldaek>       fabpot: no I guess not, they all suck to some extent 
     406Feb 17 11:55:06 <fabpot>        Seldaek: correct 
     407Feb 17 11:55:06 <Seldaek>       but yeah I've gotten quite experienced at handling the 39302 options of jira 
     408Feb 17 11:55:09 <Seldaek>       if you need help 
     409Feb 17 11:55:09 <jmikola|w>     from my experience with jira, it just takes some initial time to define workflows and such 
     410Feb 17 11:55:13 <fabpot>        the concept of a bug tracker sucks 
     411Feb 17 11:55:32 <bschussek>     I'm quite satisfied with pivotal tracker, but that might be too small for our purpose 
     412Feb 17 11:55:33 <johnwards>     Githup issue tracker not suitable (i'm interested in why not) 
     413Feb 17 11:55:38 <kriswallsmith> we're using target process at OpenSky 
     414Feb 17 11:55:39 <fabpot>        Seldaek: I will probably ask some help then, thanks 
     415Feb 17 11:55:49 <pgodel_work>   fabpot: someone was asking if ESI was supported in the symfony http cache 
     416Feb 17 11:55:59 <fabpot>        pgodel_work: of course it is 
     417Feb 17 11:56:09 <jmikola|w>     kriswallsmith: please no target process :) 
     418Feb 17 11:56:14 <pgodel_work>   that's what I thought, he was having some troubles 
     419Feb 17 11:56:19 <kriswallsmith> lol 
     420Feb 17 11:56:20 <Seldaek>       fabpot: sure, once configured honestly it's usable. But the problem is most people use it with defaults and there is just too much craziness 
     421Feb 17 11:56:51 <fabpot>        Seldaek: how do you find the configuration of the Doctrine Jira instance? 
     422Feb 17 11:57:04 <Seldaek>       fabpot: it's quite an outdated version 
     423Feb 17 11:57:11 <fabpot>        hehe 
     424Feb 17 11:57:12 <Seldaek>       new one is slightly nicer 
     425Feb 17 11:57:21 <bschussek>     what about GitHubs issue tracking? any experience with that? 
     426Feb 17 11:57:32 <jmikola|w>     pgodel_work: that was jseverson from exercise.com (ornicar could probably chime in on that, too) 
     427Feb 17 11:57:35 *       notjosh has quit (Quit: notjosh) 
     428Feb 17 11:57:43 <Seldaek>       fabpot: anyway just ping me when you have it running and we can talk 
     429Feb 17 11:57:46 <pgodel_work>   jmikola|w: yup 
     430Feb 17 11:57:47 <jmikola|w>     bschussek: i think github's is very lightweight 
     431Feb 17 11:58:01 <bschussek>     jmikola|w: in a sense of too little features? 
     432Feb 17 11:58:04 <jmikola|w>     probably not suitable for such a large project, vs other packages that support github integration 
     433Feb 17 11:58:05 <Seldaek>       bschussek: github is really not scaling too well for such a big project 
     434Feb 17 11:58:12 <bschussek>     ok 
     435Feb 17 11:58:27 <jmikola|w>     i think jira with fisheye plugin or something could interpret commit id's pointed at github 
     436Feb 17 11:58:42 <igorw> there's also lighthouse 
     437Feb 17 11:58:42 *       dustinwhittle (~dustinwhi@home.dustinwhittle.net) has joined #symfony-dev 
     438Feb 17 11:59:00 <Seldaek>       jmikola|w: eww fisheye that's going too far for me:p 
     439Feb 17 11:59:18 <kriswallsmith> igorw: a Portland company :) 
     440Feb 17 11:59:18 <pgodel_work>   Seldaek: I know doctrine uses it (I think) 
     441Feb 17 11:59:36 <Seldaek>       pgodel_work: well, it's just the slowest code browser in the universe, but besides that I'm sure it's great:p 
     442Feb 17 11:59:44 <pgodel_work>   lol 
     443Feb 17 12:01:22 <naderman>      pgodel_work: working on it as we speak ;-) (dependency stuff) 
     444Feb 17 12:01:33 *       inspiran has quit (Ping timeout: 250 seconds) 
     445Feb 17 12:01:45 *       bschussek (~bschussek@99-191.78-83.cust.bluewin.ch) has left #symfony-dev 
     446Feb 17 12:01:46 <fabpot>        naderman: Perhaps you can say a bit more about the current status? and what still need to be done? 
     447Feb 17 12:02:09 <avalanche123>  naderman, are you working with everzet? 
     448Feb 17 12:02:16 <naderman>      well I have the rule generation working, I'm on the solving part now, I'll push something later tonight or tomorrow 
     449Feb 17 12:02:37 *       ornicar (~ornicar@66.87.0.133) has joined #symfony-dev 
     450Feb 17 12:02:43 <fabpot>        naderman: great! Are you still confident about having something for Symfony Live? 
     451Feb 17 12:02:45 <naderman>      which should be able to calculate the dependencies, what we then need is actual implementations of repositories/packages 
     452Feb 17 12:02:49 <naderman>      fabpot: yes 
     453Feb 17 12:02:57 <fabpot>        cool 
     454Feb 17 12:03:10 <fabpot>        naderman: sorry about the pressure 
     455Feb 17 12:03:20 <naderman>      no that's alright 
     456Feb 17 12:03:24 <naderman>      I would have wanted to work more on it 
     457Feb 17 12:03:30 <Seldaek>       naderman: if I can help with that let me know, instead of doing logging stuff that nobody wants you know:P though maybe you need logging in the depackager ;) 
     458Feb 17 12:03:33 <naderman>      but the last few days after I got back were a bit crazy 
     459Feb 17 12:04:07 <naderman>      heh, I'm sure it'll require plenty of work/help once there is a foundation ;-) 
     460Feb 17 12:04:16 <pgodel_work>   yup 
     461Feb 17 12:04:23 <Seldaek>       aye, don't be shy to share it though 
     462Feb 17 12:04:31 <naderman>      not at all 
     463Feb 17 12:05:13 <Seldaek>       well I don't see no repo! :) 
     464Feb 17 12:05:21 <fabpot>        Seldaek: there is a lot of ground work to do before being able to share -- naderman is porting an existing library (not aPython one this time, but a C one) 
     465Feb 17 12:05:24 *       webPragmatist has quit (Quit: Leaving.) 
     466Feb 17 12:05:49 <Seldaek>       fabpot: yeah I heard, but anyway I'm just very tired and being annoying.. guess I'll head home 
     467Feb 17 12:05:50 <fabpot>        and so, it does not make sense to share things before having ported lots of code 
     468Feb 17 12:06:12 <fabpot>        Seldaek: hmmm, I really need to work on Jira to get you some work then 
     469Feb 17 12:06:32 <naderman>      heh jira is a lot of fun to set up ... 
     470Feb 17 12:07:08 <naderman>      well if you want to adjust the workflow at least 
     471Feb 17 12:07:17 <pgodel_work>   you must have a very special meaning of "fun" :P 
     472}}}