On Wed, Jan 12, 2011 at 12:26 PM, Gaetano Giunta <giunta.gaet...@gmail.com> wrote: > James Pic wrote: >> >> What lib/program/framework does it better than the components and why ? > > Completely unrelated, but the Delphi VCL is the lib I have the fondest > memories of. >
Thanks for your great input! I've picked a random documentation page: http://delphi.wikia.com/wiki/Create_Your_Own_Paint_Program I must admit, that a tutorial to create a paint program, is way more exciting than for example the hello world tutorial. On Wed, Jan 12, 2011 at 1:44 PM, Maxime Thomas <maxime.t...@gmail.com> wrote: > 2011/1/12 Gaetano Giunta <giunta.gaet...@gmail.com> > >> James Pic wrote: >> >>> On Wed, Jan 12, 2011 at 8:46 AM, Christian Grobmeier >>> <grobme...@gmail.com> wrote: >>> >>> Maybe we >>>>>> must >>>>>> consider the fact to create a false dependancy to Debug, disabled by >>>>>> default. >>>>>> >>>>> What would be the benefits of that over xdebug ? >>> >>> I insist for your own good, maybe the source of your problem is not >>> specific to the components... are you sure you're using xdebug >>> correctly ? >>> >> A pertinent question: is xdebug considered a strict requirement for doing >> zetaC development? >> >> > I can see a limitation of the use of XDebug, but maybe you can correct me > and teach me how to solve this one : > > I'm developping under Windows with Eclipse like most of the dev and I'm > running my LAMP stack inside a VM with. > My project is a shared folder mounted via network. > XDebug can help me to debug the Apache PHP script but not the cli ones with > my configuration ? > > If it does the trick, we can just write this down and put it in a FAQ / side > subjects. There are many ways, please overview the official documentation before continuing: http://www.xdebug.org/docs/remote You should set: xdebug.remote_enable="1" xdebug.remote_host="the ip of your machine that has the IDE" Using your favorite IDE, you can set breakpoints in advance in files. That said, xdebug_break() often proves useful as well. Also, you can set xdebug.remote_autostart="1" if you want to make sure it starts every time php starts. I think the trickiest part of xdebug remote debugging is to understand that: 0) xdebug.so is the DBGP *client*, it must connect to the server 1) your IDE is the DBGP *server*, it must listen for incoming client connections My last advice is: use strace (or alternative from your OS) for troubleshooting. It's important to know if: 0) the client (your http server) connects to the right ip on the right port (default is 9000) 1) the server listens on the right ip (ie rather 0.0.0.0 than 127.0.0.1) and port > > A relevant question: is xdebug considered a strict requirement for doing > zetaC development? Depends. Most of the experienced coders will consider a debugger as a strict requirement for comfortable development (amongst other stuff like TTD, SCRUM etc ...). It is however required for ZetaC core development, ie. if you want to contribute back your features, bugfixes etc ... I however, as a professional coder like probably every one on this list, am payed to write code and to maintain it and to debug it so at the end of the day i'm actually payed to use a debugger. It has been that way for years. And man, I love working with xdebug and the components (amongst other things like vim or git). Thus, as a professional, i'd expect you to be paid to use a debugger instead of trying to log/print/output debug info with temporary codes. That said, i don't care if xdebug is a requirement or whatnot. If you my friend, need some assistance with using xdebug, then feel free to just pop in #zetacomponents or query me "jpic" on freenode, like Derick and others from the powerful eZC community helped me during years ;) So i'll return the question: should it the role of ZetaC to document good coding practices such as usage of a VCS or a debugger to users ? I'd tend to say: why not after all. Diversifying our activity could improve the end user experience. *BUT* in that case, should it really be the responsibility of the Apache Zeta Components project ? Or should another project document and try (thus, try to unify) actual PHP development with "the full gear" ? > In short, PhpUnit just failed to test Zeta's exceptions objects, and > neededI'd say yes. > an explicit bootstrap to do the job. UnitTests provides such a bootstrap > file, unfortunatly UnitTest is'nt part of the Zeta's PEAR packages yet, and > I just missed this point. I don't know if including the UnitTest into PEAR > is roadmapped for now. I think newbie dev like me need a short paragraph in > the Zeta tutorials, something like "How to implement PhpUnit tests into your > Zeta-based App" Are you talking about this 15-liner ? http://svn.apache.org/repos/asf/incubator/zetacomponents/trunk/UnitTest/src/bootstrap.php Needless to say, you can check php.net/function_name or zetac.org/class_name to access documentation of pretty much everything in this file. In fine, don't you think that we should actually document how to develop with Zeta Components, rather than documenting the components themselves ? Why should the docs cover xdebug and not subversion or even filesystems ? Maybe we want to consider writing a book that would guide the user through the realisation of a project, pretty much like djangobook, delphi vlc, "pragmatic guide to javascript". It does sound like a lot of work, but i'd agree it's worth a shot ... > Otoh debugging Symfony for 3 days brought me to the conclusion that the > smartness of the code that Fabien likes to write puts it beyond mere mortals > comprehension, and no advantages gained in reduced lines of code, > extensibility and execution speed are worth it in the end (this was > confirmed by reading his slide set about dependency injection in php 5.3). > > But maybe it's just me getting old and having a hard time learning new > styles / paradigms... :-) Thanks for this great feedback as well, you totally made my day :D -- http://jamespic.info Customer is king - Le client est roi - El cliente es rey.
